Post on 17-Aug-2018
transcript
Proyecto Fin de Carrera Ingeniería de Telecomunicación
Comunicación cooperativa entre vehículos:
Estudio e implantación del protocolo ISO CALM
en un sistema embebido usando OpenWrt
Autor: José Manuel Sampedro Armenta
Tutor: Federico José Barrero García
Co-tutor: José María León Coca
UNIVERSIDAD DE SEVILLA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA
2
Índice de contenido
v Capítulo I – Introducción y objetivos .....................................................................6
1.1 Los sistemas de transporte inteligentes ...............................................................7
1.2 Demostrador ITS ................................................................................................8
1.3 Objetivos del Proyecto .......................................................................................8
v Capítulo II - Proyectos ITS ...................................................................................10
2.1 Introducción a los proyectos ITS europeos .........................................................11
2.2 CVIS ................................................................................................................12
2.2.1 Objetivos .................................................................................................12
2.2.2 Tecnología Desarrollada ............................................................................12
2.3 COOPERS .........................................................................................................16
2.3.1 Objetivos .................................................................................................16
2.3.2 Tecnología desarrollada ............................................................................17
2.4 SAFESPOT ........................................................................................................21
2.4.1 Objetivos .................................................................................................21
2.4.2 Tecnología desarrollada ............................................................................22
2.5 GCDC...............................................................................................................26
2.5.1 Estrategias de implementación..................................................................28
2.5.2 Control robusto a prueba de fallos en tiempo real ......................................28
2.5.3 Estructura de la distribución de información en tiempo real........................29
2.5.4 La comunicación inalámbrica en entornos de tiempo real ...........................29
v Capítulo III - Tecnología ITS .................................................................................31
3.1 Introducción a las redes VANET.........................................................................32
3.2 WAVE ..............................................................................................................33
3.2.1 Capas PHY y MAC .....................................................................................35
3.2.2 Capa de red ..............................................................................................37
3.2.3 Seguridad en las comunicaciones...............................................................38
3.3 CALM ..............................................................................................................39
3.3.1 IEEE 802.16-WiMax...................................................................................40
3.3.2 CALM 2G/3G ............................................................................................40
3.3.3 CALM-IR ...................................................................................................40
3.3.4 DSRC........................................................................................................41
3.3.5 CALM M5 .................................................................................................41
3
3.4 Protocolo propuesto por GCDC .........................................................................42
3.4.1 Inconvenientes de la solución de CVIS........................................................42
3.4.2 Alternativa propuesta por el GCDC ............................................................43
3.4.3 Capas del modelo propuesto .....................................................................44
v Capítulo IV - Hardware y software utilizado ........................................................46
4.1 Hardware ........................................................................................................47
4.1.1 AlixBoard 3D2...........................................................................................47
4.1.2 MikroTik R52H..........................................................................................49
4.1.3 Elementos del entorno de desarrollo .........................................................50
4.2 Software..........................................................................................................51
4.2.1 Windows 7 ...............................................................................................51
4.2.2 Linux ........................................................................................................53
v Capítulo V - Desarrollo del sistema .....................................................................57
5.1 Generación del firmware ..................................................................................58
5.1.1 Instalación de Openwrt Buildroot ..............................................................58
5.1.2 Uso de OpenWrt Buildroot ........................................................................59
5.1.3 Generación del firmware CALM FAST .........................................................62
5.1.4 Traspaso a la tarjeta Compact Flash ...........................................................64
5.2 Inicialización ....................................................................................................65
5.2.1 Arranque del sistema ................................................................................65
5.2.2 Paquetes Wireless ....................................................................................68
5.3 Configuración de las comunicaciones ................................................................70
5.3.1 Modo infraestructura ...............................................................................71
5.3.2 Modo ad-hoc............................................................................................75
5.3.3 Modo CALM FAST .....................................................................................77
v Capítulo VI - Conclusiones ..................................................................................84
6.1 Resumen conclusivo .........................................................................................84
v Bibliografía ........................................................................................................86
v Anexo I ..............................................................................................................88
v Anexo II .............................................................................................................90
4
Índice de Figuras
Figura 1 - Carreteras del futuro .......................................................................................7
Figura 2 - Componentes del sistema. Proyecto CVIS........................................................14
Figura 3 - Capas de la arquitectura del sistema. CVIS ......................................................15
Figura 4 - Visión general de la comunicación en Coopers ................................................18
Figura 5 - Escenario inicial del proyecto Coopers ............................................................18
Figura 6 - Escenario final que Coopers persigue a largo plazo ..........................................19
Figura 7 - Implantación de tecnologías en un vehículo de prueba ....................................20
Figura 8 - Implantación de tecnologías en un poste fijo de carretera ...............................20
Figura 9 - Punto de vista del conductor del vehículo .......................................................21
Figura 10 - Elementos comunicantes .............................................................................23
Figura 11 - Caso de accidente en intersección ................................................................25
Figura 12 - Maniobra de cambio de carril .......................................................................25
Figura 13 - Adelantamiento peligroso ............................................................................26
Figura 14 - Escenario de ejemplo de GCDC .....................................................................27
Figura 15 - Arquitectura de comunicación de una VANET ................................................33
Figura 16 - Banda de frecuencia de DSRC .......................................................................34
Figura 17 - Capas y protocolos asociados de WAVE.........................................................34
Figura 18 - Tabla comparativa entre 802.11p y 802.11 ....................................................35
Figura 19 - Capas y protocolos propuestos por GCDC......................................................45
Figura 20 - ALIX 3D2......................................................................................................47
Figura 21 - Tabla de características de la ALIX 3D2 ..........................................................48
Figura 22 - Mikrotik R52H .............................................................................................49
Figura 23 - Tabla de características de las tarjetas MikroTik ............................................49
Figura 24 - Esquema de conexionado para el desarrollo..................................................51
Figura 25 - Software para el desarrollo y software para la implementación ......................51
Figura 26 - Menú de configuración de OpenWrt Buildroot ..............................................60
Figura 27 - Conexión de elementos en la inicialización ....................................................65
Figura 28 - Configuración de conexión por puerto serie usando PuTTy.............................66
Figura 29 - Configuración inicial de red mostrada por ifconfig .........................................67
Figura 30 - Configuración de direccionamiento estático en Windows...............................68
Figura 31 - Dependencias de los paquetes para la comunicación inalámbrica ...................69
5
Figura 32 - Esquema general de direccionamiento..........................................................71
Figura 33 - Topología del modo infraestructura ..............................................................72
Figura 34 - Topología del modo adhoc ...........................................................................76
Figura 35 - Resultado de iwconfig con interfaz en modo adhoc .......................................77
Figura 36 - Resultado de iwconfig con interfaz configurada según GCDC ..........................79
Figura 37 - Frecuencia usada en la configuración GCDC...................................................79
Figura 38 - Resultado de sendbeacons ...........................................................................80
Figura 39 - Resultado de fastsniff...................................................................................81
Figura 40 - Routers comunicándose mediante CALM FAST en la Sala de Proyectos ...........82
6
Capítulo I
Introducción y objetivos
El aumento en la movilidad de personas y mercancías lleva al problema de la congestión de
tráfico y a la gran cantidad de accidentes que se producen cada año en las carreteras, así como
al aumento de consumo de energía y los problemas medioambientales. La respuesta a estos
importantes retos no puede limitarse a medidas tradicionales, como la ampliación de las
infraestructuras del transporte, sino que la innovación ha de desempeñar una función
fundamental. En este ámbito, este primer capítulo introduce el concepto de los sistemas de
transporte inteligente o ITS, cuyo estudio y desarrollo va a ser el objetivo principal que
persigue el presente proyecto de fin de carrera.
7
1.1 Los sistemas de transporte inteligentes
El área de investigación centrada en los ITS es una disciplina joven que evoluciona
rápidamente, lo que dificulta el consenso en una definición única. Si se toma como referencia la
Directiva 2010/40/UE de la Unión Europea, se tiene que los ITS son: “los sistemas en los que se
aplican tecnologías de la información y las comunicaciones en el ámbito del transporte por
carretera, incluidos infraestructuras, vehículos y usuarios, y en la gestión del tráfico y de la
movilidad, así como para las interfaces con otros modos de transporte”. Actualmente, los
fabricantes siguiendo el enfoque de los ITS y gracias a los grandes avances tecnológicos, están
incorporando cada vez mayor cantidad de sensores al vehículo con los que mejorar la
experiencia de la conducción. Esto va acompañado del auge de los sistemas empotrados o
embebidos, microprocesadores diseñados para realizar tareas específicas dentro de un sistema
de mayor entidad. El uso de estos sistemas se ha incrementado de manera creciente en los
últimos años debido a su gran aplicabilidad en cualquier ámbito sectorial, destacando
especialmente su gran expansión dentro del sector automovilístico. En esta línea de incluir los
progresos tecnológicos en materia de electrónica, automática y tecnologías de la información,
y continuando con la tendencia de hoy en día centrada en ofrecer al usuario productos
inteligentes, los Smartcars o coches inteligentes van a acabar por convertirse en una realidad
cotidiana. Sin embargo, el objetivo final de los ITS va más allá de la simple mejora de las
prestaciones individuales de cada vehículo, sino que persigue la consolidación de las redes
vehiculares. Estas redes supondrán una revolución en la mejora de la seguridad vial y en la
eficiencia en la conducción. Por tanto, es en este punto donde los avances en la electrónica de
comunicaciones y los protocolos de telecomunicación van a jugar un papel crucial.
Figura 1 - Carreteras del futuro
8
1.2 Demostrador ITS
Dentro del ámbito de los ITS, este proyecto persigue dar los primeros pasos en la creación
de un sistema demostrador con el que poner a prueba las nuevas tecnologías de comunicación
vehicular, haciendo especial hincapié en la comunicación cooperativa y siguiendo las
directrices e influencias de:
• Los proyectos europeos CVIS, COOPERS, SAFESPOT, GCDC.
• Los estándares 802.11p, IEEE 1609, ISO-CALM.
• Proyectos realizados en el departamento de electrónica: VisioWay, AudioZity.
El objetivo final es dotar a un vehículo de un sistema de comunicaciones externo V2V/V2I,
que se corresponden con las comunicaciones vehículo a vehículo y vehículo a infraestructura,
así como la creación de un sistema de comunicaciones y control interno que permitan mejorar
las prestaciones del vehículo. Por último, para completar el sistema demostrador será
necesario además del propio vehículo una entidad externa de comunicación.
1.3 Objetivos del Proyecto
Mientras que el trabajo relativo al sistema de comunicaciones internas del vehículo se
abordará en proyectos paralelos, el siguiente documento se centra específicamente en el área
relacionada con las comunicaciones exteriores del automóvil, conocidas como V2V / V2I. Dicho
sistema de comunicaciones se va implantar según los nuevos estándares europeos ISO-CALM.
Como se comentaba anteriormente se van a seguir los pasos dados por proyectos europeos
como COOPERS, CVIS y SAFESPOT, cuyo fruto es el propio estándar ISO-CALM. También, dado
que es pública la documentación y procede de estos proyectos, se va a estudiar el evento
GCDC (Grand Cooperative Drive Challange), iniciativa holandesa para conseguir implantar estas
tecnologías.
Por consiguiente, el principal propósito es la obtención de la entidad encargada de las
comunicaciones exteriores a la que, siguiendo la definición del sistema propuesto por el
proyecto CVIS, denominaremos Mobile Router. Esta entidad, para cuya implementación se ha
elegido una plataforma con Linux empotrado, debe permitir la comunicación inalámbrica
según los nuevos estándares de comunicación cooperativa en redes vehiculares. Atendiendo a
9
los objetivos que se pretenden cubrir hasta alcanzar el propósito principal de reproducir esta
entidad, el siguiente documento se organiza de la siguiente manera:
• Capítulo I. Explicar la importancia del desarrollo de los ITS y definir los objetivos del
proyecto
• Capítulo II. Estudio de los proyectos ITS europeos y del evento GCDC.
• Capítulo III. Estudio de las tecnologías que rodean a los ITS y de la herencia tecnológica
del evento GCDC.
• Capítulo IV. Descripción del hardware y el software elegidos tanto para el entorno de
desarrollo como para la implementación de una entidad Mobile Router.
• Capítulo V. Generación, instalación y configuración del sistema operativo que logre
reproducir una entidad Mobile Router que permita utilizar el estándar CALM. Todo ello
según la documentación procedente del GCDC y a la vez que se estudian las
posibilidades que ofrece la distribución de Linux para sistemas embebidos, Openwrt.
• Capítulo VI. Exponer las conclusiones extraídas y presentar las posibles líneas futuras
de investigación.
10
Capítulo II
Proyectos ITS
En el siguiente capítulo se pretende dar una idea general del contexto actual de desarrollo
de las tecnologías ITS, describiendo algunos de los proyectos europeos más importantes que
se han realizado por iniciativa del Sexto Programa Marco. Se ahonda en la visión y enfoque de
cada uno de estos proyectos, especificando sus objetivos y el trabajo llevado a cabo. Para
terminar, se habla de una iniciativa surgida a raíz de la cooperación entre estos proyectos y
que persigue incentivar el estudio sobre la comunicación entre vehículos.
11
2.1 Introducción a los proyectos ITS europeos
Los ITS son el futuro para garantizar la seguridad vial y reducir el tráfico, como ya se ha
comentado anteriormente. Muchos países como EEUU y Japón están llevando a cabo
proyectos para asegurar la implantación de dichos sistemas y en Europa esta iniciativa viene de
la mano del proyecto eSafety. La antesala de este proyecto europeo puede situarse en
septiembre de 2001, cuando la Comisión Europea presenta el Libro Blanco “Política Europea
de Transporte para 2010”, donde establece el objetivo de reducir en un 50% el número de
fallecidos para 2010. Este objetivo requiere un incremento y una mayor coordinación en el
esfuerzo de todos los grupos. A raíz de esta nueva política de transporte, la Comisión Europea,
conjuntamente con la industria, lanza la “iniciativa eSafety” en abril de 2002 con el fin de
acelerar el desarrollo, implementación y uso de los Sistemas Inteligentes de Seguridad basados
en Tecnologías de la Información y la Comunicación (TIC), para mejorar la seguridad vial. Para
ello se crea el “eSafety Forum” como plataforma para canalizar y monitorizar las actuaciones
de todos las partes interesadas. En febrero de 2006, Impulsados por eSafety y dentro del Sexto
Programa Marco, se inician los proyectos europeos CVIS, COOPERS y SAFESPOT. Durante los
tres años que duraron se consolidaron como los tres proyectos que más han contribuido al
desarrollo de los sistemas cooperativos, abordando el problema de la seguridad en las
carreteras y la eficiencia del tráfico pero desde diferentes enfoques:
• CVIS persigue diseñar y probar una tecnología que sea la base para los sistemas de
comunicación cooperativos.
• COOPERS se centra en los sistemas cooperativos desde el punto de vista de las
infraestructuras públicas.
• SAFESPOT se centra en los sistemas cooperativos desde el punto de vista del vehículo y
del usuario, prestando especial atención a las tareas críticas que se pueden realizar en
la carretera.
Los resultados finales de estos proyectos estuvieron reflejados en el evento The
Cooperative Mobility Showcase 2010, llevado a cabo dentro de la iniciativa GCDC y que tuvo
lugar en Amsterdam entre el 23 y el 26 de marzo de 2010 en asociación con Intertraffic
Amsterdam 2010, feria líder mundial de infraestructuras, gestión de tráfico y seguridad vial.
Este evento fue una de las más grandes manifestaciones mundiales de cooperación vehículo a
vehículo y vehículo a infraestructura.
12
A continuación, se describen con más detalles los proyectos CVIS, COOPERS y SAFESPOT así
como el evento GCDC.
2.2 CVIS
EL proyecto CVIS (Cooperative Vehicle-Infrastructure Systems) estuvo destinado a crear un
sistema para la cooperación de vehículos e infraestructuras viales aportando una capa extra
para el enriquecimiento de la conducción en aspectos tan importante como la seguridad y
eficiencia del sistema de transporte. El proyecto fundado por la Comisión Europea fue apoyado
por un consorcio de 60 universidades, centros de investigación, autoridades públicas y
empresas de gran importancia en el sector automovilístico, de las telecomunicaciones y la
electrónica, como pueden ser Renault, Vodafone y Siemens.
2.2.1 Objetivos
Entre los objetivos del proyecto se puede destacar:
• Crear una solución unificada que permita a todos los vehículos y elementos de la
infraestructura comunicarse entre sí de una manera continua y transpare nte utilizando
los diferentes medios de comunicación disponibles.
• Permitir una amplia gama de servicios cooperativos para el vehículo y los elementos
de carretera.
• Definir y validar una arquitectura abierta para aplicaciones de sistemas cooperativos, y
desarrollar los componentes básicos para las aplicaciones y los servicios destinados a
los conductores, operadores, empresas y otras partes interesadas.
• Abordar cuestiones como la aceptación de los usuarios, la privacidad y seguridad de
datos, la interoperabilidad del sistema, las necesidades de las políticas públicas, los
modelos de coste/beneficio, y la puesta en marcha de planes para su implementación.
2.2.2 Tecnología Desarrollada
El trabajo llevado a cabo ha desembocado en la definición de un sistema de
comunicaciones común, en el que se han especificado los elementos que lo forman, la
arquitectura y los estándares de comunicación empleados. Esto ha sentado las bases para la
posible creación de aplicaciones que mejoren la seguridad vial y la gestión del tráfico.
13
2.2.2.1 Elementos del sistema
El sistema propuesto por CVIS, en el cual se basa el trabajo realizado durante este
proyecto de fin de carrera, puede componerse por dos tipos de unidades denominadas OBU
(On Board Unit) y RSU (Road Side Unit).
A su vez, en la OBU se distinguen los siguientes elementos:
• Mobile Router: Entidad encargada de las comunicaciones del vehículo, tanto en el
exterior como en el interior. El entorno de ejecución está basado en Java y en OSGi,
sistema modular para Java que establece la manera de crear módulos y como estos
interactúan entre sí en tiempo de ejecución.
• Vehicle Host: Entidad encargada del control de todos los elementos del coche, podría
definirse como el ordenador de abordo tal y como se conoce en la actualidad.
• Vehicle Gateway: Entidad encargada de ser la pasarela entre el ordenador de a bordo y
los sensores y elementos de control del vehículo. La idea es ofrecer una capa de
protección entre la infraestructura CVIS y la infraestructura de nuestro subsistema.
• Human Media Interface (HMI): Entidad opcional que se conecta al sistema de forma
inalámbrica gracias al Mobile Router y muestra al usuario datos del vehículo y le
permite controlar alguno de ellos.
Mientras que en la RSU se distinguen:
• Router: Entidad encargada de proporcionar una interfaz de comunicaciones con el
exterior a un sistema de carretera ya instalado.
• Control Unit: Unidad de control del sistema de carretera.
En la siguiente imagen se puede ver los diferentes componentes que forman el sistema:
vehículo, unidad de carretera, sistema central y unidad móvil, conectados bajo IPv6 sobre el
que se implementa el protocolo CALM.
14
Figura 2 - Componentes del sistema. Proyecto CVIS
2.2.2.2 Comunicación
Una parte de suma importancia en un proyecto encargado de la interconexión de
diferentes sistemas es obviamente, la comunicación. CVIS hace uso del estándar CALM para
proporcionar la comunicación I2I, V2I, V2V. Este estándar define una serie de protocolos y
parámetros para la comunicación de sistemas ITS de alta velocidad en un rango medio-alto
mediante la utilización de diferentes métodos de transmisión. La intención es crear un
estándar para ITS que mantenga una conexión continua e independientemente del tipo de
sistema de comunicación usado. La conexión usada en cada momento será elegida por el
sistema de manera dinámica basándose en las condiciones, siendo posible utilizar los
siguientes tipos de comunicación:
• Redes móviles celulares (2G, 3G).
• Comunicaciones infrarrojas.
• Redes inalámbricas de área local (WiFi/802.11p).
• Comunicaciones de corto alcance (DSRC) en el rango de los 5.9GHz.
2.2.2.3 Arquitectura
La arquitectura del sistema ofrece un desarrollo seguro, robusto y abierto a la
interoperabilidad con diferentes ITS. La principal característica de la arquitectura es que
permite conecta los sistemas del vehículo y las infraestructuras de carreteras de manera que la
implementación sea independiente, lo que posibilita la implementación por diferentes
15
fabricantes y diferentes tecnologías. Sin embargo, la parte del entorno de ejecución está fijada
para asegurar la máxima funcionalidad del sistema, debiendo ser un entorno de ejecución
Java/OSGi sobre un sistema UNIX.
Figura 3 - Capas de la arquitectura del sistema. CVIS
Como se puede ver en la figura, la arquitectura del sistema está divida en capas donde
cada una solo puede realizar la comunicación con la capa adyacente. La capa superior o de
aplicación ofrece un servicio final al usuario. La capa intermedia está dividida en dos subcapas,
una sobre la otra, encargadas de la ejecución de las aplicaciones. Por un lado existe una capa
encargada de ofrecer servicios a la capa de aplicaciones, y por otro el módulo OSGi encargado
de la ejecución de las aplicaciones. Durante la ejecución de las aplicaciones estas realizan
accesos a la capa de Domain Facilities para la operación y colaboración necesaria para ofrecer
el servicio final al usuario. La capa de más bajo nivel está formada por el sistema operativo
encargado de las comunicaciones y el acceso al hardware.
2.2.2.4 Aplicaciones
La definición del sistema propuesto por CVIS ha supuesto un impulso importantísimo para
la correcta administración de la red de tráfico y la seguridad vial , y ha desembocado en que se
comiencen a desarrollar aplicaciones como las siguientes:
• Administración de prioridad: Dependiendo de la prioridad del vehículo se pueden
modificar los semáforos y demás señales viales para favorecer su desplazamiento.
Actualmente esta aplicación se encuentra implementada en numerosas ciudades para
16
el transporte público, así cuando un autobús se aproxima a un semáforo este manda
una señal para solicitar paso y favorecer la movilidad de los servicios de transporte
público.
• Información extendida para la seguridad: El conductor del vehículo puede recibir
información sobre el estado de la carretera, condiciones climatológicas, congestión de
tráfico, velocidad media de los vehículos circulantes y demás aspecto para posibilitar
una conducción segura y ajustada a las condiciones actuales de la vía.
• Planificación de rutas para vehículos: Dependiendo del estado del tráfico, el sistema
podrá gestionar las diferentes rutas de los vehículos facilitando una correcta
administración de los recursos disponibles.
Muchas más aplicaciones pueden ser desarrolladas gracias a la gran cantidad de
información que este sistema puede aportar. La idea consiste en ofrecer APIs a los
desarrolladores para que puedan ofrecer sus propias aplicaciones y conseguir un ecosistema
amplio en torno al proyecto.
2.3 COOPERS
El proyecto Coopers (Co-operative Systems for Intelligent Road Safety) se centra en el
desarrollo de aplicaciones telemáticas innovadoras con el objetivo a largo plazo de una gestión
del tráfico cooperativa entre vehículos e infraestructuras. El principal propósito del proyecto es
la mejora de la seguridad vial proporcionando una información directa y actualizada entre
infraestructuras de carretera y vehículos motorizados en un tramo de carretera. Para cumplir
con este objetivo, se involucraron 39 socios de diversos países coordinados por AustriaTech.
2.3.1 Objetivos
Entre los principales objetivos que persigue el proyecto cabe resaltar:
• Mejorar la infraestructura vial de sensores y las aplicaciones de control de tráfico para
obtener una información más precisa de la situación y así asesorar adecuadamente al
conductor.
• Establecer un vínculo entre los sistemas de peaje y el concepto I2V.
17
• Desarrollar un concepto de comunicación y aplicaciones capaces de hacer frente a las
necesidades I2V en términos de fiabilidad, capacidad en tiempo real y robustez,
considerando diferentes tecnologías de transmisión.
• Demostrar los resultados en importantes sectores de autopistas europeas con alta
densidad de tráfico como los Países Bajos, Francia, Alemania, Austria e Italia, y
desarrollar estrategias de implementación para entornos mixtos.
Para conseguir estos objetivos se ha trabajado en las siguientes áreas:
• Adquisición de datos de la carretera.
• Configuración de la unidad de carretera y de la unidad de abordo.
• Centro de control del tráfico (TCC – Traffic Control Center) y aplicaciones del mismo.
• Servicios de información y metodologías de pruebas.
• Simulación y demostración.
2.3.2 Tecnología desarrollada
El proyecto Coopers, basándose en la arquitectura propuesta por CVIS, implementa la
comunicación cooperativa desde el punto de vista de las infraestructuras de la vía pública. De
este modo, el proyecto ha logrado un escenario en el que se sustituyen las infraestructuras de
señalización exteriores por una comunicación inalámbrica directa con los vehículos como se
describe a continuación.
2.3.2.1 Escenario
En el escenario que propone Coopers, los vehículos están conectados mediante una
conexión inalámbrica con las infraestructuras de carretera, intercambiando datos e
información relevante acerca de unos tramos específicos de la autovía, ayudando de este
modo a aumentar la seguridad vial y permitir la gestión del tráfico de forma cooperativa.
18
Figura 4 - Visión general de la comunicación en Coopers
Este escenario proporciona:
• Un intercambio más rápido de información entre las infraestructuras y los vehículos.
• Seguridad vial mejorada, al tener información actualizada en tiempo real.
• Información relativa a la congestión del tráfico, el estado de la carretera, el tiempo.
• Identificación de accidentes e infracciones.
Sin embargo, la situación inicial con la que comienza a trabajar Coopers puede verse en la
imagen siguiente. Como se observa, los típicos postes de información conviven con la
comunicación inalámbrica para tener dos vías que aporten información al conductor. A largo
plazo se intentaría eliminar la necesidad de toda esta señalización tradicional para ser
sustituida por la más moderna información inalámbrica que aporta el proyecto.
Figura 5 - Escenario inicial del proyecto Coopers
19
A continuación se puede ver una imagen del escenario final que se pretende lograr a largo
plazo, en el que la información se dirige directamente a los vehículos sin necesidad de utilizar
la tradicional señalización exterior.
Figura 6 - Escenario final que Coopers persigue a largo plazo
2.3.2.2 Comunicación
Como se puede observar el proyecto Coopers está fuertemente orientado a una
comunicación I2V. Para llevar a cabo esta comunicación en el proyecto se usó:
• DAB / DVB-H
• GPRS / WIMAX
• CALM IR
Además, durante la fase de desarrollo del proyecto se amplió el conjunto de mensajes
inicial para poder así cubrir todos los servicios ofertados por Coopers.
2.3.2.3 Simulaciones realizadas
Puesto que el proyecto ya ha finalizado, se han realizado demostraciones con éxito del
mismo. En la siguiente figura se puede observar algunas imágenes sobre la implantación de
elementos en un vehículo de prueba.
20
Figura 7 - Implantación de tecnologías en un vehículo de prueba
De igual manera, en esta otra imagen se puede apreciar la implantación de ciertas
tecnologías en postes fijos en carretera.
Figura 8 - Implantación de tecnologías en un poste fijo de carretera
21
Y por último, se presenta la imagen de cómo se vería esta tecnología desde el punto de
vista del conductor del vehículo.
Figura 9 - Punto de vista del conductor del vehículo
2.4 SAFESPOT
El proyecto SAFESPOT se centra en la creación de una red de comunicación inter-vehicular
para la prevención de accidente s y la mejora de la seguridad en carretera. Para conseguir esta
red se buscan soluciones cooperativas que analicen la información de los vehículos y de las
infrae structuras, para aplicarlas en primer lugar a las áreas críticas, tales como los llamados
"puntos negros". El proyecto, cofundado por la Comisión Europea y apoyado por EUCAR, ha
probado las diferentes aplicaciones desarrolladas en seis sitios de prueba distintos que
involucran a seis países europeos, entre ellos España. Además, cuatro de los sitios de prueba
fueron compartidos con el Proyecto Integrado CVIS. Entre los participantes se encuentran
multitud de universidades y empresas del sector automovilístico y de las telecomunicaciones,
coordinadas por el FIAT Research Center.
2.4.1 Objetivos
Los objetivos que persigue el proyecto pueden resumirse en:
• Utilizar las infraestructuras y los vehículos como fuentes y destinos de la información.
• Obtener una arquitectura abierta, segura, flexible y modular.
22
• Desarrollar las tecnologías esenciales: red dinámica ad-hoc, localización relativa
precisa, mapas dinámicos del tráfico local.
• Desarrollar y probar aplicaciones basadas en escenarios para evaluar los impactos
sobre la seguridad vial.
• Definir una estrategia de implementación sostenible de los sistemas de cooperación
para la seguridad vial, teniendo en cuenta los aspectos de normalización.
Para conseguir estos objetivos ha sido necesario hacer frente a los siguientes retos:
• La disponibilidad de una comunicación fiable, rápida y segura.
• Implementar la tecnología de radio: IEEE 802.11p.
• Necesidad de una banda segura de frecuencia específica para V2V y V2I, evitando
interferencias, en línea con los grupos de normalización CALM.
• La disponibilidad de información fiable, muy precisa, en tiempo real de la posición
relativa.
• La disponibilidad en tiempo real del mapa local dinámico.
2.4.2 Tecnología desarrollada
El trabajo realizado, basándose en el sistema de comunicación propuesto por CVIS, se
centra en la seguridad vial desde el punto de vista del usuario del automóvil. El resultado
conseguido se traduce en la obtención de una gama de aplicaciones, cada una de ellas
enfocada a solventar una posible situación crítica que pudiera desembocar en accidente por
parte del vehículo.
2.4.2.1 Aplicaciones
Las aplicaciones tienen en cuenta los siguientes elementos comunicantes:
• Vehículos inteligentes equipados con los sistemas cooperativos.
• La infraestructura inteligente que incluye las unidades de carretera.
• Centros de seguridad y/o de Tráfico que son capaces de centralizar o transmitir la
información de seguridad procedente del vehículo y/o la infraestructura inteligente.
23
Figura 10 - Elementos comunicantes
Teniendo en cuenta estos elementos, las aplicaciones desarrolladas buscan:
• Aumentar la seguridad vial de todos los usuarios de la vía.
• Ampliar el alcance, mejorar la calidad y la fiabilidad de la información relacionada con
la seguridad ofreciendo una amplia cooperación a todos los conductores.
• Ayuda a los conductores a la hora de elegir las maniobras adecuadas en los diferentes
contextos.
• Optimizar la intervención del vehículo en las situaciones críticas.
• Posibilitar el desarrollo de nuevas aplicaciones de seguridad basadas en el enfoque
cooperativo.
Cada aplicación está pensada para actuar como un actor principal y uno secundario. El
principal está relacionado con la generación de una advertencia al conductor del propio
vehículo mientras que el secundario es un nodo del vehículo o la infraestructura responsable
de generar la información que debe comunicarse a otros vehículos o a la infraestructura. A su
vez las aplicaciones pueden clasificarse en aplicaciones basadas en vehículos y aplicaciones
basadas en infraestructuras. Las aplicaciones basadas en vehículos son aquellas que actúan
directamente sobre los vehículos y tienen en cuenta conceptos de seguridad vial como:
• Seguridad vial en intersección
• Cambio de carril de maniobra
• Adelantamiento seguro
• Colisión trasera
• Limitación de la velocidad y la distancia de seguridad
• Advertencia de colisión frontal
• Estado de las condiciones del camino - carretera resbaladiza
24
• Alerta de curva peligrosa
• Detección y prevención de usuarios vulnerables a accidentes
Por otro lado, las aplicaciones basadas en infraestructura son aquellas en los que se
procesan los datos y las decisiones son tomadas por la infraestructura vial en colaboración con
los vehículos. Estas aplicaciones tienen por objeto proporcionar la recomendación más
eficiente al conductor a través del panel de operador a bordo y por carretera a través de
dispositivos de comunicación secundarios, siendo las recomendaciones previstas las
siguientes:
• Alerta de velocidad
• Peligros y advertencias de incidente
• Prevención salida del camino
• Intersección de seguridad inteligente cooperativa
• Margen de seguridad para los vehículos de asistencia y de emergencia
2.4.2.2 Simulaciones realizadas
Como ya se ha comentado, el proyecto SAFESPOT ha puesto una gran atención en
identificar todas las posibles situaciones peligrosas que pueden llevar a que se produzcan
accidentes en la carretera. Una vez definidos estos casos críticos la principal tarea de las
aplicaciones desarrolladas va a consistir en identificar cuando se está produciendo una de
estas situaciones y enviar mensajes de advertencia tanto al usuario del vehículo como al resto
de vehículos cercanos. A continuación se muestran algunas aplicaciones desarrolladas,
asociadas cada una de ellas a uno de los posibles casos de riesgo que se han identificado.
Por ejemplo, la aplicación de seguridad en intersección es una de las más importantes,
activándose cuando se detecta alguna de las siguientes situaciones de riesgo:
• Vehículo accidentado en la intersección
• Vista obstruida en la intersección
• Denegación de permisos de vía libre
• Defectos de Señales de tráfico
• Otro vehículo frena bruscamente debido a un semáforo en rojo
• Aviso de aproximación de vehículo de emergencia
25
Figura 11 - Caso de accidente en intersección
Tomando como ejemplo el caso en el que hay un vehículo accidentado en la intersección,
la aplicación responderá ante esta situación peligrosa haciendo que el vehículo que ha sufrido
el accidente advierta al resto de conductores que se acerquen. Esta advertencia a los usuarios
por parte de la aplicación puede ser vital ya que las intersecciones son probablemente la parte
más compleja de las infraestructuras viarias donde las colisiones pueden causar lesiones
graves o la muerte. En las intersecciones el flujo de tráfico es muy complejo, por lo que el
comportamiento al volante de los demás conductores puede cambiar de inmediato, debido a
este tipo de situaciones no previstas.
Otra aplicación a destacar es la aplicación de cambio de carril que tiene en cuanta los tres
siguientes casos de riesgo:
• Maniobra de cambio de carril para camiones con puntos ciegos
• Maniobra de cambio de carril para automóviles / camiones
• Maniobra de cambio de carril para rampa en autopistas
Figura 12 - Maniobra de cambio de carril
Como puede observarse en la figura anterior, para el escenario en el que se produce un
cambio de carril en los que intervienen camiones con puntos ciegos, la aplicación tiene como
objetivo informar y advertir al conductor del camión (V1) sobre la presencia de otros vehículos
(V2) a su alrededor durante la maniobra. Incluso si los espejos laterales especiales ayudan al
conductor a tener una buena visión en torno a su vehículo, los puntos ciegos ya existen en
algunas situaciones. La información de la velocidad relativa de los demás vehículos puede
tenerse en cuenta para apreciar la seguridad de algunas maniobras. Con estas precauciones
algunos choques laterales y las colisiones traseras con otros vehículos pueden ser evitados.
26
Por último las situaciones de adelantamiento también se han identificado como caso de
riesgo, en especial cuando intervienen diferentes tipos de vehículos como las motocicletas.
Esto se ha tenido en cuenta para el desarrollo de la aplicación de adelantamiento seguro en la
que se recogen los siguientes escenarios críticos:
• Adelantamiento de seguridad en las vías urbanas y semi-urbanas con motocicletas
adelantando a otro vehículo
• Moto adelantando a otro vehículo cuando este gira a la izquierda
• Moto adelantando a otro vehículo mientras que otro vehículo está girando a la
izquierda
Figura 13 - Adelantamiento peligroso
En la figura se muestra un ejemplo en el que el vehículo (1) empieza a adelantar a el
vehículo (3) mientras que un vehículo a motor de dos ruedas (2) ya está empezando una
maniobra de adelantamiento. En esta situación la moto informa al vehículo (1) acerca de su
maniobra. Este caso es altamente crítico para los usuarios de motocicletas, debido a los puntos
ciegos y la diferencia de velocidad entre la moto y el coche, por lo que mediante esta
aplicación en la que se envía avisos, que pueden ir acompañados de información útil como las
diferentes velocidades de los vehículos, se puede evitar esta clase de accidentes.
2.5 GCDC
El evento GCDC (Grand Cooperative Driving Challenge) tiene como objetivo acelerar el
desarrollo e implementación de las tecnologías de la conducción cooperativa para contribuir
significativamente a aliviar los problemas de tráfico a nivel mundial. Concretamente, su
finalidad está enfocada a la participación y competición entre equipos internacionales para
conseguir el sistema más eficiente de cooperación vehículo-infraestructura en escenarios
predeterminados de tráfico, lo que se traduce en todo un reto internacional en el campo de la
conducción cooperativa. Toda esta iniciativa que fue anunciada en 2008 no comenzaría,
debido a varias modificaciones en el plan inicial hasta 2009 viéndose los resultados finales en
2011. En resumen, el programa fue el siguiente:
27
• 2009: Taller (mayo) durante el evento “Cooperative Systems on the Road" para
intercambiar ideas sobre las normas, protocolos y tecnología.
• 2010: Demostración de la tecnología cooperativa durante el evento Cooperative
Mobility Showcase que contó con la participación de CVIS, SAFESPOT y Coopers.
• 2011: El desafío de los sistemas cooperativos de carretera en el que participaron
equipos de todo el mundo.
El evento que se organizó en mayo de 2011 fue una oportunidad para que los equipos
participantes mostraran sus desarrollos y evaluaran su situación con respecto a los otros
equipos en competencia. Todos los equipos se beneficiarían de la exposición internacional a
los medios y de la oportunidad de poner a prueba su tecnología comparándose con los demás
competidores.
Figura 14 - Escenario de ejemplo de GCDC
La conducción cooperativa, incentivada desde este evento, permitiría un uso más eficiente
de la infraestructura existente que reduce los gastos y el uso del suelo para nuevas carreteras.
Para conseguir esta aumento de la eficiencia se basa en la comunicación inteligente entre
vehículos y entre vehículos y su entorno, que permite que los vehículos circulen a una
distancia más corta entre ellos al mismo tiempo que se garantiza un flujo homogéneo del
tráfico, lo que se traduce en una reducción del consumo y un aumento del rendimiento. La
necesidad de incorporar la comunicación inteligente se debe a que los tiempos de reacción del
ser humano son demasiado grandes como para conducir tan cerca de otro coche y hoy en día
los sistemas avanzados de control de crucero presentan problemas. Los sistemas actuales ACC
(Adaptive Cruise Control) sólo reaccionan con el vehículo que está justo enfrente, no son
capaces de predecir el comportamiento del flujo de tráfico completo. Sin embargo, los
sistemas cooperativos son capaces de proporcionar información sobre qué sucede alrededor
del vehículo, así como predecir qué va a suceder en un futuro cercano. Esto permitirá a los
28
vehículos equipados con dicho sistema amortiguar y posiblemente prevenir ondas de choque
de una serie de vehículos. Por tanto, si se impulsa los sistemas cooperativos y basándose en los
estudios sobre el tráfico realizados, se ha demostrado que en 2022 la conducción cooperativa
será capaz de reducir el tiempo perdido en los atascos de tráfico en un 50%, las muertes por
accidente de tráfico en un 8% y las emisiones de CO2 y el consumo de combustible en un 5%.
A continuación se analizarán los aspectos más relevantes que se examinaron en el GCDC
de 2011, poniendo al descubierto tanto las virtudes como los desafíos a los que se enfrenta la
comunicación cooperativa.
2.5.1 Estrategias de implementación
El GCDC de 2011 se centra en un tipo específico de conducción cooperativa, “platooning”,
que es un sistema en el que los coches se conducen solos, con una distancia corta entre
vehículos. La razón principal para centrarse en este atributo es la promesa de un aumento
significativo del rendimiento de las carreteras y la correspondiente reducción en el consumo
de combustible. A partir de los estudios de simulación se espera que el rendimiento pueda
aumentar al menos un 10% aunque dependiendo de las condiciones las prestaciones pueden
ser significativamente mayores. Esta dependencia de la eficacia se debe en gran medida al
grado de penetración de dichos sistemas entre el número total de automóviles. Por
consiguiente, se requiere una estrategia de implementación robusta y la creación de
beneficios para el usuario, incluso ante un bajo grado de penetración inicial, dando lugar a un
modelo de negocio convincente para los fabricantes de componentes del sector de la
automoción.
2.5.2 Control robusto a prueba de fallos en tiempo real
El concepto de “platooning” automático con vehículos de carretera se conoce desde hace
décadas. Una de las primeras publicaciones sobre el tema, desde una perspectiva en tiempo
real, data de 1966. Desde entonces, una gran cantidad de investigaciones han sido publicadas.
Sin embargo, el enfoque común se basa en un conjunto de vehículos bien definidos, en el
sentido de que todos tienen igual (o al menos conocida) dinámica, y hay un líder de grupo
presente. En oposición a este sistema estructurado, el GCDC se ocupa de la aplicación de
“platooning” en el tráfico cotidiano, que consta de vehículos de varios tipos e instrumentación.
Además no existe un líder natural presente. Éste puede ser manejado por cualquier
mecanismo de negociación que permita determinar el líder y los miembros del grupo de
vehículos, aumentando con ello la carga de comunicación. Otro aspecto que debe tener en
29
cuenta la aplicación en el tráfico cotidiano es el de disponer de un alto nivel de fiabilidad y
seguridad. El sistema depende en gran medida de la comunicación inalámbrica que implica
contar con una planificación de red cuidadosa y manejo de mensajes para alcanzar la fiabilidad
requerida. Un alto nivel de redundancia puede que no sea la solución a priori, ya que se
incrementarían los costes del sistema. Consecuentemente, lograr un nivel suficiente de
fiabilidad así como un mecanismo para asegurar la seguridad, manteniendo los costes a un
mínimo, es el desafío real que aún no se ha resuelto. Por último, el comportamiento y la
aceptación del usuario son aspectos importantes que deben abordarse antes de que la
aplicación pueda ser empleada.
2.5.3 Estructura de la distribución de información en tiempo real
Las tecnologías de la conducción cooperativa dependen en gran medida del intercambio
de información entre los participantes del tráfico y las carreteras. Para cooperar con éxito, los
nodos de comunicación han de comprender la información intercambiada, lo que hace crucial
la normalización de los formatos de mensajes, la comunicación y los protocolos de interacción.
En el modelo de comportamiento planeado, los usuarios y las unidades de carretera reciben
datos desde sus propios sensores para construir su propia visión local del mundo, es decir, su
modelo del mundo. Este modelo incluye una representación de la situación del tráfico local y el
estado de los vehículos vecinos y unidades en carretera, proporciona la información necesaria
para el control de la red. La conclusión es que a nivel de tráfico, los usuarios y las unidades de
carretera tienen que mantener un cierto nivel de coherencia en la visión que tienen del mundo
para custodiar un comportamiento seguro y cooperativo. Por consiguiente, se plantea un
complejo flujo de información a gran escala para intercambiar datos en movimiento y eventos
en una base de tiempo real, lo que requiere una arquitectura bien definida de la información
logrando un alto nivel de confianza y escalabilidad.
2.5.4 La comunicación inalámbrica en entornos de tiempo real
La manera de abordar el tema de la comunicación es evidentemente determinante, ya que
se sabe que las comunicaciones inalámbricas y móviles están, por naturaleza, sujetas a fallos.
Algunos ejemplos de fenómenos que impiden una comunicación eficiente son las diferentes
intensidades de señal debido a la variación de las condiciones de propagación, el
desvanecimiento multitrayecto, la interferencia entre símbolos, el efecto Doppler, las señales
de interferencias como el ruido, etc. Un problema que se hace dominante en el escenario
previsto del GCDC es el hecho de que las estaciones de transmisión pueden causar
30
interferencia mutua en un receptor. Este problema es significante en el proyecto ya que los
vehículos intercambian datos en movimiento a altas tasas de actualización, del orden de
decenas de hercios, y esperan retardos muy bajos, del orden de decenas de milisegundos.
A pesar de la gran cantidad de estrategias de mitigación que existe en los sistemas
modernos de comunicación inalámbrica, ninguno está libre de fallos. Por consiguiente, el
sistema de control debe ser robusto frente a deficiencias tales como latencia, pérdida de
tramas y de paquetes, desvanecimientos y ancho de banda. Es necesario un equilibrio
cuidadoso entre el uso y la dependencia de la información obtenida a través de las
comunicaciones inalámbricas, y el uso de sensores a bordo con el fin de garantizar la seguridad
en todo momento. Encontrar este equilibrio va a ser un objetivo importante del GCDC en
vistas del gran despliegue.
31
Capítulo III
Tecnología ITS
El capítulo siguiente describe en profundidad las tecnologías que son la base de la
comunicación vehicular y que se han usado en los proyectos descritos anteriorme nte. En
concreto, se va a hablar de los protocolos de comunicación WAVE e ISO-CALM. Para finalizar,
se exponen los motivos que dificultaban la implantación del protocolo ISO-CALM completo
durante el evento del Grand Cooperative Driving Challange y se especifica el protocolo basado
en CALM tomado como solución.
32
3.1 Introducción a las redes VANET
Un primer paso esencial para lograr una tecnología que ofrezca una comunicación
cooperativa es fijar el tipo de red que se va a emplear. Una de las características
fundamentales de la red buscada es que va a ser dinámica y va a cambiar continuamente
dependiendo del número de vehículos que existan en los alrededores. Una red ad-hoc, es
precisamente una red específica cuya infraestructura solo tiene sentido en ese instante o
situación, es decir su topología es variante en el tiempo, por lo que su elección para el sistema
perseguido parece acertada. Sin embargo, la red también debe ser inalámbrica y móvil, por lo
que la elección final pasará por las redes MANET (Mobile Ad-Hoc NETwork) y se detendrán en
las VANET (Vehicular Ad-hoc Network), que no son más que redes ad-hoc móviles enfocadas a
la comunicación vehículo a vehículo y vehículo a infraestructura. Cumpliendo con los objetivos
perseguidos por los sistemas de transporte inteligente las redes VANET ofrecen diferentes
aplicaciones, destacando aquellas que mejoran la seguridad (un vehículo detecta un accidente
y retransmite las coordenadas a los vehículos posteriores para que corrijan su conducción) y
conducción eficiente (vehículos en una congestión envían la información de su estado a otros
vehículos para que modifiquen su ruta). A estas aplicaciones hay que añadirle las de ocio (los
ocupantes de diferentes vehículos se pueden comunicar y transferir ficheros), medidas
medioambientales (los vehículos en una retención pueden modificar las características de
combustión del motor para emitir menos gases perjudiciales para el medio ambiente) y otras
aplicaciones como aviso de vehículos de emergencias o servicios multimedia. Como ya se viene
diciendo a lo largo de este documento, las comunicaciones cooperativas se plantean como el
próximo gran reto dentro del sector de la automoción y de los ITS ya que por sus
características, son las comunicaciones encargadas de los servicios que demanden baja
latencia y requisitos de tiempo real, en especial, aquellos relacionados con la seguridad vial.
Además, permitirán ampliar la cobertura y capacidad de redes inalámbricas tradicionales
mediante el uso de los diferentes nodos como encaminadores de información. Por tanto, para
conseguir esta comunicación cooperativa de manera fiable y escalable es necesario el
desarrollo de nuevos protocolos de la comunicación vehicular que actúen a través de las redes
VANET. Los primero intentos se producen en Estados Unidos de la mano del protocolo WAVE
que será tenido en cuenta para el desarrollo del protocolo ISO-CALM, como se va a ver en las
siguientes secciones.
33
Figura 15 - Arquitectura de comunicación de una VANET
3.2 WAVE
WAVE (Wireless Access Vehicular Environment) es un conjunto de estándares que tienen
como objetivo definir un sistema de comunicación inalámbrica capaz de proveer servicios a
vehículos y a todo tipo de entidades de transporte. Estos servicios incluyen aquellos
reconocidos por la arquitectura ITS así como también muchos otros contemplados por la
industria del automóvil y del trasporte. El protocolo WAVE fue desarrollado por el DOT
(Department of Transportation) de los Estados Unidos para soportar comunicaciones tanto
vehículo-infraestructura como vehículo-vehículo y satisfacer los exigentes requerimientos de la
comunicación vehicular como son los bajos tiempos de conexión, los constantes cambios en la
topología, la baja latencia en las comunicaciones, la seguridad, entre otros. La estandarización
de WAVE comienza con su asignación a la banda DSRC (Dedicated Short Range
Communication), cuando en 1999 la Comisión Federal de Comunicación de Estados Unidos
reservó 75 MHz en la banda entre 5.855 y 5.925 GHz para el uso de comunicaciones V2V y V2I.
El espectro DSRC está dividido en siete canales de 10 MHz y una banda de seguridad de 5 MHz.
El canal central es el canal de control (CCH) y está reservado solo a aplicaciones de seguridad
crítica, el primero y último de los canales están reservados para usos especiales, y el resto son
canales de servicio (SSH). Sin embargo, en Europa la asignación del espectro se ha encontrado
con mayores dificultades debido a las múltiples partes involucradas. En 2008, el Comité
Electrónico de Comunicaciones reservó 5 canales de 10 MHz, situados en la banda de
frecuencia entre 5.875 y 5.925 GHz.
34
Figura 16 - Banda de frecuencia de DSRC
En línea con las comunicaciones DSRC, el protocolo WAVE provee de un canal de control
común para señalización, donde se hace uso de mensajes cortos especializados (WSM - WAVE
Short Message) para servicios de alta prioridad y mensaj es de control del sistema, y varios
canales de servicio capaces de soportar tanto mensajes WSM como tráfico IPv6, utilizados para
aplicaciones de propósito general y de baja prioridad. En la transmisión de los mensajes y para
ofrecer los diferentes servici os van a estar involucrados diversos estándares de la arquitectura
WAVE, siendo los principales el IEEE 1609.2, IEEE 1609.3, IEEE 1609.4, IEEE 1609.6, IEEE
1609.11, e IEEE 802.11p, estandarizados y en periodo de pruebas. Cada uno representa un
parte de la arquitectura como se muestra a continuación.
Figura 17 - Capas y protocolos asociados de WAVE
En las subsecciones que siguen se ven con más detenimiento algunos de estos estándares,
en especial los pertenecientes a las capas inferiores y principales responsables de la
comunicación.
35
3.2.1 Capas PHY y MAC
El estándar IEEE 802.11p pertenece al grupo de protocolos WiFi, y cumple las funciones de
la capa física y buena parte de las funciones de la capa MAC. Está especialmente diseñado para
comunicaciones inter-vehiculares y presenta las siguientes particularidades:
• Define un modo de operación específico para comunicaciones vehiculares
• El transmisor emplea OFDM en la banda ISM libre de 5.9 GHz
• Define canales de 10 y 20 MHz de ancho de banda
• Define especificaciones de frecuencia más ajustadas para el transmisor
• Agrega requerimientos de rechazo de canales adyacentes para al receptor
• Permite comunicaciones con y sin un WBSS (WAVE Basic Service Set)
• Define un rango extendido de temperaturas en las cuales debe ser capaz de operar
Los parámetros clave de este protocolo pueden observarse en la siguiente tabla en la que
se compara con los protocolos WiFi comunes.
802.11p WAVE Wi-Fi
Tasa de transmisión 3-27 Mb/s 6-54 Mb/s
Alcance < 1000 m < 100 m
Potencia trasmitida 760 mW (US)
2 W EIRP (EU)
100 mW
Ancho de banda del canal 10 MHz
20 MHz
1-40 MHz
Mobilidad Alta Baja
Banda de frecuencia 5.86-5.92 GHz 2.4 GHz, 5.2 GHz
Estandares IEEE, ISO, ETSI IEEE
Figura 18 - Tabla comparativa entre 802.11p y 802.11
Por otra parte, el estándar IEEE 1609.4 es una extensión al estándar IEEE 802.11p con el
objetivo de lograr una operación del sistema en múltiples canales. De este modo, se posibilitan
36
mecanismos efectivos para controlar operaciones de las capas superiores (IEEE 1609.3) a
través de múltiples canales sin la necesidad de conocer datos de la capa física. En particular, se
definen dos tipos de canales, uno de control (CCH – Control Channel) y uno de servicios (SCH –
Service Channel). El primero se utiliza para transmitir mensajes de tipo WSM, mensajes
característicos del estándar de alta prioridad, principalmente orientados a aplicaciones de
seguridad. También en este canal es posible anunciar servicios WAVE. El segundo tipo de canal
es donde se hacen efectivos esos servicios una vez solicitados en el CCH, soportando e l manejo
tanto de mensajes WSM como de mensajes IP. La existencia de varios canales de servicios
distintos en el espectro permite atender varios servicios simultáneame nte una vez que han
sido apropiadamente coordinados en el canal de control. Las funcionalidades provistas por el
estándar son las siguientes:
• Channel routing: controla el encaminamiento de paquetes provenientes de la capa LLC
a su canal designado, ya sea de control o de servicios, sin necesidad de realizar
operaciones de coordinación de canal por parte de la capa MAC.
• User priority: el estándar soporta una variedad de aplicaciones seguras y no seguras
con hasta 8 niveles de prioridad predefinidos. Estos son utilizados por algoritmos de
contención a la hora de ganar el acceso al medio, siendo los de mayor prioridad los
mensajes relacionados con la seguridad. Existe un buffer para cada uno de estos 8
niveles donde los paquetes son apilados, en los que se tienen en cuenta tres
parámetros característicos:
o AIFS (Arbitration Inter-Frame Space) – Tiempo mínimo entre que el canal esta
libre y se puede comenzar a transmitir.
o CW (Contention Window) – Ventana para implementar un backoff aleatorio.
o TXOP (Transmit Oportunity) limit – Tiempo máximo durante el cual se puede
transmitir después de haber obtenido un TXOP. Si el límite es 0 solo se podrá
trasmitir un MSDU.
Mediante el uso de estos parámetros, los paquete s provenientes de cada buffer
participan primero en un mecanismo de contención interno para luego realizar otro
externo y así ganar el acceso al medio.
• Channel coordination: coordina los intervalos activos de cada canal acorde a las
operaciones de sincronización de la capa MAC para que los paquetes se transmitan en
el canal adecuado. Es necesario para soportar intercambio de datos entre dispositivos
37
que no son capaces de monitorear el canal de control a la vez que intercambian datos
en canales de servicios. La sincronización y la coordinación del canal, cuando un
dispositivo se une a una subred WAVE o WBSS (WAVE Basic Service Set), es
imprescindible para asegurar que todos los dispositivos están monitoreando el CCH
adecuadamente, canal por el que se transmiten los mensajes de mayor prioridad
relacionados a seguridad vehicular.
3.2.2 Capa de red
Por encima de la capa MAC se encuentra la capa de red, cuyos servicios están definidos en
el estándar IEEE 1609.3. Se distinguen dos áreas definidas como el plano de datos y el plano de
administración. El plano de datos contiene los protocolos y el hardware usados en la
transmisión de datos, y se encarga generalmente del tráfico generado o destinado a
aplicaciones, aunque soporta también tráfico entre planos de administración de diferentes
maquinas o tráfico entre el plano de administración y el de datos. En cambio, el plano de
administración lleva a cabo tareas de configuración y mantenimiento del sistema. Sus
funciones emplean servicios del plano de datos para intercambiar tráfico de administración
entre dispositivos. Se definen entidades específicas de administración para ciertas capas como
son PLME (Physical Layer Management Entity) y MLME (Mac Layer Management Entity),
además de WME que es una colección más general de los servicios de administración. En
resumen, el estándar se hace cargo de los siguientes servicios:
• Servicios de datos:
o LLC (Logical Link Control)
o IPv6
o UDP y TCP
o WSMP (WAVE Short Message Protocol)
• Servicios de administración:
o Mecanismos de registro para las aplicaciones
o Administración de WBSS (WAVE Basic Service Set)
o Monitoreo del uso del canal
o Configuración IPv6
o Monitorización del RCPI (Received Channel Power Indicator)
o Mantenimiento del MIB (Management Information Base)
Los dos protocolos posibles de comunicación a nivel de red son WSMP o IPv6. WSMP está
diseñado específicamente para operaciones del entorno vehicular, siendo muy eficientes en la
38
utilización del canal. Los mensajes WSM pueden ser transmitidos en cualquier canal y permite
a las aplicaciones controlar directamente parámetros de capa física como pueden ser el canal
utilizado y la potencia de transmisión, a diferencia de IPv6 que controla estos parámetros a
través de los diferentes perfiles que define el protocolo.
Las aplicaciones pueden elegir el intercambio de datos en el contexto de una subred en la
que intervienen varios dispositivos WAVE o no. Si se establece una subred WAVE o WBSS, es
posible utilizar tanto WSM como IPv6 sobre algún canal de servicio, aunque el anuncio y
coordinación de una WBSS se realiza en el canal de control. Si se decide no establecer un
WBSS, la comunicación está limitada a mensajes WSM en el canal de control. El dispositivo que
anuncia un WBSS y por ende los respectivos servicios asociados se denomina “proveedor”
mientras que cualquier dispositivo que se una a ese WBSS para uti lizar sus servicios se
denomina “usuario”, pudiendo haber varios usuarios utilizando distintas combinaciones de
servicios dentro del mismo WBSS. Al operar sin un WBSS, la aplicación prepara mensajes WSM
con una primitiva tipo request y los manda a la dirección MAC de difusión en el CCH. Al recibir
el mensaje de difusión los dispositivos receptores registran la aplicación a través de un número
único que la identifica, el PSID. Después de haber registrado la aplicación, dado que en este
punto ya se conoce la existencia y dirección del proveedor se puede continuar con el
intercambio en el CCH usando unicast o broadcast según corresponda. Si se opera dentro de
un WBSS, esta es anunciada por el proveedor junto con los servicios ofrecidos al igual que
antes, pero con un tipo de mensaje especializado llamado WSIE (WAVE Service Information
Element), conteniendo información detallada de los servicios ofrecidos, parámetros de capa
física, de encaminamiento, prioridad, entre otros.
3.2.3 Seguridad en las comunicaciones
Ya sea debido al carácter crítico que pueden tener los mensajes relacionados a la
seguridad vehicular, o simplemente para mantener la confidencialidad de la información
difundida, es necesario contar con mecanismos que aseguren el intercambio seguro y
confiable de mensajes entre las diferentes entidades. El estándar IEEE 1609.2 define los
servicios usados para proteger los mensajes de ataques tales como acceso a la información por
personas no autorizadas, alteración de los mensajes, o repetición de los mismos, entre otros.
Se definen funciones de seguridad tanto para la capa de red como para la capa de aplicación.
Aparte de los servicios típicos de seguridad como son la confidencialidad, autenticidad e
integridad, el sistema WAVE impone que se provean mecanismo para mantener el anonimato
del usuario final, ya que información propia puede llegar a ser difundida, y también porque se
39
puede llegar a tener en memoria información de otros usuarios. Para cumplir con estos
requisitos, el estándar utiliza los ampliamente conocidos mecanismos de criptografía como
pueden ser: algoritmos simétricos, algoritmos asimétricos, funciones hash, y certificados y
autorizaciones digitales. La utilización de cada uno de ellos depende de los requerimientos y
restricciones de cada situación en particular, ya que, por ejemplo, existe un compromiso entre
velocidad de codificación-decodificación y nivel de seguridad, que determina que un algoritmo
sea mejor que otro según la situación.
3.3 CALM
La arquitectura CALM (Communication Access for Land Mobiles) desarrollada en el marco
del proyecto europeo CVIS, como ya se ha mencionado previamente, proporciona la
comunicación I2I, V2I y V2V. CALM está basado en IPv6 y proporciona un conjunto de
protocolos y parámetros estandarizados para las comunicaciones inalámbricas de medio y
largo alcance de alta velocidad. Además, constituye una capa de alto nivel que define reglas
que rigen sobre protocolos y tecnologías inalámbricas ad-hoc ya existentes y desarrolladas. Los
métodos de transmisión usados pueden estar basados en una o varias tecnologías de
transmisión como:
• WLAN/Wi-Fi
• WiMax
• Sistemas celulares
• Comunicación Infrarroja
• DSRC-WAVE
• Satélite
Esta arquitectura es capaz de determinar en todo momento qué tecnología inalámbrica
está disponible en una cierta localización y decidir cuál utilizar para una comunicación óptima.
Por otra parte siempre garantiza varios canales de comunicación de forma simultánea, de esta
forma los vehículos y la infraestructura pueden mantener una comunicación de forma
continua, incluso si por cualquier motivo algún canal individual no se encuentra disponible.
Este hecho es muy importante para aplicaciones relacionadas con la seguridad. Además la
arquitectura pretende hacer frente a grandes retos como el acceso inalámbrico simultáneo por
parte de un alto número de vehículos, ubicación y redistribución de frecuencias, identificación
40
de pasarelas e infraestructuras disponibles o mecanismos de priorización en la transmisión de
datos.
A continuación, se va a analizar con más detenimiento algunas de las tecnologías más
destacables recogidas por CALM.
3.3.1 IEEE 802.16-WiMax
Se trata de una tecnología bastante parecida a la WiFi, solo que WiMax puede cubrir zonas
de hasta 50 Km. Su velocidad de transmisión de datos oscila entre 1 y 75 Mbps y opera entre
las bandas de 2.5 a 5.8 GHz con y sin licencia de operación. Se espera que pueda dar servicio a
redes vehiculares a velocidades entre 20 km/h y 200km/h con el objetivo de satisfacer
comunicaciones I2V, V2I, I2I y hasta V2V.
3.3.2 CALM 2G/3G
CALM 2G (ISO 21212) incluye las redes móviles GSM de segunda generación (2G) o de
segunda generación extendida (2.5G). Emplean la tecnología de servicio general de paquetes
vía radio o GPRS (Global Packet Radio Service) para la comunicación V2I y viceversa. Cabe
destacar su rango de alcance alrededor de los 10 km, su velocidad para la transmisión de
datos, entre 80 y 384 kbps, y su banda de operación, entre 0.8 a 1.9 GHz.
CALM 3G (ISO 21213) es similar a la anterior con la diferencia de que se trata de redes
UMTS, es decir, de tercera generación (3G) o de tercera generación extendida (3.5G). Ambas
redes emplean la tecnología para el acceso de paquetes de alta velocidad HSPA (High Speed
Packet Access) para los mismos escenarios de la tecnología 2G. Cabe destacar el aumento de
ancho de banda que pasa a ser de hasta 7.2 Mbps con alcances que oscilan entre los 10-35 km
operando en el rango de 0.8, 1.9, 2.1 GHz.
Es importante hacer mención dentro de las redes móviles a la tecnología LTE (Long Term
Evolution) que en la actualidad se ha consolidado como la cuarta generación (4G), y por tanto
se estudia su integración al estándar CALM.
3.3.3 CALM-IR
CALM-IR (ISO 21214) es utilizado principalmente para las comunicaciones entre los mismos
vehículos o entre el vehículo y la infraestructura. Esta tecnología es utilizada con frecuencia en
los sistemas de peaje automático en los países asiáticos tales como Japón. Entre sus
41
características destacamos su ancho de banda entre 1Mbps hasta 128 Mbps, su tiempo de
enlace entre 1 a 10 ms y su funcionamiento para distancias de 10 m, 100 m o 1 km.
3.3.4 DSRC
El DSRC, en el que también se basa el protocolo WAVE como se ha comentado
previamente , es una tecnología que pretende ser un complemento a las redes de móviles al
proveer velocidades de transferencia muy al tas en circunstancias en las que es importante
minimizar la latencia del enlace de comunicaciones en zonas relativamente pequeñas. Una de
las condiciones más importantes para lograr estos propósitos es minimizar la latencia. Tiene
que ser posible, por ejemplo, transmitir en menos de 100 milisegundos los mensajes con
información importante, como un accidente. Las pruebas iniciales realizadas mostraron que el
protocolo 802.11 es capaz de ofrecer latencias inferiores a las de las redes celulares y otros
tipos de redes, por lo que se pretende adaptar el 802.11p a los otros requerimientos
especiales de DSRC. Entre sus características más importantes se encentran:
• Ancho de banda de 75 MHz
• Frecuencia de 5,8 GHz
• Alcance de 100 a 1000 metros (en función de las condiciones del tiempo)
• Tiempo de latencia de 200 µs
• Tasa de transmisión de 18 Mbps
• Comunicaciones broadcast y punto a punto
Esta tecnología está pensada para proporcionar servicios de comunicación a media-corta
distancia dentro de carreteras entre vehículos y vehículos e infraestructuras con fines de
seguridad, pudiéndose destacar dos usos principales:
• Seguridad vial: sistema de alertas de emergencia para vehículos, prevención de
colisiones en intersecciones, alertas de aproximación de vehículos de emergencias,
inspecciones de seguridad de vehículos, señalización de prioridad de vehículos, etc.
• Transacciones comerciales e información de viaje: pago automático de servicios como
autovías y parkings, información en ruta sobre tráfico, etc.
3.3.5 CALM M5
CALM M5 (ISO 21215) se encuentra en proceso de desarrollo y está orientado a satisfacer
las comunicaciones entre vehículos, es decir, contribuirá a la formación de redes vehiculares o
VANETs. CALM M5 es muy cercano a las tecnologías de la iniciativa WAVE, es decir, IEEE
42
802.11p y la familia de estándares IEEE 1609.X, descritas en apartados anteriores. Esta
tecnología ofrece velocidades promedio de 6 a 27 Mbps, rango de alcance de un 1km y
latencias bajas de 200µs y opera en los 5.9GHz. Este estándar es el punto de partida en el que
se basa el protocolo CALM FAST propuesto por el GCDC y cuya implantación en un sistema de
prueba es el principal objetivo de este proyecto.
3.4 Protocolo propuesto por GCDC
En el contexto en el que el protocolo CALM se estaba desarrollando y consolidando como
la base de las comunicaciones cooperativas, el evento GCDC se encontró varias dificultades
hasta alcanzar una solución que cumpliese un enfoque abierto y multi-proveedor para las
comunicaciones (capas OSI de 1 a 5) y los protocolos de interacción (capa OSI 6). Después de
todo, los sistemas cooperativos sólo pueden funcionar en la práctica si los coches de diferentes
fabricantes "hablan el mismo idioma", por lo menos hasta cierto punto. La consecuencia
directa es que la organización del GCDC tenía que establecer las reglas para las
comunicaciones (modulación, frecuencia, codificación de canal, etc.) y la interacción
(contenido del mensaje). Naturalmente, la organización tenía que renunciar a cualquier
derecho de propiedad intelectual en las especificaciones. Eso dejó sólo un problema
pendiente: los protocolos para elegir.
3.4.1 Inconvenientes de la solución de CVIS
Para implementar los niveles inferiores, capas 1 y 2 de la pila de protocolos, parecía fácil a
primera vista dar con una solución, ya que IEEE 802.11p se estaba convirtiendo rápidamente
en el estándar de facto para sus comunicaciones, y las frecuencias de la banda de los 5,9 GHz
se empezaban a disponer, al menos en los Estados Unidos y Europa. Por otra parte, dentro del
Sexto Programa Marco el proyecto CVIS había realizado una implementación de código abierto
de IEEE 802.11p basado en una distribución Linux Debian, y su proyecto hermano SAFESPOT,
había trabajado en definir conjuntos de mensajes para las capas más altas. Ambos proyectos
habían estado funcionando durante unos años y sus resultados parecían utilizables para el
GCDC, pero hubo complicaciones graves. La aplicación CVIS se basó en gran medida en
hardware dedicado que era caro y no estaba ampliamente disponible. De hecho, había serios
indicios de que el hardware ya no se produciría en el momento de especificar las pilas de
protocolos. Por otra parte, CVIS se basó en componentes de código cerrado, que no pueden
ser distribuidos como código abierto ni modificados para adaptarse a las necesidades
particulares. Además, CVIS hizo mucho más que un simple IEEE 802.11p, implementó una pila
43
de protocolos CALM M5 totalmente funcional, lo que implica la adición de muchos módulos
CALM-específicos en el núcleo. Parecía muy difícil "extraer" los cambios del kernel CVIS y
portarlo a otras distribuciones de Linux, y mucho menos a otro hardware mejor y más barato.
En general, este enfoque iba a suponer el tener que lidiar con los siguientes inconvenientes:
• Son necesarias herramientas especiales de soporte para configurar la red inalámbrica.
• El tamaño del código de los nuevos módulos de los controladores del kernel es
demasiado grande, teniendo en cuenta las tasas de error de programación normales
esto conduce a que aparezcan problemas de estabilidad en el núcleo.
• Los controladores del kernel tienden a tener problemas de portabilidad entre distintas
versiones, lo que puede ser problemático a la hora de portar el software al hardware
de bajo coste.
• Los controladores del kernel son difíciles de probar, en comparación con los programas
normales.
• Se requiere un sistema Host para tener los módulos del Kernel, reduciendo la
flexibilidad.
• Se requiere una interfaz nativa de java (JNI) para conectar una máquina virtual de java
(JVM) a la pila de protocolos.
Con respecto a las definiciones de mensajes, las cosas no eran mejores: solo se pudo
distribuir las definiciones de mensajes SAFESPOT a los miembros del consorcio. Una objeción
más grave fue que el conjunto de mensajes era demasiado complicado para el uso en GCDC.
Dado que un conjunto de mensajes específicos parecía factible, se decidió crear el Protocolo
de Interacción GCDC. En los niveles inferiores, se desarrolló una sencilla y genérica
implementación de código para IEEE 802.11p en Linux, basándose en los resultados de CVIS. La
aplicación aún se basa en partes de ISO CALM, sin embargo, se centra especialmente en CALM
FAST.
3.4.2 Alternativa propuesta por el GCDC
De lo hablado anteriormente se puede resumir que a pesar de que gran parte de la
tecnología propuesta por el proyecto CVIS se puede utilizar, hay una serie de partes que no se
pueden usar tal como están. Esto lleva a definir una serie de requisitos globales que debe
cumplir el nuevo router con CALM FAST:
• Bajo coste del hardware exterior a la plataforma.
• Combinación de un router con una antena.
44
• La implementación en código abierto.
• Múltiples routers deben poder conectarse a un mismo host.
El enfoque alternativo sugerido por el GCDC combina la simplicidad con la máxima
portabilidad. Una característica importante de este enfoque es que no se ha implementado
dentro de la pila de red del kernel. En su lugar, un controlador de red inalámbrica estándar se
modifica de tal manera que puede soportar la configuración 802.11p requerida (frecuencias de
canal, ancho de banda, bal izas, direccionamiento). A continuación, el controlador inalámbrico
se configura mediante las herramientas estándar. El protocolo CALM FAST se implementa en
un demonio, que se comunica con el controlador inalámbrico a través de una interfaz socket
directo. La API se implementa a través de un protocolo TCP/IP que es manejado por el
demonio. Este enfoque ofrece las siguientes ventajas:
• Bajo esfuerzo en portabilidad: sólo se debe parchear el controlador de red inalámbrica.
• No existen requisitos especiales para los sistemas host (sólo se necesita una pila
TCP/IP).
• La fiabilidad del kernel casi no se ve afectada.
• El demonio puede ser probado con herramientas de análisis de aplicaciones sin
necesidad de herramientas especiales de configuración.
• Cualquier combinación de routers y hosts es posible.
La simplicidad de esta solución también tiene sus inconvenientes:
• No hay soporte para múltiples medios de comunicación o selección de medios, sólo el
CALM-M5 es compatible.
• Ninguna gestión CALM.
3.4.3 Capas del modelo propuesto
La nueva alternativa también queda plasmada en la definición de los mensajes, desde la
capa física hasta la capa de sesión, de la pila de comunicaciones:
• Capas PHY y MAC. Estas capas cumplen con el estándar IEEE 802.11p y las
especificaciones más recientes. Sólo se necesita broadcast (nivel MAC) y no hay ACK,
RTS y CTS. Como resultado, no hay administración NAV (no hay transmisiones
virtuales). Cada vehículo opera en el canal de control (CCH), con ancho de banda de 10
MHz, pero debe estar preparado también para los canales de servicio (SCH) por lo que
45
se mantiene abierta la opción de utilizar un canal diferente en el caso de la carga de
tráfico es demasiado alto.
• Capa LLC. Se limita a cumplir con el estándar IEEE 802.2 para el control del acceso
lógico.
• Capa de red. La capa de red obligatoria consiste en la especificación sobre el medio
inalámbrico de CALM FAST e IPv6 con direcciones de red y de transporte fijas. IPv6
sobre IEEE 802.11p se contempla pero no se usa, solo es necesario para peticiones de
eco ICMP (pruebas de conectividad) y el acceso SSH remoto. Opcionalmente, el IPv4
está soportado en la capa de red, también para direcciones fijas y para utilizar
solicitudes de eco ICMP y acceso remoto SSH.
• Capa de transporte . Se basa en CALM FAST con direcciones de transporte o puertos
fijos. Además, Todos los OBUs deben soportar ICMP (echo request / respuesta), UDP y
TCP sobre IPv6. El uso de TCP y/o UDP sobre IPv4 es opcional.
• Capa de sesión. Todos los nodos (vehículos e infraestructuras de carretera) deben
soportar la difusión periódica y/o intercambio de mensajes CALM FAST SCA y de SCF.
Figura 19 - Capas y protocolos propuestos por GCDC
46
Capítulo IV
Hardware y software utilizado
A lo largo del presente proyecto ha sido necesario el uso de diferentes recursos hardware
y software. El capítulo comienza describiendo el hardware necesario para implementar la
plataforma de comunicación inalámbrica sugerida por el GCDC. Seguidamente se describe el
software empleado, en especial los sistemas operativos usados tanto en el desarrollo como
para la implementación del sistema de comunicación.
47
4.1 Hardware
El primer punto a tratar va a ser detallar las características, de manera que quede
justificada su elección, de los elementos hardware seleccionados para implementar el sistema
de comunicación, a los que habrá que añadir aquellos otros elementos necesarios para el
desarrollo del mismo. Como ya se comentó en el primer capítulo, este proyecto se centra en la
entidad Mobile Router definida en la OBU. Esta entidad permite al vehículo comunicarse con el
exterior: entidades de carretera, dispositivos móviles, estaciones fijas, etc. Es por ello
conveniente que ofrezca algunas de las tecnologías de comunicación sin cables ya implantadas
como WiFi (802.11g) o Bluetooth. Además debe permitir también las nuevas formas de
comunicación inalámbrica en el ámbito ITS, ya estandarizadas pero aún en fase de
implantación, como son WAVE (802.11p/1609) o su versión europea CALM-M5.
4.1.1 AlixBoard 3D2
El dispositivo elegido para la implementación de la entidad de comunicación inalámbrica
es una placa router capaz de albergar en su interior un sistema operativo Linux. Se habla por
tanto de un Sistema Linux Embebido. La placa en cuestión es la AlixBoard 3D2 un dispositivo
que cuenta con varios puertos de expansión que la dotan de una gran capacidad para la
implementación de distintas tecnologías de comunicación.
Figura 20 - ALIX 3D2
Las características más relevantes extraídas del catálogo del fabricante son:
48
CPU 500 MHz AMD Geode LX800
DRAM 256 MB DDR DRAM
Almacenamiento Slot CompactFlash
Alimentación DC jack o POE pasivo, min. 7V to max. 20V
LEDs Tres
Expansion 2 miniPCI slots, LPC bus
Conectividad 1 Ethernet (Via VT6105M 10/100)
I/O DB9 puerto serie, dos USB
Dimensiones 100 x 160 mm
Firmware tinyBIOS
Figura 21 - Tabla de características de la ALIX 3D2
Sobre este dispositivo hay que resaltar las siguientes características que determinaron su
adquisici ón para el prototipo:
• Procesador AMD Geode LX800: Este procesador destaca por su eficacia y
funcionalidad. Además, se poseen varias placas adicionales con el formato PC104
basadas en éste y por tanto esto permite, si fuese necesario, portar las aplicaciones
realizadas al tratarse de la misma arquitectura.
• Dos puertos mini-PCI: En la actualidad la mayoría de tarjetas de comunicación
industrial poseen este formato. Permitiendo, en el caso de las tarjetas inalámbricas, la
posibilidad de utilizar una antena externa que garantice la potencia de transmisión y
pueda situarse en el exterior del vehículo.
• Dos puertos USB: Permite el conexionado a la placa router de dongles Bluetooth o WiFi
genéricos y ofrece la posibilidad de utilizar dispositivos de almacenamiento masivo
USB que doten a la placa de espacio suficiente para las futuras aplicaciones.
• Conexión Ethernet: Mediante esta interfaz se realizará la comunicación con el Vehicle
Host estableciéndose así un canal de comunicación fiable, seguro y de alta velocidad
de transmisión de datos.
49
4.1.2 MikroTik R52H
Las tarjetas elegidas para la comunicación inalámbrica son las MikroTik R52H que poseen
el chipset de comunicaciones AR5414 uno de los requisitos para el desarrollo del protocolo de
comunicaciones WAVE. Estas tarjetas son de uso industrial y permiten implementar sin
modificación alguna los protocolos de comunicaciones 802.11a/b/g permitiendo un uso en un
rango ampliado de frecuencias.
Figura 22 - Mikrotik R52H
Las principales características del dispositivo son:
Chipset AR5414
Frequency range 2.192-2.539MHz / 4920-6100MHz
Standards IEEE802.11a/IEEE802.11b/IEEE802.11g
Max output power 25dBm
Format miniPCI
Dimensions 6.0cm x 4.5 cm
Connectors 2x uFl
Temperature Operating -20C to +70C
Powering 3.3V +/- 10% DC; 800mA max.
Figura 23 - Tabla de características de las tarjetas MikroTik
50
4.1.3 Elementos del entorno de desarrollo
Para la creación de un entorno de desarrollo que permita implementar la entidad Mobile
Router es necesario el uso de varias herramientas y elementos hardware , muchos de ellos
ampliamente utilizados para el desarrollo con dispositivos embebidos:
• Ordenador. Se utiliza tanto para generar el firmware de las placas como para la
posterior configuración de las mismas.
• Cable para puerto serie. Es la manera común de acceder a un dispositivo embebido en
el arranque inicial y ver la configuración de red.
• Cable Ethernet. Una vez se ha accedido mediante el puerto serie y se han configurado
los parámetros de red, va a ser más cómodo utilizar Ethernet para realizar las tareas de
desarrollo, como pueden ser editar los ficheros de configuración.
• Dos placas Alix 3D2. Para implementar dos Mobile Router y lograr que se comuniquen
entre ellos.
• Dos tarjetas MikroTik R52H. Proporcionan la comunicación inalámbrica en cada uno de
los Mobile Router.
• Fuente de tensión. Proporciona la alimentación necesaria para el funcionamiento de
las placas router.
• Tarjetas de memoria Compact Flash. En ellas se almacenarán cada uno de los sistemas
operativos generadas específicamente para sendas placas router.
En la figura que se muestra a continuación es posible observar como quedarían
conectados los diferentes elementos del sistema durante la fase de configuración de una de las
dos placas.
.
51
Figura 24 - Esquema de conexionado para el desarrollo
4.2 Software
En esta sección se describe el software utilizado tanto para el desarrollo como para la
implementación del sistema de comunicación. Dentro de este software empleado conviene
aclarar cuál es usado en el desarrollo de la entidad de comunicación, Windows 7 y Ubuntu, y
cuál es usado para implementar la entidad, OpenWrt.
Figura 25 - Software para el desarrollo y software para la implementación
4.2.1 Windows 7
Windows 7 pertenece a la popular línea de sistemas operativos producida por Microsoft.
Esta versión está diseñada para su uso en PC, incluyendo equipos de escritorio en hogares y
oficinas, equipos portátiles, tablet PC y netbooks. El desarrollo de Windows 7 se completó en
52
julio de 2009, siendo entonces confirmada su fecha de venta oficial para octubre de 2009. A
pesar de que esta versión sigue gozando de popularidad, actualmente ya está disponible una
nueva versión: Windows 8.
Una de las principales ventajas de Windows 7 es su gran compatibilidad con la mayoría de
los programas del mercado, pero la razón fundamental para la utilización de este sistema
operativo ha sido la posibilidad de disponer de un ordenador en la Sal a de Proyectos en el que
ya estaba previamente instalado. Sin embargo, su uso se va a limitar a la configuración de la
dirección IP y a la utilización del programa PuTTy. Este programa se corresponde con un
emulador de terminal , frecuentemente utilizado a la hora de trabajar con dispositivos
embebidos, que permite conectarse con máquinas remotas y ejecutar programas a distancia.
Para el resto del desarrollo se ha optado por la virtualización usando VMware para poder
trabajar con una máquina virtual de Ubuntu 10.04.
4.2.1.1 VMware
La virtualización es una de las tendencias de la actualidad tecnológica, por lo que en este
proyecto se ha hecho uso de VMware Player, un producto de virtualización gratuita de
escritorios. La compañía VMware es líder en virtualización a nivel empresa y sus productos van
mucho más allá de la virtualización de escritorios, ofreciendo también soluciones para la
virtualización de redes, servidores, aplicaciones y almacenamiento. La idea básica detrás de la
virtualización es el uso de software para simular la existencia de hardware. Cada uno de los
ordenadores simulados es una máquina virtual (VM). A todos los efectos, cada máquina virtual
parece ser un sistema informático completo, autónomo, con su propio procesador, memoria,
unidades de disco, unidades de CD-ROM/DVD, teclado, ratón, monitor, interfaces de red,
puertos USB, y así sucesivamente. Al igual que un ordenador de verdad, cada máquina virtual
requiere un sistema operativo. Por ejemplo para disponer de una máquina virtual con la
distribución de Linux Ubuntu 10.04 como la utilizada durante la realización del proyecto es tan
sencillo como descargarse la distribución deseada de la página oficial de Ubuntu, crear la
máquina virtual usando VMware Player a la vez que se configuran los parámetros del entorno,
como la memoria RAM disponible o la capacidad de almacenamiento.
Se puede sospechar que la virtualización es ineficiente debido a que un ordenador de
verdad es de por sí más rápido que un ordenador simulado. Si bien es cierto que las
computadoras reales son más rápidas que los ordenadores simulados, la tecnología de
virtualización ha avanzado tanto que la penalización de rendimiento por funcionar en una
53
máquina virtual en lugar de una máquina real es sólo un pequeño porcentaje. Por el contrario,
la virtualización nos ofrece grandes ventajas como la reducción en el gasto de hardware y
energía. También cabe señalar la portabilidad y la recuperabilidad, esto significa que la
máquina virtual puede ser transferida o copiada a otro equipo siempre que sea conveniente,
como se hizo durante este proyecto en el que se empezó a trabajar en un ordenador personal
para posteriormente copiar la máquina virtual en el ordenador de trabajo del laboratorio de
proyectos. También es interesante esta característica en el caso de que haya un fallo del
hardware del equipo. Ante esta situación la máquina virtual se transferiría a otro equipo y
rápidamente volvería a estar operativa. Debido a todas estas ventajas es fácil entender el
motivo del gran éxito cosechado por la virtualización en el mercado tecnológico actual.
4.2.2 Linux
Linux es un sistema operativo basado en Unix que goza de gran popularidad en ambientes
académicos y empresariales. El kernel o núcleo de Linux es la parte principal del sistema
operativo, es el software encargado de garantizar el acceso seguro al hardware y de gestionar
los recursos. La característica más destacable de este sistema operativo y uno de los
principales motivos de su éxito es que se trata de software libre lo que ha fomentado la
creación de una larga red de colaboradores y desarrolladores en todo el mundo. El sistema
operativo dispone de múltiples distribuciones entre las encuentran dos usadas en este
proyecto: Ubuntu, utilizada para el desarrollo, y OpenWrt, utilizada para implementar el
sistema de comunicación inalámbrica.
4.2.2.1 Ubuntu
La distribución Linux Ubuntu ha sido utilizada en este proyecto tanto para la generación
del firmware de las placas como para su posterior configuración. Esta distribución, basada en
Debian y que se distribuye como software libre y gratuito, está orientado al usuario medio con
un fuerte enfoque en la facilidad de uso e instalación del sistema, apostando por un sistema
operativo actualizado y estable que mejore la experiencia del usuario. La distribución está
patrocinada por la compañía británica Canonical. Cada seis meses se publica una nueva versión
de Ubuntu la cual recibe soporte por parte de Canonical, durante dieciocho meses, por medio
de actualizaciones. Las versiones LTS (Long Term Support), que se publican cada dos años,
reciben soporte durante tres años en los sistemas de escritorio y cinco para la edición
orientada a servidores. La tercera versión LTS desarrollada es la 10.04 (Lucid Lynx), usada
durante este proyecto. Aunque ha gozado de gran estabilidad y popularidad, desde mayo de
54
2013 la edición de escritorio ha dejado de recibir soporte. La actual versión LTS es la 12.04
(Precise Pangolin), por lo que sería interesante tenerlo en cuenta para futuros desarrollos.
4.2.2.2 OpenWrt
Para la implementación del protocolo CALM en el Mobile Router el GCDC nos propone el
uso de OpenWrt, una distribución GNU/Linux altamente extensible para dispositivos
embebidos que goza de las siguientes características:
• Gratuito y de código abierto. El proyecto es completamente gratis y de código abierto,
con licencia GPL.
• Fácil y libre acceso. La documentación está siempre alojada en un sitio de fácil acceso,
con el código fuente completo disponible. El proyecto siempre está abierto a nuevos
contribuidores y a todas las personas capaces de aportar y participar.
• Impulsado por la Comunidad. La idea es unirse para trabajar y colaborar para lograr un
objetivo común.
OpenWrt se ha establecido como una de las mejores soluciones de firmware para
dispositivos de comunicación inalámbrica. Es muy superior a otras soluciones en el
rendimiento, la estabilidad, la expansibilidad, la robustez y el diseño. La meta de los
desarrolladores de OpenWRT es continuar expandiendo el desarrollo y asegurar que OpenWrt
sea el principal framework de soluciones innovadoras e ingeniosas. El software no pretende
ser una distribución prefabricada que pueda cargarse directamente en un dispositivo
embebido. En su lugar, el framework permite crear un firmware adaptado a necesidades
particulares. Por lo tanto, aunque hay varios proyectos disponibles para cubrir los casos de uso
común, OpenWrt no es un firmware para el usuario final. Las tareas más avanzadas requieren
operaciones de línea de comandos y conocimientos básicos sobre el funcionamiento de un
sistema basado en Linux. La arquitectura abierta permite realizar inspecciones del estado de
paquetes de datos, detección de intrusos, y un sinnúmero de otras cosas que normalmente
requiere invertir gran cantidad de dinero en hardware para hacerlo con eficiencia. En este
momento existen más de 2000 paquetes de software en el repositorio oficial, y muchos más
proporcionados por la comunidad. El número de paquetes evidencia la efectividad de la
construcción del sistema OpenWrt, proporcionando la oportunidad de portar fácilmente
paquetes y crear un firmware propio.
55
4.2.2.2.1 OpenWrt Buildroot
La herramienta que permite crear este firmware adaptado para cada necesidad no es más
que el OpenWrt Buildroot, pero antes de adentrase a hablar sobre el mismo es conveniente
definir varios conceptos:
• Compilador cruzado: es un compilador capaz de crear código ejecutable para otra
plataforma distinta a aquélla en la que se ejecuta.
• Toolchain: significa literalmente cadena de herramientas y es un conjunto de
programas informáticos o herramientas que permiten compilar código para un
sistema. Los distintos programas se suelen usar en una cadena, de modo que la salida
de cada herramienta sea la entrada de la siguiente .
• Buildroot: es un conjunto de archivos Makefiles y parches que permiten generar
fácilmente tanto el toolchain de compilación-cruzada como el sistema de archivos raíz
para sistemas embebidos.
Por tanto, OpenWrt Buildroot es un buildroot modificado para adaptarse mejor a las
características de OpenWrt. El entorno de compilación cruzada está formado por un conjunto
de librerías, de archivos utilitarios y de archivos binarios, que permiten realizar la compilación
cruzada. Las herramientas para la compilación cruzada pueden consistir en:
• Compilador de C. Un compilador como gcc que debe ser capaz de generar código
objeto, tanto del Kernel como de las aplicaciones.
• Librerías de C. Librerías como puede ser libc, uClibc o dietlibc que implementan las
llamadas al sistema mediante APIs (Application Programming Interface – Interfaz de
Programación de Interfaces).
• Binutils: Conjunto de herramientas necesarias para la compilación, enlazado,
ensamblado y depuración de código.
Bajo la mayoría de los sistemas Linux, el toolchain de compilación usa GNU libc como
librería estándar de C. EL toolchain de compilación que viene con el sistema se ejecuta y
genera código para el procesador del sistema anfitrión. En el caso de un PC, el toolchain de
compilación se ejecuta en un procesador x86. Como el sistema embebido tiene un procesador
diferente, se necesita un toolchain de compilación-cruzada. Este es un toolchain de
compilación que se ejecuta en el sistema anfitrión pero que genera código para el sistema
objetivo, en este caso un sistema embebido. Por ejemplo, si el sistema usa x86 y el sistema
56
objetivo utiliza MIPS32, el toolchain de compilación normal se ejecuta en el sistema x86 y
genera código para x86, mientras que el toolchain de compilación-cruzada se ejecuta en x86 y
genera código para MIPS32.
Existen herramientas de compilación como gcc, binutils, uClibc pero tratar con todas las
opciones de configuración, con todos los problemas de gcc o binutils requiere demasiado
tiempo y es poco interesante. El Buildroot de Openwrt automatiza este proceso a través del
uso de archivos Makefiles, y tiene un conjunto de parches para cada versión de gcc y binutils
para hacerlos funcionar en el set de instrucciones de arquitectura respectivo para la mayoría
de los sistemas embebidos. Por último, es conveniente señalar que a pesar de que el Buildroot
de OpenWrt fue pensado principalmente para desarrolladores, es lo suficientemente simple
para que un usuario sin experiencia pueda construir su propio firmware modificado.
57
Capítulo V
Desarrollo del sistema
A lo largo del siguiente capítulo se describe el trabajo de desarrollo técnico llevado a cabo.
Se explica el proceso de generación, usando buildroot, de un firmware con OpenWrt adaptado
a las necesidades del usuario y su posterior configuración. Después de crear el firmware se
describe el proceso de arranque del sistema y como se prepara el mismo instalando los
diferentes paquetes necesarios para la comunicación inalámbrica. Seguidamente se muestran
las opciones de configuración que ofrece OpenWrt diferenciando entre la comunicación en
modo infraestructura y en modo ad-hoc. Por último, se centra en la configuración propuesta
para conseguir implementar el protocolo CALM FAST.
58
5.1 Generación del firmware
El primer paso en el proceso de obtención del software que implemente el Mobile Router
va a ser lograr instalar la herramienta Buildroot de Openwrt y aprender a manejarla. Cuando se
hayan adquirido los conocimientos necesarios de Buildroot ya va a ser posible dar el siguiente
paso y generar el firmware en base a la documentación proveniente del GCDC.
5.1.1 Instalación de Openwrt Buildroot
Como ya se ha comentado anteriormente la herramienta Buildroot permite generar un
firmware propio y a medida. A continuación se describen los pasos para instal ar e utilizar esta
herramienta, pero antes de comenzar es importante señalar que Buildroot no debe usarse
como usuario root. Tras esta apreciación lo primero es descargar un software para el control
de versiones, como puede ser git o subversión, que permita obtener cómodamente el código
fuente:
sudo apt-get update
sudo apt-get install subversion git-core
Para descargar el código fuente existen dos opciones:
• Descargar el trunk (tronco en inglés) que se corresponde con la versión experimental
en desarrollo.
• Descargar un branch (rama en inglés) que es la opción recomendada ya que se
corresponde con una versión estable del proyecto. Actualmente la última versión
estable es la “attitude adjustment”.
En el caso de querer obtener la versión de desarrollo se crea una carpeta para albergar el
proyecto y se descarga seguidamente del repositorio usando una de las herramientas de
control de versiones como puede ser subversion.
mkdir ~/openwrt
cd ~/openwrt
svn co svn://svn.openwrt.org/openwrt/trunk/
Una vez se haya descargado el proyecto, de manera opcional, se pueden actualizar e
instalar todas las fuentes.
59
cd trunk
./scripts/feeds update -a
./scripts/feeds install -a
En el caso en el que se desee descargar la última versión estable del proyecto con sus
paquetes, que es lo recomendado, y usar git en vez de subversión se seguiría el siguiente
ejemplo.
git clone git://git.openwrt.org/12.09/openwrt.git
git clone git://git.openwrt.org/12.09/packages.git
El siguiente paso es comprobar mediante alguno de los siguientes comandos los paquetes
que falten en el sistema anfitrión para construir el firmware deseado. Los siguientes comandos
mostrarán una lista de paquetes de sistema necesarios para construir OpenWrt correctamente
usando Buildroot:
make defconfig
make prereq
make menuconfig
En el caso de usar Ubuntu 10.04 como se propone para la realización de este trabajo, los
prerrequisitos que faltan son build-essential, ncurses y zlib por lo que hay que instalar los
siguientes paquetes:
sudo apt-get install build-essential libncurses5-dev
zlib1g-dev
5.1.2 Uso de OpenWrt Buildroot
Una vez instalado Buildroot es posible lanzar la interfaz de configuración mediante:
make menuconfig
En el menú de configuración se observa que cada entrada tiene asociada una descripción
para facilitar el uso.
60
Figura 26 - Menú de configuración de OpenWrt Buildroot
Dependiendo de la plataforma, de los paquetes requeridos y de las necesidades de los
módulos del kernel se modifican las diferentes opciones del menú. Es imprescindible adecuar
la configuración de nuestro sistema objetivo al hardware que se pretende utilizar. Para una
ALIX 3d2 se requiere:
• Target System: x86
• Subtarget: PCEngines alix2
Las opciones de Buildroot también permiten elegir entre distintos sistemas de ficheros
para la imagen generada como:
• squashfs. Ocupa poco espacio pero tarda en arrancar el sistema.
• ext4. Ocupa más espacio pero tarda menos en arrancar el sistema.
A la hora de seleccionar los diferentes paquetes existen tres opciones de selección:
• Presionando “y” se obtiene la etiqueta <*>. El paquete seleccionado se incluirá en la
imagen a crear.
61
• Presionando “m” se obtiene la etiqueta <M>. El paquete se compila pero no se incluirá
en la imagen a crear.
• Presionando “n” se obtiene la etiqueta < >. El paquete no se compila.
Cuando se guarda la configuración se crea el archivo .config que se usará por los
makefiles para generar el firmware deseado. Los diferentes makefiles se encuentran
distribuidos de la siguiente manera en cada ruta indicada:
• /openwrt/package. Contiene los Makefiles y archivos asociados para el espacio de
usuario y sus herramientas. Éstos pueden compilarse y añadirse al sistema de archivos
raíz objetivo. Hay uno por cada subdirectorio correspondiente a cada herramienta.
• /openwrt/toolchain. Se localizan los Makefiles y ficheros asociados al software
relacionado con las herramientas de compilación cruzada: binutils, ccache, gcc, gdb,
cabeceras del Kernel y µClibc.
• /openwrt/target. En su interior alberga los Makefiles y archivos asociados al
software relacionado con el sistema de ficheros de la imagen objetivo y el Kernel para
los diferentes sistemas.
Cada directorio contiene al menos dos ficheros:
• Makefile: es el encargado de descargar, configurar y compilar el sistema de
ficheros.
• config.in: es parte de la herramienta del archivo de configuración.
Para generar la imagen se llama al makefile principal mediante el siguiente comando:
make
Con este comando se descargan, configuraran y compilaran las herramientas
seleccionadas, y se genera la imagen deseada con los paquetes seleccionados. El proceso de
construcción requiere de bastante tiempo, dependiendo de los recursos del sistema.
Finalmente, las imágenes resultantes se encuentran en el subdirectorio:
/openwrt/bin
62
5.1.3 Generación del firmware CALM FAST
En las secciones anteriores se ha detallado como generar el firmware de manera genérica
ahora el objetivo es centrarnos en el firmware propuesto por GCDC. El software y la
documentación necesarios para generar el firmware se pueden obtener en la página oficial de
GCDC http://www.gcdc.net. Este software ha sido testado con éxito en una placa ALIX 2D2 con
tarjetas Mikrotik RB433AH y RB493AH, por lo que nuestro principal objetivo es comprobar que
también es aplicable para el hardware seleccionado para este proyecto, ALIX 3D2 y Mikrotik
R52H. El software se distribuye como un archivo tar comprimido con gzip, que puede ser
descomprimido mediante:
tar -xzvf GCDCCommStackV3.tgz
El archivo distribuido tiene la siguiente estructura:
• doc. La documentación de referencia.
• openwrt-gcdc. El sistema de OpenWRT personalizado para GCDC.
• Samples. Ejemplo de código en Java y C par el uso de las comunicaciones GCDC.
A la hora de situar el directorio openwrt-gcdc se recomienda que tenga la ruta
/home/gcdc/openwrt-gcdc, aunque puede ser diferente mientras se tenga en cuenta.
Seguidamente, dentro del directorio openwrt-gcdc/build se descomprime la
distribución backfire de OpenWrt presente en el directorio openwrt-gcdc/dl.
tar -xvf ../dl/backfire_10.03_source.tar.bz2
Dentro del directorio backfire_10.03 se edita el archivo feeds.conf.default,
agregando la siguiente línea:
src-link gcdc home/gcdc/openwrt-gcdc/gcdc-backfire-10.03-
V3/feed/packages
Si ha instalado el software en otro lugar es necesario cambiar la ruta para que esté acorde.
Opcionalmente, se pueden comentar las fuentes xwrt y luci, ya que no son necesarias y su
desactivación acelera el proceso de construcción. El siguiente paso es activar las fuentes de
paquetes GCDC y hacer los preparativos necesarios para que estos paquetes sean
incorporados en el sistema de construcción Openwrt.
63
./scripts/feeds update
make package/symlinks
A continuación, ya es posible llamar al menú de configuración del OpenWrt Buildroot.
Como ya se comentó en la sección anterior, los parámetros se van a seleccionar dependiendo
básicamente de la plataforma objetivo, de los paquetes requeridos y de las nece sidades del
kernel.
make menuconfig
Aunque es posible realizar los mismo cambios realizados anteriormente a través de la
interfaz de configuración, GCDC proporciona un archivo de configuración estándar para una
ALIX 2D2, que ha resultado compatible con la ALIX 3D2 utilizada en este proyecto. Para usar los
cambios de la ALIX 2D2 se reemplaza el fichero de configuración por el fichero proporcionado
mediante:
cp -p ../../gcdc-backfire-10.03-
V3/configs/Dot_Config_ALIX2D2 ./.config
Tras realizar las modificaciones, se ejecuta el comando make para que se descarguen,
configuren y compilen las herramientas seleccionadas, a la vez que se genera una imagen con
los paquetes seleccionados.
make
En el caso de usar un directorio diferente a /home/gcdc se usa la siguiente sentencia:
make <ruta_directorio>/openwrt-gcdc/gcdc-
backfire-10.03-V3/feed/files
Una vez que la construcción haya finalizado con éxito, es necesario instalar una serie de
parches, en concreto para iw y compat–wireless. Para ello basta con copiar los parches al
fichero package y volver a ejecutar el comando make. Estos parches van a posibilitar, por
ejemplo, el uso de frecuencias en la banda de los 5,9 GHz, ya que según el dominio regulador
de cada país los controladores de la tarjeta inalámbrica pueden restringir el uso de este rango
de frecuencias.
64
cp -dpr ../../gcdc-backfire-10.03-
V3/feed/patches/package ./
Dentro del fichero, se comprueba que los parches se han copiado correctamente en la
siguiente ruta:
• package/mac80211/patches/930-its-ath-2010-01-22.patch
• package/mac80211/patches/930-its-wireless.patch
• package/iw/patches/200-iw-beacon-argument.patch
Para mayor seguridad, se realiza la limpieza de los paquetes para los que se han instalado
los nuevos parches.
make package/mac80211/clean
make package/iw/clean
Por último, se genera la imagen del sistema especificado, esta vez con los parches
correctos instalados. Debido a que la mayoría de las herramientas ya se descargaron y
compilaron la primera vez, esta segunda compilación y las sucesivas ya van a ser más rápidas.
make
5.1.4 Traspaso a la tarjeta Compact Flash
Llegados a este punto y antes de pasar la imagen generada a la tarjeta Compact Flash, es
un buen momento para hacer una copia de seguridad de las imágenes creadas. Antes de usar
la tarjeta es conveniente formatearla a FAT32 usando algún programa como gparted. Cuando
se tenga conectada la tarjeta al equipo se invoca al comando dmesg para averiguar el
identificador de dispositivo, como puede ser por ejemplo dev/sdb. Si la imagen está
comprimida es necesario descomprimirla usando:
gunzip openwrt-x86-ext2.img.gz
Después de descomprimir, se copia la imagen en la tarjeta Compact Flash, teniendo en
cuenta que la operación puede tardar varios minutos. En este caso, se ha elegido una imagen
ext2 ya que tarda menos en arrancar el sistema pero también se puede elegir una imagen
squashfs.
65
dd if=bin/x86/openwrt-x86-ext2.img of=/dev/sdb
Finalmente, ya solo falta introducir la tarjeta en la ranura correspondiente de la placa y
arrancar el sistema como se va a describir seguidamente .
5.2 Inicialización
Una vez se ha logrado obtener el firmware se va a proceder a cargarlo en el sistema. Para
ello se introduce la tarjeta de memoria a la que se ha traspasado la imagen generada en la
ranura de la placa router correspondiente y se alimenta usando la fuente de tensión. Para
observar el proceso de arranque y posteriormente acceder al sistema se hace uso de un cable
para el puerto serie. Este conjunto de elementos usados en la fase de inicialización queda
descrito en la siguiente figura.
Figura 27 - Conexión de elementos en la inicialización
5.2.1 Arranque del sistema
En esta fase se va a trabajar desde Windows 7 donde se tiene instalado el programa PuTTy.
A la hora de arrancar el Sistema Operativo creado con OpenWrt se va a utilizar este emulador
de terminal para acceder a la ALIX 3D2 desde el ordenador mediante el puerto serie. Para ello
se configura la conexión con los parámetros especificados en el datasheet del fabricante como
se observa en la siguiente figura. La velocidad va a ser de 38400 baudios mientras que,
siguiendo la configuración habitual del puerto serie 8N1, se van a tener 8 bits de datos, 1 de
parada y ninguno de paridad.
66
Figura 28 - Configuración de conexión por puerto serie usando PuTTy
Una vez configurada la comunicación serie y se haya mandado la orden de abrir la
conexión, se alimenta la placa con una tensión entre 7V y 20V como recomienda el fabricante.
En base a esta recomendación en este proyecto se han usado 18V. En este momento se inicia
el gestor de arranque (bootloader) y tras la carga del sistema ya se puede navegar por el
sistema de directorios a través del terminal. Sin embargo, de aquí en adelante para una mayor
comodidad a la hora de trabajar se va a utilizar Ethernet debido a que ofrece una tasa de
transferencia mucho más elevada lo que va a facilitar el traspaso de ficheros y paquetes. Pero
antes de poder acceder al sistema mediante Ethernet va a ser necesario conocer cuál es la
dirección IP del router. Esto no es problema ya que utilizando el comando ifconfig desde
el terminal abierto mediante PuTTy se puede obtener fácilmente que 192.168.1.1 es la
dirección del dispositivo.
67
Figura 29 - Configuración inicial de red mostrada por ifconfig
Esta dirección puede ser modificada usando también el comando ifconfig o editando
el fichero /etc/config/network como se explica en los Anexos I y II, respectivamente.
Una vez se conoce la dirección del dispositivo es necesario que tanto el equipo como la placa
router estén dentro de la misma red local. En Windows 7 la asignación de una IP estática que
esté dentro del mismo rango que la del dispositivo se hace desde el Centro de redes y recursos
compartidos pichando en Conexión de área local . En las propiedades se selecciona el Protocolo
de Internet versión 4 (TCP/IPv4). En las propiedades del protocolo aparece por defecto
configurado para hacer uso del protocolo DHCP, utilizado para asignar direcciones
dinámicamente. Por tanto, es necesario modificar estas propiedades para otorgarle una
dirección dentro del rango de la subred, como se ve en la siguiente figura:
68
Figura 30 - Configuración de direccionamiento estático en Windows
Tras estos cambios en el equipo y conectando el cable Ethernet ya es posible conectarse
con la placa desde la máquina virtual de Ubuntu, donde se va a realizar el resto del desarrollo.
Para acceder la primera vez desde Ubuntu en el caso de haber dejado la dirección IP inicial del
router, hay que escribir desde el terminal el siguiente comando:
telnet 192.168.1.1
El protocolo Telnet para el control remoto tiene problemas de seguridad por lo que una
vez se ha accedido se puede usar el comando passwd para cambiar la contraseña y así
poder realizar conexiones más seguras usando el protocolo SSH. Por, tanto para acceder de
manera segura al dispositivo desde la máquina virtual se utiliza el siguiente comando:
ssh root@192.168.1.1
5.2.2 Paquetes Wireless
Durante la generación del firmware con el OpenWrt Buildroot, una de las opciones era
seleccionar los paquetes que se desean incluir. Si se sigue la configuración propuesta por el
69
GCDC los paquetes relativos a la comunicación inalámbrica son incluidos pero si se utiliza una
configuración base propuesta por OpenWrt estos paquetes no vienen incluidos. Por tanto en
caso de necesitar incluir estos paquetes, en la siguiente figura se muestran organizados
jerárquicamente por dependencia, de manera que los paquetes que aparecen situados a la
izquierda dependen de los que tienen situados a la derecha:
kmod-ath5k kmod-ath
kmod-
mac80211
kmod-crypto-core
kmod-crypto-arc 4 kmod-crypto-
core kmod-crypto-aes
kmod-cfg80211
wireless-tools
iw libnl-tiny
crda
Figura 31 - Dependencias de los paquetes para la comunicación inalámbrica
Además para realizar una comunicación entre un dispositivo configurado como punto de
acceso y otra como cliente es necesario uno de los siguientes paquetes, ninguno de ellos
incluidos en el firmware del GCDC al estar pensado para realizar una comunicación inalámbrica
usando redes ad-hoc :
wpad
wpad-mini (recomendado)
Los paquetes para la versión backfire 10.03.1 de OpenWrt, instalado en la placa router, se
pueden descargar del siguiente enlace:
http://downloads.openwrt.org/backfire/10.03.1/x86_generic/packages/
70
Cuando estén descargados en el equipo de desarrollo hay que transferirlos al dispositivo.
Para ello se usa el comando scp para transferencia segura de ficheros, cuyo modo de uso es
el siguiente:
scp usuario_host@ip_origen:ruta_orig
usuario_placa@ip_destino:ruta_dest
Por ejemplo, para transferir el paquete wpad-mini_20111103-2_x86.ipk se
escribiría por línea de comandos lo siguiente:
scp jossamarm@192.168.1.1:/home/jossamarm/descargas/wpad-
mini_20111103-2_x86.ipk
root@192.168.2.1:/root/paquetes/wpad-mini_20111103
2_x86.ipk
Para gestionar paquetes en OpenWrt se usa la herramienta opkg, basada en el dpkg de
Debian. Con esta herramienta, la instalación de los paquetes que se han transferido a la placa
se realiza de la manera que sigue:
opkg install /root/paquetes/*.ipk
Por último, para comprobar que se han instalado correctamente o simplemente para
conocer todos los paquetes que tenemos en nuestro sistema puede ser de utilidad el siguiente
comando:
opkg list-installed
5.3 Configuración de las comunicaciones
Después de haber iniciado cada una de las dos placas router, haber accedido a ellas
mediante Ethernet y haber instalado los paquetes necesarios en el caso de que los hubiera, es
la hora de configurar el sistema de comunicación que permita a las dos entidades Mobile
Router comunicarse inalámbricamente. Para ello conviene tener claro y recordar los elementos
que integran el sistema total :
71
• Plataforma de desarrollo. Se corresponde con el PC. En el momento de editar los
ficheros de configuración se conecta alternativamente a cada una de las placas router
mediante el cable Ethernet. Una vez se ha configurado cada router se puede dejar uno
conectado mediante Ethernet y el otro al puerto serie. Esto permite de manera sencilla
tener conectadas ambas entidades Mobile Router al equipo y poder testear la
comunicación simultáneamente en cada una.
• Plataforma de comunicaciones inalámbricas. Se corresponde con las dos placas router
ALIX 3D2 que actúan como entidades Mobile Router. Ambas se configuran desde el
equipo de desarrollo en diferentes modos y con parámetros distintos.
Como puede apreciarse en la siguiente figura el sistema total queda definido por tres
subredes:
• 192.168.1.0/24. Subred para la comunicación entre el equipo y el “Router 1”.
• 192.168.2.0/24. Subred para la comunicación inalámbrica entre los dos routers.
• 192.168.3.0/24. Subred para la comunicación entre el equipo y el “Router 2”.
Figura 32 - Esquema general de direccionamiento
5.3.1 Modo infraestructura
El primer modo de comunicación que se va a estudiar es aquel en el que existe un nodo
principal conocido como punto de acceso (AP) al que se conectan los equipos clientes y a
través del cual se transmite la información. Esta topología es conocida como de infraestructura
72
y se utiliza comúnmente para extender una red para incluir dispositivos inalámbricos. El AP
forma un puente entre la infraestructura de la red y los dispositivos inalámbricos, por lo que
las estaciones configuradas en modo AP se convierten en parte de la infraestructura de red, de
ahí el nombre . Esta topología presenta una eficiencia superior a la red ad-hoc, de la que se
hablará más adelante. En este modo de funcionamiento, la tarjeta de red se configura
automáticamente para utilizar el mismo canal radio que utiliza el punto de acceso más
próximo de la red.
Teniendo en cuenta que el objetivo final de este proyecto es el de hacer posible la
comunicación entre un red de vehículos, este diseño no parece el más apropiado pero se ha
propuesto su estudio para obtener una visión más global de cómo se configura una red y
poder analizar todas la opciones que ofrece OpenWrt.
Figura 33 - Topología del modo infraestructura
5.3.1.1 Configuración usando punto de acceso
Para este tipo de topología, en la que se pretende que uno de los dispositivos inalambricos
funcione como punto de acceso y el otro como cliente, el primer paso es editar el fichero
network de los dos dispositivos que se encuentra en la ruta /etc/config, para que estén
73
acordes con el esquema de subredes descrito con anterioridad. En el Anexo II se pueden
encontrar ejemplos de cómo sería la configuración básica de cada uno de los ficheros de
configuración y la descripción de los parámetros más relevantes. En el fichero network inicial
que trae por defecto el firmware están definidas la interfaz loopback y lan, por lo que habría
que añadir también una sección para la interfaz wifi y asignarle las direcciones IP propuestas
en la arquitectura general, aunque también son posibles otros esquemas de comunicación
siempre y cuando estén dentro del mismo rango de red.
config interface wifi
option proto static
option ipaddr 192.168.3.1
option netmask 255.255.255.0
Para editar los ficheros existen varias opciones como:
• El editor vi. Viene instalado en el sistema pero la curva de aprendizaje para utilizarlo
puede ser ligeramente elevada.
• El editor nano. Hay que instalarlo pero es más sencillo e intuitivo.
• Usar el comando scp, tal como se hizo para traspasar paquetes anteriormente, para
traspasar los ficheros y editarlos cómodamente desde Ubuntu.
Una vez se hayan modificado y guardado los ficheros hay que reiniciar la red por lo que
hay que ejecutar la siguiente línea:
/etc/init.d/network restart
Para configurar la comunicación inalámbrica lo más cómodo es usar el siguiente comando:
wifi detect > /etc/config/wireless
De esta forma se detecta la configuración compatible con los drivers inalámbri cos y se crea
el fichero de configuración wireless de manera acorde, en la ruta /etc/config. En el
fichero se define por defecto una interfaz wifi genérica en modo punto de acceso y sin
encriptación. También por defecto, se especifica en el fichero generado que el wifi esté
desactivado. Para habilitarlo simplemente hay que eliminar o cambiar el “1” por un “0” en la
siguiente línea:
74
#REMOVE THIS LINE TO ENABLE WIFI
option disabled 1
Como se explica en el Anexo II las opciones del dispotivo type, channel, macaddr y
hwmode son autodetectadas. Para el dispositivo inalámbrico utilizado se tiene que el tipo es
mac80211 ya que es lo que se corresponde para los drivers ath5k, el canal es el 11 que se
corresponde con una frecuencia de 2.462 Ghz, la dirección MAC del dispositivo que actúa
como AP es 00:0c:42:69:ec:b7 y el protocolo WiFi utilizado es el 802.11g . Para
conseguir una conexión en modo infraestructura, en una de las placas hay que cambiar en la
configuración de la interfaz la opción “ap” del modo por “sta” para que en vez de funcionar
como punto de acceso funcione como cliente. Además en la opción network se debe
especificar el nombre de la interfaz de red definida en el fichero network al que se quiere
asociar la interfaz inalámbrica. También es importante recordar que el ssid del cliente debe
ser el mismo que el del punto de acceso con el que se quiere conectar. Inicialmente el ssid es
“Openwrt” pero es conveniente darle un nombre personalizado a la red.
config wifi-device radio0
option type mac80211
option channel 11
option macaddr 00:0c:42:69:ec:b7
option hwmode 11g
config wifi-iface
option device radio0
option network wifi
option mode ap
option ssid OpenWrt
option encryption none
75
Cuando se haya terminado de editar los ficheros de configuración inalámbrica y se hayan
guardado es necesario decirle al sistema que vuelva a leer las nuevas configuraciones y levante
las interfaces de radio mediante el comando wifi. Llegados a este punto ya es posible
establecer una comunicación inalámbrica entre las placas y se comprueba haciendo ping
desde el “Router 1” al “Router 2” y viceversa. Otra manera de comprobar que existe conexión
entre las placas router es escribir desde la placa que funciona como cliente el siguiente
comando:
iwlist wlan0 scan
Tras ejecutar esta línea se muestran todos los puntos de accesos que son visibles desde el
cliente, por lo que debe aparecer uno cuyo ssid es “OpenWrt” o el nombre que se le haya
dado a la red. Una vez se ha logrado una comunicación inalámbrica entre los routers es posible
seguir modificando los parámetros de configuración para mejorar la funcionalidad de la
conexión. Por ejemplo, para mejorar la seguridad usando encriptación o permitiendo el uso de
DHCP. Usar encriptación es tan sencillo como cambiar en el fichero wireless el valor de la
opción encryption por “psk2” para utilizar la encriptación WPA2 que es la más segura.
Además hay que añadir la opción key con el valor de la contraseña deseada. En el caso de
querer usar una configuración con DHCP, en el fichero network de una de las placas router,
hay que cambiar la opción proto de “static” a “dhcp” y por tanto eliminar las opciones
ipaddr y netmask, ya que solo tienen sentido para direcciones estáticas. También es
necesario modificar el fichero dhcp para añadir la nueva interfaz wifi que ya se ha añadido
previamente al fichero network y que se ha configurado en el wireless. Tras estos
cambios solo falta reiniciar los servicios para cargar las nuevas configuraciones escribiendo lo
siguiente:
/etc/init.d/network restart
/etc/init.d/dnsmasq restart
5.3.2 Modo ad-hoc
En contraposición a las redes Wi-Fi en modo infraestructura existe la topología inalámbrica
ad-hoc, en la que los dispositivos se comunican directamente entre sí sin necesidad de utilizar
un punto de acceso. Este diseño de redes punto a punto se utiliza comúnmente para conectar
un pequeño número de ordenadores o dispositivos inalámbricos. Los terminales de esta red
76
que quieran comunicarse entre sí tienen que utilizar el mismo canal radio y configurar un
identificador específico en modo ad-hoc. Por ejemplo, una red inalámbrica ad-hoc puede ser
configurada temporalmente entre los ordenadores portátiles en una sala de juntas o para
conectar sistemas en un hogar, en lugar de utilizar una solución cableada. El diseño
inalámbrico ad-hoc proporciona un método rápido para compartir archivos y recursos entre un
pequeño número de sistemas. Esta topología resulta apropiada para llevar a cabo la
comunicación entre vehículos y es la propuesta por el GCDC como se verá más adelante.
Figura 34 - Topología del modo adhoc
5.3.2.1 Configuración ad-hoc
Anteriormente, se ha explicado como configurar una red en modo infraestructura
mediante ficheros de configuración pero también es posible configurar los dispositivos
directamente a través de la línea de comandos como se va a describir en esta sección. No
obstante, para crear una red en modo ad-hoc usando ficheros de configuración simplemente
hay que modificar los ficheros wireless de ambas placas como en el caso anterior pero en
vez de usar el modo “ap” o “sta” se debe especificar el modo “adhoc”.
En cambio, si se desea configurar directamente la red en modo ad-hoc se utiliza el
comando iwconfig. Pero antes de modificar el modo es necesario deshabilitar la interfaz
inalámbrica mediante el comando ifconfig y tras modificarlo volver a habilitarla. La
sentencia completa se puede ver en el siguiente recuadro.
77
ifconfig wlan0 down
iwconfig wlan0 mode ad-hoc
ifconfig wlan0 up
Para comprobar que los cambios se han efectuado correctamente se utiliza el comando
iwconfig que muestra las interfaces inalámbricas. En la siguiente figura se aprecia que en
efecto la interfaz inalámbrica wlan0 está configurada correctamente en modo ad-hoc.
Figura 35 - Resultado de iwconfig con interfaz en modo adhoc
Para ver que ambos dispositivos inalámbricos están conectados y que es posible la
comunicación se hace ping de un dispositivo a otro y se comprueba efectivamente que la
comunicación es correcta.
5.3.3 Modo CALM FAST
Las configuraciones anteriores se han realizado haciendo uso de los estándares WiFi
clásicos, en concreto del 802.11g y habrá que tener presente que independientemente de la
banda de frecuencia en que trabajan, todos estos estándares de la subfamilia 802.11
comparten algunas limitaciones como pueden ser el alcance, el ancho de banda y la movilidad.
En el desarrollo de una comunicación vehicular como el que se propone la limitación por
movilidad va a jugar un papel clave. Popularmente, se considera que las redes Wi-Fi son
móviles, ya que no hay que conectarse desde una ubicación fija para acceder a los servicios
que nos ofrecen, y además se puede ir caminando y navegando por Internet al mismo tiempo.
78
Estrictamente hablando, eso se considera itinerancia (roaming). De hecho, no es posible
utilizar una red WiFi desde un vehículo en movimiento a velocidad normal, por razones físicas
asociadas a la velocidad. Además, incluso cuando nos movemos a baja velocidad (caminando),
a causa del escaso alcance de cobertura de un punto de acceso, rápidamente tenemos que
establecer conexión con otro punto de acceso. También en este aspecto el estándar presenta
deficiencias que pueden hacer que perdamos brevemente la conexión e incluso hayamos de
volver a conectarnos manualmente. El encargado de solventar estas restricciones es el
estándar 802.11p, que se ocupa precisamente de las comunicaciones en vehículos y ha sido el
estándar usado en proyectos como CVIS y SAFESPOT, sobre el que se ha apoyado el protocolo
CALM FAST.
5.3.3.1 Configuración CALM FAST
La configuración inalámbrica propuesta para soportar el protocolo 802.11p sobre el que se
utilizará CALM FAST se obtiene utilizando las siguientes sentencias:
iw reg set NL
ifconfig wlan0 down
iwconfig wlan0 mode ad-hoc
ifconfig wlan0 up
iw dev wlan0 ibss leave
iw dev wlan0 ibss join ITS 5890 fixed-freq
00:00:00:00:00:00 beacon 0
En primer lugar se establece como dominio regulador los Países Bajos ya que fue el lugar
donde se celebró el evento GCDC y es para lo que se ha preparado el software . Además esto
nos va a permitir utilizar los canales de la banda de 5.9GHz. La lista de canales reglamentarios
viene recogido en el crda, paquete que ha sido previamente modificado y parcheado para
extender los canales del domino regulador a los de la frecuencia de la banda de 5.9 GHz. El
siguiente paso va a ser configurar la interfaz en modo ad-hoc, para lo que hay que
deshabilitarla previamente . Finalmente se selecciona la frecuencia de ITS que es exactamente
5,89 GHz y una dirección fija IBSS. El intervalo de baliza se ajusta a cero, indicando que no hay
79
balizas WLAN en absoluto. Mediante el comando iwconfig se puede ver que la
configuración se ha llevado cabo correctamente.
Figura 36 - Resultado de iwconfig con interfaz configurada según GCDC
También se pude comprobar cómo han cambiado los canales y la frecuencia mediante el
comando iwlist.
Figura 37 - Frecuencia usada en la configuración GCDC
80
Ahora que la interf az inalámbrica está levantada y configurada según los requisitos se
puede lanzar el demonio que implementa el protocolo CALM FAST usando el comando calmd.
Para probar la comunicación están los programas sendbeacons, que envía paquetes por la
red y fastsniff que captura paquetes. A ambos hay que pasarle como parámetro la
interfaz de red inalámbrica, en este caso wlan0, y en el caso de sendbeacons se permite
también la opción de especificar el número de paquetes que se desea enviar. Estando
conectado a una de las placas desde Ubuntu a través del cable Ethernet y a la otra desde un
terminal usando PuTTy mediante el puerto serie, si se usa el comando sendbecons desde
Ubuntu se aprecia que envía el siguiente mensaje:
Figura 38 - Resultado de sendbeacons
81
Entre la información que aparece en el mensaje es posible observar la dirección MAC
destino que es la de difusión y la dirección MAC origen que coincide con la de la placa router.
Si ahora se ejecuta fastsniff en el terminal que está conectado a la otra placa router
usando PuTTy se ve que se captura el mismo mensaje anterior:
Figura 39 - Resultado de fastsniff
82
Por tanto, al lograr que el programa fastaniff ejecutado en una de las entidades
Mobile Router consiga recibir los paquetes enviados por sendbeacons en la otra entidad,
todo ello haciendo uso del demonio calmd que implementa la comunicación CALM FAST,
quedaría demostrado experimentalmente que una comunicación haciendo uso del protocolo
CALM es viable.
Figura 40 - Routers comunicándose mediante CALM FAST en la Sala de Proyectos
83
Capítulo VI
Conclusiones
Para finalizar, una vez vista toda la labor realizada en su conjunto se presenta un breve
resumen acompañado de las conclusiones extraídas hasta alcanzar el principal objetivo
propuesto, implementar un sistema compuesto por entidades Mobile Router que posibilite la
comunicación cooperativa. Por último, se plantean cuáles podrían ser las futuras líneas de
trabajo.
84
6.1 Resumen conclusivo
En los primeros capítulos se presentaba la multitud de ventajas que presentaba el
desarrollo de la comunicación inteligente entre vehículos, que justificaban los avances de estas
tecnologías y el interés de este proyecto. Seguidamente se exponían las diversas iniciativas y
protocolos desarrollados en este ámbito, siendo la iniciativa GCDC y el protocolo ISO CALM la
base sobre la que se ha desarrollado este proyecto. El proyecto ha demostrado que usando un
hardware de bajo coste como una AlixBoard 3D2 es posible modificar los drivers de la
comunicación inalámbrica para que sean compatibles con los requisitos de CALM. En cuanto al
software, se han enseñado las virtudes de OpenWrt, un software libre y gratuito que ofrece
multitud de posibilidades, permitiendo un gran control sobre la configuración del sistema, y
con una comunidad de usuarios creciente. Por tanto, es posible afirmar que se ha obtenido un
sistema ligero, de bajo coste, basado en software libre y que implementa el protocolo CALM
FAST propuesto por el GCDC. Este sistema obtenido, compuesto por dos nodos de transmisión
o entidades Mobile Router, es capaz bajo condiciones controladas de laboratorio de enviar
mensajes entre los dos nodos mediante el estándar CALM, cumpliéndose de este modo el
principal objetivo de este proyecto.
El siguiente paso a realizar en líneas de investigación futuras sería integrar este sistema en
un vehículo y realizar pruebas en un entorno real con comunicaciones vehículo a vehículo y
vehículo a infraestructura. Otra importante línea de investigación a seguir es implementar un
nivel de aplicación, ya que el sistema obtenido solo se centra en las capas inferiores y haría
falta el desarrollo de servicios y aplicaciones que hagan uso de la comunicación ante las
diferentes situaciones que se puedan presentar.
Como conclusión final, decir que los dispositivos inteligentes son claramente una
tendencia hoy en día y los coches inteligentes no van a ser una excepción. Con este proyecto
se han mostrado las virtudes que ofrecería la comunicación entre vehículos y se ha
demostrado que la creación de un sistema demostrador de estas tecnologías es posible.
Aunque todavía queda trabajo por realizar y hay problemas a los que enfrentarse todo apunta
a que en el futuro la comunicación cooperativa entre automóviles se convertirá en una
realidad.
85
Bibliografía
[1] IEEE P1609.0. Draft Guide for Wireless Access in Vehicular Environments (WAVE) –
Architecture. 2013
[2] DIRECTIVA 2010/40/UE del Parlamento Europeo y del Consejo. 2010
[3] Jan de Jongh. GCDC Communications Stack v3. 2011
[4] Erik koenders. CALM FAST router. 2010
[5] Gwenaelle Toulminet, Jacques Boussug y Claude Largeau. Comparative synthesis of
the 3 main European projects dealing with Cooperative Systems (CVIS, SAFESPOT
and COOPERS)
[6] Luis Felipe Herrera Quintero. Modelo de prestación de servicios ITS de valor
agregado. 2011
[7] Ministerio de Fomento. Los sistemas inteligentes de transporte. 2010
[8] Mohammadreza Khaksari. Analysis of communication architecture GCDC. 2011
[9] Nikolajs Agafonovs, Girts Strazdins y Modris Greitans. Accessible, Customizable,
High-Performance IEEE 802.11p Vehicular Communication Solution. 2012
[10] Asoke K. Talukder, Nuno M. Garcia y Jayateertha G. M. Convergence Through All-
IP Networks. 2013
[11] Wim Vandenberghe, Ingrid Moerman y Piet Demeester. Approximation of the IEEE
802.11p Standard Using Commercial Off-The-Shelf IEEE 802.11a Hardware. 2011
[12] Matthew Helmke. Ubuntu Unleashed 2013 Edition
[13] Página oficial de SAFESPOT. Disponible en: http://www.safespot-eu.org/
(consultada en febrero de 2014)
[14] Página oficial de COOPERS. Disponible en: http://www.coopers-ip.eu/ (consultada
en febrero de 2014)
[15] Página oficial de CVIS. Disponible en: http://www.cvisproject.org/ (consultada en
febrero de 2014)
86
[16]Página oficial del GCDC. Disponible en: http://www.gcdc.net/ (consultada en
febrero de 2014)
[17] Página oficial de OpenWrt. Disponible en: https://openwrt.org/ (consultada en
febrero de 2014)
[18] Página oficial de BuildRoot. Disponible en: http://buildroot.uclibc.org/ (consultada
en febrero de 2014)
[19] Página con documentación sobre los drivers de comunicación inalámbrica para
Linux. Disponible en: http://wireless.kernel.org/en/users/Documentation
(consultada en febrero de 2014)
87
Anexo I
Comandos Linux de configuración de red
A lo largo de este proyecto ha sido necesario utilizar diversas herramientas cuyo uso es
común a la hora de administrar y configurar redes en Linux. En este anexo se resumen algunas
de las herramientas más útiles, mostrando su sintaxis y una breve descripción.
88
ifconfig [interfaz] [configuración] [up|down]
Es el principal comando para configurar la interfaz de red. En concreto se usa para:
• Mostrar el estado de las interfaces activas. En este caso se escribe el comando sin
argumentos.
• Activar o desactivar la tarjeta de red o cambiar el modo del NIC (Network Interface
Card, en español "tarjeta de interfaz de red").
• Cambiar la dirección IP de la máquina, la máscara de red o de difusión.
• Crear un alias de IP para permitir más de una dirección IP en la NIC.
• Configurar una dirección de destino para una conexión punto a punto.
route [opciones]
Permite modificar la tabla de enrutamiento, mostrando, añadiendo o borrando rutas. Se
usa después de que ifconfig haya inicializado la interfaz. Su principal uso es el de:
• Mostrar las rutas definidas.
• Añadir/borrar rutas estáticas.
• Definir una pasarela de salida por defecto para conectarse al exterior.
• Configurar el sistema para que actúe como un router.
netstat [tipo de información] [opciones]
Permite visualizar el estado de la red y los servicios en uso clasificados por sockets.
ping [opciones] dirección
Muestra la disponibilidad de conexión y la velocidad de transmisión con un host remoto. El
comando envía paquetes ICMP al destino y espera respuesta, midiendo el tiempo que tarda en
llegar esta.
iwconfig [interfaz] [opciones]
Es similar a ifconfig pero enfocado a la configuración de inte rfaces de red
inalámbricas.
iwlist [interfaz] [opciones]
Entre sus opciones destacan “scan” que muestra todas las redes visibles desde el
dispositivo y “channel” que informa de los valores de frecuencia y canal que soporta la
interfaz.
89
Anexo II
Ficheros de configuración de OpenWrt
La configuración de la red puede realizarse mediante línea de comandos usando las
herramientas expuestas en el anexo I pero también editando los ficheros de configuración
existentes en la ruta /etc/config. A continuación se describen los principales ficheros de
configuración con sus respectivos parámetros necesarios para habilitar y configurar una red
inalámbrica.
90
Network
El fichero network es el encargado de la configuración de las interfaces asociadas a cada
red. A continuación se muestra un ejemplo de cómo sería una configuración básica del fichero.
config interface loopback
option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0
config interface lan
option ifname eth0
option proto static
option ipaddr 192.168.2.1
option netmask 255.255.255.0
config interface wifi
option proto static
option ipaddr 192.168.3.1
option netmask 255.255.255.0
Se pueden observar tres interfaces:
• La interfaz loopback, que se suele utilizar cuando una transmisión de datos tiene
como destino el propio host. También en tareas de diagnóstico de conectividad y
validez del protocolo de comunicación.
• La interfaz lan, definida para la comunicación dentro de una red local.
• La interfaz wifi, definida para la comunicación inalámbrica.
91
Cada vez que se quiera declarar una nueva interfaz lógica en la red se le debe otorgar un
nombre y configurarla dando valores a las diferentes opciones según el uso que se le vaya a
dar a la nueva interfaz:
• La opción ifname se debe completar con la inte rfaz física que se desea usar.
Observar que la interfaz wifi no tiene la opción ifname ya que junto con otras
opciones será definido posteriormente en el fichero de configuración wireless.
• La opción proto hace referencia al protocolo que se pretende utilizar. En este
ejemplo se usa la opción “static” para asignar direcciones de forma estática, es decir,
configurar manualmente la información de la dirección IP pero también se puede
hacer uso de la opción “dhcp” para el direccionamiento dinámico a través del
protocolo de configuración dinámica de host (DHCP). Existen otras opciones como PPP
(Punto a Punto) y 3g pero no se han tenido en cuenta como objeto de estudio para
este proyecto.
• Para cada protocolo existen varias opciones específicas que pueden ser obligatorias u
opcionales. En este ejemplo, al haber seleccionado el protocolo estático, es necesario
para determinar la dirección de la red completar las opciones ipaddr y netmask,
que se corresponden con la dirección IP y la máscara de red.
92
Wireless
El fichero wireless es necesario para la configuración de la comunicación inalámbrica.
En el siguiente recuadro se muestra como sería un fichero de ejemplo.
config wifi-device wl0
option type broadcom
option channel 6
config wifi-iface
option device wl0
option network lan
option mode ap
option ssid MiWifiAP
option encryption psk2
option key contraseña
El wifi-device se corresponde con el dispositivo inalámbrico utilizado que en este
ejemplo es “wl0”. Dentro de la configuración del wifi-device cabe destacar las siguientes
opciones:
• type. Este parámetro es autodetectado en el arranque inicial por lo que, por regla
general, no es necesario cambiarlo. Los valores típicos son “broadcom” para brcm-2.4,
“atheros” para madwifi y “mac80211” para b43, ath9k y ath5k.
• channel. Especifica el canal inalámbrico utilizado. En el modo estación está
permitido el valor “auto” pero en el modo punto de acceso se debe fijar un canal.
• phy y macaddr. La opción phy determina la interfaz radio física que se pretende
utilizar en el caso en el que se desee ser más independiente del hardware ya que
OpenWrt por defecto usa la opción macaddr que usa la dirección MAC del dispositivo
ya que es más preciso. Ambas opciones son autodetectables en el arranque y solo son
compatibles con el type “mac80211” y “atheros”.
93
• hwmode. Especifica el estándar inalámbrico en la categoría de IEEE 802.11 utilizado
siendo posibles valores 11a, 11b, 11g, 11bg, 11ng, etc.
• htmode. Campo solo compatible con “mac80211” que especifica el ancho de banda
del canal en modo 11na y 11ng. Los valores posibles son HT20, HT40- y HT40+.
• country. Especifica el código del país, que determina los canales y niveles de
potencia permitidos.
• txpower. Determina la potencia de transmisión de la antena en dbm
• beacon_int. Determina el intervalo de envío de balizas o beacons para los modos
ap y adhoc.
• disabled. Si se fija a 1 deshabilita el adaptador inalámbrico.
La sección wifi-iface se corresponde con la configuración de la interfaz inalámbrica
virtual. Cabe resaltar las siguientes opciones:
• device. Especifica el adaptador inalámbrico utilizado y debe corresponder con el
definido en la sección wifi-device.
• network. Determina el nombre de la interfaz de red a la que asociar la interfaz
inalámbrica. Este nombre debe coincidir con el configurado en el fichero
etc/config/network.
• mode. Especifica el modo de operación del dispositivo inalámbrico. Alguno valores
posibles son:
o “ap” para funcionamiento en modo punto de acceso.
o “sta” para funcionamiento en modo cliente.
o “adhoc” para funcionamiento en modo ad-hoc.
o Otros modos de funcionamiento que no se han analizado en este proyecto son
“wds”, “monitor” y “mesh”.
• ssid. El Service Set Identifier (SSID) es un nombre asignado a una red inalámbrica. En
modo punto de acceso, especifica el nombre de esa red mientras que en modo cliente
determina el nombre de la red a la que se desea conectarse.
94
• encryption. Permite elegir la encriptación deseada. Las opciones posibles son
“none” para una red abierta, wep para WEP, psk para WPA-PSK y psk2 para WPA2-PSK.
• key. En el caso de haber elegido una encriptación este parámetro se corresponde con
la clave.
DHCP
En el fichero dhcp se encuentran las configuraciones tanto del servidor DNS como del
DHCP. El DNS no ha sido objeto de estudio durante la realización de este trabajo por lo que se
obviará la descripción de sus opciones de configuración. En cambio, sí que es interesante
conocer las opciones básicas para la configuración del DHCP para cuando se desee usar
direccionamiento dinámico.
config dhcp wifi
option interface wifi
option start 100
option limit 150
option leasetime 12h
La configuración que se muestra en el siguiente recuadro, correspondiente a la interfaz
“wifi” se interpreta de la siguiente manera:
• interface. Especifica la interfaz a la que está asociada la configuración. Debe
coincidir con la definida en el archivo network.
• start. Especifica el offset de la dirección de red, que por defecto es 192.168.1.100
• limit. Especifica el máximo número de direcciones que pueden otorgarse.
• leasetime. Especifica el tiempo de concesión de las direcciones otorgadas.