Download - Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

Transcript
Page 1: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 2: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 3: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 4: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 5: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 6: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 7: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 8: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 9: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 10: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 11: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 12: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 13: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 14: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 15: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 16: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 17: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 18: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 19: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 20: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 21: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 22: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 23: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 24: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 25: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 26: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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:

Page 27: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 28: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 29: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 30: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 31: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 32: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 33: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 34: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 35: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 36: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 37: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 38: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 39: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 40: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 41: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 42: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 43: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 44: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 45: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 46: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 47: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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:

Page 48: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 49: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 50: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

.

Page 51: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 52: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 53: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 54: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 55: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 56: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 57: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 58: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 59: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 60: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 61: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 62: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 63: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 64: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 65: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 66: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 67: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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:

Page 68: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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 [email protected]

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

Page 69: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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/

Page 70: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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 [email protected]:/home/jossamarm/descargas/wpad-

mini_20111103-2_x86.ipk

[email protected]:/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 :

Page 71: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 72: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 73: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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:

Page 74: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 75: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 76: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 77: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 78: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 79: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 80: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 81: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 82: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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

Page 83: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 84: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 85: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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)

Page 86: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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)

Page 87: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 88: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 89: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 90: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 91: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 92: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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”.

Page 93: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.

Page 94: Proyecto Fin de Carrera Ingeniería de Telecomunicaciónbibing.us.es/proyectos/abreproy/12196/fichero/PFC_Jose_M_Sampedr… · Proyecto Fin de Carrera ... Figura 22 - Mikrotik R52H

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.