SACAR - Sistema de Alertas en Carretera

  • 2,817 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,817
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ´ UNIVERSIDAD DE ALCALA Escuela T´cnica Superior de Ingenier´ Inform´tica e ıa a INGENIER´ EN INFORMATICA IA ´ Trabajo Fin de Carrera SACAR Sistema de Alertas en CARretera Autor: Eduardo Mar´ Izquierdo ın Director: Enrique de la Hoz de la HozTribunal:Presidente:Vocal 1º:Vocal 2º: ´CALIFICACION: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FECHA: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  • 2. 2
  • 3. ´ UNIVERSIDAD DE ALCALAESCUELA TECNICA SUPERIOR DE INGENIER´ INFORMATICA ´ IA ´ INGENIER´ EN INFORMATICA IA ´ PROYECTO FIN DE CARRERA SACAR Sistema de Alertas en CARretera Autor: EDUARDO MAR´ IZQUIERDO IN Tutor: D. ENRIQUE DE LA HOZ DE LA HOZ SEPTIEMBRE DE 2012
  • 4. Sin embargo, hasta que ponemos a prueba lo incon-trolable que llevamos dentro dejamos que la prudenciaestablezca los l´ımites, sabemos poco acerca de lo quenos impulsa a atravesar glaciares y torrentes y subir apeligrosas alturas. JOHN MUIR
  • 5. AgradecimientosMe gustar´ agradecer, en primer lugar, a mi tutor Enrique de la Hoz de la Hoz, el inter´s ıa erecibido de su parte en este proyecto, por su apoyo y paciencia mostrada a lo largo deldesarrollo del mismo. En segundo lugar, a mis amigos, gracias por estar ah´ Finalmente, ı.y de forma muy especial, a Marta, por haberme acompa˜ado en el camino, y a mi familia, nmis hermanas y mis padres, que sin su apoyo, confianza y educaci´n esta meta habr´ o ıaestado muy muy lejos.
  • 6. v SACAR - Sistema de Alertas en Carretera Eduardo Mar´ Izquierdo ın 09 de septiembre de 2012 802.15.4, zigBee, xBee, APAL, Arduino, Omnet++, V2V, ResumenProyecto de desarrollo de un Sistema de Alertas en Carretera implementado sobre micro-controladores opensource - openhardware Arduino capaz de transmitir mensajes siguiendola filosof´ vehicle to vehicle bajo el protocolo de comunicaci´n 802.15.4 (ZigBee). Pre- ıa ovia a la implementaci´n, se realiza una fase de simulaci´n, creando diferentes escenarios o oy situaciones relacionados con el tr´fico vehicular, y una fase de recogida de datos que apermiten evaluar el algoritmo de control de broadcast storming probabil´ ıstico (APAL -Adaptive Probability Alert Protocol ) que usamos, todo ello en plataformas de simulaci´n ode redes de comunicaci´n Omnet++ y de redes de tr´fico vehicular SUMO. o a AbstractRoad warning system development project implemented using mocrocontrollers opensource- openhardware. This system is capable to transmit messages under vehicle to vehicle phi-losophy. The system uses the 802.15.4 (zigBee) communication protocol. Previous to theimplementation work, several simulations were made to create different scenarios relatedwith vehicular traffic. As a result of the diferent situations studied, data samples werecollected to evaluate the diffusion APAL algorithm (Adaptive Probability Alert Protocol )used in the communication networks (Omnet++) and vehicular traffic (SUMO) simula-tions frameworks.Introducci´n o comunicaci´n inal´mbrica ”vehicle to vehi- o a cle” basado en el protocolo 802.15.4, m´s a SACAR, Sistema de alertas en carretera comunmente conocida como tecnolog´ in- ıase presenta como un un proyecto de Inge- al´mbrica zigBee. Tras acercarnos al tipo anier´ que encierra un proceso de investi- ıa de tecnolog´ que usaremos en nuestro sis- ıagaci´n y desarrollo. Por un lado, se real- o tema de alertas, y previo al paso de desar-iza un proceso de investigaci´n en el cual o rollo, continuaremos en el proceso de inves-se presenta la problem´tica a resolver, esto a tigaci´n desplegando y adaptando una serie oes, la falta de intercomunicaci´n que existe o de herramientas de simulaci´n que nos per- oen la actualidad en los veh´ ıculos rodados, mitan llevar a cabo aproximaciones de al-y la consecuente falta de aprovechamiento goritmos de distribuci´n de la informaci´n o ode informaci´n util, valiosa para evitar ac- o ´ sobre el protocolo zigBee en diferentes en-cidentes o facilitar el paso de diferente tipos tornos que pongan de manifiesto el porqu´ ede veh´ ıculos. Una vez definido el prob- de su empleo en el sistema f´ ısico que final-lema a resolver establecemos la forma en la mente desarrollemos. Para poder realizarque lo resolveremos, realizando una primera ese tipo de argumentaciones debemos reali-investigaci´n sobre el tipo de tecnolog´ o ıa zar una serie de tomas de datos que facilitendisponible en la actualidad y qu´ alterna- e la comprensi´n y la elecci´n de uno u otro al- o otiva seleccionamos y por qu´. As´ en nue- e ı, goritmo. Veremos, por tanto, c´mo las sim- ostro caso, y por las razones que m´s ade- a ulaciones nos ayudan a comprobar que difu-lante detallaremos, seleccionamos un tipo de siones de alertas sin control son problem´ti- a
  • 7. vicas y no reguladas a alto nivel por el proto- y cuyos avances apuntan a que ser´ el sis- acolo zigBee, sino que debemos establecer un tema de comunicaci´n entre veh´ o ıculos est´n- amecanismo a nivel de aplicaci´n que lleve o dar del futuro.a cabo dicha gesti´n. As´ veremos c´mo o ı, o No obstante, no est´ de m´s aproxi- a ase comporta un tipo de algoritmo llamado marnos por otras v´ y que en el prop´sito ıas, oAPAL (Adaptive Probability Alert Protocol ) de este proyecto se centra en hacerlo me-y c´mo favorece la difusi´n de mensajes evi- o o diante el empleo de recursos abiertos ytando el colapso del sistema por problemas baratos. Y, para poder decantarnos porasociados al broadcast (broadcast storming). una alternativa, debemos contemplar las op- Como segunda fase en la elaboraci´n de o ciones disponibles actualmente:este proyecto, y en base a las conclusionesobtenidas en la primera parte del proyecto, ˆ IEEE 802.11 - WiFi La creaci´n deollevamos a cabo un desarrollo ligero del sis- los est´ndares que han dado lugar al atema de alertas utilizando la tecnolog´ de- ıa Wi-Fi, bajo el nombre IEEE 802.11scrita anteriormente, esto es, difusi´n de o [13], es una tarea llevada a cabo poralertas mediante el empleo de tecnolog´ in- ıa el International Electrical and Elec-al´mbrica 802.15.4 y l´gica de gesti´n con el a o o tronic Engineers (Asociaci´n Interna- ouso del algoritmo APAL, todo ello montado cional de Ingenieros Electr´nicos y de osobre sistemas embebidos, de bajo coste, Telecomunicaciones), conocido por lasfamosos por su alta flexibilidad tanto en tec- siglas IEEE.nolog´ soportadas como en flexibilidad en ıas De manera purista vale decir que eldesarrollo de l´gica de control. Hablamos o acr´nimo Wi-Fi se utiliza para iden- ode microcontroladores Atmega en su versi´n o tificar los productos que incorporancomercial m´s famosa, la serie Arduino. a cualquier variaci´n de la tecnolog´ o ıa inal´mbrica de los est´ndares IEEE a a 802.11, que permiten la creaci´n de re- oEstado del arte des de ´rea local sin hilos conocidas a como WLAN, y que son plenamente Hablar sobre la situaci´n actual en lo ref- o compatibles con los de cualquier otroerente a tecnolog´ de comunicaci´n en el ıas o fabricante que utilice estos est´ndares. a´mbito del transporte rodado es hablar dea Las caracter´ısticas generales de fun-redes VANET. cionamiento de una red Wi-Fi son las Las redes VANET (Vehicular Ad-Hoc mismas que las de una red cableada.Networks) son un tipo de infraestructura La particularidad es que el Wi-Fi uti-de comunicaci´n basada en las redes ad- o liza el espacio como medio de trans-hoc para dispositivos m´viles (Mobile Ad- o misi´n. oHoc Network (MANET)), y destinadas aluso en veh´ ıculos. Este tipo de tecnolog´ ıa Los componentes b´sicos de una red apermite considerar cada veh´ ıculo como un Wi-Fi son:nodo activo en la red que, de forma con- – El punto de acceso (AP): es lajunta con sus adyacentes, interconecta no- uni´n entre las redes cableadas odos m´s lejanos, levantando una infraestruc- a y la red WiFi, o entre diversastura din´mica de comunicaci´n relativa- a o zonas cubiertas por redes Wi-Fi,mente grande sin apoyo de infraestructura que act´a entonces como repeti- ude red fija. dor de la se˜al entre estas zonas n Para la implantaci´n de redes VANET o (celdas).se dispone de diferentes protocolos de co-municaci´n que podr´ ser utilizadas para o ıan – Una o m´s antenas conectadas al atal prop´sito. No obstante, para una im- o punto de acceso.plantaci´n real, estandarizada y que no com- o ´ – Un terminal Wi-Fi. Este puedeprometa aspectos relacionados con la seguri- tener forma de dispositivo ex-dad o fiablidad de la misma se propone el terno Wi-Fi, que se instala enprotocolo 802.11p, base del est´ndar DSRC a el PC del usuario, o bien puede
  • 8. vii encontrarse ya integrado, como ciones separadas si la potencia de sucede habitualmente con los transmisi´n lo permite. o ordenadores port´tiles. a Adi- cionalmente se pueden encontrar ˆ UWB Ultra Wide Band es un es- otros terminales con capacidad t´ndar basado en 802.15.3 que fun- a de comunicaci´n, como agendas o ciona emitiendo a muy baja potencia electr´nicas (PDA) y tel´fonos o e en un espectro enorme. Su alcance m´viles, que disponen de acce- o es muy limitado (<10m) pero propor- sorios (internos o externos) para ciona tasas de transferencia muy el- conectarse a redes Wi-Fi. evadas llegando a los 480 Mbps. Su consumo de energ´ es muy reducido. ıaˆ 802.11p Tambi´n conocida como e Wireless Access for the Vehicular En- ˆ ZigBee - 802.15.4 ZigBee es el nom- vironment (WAVE), est´ en proceso a bre de la especificaci´n de un con- o de estandarizaci´n y ser´ la encar- o a junto de protocolos de alto nivel de gada en un futuro de soportar las comunicaci´n inal´mbrica para su uti- o a comunicaciones vehiculares. WAVE lizaci´n con radiodifusi´n digital de o o es una evoluci´n del est´ndar IEEE o a bajo consumo, basada en el est´ndar a 802.11a con modificaciones a nivel IEEE 802.15.4 de redes inal´mbricas a f´ ısico y MAC para mejorar su com- de ´rea personal (Wireless Personal a portamiento en el entorno vehicular y Area Network, WPAN). Su objetivo dar soporte a sistemas de transporte son las aplicaciones que requieren co- inteligente (Itelligent Transportation municaciones seguras con baja tasa de Systems (ITS)). Asimismo, WAVE es env´ de datos y maximizaci´n de la ıo o la base sobre la que se desarrolla el vida util de sus bater´ ´ ıas. DSRC (Dedicated Short Range Com- munications), otro proyecto de es- Debido a las caracter´ısticas que ofrece tandarizaci´n impulsado por el minis- o ZigBee, en cuanto a coste y facilidad de inte- terio de transporte de EE UU y por un graci´n con plataformas de desarrollo, abier- o n´mero importante de fabricantes de u tas y baratas, elegiremos dicho protocolo. la industria del autom´vil, cuyo obje- o tivo es crear una red nacional de comu- nicaciones vehiculares. El prop´sito el o zigBee - 802.15.4 proyecto es definir un est´ndar para a ZigBee/802.15.4 es una tecnolog´ in- ıa las comunicaciones V2V y las comu- al´mbrica de bajo consumo, baja tasa de a nicaciones con la infraestructura vial transmisi´n y coste reducido, que se engloba o (V2I) que se puede instalar en sem´- a dentro del grupo de las tecnolog´ WPAN ıas foros o paneles de informaci´n, por o (Wireless Personal Area Network). ejemplo. Una de las ventajas que ofrece es la flex-ˆ Bluetooth Se denomina Bluetooth ibilidad para la construcci´n de diferentes o al protocolo de comunicaciones dis- topolog´ a partir de una serie de roles que ıas e˜ado especialmente para dispositivos n puede representar cada uno de los compo- de bajo consumo, con una cobertura nentes de la red. baja y basados en transceptores de As´ hablamos de elemento: ı, bajo costo. ˆ Coordinador. Este dispositivo ini- Gracias a este protocolo, los disposi- cializa y controla la red. Tambi´n se e tivos que lo implementan pueden co- encarga de gestionar las tareas de se- municarse entre ellos cuando se en- guridad. Para poder formar una red cuentran dentro de su alcance. Las ZigBee debe existir un coordinador. comunicaciones se realizan por ra- diofrecuencia de forma que los dispos- ˆ Router. Estos dispositivos son los en- itivos no tienen que estar alineados cargados de extender la cobertura de y pueden, incluso, estar en habita- la red, gestionando nuevos caminos en
  • 9. viii el caso de que la red experimente con- raci´n y trazabilidad de datos, extracci´n de o o gesti´n o se produzca la ca´ de al- o ıda estad´ ısticas y flexibilidad a la hora de adap- g´n nodo. Pueden conectarse directa- u tar cualquier elemento que en ella exista a mente al coordinador o a otros routers. nuestras necesidades. Gestionan dispositivos hijo. Por otro lado, estos dispositivos ir´n a montados en veh´ ıculos que podr´n moverse a ˆ Dispositivo final. Este tipo de dis- con total libertad a lo largo de un es- positivo puede enviar y recibir datos cenario. Se desprende inmediatamente la pero no realizar tareas de encami- necesidad de contar con una herramienta namiento. Deben estar conectados a de simulaci´n de tr´fico de veh´ o a ıculos que un router o al coordinador y no ad- ofrezca, adem´s, integraci´n o soporte para a o miten dispositivos hijo. la herramienta de simulaci´n que hemos o Que derivan en tres tipos de topolog´ ıas: mencionado anteriormente. Adem´s, de laaestrella, malla y ´rbol (figura 3.2). Una a misma manera, deber´ tratarse de una apli- ıared se caracteriza por su identificador PAN caci´n flexible en configuraci´n de escenar- o o(PAN ID), que la distingue de otras posibles ios, facilidad en creaci´n de flujos de tr´fico o aredes funcionando en la misma zona. vehicular y comportamiento aleatorio de ve- h´ıculos. Adem´s, el est´ndar soporta un tipo a a As´ para la simulaci´n de protocolos ı, ode topolog´ en el cual no es necesario ıa de comunicaci´n, haremos uso de la her- oning´n elemento coordinador siempre que se u ramienta de simulaci´n Omnet++. El dis- oest´ transmitiendo en modo difusi´n. Esta e o e˜o de OMNeT++ se basa en los siguientes ntopolog´ que permite hacer crecer una red ıa, puntos:de forma din´mica y sin la limitaci´n de que a o ˆ Permitir simulaciones a gran escala,deba haber un elemento coordinador ser´ la a mediante modelos jer´rquicos constru- aelegida para nuestro prop´sito. o idos con componentes reutilizables. ˆ Una interfaz gr´fica orientada a la aSimulaci´n en Omnet++ - o depuraci´n y verificaci´n de los mod- o o elos implementados.SUMO ˆ Estructura modular que permite ex- El desarrollo de un sistema de alertas tensibilidad y personalizaci´n, as´ o ıcomo el aqu´ descrito implica la existencia de ı como inclusi´n de componentes en oun n´mero de dispositivos lo suficientemente u aplicaciones m´s grandes de planifi- agrande para que puedan llevarse a cabo las caci´n de red. opruebas necesarias para comprobar que elsistema funciona correctamente. Una de las ˆ Interfaces de datos abiertas,opciones ser´ realizar dichas pruebas en un ıa generando ficheros de definici´n y de oescenario real, con dispositivos reales. resultados f´cilmente interpretables y a Dado que ese escenario se vuelve com- procesables por herramientas gen´ri- eplejo, extenso y caro, es necesario plantear cas.una serie de simulaciones, que nos permiten ˆ Proveer un entorno de desarrollo inte-aproximar resultados a los que pudieran de- grado que facilita el desarrollo de mod-volverse de una ejecuci´n real. o elos y el an´lisis de resultados. a Por un lado, dado que trabajaremoscon dispositivos de comunicaci´n inal´m- o a La base del entorno de simulaci´n es el obrica, que tienen soporte para un protocolo n´cleo o kernel. En ´ste se encuentran pro- u eest´ndar de comunicaci´n como es IEEE a o gramadas las funciones generales que per-802.15.4, necesitaremos una herramienta de miten la extensi´n modular del programa osimulaci´n capaz de ofrecer la arquitectura o para la simulaci´n en ´reas espec´ o a ıficas me-necesaria para crear redes de comunicaci´n,o diante herencia e interfaces en C++. Dentrocon soporte para diferentes protocolos de co- de cada extensi´n o framework espec´ o ıfico semunicaci´n, que ofrezca utilidades de depu- o pueden definir los modelos de simulaci´n. o
  • 10. ix La definici´n de modelos en OMNeT se o donde los paquetes RREQ (route request -lleva a cabo de forma modular jer´rquica. a petici´n de ruta) compiten con los paque- oExiste un m´dulo principal, por ejemplo el o tes de datos, nos encontramos con que, enm´dulo de red, que engloba todos los ele- o el nivel de aplicaci´n, un paquete puede ser omentos y relaciones existentes entre ellos. reenviado m´ltiples veces si no existe un uDebajo de este nivel, est´n los m´dulos com- a o control expl´ ıcito que limite el n´mero de in- upuestos, que integran sistemas y elementos tentos.f´ ısicos de la red, como pueden ser routers, Es necesario, por tanto, aplicar algorit-servidores Web, hosts de usuarios finales, mos de difusi´n que minimicen estos proble- oenlaces inal´mbricos, etc. Y finalmente, en a mas, tomando como par´metros de control ael nivel m´s bajo de la jerarqu´ se en- a ıa, valores relativos a la posici´n del emisor y o ´cuentran los m´dulos simples. Estos imple- o remitentes, ventanas de reenv´ probabil´ ıo, ıs-mentan funciones concretas, como interfaces ticos, . . .de red (punto-a-punto, Ethernet. . . ), proto- Si bien, en nuestro caso, pudi´ramos ecolos espec´ ıficos (TCP, FTP. . . ), o canales haber optado por un par´metro de con- apara la conexi´n entre m´dulos (enlaces de o o trol basado en la geolocalizaci´n, preferimos ofibra, enlaces inal´mbricos. . . ). Los m´- a o suponer que no todos los intervinientes en eldulos simples son la base de los modelos sistema tendr´ un dispositivo GPS. ıandefinidos en OMNeT++, y est´n implemen- a Bajo este supuesto, optamos por un al-tados en lenguaje C++. goritmo probabil´ ıstico, que toma diferentes Gracias a esta jerarqu´ o modular- ıa valores para regular el reenv´ de paquetes. ıoizaci´n podremos construir nuestro sistema, o Dicho algoritmo es APAL (Adaptative Prob-basado en el protocolo 802.15.4, mediante el ability Alert Protocol [63]).empleo de un paquete que contiene su defini- APAL se presenta para resolver difer-ci´n (proyecto mixim-sommer ) y adaptar la o entes problemas en la difusi´n de alertas ocapa de aplicaci´n a las necesidades concre- o en caso de accidente en redes VANET. Sitas del proyecto. Una de esas adaptaciones un mensaje de alerta es difundido de formaser´ la inclusi´n de un algoritmo de con- a o indiscriminada, en poco tiempo nos encon-trol de broadcast storming que detallaremos traremos ante el problema de la tormentaa continuaci´n.o de difusi´n (broadcast storm). Por contra, o si realizamos una restricci´n en la retrans- o misi´n de dicha informaci´n, podemos en- o oAlgoritmo APAL contrarnos ante una muerte temprana de los paquetes de alerta. Este problema crece Se define broadcast radiation como una si tenemos en cuenta que, en situacionesacumulaci´n de tr´fico broadcast y multicast o a reales, las inclemencias meteorol´gicas y las oen una red inform´tica. Si dicha acumu- a diferentes velocidades que comportan los ve-laci´n alcanza niveles extremos de difusi´n, o o h´ıculos, empobrecen la calidad de la co-constituyen lo que se conoce como broad- municaci´n. Muchos protocolos existentes ocast storm. El mayor problema que se aso- para el control de broadcast storm asumencia a este suceso es la cantidad de recursos la disponibilidad de dispositivos GPS en losque son consumidos en la red, llegando a veh´ıculos para poder operar, no obstante,alcanzar niveles de colapso que impiden la dicha premisa es arriesgada, pues no secorrecta entrega de paquetes de datos (dene- tienen en cuenta las altas latencias o impre-gaci´n de servicio). o cisi´n en el c´lculo de las posiciones de cada o a En el contexto de las redes ad-hoc veh´ıculo, que dificultan un control fino sobre(MANET), y m´s concretamente en las a este problema.redes VANET, ante un medio de trans- Por ello, el protocolo APAL no necesitamisi´n inal´mbrico, nos encontramos con o a informaci´n sobre la localicaci´n espacial del o ouna topolog´ de red en la cual, una difusi´n ıa o veh´ıculo. La probabilidad con la que unde paquetes de datos se vuelve impredecible mensaje de alerta se reenv´ es continua- ıay de dif´ seguimiento y control. ıcil mente adaptado en funci´n del grado de ex- o Aparte de la problem´tica existente, a istencia de broadcast problem, sin dejar de
  • 11. xlado, por otro lado, el problema de p´rdida e y reenv´ a lo largo de un n´mero ıo ude mensajes por la aparici´n de ”veh´ o ıculos determinado de intervalos de tiempociegos” no alcanzables. (v delta[]). As´ ante un accidente o situaci´n de ı, o ˆ v duplicatenumber[]: n´mero de uemergencia, el veh´ıculo comienza a difundir mensajes repetidos que se detectanun mensaje de alerta. Los veh´ ıculos que a lo largo del tiempo de vida dese aproximan al accidente recibir´n dicho a la operaci´n (el tiempo de vida - omensaje. Todos los veh´ ıculos que lo hayan v countime - engloba varios intervalosrecibido, de forma adaptativa, decidir´n si a de tiempo - v delta - ).deben o no reenviarlo, dependiendo de di-versos factores. ˆ v limite intervalo[]: indica el punto A continuaci´n detallamos el pseu- o temporal en el que expira el inter-doc´digo del algoritmo APAL: o valo de tiempo. As´ para un in- ı, stante i = simTime(), v delta[] expiraWhen Receive Alert message IF(Receive alert message for First time) en v limite intervalo[] = simTime() + ∆i Random between 1 - 100ms v delta[]. Pi Random probability between 0.7 - 0.9 END IF ˆ v beta[]: vector que contiene, para CountTime = 0 cada mensaje, un l´ ımite m´ximo de a DuplicateNumber = 0 tiempo de vida de operaci´n. Estable- o WHILE( CountT ime < β&&DuplicateN umber < δ) cido, por defecto, a cinco segundos. WHILE(∆τi is not expired) Listen for duplicate alert message ˆ v sigma[]: vector que contiene, para Count = number of received duplicate cada mensaje, un l´ ımite m´ximo de a alert message mensajes repetidos en el tiempo de END WHILE vida de operaci´n. Establecido, por o IF(received duplicate alert message) DuplicateN umber = DuplicateN umber+ defecto, a cinco mensajes. Count Una vez definido el protocolo de comuni- Pi+1 = Pi /DuplicateN umber ∆τi+1 = ∆τi ∗ DuplicateN umber caci´n a utilizar, establecida la herramienta o ELSE de simulaci´n de redes y de tr´fico vehicu- o a Rebroadcast with Pi lar, y seleccionado el algoritmo de control de END IF broadcast storm, se realizan las simulaciones CountT ime = CountT ime + ∆τiEND WHILE pertinentes. Estas simulaciones, realiza- das sobre una serie de escenarios, que van A continuaci´n se detalla el significado o desde simples v´ rectas unidireccionales, ıasde cada uno de estos vectores: hasta completos escenarios reales, pasando por figuras geom´tricas bien definidas (red e ˆ v delta[]: vector que contiene el in- manhattan), obtendremos una serie de re- tervalo de escucha en un determinado sultados en los que se comparan latencias instante para un determinado men- en el env´ de paquetes desde su origen ıo saje. hasta los diferentes componentes de la red, n´mero de veh´ u ıculos que reciben o que no ˆ v pi[]: vector que contiene la proba- reciben los mensajes de alerta respecto al bilidad de reenv´ asociada a un deter- ıo total (bind vehicles), y en diferentes situa- minado mensaje. ciones (movimiento, obst´culos, con o sin al- a ˆ v count[]: n´mero de mensajes u goritmo APAL...). repetidos que se detectan a lo largo de un determinado instante de escucha Implementaci´n o en Ar- (v delta[]), para un determinado men- saje. duino ˆ v countime[]: tiempo de vida en el Arduino es una plataforma de hardware cual se realizar´n, para un determi- libre, basada en una placa con un micro- a nado nodo, las operaciones de escucha controlador y un entorno de desarrollo, dis-
  • 12. xie˜ada para facilitar el uso de la electr´nica Hardware - Open Software Arduino. n oen proyectos multidisciplinares (figura 9.1). Si bien el objetivo inicial del proyecto pasaba por un sistema funcional completo, El hardware consiste en una placa con un diferentes limitaciones han hecho nece-microcontrolador Atmel AVR y puertos de sario diferentes adaptaciones que se reflejan,entrada/salida. Los microcontroladores m´s tanto en limitaciones funcionales (forma de ausados son el Atmega168, Atmega328, At- presentaci´n de las alertas, tipo de alertas y omega1280, ATmega8 por su sencillez y bajo datos a registrar, ...) como limitaciones rela-coste que permiten el desarrollo de m´lti- tivas a la capacidad de c´mputo y eficiencia u oples dise˜os. Por otro lado el software con- del mismo (n´mero de alertas a procesar en n usiste en un entorno de desarrollo que imple- paralelo, precisi´n y filtrado de alertas, ...). omenta el lenguaje de programaci´n Process- o No obstante, dada la evoluci´n y mejora oing/Wiring y el cargador de arranque (boot constante que sufren las plataformas deloader ) que corre en la placa. microcontrol como Arduino, es interesante Sobre esta plataforma de desarrollo, seguir prestando atenci´n a las posibles solu- oinstalaremos un m´dulo de comunicaci´n o o ciones que podamos desarrollar de cara abasado en el protocolo de comunicaci´n de- o mejorar este tipo de sistemas, y quiz´ po- ascrito en este proyecto, esto es, el est´ndar a damos contar, en un tiempo relativamente802.15.4 en su versi´n comercial xBee. o corto, de dispositivos con mayor capacidad que nos permitan mejorar dichas soluciones Este m´dulo nos permitir´ realizar la o a y solventar las limitaciones comentadas.comunicaci´n entre los diferentes Arduinos outilizando el env´ de datos como si de un ıo De esta forma, y como prototipo simplifi-puerto serie se tratase. As´ la definici´n de ı, o cado del sistema SACAR, podemos observarlos paquetes de datos y su gesti´n debemos o en la figura 9.8 el montaje realizado sobre elhacerla nosotros. Los m´dulos XBee unica- o ´ par de plataformas f´ ısicas Arduino.mente nos ofrecen el mecanismo de comu-nicaci´n, de una forma transparente, entre o As´ se presenta un par de dispositivos ıellos. Arduino (A y B), que comparten la misma Finalmente, para completar la funcional- implementaci´n del sistema APAL, adap- oidad del sistema, montaremos un m´dulo o tado con ligeras variantes.GPS que nos permita conocer la posici´n ex- o El dispositivo A realizar´ las funciones aacta de cada dispositivo para poder avisar a de veh´ ıculo especial, en este caso veh´ıculolos dem´s veh´ a ıculos sobre la distancia a la de emergencia, que debe informar al resto deque se encuentra la alerta. veh´ıculos sobre su posici´n y tipo de alerta o Para ello, utilizaremos m´dulos GPS o que est´ emitiendo. Si bien este veh´ a ıculoEM-406A SiRF III [61], compactos, pre- deber´ de moverse en una situaci´n real, ıa ocisos y f´ciles de instalar en nuestra placa nosotros nos limitaremos a fijar su posici´n a oArduino de forma manual en un par de coordenadas geogr´ficas. a Tras la configuraci´n de los diferentes o Por su parte, el dispositivo B cuenta conm´dulos sobre la placa Arduino finalmente un m´dulo GPS que le permite conocer su o oqueda adaptar el algoritmo APAL a las car- posici´n y, por tanto, podr´ determinar a o aacter´ısticas y limitaciones que nos impone qu´ distancia se encuentra de ´l el veh´ e e ıculoeste tipo de sistemas embebidos. de emergencias A. Llegados a este punto, y como objetivo De esta forma, el par de dispositivos es-final de este proyecto de final de carrera, tablece una comunicaci´n inal´mbrica, ha- o arealizaremos una aproximaci´n hacia una ciendo uso del algoritmo adaptado APAL osoluci´n b´sica de Sistema de Alertas en para redifusi´n y control de broadcast storm- o a oCarretera, basado en el algoritmo de control ing, y donde el veh´ ıculo B podr´ estar infor- ade broadcast storming APAL, adaptado, e mado de las alertas que env´ el dispositivo ıeimplementado en el microcontrolador Open A.
  • 13. xii
  • 14. Contents1 OBJETIVOS Y MOTIVACION ´ 1 1.1 Introducci´n . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . 1 1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Requisitos de la soluci´n propuesta . . . . . . . . o . . . . . . . . . . . . . . . 3 1.3.1 Requisitos de la plataforma de simulaci´n o . . . . . . . . . . . . . . . 4 1.3.2 Requisitos de la plataforma de desarrollo . . . . . . . . . . . . . . . 42 ESTADO DEL ARTE 7 2.1 Redes VANETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1 Caracter´ ısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2 Desaf´ . . . . . . . . . . . . . . . . . . . . ıos . . . . . . . . . . . . . . 8 2.2 Tecnolog´ inal´mbricas usadas en redes VANETs ıas a . . . . . . . . . . . . . . 9 2.2.1 Tencolog´ IEEE 802.11 . . . . . . . . . . . ıa . . . . . . . . . . . . . . 9 2.2.2 802.11p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4 UWB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.5 ZigBee - 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Servicios para la seguridad vial . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Mecanismos anti-colisi´n . . . . . . . . . . . o . . . . . . . . . . . . . . 13 2.3.2 Aviso de peligro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 Paso de veh´ ıculos de emergencia . . . . . . . . . . . . . . . . . . . . 143 ZigBee/802.15.4 15 3.1 Introducci´n a ZigBee/802.15.4 . . . . . . . . . o . . . . . . . . . . . . . . . . 15 3.2 Topolog´ . . . . . . . . . . . . . . . . . . . . . ıa . . . . . . . . . . . . . . . . 16 3.2.1 Topolog´ en estrella . . . . . . . . . . . ıa . . . . . . . . . . . . . . . . 16 3.2.2 Topolog´ en malla . . . . . . . . . . . . ıa . . . . . . . . . . . . . . . . 17 3.2.3 Topolog´ en ´rbol . . . . . . . . . . . . ıa a . . . . . . . . . . . . . . . . 17 3.3 Capa F´ısica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4 Capa MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.1 Descripci´n general . . . . . . . . . . . . o . . . . . . . . . . . . . . . . 20 3.4.2 Modos de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . 20 Modo balizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Modo no balizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4.3 Algoritmo CSMA-CA . . . . . . . . . . . . . . . . . . . . . . . . . . 23 CSMA-CA ranurado . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 CSMA-CA no ranurado . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.4 Inicializaci´n y mantenimiento de PAN o . . . . . . . . . . . . . . . . 24 3.4.5 Formato de trama . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Formato general de trama MAC . . . . . . . . . . . . . . . . . . . . 26 Tramas de baliza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Tramas de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 xiii
  • 15. xiv CONTENTS Tramas de ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5 Capa de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5.1 Descripci´n general . . . . . . . . . . . . . . . . . . . . . . . . . . o . . 28 3.5.2 Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Establecer una nueva red . . . . . . . . . . . . . . . . . . . . . . . . 29 Permitir a los dispositivos unirse a una red . . . . . . . . . . . . . . 29 Descubrimiento de red . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Unirse a una red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Tablas de vecindad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Mecanismo distribuido de asignaci´n de direcci´n corta . . . . . o o . . 31 Abandonar una red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5.3 Formato de trama . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.6 Capa de aplicaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o . . 34 3.6.1 Descripci´n general . . . . . . . . . . . . . . . . . . . . . . . . . . o . . 34 3.6.2 Subcapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Subcapa de soporte de aplicaci´n (APS o Application Sublayer ) . o . . 35 Marco de aplicaci´n (AF o Application Framework ) . . . . . . . o . . 35 Objeto de dispositivo ZigBee (ZDO o ZigBee Device Object) . . . . . 36 3.6.3 Formato de trama . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.7 Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 PLATAFORMA DE SIMULACION ´ 41 4.1 Simuladores para VANETs . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 Generadores de tr´fico vehicular . . . . . . . . a . . . . . . . . . . . . . . . . 43 4.2.1 Modelos de tr´fico vehicular . . . . . . . a . . . . . . . . . . . . . . . . 43 4.2.2 Generadores de Movilidad . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.3 Simuladores de redes de comunicaci´n . o . . . . . . . . . . . . . . . . 45 4.3 Simulador de redes OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.1 Simulation for Urban mobility (SUMO) . . . . . . . . . . . . . . . . 49 ¿Por qu´ SUMO? . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . 49 M´s sobre SUMO . . . . . . . . . . . . . a . . . . . . . . . . . . . . . . 49 ´5 NIVEL DE APLICACION - OMNET++ 51 5.1 mi applayer.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 APAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.2.1 Broadcast Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 APAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 ´6 ESPECIFICACION DE ESCENARIOS 75 6.1 NETCONVERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.1.1 Utilizando NETCONVERT . . . . . . . . . . . . . . . . . . . . . . . 76 Edges y Lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 vehicle types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.2 MOVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.3 JTRROUTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.4 Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.4.1 Escenario 1: v´ unica unidireccional . . . . . ıa ´ . . . . . . . . . . . . . 82 6.4.2 Escenario 2: v´ cuadrada unidireccional . . . ıa . . . . . . . . . . . . . 84 6.4.3 Escenario 3: red Manhattan . . . . . . . . . . . . . . . . . . . . . . . 85 6.4.4 Escenario 4: escenario real - Campus Externo UAH y barrio anexo . 89
  • 16. CONTENTS xv ´7 SIMULACION Y RESULTADOS 93 7.1 Simulaci´n en v´ cuadrada . . . . . . . . . . . . . . . . . . . . . . . . . . o ıa . 104 7.1.1 APAL - Tiempo medio de recepci´n de mensaje de alerta (en funci´n o o del n´mero de veh´ u ıculos) . . . . . . . . . . . . . . . . . . . . . . . . 104 7.1.2 APAL - Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´mero de veh´ o u ıculos) . . . . . . 105 7.1.3 APAL - Tiempo medio de recepci´n de mensajes de alerta (en fun- o ci´n de la velocidad) . . . . . . . . . . . . . . . . . . . . . . . . . . o . 106 7.1.4 APAL - Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta (en funci´n de la velocidad) . . . . . . . . . . o . 107 7.2 Simulaci´n - Mapa campus externo UAH . . . . . . . . . . . . . . . . . . o . 108 7.2.1 APAL - Tiempo medio de recepci´n de mensaje de alerta (en funci´n o o del n´mero de veh´ u ıculos) . . . . . . . . . . . . . . . . . . . . . . . . 108 7.2.2 APAL - Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´mero de veh´ o u ıculos) . . . . . . 108 7.2.3 Tiempo medio de recepci´n de mensaje de alerta (en funci´n de la o o velocidad) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.2.4 APAL - Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta (en funci´n de la velocidad) . . . . . . . . . . o . 110 7.2.5 Obst´culos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a . 111 Right Two-Ray Model . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Attenuation per wall and attenuation per meter of penetration ap- proaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Obst´culos en OMNET++ . . . . . . . . . . . . . . . . . . . . . . a . 1158 SEGURIDAD EN REDES VANET BAJO PROTOCOLO 802.15.4 121 8.1 Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 8.2 (IDS) Sistemas de detecci´n de intrusos . . . . . . . . . . . . . . . . . . o . . 123 8.3 Cifrado y firmas digitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Gesti´n de claves en cadena de certificados . . . . . . . . . . . . o . . 125 Gesti´n de claves basada en la movilidad . . . . . . . . . . . . . o . . 125 Autoridades de certificaci´n distribuidas . . . . . . . . . . . . . . o . . 125 Gesti´n paralela de claves . . . . . . . . . . . . . . . . . . . . . . o . . 125 ´ 8.4 SOLUCION ADOPTADA - Autorizaci´n de certificaci´n distribu´ o o ıda . . . . 126 8.4.1 Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Transmisi´n de mensajes . . . . . . . . . . . . . . . . . . . . . . o . . 127 Obtenci´n de un pseud´nimo . . . . . . . . . . . . . . . . . . . . o o . . 127 Broadcast de mensajes veh´ ıculo-a-todos . . . . . . . . . . . . . . . . 128 ´9 IMPLEMENTACION EN ARDUINO 131 9.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 9.1.1 Visi´n general . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . 132 9.1.2 Alimentaci´n . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . 132 9.1.3 Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 9.1.4 Entradas y Salidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 9.1.5 Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.1.6 Programaci´n . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . 135 9.1.7 Reinicio Autom´tico (Software) . . . . . . . . a . . . . . . . . . . . . . 135 9.1.8 Protecci´n contra sobretensiones en USB . . o . . . . . . . . . . . . . 136 9.1.9 Caracter´ısticas F´ısicas . . . . . . . . . . . . . . . . . . . . . . . . . . 136 9.2 Configuraci´n Xbee para Arduino Uno . . . . . . . . o . . . . . . . . . . . . . 136 9.2.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 9.2.2 Configuraci´n XBee XNET 2.5 - peer-to-peer o . . . . . . . . . . . . . 137
  • 17. xvi CONTENTS Paso 1. Conexi´n del XBee al xplorer y preparaci´n del software o o . . 138 Paso 2. Ejecutar X-CTU y conectar con XBee . . . . . . . . . . . . 138 9.2.3 Actualizaci´n de firmware . . . . . . . . . . . . . . . . . . . . . . o . . 138 9.2.4 Probando comunicaci´n entre los m´dulos XBee . . . . . . . . . o o . . 141 9.3 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 9.3.1 Instalaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o . . 142 9.4 Sistema de alertas en carretera - APAL - b´sico . . . . . . . . . . . . . . a . . 144 9.4.1 Algoritmo APAL adaptado . . . . . . . . . . . . . . . . . . . . . . . 14610 CONCLUSIONES 15311 TRABAJO FUTURO 155BIBLIOGRAF´ IA 157
  • 18. Lista de Figuras 2.1 Problema del terminal escondido . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 Pila de protocolos ZigBee/802.15.4 . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Topolog´ de red . . . . . . . . . . . . . . . . . . . . . . . . . . . ıas . . . . . . 17 3.3 Canales radio 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4 PDU (Protocol Data Unit ) de nivel f´ ısico o PPDU. . . . . . . . . . . . . . 19 3.5 Tratamiento de la PPDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.6 Estructura de supertrama. Fuente: [15] . . . . . . . . . . . . . . . . . . . . 22 3.7 Diagrama de bloques del algoritmo CSMA-CA. . . . . . . . . . . . . . . . . 25 3.8 Formato general de trama MAC . . . . . . . . . . . . . . . . . . . . . . . . 26 3.9 Trama de baliza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.10 Trama de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.11 Trama de ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.12 Ejemplo de red mostrando el Cskip(d) y las direcciones de red . . . . . . . . 33 3.13 Formato general de trama de red . . . . . . . . . . . . . . . . . . . . . . . . 33 3.14 Capa de aplicaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . o . . . . . . 34 3.15 Formato general de trama de aplicaci´n . . . . . . . . . . . . . . o . . . . . . 36 3.16 Formato de trama con seguridad habilitada - Capa MAC . . . . . . . . . . 38 3.17 Formato de trama con seguridad habilitada - Capa de red . . . . . . . . . . 38 3.18 Formato de trama con seguridad habilitada - Capa de aplicaci´n o . . . . . . 38 4.1 Relaci´n de aplicaciones de simulaci´n para VANETs . . . . . . . . . . . . . 42 o o 4.2 Estructura modular de los modelos de OMNeT++. . . . . . . . . . . . . . . 48 5.1 Pila de protocolo 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.2 Estructura interna componente ieee802154 . . . . . . . . . . . . . . . . . . . 52 5.3 Estructura interna componente ieee802154 . . . . . . . . . . . . . . . . . . . 53 5.4 Componente gr´fico IEEE 802.15.4 . . . . . a . . . . . . . . . . . . . . . . . . 54 5.5 Estructura interna componenete ieee802154 . . . . . . . . . . . . . . . . . . 54 5.6 Pila de protocolo 802.15.4 en OMNET++ . . . . . . . . . . . . . . . . . . . 55 5.7 Estructura de la capa de aplicaci´n creada . o . . . . . . . . . . . . . . . . . . 62 5.8 Ejecuci´n de la simulaci´n . . . . . . . . . . o o . . . . . . . . . . . . . . . . . . 63 5.9 APAL OMNET++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.1 Esquema v´ unica unidireccional - SUMO ıa ´ . . . . . . . . . . . . . . . . . . . 77 6.2 V´ unica unidireccional - SUMO . . . . . ıa ´ . . . . . . . . . . . . . . . . . . . 80 6.3 Pantalla principal MOVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.4 V´ unica unidireccional . . . . . . . . . . ıa ´ . . . . . . . . . . . . . . . . . . . 83 6.5 V´ cuadrada unidireccional . . . . . . . . ıa . . . . . . . . . . . . . . . . . . . 85 6.6 Mapa de Manhattan - 1807 . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.7 Esquema rejilla manhattan . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.8 MOVE - Generaci´n de escenarios . . . . o . . . . . . . . . . . . . . . . . . . 87 xvii
  • 19. xviii LISTA DE FIGURAS 6.9 MOVE - Generaci´n aleatoria de escenarios . . . . . . . . . . . . . . . . . . o 88 6.10 MOVE - Configuraci´n de par´metros - Generaci´n aleatoria de escenarios o a o 89 6.11 Escenario generado operativo en SUMO . . . . . . . . . . . . . . . . . . . . 90 6.12 Campus externo y barrio anexo de la Universidad de Alcal´ de Henares . . a 90 6.13 Exportando datos de OpenStreetMap . . . . . . . . . . . . . . . . . . . . . 91 6.14 Escenario final del campus externo UAH en SUMO . . . . . . . . . . . . . . 91 7.1 Componentes b´sicos en una simulaci´n SUMO-OMNET . . . . . . . . . . a o 93 7.2 Manager controlador en OMNET . . . . . . . . . . . . . . . . . . . . . . . . 94 7.3 Componente ”car” en OMNET . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.4 Componentes b´sicos + observador en OMNET . . . . . . . . . . . . . . . . a 95 7.5 Escenario v´ cuadrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ıa 97 7.6 Diagrama de flujo del observador . . . . . . . . . . . . . . . . . . . . . . . . 98 7.7 Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o u veh´ıculos) - broadcast simple - NO APAL . . . . . . . . . . . . . . . . . . . 100 7.8 Diagrama de flujo del observador . . . . . . . . . . . . . . . . . . . . . . . . 101 7.9 Estructura del vector de registro de datos de veh´ ıculos . . . . . . . . . . . . 101 7.10 Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´mero de veh´ o u ıculos) - broadcast simple - NO APAL 103 7.11 Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o u veh´ıculos) - broadcast APAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.12 Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´mero de veh´ o u ıculos) - broadcast APAL . . . . . . . . 107 7.13 Tiempo medio de recepci´n de mensajes de alerta (en funci´n de la veloci- o o dad) broadcast APAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7.14 Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta (en funci´n de la velocidad) broadcast APAL . . . . . . . . . . . . . . o 109 7.15 Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o u veh´ıculos) en mapa urbano UAH - broadcast APAL . . . . . . . . . . . . . 110 7.16 Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´mero de veh´ o u ıculos) en mapa urbano UAH - broadcast APAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.17 Tiempo medio de recepci´n de mensajes de alerta (en funci´n de la veloci- o o dad) en mapa urbano UAH - broadcast APAL . . . . . . . . . . . . . . . . . 113 7.18 Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta (en funci´n de la velocidad) en mapa urbano UAH - broadcast APAL o 114 7.19 Right Two Ray Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.20 Movimiento de veh´ ıculo para la comprobaci´n de atenuaci´n . . . . . . . . o o 115 7.21 Proyecto Veins - Simulaci´n de obst´culos . . . . . . . . . . . . . . . . . . . o a 115 7.22 Estadistica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.23 Matriz grid Manhattan de obst´culos . . . . . . . . . . . . . . . . . . . . . . a 117 7.24 Tiempo medio de recepci´n de mensajes con y sin obst´culos . . . . . . . . o a 118 7.25 N´mero de veh´ u ıculos ciegos con y sin obst´culos . . . . . . . . . . . . . . . a 119 7.26 Tiempo medio de recepci´n de mensajes con y sin obst´culos en funci´n de o a o la velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.27 N´mero de veh´ u ıculos ciegos con y sin obst´culos en funci´n de la velocidad a o 120 8.1 Requisitos a cumplir en seguridad de la informaci´no . . . . . . . . . . . . . 122 8.2 Nuevo pseud´nimo . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . 128 8.3 Mensaje cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 8.4 Trama hello beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 9.1 Arduino Uno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 9.2 XBee ZNET 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
  • 20. LISTA DE FIGURAS xix 9.3 XBee explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 9.4 X-CTU Pantalla principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 9.5 X-CTU Pantalla selecci´n de firmware . o . . . . . . . . . . . . . . . . . . . . 140 9.6 GPS EM-406A SiRF III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 9.7 Esquema de instalaci´n GPS en Arduino o . . . . . . . . . . . . . . . . . . . 143 9.8 SACAR simplificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 9.9 APAL - SACAR adaptado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
  • 21. xx LISTA DE FIGURAS
  • 22. Lista de Tablas 3.1 Caracter´ ısticas de las frecuencias 802.15.4 . . . . . . . . . . . . . . . . . . . 18 3.2 Ejemplo de tama˜o de subgrupos de direcciones . . . . . . . . . . . . . . . . 32 n 7.1 Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o u veh´ıculos) - broadcast simple - NO APAL . . . . . . . . . . . . . . . . . . . 100 7.2 Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´mero de veh´ o u ıculos) - broadcast simple - NO APAL 102 7.3 Par´metros de simulaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . a o 104 7.4 Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o u veh´ıculos) - broadcast APAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.5 Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´mero de veh´ o u ıculos) - broadcast APAL . . . . . . . . 106 7.6 Tiempo medio de recepci´n de mensajes de alerta (en funci´n de la veloci- o o dad) broadcast APAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.7 Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta (en funci´n de la velocidad) broadcast APAL . . . . . . . . . . . . . . o 107 7.8 Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o u veh´ıculos) en mapa urbano UAH - broadcast APAL . . . . . . . . . . . . . 109 7.9 Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´mero de veh´ o u ıculos) en mapa urbano UAH - broadcast APAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.10 Tiempo medio de recepci´n de mensajes de alerta (en funci´n de la veloci- o o dad) en mapa urbano UAH - broadcast APAL . . . . . . . . . . . . . . . . . 111 7.11 Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta (en funci´n de la velocidad) en mapa urbano UAH - broadcast APAL o 112 7.12 Tiempo medio de recepci´n de mensajes con y sin obst´culos . . . . . . . . o a 117 7.13 N´mero de veh´ u ıculos ciegos con y sin obst´culos . . . . . . . . . . . . . . . a 118 7.14 Tiempo medio de recepci´n de mensajes con y sin obst´culos en funci´n de o a o la velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.15 N´mero de veh´ u ıculos ciegos con y sin obst´culos en funci´n de la velocidad a o 120 9.1 Microcontrolador ATmega328 . . . . . . . . . . . . . . . . . . . . . . . . . . 133 xxi
  • 23. xxii LISTA DE TABLAS
  • 24. Chapter 1 ´OBJETIVOS Y MOTIVACION1.1 Introducci´n o Hace algo mas de 200 a˜os, en 1771, un ingeniero militar franc´s, Cugnot, cre´ el n e oprimer autom´vil de la historia movido por tracci´n mec´nica [1]. A partir de entonces, y o o agracias al proceso de fabricaci´n en serie que Henry Ford aplic´ en la construcci´n de su o o oautom´vil, el Ford T, el n´mero de coches en circulaci´n ha crecido espectacularmente en o u otodo el mundo, alcanzando los 800 millones de veh´ ıculos en la actualidad. Esta cifra, que en un principio nos hace pensar en un progreso positivo del ser humano,favoreciendo la movilidad, comunicaci´n y productividad, tiene tambi´n su lado negativo, o ey es el n´mero de accidentes de tr´fico que cada a˜o se cobran la vida de miles de personas. u a nEn este sentido, si observamos la evoluci´n del n´mero de accientes de tr´fico en la Uni´n o u a oEuropea, vemos como en el a˜o 1995 fueron aproximadamente unos 65.000, mientras que nen el a˜o 2006, se sit´an por debajo de los 50.000 [2]. n u Vemos por tanto como hay una tendencia a la baja, a pesar de que el n´mero de uveh´ıculos creci´ en el mismo per´ o ıodo. Este hecho se debe, principalmente, a las continuasmejoras en la calidad de los trazados, en la educaci´n vial del ciudadano y en la seguridad ode los veh´ıculos. Cabe destacar la importancia que ha tenido el desarrollo de este ultimo aspecto, la se- ´guridad en los veh´ıculos. As´ la agencia norteamericana de seguridad, National Highway ı,Traffic Safety Administration, ha estimado que, en el per´ ıodo 1975-1999, han podido sal-varse 123.000 vidas gracias al uso del cintur´n, y que, gracias al uso del airbag, se habr´ o ıansalvado en el per´ ıodo 1987-2001, 7200 vidas. Estos dos dispositivos mencionados anteriormente se enmarcan dentro de los elementosde seguridad pasivos, pues realizan su funci´n tras producirse el accidente. Si nos fijamos oen los elementos de seguridad activos (entre ellos se encontrar´ los frenos), podemos ıan 1
  • 25. 2 ´ CHAPTER 1. OBJETIVOS Y MOTIVACIONdestacar c´mo la introducci´n en los veh´ o o ıculos del ESP (Electronic Stability Program),logr´ reducir la gravedad de las heridas severas de un accidente en un 21œ[3]. Parecen ser, opor lo tanto, razones suficientes para continuar en el empe˜o de mejorar los dispositivos nde seguridad, aprovechando las ventajas que nos ofrece la tecnolog´ ıa. En este sentido, los veh´ıculos han ido mejor´ndose d´ a d´ hasta el punto de lograr a ıa ıauna inteligencia muy particular, gracias a la inclusi´n de electr´nica y sensores como par o ofundamental en la fabricaci´n actual de veh´ o ıculos. Sin embargo, la percepci´n que el oveh´ ıculo tiene del exterior mediante estos sensores esta limitada, y podr´ ıamos hablar deuna percepci´n local, que se extender´ pocos metros a su alrededor (incluir´ o ıa ıamos en estepunto los sensores mas avanzados como son los sistemas de control de crucero basados enradares de corto alcance). Parece ser, por tanto, un l´ ımite real que habr´ que cruzar, ıaotorgando un mayor campo de visi´n al veh´ o ıculo para potenciar esa inteligencia. En 1997, el Centro Europeo para la Estandarizaci´n (CEN), adopt´ un nuevo est´ndar o o ade comunicaci´n bajo el protocolo TC 278 (ISO TC 204), llamado DSRC (Dedicated Short- oRange Communication) [4]. Gracias a este nuevo protocolo, desarrollado expresamentepara el intercambio de informaci´n entre los distintos medios de transporte, podr´ o ıamosestablecer comunicaciones de hasta 1km de distancia, permitiendo as´ el intercambio de ıinformaci´n entre los veh´ o ıculos que se encontraran dentro de ese radio de acci´n. o En 2005 esta tecnolog´ fue aprovechada por General Motors para desarrollar su sis- ıatema v2v que permit´ la comunicaci´n entre veh´ ıa o ıculos (de forma similar a como se inter-cambia informaci´n en redes p2p), para as´ ”montar” una red din´mica en carretera que o ı atransmite informaci´n relevante en cuanto al estado de la v´ y situaciones peligrosas en la o ıacirculaci´n. La idea era crear una red de comunicaci´n ”al vuelo” cuyos nodos fueran los o opropios veh´ıculos, que generase el contenido necesario para la prevenci´n de incidentes o oaccidentes, y que no dependiera de fuentes de informaci´n externa a la red, como pudiera oser Internet (o si as´ fuera, que dependiera m´ ı ınimamente). Y si bien todo apunta a que el d´ de ma˜ana cualquier equipo medianamente in- ıa nteligente tendr´ conectividad directa a Internet, en determinados escenarios, donde esta apremisa puede no estar garantizada, puede resultar necesaria la existencia de un sistemade apoyo que nos aporte cobertura o minimice latencias hacia servidores centrales en de-terminados escenarios aislados. Visto esto, ¿qu´ aplicaciones pr´cticas podr´ desarrollarse? Sabemos que en caso de e a ıanaccidente en una autovia, ´sta se colapsa y las retenciones pueden provocar aparatosos y epeligrosos alcances que podrian evitarse con este sistema. Adem´s, podriamos facilitar el apaso de ambulancias y vehiculos de emergencia al conocer su posicion. Podriamos inclusoevitar la retencion, tomando una ruta alternativa que, ademas, facilitaria la descongestionde la misma. Pero no s´lo ser´ util en este tipo de v´ o ıa ´ ıas. En carreteras interurbanasy urbanas podr´ evitarse colisiones en cruces y adelantamientos, pues el sistema seria ıancapaz de advertirnos de la presencia de otro autom´vil dirigiendose hacia un punto de ocruce en nuestra trayectoria.
  • 26. 1.2. OBJETIVOS 31.2 Objetivos El proyecto de estandarizaci´n del IEEE basado en el protocolo 802.11p, bajo el nombre ode DSRC (Dedicated Short Range Communications), cuyo objetivo es crear en EstadosUnidos una red nacional de comunicaciones que permita el intercambio de informaci´n oentre veh´ ıculos y la infraestructura viaria, nos ofrece una idea de la importancia que est´acobrando a d´ de hoy la implantaci´n de un sistema de comunicaci´n est´ndar entre ıa o o aveh´ ıculos. Se pretende que DSRC sea un complemento a las redes de m´viles al proveer de ve- olocidades de transferencia muy altas en circunstancias en las que es importante minimizarla latencia del enlace de comunicaciones en zonas relativamente peque˜as. Se pretende nasimismo que la red pueda ser extendida a todo el territorio norteamericano, que funcionecon cualquier condici´n meteorol´gica y que se pueda operar con 100 o m´s veh´ o o a ıculos encada zona. Bajo estas condiciones, resulta obvio que el desarrollo de un sistema de estas carac-ter´ ısticas es complejo y debe llevar asociado un proceso de investigaci´n y an´lisis que o apermita contemplar situaciones o casu´ısticas posibles previas a la implantaci´n final en un oescenario donde la seguridad tiene un peso muy importante. Por otro lado, dado que la tecnolog´ DSRC es cara, y dado que debe realizarse el pro- ıaceso de an´lisis e investigaci´n anteriormente mencionado, dividiremos el presente proyecto a oen dos puntos diferenciables. Por un lado realizaremos un estudio previo que comprender´ ael an´lisis de las diferentes alternativas de comunicaci´n para redes VANETs, as´ como a o ıla realizaci´n de diferentes simulaciones sobre diferentes escenarios empleando uno de los oprotocolos de comunicaci´n sobre el que centramos este trabajo, el protocolo 802.15.4. oEl empleo de este protocolo nos permitir´ establecer una comunicaci´n similar a la que a oofrece DSRC pero empleando dispositivos de bajo coste. As´ el segundo de los puntos se ı,centra en la implementaci´n de las diferentes soluciones estudiadas en dispositivos ”open ohardware”. Entre estos dispositivos se encuentra la plataforma de desarrollo Arduino [5]que facilita la creaci´n de sistemas interactivos a trav´s de sus m´ltiples m´dulos compat- o e u oibles. Entre ellos, m´dulos de comunicaci´n Xbee (802.15.4) o m´dulos de geolocalizaci´n o o o o(GPS), permitir´n disponer de un sistema muy parecido al caro DSRC y poner a prueba anuestras simulaciones.1.3 Requisitos de la soluci´n propuesta o Al enfrentarnos a un determinado problema, este puede ser abordado de m´ltiples uformas, y pueden utilizarse diferentes t´cnicas para resolverlo. En nuestro caso particular, elas diferentes opciones existentes para realizar las simulaciones as´ como las m´ltiples ı uplataformas de desarrollo basadas en microcontroladores nos devuelven un amplio abanicoque debemos restringir imponiendo una serie de requisitos.
  • 27. 4 ´ CHAPTER 1. OBJETIVOS Y MOTIVACION1.3.1 Requisitos de la plataforma de simulaci´n o Para cumplir de manera satisfactoria los requisitos de este proyecto las plataformas desimulaci´n deben presentar caracter´ o ısticas espec´ ıficas. Estos requisitos son: ˆ Cada una de las aplicaciones que componen las herramientas de simulaci´n, o paque- o tes a˜adidos necesarios para realizar nuestras pruebas, deben ser de libre distribu- n ci´n y c´digo abierto. Estos requisitos permiten, por un lado, liberarnos de licencias o o propietarias que suelen ser caras para herramientas muy t´cnicas y espec´ e ıficas. Por otro lado, el hecho de liberar el c´digo y ponerlo a disposici´n de los desarrolladores, o o permite el acceso al mismo, su modificaci´n y adaptaci´n a necesidades concretas y o o particulares. Adem´s, favorecen la creaci´n de comunidades de desarrollo que suelen a o mantener un grupo abierto o foro de apoyo a dicha comunidad. ˆ Ser´ necesario disponer de una implementaci´n del protocolo de comunicaci´n elegido a o o en la herramienta de simulaci´n. Este requisito nos permite centrarnos en la soluci´n o o de alto nivel y dejar de lado la implementaci´n de bajo nivel del protocolo. o ˆ Otro requisito imprescindible, asociado a la herramienta de simulaci´n de tr´fico de o a veh´ıculos, ser´ el disponer de m´dulos o herramientas que permitan la creaci´n de a o o diferentes escenarios de una forma simple y r´pida. Esto incluye la creaci´n de v´ a o ıas de circulaci´n con topolog´ variadas, y rutas de movimiento flexibles y adaptables o ıas basadas en patrones o definiciones concretas. ˆ Tras una determinada simulaci´n, cabr´ esperar poder obtener una serie de con- o ıa clusiones asociadas a dicha ejecuci´n. Por ello, otro de los requisitos que deber´ o ıa cumplir tanto la herramienta de simulaci´n de tr´fico de veh´ o a ıculos, como la her- ramienta de simulaci´n de redes, ser´ disponer de diferentes indicadores, variables o ıa para estad´ısticas o trazas depurables. ˆ A partir de los indicadores o de las trazas obtenidas ser´ necesario disponer de una a herramienta que permita representar de forma gr´fica los valores de los indicadores. a ˆ Si bien la simulaci´n del tr´fico de veh´ o a ıculos y la simulaci´n de la red de datos a trav´s o e de las respectivas herramientas puede realizarse mediante la utilizaci´n de consolas o de ´rdenes, es interesante que ambas aplicaciones dispongan de motores de animaci´n o o gr´ficos para permitir un seguimiento mucho m´s intuitivo del comportamiento tanto a a de veh´ıculos como de paquetes de datos en el escenario. Esto permite muchas veces realizar una depuraci´n m´s fina, basada en lo que uno espera que haga la red y en o a lo que realmente realiza ´sta. e1.3.2 Requisitos de la plataforma de desarrollo De la misma forma, la selecci´n de una determinada plataforma de desarrollo deber´ o ıacumplir otra serie de requisitos, entre los que podemos encontrar los siguientes: ˆ Hemos visto como la selecci´n de herramientas de simulaci´n que sean de libre dis- o o tribuci´n y c´digo abierto permiten ahorrar costes y beneficiarnos del apoyo de una o o
  • 28. ´1.3. REQUISITOS DE LA SOLUCION PROPUESTA 5 comunidad de desarrollo y posibilidad de modificaci´n y adaptaci´n. De la misma o o forma, la plataforma de desarrollo deber´ cumplir ambos requisitos. Si bien para ıa entornos hardware esto no es aplicable al cien por cien, s´ existe el concepto ”open ı hardware” libre de patentes o licencias caras. Tendremos en cuenta dichos requisitos a la hora de seleccionar la plataforma de desarrollo. ˆ Dado que el objetivo tras la realizaci´n de las simulaciones ser´ trasladarlas a un o a escenario real, en el cual se ponga de manifiesto parte de los resultados en ellas obtenidos, deber´n mantenerse diferentes elementos en ellas utilizados, como pueden a ser los protocolos de comunicaci´n, las condiciones de las simulaciones... Para ello, o deber´n seleccionarse diferentes m´dulos, como pudieran ser dispositivos de comuni- a o caci´n que utilicen los mismos protocolos, m´dulos de geolocalizaci´n, ... todos ellos o o o compatibles con la plataforma de desarrollo elegida.
  • 29. 6 ´ CHAPTER 1. OBJETIVOS Y MOTIVACION
  • 30. Chapter 2ESTADO DEL ARTE En el siguiente cap´ ıtulo realizaremos una aproximaci´n a las redes VANETs en la oque abordaremos tanto su definici´n como los diferentes aspectos que las caracterizan. oComo en cualquier modelo de comunicaci´n se nos presentar´n determinadas dificultades o ao desaf´ que deben ser resueltos. No obstante, muchos de ellos ya han sido solventados ıosy tratados mediante el empleo de protocolos y tecnolog´ apropiadas. En este apartado ıastambi´n trataremos algunas de estas dificultades y las opciones que se nos presentan para ela construcci´n de redes VANETs. o2.1 Redes VANETS Las redes VANET (Vehicular Ad-Hoc Networks) son un tipo de infraestructura de co-municaci´n basada en las redes ad-hoc para dispositivos m´viles (Mobile Ad-Hoc Network o o(MANET)), y destinadas al uso en veh´ ıculos. Este tipo de tecnolog´ permite considerar ıacada veh´ıculo como un nodo activo en la red que, de forma conjunta con sus adyacentes,interconecta nodos m´s lejanos, levantando una infraestructura din´mica de comunicaci´n a a orelativamente grande sin apoyo de infraestructura de red fija.2.1.1 Caracter´ ısticas Detallemos a continuaci´n ciertas caracter´ o ısticas de este tipo de redes: ˆ Autonom´ Una de las caracter´ ıa. ısticas que definen a este tipo de redes es la ca- pacidad de adaptaci´n y dinamismo debido a la autonom´ que presentan sus nodos. o ıa Cada uno de ellos es capaz de procesar de forma independiente la informaci´n que o recibe y aporta la funcionalidad necesaria para mantener una infraestructura de red 7
  • 31. 8 CHAPTER 2. ESTADO DEL ARTE capaz de distribuir dicha informaci´n sin la implicaci´n de elementos externos no o o aut´nomos. o ˆ Encaminamiento distribuido. Una vez procesada la informaci´n en cada nodo, o ´sta debe volcarse a la red teniendo en cuenta las particularidades que definen su e infraestructura y realizar encaminamientos adecuados para llegar a los destinos ob- jetivo. ˆ Topolog´ de red variable. Si bien, como hemos comentado anteriormente, las ıa redes VANET se basan en muchos aspectos en las redes MANET, en relaci´n a la o topolog´ de red hay que matizar ciertos puntos que las hacen diferentes. As´ en ıa ı, las redes MANET el comportamiento de los elementos m´viles es diferente al que o presentan los nodos en las redes VANET, que suelen seguir patrones de movimiento lineales a trav´s de mapas urbanos, y presentan velocidades muy altas con variaciones e muy irregulares en sus direcciones, aspectos estos que pueden generar p´rdidas en e paquetes de datos. ˆ Capacidad variable de los enlaces. Esta caracter´ ıstica tiene cabida en todas las comunicaciones inal´mbricas, pues es intr´ a ınseca al medio de transmisi´n pero sus o efectos se agravan m´s en las VANETs. Esto se debe a que cada nodo act´a como a u router y la informaci´n atreviesa m´ltiples enlaces inal´mbricos. o u a ˆ Terminales limitados. En la mayor´ de los casos los nodos de este tipo de re- ıa des ser´n terminales ligeros embarcados en veh´ a ıculos con capacidades limitadas de procesamiento y comunicaci´n, por lo que es primordial que los algoritmos utilizados o optimicen estos recursos.2.1.2 Desaf´ ıos Cuando surge una nueva soluci´n tecnol´gica con un cierto grado de complejidad y o ogran alcance, como es el caso de las redes MANET, y en particular las redes VANET,se presentan a la comunidad cient´ ıfica una serie de desaf´ y problemas que deben ser ıosestudiados y resueltos. A continuaci´n mostramos algunos de los desaf´ que quedan o ıosabiertos como l´ ıneas de investigaci´n. o ˆ Encaminamiento. Una de las caracter´ ısticas principales de las redes VANET es la volatilidad y continua movilidad que experimentan los elementos que la compo- nen, traduci´ndose estas circunstancias en una topolog´ de red muy variable. Esto e ıa implica disponer de m´todos de encaminamiento adaptativos, que realicen reconfig- e uraciones en las tablas de encaminamiento de cada nodo de forma ´gil. a ˆ Seguridad. Cuando trabajamos con sistemas de comunicaci´n debemos tener en o cuenta que la informaci´n que se transmite viajar´ a trav´s de un canal de comu- o a e nicaci´n que puede ser vulnerable a escuchas o modificaciones externas. Si adem´s, o a el medio elegido para transportar dicha informaci´n es inal´mbrico, el problema se o a agrava, pues cualquier intruso puede escuchar directamente, sin necesidad de acceder f´ ısicamente al canal de comunicaci´n, y todav´ m´s en las redes VANET, que no o ıa a disponen de una infraestructura central que gestione aspectos de seguridad como au- tenticaci´n o cifrado. Este campo se presenta, por lo tanto, disponible a investigaci´n o o y an´lisis futuro. a
  • 32. 2.2. TECNOLOG´ ´ IAS INALAMBRICAS USADAS EN REDES VANETS 9 ˆ Calidad de servicio (QoS). La calidad de servicio en redes cableadas se pro- porciona mediante mecanismos de reserva de recursos. Sin embargo, la reserva de recursos se complica con la variabilidad de la topolog´ de las VANETs. Adem´s ıa a ninguna red puede prescendir de QoS ya que las aplicaciones de tiempo real como la videoconferencia o el videostreaming exigen un nivel alto de QoS. Actualmente exis- ten propuestas, sin embargo muchas de ellas son te´ricas, simuladas o implementadas o con pocos nodos, y ninguna de ella aporta una soluci´n definitiva. o ˆ Consumo de potencia. Hemos destacado previamente el car´cter ligero de muchos a terminales de la red, por lo cual es importante optimizar los procesos de comunicaci´n o y procesamiento para garantizar un bajo consumo de energ´ Este recurso depende ıa. mucho de la tecnolog´ usada. ıa2.2 Tecnolog´ inal´mbricas usadas en redes VANETs ıas a En este apartado se detallan tecnolog´ inal´mbricas susceptibles de dar soporte a ıas aredes VANETs.2.2.1 Tencolog´ IEEE 802.11 ıa La creaci´n de los est´ndares que han dado lugar al Wi-Fi, bajo el nombre IEEE 802.11 o a[13], es una tarea llevada a cabo por el International Electrical and Electronic Engineers(Asociaci´n Internacional de Ingenieros Electr´nicos y de Telecomunicaciones), conocido o opor las siglas IEEE. De manera purista vale decir que el acr´nimo Wi-Fi se utiliza para identificar los oproductos que incorporan cualquier variaci´n de la tecnolog´ inal´mbrica de los est´ndares o ıa a aIEEE 802.11, que permiten la creaci´n de redes de ´rea local sin hilos conocidas como o aWLAN, y que son plenamente compatibles con los de cualquier otro fabricante que utiliceestos est´ndares. a Las caracter´ ısticas generales de funcionamiento de una red Wi-Fi son las mismas quelas de una red cableada. La particularidad es que el Wi-Fi utiliza el espacio como mediode transmisi´n. o Los componentes b´sicos de una red Wi-Fi son: a ˆ El punto de acceso (AP): es la uni´n entre las redes cableadas y la red WiFi, o entre o diversas zonas cubiertas por redes Wi-Fi, que act´a entonces como repetidor de la u se˜al entre estas zonas (celdas). n ˆ Una o m´s antenas conectadas al punto de acceso. a
  • 33. 10 CHAPTER 2. ESTADO DEL ARTE ˆ Un terminal Wi-Fi. Este puede tener forma de dispositivo externo Wi-Fi, que se ´ instala en el PC del usuario, o bien puede encontrarse ya integrado, como sucede habitualmente con los ordenadores port´tiles. Adicionalmente se pueden encontrar a otros terminales con capacidad de comunicaci´n, como agendas electr´nicas (PDA) o o y tel´fonos m´viles, que disponen de accesorios (internos o externos) para conectarse e o a redes Wi-Fi. Independientemente de la banda de frecuencia en que trabajan, todos los est´ndares ade la subfamilia 802.11 comparten algunas limitaciones que es conveniente conocer antesde tomar una decisi´n sobre coberturas, alcance o velocidades que se pueden cubrir. Estas olimitaciones son cinco: ˆ Alcance Aunque comercialmente se habla t´ ıpicamente de un alcance de hasta 100 metros, este dato depende, en primer lugar, de la ubicaci´n y de la presencia de o obst´culos en el camino entre el punto de acceso y el terminal, y en segundo lugar, a de las condiciones meteorol´gicas y de las interferencias. As´ en espacio abierto, o ı, con buenas condiciones meteorol´gicas y antenas exteriores de los terminales, este o alcance puede ser bastante superior. Sin embargo, en el interior de un edificio, donde las paredes representan un obst´culo muy importante, la distancia ser´ notablemente a a inferior. Asimismo, si hay otros redes Wi-Fi pr´ximas, o sencillamente otras fuentes o de interferencias, es tambi´n muy probable que las distancias disminuyan. e ˆ Anchura de banda Nominalmente, los diferentes est´ndares pueden alcanzar, f´ a ısi- camente (es decir, en el canal a´reo, descontando cualquier ineficiencia que puedan e introducir los protocolos superiores), velocidades bastante altas. Ahora bien, a causa del efecto de los protocolos necesarios para transportar la informaci´n de usuario so- o bre el canal a´reo, la velocidad util es mucho menor. Adem´s, en funci´n de las e ´ a o condiciones del entorno y, por lo tanto, de la calidad de cada comunicaci´n entre un o terminal y el punto de acceso, la anchura de lado de esta comunicaci´n se adapta, o con el fin de utilizar codificaciones m´s robustas ante interferencias y/o errores. Es a por eso que a veces nos encontremos con una conexi´n con el punto de acceso de 11 o Mbps, otros en 5 Mbps, en 2 Mbps o, incluso, en 1 Mbps. ˆ Calidad de servicio No todo el tr´fico tiene la misma importancia desde el punto de a vista de cada usuario. As´ se puede considerar que una llamada de VoIP tendr´ que ı, ıa tener prioridad sobre una transferencia de ficheros. Los protocolos m´s extendidos a de Wi-Fi, como b y gr, no incluyen ning´n mecanismo para priorizar un tipo de u tr´fico sobre uno otro, lo cual resulta muy perjudicial cuando se mezclan flujos de a tr´fico con requerimientos muy diferentes, como voz y datos. La consecuencia es que a Wi-Fi es poco adecuado para transportar tr´fico exigente en t´rminos de calidad, a e como VoIP, no tanto para que no funcione adecuadamente, como porque no se puede garantizar cu´ndo y en qu´ condiciones funcionar´. a e a ˆ Seguridad En un principio, las redes Wi-Fi no presentaban mecanismos de seguri- dad muy sofisticados, ya que el ´nfasis se puso en c´mo transmitir datos sobre el e o aire, que era un desaf´ tecnol´gico m´s urgente. Con el ´xito de esta tecnolog´ ıo o a e ıa, sin embargo, y la publicaci´n de las debilidades de los mecanismos de seguridad o originales, se hizo necesario introducir mejoras en este aspecto. De hecho, la falta de seguridad de ´stas redes es un punto en contra a favor de sus detractores. No e obstante, nuevas mejoras, como la que introduce 802.11i, resuelve la mayor´ de las ıa debilidades originales, hasta el punto de hacerlas comparables en seguridad en las redes fijas.
  • 34. 2.2. TECNOLOG´ ´ IAS INALAMBRICAS USADAS EN REDES VANETS 11 ˆ Movilidad Popularmente, se considera que las redes Wi-Fi son m´viles, ya que no o hay que conectarse desde una ubicaci´n fija para acceder a los servicios que nos o ofrece, y adem´s se puede ir caminando y navegando por Internet o leyendo el correo a electr´nico al mismo tiempo. Estrictamente hablando, eso se considera itinerancia, o y no movilidad. De hecho, no es posible utilizar una red Wi-Fi desde un veh´ ıculo en movimiento a velocidad normal, por razones f´ısicas asociadas a la velocidad. Adem´s, a 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 a o con otro punto de acceso, la cual cosa implica ”saltar” del uno al otro. Tambi´n e en este aspecto el est´ndar presenta deficiencias que pueden hacer que perdamos a brevemente la conexi´n e incluso hayamos de volver a conectarnos manualmente. o Para compensar ambas restricciones, est´n desarrollando nuevos est´ndares, y es de a a esperar que pronto se dispondr´ de productos en el mercado. a2.2.2 802.11p Tambi´n conocida como Wireless Access for the Vehicular Environment (WAVE), est´ e aen proceso de estandarizaci´n y ser´ la encargada en un futuro de soportar las comunica- o aciones vehiculares. WAVE es una evoluci´n del est´ndar IEEE 802.11a con modificaciones o aa nivel f´ ısico y MAC para mejorar su comportamiento en el entorno vehicular y dar soportea sistemas de transporte inteligente (Itelligent Transportation Systems (ITS)). Asimismo,WAVE es la base sobre la que se desarrolla el DSRC (Dedicated Short Range Commu-nications), otro proyecto de estandarizaci´n impulsado por el ministerio de transporte ode EE UU y por un n´mero importante de fabricantes de la industria del autom´vil, u ocuyo objetivo es crear una red nacional de comunicaciones vehiculares. El prop´sito del oproyecto es definir un est´ndar para las comunicaciones V2V y las comunicaciones con la ainfraestructura vial (V2I) que se puede instalar en sem´foros o paneles de informaci´n, a opor ejemplo. WAVE pretende aumentar las tasas de trasferencia a corto alcance, tipicamente entre100 y 500m. La t´cnica de modulaci´n se basa en IEEE802.11a, utilizando OFDM pero e ocon tasas de transmisi´n de 3, 4.5, 6, 9, 12, 18, 24 y 27 Mbps en canales de 10MHz. Utiliza o52 sub-portadoras moduladas utilizando BPSK, QPSK, 16-QAM, o 64-QAM. En cuanto a la canalizaci´n, la norma define 7 canales no solapados de 10MHz en la obanda de 5.9 GHz: 6 canales de servicio (SCH) y uno de control (CCH). El CCH est´ autilizado como canal de referencia para realizar una primera detecci´n de los veh´ o ıculoscercanos como paso previo al establecimientode las comunicaciones. Al mismo tiempo,dicho canal se usa para anunciar los servicios disponibles en canales SCH (acceso a Internet,descarga de contenidos..etc.) El canal CCH se usa para la transmisi´n en modo broadcast ode mensajes de seguridad vial. Este contenido es prioritario sobre los dem´s tr´ficos y a ase transmite en el canal CCH con una tasa de datos de 6Mbps, correspondiente a unamodulaci´n QPSK con un ratio de codificaci´n de 1/2. o o En la capa MAC, WAVE se basa en las definiciones del IEEE802.11 usando una t´cnica ede acceso basada en CSMA/CA (Carrier Sense Multiple with Collision Avoidance). Sinembargo, CSMA/CA no logra solucionar el problema del terminal escondido.
  • 35. 12 CHAPTER 2. ESTADO DEL ARTE Figure 2.1: Problema del terminal escondido Como podemos observar en la figura 2.1, la estaci´n 1 y la estaci´n 3 intentan mandar o otr´fico al mismo instante a la estaci´n 2, ya que no se escuchan, no tienen alcance la a ouna a la otra. Se producen entonces colisiones de paquetes. El problema del terminalescondido surge siempre cuando dos nodos se hallan fuera del alcance radio entre ellos eintentan mandar informaci´n a un mismo nodo en un mismo instante. Para tratar ese oproblema se implementa un mecanismo de intercambio de mensajes RTS/CTS (Request-to-Send/Clear-to-send ). Antes de mandar datos, la estaci´n 1 manda una trama RTS oal destino para indicar que desea mandar tr´fico. La estaci´n 2 recibe el RTS e informa a oal resto de los nodos a su alcance que va a reservar el canal para la comunicaci´n con la oestaci´n 1. De esta forma la estaci´n 3 queda informada que tiene que esperar antes de o omandar paquetes. Podr´ darse casos de colisiones de paquetes RTS, sin embargo el efecto ıanser´ reducido ya que se tratan de paquetes de peque˜o tama˜o (hasta 2347 octetos). ıa n n Este mecanismo evita colisiones pero introduce una sobrecarga de tr´fico en la red y aretardo en las transmisiones. Por esas razones, WAVE no implementa RTS/CTS en elcanal CCH por transmitir en modo broadcast. Como consecuencia, todos los nodos queutilizan el canal de control est´n sujetos al problema del terminal escondido, incrementando ael riesgo de p´rdidas de paquetes y de congesti´n de canal. e o2.2.3 Bluetooth Se denomina Bluetooth al protocolo de comunicaciones dise˜ado especialmente para ndispositivos de bajo consumo, con una cobertura baja y basados en transceptores de bajocosto. Gracias a este protocolo, los dispositivos que lo implementan pueden comunicarse entreellos cuando se encuentran dentro de su alcance. Las comunicaciones se realizan porradiofrecuencia de forma que los dispositivos no tienen que estar alineados y pueden inclusoestar en habitaciones separadas si la potencia de transmisi´n lo permite. Estos dispositivos ose clasifican como ”Clase 1”, ”Clase 2” o ”Clase 3” en referencia a su potencia de transmisi´n, osiendo totalmente compatibles los dispositivos de una clase con los de las otras. En la mayor´ de los casos, la cobertura efectiva de un dispositivo de clase 2 se extiende ıacuando se conecta a un transceptor de clase 1. Esto es as´ gracias a la mayor sensibilidad ı
  • 36. 2.3. SERVICIOS PARA LA SEGURIDAD VIAL 13y potencia de transmisi´n del dispositivo de clase 1, es decir, la mayor potencia de trans- omisi´n del dispositivo de clase 1 permite que la se˜al llegue con energ´ suficiente hasta el o n ıade clase 2. Por otra parte la mayor sensibilidad del dispositivo de clase 1 permite recibirla se˜al del otro pese a ser m´s d´bil. n a e2.2.4 UWB Ultra Wide Band es un est´ndar basado en 802.15.3 que funciona emitiendo a muy baja apotencia en un espectro enorme. Su alcance es muy limitado (<10m) pero proporcionatasas de transferencia muy elevadas llegando a los 480 Mbps. Su consumo de energ´ es ıamuy reducido.2.2.5 ZigBee - 802.15.4 ZigBee es el nombre de la especificaci´n de un conjunto de protocolos de alto nivel de ocomunicaci´n inal´mbrica para su utilizaci´n con radiodifusi´n digital de bajo consumo, o a o obasada en el est´ndar IEEE 802.15.4 de redes inal´mbricas de ´rea personal (Wireless a a aPersonal Area Network, WPAN). Su objetivo son las aplicaciones que requieren comuni-caciones seguras con baja tasa de env´ de datos y maximizaci´n de la vida util de sus ıo o ´bater´ ıas.2.3 Servicios para la seguridad vial Los servicios dirigidos a la seguridad vial son de forma clara los m´s importantes y los am´s cr´ a ıticos dado que su objetivo no es otro que salvar vidas disminuyendo el n´mero de uaccidentes en la carretera. En este contexto se est´ haciendo un esfuerzo importante por aparte de la Comisi´n Europea en la investigaci´n, desarrollo e implementaci´n de este tipo o o ode servicios con el prop´sito de que entren en actividad lo antes posible. o2.3.1 Mecanismos anti-colisi´n o Se trata de un servicio de ayuda a la conducci´n que sirve para detectar posibles oobst´culos en la v´ a ıa. La funcionalidad principal consiste en el aviso mediante se˜ales nac´sticas o visuales al conductor de la presencia de otro veh´ u ıculo o de que se acercaa una velocidad peligrosa para ese entorno. Este servicio requiere mucha rapidez a lahora de establecer el enlace y no es tan importante el tema de encaminamiento ya queb´sicamente la comunicaci´n se dar´ entre veh´ a o a ıculos con visi´n inal´mbrica directa sin o anodos intermediarios.
  • 37. 14 CHAPTER 2. ESTADO DEL ARTE Para un correcto despliegue ser´ necesaria una peque˜a instalaci´n en los equipos de a n olos usuarios que enviase a sus vecinos informaci´n de posici´n, trayectoria y velocidad as´ o o ıcomo un mecanismo que permanentemente escuche la informaci´n enviada por el resto de olos veh´ ıculos y la infraestructura.2.3.2 Aviso de peligro La funcionalidad principal de ese servicio consiste en detectar eventos peligrosos parainformar al resto de los veh´ıculos de la red. Los sensores pueden detectar un peligro yavisar al conductor con una breve descripci´n o el conductor mismo puede detectar el opeligro y a trav´s de una interfaz vocal describir el peligro para el resto de los usuarios. e Puede interesar mandar la informaci´n a todos los usuarios de la red para informar opor ejemplo que se produce un atasco en un cierto punto de la carretera donde est´n acirculando. Por otro lado, se puede necesitar un env´ geocast, por ejemplo si se detecta ıoun vertido de aceite en una salida de la v´ solo interesa mandarla a aquellos que van a ıatomar esa salida. Por lo tanto, es necesario que los veh´ıculos soporten protocolos broadcasty geocast que no sobrecargen la red con mensajes de control para que la informaci´n llegue oal destino de manera eficiente y r´pida. a2.3.3 Paso de veh´ ıculos de emergencia Ante un accidente, incidente grave, o circunstancia que requiera la presencia de personalde socorro, de emergencia o una determinada autoridad, surge la necesidad de ofrecer unservicio de paso de veh´ıculos de emergencia que facilite el acceso y localizaci´n de ´stos. o e As´ cabr´ esperar que el sistema permitiera que un determinado veh´ ı, ıa ıculo de emer-gencia, de la misma forma que puede activar las se˜ales de alarma convencionales, como npueden ser luminosas y sonoras, pueda activar la se˜al de alarma telem´tica, iniciando en n aeste proceso un env´ continuado de un mensaje de alerta determinado, indicando su posi- ıoci´n. Este mensaje podr´ viajar unos cientos de metros o kil´metros, en modo redifusi´n, o ıa o opermitiendo a los veh´ıculos afectados por ese radio de acci´n, advertir de forma precisa y oc´moda la proximidad del veh´ o ıculo de emergencia, pudiendo actuar en consecuencia.
  • 38. Chapter 3ZigBee/802.15.43.1 Introducci´n a ZigBee/802.15.4 o Como ya hemos visto en el cap´ ıtulo 2, ZigBee/802.15.4 es una tecnolog´ inal´mbrica ıa ade bajo consumo, baja tasa de transmisi´n y coste reducido. Se engloba dentro del grupo ode las tecnolog´ WPAN (Wireless Personal Area Network ). El est´ndar ha sido definido ıas apor la ZigBee Alliance, de la que forman parte m´s de 300 empresas, y por el IEEE Task aGroup 4. En concreto, la ZigBee Alliance se encarga de la definici´n de las capas de red y oaplicaci´n mediante el est´ndar ZigBee [16] mientras que el Task Group 4 se centra en la o adefinici´n de las capas f´ o ısica y MAC (Medium Access Control ) mediante est´ndar 802.15.4 a[15]. Estos t´rminos, ZigBee y 802.15.4, son a veces utilizados como sin´nimos cuando en e orealidad definen partes diferentes de la pila de protocolos. En la figura 3.1 podemos veruna simplificaci´n de dicha pila de protocolos. o Figure 3.1: Pila de protocolos ZigBee/802.15.4 Dentro del est´ndar ZigBee encontramos dos versiones: ZigBee-2006 y ZigBee PRO a(2007). En las siguientes secciones utilizaremos el t´rmino ZigBee para referirnos a ZigBee e 15
  • 39. 16 CHAPTER 3. ZIGBEE/802.15.4PRO. La mayor´ de los fabricantes comercializan dispositivos compatibles con ambas ıaversiones.3.2 Topolog´ ıa Antes de describir los distintos tipos de redes ZigBee es necesario definir los 3 tiposdistintos de dispositivos que la componen. Estos son: ˆ Coordinador. Este dispositivo inicializa y controla la red. Tambi´n se encarga de e gestionar las tareas de seguridad. Para poder formar una red ZigBee debe existir un coordinador. ˆ Router. Estos dispositivos son los encargados de extender la cobertura de la red, gestionando nuevos caminos en el caso de que la red experimente congesti´n o se o produzca la ca´ de alg´n nodo. Pueden conectarse directamente al coordinador o ıda u a otros routers. Gestionan dispositivos hijo. ˆ Dispositivo final. Este tipo de dispositivo puede enviar y recibir datos pero no rea- lizar tareas de encaminamiento. Deben estar conectados a un router o al coordinador y no admiten dispositivos hijo. Los dispositivos tambi´n pueden organizarse seg´n otro criterio: e u ˆ FFD (Full Function Device). Este dispositivo tiene una funcionalidad completa. Puede funcionar como Coordinador, router o dispositivo final. ˆ RFD (Reduced Function Device). Tiene una implementaci´n m´ o ınima del proto- colo 802.15.4. Est´ pensado para realizar tareas extremadamente simples en las que a se env´ peque˜as cantidades de datos. Ejemplos de esto pueden ser interruptores ıen n de luz, sensores de infrarrojos u otros dispositivos con una funcionalidad b´sica. S´lo a o ´ pueden estar conectados a un FFD. Unicamente pueden funcionar como dispositivos finales. Como podemos ver en la especificaci´n de ZigBee [16], el est´ndar soporta 3 tipos o ade topolog´ de red: estrella, malla y ´rbol (figura 3.2). Una red se caracteriza por su ıas aidentificador PAN (PAN ID), que la distingue de otras posibles redes funcionando en lamisma zona.3.2.1 Topolog´ en estrella ıa Este tipo de redes se componen de un FFD funcionando como coordinador y variosFFD o RFD funcionando como dispositivos finales. Todos los dispositivos finales est´n a
  • 40. 3.2. TOPOLOG´ IA 17 Figure 3.2: Topolog´ de red ıasdirectamente conectados al coordinador, que es el encargado de haber iniciado la red yde gestionarla. En una red tipo estrella todas las comunicaciones entre dos dispositivosfinales deben pasar antes por el coordinador. Se recomienda que mientras los dispositivosfinales est´n alimentados por bater´ el coordinador lo est´ directamente a trav´s de la red e ıas e eel´ctrica ya que su consumo es mucho mayor. Un problema de esta configuraci´n es que e ola expansi´n de la red est´ muy limitada puesto que el rango de alcance del coordinador o aes el que define el tama˜o de la red. n3.2.2 Topolog´ en malla ıa En este tipo de red se puede establecer comunicaci´n directa entre cualquier par de onodos. El coordinador no realiza funciones muy diferentes a las que realizan el resto de derouters de la red; de hecho, la funci´n de coordinador la realiza el primer dispositivo para ogestionar la red, la fiabilidad de esta configuraci´n es mayor. o En la topolog´ en malla ganamos en flexibilidad a costa de aumentar la complejidad. ıaEsto se debe a que para comunicar cualquier par de dispositivos hay m´s de un camino aposible. La elecci´n de dicho camino conlleva un aumento de computaci´n que debe o orealizarse en el nivel de red. Por lo tanto, estas consideraciones no se tienen en cuenta enla especificaci´n del IEEE 802.15.4 sino que se definen en la especificaci´n de ZigBee. o o3.2.3 Topolog´ en ´rbol ıa a La topolog´ en ´rbol es un caso particular de la topolog´ en malla. En ella los difer- ıa a ıaentes componentes de la red se organizan en una estructura jer´rquica. El coordinador ao los routers, que son los encargados de gestionar el encaminamiento, pueden tener dis-positivos hijos. Estos dispositivos hijos pueden ser otros routers o dispositivos finales.
  • 41. 18 CHAPTER 3. ZIGBEE/802.15.4 Banda de frecuencia Tasa de transferencia Modulaci´n o 868 MHz 20 kbps BPSK 915 MHz 40 kbps BPSK 2,4 GHz 250 kbps O-QPSK Tabla 3.1: Caracter´ ısticas de las frecuencias 802.15.4La topolog´ en ´rbol, al igual que la mallada, es id´nea para expandir la red de forma ıa a odin´mica. Al igual que en el caso anterior se recomienda que el coordinador y los routers aest´n alimentados de forma cableada. e3.3 Capa F´ ısica La capa f´ısica gestiona la transmisi´n y recepci´n de datos usando determinados canales o oradio. En 802.15.4 tenemos tres posibles bandas de frecuencia en las que poder trabajar:868 MHz, 915 MHz y 2,4 GHz. En la primera banda unicamente tenemos un canal entre ´868 y 868,6 MHz. En la siguiente banda tenemos 10 canales entre 902 y 928 MHz. Porultimo, 16 canales m´s est´n localizados entre 2,405 y 2,48 GHz. El protocolo permite´ a auna selecci´n din´mica del canal, de forma que se elija el menos ruidoso de entre aquellos o aposibles. L´gicamente, la tasa de transferencia es distinta para cada una de las bandas de ofrecuencia. Para 868 MHz la tasa de transferencia es de 20 Kbps, para 915 MHz es de 40kbps y para 2,4 GHz es de 250 kbps. Por supuesto, las bandas de 868 y 915 MHz tienen unrango de alcance mayor que la de 2,4 GHz a cambio de una menor tasa de transferencia.Otra diferencia es que, la banda de 868 MHz est´ disponible s´lo en Europa mientras que a ola de 915 MHz s´lo en Estados Unidos y Australia. Sin embargo la banda a 2,4 GHz es ouniversal, por lo que su uso est´ permitido en la mayor´ de pa´ del mundo. En la figura a ıa ıses3.3 podemos ver una representaci´n de los canales radio 802.15.4. o Figure 3.3: Canales radio 802.15.4 En 804.15.4 se utiliza DSSS (Direct Sequence Spread Spectrum) como t´cnica de en- esanchado de espectro. En la tabla 3.1 mostramos la tasa de transferencia y el tipo demodulaci´n usada para las distintas frecuencias de transmisi´n. o o
  • 42. 3.3. CAPA F´ ISICA 19 Respecto a las funciones que realiza la capa f´ ısica en 802.15.4 podemos destacar: ˆ Activar y desactivar el transceptor radio. El transceptor radio tiene tres modos de funcionamiento: transmisi´n, recepci´n y sleeping (descanso). Bajo petici´n de la o o o capa MAC la capa f´ ısica debe conmutar entre estos tres estados. El est´ndar exige a que la conmutaci´n entre transmisi´n y recepci´n, o viceversa, se haga en menos o o o de 12 s´ ımbolos (aTurnaroundTime = 12). Para el caso de 2,4 GHz y teniendo en cuenta que cada s´ ımbolo corresponde a 4 bits, se puede calcular el tiempo m´ximo a de conmutaci´n entre los estados de transmisi´n y recepci´n: o o o 12simbolos = 48bits (3.1) 48bits = 192µs (3.2) 250 kbits s ˆ Detecci´n de energ´ de cada canal (ED, Energy Detection). La capa f´ o ıa ısica tambi´n es la encargada de comprobar qu´ nivel de potencia tiene un determinado e e canal. Esta medida es utilizada por la capa de red como parte de su algoritmo para la elecci´n de canal. o ˆ Indicaci´n de la calidad de enlace (LQI, Link Quality Indicator ). Mide la o potencia en dBm de la se˜al que ha transmitido el ultimo paquete. n ´ ˆ Evaluaci´n de canal libre (CCA, Clear Channel Assessment). Este indi- o cador ser´ utilizado por el algoritmo CSMA-CA (Carrier Sense Multiple Access with a Collision Avoidance) como se ver´ m´s adelante. a a ˆ Selecci´n de frecuencia. Dentro de los 27 canales posibles de ZigBee, la capa o f´ ısica debe ser capaz de seleccionar aquel que le especifiquen las capas superiores. ˆ Env´ y recepci´n de datos. ıo o De acuerdo con el est´ndar 802.15.4, el sistema radio debe ser capaz de emitir con una apotencia de -3 dBm o superior y debe tener una sensibilidad m´ ınima de -20 dBm. En la figura 3.4 se muestra el formato de trama 802.15.4 a nivel f´ ısico. Dicha tramaest´ compuesta principalmente por una cabecera de sincronizaci´n (SHR), un campo para a oindicar la longitud de la trama (PHR) y la carga util. ´ Figure 3.4: PDU (Protocol Data Unit ) de nivel f´ ısico o PPDU. Una vez generada la PPDU (Presentation Protocol Data Unit), y de acuerdo con elest´ndar 802.15.4 [15], los bits se convierten en s´ a ımbolos. Puesto que cada s´ ımbolo est´ a
  • 43. 20 CHAPTER 3. ZIGBEE/802.15.4formado por 4 bits, se tienen 16 posibles s´ ımbolos. Para cada uno de ellos existe unasecuencia de chips (formada por 32 bits cada una) que ser´ la que definitivamente se amodule y env´ gracias al sistema de radio. El proceso se esquematiza en la figura 3.5. ıe Figure 3.5: Tratamiento de la PPDU3.4 Capa MAC3.4.1 Descripci´n general o La capa MAC, o capa de acceso al medio, es la responsable de asegurar la comuni-caci´n entre un nodo y todos los nodos conectados directamente a ´l, evitando colisiones y o emejorando la eficiencia. M´s concretamente, las tareas que la capa MAC tiene que realizar ason: ˆ Generar balizas (beacons) si el dispositivo es un coordinador y si funciona en modo balizado. ˆ Sincronizar las balizas de la red. ˆ Gestionar la conexi´n y desconexi´n a la red de los dispositivos asociados al propio o o nodo. ˆ Emplear el algoritmo CSMA-CA para gestionar el acceso al canal. ˆ Asegurar un enlace fiable con la capa MAC de los nodos contiguos. Al igual que ocurre con la capa f´ ısica, para configurar la capa MAC se utilizan una seriede constantes y atributos. Ejemplos de dichas constantes y atributos son macBeaconOrdermacSuperframeOrder o aBaseSuperframeDuration, que, junto con otros, ser´n utilizados aen las siguientes secciones para profundizar en la descripci´n de la capa de acceso al medio. o3.4.2 Modos de funcionamiento El protocolo MAC soporta dos modos de funcionamiento (el coordinador es el encargadode seleccionar uno u otro en el momento de iniciar la red):
  • 44. 3.4. CAPA MAC 21 ˆ Modo balizado. La baliza es generada peri´dicamente por el coordinador y dis- o tribuida por toda la red gracias a los routers. Dicha baliza sirve para sincronizar todos los nodos de la red, de modo que estos puedan despertarse en un momento determinado (conocido por todos), enviar los datos almacenados y volver al modo de ahorro energ´tico (sleep). As´ tanto el coordinador como los routers y los dis- e ı, positivos finales pueden pasar gran parte del tiempo en modo de bajo consumo. La topolog´ en malla no admite el modo balizado debido a la complejidad que ello ıa conllevar´ (a un mismo dispositivo podr´ llegarle balizas provenientes de distintos ıa ıan routers). ˆ Modo no balizado. En este modo los dispositivos no est´n sincronizados unos con a otros. As´ unicamente los dispositivos finales pueden entrar en el modo sleep mien- ı, ´ tras que los routers y el coordinador deben estar continuamente con el sistema radio en modo recepci´n y as´ estar preparados para recibir datos en cualquier momento. o ı Este modo es m´s simple pero hace que gran parte de sus nodos (el coordinador y a los routers) tengan un mayor consumo energ´tico. Asimismo, impide que los coor- e dinadores puedan planificar sus env´ a los dispositivos finales. ıosModo balizado El coordinador es el que determina si trabajamos o no en este modo. En caso positivo,´l ser´ el encargado de distribuir la baliza a todos los elementos de la red.e a Cuando se trabaja en el modo balizado se utiliza una estructura de env´ de datos ıoconocida como ”supertrama”. Una supertrama est´ delimitada por dos balizas consecutivas ay se compone por una parte activa y otra inactiva (figura 3.6). Durante la parte activael coordinador interact´a con la red mientras que en la inactiva entra en modo sleep. La uestructura de una supertrama viene definida por dos par´metros: a ˆ BO (macBeaconOrder ). Determina el intervalo de transmisi´n de las balizas. El o valor del BO y del BI (Beacon Interval ) est´rn relacionadas seg´n la siguiente ex- a u presi´n, donde 0 ≤ BO ≤ 14 y aBaseSuperf representa el n´mero de s´ o u ımbolos que forman una supertrama de orden 0 (por defecto toma el valor de 960): BI = aBaseSuperf rameDuration · 2BO smbolos ˆ SO (macSuperFrameOrder ). Determina el tama˜o de la parte activa de la super- n trama. El valor del SO y del SD (Superframe Duration) est´n relacionados seg´n la a u siguiente expresi´n, donde 0 ≤ SO ≤ BO ≤ 14: o SD = aBaseSuperf rameDuration · 2SO smbolos Si los valores de BI y SD coinciden la supertrama carecer´ de periodo inactivo. Por otra aparte, de acuerdo con el est´ndar 802.15.4, si SO y BO valen 15 el coordinador configurar´ a ala red para trabajar en modo no balizado. La parte activa de la supertrama se divide en 16 slots temporales, el primero de loscuales contiene la baliza. Estos slots se dividen en dos grupos: el Contention Access Period(CAP) y el Contention Free Period (CFP). A continuaci´n los detallamos: o
  • 45. 22 CHAPTER 3. ZIGBEE/802.15.4 Figure 3.6: Estructura de supertrama. Fuente: [15] ˆ CAP. Un dispositivo que desee comunicarse con su nodo padre debe competir por el canal utilizando el algoritmo CSMA-CA. Si consigue transmitir lo har´ utilizando a uno de los slots del CAP. ˆ CFP. Bajo petici´n de un nodo, el coordinador puede asignarle uno o varios slots o temporales del CFP de forma que no tenga que competir con otros nodos de la red por el env´ de informaci´n. Un grupo de slots temporales asignados a un determinado ıo o nodo se denominan Guarantee Time Slots (GTS). Mediante esta caracter´ ıstica, el protocolo 802.15.4 puede ofrecer cierta calidad de servicio a ciertas aplicaciones con requerimientos especiales.Modo no balizado Como hemos dicho en el punto anterior, si se asigna el valor 15 a las variables BO ySO activaremos el modo no balizado. En ´l no existen los conceptos de disputa de acceso eal canal gracias al empleo del algoritmo CSMA-CA. Si se consigue el acceso, los dem´s a ´dispositivos tendr´n que esperar su turno. Unicamente los mensajes de reconocimiento de amensaje recibido (acknowledgment o ack en ingl´s) podr´n ser enviados inmediatamente e asin necesidad de competir por el acceso al medio mediante el empleo de CSMA-CA. En este modo el consumo del coordinador y de los routers es mucho mayor que en elmodo balizado. El consumo de los dispositivos finales s´ se mantiene pr´cticamente igual ı aen ambos modos puesto que siempre pueden pasar al modo de bajo consumo una veztransmitidos los datos. Vi´ndolo de otra forma podemos decir que en una red con balizas etodos los dispositivos est´n dormidos la mayor parte del tiempo, gracias a la sincronizaci´n a oentre ellos que les permite despertarse a la vez. En una red sin balizas el coordinador ylos routers no tienen manera de saber cu´ndo se despertar´n los dispositivos finales, por a alo que tienen que estar el 100œdel tiempo con el sistema radio activado. El modo no balizado nos ofrece simplicidad a cambio de un consumo mayor y unamenor eficiencia.
  • 46. 3.4. CAPA MAC 233.4.3 Algoritmo CSMA-CA Cuando se emplea este algoritmo los dispositivos anuncian que est´n listos para enviar apaquetes de datos antes de acceder al canal. De esta forma se evita la colisi´n. Depen- odiendo de unos ciertos par´metros se da prioridad a uno de los candidatos, que podr´ a aacceder al canal para enviar su paquete de datos. El resto de dispositivos esperar´n un atiempo aleatorio (distinto en cada uno de ellos) para volver a intentar acceder al canal. Se definen dos tipos distintos de algoritmo CSMA-CA seg´n estemos usando el modo ubalizado o el no balizado. Para el modo balizado se emplea el CSMA-CA ranurado mientrasque para el no balizado se utiliza el CSMA-CA no ranurado. En ambos casos, un transmisors´lo puede intentar acceder al medio con una periodicidad concreta (determinada por oel tiempo de backoff ). En el CSMA-CA ranurado, este tiempo de backoff debe estarsincronizado con la baliza. Para el caso del CSMA-CA no ranurado, cada transmisor tienesu propio tiempo de backoff. El algoritmo CSMA-CA utiliza tres variables para priorizar el acceso al medio: ˆ NB (Number of Backoffs). Es el n´mero de intentos de acceso al canal que un u dispositivo lleva acumulados. Cada vez que un dispositivo quiere enviar un nuevo paquete esta variable debe ser inicializada a 0. ˆ CW (Contention Window ). Es la longitud de la ventana de contienda. Representa el n´mero de periodos de backoff que el canal debe estar sin actividad para que se u considere libre y, en consecuencia, poder ser asignado a un dispositivo. ˆ BE (Backoff Exponent). Se emplea para determinar, aleatoriamente, el n´mero de u per´ ıodos de backoff que el dispositivo debe esperar para intentar acceder al canal despu´s de un acceso fallido. eA continuaci´n explicaremos de forma detallada ambos algoritmos. En la figura 3.7 pode- omos ver su diagrama de bloques.CSMA-CA ranurado Este algoritmo se divide en cinco pasos: 1. Inicializaci´n de NB, CW y BE. N B = 0 y CW = 2. El valor de BE depende o de la variable macBattLifExt. Si ´sta es FALSE entonces BE = macM inBe, que e por defecto vale 3. Si macBattLif Ext = T RU E (extensi´n de vida de la bater´ o ıa) entonces BE = minimo(2; macM inBE). 2. Tiempo de espera aleatorio para intentar acceder al canal. Este tiempo de espera valdr´ como m´ximo 2BE − 1 periodos de backoff. Si BE = 1 entonces el tiempo de a a espera es nulo, con lo que saltamos directamente al paso 3.
  • 47. 24 CHAPTER 3. ZIGBEE/802.15.4 3. Evaluaci´n de canal libre (CCA o Clear Channel Assessment). El dispositivo escucha o el canal en el siguiente periodo de backoff. Si el canal no se encuentra en uso, saltamos al paso 5. Si el canal resulta estar ocupado pasamos al paso 4. 4. CW es reiniciado a su valor original (2). NB se incrementa en 1. BE tambi´n se e incrementa en 1 siempre que no sobrepasemos el valor de macMaxBE (constante de valor 5 seg´n el est´ndar). Si N B > macM axCSM ABackof f s (tambi´n de valor u a e 5) se considera que la transmisi´n ha fallado. Si no, volvemos al paso 2. o 5. El canal no est´ siendo usado. Se disminuye en 1 el par´metro CW. Si CW es 0 a a entonces se ha superado la ventana de contienda y el canal se considera libre. La transmisi´n puede comenzar. Si CW no es 0 todav´ no hemos superado la ventana o ıa de contienda con lo que se vuelve al paso 3.CSMA-CA no ranurado Este algoritmo es muy similar al visto en el punto anterior. Los pasos a seguir son: 1. Inicializaci´n de NB, CW y BE. Al igual que en el caso anterior N B = 0. En o este caso sin embargo CW = 0 con lo que no existe ventana de contienda: si se detecta una unica vez que el canal no est´ siendo usado se considera que est´ libre. ´ a a Por otro lado, el modo no balizado no soporta el modo macBattLifExt, por lo que directamente BE se iguala a macMinBE. 2. Id´ntico al caso de CSMA-CA ranurado. e 3. Id´ntico al caso de CSMA-CA ranurado. e 4. Id´ntico al caso de CSMA-CA ranurado excepto que en este caso no reiniciamos CW e a su valor original puesto que estamos utilizando la ventana de contenci´n. o 5. Transmisi´n (como en el caso ranurado). o3.4.4 Inicializaci´n y mantenimiento de PAN o Como hemos mencionado, la capa MAC es la encargada de gestionar la conexi´n y odesconexi´n de un dispositivo a la red. Para realizar esta tarea, as´ como la de inicializar o ıla red para el caso del coordinador, la capa MAC se sirve de los siguientes procedimientos: ˆ Detecci´n de energ´ de canal. Mediante este procedimiento, y a petici´n de o ıa o las capas superiores, la capa MAC mide la energ´ de un canal o lista de canales ıa determinados. Para ello indica a la capa f´ısica realizar una detecci´n de energ´ de o ıa canal (ED) para cada uno de los canales elegidos. Mediante este procedimiento el coordinador puede elegir, entre varios canales aquel con menos tr´fico e iniciar la red a PAN en ´l. e
  • 48. 3.4. CAPA MAC 25 Figure 3.7: Diagrama de bloques del algoritmo CSMA-CA. ˆ Escaneo activo de canal. Permite a un dispositivo localizar a un coordinador que transmita balizas y est´ dentro de su rango de alcance. Los routers y los dispositivos e finales usan este procedimiento a la hora de asociarse a la red. Si el dispositivo se trata de un coordinador, este m´todo se puede usar para detectar las redes PAN e dentro de un canal y as´ seleccionar un identificador distinto a los ya existentes ı para la nueva red. Un dispositivo que realice un escaneo activo de canal transmitir´ a peri´dicamente balizas. Si la red trabaja en modo no balizado, el coordinador re- o sponder´ a cada una de estas balizas con una nueva baliza. Si la red trabaja en modo a balizado, el coordinador ignorar´ estas balizas y seguir´ transmitiendo de forma reg- a a ular las suyas. As´ en cualquier caso, el dispositivo que realiza el escaneo recibir´ ı, a una serie de balizas como respuesta a su petici´n de asociaci´n. o o ˆ Escaneo pasivo de canal. La unica diferencia con el caso anterior es que el ´ dispositivo que realiza el escaneo no transmite baliza alguna. Lo unico que har´ ser´ ´ a a escuchar el canal en busca de balizas emitidas por el coordinador. Obviamente, este
  • 49. 26 CHAPTER 3. ZIGBEE/802.15.4 modo no es adecuado para el modo no balizado. ˆ Escaneo de canal por un dispositivo hu´rfano. Si el dispositivo ha perdido la e sincronizaci´n con su coordinador emitir´ lo que se conoce como notificaciones de o a orfandad. Las capas superiores indicar´n a la capa MAC por qu´ canales transmitir a e dichas notificaciones. El coordinador debe responder a dicha notificaci´n haciendo o que la sincronizaci´n entre ´l y el dispositivo hu´rfano se recupere. o e e3.4.5 Formato de trama Se definen cuatro tipos distintos de tramas: formato general de trama MAC, tramasde baliza, tramas de datos y tramas de ack. Estas tramas est´n compuestas por: a ˆ Cabecera (MHR o MAC Header ): Se compone por un campo de control, n´mero u de secuencia, informaci´n de direcci´n destino y fuente e informaci´n relativa a la o o o seguridad utilizada. ˆ Carga util. Este campo var´ para cada uno de los cuatro tipos de tramas. Las ´ ıa tramas de ack no contienen este campo. ˆ Secuencia de control (MFR o MAC Footer ): secuencia de 16 bits conocida como FCS (Frame Check Sequence) que no es m´s que un c´digo CRC (c´digo de redundancia a o o c´ ıclico).Formato general de trama MAC Figure 3.8: Formato general de trama MAC Figure 3.9: Trama de baliza ˆ MHR compuesto por:
  • 50. 3.4. CAPA MAC 27 Figure 3.10: Trama de datos Figure 3.11: Trama de ack – Control de trama: 16 bits para indicar el tipo de trama, si la trama utiliza un c´digo de seguridad, si se requiere de ack por parte del nodo adyacente, etc. o – N´mero de secuencia: 8 bits para identificar la trama. u – Identificador de PAN destino: 16 bits para identificar el n´mero de PAN con el u que nos estamos comunicando. Usamos el valor hexadecimal FFFF para indicar ”cualquier PAN”. – Direcci´n destino (16 ´ 64 bits). o o – Identificador de PAN origen (16 bits). – Direcci´n origen (16 ´ 64 bits). o o ˆ Carga util. ´ ˆ MFR.Tramas de baliza El MHR y el MFR son exactamente iguales que en el caso anterior. En este caso elcampo de carga util tiene el siguiente formato: ´ ˆ Especificaci´n de supertrama: 16 bits para especificar los par´metros BO, SO, mac- o a BattLifExt, permiso de asociaci´n, etc. o ˆ Informaci´n sobre los campos GTS. o ˆ Direcciones pendientes de ser atendidas (Pending address): Lista con las direcciones de los dispositivos pendientes de comunicarse con el coordinador. ˆ Carga util: opcional. ´
  • 51. 28 CHAPTER 3. ZIGBEE/802.15.4Tramas de datos El MHR y el MFR son exactamente iguales a los casos anteriores. El campo de cargautil contiene la informaci´n pasada por las capas superiores.´ oTramas de ack El MHR est´ compuesto unicamente por los campos de control de trama y de n´mero a ´ ude secuencia. Este tipo de trama no posee carga util. El campo MFR es igual que en los ´casos anteriores.3.5 Capa de red3.5.1 Descripci´n general o La capa de red se define en la especificaci´n de ZigBee [16]. Esta capa es necesaria para ogestionar las capas f´ ısicas y MAC del est´ndar 802.15.4 y para proveer de una adecuada ainterfaz de servicio al nivel de aplicaci´n. B´sicamente las tareas que realiza la capa de o ared son las siguientes: ˆ Configuraci´n de nuevos dispositivos. o ˆ Inicializaci´n de la red PAN. o ˆ Asociaci´n, reasociaci´n y abandono de una red. o o ˆ Adjudicaci´n de direcciones de red. o ˆ Descubrimiento de la topolog´ de red. ıa ˆ Encaminamiento (routing). Las constantes y atributos utilizadas para configurar la capa de red son listadas en ladefinici´n del est´ndar ZigBee [16]. Ejemplos de dichas constantes y atributos son nwkcCo- o aordinatorCapable, nwkcDefaultSecurityLevel, nwkMaxChildren, nwkMaxDepth, nwkNeigh-borTable, etc. A nivel de red, existen dos tipos de direcciones: direcciones cortas (16 bits) y direccioneslargas o direcciones IEEE (64 bits). Cada dispositivo debe tener asignada una direcci´n oIEEE unica. No puede haber dos dispositivos que cumplan con la especificaci´n ZigBee y ´ oque posean la misma direcci´n IEEE. As´ esta direcci´n es asignada en el momento de la o ı, ofabricaci´n del dispositivo. Por contra, la direcci´n corta es asignada por la capa de red o o
  • 52. 3.5. CAPA DE RED 29de forma din´mica. Dentro de una red ZigBee no puede haber m´s de un dispositivo con a aigual direcci´n corta. o3.5.2 Funciones A continuaci´n explicamos de forma m´s detallada las funciones principales que realiza o ala capa de red ZigBee.Establecer una nueva red S´lo los dispositivos con capacidad para comportarse como coordinador (constante onwkcCoordinatorCapable igual a 1) que no est´n actualmente asociados a una red pueden erealizar este procedimiento. El primer paso para establecer una nueva red es indicar a la capa MAC que realice unadetecci´n de energ´ de canal para un determinado conjunto de canales o, en su defecto, o ıapara todos. Si estamos obligados a trabajar unicamente en un canal, no es necesario ´realizar dicha detecci´n de energ´ Una vez realizada la detecci´n de energ´ de los canales, o ıa. o ıase ordenan de mayor a menor calidad, descartando aquellos con un nivel de interferenciademasiado elevado. A continuaci´n se realiza un escaneo activo de canal para cada uno ode ellos. Finalmente se elige aquel canal con menor interferencia y en el que trabaje unmenor n´mero de redes ZigBee. u Una vez seleccionado el canal se elige un identificador de red menor que el valor hex-adecimal 0xFFFF (ya que ´ste significa ”cualquier red”) y se indica a la capa MAC dicho evalor. A continuaci´n el dispositivo que ha iniciado la red, el coordinador, se autoasigna la odirecci´n corta 0x0000. Por ultimo se indica a la capa MAC que la red ha sido establecida o ´con ´xito. ePermitir a los dispositivos unirse a una red S´lo el coordinador y los routers pueden realizar este procedimiento. o La capa de red modificar´ el valor del atributo macAssociationPermit de la capa MAC. aPara el caso de que macAssociationPermit sea TRUE el dispositivo en cuesti´n permitir´ o aa otros dispositivos asociarse a ´l. La capa de red puede modificar dicho valor de forma eindefinida o simplemente durante una cantidad de tiempo determinada.
  • 53. 30 CHAPTER 3. ZIGBEE/802.15.4Descubrimiento de red Mediante este procedimiento la capa de red indica a la capa superior qu´ redes ZigBee eest´n operando dentro del rango de alcance del dispositivo en cuesti´n. a o La capa de red solicita a la capa MAC realizar un escaneo activo de canal para undeterminado grupo de canales. Una vez realizado, la capa MAC responder´ indicando en aqu´ canales l´gicos est´n trabajando las redes encontradas, cu´les son sus identificadores e o a a(PAN ID) y si permiten o no a otros dispositivos unirse a ellas.Unirse a una red El primer paso para unirse a una red es efectuar un ”descubrimiento de red”, comohemos visto en el punto anterior. Una vez seleccionada la red en la que vamos a trabajarse realiza un listado con los candidatos a ”padre” (estos dispositivos ser´n routers y/o el acoordinador que est´n dentro del rango de alcance del dispositivo en cuesti´n). L´gica- e o omente descartaremos aquellos que no tengan activado el permiso para unirse ellos. Entrelos candidatos restantes seleccionaremos aquellos con menor profundidad (m´ ınima distan-cia hasta el coordinador); esto quiere decir que el coordinador siempre ser´ prioritario, a acontinuaci´n los routers conectados directamente a ´l y as´ en adelante. Si varios can- o e ıdidatos cumplen las mismas condiciones el dispositivo que intenta unirse a la red puedeelegir libremente entre ellos. Durante el procedimiento de uni´n a la red, el dispositivo debe enviar su direcci´n IEEE o oal candidato al dispositivo padre. El dispositivo padre guardar´ en su lista de direcciones adicha direcci´n IEEE, le asociar´ una direcci´n corta y, acto seguido, enviar´ esta direcci´n o a o a ocorta al dispositivo. En adelante ambos dispositivos, padre e hijo, utilizar´n esta direcci´n a ocorta para comunicarse. Cuando un dispositivo hijo pierde la conexi´n con su dispositivo padre, puede solicitar ouna reasociaci´n con ´ste. El procedimiento es id´ntico al que acabamos de describir o e eexcepto por el detalle de que, aunque el dispositivo padre haya cambiado su configuraci´n oy ya no acepte a otros dispositivos unirse a ´l, permitir´ asociarse al dispositivo hijo puesto e aque no se trata de una nueva asociaci´n. Otra opci´n cuando el dispositivo hijo ha perdido o ola conexi´n con el dispositivo padre es solicitar a la capa MAC realizar un ”escaneo de canal opor dispositivo hu´rfano”. Cuando la capa MAC de un dispositivo hu´rfano realiza este e eprocedimiento env´ su direcci´n IEEE. Cuando el padre recibe dicha direcci´n comprueba ıa o oque dicho dispositivo era su hijo y le responde indicando su antigua direcci´n corta, con olo que se considera que la conexi´n se ha recuperado. oTablas de vecindad Un dispositivo debe guardar informaci´n de cada uno de los dispositivos dentro de su orango de alcance. Esta informaci´n es almacenada en la tabla de vecindad. Dicha tabla es o
  • 54. 3.5. CAPA DE RED 31de utilidad en diferentes contextos. Primero, cuando un dispositivo intenta unirse a la redutiliza esta tabla para realizar el listado de candidatos a dispositivos padre, como hemosvisto en el punto anterior. Segundo, una vez asociado, esta tabla se utiliza para almacenarpar´metros relacionados con la calidad del enlace, tipo de relaci´n y dem´s informaci´n a o a oreferente a los dispositivos dentro de nuestro rango de alcance. La tabla de vecindad debeser actualizada cada vez que recibimos una trama proveniente del otro dispositivo. Los par´metros que se almacenan en esta tabla para cada uno de los distintos dis- apositivos son: direcci´n IEEE, direcci´n corta, tipo de dispositivo, relaci´n con dicho o o odispositivo (el dispositivo es el padre, hijo, hijo asociado a un padre com´n, antiguo hijo, uetc), LQI (Link Quality Indicator ), n´mero de saltos hasta dicho dispositivo, permiso de uasociaci´n, si ha sido seleccionado como candidato a padre, etc. oMecanismo distribuido de asignaci´n de direcci´n corta o o Cuando un dispositivo padre (coordinador o router ) recibe la petici´n de conexi´n por o oparte de otro dispositivo (candidato a dispositivo hijo), el dispositivo padre debe asignarleuna direcci´n corta. o Este algoritmo se basa en la generaci´n de subgrupos de direcciones. El coordinador oelige la primera direcci´n libre, 0x0000. A continuaci´n, asigna un subgrupo de las direc- o ociones restantes a cada uno de sus hijos con capacidades de router. Cada uno de esos hijostendr´ como direcci´n propia la primera del subgrupo que le ha sido asignado, teniendo las a orestantes direcciones disponibles para repetir el proceso con los dispositivos hijos que seconecten a ´l. Una vez asignados estos subgrupos de direcciones a los routers, se asignan elas direcciones a los dispositivos finales, comenzando por la primera direcci´n libre. o Para calcular el tama˜o de estos subgrupos de direcciones se tienen en cuenta ciertos npar´metros de la red definidos por el coordinador: m´ximo n´mero de hijos que un padre a a upuede tener (nwkMaxChildren o Cm ), m´xima profundidad de la red (nwkMaxDepth o Lm ) ay m´ximo n´mero de routers que un padre puede tener como hijos (nwkMaxRouters o Rm ). a uTeniendo en cuenta que d es la profundidad de un determinado dispositivo [16] (n´mero ude saltos necesarios por el camino m´s corto hasta llegar al coordinador, 0 ≤ d ≤ Lm ) adefinimos la funci´n Cskip(d) como sigue: o   1 + Cm · (Lm − d − 1) si Rm = 1 Cskip(d) = (3.3)  1+Cm −Rm −Cm ·Rm 1−Rm en otro caso Cskip(d) es el tama˜o del subgrupo de direcciones asignado a cada hijo de dicho ndispositivo. Si el resultado de la expresi´n anterior es negativo, se asume que Cskip(d) = 0, oen cuyo caso el dispositivo no puede tener dispositivos hijo. Formalmente, las direccionesasignadas a los dispositivos finales vienen dadas por la siguiente expresi´n, donde Direcn oes la direcci´n asignada al hijo n´mero n y Direcpadre es la direcci´n de su dispositivo o u o
  • 55. 32 CHAPTER 3. ZIGBEE/802.15.4 Profundidad en la red, d Cskip(d) 0 31 1 7 2 1 3 (= Lm ) 0 Tabla 3.2: Ejemplo de tama˜o de subgrupos de direcciones npadre: Direcn = Direcpadre + Cskip(d)Rm + n (3.4) En la definici´n del est´ndar ZigBee [16] podemos ver un ejemplo de dicho algoritmo. o aEn ´l, para todos los dispositivos de la red: Cm = 8, Rm = 4 y Lm = 3. En la tabla e3.2 podemos ver el tama˜o de los subgrupos de direcciones, Cskip(d), para los distintos nvalores de profundidad. En la figura ?? podemos ver una representaci´n de dicha red. o Adem´s de este, es importante mencionar que existe otro mecanismo de asignaci´n de a odirecciones. Su nombre es mecanismo estoc´stico de asignaci´n de direcci´n [16]. En ´l, a o o etodas las direcciones (excepto la del coordinador, que sigue siendo la 0x0000) se asignan de ´manera aleatoria. Unicamente ZigBee PRO soporta el mecanismo estoc´stico de asignaci´n a ode direcci´n. oAbandonar una red A la hora de abandonar una red se pueden dar dos casos distintos: el padre decide queun hijo debe abandonar la red o el hijo comunica al padre que quiere abandonar la red.En ambos casos el dispositivo padre debe actualizar su tabla de vecindad de forma que eldispositivo eliminado no aparezca en ella.Encaminamiento El coordinador de red y los routers tienen la opci´n de crear tablas de encaminamiento. oDichas tablas contienen datos como la direcci´n corta del destino, el estatus de la ruta, o ola direcci´n corta del siguiente dispositivo en la ruta. o Para calcular la mejor ruta posible se usa un algoritmo que se basa en el ”coste” de uncamino determinado. El coste se puede calcular teniendo en cuenta el n´mero de saltos unecesario y la calidad de los enlaces (usando el indicador LQI).
  • 56. 3.5. CAPA DE RED 33 Figure 3.12: Ejemplo de red mostrando el Cskip(d) y las direcciones de red3.5.3 Formato de trama El formato general de trama de capa de red se muestra en la figura 3.13. Figure 3.13: Formato general de trama de red La trama est´ formada por: a ˆ Campo de control de trama. Est´ compuesto por 16 bits que indican el tipo de a trama, la versi´n del protocolo y si se est´ empleando seguridad en la transmisi´n, o a o principalmente. ˆ Direcci´n corta de destino. El valor 0xFFFF se usa para enviar el paquete a o todos los nodos dentro del rango de alcance. ˆ Direcci´n corta de origen. o ˆ Radio. Cada dispositivo que reciba la trama restar´ uno al valor de esta variable. a As´ podremos limitar el m´ximo n´mero de saltos de la trama. ı a u ˆ N´ mero de secuencia. Gracias a la direcci´n origen y al n´mero de secuencia se u o u puede identificar una trama de forma un´ ıvoca.
  • 57. 34 CHAPTER 3. ZIGBEE/802.15.4 ˆ Direcci´n IEEE destino. Su uso es opcional y es indicado en el campo de control o de trama. ˆ Direcci´n IEEE origen. Su uso es opcional y es indicado en el campo de control o de trama. ˆ Campo de control Multicast. Su uso es opcional y es indicado en el campo de control de trama. Define par´metros necesarios para la transmisi´n multicast. a o ˆ Subtrama de ruta origen. Su uso es opcional y es indicado en el campo de control de trama. ˆ Carga util. ´3.6 Capa de aplicaci´n o3.6.1 Descripci´n general o La capa de aplicaci´n ZigBee est´ compuesta por la subcapa de soporte de aplicaci´n o a o(APS), el marco de aplicaci´n (application framework ) y el objeto de dispositivo ZigBee o(ZigBee Device Object o ZDO). En la figura 3.14 podemos ver una representaci´n de la ocapa de aplicaci´n y sus diferentes partes. o Figure 3.14: Capa de aplicaci´n o En el siguiente subapartado explicaremos cada una de las partes que componen lacapa de aplicaci´n ZigBee. No obstante, antes es necesario explicar el significado de varios ot´rminos bastante recurrentes a la hora de hablar de la capa de aplicaci´n: e o ˆ Perfil de aplicaci´n. Describe el intercambio de mensajes de un conjunto de o dispositivos empleados para una determinada aplicaci´n. Por ejemplo, el perfil de o
  • 58. ´3.6. CAPA DE APLICACION 35 aplicaci´n que define un sistema de dom´tica es distinto al que define un sistema de o o control de sensores para la industria. ˆ Cluster. Es un conjunto de atributos que se utilizan en la comunicaci´n de los o distintos dispositivos ZigBee. Por ejemplo, dentro de un sistema de dom´tica, se o puede definir un cluster para el control de luces, otro para el control de temperatura, etc. ˆ Punto de acceso (endpoint). Dentro de un mismo dispositivo, se pueden definir varios puntos de acceso. Cada uno de estos puntos de acceso gestiona el fun- cionamiento de una aplicaci´n diferente. Siguiendo con el ejemplo del sistema de o dom´tica, un router que funcione como control remoto puede tener un punto de o acceso para el manejo del sistema de alarmas, otro para el control de luces, otro para el de temperatura, etc. ˆ V´ınculo (binding ). Es una conexi´n l´gica entre un punto de acceso origen y uno o o o varios de destino. S´lo se puede realizar un v´ o ınculo entre puntos de acceso que compartan el mismo cluster. Ya que un dispositivo puede poseer varios puntos de acceso, tambi´n puede soportar varios v´ e ınculos.3.6.2 SubcapasSubcapa de soporte de aplicaci´n (APS o Application Sublayer ) o La subcapa de soporte de aplicaci´n proporciona una interfaz de comunicaci´n entre o ola capa de red y la capa de aplicaci´n. Las tareas que realiza esta capa son: o ˆ Genera la PDU a nivel de aplicaci´n. o ˆ Una vez los puntos de acceso de dos dispositivos est´n vinculados, la capa APS es a la encargada de gestionar el intercambio de mensajes. ˆ Mejorar la fiabilidad de la capa de red. Por ejemplo, se puede definir una confirma- ci´n ack a nivel de aplicaci´n. o o ˆ Rechaza mensajes recibidos por duplicado.Marco de aplicaci´n (AF o Application Framework ) o El marco de aplicaci´n es el entorno en el cual se gestionan las diferentes aplicaciones. oCada una de dichas aplicaciones est´ relacionada a un punto de acceso distinto. a Se permiten hasta 240 aplicaciones distintas dentro de un mismo dispositivo. El puntode acceso 0 est´ asignado al nivel ZDO. El rango de 241-254 est´ reservado para uso futuro. a aPor ultimo, el punto de acceso 255 es usado para la comunicaci´n broadcast con todas las ´ oaplicaciones dentro del marco de aplicaci´n. o
  • 59. 36 CHAPTER 3. ZIGBEE/802.15.4 Esta capa es la encargada de definir tanto el perfil de aplicaci´n como los diferentes oclusters. Cada cluster se caracteriza por un identificador propio (cluster ID).Objeto de dispositivo ZigBee (ZDO o ZigBee Device Object) Este nivel satisface necesidades comunes a todas las aplicaciones dentro del marco deaplicaci´n. Las tareas que realiza son: o ˆ Inicializar las capas APS y de red. ˆ Definir el rol del dispositivo dentro de la red (coordinador, router o dispositivo final). ˆ Gestiona los v´ ınculos entre puntos de acceso. ˆ Asegura una comunicaci´n segura entre dispositivos. o Como hemos dicho anteriormente, el ZDO se encuentra en el punto de acceso 0.3.6.3 Formato de trama El formato general de trama de capa de aplicaci´n se muestra en la figura 3.15. o Figure 3.15: Formato general de trama de aplicaci´n o La trama est´ compuesta por: a ˆ Campo de control de trama. Est´ formado por 8 bits que indican el tipo de a trama, si se utiliza seguridad, si estamos empleando la extensi´n de cabecera y si se o requiere confirmaci´n ack a nivel de aplicaci´n. o o ˆ Direcci´n del punto de acceso destino. o ˆ Direcci´n de grupo. Si se usa direccionamiento de grupo la trama no debe incluir o la direcci´n del punto de acceso destino. Todos los puntos de acceso asociados a la o direcci´n de grupo en cuesti´n recibir´n esta trama. o o a ˆ Cluster ID. Identificador de cluster. ˆ Perfil ID. Identificador del perfil de aplicaci´n. o
  • 60. 3.7. SEGURIDAD 37 ˆ Direcci´n del punto de acceso origen. o ˆ Contador APS. Se usa para evitar la recepci´n de tramas duplicadas. o ˆ Extensi´n de cabecera. Extiende la funcionalidad de la cabecera. o ˆ Carga util. ´3.7 Seguridad Desde el punto de vista de la seguridad, las redes inal´mbricas son altamente vulner- aables debido a que no se requiere tener acceso a un medio cableado para participar enlas comunicaciones. ZigBee/802.15.4 est´ orientado hacia un mercado en el que el bajo aconsumo y el bajo coste son requisitos esenciales.Debido a la restricci´n en lo que al coste ose refiere, los dispositivos que trabajan con esta tecnolog´ se enfrentan a una limitaci´n ıa ocomputacional evidente. Esto quiere decir que los sistemas de seguridad son mas dif´ ıcilesde implementar en sistemas que trabajan bajo ZigBee/802.15.4. Adem´s, a la hora de aimplementar mecanismos de seguridad para ZigBee/802.15.4 se ha tenido en cuenta quelos dispositivos no tienen por qu´ tener acceso a una base de datos de forma continua. eDe esta forma, los distintos dispositivos deben ser capaces de gestionar los mecanismosde seguridad por s´ mismos. Por ultimo, es importante destacar que ZigBee/802.15.4 est´ ı ´ aorientado hacia el env´ de peque˜os paquetes de informaci´n, por lo que los mecanismos ıo n ode seguridad utilizados no deber´ aumentar en exceso el tama˜o de la cabecera. En los ıan nest´ndares ZigBee [16] y 802.15.4 [15] se definen mecanismos de seguridad para las capas aMAC, de red y de aplicaci´n. El mecanismo criptogr´fico utilizado se basa en el uso de o aclaves sim´tricas. La clave en cuesti´n debe ser generada por las capas superiores. El e omecanismo criptogr´fico debe ser capaz de asegurar: a ˆ Confidencialidad de los datos o privacidad. Esto quiere decir que la informaci´n o transmitida s´lo de llegar a los dispositivos asociados a la red. o ˆ Autentificaci´n de los datos. Se debe asegurar que la informaci´n recibida proviene o o de un dispositivo v´lido (en otras palabras, no ha habido intromisi´n en las comuni- a o caciones). ˆ Detecci´n de informaci´n duplicada. Los paquetes de informaci´n deben de ser o o o recibidos unicamente una vez. ´ De acuerdo al est´ndar [15] la clave utilizada puede ser conocida por los dos dispositivos aque participan en la comunicaci´n o por un grupo de dispositivos. Si utilizamos una unica o ´clave para un grupo de dispositivos ganamos en simplicidad pero, por contra, estamosdesprotegidos ante el ataque de un dispositivo de la propia red. ZigBee/802.15.4 usa el modo de funcionamiento CCM*, una variante del modo CCM(Counter with CBC-MAC ). CCM* usa bloques de cifrado basados en el algoritmo AES-128 (Advanced Encryption Standard ). AE5-CCM* es un algoritmo sim´trico, lo que quiere edecir que tanto el dispositivo que transmite como el que recibe usan la misma clave paradescifrar el mensaje.
  • 61. 38 CHAPTER 3. ZIGBEE/802.15.4 Figure 3.16: Formato de trama con seguridad habilitada - Capa MAC Figure 3.17: Formato de trama con seguridad habilitada - Capa de red En caso de que la seguridad est´ habilitada, el coordinador es normalmente el que erealiza las funciones de centro de seguridad, permitiendo o no la asociaci´n de un nuevo odispositivo. El centro de seguridad debe actualizar peri´dicamente la clave utilizada, ocambi´ndola por una nueva si lo estima necesario. Para ello, distribuye la nueva clave acifrada con la antigua. Despu´s comunica a todos los dispositivos que a partir de ese emomento deben usar la nueva clave. El centro de seguridad, que como hemos dicho suele ser el coordinador pero que tambi´nepuede ser un dispositivo expresamente dedicado a ello, realiza las siguientes funciones: ˆ Autentificar dispositivos que quieren unirse a la red. ˆ Generar y distribuir nuevas claves. ˆ Habilitar el uso de seguridad punto a punto entre dispositivos. ZigBee/802.15.4 usa tres tipos de claves: ˆ Claves de enlace. Sirven para dotar de seguridad las comunicaciones punto a punto a nivel de aplicaci´n. S´lo los dos dispositivos que participan en la comunicaci´n o o o conocen esta clave. ˆ Claves de red. Esta clave se usa para la seguridad a nivel de red. Todos los dispositivos dentro de una misma red deben compartir esta clave. ˆ Claves maestro. Esta clave es utilizada por dos dispositivos en el inicio de la comunicaci´n para generar la clave de enlace. La clave maestro no se usa para o encriptar tramas. Se definen dos tipos de seguridad: Figure 3.18: Formato de trama con seguridad habilitada - Capa de aplicaci´n o
  • 62. 3.7. SEGURIDAD 39 ˆ Modo de seguridad est´ndar. En este modo la lista de dispositivos pertenecientes a a la red y las diferentes claves pueden estar almacenadas dentro de cada uno de los distintos dispositivos. El centro de seguridad solamente se encarga de mantener una clave de red com´n y de controlar las pol´ u ıticas de admisi´n. As´ el centro de o ı, seguridad no necesita una gran memoria para almacenar los datos relacionados con la seguridad de la red. ˆ Modo de seguridad avanzado. En este caso el centro debe almacenar tanto las claves como el listado de dispositivos, as´ como de controlar las pol´ ı ıticas de admisi´n. Conforme crezca el n´mero de dispositivos asociados a la red, aumentar´n o u a los requerimientos de memoria del centro de seguridad. Solamente ZigBee PRO soporta este modo de seguridad. Las diferentes capas a˜adir´n una cabecera auxiliar en el caso de que utilicemos un n amodo seguro de transmisi´n. Adem´s, se debe incluir un c´digo de integridad (MIC o o a oMessage Integrity Code) a continuaci´n de la carga util. (Figuras 3.16, 3.17 y 3.18). o ´
  • 63. 40 CHAPTER 3. ZIGBEE/802.15.4
  • 64. Chapter 4PLATAFORMA DE ´SIMULACION Hasta el presente cap´ıtulo hemos querido definir un marco de contexto presentando unaserie de objetivos bajo unos determinados requisitos o limitaciones (cap´ ıtulo 1). Hemosrealizado un estudio sobre el estado del arte, o situaci´n actual de las diferentes tecnolog´ o ıasexistentes equiparables a la aqu´ seleccionada en este proyecto (cap´ ı ıtulo 2), y hemos pro-fundizado en los aspectos t´cnicos que describen y definen los est´ndares acerca de esta e atecnolog´ (cap´ ıa ıtulo 3). El siguiente paso ser´ presentar las herramientas que utilizaremos para llevar a cabo alas diferentes simulaciones que realizaremos. Como adelantamos en el primer cap´ ıtulo, elescenario real en el que deber´ıamos realizar los diferentes estudios puede ser demasiadocomplejo, extenso y, en definitiva, con unos costes que se escapan a este proyecto. Por ello,es necesario plantear una serie de simulaciones, que nos permiten aproximar resultados alos que pudieran devolverse de una ejecuci´n real. o Por un lado, dado que trabajaremos con dispositivos de comunicaci´n inal´mbrica, que o atienen soporte para un protocolo est´ndar de comunicaci´n como es IEEE 802.15.4, nece- a ositaremos una herramienta de simulaci´n capaz de ofrecer la arquitectura necesaria para ocrear redes de comunicaci´n, con soporte para diferentes protocolos de comunicaci´n, que o oofrezca utilidades de depuraci´n y trazabilidad de datos, extracci´n de estad´ o o ısticas y flex-ibilidad a la hora de adaptar cualquier elemento que en ella exista a nuestras necesidades. Por otro lado, estos dispositivos ir´n montados en veh´ a ıculos que podr´n moverse con atotal libertad a lo largo de un escenario. Se desprende inmediatamente la necesidad decontar con una herramienta de simulaci´n de tr´fico de veh´ o a ıculos que ofrezca, adem´s, aintegraci´n o soporte para la herramienta de simulaci´n que hemos mencionado anteri- o oormente. Adem´s, de la misma manera, deber´ tratarse de una aplicaci´n flexible en a ıa oconfiguraci´n de escenarios, facilidad en creaci´n de flujos de tr´fico vehicular y compor- o o atamiento aleatorio de veh´ıculos. 41
  • 65. 42 ´ CHAPTER 4. PLATAFORMA DE SIMULACION A continuaci´n presentamos diferentes alternativas que podemos encontrar, tanto para ola simulaci´n de redes de comunicaci´n, como para simulaci´n de tr´fico vehicular. o o o a4.1 Simuladores para VANETs En esta secci´n presentaremos varias alternativas de libre distribuci´n para la sim- o oulaci´n de redes VANET que tienen buena acogida entre la comunidad cient´ o ıfica. Ennuestro estudio, excluiremos algunas aplicaciones como TSIS-CORSIM [18], Paramics [19],Carisma [20], VISSIM [21], QualNet [22], u OPNET [23], todas ellas de licencia propietaria.Nos centramos en las herramientas freeware y de c´digo abierto que permiten disponer del oc´digo fuente en el caso de tener que realizar ciertas modificaciones o adaptaciones. o En la figura 4.1 podemos observar la relaci´n de herramientas y compatibilidades en- otre ellas, separadas por diferentes categor´ ıas. As´ tenemos: (a) generadores de tr´fico ı, avehicular, (b) simuladores de redes de comunicaci´n, y (c) simuladores VANET. o Figure 4.1: Relaci´n de aplicaciones de simulaci´n para VANETs o o Los generadores de tr´fico vehicular permiten obtener comportamientos y flujos de atr´fico con unos niveles de realismo mucho mayores en las simulaciones VANET. Generan atrazas o registros de movilidad que ser´n utilizados como fuente de datos por parte de alos simuladores de redes de comunicaci´n. A su vez, los generadores de tr´fico vehicular o adeben tomar unos par´metros de entrada sobre los cuales se definan aspectos indicativos acomo velocidad m´xima de cada veh´ a ıculo, puntos de inicio y llegada de cada uno deellos, definici´n de intersecciones y control de tr´fico. . . Ejemplos de estos generadores de o atr´fico vehicular son SUMO [24], MOVE [25], CityMob [26], STRAW [27], FreeSim [28], aNetstream [29], o VanetMobySim [30]. Por su parte, los simuladores de redes de comunicaci´n permiten ejecutar escenarios ovirtuales de comunicaci´n de forma muy aproximada a un escenario real, respetando las ocaracter´ısticas y comportamientos que pudieran tener los diferentes elementos de una reddentro de la simulaci´n, como pudieran ser valores e implementaciones sobre direcciones de ored fuente y destino, formatos de paquetes de datos, protocolos de comunicaci´n y trans- omisi´n de datos, recepci´n, carga de fondo, ruta, enlaces, canales. . . Entre estas herramien- o otas de simulaci´n podemos encontrar ns-2 [31], GloMoSim [32], SNS[33], o JiST/SWANS o
  • 66. ´4.2. GENERADORES DE TRAFICO VEHICULAR 43[34], o GTNetS [35]. Este tipo de aplicaciones est´n concebidas para la realizaci´n de simulaciones de re- a odes m´viles MANET (Mobile ad-hoc NETworks), como pueden ser las redes de telefon´ o ıam´vil. Para aproximar estas herramientas a aplicaciones de simulaci´n de redes VANETs o opuras, deben adaptarse a trav´s de diferentes extensiones o plugins para integrarse con las eaplicaciones de simulaci´n de redes vehiculares. o Por ultimo, y como simuladores de redes VANETs puros, en los cuales las dos partes for- ´man una aplicaci´n completa, tanto de simulaci´n de red de comunicaci´n como de red de o o otr´fico vehicular, podemos encontrar las siguientes: TraNS [36], NCTUns [37], GrooveNet a[38], o MobiREAL [39]. En las pr´ximas secciones vamos a discutir en profundidad sobre olas caracter´ ısticas y funcionalidades de cada una de ellas.4.2 Generadores de tr´fico vehicular a Los generadores de tr´fico vehicular permiten aumentar los niveles de realismo en las asimulaciones VANETs. En esta secci´n presentaremos los diferentes modelos de tr´fico o avehicular y las diferentes herramientas existentes junto con una comparativa entre ellas.4.2.1 Modelos de tr´fico vehicular a El modelado de tr´fico vehicular es un ´rea de investigaci´n muy conocida en inge- a a onier´ civil o ingenier´ de caminos y es crucial a la hora de dise˜ar correctamente las ıa ıa ndiferentes v´ de carreteras e intersecciones [40]. En este campo, un modelo de tr´fico ıas apuede clasificarse como mesosc´pico, macrosc´pico o microsc´pico, dependiendo del nivel o o ode granularidad o detalle con el que se examinan los flujos de tr´fico. a En este sentido, un modelo microsc´pico describe el comportamiento y caracter´ o ısti-cas individuales de cada veh´ ıculo, mientras que los modelos macrosc´picos nos permiten oestudiar el comportamiento t´ ıpico de grupos de veh´ ıculos a mayor escala. Los modelosmesosc´picos combinan propiedades tanto de los microsc´picos como de los macrosc´pi- o o ocos. En las simulaciones de escenarios VANET, de la misma forma que pudiera ocurrir enun entorno real, la transmisi´n de ondas de radio es muy dependiente de las posiciones ode los diferentes nodos y es por ello que se requiere una gran exactitud en el c´lculo de alas mismas. Dado que en los modelos macrosc´picos y mesosc´picos ese nivel de detalle o ono se alcanza, nos encontramos con que los modelos microsc´picos son los m´s adecuados o apara la realizaci´n de estas simulaciones, en los que los comportamientos de veh´ o ıculosindividuales y las interacciones entre ellos cobran mayor peso. Modelos conocidos y quehan adquirido peso en la comunidad cient´ ıfica son el modelo Cellular Automaton (CA)[41], el modelo Stefan Krauss (SK) [42], y el Intelligent Driving Model (IDM) [43]. Un
  • 67. 44 ´ CHAPTER 4. PLATAFORMA DE SIMULACIONaspecto importante sobre los modelos microsc´picos es que requieren altos tiempos de oc´mputo y gran cantidad de memoria para realizar las simulaciones, donde, normalmente, odeben limitarse en tama˜o de la red o en n´mero de ejecuciones. n u Cuando trabajamos en el modelado de la movilidad vehicular es frecuente distinguirentre macro-movilidad y micro-movilidad [44]. Por macro-movilidad se entiende a aquellosaspectos macrosc´picos que influyen en el tr´fico de veh´ o a ıculos, es decir, la topolog´ de las ıacarreteras, intersecciones, el n´mero de carriles, se˜alizaci´n, normativa y seguridad vial u n o. . . Por otra parte, micro-movilidad habla sobre la interactividad del conductor con ese en-torno ya descrito, sobre c´mo afecta en ´l su comportamiento, las diferentes velocidades de o ecada veh´ ıculo, aceleraciones, frenadas, criterios de adelantamiento, patrones de conductasobre diferentes se˜alizaciones e infraestructuras viales, edad de los conductores, estado de na´nimo, etc. Estas dos terminolog´ llevadas a la pr´ctica dentro de simulaciones VANET, ıas, adeben ser tenidas muy en cuenta como un t´ndem indivisible. a4.2.2 Generadores de Movilidad A continuaci´n presentamos varias aplicaciones software capaces de generar trazas de omovilidad para la realizaci´n de simulaciones VANET. o ˆ VanetMobiSim[30] es una extensi´n del entorno de simulaci´n CANU (CanuMo- o o biSim) que se centra en la movilidad vehicular. Genera trazas de movimientos ve- hiculares realistas tanto en niveles macrosc´picos como en microsc´picos. Para la o o aproximaci´n en el nivel macrosc´pico, VanetMobiSim puede importar los mapas o o codificados en formato TIGER de la Oficina del Censo de los EE.UU. o generar de forma aleatoria un escenario mediante la t´cnica de teselaci´n de Voronoi [17]. e o La codificaci´n en bases de datos TIGER permite almacenar cualidades geogr´ficas o a tales como carreteras, ferrocarriles, r´ lagos, l´ ıos, ımites legales, etc. VanetMobiSim permite a˜adir caracter´ n ısticas extras tales como flujos direccionales, un n´mero de- u terminado de carriles a cada v´ limitaciones de velocidad, se˜alizaciones de tr´fico ıa, n a en intersecciones, . . . A nivel microsc´pico, es compatible con diferentes modelos de o movilidad, como el Modelo de Conducci´n Inteligente con Administraci´n de Inter- o o secciones (IDM/IM - Intelligent Driving Model with Intersection Management), el Modelo de Conducci´n Inteligente con Cambio de Carril (IDM/LC - Intelligent Driv- o ing Model with Lane Changing) y con un modelo de adelantamientos (MOBIL), que interact´a con IDM/IM para gestionar los cambios de carril y las aceleraciones y fre- u nadas de cada veh´ ıculo, proporcionando interacciones realistas veh´ ıculo-a-veh´ ıculo y veh´ıculo-infraestructura. VanetMobiSim est´ basado en Java y puede generar trazas a de movilidad en diferentes formatos. ˆ MOVE (MObility model generator for VEhicular networks)[25] es un generador r´pido de flujos realistas de movilidad vehicular para redes VANET. MOVE es uti- a lizado en el nivel superior de la aplicaci´n SUMO. Genera trazas de movilidad que o puden ser utilizadas directamente sobre las herramientas de simulaci´n de red m´s o a conocidas, tales como ns-2 o GloMoSim. Adem´s, MOVE ofrece un entorno gr´fico a a (GUI) que permite al usuario generar r´pidamente escenarios realistas de simulaci´n a o sin necesidad de recurrir a tediosas l´ ıneas u ´rdenes de ejecuci´n. o o
  • 68. ´4.2. GENERADORES DE TRAFICO VEHICULAR 45 ˆ STRAW (STreet RAndom Waypoint)[27] ofrece trazas precisas de simulaci´n me- o diante el uso de un modelo de movilidad vehicular real, basado en descripciones de tr´fico reales de ciudades de los Estados Unidos. STRAW est´ desarrollada para el a a simulador de eventos discretos JiST/SWANS, y sus trazas de movilidad no puede ser utilizadas directamente por los simuladores de red mencionados anteriormente (ns-2 o GloMoSim). STRAW es parte del proyecto C3 (Car-toCar-Cooperation) [45]. Un modelo de movilidad realista con un alto nivel de detalle es crucial para una simu- laci´n de red VANET precisa. El modelo de movilidad STRAW limita el movimiento o de los nodo a las calles definidas en los mapas reales de las ciudades de los Estados Unidos, y limita su movilidad de acuerdo con la congesti´n vehicular y mecanismos o simplificados de control de tr´fico. a ˆ FreeSim [28] es un simulador de tr´fico opensource que abarca tanto el nivel mi- a crosc´pico como el macrosc´pico facilitando las tareas de simulaci´n al presentar un o o o entorno gr´fico con soporte para flujos de tr´fico sobre v´ multicarril, con defini- a a ıas ci´n de velocidades en cada uno de ellos. Los algoritmos de simulaci´n del tr´fico o o a pueden ser aplicados sobre toda la red o individualmente sobre cada veh´ıculo o nodo. El origen de los datos o trazas de simulaci´n pueden ser generados por el usuario o u obtenidos en tiempo real por determinadas organizaciones de transporte. De esta forma, los veh´ ıculos que son generados dentro de FreeSim pueden comunicarse con los sistemas de monitorizaci´n del tr´fico en las autopistas, obteni´ndose as´ un en- o a e ı torno de simulaci´n muy bueno para los sistemas de transporte inteligente (ITS). o Adem´s, como hab´ a ıamos indicado, FreeSim es un producto de licencia abierta y su c´digo fuente est´ disponible para su descarga. o a ˆ CityMob v.2 [26] CityMob es un generador de modelos de movilidad compatible con ns-2 para la simulaci´n en redes VANETs. CityMob implementa tres modelos difer- o entes de movilidad: (a)Simple Model (SM), (b)Manhattan Model (MM), y (c)realistic Downtown Model (DM). En el modelo DM, las calles son dibujadas sobre una ret´ ıcula de tipo Manhattan, con un tama˜o de bloque uniforme para cada una de las inter- n secciones que lo componen. Todas las calles son de doble sentido. Los veh´ ıculos pueden moverse a lo largo de ellas con una velocidad aleatoria, siempre dentro de unos l´ımites impuestos por el usuario. El modelo DM tiene capacidad para simular se˜alizaciones din´micas, como sem´foros, con un comportamiento pseudoaleatorio, n a a a lo largo de los diferentes cruces del mapa. DM a˜ade, adem´s, densidades de n a tr´fico de forma similar a como podemos encontrarlas en una ciudad real, en donde a dicha densidad no se ajusta a un patr´n uniforme. CityMob DM tiene, por tanto, las o siguientes caracter´ısticas: (a) m´ltiples carriles en ambas direcciones para todas las u calles, (b) capacidad de simular retenciones de veh´ ıculos y (c) capacidad de manejar m´ltiples puntos de congesti´n. u o4.2.3 Simuladores de redes de comunicaci´n o A continuaci´n presentamos varias herramientas de simulaci´n de redes de comuni- o ocaci´n frecuentemente usadas para redes VANET’s. o ˆ ns-2 [31] es un simulador de eventos discretos desarrollado por el grupo del proyecto VINT de la Universidad de California, en Berkeley. El simulador fue extendido por el grupo de investigaci´n Monarca en la Universidad de Carnegie Mellon para incluir: o
  • 69. 46 ´ CHAPTER 4. PLATAFORMA DE SIMULACION (a) movilidad en nodos, (b) una capa f´ısica realista con modelo de radiopropagaci´n, o (c) interfaces de redes de radio y (d) el protocolo de acceso al medio (MAC) IEEE 802.11 usando la funci´n de coordinaci´n distribuida (DCF). No obstante ns-2 ten´ o o ıa importantes deficiencias tanto en la arquitectura general como en detalles del modelo que implementaba el protocolo IEEE 802.11 a nivel MAC y f´ ısico. En la referencia [46], los autores presentan una arquitectura totalmente revisada y nuevos dise˜os de n estos dos m´dulos. o ˆ GloMoSim [32] es un entorno de simulaci´n escalable para redes cableadas e in- o al´mbricas. Se apoya en simulaciones de eventos discretos que ofrec´ Parsec [47]. a ıa GloMoSim ha sido implementado utilizando una aproximaci´n similar a la s´ptima o e capa de la pila de protocolo de comunicaci´n de OSI. Se utilizan, de esta forma, APIs o de comunicaci´n est´ndares entre las diferentes capas de simulaci´n. Esto permite o a o una r´pida integraci´n con modelos desarrollados en diferentes capas y por difer- a o entes equipos o personas. Una alternativa comercial del simulador GloMoSim es la aplicaci´n QualNet. o ˆ JiST/SWANS [34]. JiST es un simulador de eventos discretos de alto rendimiento cuyo n´cleo corre sobre una m´quina virtual de Java. Se trata de un prototipo para u a la creaci´n de simuladores de eventos discretos, de prop´sito general, que unifica los o o sistemas tradicionales con los lenguajes orientados a simuladores de eventos, ofre- ciendo mejoras en tiempo y consumo de memoria. El c´digo de simulaci´n que se o o ejecuta en JiST no necesita ser escrito en un lenguaje espec´ ıfico destinado a tal prop´sito, sino que se apoya en el lenguaje de programaci´n Java para, mediante la o o compilaci´n previa, ofrecer a la m´quina virtual un lenguaje ”byte-code”. SWANS o a es un simulador escalable de redes inal´mbricas, emplazada en los niveles superiores a de JiST. Se trata de una extensi´n sobre JiST, que cubre nuevas necesidades que o originalmente no se contemplaban. SWANS contiene componentes software inde- pendientes que pueden combinarse para formar una completa red inal´mbrica o de a sensores. Estas capacidades son similares a las que ofrece ns-2 o GloMoSim, pero, a su favor, SWANS es capaz de realizar simulaciones con redes m´s grandes. Para a ello, SWANS aprovecha las ventajas de JiST, en cuanto a mejora de rendimiento en simulaci´n, menores requisitos en memoria, y la potencia que ofrece un lenguaje o concurrente y distribuido como es Java. Cuantitativamente, esta ventaja se traduce en una capacidad de simulaci´n de redes con uno o dos ´rdenes de magnitud mayo- o o res que las que puede contemplar GloMoSim o ns-2, respectivamente, utilizando los mismos recursos de memoria y tiempo, para el mismo nivel de detalle. ˆ SNS (a Staged Network Simulator - Simulador de redes por etapas) [33]. Los simu- ladores de redes de comunicaci´n tradicionales est´n limitados en velocidad o escala, o a ya que realizan una gran cantidad de operaciones repetitivas y concurrentes dentro de una unica simulaci´n. La t´cnica de simulaci´n por etapas [48] tiene el objetivo ´ o e o de eliminar ese tipo de c´lculos repetitivos o redundantes a trav´s del uso de cach´s a e e que agilicen la reutilizaci´n del resultado de esas operaciones. SNS est´ basado en o a ns-2. Comparativamente, en una ejecuci´n de una red ad-hoc con 1500 nodos, SNS o se ejecuta aproximadamente 50 veces m´s r´pido que ns-2 y el 30œde esta mejora es a a debido a la t´cnica de ”staging” y el resto a la ingenier´ Este nuevo nivel de mejora e ıa. permite a SNS simular grandes escenarios. No obstante, la tendencia de ns-2 en su enfoque no lo hace apropiado para simular redes VANET.
  • 70. 4.3. SIMULADOR DE REDES OMNET++ 474.3 Simulador de redes OMNeT++ El simulador de eventos discretos OMNeT++ [49], est´ disponible desde 1997. La aconcepci´n de OMNeT++ fue implementar un simulador gen´rico que pudiera exten- o ederse modularmente para hacerlo espec´ ıfico para ´reas como redes de comunicaciones, sis- atemas multiprocesador y sistemas distribuidos. Este entorno ha sido usado desde entoncesprobando su eficacia para simular colas en redes de comunicaciones, redes ad-hoc, inal´m- abricas, peer-to-peer, redes de conmutaci´n ´ptica, redes de almacenamiento distribuido, o oetc. Lejos de ser punto en contra, es un punto a favor el hecho de que OMNeT sea unsimulador que ofrece un marco gen´rico para distintas ´reas de simulaci´n. Se encuentran e a odisponibles el c´digo fuente y documentaci´n, as´ como foros y listas de correo para la o o ıcolaboraci´n entre usuarios. Esto permite extender el simulador base mediante la adici´n o ode marcos de trabajo o frameworks, que a˜aden especificidad para un ´rea concreta de n asimulaci´n. Los frameworks son en s´ mismos extensibles mediante la adici´n de nuevos o ı om´dulos simples. o El dise˜o de OMNeT++ se basa en los siguientes puntos: n ˆ Permitir simulaciones a gran escala, mediante modelos jer´rquicos construidos con a componentes reutilizables. ˆ Una interfaz gr´fica orientada a la depuraci´n y verificaci´n de los modelos imple- a o o mentados. ˆ Estructura modular que permite extensibilidad y personalizaci´n, as´ como inclusi´n o ı o de componentes en aplicaciones m´s grandes de planificaci´n de red. a o ˆ Interfaces de datos abiertas, generando ficheros de definici´n y de resultados f´cil- o a mente interpretables y procesables por herramientas gen´ricas. e ˆ Proveer un entorno de desarrollo integrado que facilita el desarrollo de modelos y el an´lisis de resultados. a La base del entorno de simulaci´n es el n´cleo o kernel. En ´ste se encuentran pro- o u egramadas las funciones generales que permiten la extensi´n modular del programa para ola simulaci´n en ´reas espec´ o a ıficas mediante herencia e interfaces en C++. Dentro de cadaextensi´n o framework espec´ o ıfico se pueden definir los modelos de simulaci´n. o La definici´n de modelos en OMNeT se lleva a cabo de forma modular jer´rquica. o aExiste un m´dulo principal, por ejemplo el m´dulo de red, que engloba todos los elemen- o otos y relaciones existentes entre ellos. Debajo de este nivel, est´n los m´dulos compuestos, a oque integran sistemas y elementos f´ ısicos de la red, como pueden ser routers, servidoresWeb, hosts de usuarios finales, enlaces inal´mbricos, etc. Y finalmente, en el nivel m´s a a ıa o ´bajo de la jerarqu´ se encuentran los m´dulos simples. Estos implementan funciones conc-retas, como interfaces de red (punto-a-punto, Ethernet. . . ), protocolos espec´ ıficos (TCP,
  • 71. 48 ´ CHAPTER 4. PLATAFORMA DE SIMULACIONFTP. . . ), o canales para la conexi´n entre m´dulos (enlaces de fibra, enlaces inal´mbri- o o acos. . . ). Los m´dulos simples son la base de los modelos definidos en OMNeT++, y est´n o aimplementados en lenguaje C++. La estructura modular descrita puede observarse en la figura 4.2. Figure 4.2: Estructura modular de los modelos de OMNeT++. Por otro lado, s´lo se implementan en C++ los m´dulos simples. La definici´n de los o o omodelos de red y m´dulos compuestos se realiza mediante un lenguaje especial desarrollado opara esta funci´n, el lenguaje NED (Network Description Language). o Mediante el lenguaje NED se establece la jerarqu´ modular, la construcci´n de m´dulos ıa o ocompuestos y la asociaci´n y conexi´n entre los elementos del modelo, as´ como la definici´n o o ı ode los canales de comunicaci´n e interfaces de entrada y salida. o Una vez se tienen definidos los m´dulos a usar, ya sean m´dulos existentes previamente o oo creados para tal fin, se pasa definir topolog´ concretas sobre las que realizar una config- ıasuraci´n de elementos y m´dulos implicados. Una vez decididos los rangos de par´metros, o o ase crea un fichero inicializaci´n de topolog´ por defecto ”MNETPP.INI”, que contiene los o ıa,valores concretos de cada par´metro a usar en cada experimento y conjunto de medidas. aSe crean instancias concretas de ejecuci´n, llamadas ”runx”, y se ejecuta la simulaci´n. o o A lo largo de la simulaci´n se van produciendo una serie de eventos programados en oel tiempo dentro de la cola de espera principal. Estos eventos pueden implementar bienmensajes entre los m´dulos simples o bien automensajes para simular temporizadores. La otransmisi´n de mensajes se puede realizar entre m´dulos directamente conectados, a trav´s o o elas interfaces directas entre m´dulos simples o los canales de comunicaci´n entre objetos y o om´dulos compuestos. Tambi´n se pueden transmitir mensajes directamente entre un par o ede m´dulos cualquiera en caso de ser necesario hacer llamadas por ejemplo pasando varios oniveles de jerarqu´ıa. Durante cada ejecuci´n de la simulaci´n se obtienen resultados de salida de los distintos o om´dulos as´ como colecciones de estad´ o ı ısticas, que se van almacenando en ficheros escalaresy vectoriales para su posterior procesado y visualizaci´n en herramientas gr´ficas. Adem´s o a ael proceso de ejecuci´n permite elegir entre una interfaz textual muy r´pida o una interfaz o agr´fica m´s lenta pero especialmente dise˜ada para la depuraci´n, localizaci´n y correcci´n a a n o o ode fallos.
  • 72. 4.3. SIMULADOR DE REDES OMNET++ 494.3.1 Simulation for Urban mobility (SUMO) Una de las grandes ventajas de SUMO o Simulation of Urban Mobility es que se tratade un simulador de VANETS de c´digo abierto y gratuito desarrollado por la DLR o oDeutsche Gesellschaft f¨r Luft und Raumfahrt, es decir, el centro aeroespacial nacional ualem´n. a Se trata de un simulador que permite definir entornos de movilidad reales gracias a lautilizaci´n de mapas digitales, ofrece la posibilidad de utilizar diferentes tipos de veh´ o ıculos,carreteras que cambian en cuanto a su composici´n (carriles, velocidad, prioridades, etc.) oy un amplio abanico de posibilidades e integraci´n con otros simuladores debido a que es oc´digo abierto. o Una de las limitaciones de SUMO es el hecho de que ´ste calcula las rutas de los eveh´ ıculos antes de realizar la simulaci´n, cosa que dificulta la evaluaci´n de la comunicaci´n o o ovehicle-to-vehicle afectada por variaciones en el comportamiento de los mismos durante lapropia simulaci´n,es decir, que nos ser´ m´s dif´ evaluar a tiempo real la comunicaci´n o a a ıcil oentre veh´ıculos frente a una variaci´n provocada de su comportamiento de una forma orepentina (aceleraci´n, cambio de ruta, frenada, etc.) ya que con SUMO se tiene que oprever todo esto antes de hacer la propia simulaci´n.o¿Por qu´ SUMO? e Como hemos visto en el apartado anterior, existen varias posibilidades a la hora deescoger un simulador de tr´fico. Aunque existen varias opiniones ante la calidad de cada auna, la gran parte de los investigadores que han evaluado diferentes simuladores, coincidenen afirmar que SUMO es una herramienta que ofrece unos resultados ´ptimos y que adem´s o aes de c´digo abierto (mucha documentaci´n, gratuito, etc.) frente a la mayor´ de opciones o o ıaexistentes de pago. Como pasa en todo el software de licencia p´blica, cada uno tiene la uposibilidad de poner su grano de arena para ir mejorando y desarrollando esta herramienta,que aunque ya se encuentra entre una de las principales, es una buena apuesta a tener encuenta de cara al futuro debido a su utilizaci´n y continua mejora por parte del sector ocient´ıfico; por tanto, todas estas razones son las que han hecho que nos decidi´ramos a eutilizar SUMO.M´s sobre SUMO a En el cap´ ıtulo anterior describimos de forma generalizada las caracter´ ısticas m´s im- aportantes sobre SUMO y sus or´ ıgenes, en este apartado vamos a profundizar m´s sobre aeste simulador desarrollado en lenguaje C++, m´s concretamente en su funcionamiento. a La definici´n formal de SUMO ser´ la de un simulador de tr´fico microsc´pico, que o ıa a otrabaja en espacio continuo y con tiempo discreto.
  • 73. 50 ´ CHAPTER 4. PLATAFORMA DE SIMULACION Que SUMO es un simulador microsc´pico quiere decir que se basa en la emulaci´n o oindividual del movimiento de cada veh´ ıculo que participa en el escenario, es decir, queSUMO es capaz de adoptar un movimiento diferente a cada veh´ ıculo del escenario haciendoas´ un entorno m´s pr´ximo a la realidad, d´nde el modelo matem´tico que implementa ı a o o aeste comportamiento microsc´pico est´ desarrollado por Stefan Krauss. o a SUMO trabaja en espacio continuo en el sentido que en cada instante de tiempo discretode la simulaci´n, es decir solo en unos instantes de tiempo determinados, la posici´n de o ocada veh´ıculo est´ perfectamente descrita, es decir, que podemos saber la posici´n exacta a ode cada veh´ıculo en cualquier instante de tiempo definido en nuestra simulaci´n. o Como dijimos en el cap´ ıtulo anterior SUMO computa las rutas de los veh´ ıculos antesde realizar la simulaci´n con los posibles inconvenientes que comentamos, una vez en la osimulaci´n, los veh´ o ıculos llegan a su destino definido (por el usuario o autom´ticamente) amediante el trayecto m´s corto; En un escenario donde actuase un n´mero elevado de ve- a uh´ıculos (unos pocos miles de veh´ ıculos, seg´n especificaciones de los autores) esto podr´ u ıacausar congesti´n de tr´fico en las calles arteriales del mapa digital utilizado; precisa- o amente para evitar esto, se utiliza un algoritmo denominado ”dynamic user assignment”desarrollado por Christian Gawron. Otra de las limitaciones de SUMO al tener preestablecidas las rutas de cada veh´ıculoen la simulaci´n, ser´ el gran uso de memoria de la m´quina utilizada, sin la utilizaci´n o a a otampoco de ning´n tipo de compresi´n, cosa que se agrava bastante en escenarios donde u ointerviene un gran n´mero de veh´ u ıculos; ´ste es, por tanto, uno de los aspectos que se eest´n mejorando de este simulador. a Por ultimo, valdr´ la pena resaltar que SUMO se puede dividir en peque˜os subpro- ıa ngramas que trabajan en conjunci´n y d´nde cada uno tiene su funci´n para llevar a cabo o o oel resultado final, en este caso, nuestro entorno simulado.
  • 74. Chapter 5 ´NIVEL DE APLICACION -OMNET++ El paquete mixim-sommer implementa el protocolo de comunicaci´n IEEE 802.15.4 oen todas sus capas. Como podemos ver en la figura 5.1 este protocolo abarca el nivelf´ ısico y de enlace (MAC Y LLC) y por encima se sostienen capas que el usuario puededefinir en funci´n de sus necesidades. En el caso de la implementaci´n de ejemplo que o onos ofrece mixim-sommer, desarrollan una capa de aplicaci´n particular y que nosotros omodificaremos de forma evolutiva para ir integrando nuestras propias funciones. Figure 5.1: Pila de protocolo 802.15.4 51
  • 75. 52 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++ Dentro de los ejemplos del framework, existe una implementaci´n de ese protocolo lla- omada ieee802154a. Para no modificar ese ejemplo, directamente duplicaremos el directorio(desde omnetpp) y cambiaremos el nombre al duplicado (en nuestro caso: mi ieee802154a).Internamente, debemos modificar correctamente toda referencia al antiguo nombre, y susti-tuirlo por el nuevo (empezando por el nombre del paquete: package org.mixim. exam-ples.mi ieee802154a; y continuando con posibles importaciones y llamadas a clases quehagan referencia a elementos internos a ese directorio). Una vez realizados estos cambios, nos fijaremos en la capa m´s externa, la que imple- amenta el nivel de aplicaci´n de este protocolo. Este nivel ser´ el que debamos modificar o apara adecuarlo al comportamiento que nosotros deseamos otorgarle. Como primera funcionalidad de prueba, para comprobar la correcta comunicaci´n entre opares, implementaremos un nivel de aplicaci´n que permita enviar mensajes en modo obroadcast. As´ partimos del m´dulo implementado original cuya estructura interna es la que ı, opodemos observar en la figura 5.2. Figure 5.2: Estructura interna componente ieee802154 El primer paso ser´ copiar (duplicar) dicho directorio y cambiar el nombre a los archivos apara evitar duplicidad con el original. V´ase figura 5.3. e Vemos como hemos cambiado el nombre del archivo .ned y del script sh. Este ultimo ´tampoco es importante, pues su finalidad es la de automatizar el lanzamiento de la reddesde un terminal. En cambio, el archivo .ned (en nuestro caso mi ieee802154a.ned) es uno de los m´dulos oprincipales en la simulaci´n de esta red. A trav´s de ´ste podemos definir una determinada o e ered de forma gr´fica (mediante la interfaz que ofrece omnet) y modular. La modularizaci´n a oes una de las ventajas de omnet. Permite aprovechar implementaciones m´s sencillas o a
  • 76. 53 Figure 5.3: Estructura interna componente ieee802154espec´ ıficas para construir sistemas m´s complejos. As´ mi ieee82154a.ned define un esce- a ı,nario en el que se indica la aparici´n de un elemento m´s simple, un ”host” implementado o apreviamente para este protocolo dentro del framework, ”Host802154A.ned”. M´s tarde lo aanalizaremos. As´ en nuestro archivo mi ieee802154a.ned nos encontramos con el siguiente c´digo: ı, onetwork mi ieee802154a{parameters:double playgroundSizeX @unit(m); // x size of the area the nodes are in (in meters)double playgroundSizeY @unit(m); // y size of the area the nodes are in (in meters)double playgroundSizeZ @unit(m); // z size of the area the nodes are in (in meters)double numHosts; // total number of hosts in the network@display(’’bgb=$playgroundSizeX,$playgroundSizeY,white,,;bgp=10,50’’);submodules:world: BaseWorldUtility {parameters:playgroundSizeX = playgroundSizeX;playgroundSizeY = playgroundSizeY;playgroundSizeZ = playgroundSizeZ;@display(’’p=251,50;i=misc/globe’’);}channelControl: ConnectionManager {parameters:@display(’’p=450,0;b=42,42,rect,red,,;i=abstract/multicast’’);}node[numHosts]: mi Host802154A {parameters:numHosts = numHosts;@display(’’p=121,123;b=42,42,rect,red;i=device/wifilaptop’’);}connections allowunconnected:// all connections and gates are to be generated dynamically}
  • 77. 54 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++ Que simplemente se trata de la codificaci´n que representa el entorno de la figura 5.4. o Figure 5.4: Componente gr´fico IEEE 802.15.4 a Como hemos dicho antes, esta declaraci´n reutiliza un m´dulo (objeto) que imple- o omenta el comportamiento de un nodo o ”host” determinado. Este nodo existe dentro delframework mixim-sommer y se llama ”Host802154A.ned”. Si recordamos, mi ieee802154aera una copia del directorio ieee802154, y, como tal, estar´ reutilizando ese mismo m´dulo a o(”Host802154A.ned”). Si bien podr´ ıamos dejar que nuestra versi´n reutilizara directa- omente ese m´dulo, estar´ o ıamos duplicando el comportamiento de la versi´n original. As´ o ıpues, lo que nosotros haremos ser´ duplicar el m´dulo ”Host802154A.ned”, renombrarlo a o(”mi Host802154A.ned”) y modificarlo internamente. (Obs: Este m´dulo lo podemos en- ocontrar en el directorio mixim-sommer/modules/node/). ”Host802154A.ned” implementa el comportamiento de un nodo o dispositivo basadoen el protocolo IEEE 802.15.4 como pudiera ser un ZigBee. En concreto, se basa en elcomportamiento real del chipset de los transmisores zigbee CC2420 de Texas Instrument(enlace). Volviendo al comportamiento virtual, en el editor OMNET++, podemos visu-alizar la torre de protocolos que define este m´dulo en la figura 5.6. o Figure 5.5: Estructura interna componenete ieee802154 Observamos c´mo vuelve a repetirse la reutilizaci´n de m´dulos m´s sencillos, simpli- o o o aficando la construcci´n de los elementos. De un vistazo intuimos diversos elementos que opodr´ resultarnos familiares. Estos elementos son los que aparecen en el lado izquierdo, ıaninterconectados, y que representan la torre de protocolos de ieee 802.15.4. Esta torre deprotocolos ser´ la siguiente. As´ el m´dulo ”nic” se encarga de implementar la funcionali- ıa ı, odad de los dos bloques inferiores IEEE 802.15.4 868/915 MHz PHY - IEEE 802.15.4 2400Mhz PHY (en nuestro caso concreto, el chipset trabaja sobre el espectro de los 2.4 Ghz).Por otro lado, el m´dulo ”net” encapsula el segundo y tercer nivel del protocolo (nivel de o
  • 78. 55enlace). En la figura 5.5, IEEE 802.15.4 MAC, IEEE 802.15.4 LLC y IEEE 802.2 LLC,Type1. Figure 5.6: Pila de protocolo 802.15.4 en OMNET++ Dado que esos niveles son propios del protocolo IEEE 802.15.4, nosotros no debemosmodificarlos, y los dejaremos como est´n. Por ultimo, el tercer nivel llamado ”app” se a ´corresponde con las capas superiores que representa la imagen (en ´sta, se extiende hacia eZigBee), y ser´ el que nosotros necesitamos modificar. a Aparte de esa torre de protocolos, encontramos una serie de m´dulos en el lado dere- ocho. Estos m´dulos implementan una serie de funcionalidades complementarias al propio oprotocolo que permiten simular de forma m´s aproximada el comportamiento del dis- apositivo f´ısico (”battery”, ”arp”), permiten obtener ciertas estad´ ısticas de uso (”batterystats”, ”stats”), o que, simplemente, son necesarios para el correcto funcionamiento de lasimulaci´n (”utility”, ”mobility”). o Volviendo al nivel de aplicaci´n (”app”), como se˜alamos, queda fuera del protocolo y o nde ´l depende el comportamiento ultimo que deseamos otorgar al nodo o dispositivo. En e ´la implementaci´n original, este nivel es muy parecido al que nosotros queremos construir oen primer lugar. Internamente, el m´dulo utiliza la implementaci´n desarrollada en C++ o o
  • 79. 56 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++llamada ”TestAppLayer.cc” que permite el env´ en modo broadcast de un unico mensaje. ıo ´Pero, entonces, ¿por qu´ debemos modificar esta capa, y crear una nosotros? En la eimplementaci´n original, este mensaje broadcast hace uso de una clase especial para el oenv´ de mensajes ”cMessage”. Esta clase encapsula determinada informaci´n relativa, ıo omayormente, con par´metros de control (tipo de mensaje, timestamp, prioridad), pero acarece, por ejemplo, de un campo de datos donde enviar informaci´n de usuario del nivel ode aplicaci´n. El objetivo de esta elecci´n se basa en dejar al usuario que implemente su o opropio mensaje aprovechando esta clase como ”template” b´sico. a As´ lo primero que debemos realizar es la creaci´n de nuestro propio mensaje para ı, oeste nivel de aplicaci´n, eligiendo los campos que creamos oportunos. Como primera oaproximaci´n, crearemos un paquete con un campo de datos, y campos relativos a la odirecci´n fuente y destino IP. o Para ello, en omnet, vamos al directorio de mixim-sommer: mixim-sommer /base/mes-sages. Una vez aqu´ bot´n derecho ”New-Message Definition (msg)”. Daremos nombre a ı, onuestro mensaje (Mi paquete.msg), seleccionaremos la clase padre (packet), y finalizare-mos su creaci´n. Habremos creado un archivo que tendr´ el siguiente c´digo: o a omessage Mi paquete {int someField;string anotherField;double arrayField1[];double arrayField2[10];} Este c´digo, a modo de plantilla, ser´ modificado seg´n lo que hab´ o a u ıamos comentadoanteriormente.packet Mi paquete {int destAddr = -1; // direcci´n destino oint srcAddr = -1; // direcci´n fuente ostring datos; // datos} A partir de esta definici´n, crearemos, mediante una herramienta que provee omnet, la oclase para este nuevo paquete. Para ello, desde un terminal, iremos hasta donde se encuen-tre este nuevo archivo (”mis documentos/omntpp/ mixim-sommer/base/messages”). Unavez aqu´ basta con ejecutar esta herramienta: opp_msgc Mi_paquete.msg. Autom´tica- ı, amente se crear´n dos archivos: Mi paquete m.cc y Mi paquete m.h que contendr´ la nueva a aclase para este mensaje, con funciones propias para poder acceder a los datos encapsuladosen ella. Una vez definida esta clase, ya podemos implementar nuestro nivel de aplicaci´n. o Pero antes, vamos a se˜alar algunos conceptos que permitir´n comprender mejor el n ac´digo que en nuestra aplicaci´n vamos a usar. o o Anteriormente hemos visto c´mo hab´ o ıamos utilizado la clase cPacket para crear nuestropropio paquete. Esta clase es, a su vez, una subcase de cMessage. cMessage, por su
  • 80. 5.1. MI APPLAYER.C 57parte, puede utilizarse para intercambiar informaci´n entre clases o incluso utilizarse como o”selfMessages”. Pero, ¿para qu´ enviarse mensajes a s´ mismos?. La idea es simple. Se e ıenv´ mensajes ”programados”, con una indicaci´n temporal, permitiendo de esta forma ıan oplanificar el flujo de ejecuci´n de una determinada instancia (en nuestro caso, del nivel de oaplicaci´n). o Dicho esto, parece que en l´ ıneas sucesivas veremos un determinado tipo de mensajes”selfMessages” que ”recordar´n” al propio nivel de aplicaci´n qu´ y cuando deben hacer a o ealgo. Se trata de una forma original de scheduling que nosotros aprovecharemos y queveremos a continuaci´n. o5.1 mi applayer.c El objetivo de esta clase (que implementa nuestro nivel de aplicaci´n), ser´ el de dotar o aa cada nodo de la posibilidad de enviar mensajes broadcast a sus vecinos. Para ello, podr´ ıamos preguntarnos qu´ valores o par´metros debemos tener en cuenta e aa la hora de enviar estos mensajes. Podemos pensar en el n´mero de mensajes que cada unodo enviar´, qu´ informaci´n voy a enviar en esos mensajes, qu´ hacer cuando reciba los a e o ede mis vecinos, etc. Tendremos que pensar, incluso, en qu´ funciones ser´n necesarias para e amanejar dichos par´metros, y en la propia implementaci´n de la clase. a o As´ tendremos en cuenta los siguientes par´metros: ı, a N´mero de mensajes a enviar, direcci´n broadcast, mensajes enviados e informaci´n del u o omensaje. En cuanto a las funciones que entran necesarias: Inicializaci´n y finalizaci´n de la aplicaci´n, manejador de mensajes de la capa inferior o o oy de automensajes, planificador de siguiente mensaje, envio de mensaje broadcast hacianivel inferior y env´ de respuesta a otro nodo. ıo C´digo fuente: o/******************************** file: SensorApplLayer.h** author: Eduardo Mar´n ı** copyright: (C) 2010-2011** This program is free software; you can redistribute it* and/or modify it under the terms of the GNU General Public* License as published by the Free Software Foundation; either* version 2 of the License, or (at your option) any later* version.* For further information see file COPYING
  • 81. 58 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++* in the top level directory********************************** part of: Modifications to the MF-2 framework by CSEM********************************#include ’’mi_app_layer.h’’#include ’’NetwControlInfo.h’’#include <SimpleAddress.h>#include ’’mi_app_layer.h’’#define DIR_BROADCAST 2147483647 //255.255.255.255 en decimalDefine_Module(mi_app_layer);/*** Mediante esta funci´n inicializamos el m´dulo convenientemente, en primer lugar o o* a trav´s del m´dulo BasicAppLayer. e o**/void mi app layer::initialize(int stage) {BaseApplLayer::initialize(stage);//Realizamos inicializaci´n del m´dulo en dos fases o o//En la primera, creamos el mensaje de control que activar´ el env´o BROADCAST a ı//Inicializamos variables para llevar el control del n´mero de mensajes enviados uif(stage == 0) {delayTimer = new cMessage( ’’delay-timer’’, SEND BROADCAST TIMER );mensajes enviados = 0;num mensajes a enviar = par(’’num mensajes a enviar’’);}//En la segunda fase a~adimos al planificador el mensaje de control nelse if(stage==1) {scheduleAt(simTime() + dblrand()*10, delayTimer);}}/*** Manejador de mensajes de la capa inferior**/void mi app layer::handleLowerMsg(cMessage *msg) {Mi paquete *mensaje;const void *datos;//Debemos identificar el tipo de mensaje recibidoswitch( msg->getKind() ){//Si se trata de un mensaje BROADCAST, procesamos el mensajecase BROADCAST MESSAGE:mensaje = static cast<Mi paquete *>(msg);EV << ’’Se ha recibido un paquete broadcast desde [’’<<mensaje->getSrcAddr()<<’’] -> enviando respuestan’’;datos = mensaje->getDatos();EV<<(char *)datos<<endl;sendReply(mensaje);break;//En caso de tratarse de una respuesta de broadcast (BROADCAST_REPLY), simplemente lo anunciamoscase BROADCAST REPLY MESSAGE:mensaje = static cast<Mi paquete *>(msg);EV << ’’Se ha recibido respuesta desde [’’<<mensaje->getSrcAddr()<<’’]; borrando el mensajen’’;delete msg;break;//En caso de no ser de ninguno de los dos tipos, se lanza error.
  • 82. 5.1. MI APPLAYER.C 59default:EV <<’’Error! paquete desconocido: ’’ << msg->getKind()<<endl;delete msg;}}/*** Esta funci´n act´a de disparador de una nueva acci´n a partir de la recepci´n de o u o o* un automensaje. Cuando se recibe un automensaje (SEND_BROADCAST_TIMER, en este caso)* el nivel ’’despertar´’’ para llevar a cabo el env´o de un nuevo mensaje BROADCAST. a ı* Tras eso, volver´ a autoplanificar un nuevo automensaje que le volver´ a despertar a a* al cabo de un tiempo igual al establecido.***/void mi app layer::handleSelfMsg(cMessage * msg) {//Informamos del n´mero de mensajes que el nivel ha enviado uEV << ’’numero de mensajes enviados: ’’<< mensajes enviados << endl;//Si se trata del tipo de mensaje correcto, actuamos en consecuenciaswitch( msg->getKind() ){case SEND BROADCAST TIMER://Si no hemos alcanzado el umbral m´ximo de mensajes enviados continuamos aif(num mensajes a enviar > mensajes enviados){mensajes enviados++;//Llamamos a la funci´n de env´o de mensaje o ısendBroadcast();//Planificamos nueva acci´n oplanificar siguiente mensaje();}delete msg;break;//En caso de no corresponder el tipo, informamos del errordefault:EV << ’’Automensaje desconocido! -> borr´ndolo, tipo: ’’<<msg->getKind() <<endl; adelete msg;}}/*** Creamos la funci´n planificadora de mensajes o**/void mi app layer::planificar siguiente mensaje(){delayTimer = new cMessage( ’’delay-timer’’, SEND BROADCAST TIMER );scheduleAt(simTime() + dblrand()*10, delayTimer);}/*** Mediante esta funci´n creamos un nuevo mensaje broadcast, que en un principio o* ´nicamente contendr´ un mensaje ’’Hola mundo’’ para enviarlo a la capa inferior u a**/void mi app layer::sendBroadcast(){Mi paquete *mensaje = new Mi paquete(’’BROADCAST MESSAGE’’, BROADCAST MESSAGE);//Incluido en informaci´n del mensaje, indicamos la direcci´n de destino (broadcast) o omensaje->setDestAddr(DIR BROADCAST);// usamos la funci´n getIndex() del m´dulo para obtener nuestra direcci´n (fuente) o o omensaje->setSrcAddr( myApplAddr() );//Establecemos la informaci´n dentro del campo de datos omensaje->setDatos(’’Hola mundo’’);// Establecemos la direcci´n de env´o del paquete. En este caso, direcci´n broadcast o ı omensaje->setControlInfo( new NetwControlInfo(DIR BROADCAST) );EV << ’’Enviando paquete!n’’;//Enviamos a la capa inferior
  • 83. 60 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++sendDown( mensaje );}/*** Mediante esta funci´n se simula la funcionalidad de un paquete ACK para nuestro nivel o* de aplicaci´n. De esta forma, al recibir un mensaje broadcast se informa al nodo o* fuente de que hemos recibido el mensaje**/void mi app layer::sendReply(Mi paquete *mensaje){simtime t delay;delay = uniform(0, 0.01);mensaje->setDestAddr(mensaje->getSrcAddr());mensaje->setSrcAddr(myApplAddr());mensaje->setKind(BROADCAST REPLY MESSAGE);mensaje->setName(’’BROADCAST REPLY MESSAGE’’);sendDelayedDown(mensaje, delay);EV << ’’Enviando la respuesta con retraso: ’’ << delay << endl;//NOTE: the NetwControl info was already ste by the network layer//and stays the same}/*** Finalizamos el m´dulo a trav´s de esta funci´n o e o**/void mi app layer::finish(){BaseApplLayer::finish();if(!delayTimer->isScheduled()) delete delayTimer;} Una vez creado este nuevo nivel de aplicaci´n, cuya clase mi app layer.cc se encon- otrar´ en el directorio: mixim-sommer/base/modules/ junto con el archivo de cabecera ami app layer.h que contendr´ la siguiente informaci´n (con declaraciones y definiciones a onecesarias):/********************************** file: mi_app_layer.h** author: Eduardo Mar´n ı** copyright: (C) 2010-2011** This program is free software; you can redistribute it* and/or modify it under the terms of the GNU General Public* License as published by the Free Software Foundation; either* version 2 of the License, or (at your option) any later* version.* For further information see file COPYING* in the top level directory************************************ part of: Modifications to the MF-2 framework by CSEM**********************************/#ifndef MI_APPL_LAYER_H#define MI_APPL_LAYER_H#include ’’BaseApplLayer.h’’#include ’’NetwControlInfo.h’’
  • 84. 5.1. MI APPLAYER.C 61//#include ’’cstat.h’’#include ’’BaseMacLayer.h’’#include ’’Mi_paquete_m.h’’using namespace std;class mi app layer : public BaseApplLayer{public:/** @brief Initialization of the module and some variables*/virtual void initialize(int);virtual void finish();enum APPL MSG TYPES{SEND BROADCAST TIMER,BROADCAST MESSAGE,BROADCAST REPLY MESSAGE};protected:cMessage *delayTimer;int num mensajes a enviar;int mensajes enviados;protected:/** @brief Handle self messages such as timer... */virtual void handleSelfMsg(cMessage*);/** @brief Handle messages from lower layer */virtual void handleLowerMsg(cMessage*);/** Generaci´n de automensajes */ ovoid planificar siguiente mensaje();/** @brief send a broadcast packet to all connected neighbors */void sendBroadcast();/** @brief send a reply to a broadcast message */void sendReply(Mi paquete *msg);};#endif Finalmente, para nuestra red mi ieee802154a, creada a partir de la copia de la originalieee802154a, modificaremos el nivel de aplicaci´n utilizado por defecto y seleccionaremos el oque acabamos de implementar, que, tras la construcci´n de todo el espacio (Men´: Project- o u>build all), nos debe aparecer el m´dulo autom´ticamente en el espacio de trabajo, como o aobservamos en la figura 5.7. Estamos ya en disposici´n de poder ejecutar esta red. Para ello, en el directorio ode nuestra red (mixim-sommer/examples/mi ieee802154a), bot´n derecho sobre el fichero omi ieee802154a.ned, ”Run as”->”Run configurations. . . ”. En la nueva ventana, damos unnuevo nombre a la configuraci´n de ejecuci´n, comprobamos que se selecciona el archivo o ode configuraci´n adecuado (omnetpp.ini) y ejecutamos seg´n vemos en la figura 5.8. o u El archivo ”omnetpp.ini” mencionado, es un archivo de configuraci´n inicial que guarda ovalores para realizar, sobre una misma red, diferentes tipos de inicio o configuraciones. Ennuestro caso, este archivo, para esta red, contiene el siguiente c´digo: o[General]
  • 85. 62 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++ Figure 5.7: Estructura de la capa de aplicaci´n creada onetwork = mi ieee802154adebug-on-errors = falsefname-append-host = false**.module-eventlog-recording = false**.vector-recording = true#**.debug = falsenum-rngs = 88ned-path = ../../base;../../modules;../../examples;# tkenv-default-run=1# cmdenv-runs-to-execute=1cmdenv-express-mode = true# Because of the battery module, there are always scheduled events# thus we need a fallback sim-time-limit.# Otherwise the battery module will eventually lead to a simtime_t overflowsim-time-limit=3 d # 30s for 10000 packetsmi ieee802154a.**.coreDebug = falsemi ieee802154a.playgroundSizeX = 500 mmi ieee802154a.playgroundSizeY = 500 mmi ieee802154a.playgroundSizeZ = 500 mmi ieee802154a.world.useTorus = falsemi ieee802154a.world.use2D = falsemi ieee802154a.channelControl.sendDirect = falsemi ieee802154a.channelControl.pMax = 1000 mWmi ieee802154a.channelControl.sat = -100 dBmmi ieee802154a.channelControl.alpha = 2.0mi ieee802154a.channelControl.carrierFrequency = 4500e+6 Hz################ PhyLayer parameters #####################mi ieee802154a.node[*].nic.phy.usePropagationDelay = falsemi ieee802154a.node[*].nic.phy.analogueModels = xmldoc(’’config.xml’’)mi ieee802154a.node[*].nic.phy.useThermalNoise = true################ MAC layer parameters ####################mi ieee802154a.node[*].nic.mac.txPower = 1mW # [mW]mi ieee802154a.node[*].nic.mac.notAffectedByHostState = truemi ieee802154a.node[*].nic.mac.macMinBE = 1
  • 86. 5.1. MI APPLAYER.C 63 Figure 5.8: Ejecuci´n de la simulaci´n o omi ieee802154a.node[*].nic.mac.macMaxBE = 6mi ieee802154a.node[*].nic.mac.macMaxCSMABackoffs = 20mi ieee802154a.node[*].nic.mac.macAckWaitDuration = 0.000864smi ieee802154a.node[*].nic.mac.aUnitBackoffPeriod = 0.02s***.debug = false**.battery.nominal = 99999mAh**.battery.capacity = 99999mAh**.battery.voltage = 3.3V**.battery.resolution = 10s**.battery.publishDelta = 0.1**.battery.publishTime = 0**.battery.numDevices = 1 # only the PHY module uses energy from the battery**.batteryStats.detail = false**.batteryStats.timeSeries = falsemi ieee802154a.node[*].nic.mac.headerLength = 16 bitmi ieee802154a.node[*].nic.mac.stats = truemi ieee802154a.node[*].nic.mac.trace = false## Nodes positionsmi ieee802154a.node[0].mobility.x = 170mi ieee802154a.node[0].mobility.y = 170mi ieee802154a.node[0].mobility.z = 0mi ieee802154a.node[1].mobility.x = 300mi ieee802154a.node[1].mobility.y = 170mi ieee802154a.node[1].mobility.z = 0**.mi app layer.num mensajes a enviar = 40[Config Pruebabroadcast]**.numHosts = 2mi ieee802154a.node[*].mi app layer.num mensajes a enviar = 4
  • 87. 64 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++5.2 APAL Hasta este punto hemos visto una serie de configuraciones e implementaciones quenos han permitido obtener un nivel de aplicaci´n funcional en el cu´l el algoritmo de o areenv´ (broadcast) no realiza ning´n proceso de filtrado o tratamiento previo que nos ıo upermita alcanzar a un n´mero grande de veh´ u ıculos sin encontrarnos ante la problem´tica adel broadcast storming. En esta secci´n presentaremos un algoritmo que minimiza este problema, as´ como una o ıimplementaci´n para OMNET++ que nos permita realizar una serie de simulaciones en olas que podamos observar dicha mejora.5.2.1 Broadcast Storm Se define broadcast radiation como una acumulaci´n de tr´fico broadcast y multicast o aen una red inform´tica. Si dicha acumulaci´n alcanza niveles extremos de difusi´n, con- a o ostituyen lo que se conoce como broadcast storm. El mayor problema que se asocia a estesuceso es la cantidad de recursos que son consumidos en la red, llegando a alcanzar nivelesde colapso que impiden la correcta entrega de paquetes de datos (denegaci´n de servicio). o En el contexto de las redes ad-hoc (MANET), y m´s concretamente en las redes aVANET, ante un medio de transmisi´n inal´mbrico, nos encontramos con una topolog´ o a ıade red en la cual, una difusi´n de paquetes de datos se vuelve impredecible y de dif´ o ıcilseguimiento y control. Aparte de la problem´tica existente donde los paquetes RREQ (route request - petici´n a ode ruta) compiten con los paquetes de datos, nos encontramos con que, en el nivel deaplicaci´n, un paquete puede ser reenviado m´ltiples veces si no existe un control expl´ o u ıcitoque limite el n´mero de intentos. u Es necesario, por tanto, aplicar algoritmos de difusi´n que minimicen estos problemas otomando como par´metros de control valores relativos a la posici´n del emisor y remitentes, a oventanas de reenv´ probabil´ ıo, ısticos, . . . Si bien, en nuestro caso, pudi´ramos haber optado por un par´metro de control basado e aen la geolocalizaci´n, preferimos suponer que no todos los intervinientes en el sistema otendr´ un dispositivo GPS. ıan Bajo este supuesto, optamos por un algoritmo probabil´ ıstico, que toma diferentes valo-res para regular el reenv´ de paquetes. Dicho algoritmo es APAL (Adaptative Probability ıoAlert Protocol [63]).
  • 88. 5.2. APAL 65APAL APAL se presenta para resolver diferentes problemas en la difusi´n de alertas en caso de oaccidente en redes VANET. Si un mensaje de alerta es difundido de forma indiscriminada,en poco tiempo nos encontraremos ante el problema de la tormenta de difusi´n (broadcast ostorm). Por contra, si realizamos una restricci´n en la retransmisi´n de dicha informaci´n, o o opodemos encontrarnos ante una muerte temprana de los paquetes de alerta. Este problemacrece si tenemos en cuenta que, en situaciones reales, las inclemencias meteorol´gicasoy las diferentes velocidades que comportan los veh´ ıculos, empobrecen la calidad de lacomunicaci´n. Muchos protocolos existentes para el control de broadcast storm asumen ola disponibilidad de dispositivos GPS en los veh´ ıculos para poder operar, no obstante,dicha premisa es arriesgada, pues no se tienen en cuenta las altas latencias o imprecisi´noen el c´lculo de las posiciones de cada veh´ a ıculo, que dificultan un control fino sobre esteproblema. Por ello, el protocolo APAL no necesita informaci´n sobre la localicaci´n espacial del o oveh´ıculo. La probabilidad con la que un mensaje de alerta se reenv´ es continuamente ıaadaptado en funci´n del grado de existencia de broadcast problem, sin dejar de lado, por ootro lado, el problema de p´rdida de mensajes por la aparici´n de ”veh´ e o ıculos ciegos” noalcanzables. As´ ante un accidente o situaci´n de emergencia, el veh´ ı, o ıculo comienza a difundir unmensaje de alerta. Los veh´ ıculos que se aproximan al accidente recibir´n dicho mensaje. aTodos los veh´ıculos que lo hayan recibido, de forma adaptativa, decidir´n si deben o no areenviarlo, dependiendo de diversos factores. Despu´s de recibir el primer mensaje de alerta, la condici´n para comprobar si se ha de e oreenviar o no es accionada en intervalos de tiempo. Estos intervalos de tiempo var´ deıanforma adaptativa. Esa duraci´n variable, para cada intervalo ith , ser´ denotado como ∆τi . o aAdem´s, la probabilidad de accionar o no la difusi´n de alerta es adaptada en funci´n de a o odiferentes factores. A esta probabilidad de difusi´n en el interlvalo ith la llamamos Pi . o A continuaci´n describimos la funci´n APAL. o o Paso 1. Si un nodo recibe un mensaje de alerta por primera vez, esperar´ por un aintervalo de tiempo aleatorio ∆τi , el cual se decide con una probabilidad aleatoria uniformeen un rango fijado, el cual depende de la densidad del tr´fico (en nuestras pruebas este aintervalo ser´ definido entre 1 a 100 ms), esto es ∆τi = rand(1 − 100ms). La expiraci´n a ode este intervalo de tiempo accionar´ el env´ del mensaje de alerta en funci´n del n´mero a ıo o ude mensajes duplicados que pueda recibir el nodo en ese per´ ıodo de tiempo. Si no recibening´n mensaje de alerta realizar´ un reenv´ de ´ste con una probabilidad P1 . P1 toma u a ıo eun valor alto (en nuestras pruebas, toma un valor aleatorio entre 0.7 a 0.9). Paso 2. Si durante el intervalo de tiempo ∆τi un veh´ ıculo ha recibido mensajes repetidos(DuplicateNumber ), tras la expiraci´n de este intervalo, el veh´ o ıculo se abstendr´ de reen- aviarlo otra vez y, en funci´n de ese valor de mensajes duplicados, actualizar´ las variables o a
  • 89. 66 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++de probabilidad para el siguiente intervalo Pi+1 , y ∆τi+1 como se muestra a continuaci´n: o Pi+1 = Pi /DuplicateN umber (5.1) ∆τi+1 = ∆τi ∗ DuplicateN umber (5.2) Esto hace que el siguiente intervalo de tiempo aumente y, por otro lado, la proba-bilidad de reenv´ de alertas disminuya, continuando as´ en el paso 4. Si, por contra, ıo ıDuplicateN umber = 0, no tales ecuaciones e iremos al paso 3. En cualquier caso, elpar´metro CountT ime es incrementado la parte proporcional al intervalo de tiempo ac- atual, par´metro que es determinante en la finalizaci´n o no del algoritmo. a o Paso 3. Cuando el intervalo de tiempo expira, y el nodo no ha recibido ning´n mensaje ude alerta duplicado, el veh´ ıculo har´ una redifusi´n con una probabilidad alta Pi . a o Tras el paso 3 se ejecuta el paso 4. Paso 4. En este punto aparecen dos nuevos t´rminos a tener en cuenta, β y δ. β ehace referencia al tiempo de vida l´ ımite. Tiene un valo fijado dependiendo de la criticidadde los mensajes de alerta (en nuestras pruebas, lo fijamos a 5s). Este tiempo indica lafranja temporal sobre la que un nodo podr´ manejar y realizar el proceso APAL sobre aun determinado mensaje recibido. δ es otro valor fijado, e indica el m´ximo n´mero de a umensajes de alerta que el nodo podr´ recibir antes de abortar el procesamiento o proto- acolo APAL aplicado sobre ´l (en nuestras pruebas, δ es configurado a 5). Cada veh´ e ıculocomprobar´ las condiciones para decidir si contin´a manteniendose como un miembro a udel set de nodos para propagar el mensaje de alerta o no. Bajo esta premisa, mientras(CountT ime < β&&DuplicatN umber < δ), CountT ime es el tiempo total, contabilizadodesde el primer instante en que se recibe el mensaje de alerta, es decir, el sumatorio deltotal de intervalos de tiempo parciales hasta el momento presente, y es calculado como : ∑ CountT ime = ∆τi (5.3) i Si las condiciones se cumplen, entonces el veh´ ıculo continuar´ permaneciendo como un amiembro del set de nodos y volver´ al paso 2, si no, saldr´ del proceso. a aWhen Receive Alert messageIF(Receive alert message for First time) ∆i Random between 1 - 100ms Pi Random probability between 0.7 - 0.9END IFCountTime = 0DuplicateNumber = 0WHILE(CountT ime < β&&DuplicateN umber < δ) WHILE(∆τi is not expired) Listen for duplicate alert message
  • 90. 5.2. APAL 67 Count = number of received duplicate alert message END WHILE IF(received duplicate alert message) DuplicateN umber = DuplicateN umber + Count Pi+1 = Pi /DuplicateN umber ∆τi+1 = ∆τi ∗ DuplicateN umber ELSE Rebroadcast with Pi END IF CountT ime = CountT ime + ∆τiEND WHILE Para integrar este algoritmo en omnet, hemos tenido que adaptarlo a las condiciones queimpone el framework (v´ase figura 5.9), y en las limitaciones que podemos encontrarnos, em´s adelante, al llevar la implementaci´n sobre microcontroladores. As´ en primer lu- a o ı,gar, debemos llevar un registro de cada uno de los mensajes que un nodo recibe, poderidentificarlos de forma un´ ıvoca, y conocer informaci´n asociada a cada uno de ellos. Para oello creamos vectores que contendr´n tanto sus uids, como las probabilidades de reenv´ a ıoasociadas a cada uno de ellos, los intervalos de escucha y tiempos de vida, etc. Figure 5.9: APAL OMNET++ A continuaci´n se detalla el significado de cada uno de estos vectores: o ˆ v delta[]: vector que contiene el intervalo de escucha en un determinado instante para un determinado mensaje. ˆ v pi[]: vector que contiene la probabilidad de reenv´ asociada a un determinado ıo mensaje. ˆ v count[]: n´mero de mensajes repetidos que se detectan a lo largo de un determi- u nado instante de escucha (v delta[]), para un determinado mensaje. ˆ v countime[]: tiempo de vida en el cual se realizar´n, para un determinado nodo, las a operaciones de escucha y reenv´ a lo largo de un n´mero determinado de intervalos ıo u de tiempo (v delta[]).
  • 91. 68 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++ ˆ v duplicatenumber[]: n´mero de mensajes repetidos que se detectan a lo largo u del tiempo de vida de la operaci´n (el tiempo de vida - v countime - engloba varios o intervalos de tiempo - v delta - ). ˆ v limite intervalo[]: indica el punto temporal en el que expira el intervalo de tiempo. As´ para un instante i = simTime(), v delta[] expira en v limite intervalo[] ı, = simTime() + v delta[]. ˆ v beta[]: vector que contiene, para cada mensaje, un l´ ımite m´ximo de tiempo de a vida de operaci´n. Establecido, por defecto, a cinco segundos. o ˆ v sigma[]: vector que contiene, para cada mensaje, un l´ımite m´ximo de mensajes a repetidos en el tiempo de vida de operaci´n. Establecido, por defecto, a cinco men- o sajes. Estos cambios podemos verlos a continuaci´n: omi app layer.h/*********************************************************** * file: mi_app_layer.h * * author: Eduardo Mar´n ı * * copyright: (C) 2010-2011 * * This program is free software; you can redistribute it * and/or modify it under the terms of the GNU General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later * version. * For further information see file COPYING * in the top level directory * *********************************************************** * part of: Modifications to the MF-2 framework by CSEM **********************************************************/#ifndef MI_APPL_LAYER_H#define MI_APPL_LAYER_H#include "BaseApplLayer.h"#include "NetwControlInfo.h"//#include "cstat.h"#include "BaseMacLayer.h"#include "Mi_paquete_m.h"using namespace std;class mi app layer : public BaseApplLayer{ public: /** @brief Initialization of the module and some variables*/ virtual void initialize(int); virtual void finish(); enum APPL MSG TYPES{SEND BROADCAST TIMER,BROADCAST MESSAGE,BROADCAST REPLY MESSAGE };
  • 92. 5.2. APAL 69protected: cMessage *delayTimer; int num mensajes a enviar; int mensajes enviados; int tipo vehiculo; //Seg´n este par´metro, podremos decidir si se trata u a //de veh´culo accidentado, veh´culo de emergencias, ... ı ı//cada veh´culo ir´ almacenando los identificadores de mensajes ı a //para comprobar si recibe duplicados int max ids;int vector ids recibidas[200000];//vector para almacenar los ids de los mensajesdouble v limite intervalo[200000];//vector con l´mites temporales para intervalos por cada ı mensajeint v duplicatenumber[200000];//vector para almacenar el n´mero de duplicados por mensaje uint puntero limite vector;//l´mite real del n´mero de ids dentro del vector ı u//de esta forma evitamos leer 200.000 registros vac´os ı//par´metros necesarios para el algoritmo APAL a double v delta[200000]; int v pi[200000]; double v beta[200000]; int v sigma[200000]; double v countime[200000]; int v count[200000];protected: /** @brief Handle self messages such as timer... */ virtual void handleSelfMsg(cMessage*); /** @brief Handle messages from lower layer */ virtual void handleLowerMsg(cMessage*);/** Generaci´n de automensajes */ o void planificar siguiente mensaje(); /** @brief send a broadcast packet to all connected neighbors */ void sendBroadcast(); /** @brief send a reply to a broadcast message */ void reenvio paquete(Mi paquete *msg);};#endify en mi app layer.c/******************************************************** * file: mi_app_layer.cc * * author: Eduardo Mar´n ı * * copyright: (C) 2010-2011 * * This program is free software; you can redistribute it * and/or modify it under the terms of the GNU General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later * version. * For further information see file COPYING * in the top level directory * ********************************************************* * part of: Modifications to the MF-2 framework by CSEM *********************************************************//*Recordar modificar tanto cabecera mi_app_layer.h como archivo de red Car.ned*/
  • 93. 70 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++#include "mi_app_layer.h"#include "NetwControlInfo.h"#include <SimpleAddress.h>#include "mi_app_layer.h"#define DIR_BROADCAST 2147483647 //255.255.255.255 en decimalDefine Module(mi app layer);/** * Mediante esta funci´n inicializamos el m´dulo convenientemente, en primer lugar o o * a trav´s del m´dulo BasicAppLayer. e o **/void mi app layer::initialize(int stage) {int aux; EV << "Inicializaci´n de m´dulo"; o o BaseApplLayer::initialize(stage); //Realizamos inicializaci´n del m´dulo en dos fases o o //En la primera, creamos el mensaje de control que activar´ el env´o BROADCAST a ı //Inicializamos variables para llevar el control del n´mero de mensajes enviados u if(stage == 0) { delayTimer = new cMessage( "delay-timer", SEND BROADCAST TIMER ); mensajes enviados = 0; num mensajes a enviar = par("num_mensajes_a_enviar"); tipo vehiculo = par("tipo_vehiculo"); max ids=200000; puntero limite vector=0; for(aux=0; aux<max ids;aux++){ vector ids recibidas[aux]=0; } } //En la segunda fase a~adimos al planificador el mensaje de control n else if(stage==1) { scheduleAt(simTime()+1, delayTimer); }}/** * Manejador de mensajes de la capa inferior **/void mi app layer::handleLowerMsg(cMessage *msg) { Mi paquete *mensaje; const void *datos; //Debemos identificar el tipo de mensaje recibido switch( msg->getKind() ){ //Si se trata de un mensaje BROADCAST, procesamos el mensaje y reenviamos case BROADCAST MESSAGE: mensaje = static cast<Mi paquete *>(msg); EV << "Se ha recibido un paquete broadcast desde ["<<mensaje->getSrcAddr()<<"]n"; datos = mensaje->getDatos(); EV<<(char *)datos<<endl; reenvio paquete(mensaje); break; //En caso de no tratarse de un mensaje broadcast, se elimina default: EV <<"Error! paquete desconocido: " << msg->getKind()<<endl; delete msg; }}/**
  • 94. 5.2. APAL 71* Esta funci´n act´a de disparador de una nueva acci´n a partir de la recepci´n de o u o o* un automensaje. Cuando se recibe un automensaje (SEND_BROADCAST_TIMER, en este caso)* el nivel "despertar´" para llevar a cabo el env´o de un nuevo mensaje BROADCAST. a ı* Tras eso, volver´ a autoplanificar un nuevo automensaje que le volver´ a despertar a a* al cabo de un tiempo igual al establecido.***/void mi app layer::handleSelfMsg(cMessage * msg) { //Informamos del n´mero de mensajes que el nivel ha enviado u EV << "numero de mensajes enviados: "<< mensajes enviados << endl; //Si se trata del tipo de mensaje correcto, actuamos en consecuencia switch( msg->getKind() ){ case SEND BROADCAST TIMER: if(tipo vehiculo==2){ //Si no hemos alcanzado el umbral m´ximo de mensajes enviados continuamos a if(num mensajes a enviar > mensajes enviados){ mensajes enviados++; //Llamamos a la funci´n de env´o de mensaje o ı sendBroadcast(); //Planificamos nueva acci´n o planificar siguiente mensaje(); } delete msg; } break; //En caso de no corresponder el tipo, informamos del error default: EV << "Automensaje desconocido! -> borr´ndolo, tipo: "<<msg->getKind() <<endl; a delete msg; }}/** * Creamos la funci´n planificadora de mensajes o**/void mi app layer::planificar siguiente mensaje(){ delayTimer = new cMessage( "delay-timer", SEND BROADCAST TIMER ); scheduleAt(simTime() + 1, delayTimer);}/** * Mediante esta funci´n creamos un nuevo mensaje broadcast, que en un principio o * ´nicamente contendr´ un mensaje "Hola mundo" para enviarlo a la capa inferior u a **/void mi app layer::sendBroadcast(){int indice = 0;//contador Mi paquete *mensaje = new Mi paquete("BROADCAST_MESSAGE", BROADCAST MESSAGE);//Incluido en informaci´n del mensaje, indicamos la direcci´n de destino (broadcast) o omensaje->setDestAddr(DIR BROADCAST); // usamos la funci´n getIndex() del m´dulo para obtener nuestra direcci´n (fuente) o o omensaje->setSrcAddr( myApplAddr() );//Generamos dos n´meros aleatorios para componer el identificador ´nico del mensaje: u uint ran 01 = rand()%10000;int ran 02 = rand()%10000;int id = ran 01 + ran 02;//A~adimos el identificador ´nico al mensaje n umensaje->setUid(id);//Establecemos la informaci´n dentro del campo de datos o
  • 95. 72 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++ mensaje->setDatos("mensaje de alerta"); // Establecemos la direcci´n de env´o del paquete. En este caso, direcci´n broadcast o ı omensaje->setControlInfo( new NetwControlInfo(DIR BROADCAST) ); EV << "Enviando paquete!n"; //Enviamos a la capa inferior sendDown( mensaje );}/** * Mediante esta funci´n se realiza el reenv´o de paquetes (implementando APAL) o ı **/void mi app layer::reenvio paquete(Mi paquete *mensaje){ int aux,indice; int repetido; int random pi; int reenviar; char* aux string; simtime t delay; delay = uniform(0, 0.01); //comprobamos si ya lo hab´amos recibido anteriormente ı reenviar = 0; indice = 0; repetido=0; aux=0; while((!repetido)&&(aux<max ids)&&(aux<puntero limite vector)){ EV << "id recibido= " << mensaje->getUid(); EV << " | id del vector[" << aux << "] = " << vector ids recibidas[aux]; if(mensaje->getUid()==vector ids recibidas[aux]){ repetido = 1; indice = aux; //almacenamos el ´ndice del uid detectado. ı } aux++;} if(!repetido){ v delta[puntero limite vector] = rand()%100 + 1;//obtenemos un valor entre 0 y 100 ms //Asociamos el valor del intervalo v delta[puntero limite vector] = v delta[puntero limite vector]/1000; v limite intervalo[puntero limite vector] = simTime().dbl() + v delta[ puntero limite vector]; v pi[puntero limite vector] = (rand()%200 + 700); v count[puntero limite vector] = 0; v countime[puntero limite vector] = 0; v duplicatenumber[puntero limite vector] = 0; v beta[puntero limite vector] = simTime().dbl() + 5; //5 segundos v sigma[puntero limite vector] = 5; //5 mensajes duplicados EV << "delta_t_actual= " << v delta[puntero limite vector]; EV << "pi_actual = " << v pi[puntero limite vector]; vector ids recibidas[puntero limite vector]=mensaje->getUid(); puntero limite vector++; reenviar = 1; }else{ EV << "v_countime["<< indice <<"] = " << v countime[indice]; EV << " v_beta["<< indice <<"] = " << v beta[indice]; EV << " v_duplicatenumber["<< indice <<"] = " << v duplicatenumber[indice];
  • 96. 5.2. APAL 73 EV << " v_sigma["<< indice <<"] = " << v sigma[indice]; EV << " v_limite_intervalo["<< indice <<"] = " << v limite intervalo[indice]; if((v countime[indice] < v beta[indice])&&(v duplicatenumber[indice] < v sigma[ indice])){ if(v limite intervalo[indice]> simTime().dbl()){ v count[indice]++; EV << " v_count["<< indice <<"] = " << v count[indice]; }else{ if(v count[indice]>0){ EV << "AQUI ENTRA"; v duplicatenumber[indice]=v duplicatenumber[indice]+v count[indice]; v pi[indice] = v pi[indice]/2; v delta[indice] = v delta[indice]*v duplicatenumber[indice]; }else{ random pi = rand()%1000 + 1; if(random pi < v pi[indice]){ EV << "Reenviando paquete con probabilidad: " << v pi[indice]; reenviar = 1; } } v count[indice] = 0; v limite intervalo[indice] = simTime().dbl() + v delta[indice]; v countime[indice] = v countime[indice] + simTime().dbl(); EV << "v_countime["<< indice <<"]: " << v countime[indice]; } } } if(reenviar){ Mi paquete *m reenvio = new Mi paquete("BROADCAST_MESSAGE", BROADCAST MESSAGE); //Establecemos el uid del mensaje m reenvio->setUid(mensaje->getUid()); //Incluido en informaci´n del mensaje, indicamos la direcci´n de destino (broadcast) o o m reenvio->setDestAddr(DIR BROADCAST); // usamos la funci´n getIndex() del m´dulo para obtener nuestra direcci´n (fuente) o o o m reenvio->setSrcAddr( myApplAddr() ); //Establecemos la informaci´n dentro del campo de datos o m reenvio->setDatos(mensaje->getDatos()); // Establecemos la direcci´n de env´o del paquete. En este caso, direcci´n broadcast o ı o m reenvio->setControlInfo( new NetwControlInfo(DIR BROADCAST) ); sendDelayedDown(m reenvio, delay); EV << "Reenviando paquete con retraso: " << delay << endl; }}/** * Finalizamos el m´dulo a trav´s de esta funci´n o e o **/void mi app layer::finish(){ BaseApplLayer::finish(); if(!delayTimer->isScheduled()) delete delayTimer;}
  • 97. 74 ´ CHAPTER 5. NIVEL DE APLICACION - OMNET++
  • 98. Chapter 6 ´ESPECIFICACION DEESCENARIOS Como paso previo a las diferentes simulaciones que realizaremos, y para definir unmarco de contexto para los resultados generados en esas simulaciones, presentaremos acontinuaci´n una serie de escenarios que describir´n la topolog´ y caracter´ o a ıa ısticas princi-pales de nuestras redes VANETs. As´ mismo, y tras haber visto las diferentes aplicaciones ıde simulaci´n elegidas en el cap´ o ıtulo anterior, veremos c´mo definir y construir los difer- oentes escenarios que ser´n importados a dichas aplicaciones mediante el uso de frameworks ao herramientas de apoyo a partir de descripciones en formato xml. Sobre cada configuraci´n de escenario, se realizar´n diferentes pruebas de simulaci´n, o a oque comprenden: tiempo medio de recepci´n de paquetes entre los diferentes componentes ode la red, desde un origen concreto; n´mero de veh´ u ıculos que recibe una determinadaalerta; n´mero de veh´ u ıculos ciegos (blind vehicles) a los cu´les no llegan los mensajes de aalerta; y para cada uno de estos valores, aplicaremos diferentes valores condicionantes.6.1 NETCONVERT El simulador de tr´fico de veh´ a ıculos SUMO trae consigo una serie de utilidades y apli-caciones enfocadas a facilitar diferentes tareas de procesado de datos, bien para adaptarlosdesde fuentes externas o bien para aplicar una serie de filtros previos a las simulaciones. En el caso que nos ocupa, NETCONVERT es una herramienta que permite generarredes de carreteras para nuestro simulador SUMO a partir de diferentes descripciones dig-itales de redes de carretera entre las que se encuentran archivos generados por aplicacionesweb conocidas (openstreetmap[11]), aplicaciones SIG comerciales (ARCView, Tiger ), yotros muchos formatos (VISUM, Vissim, openDRIVE, MATsim, DLR de Navteq), entrelos que se encuentran las descripciones nativas xml de SUMO. 75
  • 99. 76 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS As´ para nuestro proyecto, en el cual debemos definir determinados escenarios con- ı,cretos en los que construiremos diferentes tipos de v´ lo m´s acertado ser´ utilizar las ıas, a adescripciones en formato xml para, mediante NETCONVERT, generar las definiciones de ´redes de carreteras soportadas por SUMO. Unicamente, como veremos m´s adelante, uti- alizaremos NETCONVERT para generar dichas definiciones a partir de la aplicaci´n web oopenstreetmap[11], debido a la complejidad de la red a simular.6.1.1 Utilizando NETCONVERT En SUMO una red de carreteras no es m´s que un grafo dirigido en el que los v´rtices a edel grafo o nodos (nodes) representan interecciones y uniones, y cuyos lados o bordes(edges) representan las carreteras y calles. Junto a estos elementos b´sicos, una red SUMO acontiene informaci´n adicional relacionada con aspectos del tr´fico: o a ˆ Por cada carretera (edge), el n´mero de carriles (lanes) que contiene, u ˆ La posici´n, forma y l´ o ımites de velocidad de cada carril (lane), ˆ El sentido de circulaci´n en la v´ o ıa, ˆ Las conexiones entre carriles (lane) que suceden en un cruce o uni´n (node) y o ˆ La posici´n y l´gica de las diferentes se˜ales luminosas de regulaci´n de tr´fico o o n o a (sem´foros). aEdges y Lanes Los atributos que definen a una carretera (edge) son los siguientes: ˆ id El identificador del edge. ˆ from El identificador del node origen desde donde parte el fragmento de carretera. ˆ to El identificador del node destino donde termina el fragmento de carretera. ˆ priority Un valor num´rico que aporta prioridad de selecci´n a un veh´ e o ıculo ante varias posibles elecciones. ˆ function Definici´n abstracta de una carretera. o Cada definici´n de un fragmento de carretera puede, a su vez, contener una descripci´n o opor cada uno de los carriles que tuviera, donde se indicar´ ıa: ˆ id El identificador de lane.
  • 100. 6.1. NETCONVERT 77 ˆ depart Variable para indicar si los veh´ıculos que partan desde esta carretera pueden o no utilizar el carril (=1) o no (=0). ˆ vclasses Un listado de tipos de veh´ ıculos que tienen permiso o no para utilizar o no el carril (´til por ejemplo, en carrilbus, de emergencias, etc). u ˆ speed Velocidad m´xima permitida en ese carril. a ˆ length Longitud del carril.Nodes De la misma forma que las v´ y carriles, los nodos vienen determinados por una serie ıasde atributos: ˆ id El identificador de nodo. ˆ x Valor num´rico de la posici´n (en metros) del nodo sobre el eje X. e o ˆ y Valor num´rico de la posici´n (en metros) del nodo sobre el eje Y. e o Mediante los elementos presentados anteriormente, y siguiendo una sint´xis descriptiva aen formato xml, podremos crear escenarios de diferente complejidad seg´n las necesidades uque se nos presenten. A continuaci´n, para mostrar la simplicidad que nos ofrecen este tipo de descripciones, oabordaremos el caso b´sico de una v´ recta de unico sentido formado por dos nodos (inicio a ıa ´y fin) a la que inyectaremos un flujo de veh´ ıculos constante (Figura 6.1). Este caso b´sico anos servir´ para crear redes m´s complejas que detallaremos en el siguiente apartado. a a As´ en primer lugar, crearemos un archivo de descripci´n de nodos, que llamaremos ı, o”net.node.xml ”, y que contendr´ tanto los identificadores de nodo como sus posiciones en ael escenario. Figure 6.1: Esquema v´ unica unidireccional - SUMO ıa ´ La idea esquem´tica de la v´ se muestra en la figura , y la descripci´n de este esquema, a ıa oen t´rminos xml, ser´ la siguiente: e a<nodes> <node id=’’0’’ x=’’0.0’’ y=’’0.0’’/> <node id=’’1’’ x=’’500.0’’ y=’’0.0’’/></nodes>
  • 101. 78 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS Por otro lado, uniremos los dos nodos mediante una configuraci´n de v´ determinada, o ıasasignando un n´mero de carriles por sentido, y el inicio y final de dichas v´ bajo el archivo u ıas,de descripci´n ”net.edg.xml ”. o<edges> <edge id=’’0t1’’ fromnode=’’0’’ tonode=’’1’’ priority=’’1’’ nolanes=’’1’’ speed =’’11.11’’/> <edge id=’’1t0’’ fromnode=’’1’’ tonode=’’0’’ nolanes=’’1’’ speed=’’11.11’’/></edges> A partir de estos dos archivos descriptivos, crearemos el archivo de red propiamentedicho (”net.ned.xml ”), mediante la herramienta NETCONVERT, que toma como entradaambos y nos devuelve la red:netconvert --xml-node-files=net.nod.xml --xml-edge-files=net.edg.xml --output-file=net. net.xml Hasta este punto hemos estado realizando la descripci´n de la infraestructura o topolog´ o ıadel escenario, atendiendo a elementos est´ticos, como puntos de origen y destino, l´ a ıneasde conexi´n entre ellos, n´mero de carriles contenidas en ellas, etc. Sin embargo, para o urealizar la simulaci´n debemos aportar informaci´n sobre los veh´ o o ıculos, elementos din´mi- acos principales cuyo comportamiento puede ser definido, de la misma forma que con loselementos est´ticos, bajo archivos de descripci´n en formato xml. a ovehicle types As´ la informaci´n relativa a la descripci´n de un tipo de veh´ ı, o o ıculo es la siguiente: ˆ id Identificador del tipo de veh´ ıculo. ˆ accel Capacidad de aceleraci´n de un veh´ o ıculo, expresado en m/s2 . ˆ decel Capacidad de deceleraci´n de un veh´ o ıculo, expresado en m/s2 . ˆ sigma Valor num´rico, factor de imperfecci´n, comprendido entre 0 y 1. e o ˆ length Longitud neta de un veh´ ıculo, expresado en metros. ˆ minGap Espacio m´ ınimo vac´ entre veh´ ıo ıculos, expresado en metros. ˆ maxSpeed Velocidad m´xima de un veh´ a ıculo, expresado en m/s. ˆ color Color a aplicar a un veh´ ıclulo, bajo representaci´n rgb. o ˆ vClass Representaci´n abstracta de un veh´ o ıculo. Detallado a continuaci´n. o ˆ emissionClass Representaci´n abstracta de emisiones de CO2 u otro compuesto a o analizar para un determinado veh´ ıculo. ˆ guiShape C´mo el veh´ o ıculo ser´ renderizado en el escenario. a
  • 102. 6.1. NETCONVERT 79 La anterior informaci´n nos ofrece caracter´ o ısticas f´ ısicas propias del veh´ ıculo, pero nonos aporta informaci´n sobre el comportamiento de ´ste. Para ello, debemos indicarlo en o ela definici´n de veh´ o ıculos:vehicle Los atributos que lo describen son los siguientes: ˆ id El identificador del veh´ ıculo. ˆ type Identificador de referencia del tipo de veh´ ıculo (definido anteriormente). ˆ route Identificador de referencia de la ruta que seguir´ el veh´ a ıculo (definido en el siguiente punto). ˆ color Color del veh´ ıculo. ˆ depart Valor temporal en el que el veh´ ıculo aparecer´ en el punto de partida definido a en su ruta. ˆ departLane Identificador de carril de partida que utilizar´ el veh´ a ıculo. Este valor debe coincidir con el primer carril definido en su ruta de navegaci´n. o ˆ departPos A diferencia del valor anterior, la posici´n de partida permite a un o veh´ ıculo ser insertado en el carril (lane) m´s cercano de la red a esa posici´n. a o ˆ departSpeed Velocidad de partida del veh´ ıculo, expresada en m/s. ˆ arrivalLane Carril de llegada o finalizaci´n en la navegaci´n de un veh´ o o ıculo. ˆ arrivalSpeed Velocidad final de un veh´ ıculo al abandonar la red, expresada en m/s.routes Finalmente, como hemos visto en los atributos anteriores, un determinado veh´ ıculopuede definir su ruta de navegaci´n mediante la utilizaci´n de una descripci´n externa de o o oruta. Esta descripci´n contiene los siguientes atributos: o ˆ id Identificador de ruta. ˆ color Color de ruta. ˆ edges Listado de carreteras (edges) que seguir´ el veh´ a ıculo que utilice dicha ruta, separado por espacios en blanco. ˆ probability Probabilidad de que un veh´ ıculo utilice una u otra definici´n de ruta, o entre otras posibles.
  • 103. 80 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS Continuando as´ con el ejemplo b´sico que hab´ ı a ıamos comenzado, y que tan s´lo hab´ o ıamosmostrado en su definici´n est´tica, a continuaci´n indicamos la descripci´n del compor- o a o otamiento de un veh´ ıculo, incluyendo su tipo, ruta, y una especificaci´n de veh´ o ıculo nocomentada hasta ahora, y que se basa en la descripci´n de un flujo de veh´ o ıculos, m´s aque en la descripci´n de un unico veh´ o ´ ıculo. Esta definici´n se encierra bajo la etiqueta o”flow ” en sustituci´n de la etiqueta ”vehicle” y que a˜ade tres par´metros (”begin”, ”end ” y o n a”period ”) que indican valor temporal de inicio y fin de flujo, y periodicidad de aparici´n de oveh´ ıculos en segundos. De esta forma automatizamos la generaci´n de veh´ o ıculos cuandoqueremos hacer una simulaci´n con un n´mero grande de ´stos. o u e<vtype id=’’vehiculo’’ accel=’’2.6’’ decel=’’4.5’’ sigma=’’0.5’’ length=’’5’’ maxspeed =’’14’’ color=’’1,1,1’’/> <route id=’’from0’’ multi ref=’’x’’ edges=’’0t1 1t0’’/> <flow id=’’from0’’ type=’’vehiculo’’ route=’’from0’’ begin=’’1’’ end=’’5002’’ period =’’1’’/></routes> El resultado de la descripci´n de escenario bajo el simulador SUMO es la que se puede oobservar en la Figura 6.2. Figure 6.2: V´ unica unidireccional - SUMO ıa ´6.2 MOVE La herramienta NETCONVERT [8] nos permit´ generar archivos de definici´n de es- ıa ocenarios compatibles con el entorno de simulaci´n SUMO a partir de diferentes fuentes ode descripci´n de elementos. Una de esas fuentes, como hemos visto, se realiza de forma omanual, mediante la creaci´n de varios archivos xml. Sin embargo, como veremos en uno ode los escenarios que crearemos, debido a la complejidad del mismo, y aprovechando lageometr´ regular que presenta, podemos apoyarnos en otra herramienta o framework que ıanos facilita esa tarea de definici´n. o Esta herramienta es MOVE (MObility model generator for VEhicular networks)[9] (Figura6.3), y se define como una aplicaci´n de generaci´n r´pida de escenarios, que toma difer- o o aentes par´metros de entrada configurables por el usuario y genera archivos de descripci´n a o
  • 104. 6.3. JTRROUTER 81en formato XML soportados por la herramienta NETCONVERT para generar en un se-gundo paso el entorno de simulaci´n hacia SUMO. o Figure 6.3: Pantalla principal MOVE Si bien MOVE tambi´n nos ofrece la posibilidad de generar, tras la construcci´n de un e oescenario est´tico, el comportamiento din´mico para una serie de veh´ a a ıculos (Vehicle Move-ment Editor ), para este prop´sito utilizaremos otra herramienta auxiliar, JTRROUTER. o6.3 JTRROUTER Si mediante NETCONVERT pod´ ıamos realizar una descripci´n de escenarios de forma omanual y con MOVE pod´ ıamos automatizar ese proceso, con JTRROUTER[10] cerramosel c´ ırculo al poder automatizar la definici´n din´mica de estos escenarios. o a Y es que para cada uno de los veh´ ıculos que vayamos a inyectar en nuestro escenariopodr´ıamos realizar la descripci´n de sus rutas que permitan concluir en una simulaci´n o om´s o menos real. Sin embargo, si la definici´n manual del mapa era tediosa, la definici´n a o ode rutas de esta forma lo es mucho m´s. a
  • 105. 82 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS As´ mediante JTRROUTER, y partiendo de diferentes archivos de entrada, obten- ı,dremos un archivo de rutas o comportamiento vehicular de forma sencilla y potente. En concreto, esta aplicaci´n puede tomar como entrada el archivo de red (*.net.xml), oarchivo que puede haber sido generado por MOVE ; un archivo de flujos (*.flows.xml),que establezca el n´mero de flujos diferentes que podemos tener; un archivo de ”giros”, uque define las probabilidades de que un determinado veh´ ıculo tome una u otra trayectoriaen una intersecci´n; o un archivo de configuraci´n global (*.jtr.cfg) que JTRROUTER o ointerpreta y aplica en consecuencia. Veremos en m´s detalle su aplicaci´n al realizar la a odescripci´n de rutas para un escenario concreto (”rejilla manhattan”). o6.4 Escenarios Partiendo de la definici´n b´sica de escenario que hemos realizado mediante el empleo o ade la herramienta NETCONVERT, presentaremos los escenarios que utilizaremos en lasdiferentes simulaciones a realizar.6.4.1 Escenario 1: v´ unica unidireccional ıa ´ Este primer escenario es el m´s sencillo de los tres que describiremos. Se basa en la adefinici´n realizada en el punto anterior. Mediante su uso podremos realizar una simulaci´n o oinicial de VANET pura, en modo ad-hoc, que nos permitir´ comprender la importancia de aestablecer un algoritmo de control de difusi´n de paquetes para evitar el conocido problema ode broadcast storm. As´ se establece un escenario definido por una v´ de circulaci´n de unico sentido ı, ıa o ´y 300 metros de longitud en cuyo final se describe un cruce en aspa (Figura 6.4). Eneste cruce se simular´ un accidente y un nodo en este punto comenzar´ a emitir se˜ales a a nde alerta cada segundo. Desde el otro extremo de la v´ comenzar´ a inyectarse tr´fico ıa, a aconstante que, al acercarse hasta el punto del incidente, se generar´ una congesti´n de a oveh´ıculos que permitir´ establecer una red de nodos lo bastante densa como para alcanzar ala problem´tica que hemos mencionado de broadcast storm sin un algoritmo de control. a La definici´n de nodos la inclu´ o ımos en el archivo net.nod.xml y cuyo contenido es elsiguiente:<nodes> <node id=’’0’’ x=’’0.0’’ y=’’0.0’’/> <node id=’’1’’ x=’’190.0’’ y=’’0.0’’/> <node id=’’2’’ x=’’200.0’’ y=’’0.0’’/> <node id=’’3’’ x=’’190’’ y=’’10’’ /> <node id=’’4’’ x=’’190’’ y=’’-10’’ /></nodes> Una vez creada la definici´n de nodos, debemos crear los carriles (edges) que definen o
  • 106. 6.4. ESCENARIOS 83 Figure 6.4: V´ unica unidireccional ıa ´realmente el origen y destino de cada v´ As´ tenemos una v´ que va del nodo 0 al nodo ıa. ı, ıa1 de tres carriles, una v´ de un carril del nodo 1 al 3, otra del nodo 1 al 2 y otra del 1 al ıa4. La definici´n se da en net.edg.xml : o<edges> <edge id=’’0t1a’’ fromnode=’’0’’ tonode=’’1’’ nolanes=’’3’’ priority=’’2’’ speed=’’30’’ /> <edge id=’’1ti’’ fromnode=’’1’’ tonode=’’3’’ nolanes=’’1’’ speed=’’30’’/> <edge id=’’1tc’’ fromnode=’’1’’ tonode=’’2’’ nolanes=’’1’’ speed=’’30’’/> <edge id=’’1td’’ fromnode=’’1’’ tonode=’’4’’ nolanes=’’1’’ speed=’’30’’/></edges> Finalmente, queda definir el comportamiento o ruta de los veh´ ıculos que entrar´n aen escena. Para ello, deben definirse los tipos de cada veh´ ıculo (longitud del veh´ıculo,par´metros de aceleraci´n, velocidad punta, variaci´n, . . . ). Una vez creado el tipo, defin- a o oimos la ruta que seguir´ cada uno de ellos. As´ definimos tres rutas, que parten del nodo 0 a ı,y van, respectivamente, al nodo 3, 2 y 4. Ya tan s´lo queda instanciar a los veh´ o ıculos. Estainstanciaci´n puede realizarse de forma individual, uno a uno, o definir flujos de veh´ o ıculosque generan autom´ticamente la ”fuente de veh´ a ıculos”, como hemos comentado anterior-mente. En nuestro caso, definimos los tres primeros de forma individual, para otorgarlesla caracter´ ıstica de parada (stop) que permita bloquear la v´ y los dem´s se generar´n ıa, a ade forma autom´tica mediante ”flows”. a La definici´n de las rutas se definen en net.rou.xml : o<routes> <vtype id=’’rapido’’ accel=’’0.8’’ decel=’’4.5’’ sigma=’’0.5’’ length=’’5’’ maxspeed =’’25’’/> <vtype id=’’medio’’ accel=’’0.8’’ decel=’’4.5’’ sigma=’’0.5’’ length=’’5’’ maxspeed =’’20’’/> <vtype id=’’lento’’ accel=’’0.8’’ decel=’’4.5’’ sigma=’’0.5’’ length=’’5’’ maxspeed =’’15’’/> <vtype id=’’accidentado’’ accel=’’0.8’’ decel=’’4.5’’ sigma=’’0.5’’ length=’’5’’ maxspeed=’’30’’/><route id=’’izquierda’’ edges=’’0t1a 1ti’’/><route id=’’centro’’ edges=’’0t1a 1tc’’/><route id=’’derecha’’ edges=’’0t1a 1td’’/> <flow id=’’from0r’’ type=’’rapido’’ route=’’izquierda’’ begin=’’1’’ end=’’1000’’ period=’’10’’/><flow id=’’from0m’’ type=’’medio’’ route=’’centro’’ begin=’’1’’ end=’’1000’’ period =’’10’’/>
  • 107. 84 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS<flow id=’’from0l’’ type=’’lento’’ route=’’derecha’’ begin=’’1’’ end=’’1000’’ period =’’10’’/> <vehicle id=’’v accidentado’’ type=’’accidentado’’ route=’’izquierda’’ depart=’’0’’ color=’’0,1,0’’> <stop lane=’’1ti 0’’ pos=’’0’’ duration=’’50’’/> </vehicle> <vehicle id=’’v accidentado1’’ type=’’accidentado’’ route=’’centro’’ depart=’’0’’ color =’’0,1,0’’> <stop lane=’’1tc 0’’ pos=’’0’’ duration=’’50’’/> </vehicle> <vehicle id=’’v accidentado2’’ type=’’accidentado’’ route=’’derecha’’ depart=’’0’’ color=’’0,1,0’’> <stop lane=’’1td 0’’ pos=’’0’’ duration=’’50’’/> </vehicle></routes> Finalmente, debemos generar el archivo de definici´n de la red (que integra nodes oy edges). Recordemos que deb´ ıamos pasar el archivo de red (*.net.xml ) y el de rutas(*.rou.xml ). Para ello, lo generamos mediante la herramienta NETCONVERT :netconvert --xml-node-files=net.nod.xml --xml-edge-files=net.edg.xml --output net.net .xml6.4.2 Escenario 2: v´ cuadrada unidireccional ıa El siguiente escenario, una v´ con forma de cuadrado (Figura 6.5), en el que inyecta- ıamos un tr´fico de 10 veh´ a ıculos que circulan en sentido horario y en la que el primero es elunico act´a como emisor, nos permitir´ comprobar los beneficios de aplicar un algoritmo´ u ade control de broadcast storm como es el elegido en este proyecto, el algoritmo APAL(Adaptative Probability Alert Protocol ). As´ de la misma forma, definimos el archivo de descripci´n de nodos net.nod.xml : ı, o<nodes> <node id=’’a’’ x=’’0.0’’ y=’’300’’ /> <node id=’’b’’ x=’’300.0’’ y=’’300’’ /> <node id=’’c’’ x=’’300.0’’ y=’’0’’ /> <node id=’’d’’ x=’’0.0’’ y=’’0’’ /></nodes> Definimos el archivo de descripci´n de v´ net.edg.xml : o ıas<edges> <edge id=’’ed ab’’ fromnode=’’a’’ tonode=’’b’’ priority=’’1’’ nolanes=’’1’’ speed =’’11.111’’ /> <edge id=’’ed bc’’ fromnode=’’b’’ tonode=’’c’’ priority=’’1’’ nolanes=’’1’’ speed =’’11.111’’ /> <edge id=’’ed cd’’ fromnode=’’c’’ tonode=’’d’’ priority=’’1’’ nolanes=’’1’’ speed =’’11.111’’ /> <edge id=’’ed da’’ fromnode=’’d’’ tonode=’’a’’ priority=’’1’’ nolanes=’’1’’ speed =’’11.111’’ /></edges>
  • 108. 6.4. ESCENARIOS 85 Y, por ultimo, su descripci´n de comportamiento en el archivo de rutas net.rou.xml : ´ o<routes> <route id=’’basica’’ multi ref=’’x’’ edges=’’ed ab ed bc ed cd ed da ed ab ed bc ed cd ed da ed ab ed bc ed cd ed da ed ab ed bc ed cd ed da ed ab ed bc ed cd ed da ed ab ed bc ed cd ed da ed ab ed bc ed cd ed da ed ab ed bc ed cd ed da ed ab ed bc ed cd ed da’’/> <flow id=’’flujo basico’’ route=’’basica’’ begin=’’50’’ end=’’500’’ no=’’10’’/></routes> Figure 6.5: V´ cuadrada unidireccional ıa6.4.3 Escenario 3: red Manhattan Si nos fijamos en las dos redes que hemos definido hasta ahora podemos apreciar sindemasiada dificultad que estos escenarios se alejan bastante de las situaciones reales ycondiciones en las que un veh´ ıculo se mueve en entornos urbanos e interurbanos. Por ellodebemos aproximarnos cuanto podamos a esas condiciones. En este sentido, lo m´s pr´ximo a ese escenario real pasa directamente por realizar a oun estudio de campo, desplegar las unidades que componen nuestra red sobre una zonaurbana, y tomar y analizar datos reales que nos aporten informaci´n ver´ o ıdica basada enuna experimentaci´n real. Sin embargo, dado el alcance del proyecto, del presupuesto oque eso supondr´ y que, gracias a las herramientas de simulaci´n con las que hoy en d´ ıa, o ıacontamos, podemos hacer simulaciones muy aproximadas a situaciones reales, unicamente ´debemos crear escenarios algo m´s complejos y que guarden similitudes con los entornos areales. Este entorno ideal ser´ una copia exacta de una peque˜a ciudad, poblaci´n o barrio, ıa n ocon calles, cruces, rotondas y un dibujo de la v´ muy irregular. Pero antes de llevar ıalas pruebas a ese escenario, pasemos por uno intermedio, un escenario de tipo ”rejillaManhattan”, cuyo trazado se hizo famoso en 1811 en el plan de desarrollo urbano de laisla de Manhattan (Gouverneur Morris, John Rutherfurd y Simeon De Witt [6] - Figura6.6).
  • 109. 86 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS Figure 6.6: Mapa de Manhattan - 1807 As´ con este tipo de trazado, muy utilizado para diferentes operaciones heur´ ı, ısticas(”manhattan distance” [7]), podremos obtener de los veh´ ıculos un comportamiento m´sairregular, aleatorio, variable y ca´tico. M´s real, a fin de cuentas. o a Como describimos en un punto anterior, podemos realizar nuestras propias descrip-ciones de caminos y v´ de forma manual, mediante la definici´n de nodos, bordes y ıas ocarriles. Para un escenario simple como en el que hemos llevado a cabo las simulacionesanteriores, dicha descripci´n es sencilla y r´pida. Sin embargo, para el nuevo escenario o aque proponemos, el n´mero de nodos aumenta, as´ como los bordes y carriles asociados, u ılo que conlleva un trabajo meticuloso y arduo. Para evitar la definici´n manual y ahorrar otiempo, podemos utilizar una serie de herramientas que automatizan este proceso. As´ una de las herramientas que nos permiten generar autom´ticamente el archivo que ı, adefine el mapa de carreteras (*.net.xml), es la aplicaci´n MOVE que hab´ o ıamos presentadoal inicio del cap´ ıtulo. En nuestro caso, como hemos comentado, crearemos un escenario basado en ”rejillamanhattan”, en concreto, definida por seis calles horizontales y seis calles verticales, conuna separaci´n entre ellas de cuatrocientos metros (Figura 6.7). o Nos encontraremos entonces con la siguiente ventana (Figura 6.8). Tras seleccionar ”Mobility Model”, nos encontraremos con las opciones de la Figura6.9. Tras seleccionar ”Random Map” la aplicaci´n nos presenta la opci´n de definir una serie o ode par´metros antes de generar el mapa aleatorio (Figura 6.10). As´ en nuestro caso, a ı,seleccionamos el m´todo de generaci´n basado en rejilla (”grid layout”), estableciendo el e on´mero de intersecciones vertical y horizontal igual a seis y una separaci´n entre ellas u ode cuatrocientos metros. Establecemos el nombre de salida de nuestro archivo de red(”manhattan.net.xml”) y confirmamos. El resultado es un archivo xml que contiene la descripci´n de dicha red, y que m´s o atarde SUMO podr´ interpretar adecuadamente (Figura 6.11). a
  • 110. 6.4. ESCENARIOS 87 Figure 6.7: Esquema rejilla manhattan Figure 6.8: MOVE - Generaci´n de escenarios o Una vez disponemos de la descripci´n est´tica de nuestro escenario, basado en la ”re- o ajilla manhattan”, dotaremos a la red del comportamiento din´mico necesario para que la asimulaci´n se aproxime a una situaci´n real de tr´fico que pudiera darse en una topolog´ o o a ıaen rejilla en un entorno urbano. Para ello, y haciendo uso de la herramienta JTRROUTER que hab´ ıamos presentado alinicio del cap´ ıtulo, realizaremos el proceso de generaci´n del archivo de rutas para obtener oeste comportamiento din´mico. a Por un lado tendremos en cuenta el archivo de red generado por MOVE (”manhat-tan.net.xml”). Por otro, y teniendo en cuenta dicho escenario est´tico, crearemos, de aforma manual, el archivo de flujos (”mahattan.flows.xml”) y el archivo de configuraci´n o(”manhattan.jtr.cfg”) que se detalla a continuaci´n: o<configuration> <input net-file=’’manhattan.net.xml’’ flow-definition=’’manhattan.flows.xml’’ /> <output output-file=’’manhattan.rou.xml’’ /> <processing continue-on-unbuild=’’true’’
  • 111. 88 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS Figure 6.9: MOVE - Generaci´n aleatoria de escenarios o turn-defaults=’’25,25,25,25’’ sinks=’’4/0to5/0’’ /></configuration> Mediante este archivo de configuraci´n, indicamos a JTRROUTER que deseamos ogenerar un archivo de rutas para un mapa que se encuentra definido en ”manhattan.net.xml”y que, mediante el archivo de flujos ”manhattan.flows.xml”, cuyo contenido es el siguiente,<flowdefs><flow id=’’flow0’’ from=’’0/5to0/4’’ begin=’’0’’ end=’’100’’ no=’’25’’ /></flowdefs> pretendemos que las rutas que se generen partan desde el edge ”0/5to0/4” y se aplique aun total de 25 veh´ ıculos, que ser´n generados entre el intervalo de tiempo 0 a 100 segundos. a Pero adem´s, lo que es m´s importante, y que es lo que otorga a nuestro escenario a ael car´cter aleatorio y ca´tico, se encuentra en las ultimas l´ a o ´ ıneas. En concreto, ”turn-defaults”, que indica la probabilidad de que un veh´ ıculo gire a la izquierda, a la derecha,al frente, o hacia atr´s, y que establecemos en un valor de 25œ(el valor ”sinks” define el apunto final en el que muere un veh´ ıculo). Finalmente, ejecutaremos, en l´ ınea de ´rdenes: o
  • 112. 6.4. ESCENARIOS 89Figure 6.10: MOVE - Configuraci´n de par´metros - Generaci´n aleatoria de escenarios o a ojtrrouter -c manhattan.jtr.cfg -t manhattan.turns.xml El resultado es un archivo (”manhattan.rou.xml”) que podremos inyectar a SUMO,junto con el archivo de red (”manhattan.net.xml”) para generar la simulaci´n en la rejilla omanhattan.6.4.4 Escenario 4: escenario real - Campus Externo UAH y barrio anexo Tras la generaci´n del escenario basado en la cuadr´ o ıcula Manhattan, el siguiente pasoes recrear un mapa de carreteras real, basado en una zona urbana, con diversidad deintersecciones, rotondas, giros, curvas y dem´s componentes que podemos encontrar al acircular por cualquier ciudad con nuestro veh´ıculo. Para ello nos aproximaremos, a vista de sat´lite, hasta el campus externo de la Uni- eversidad de Alcal´ de Henares, para fijarnos en sus calles y barrios anexos (Figura 6.12). a De nuevo, como comentamos a la hora de realizar la definici´n del archivo de red para ola rejilla Manhattan, podr´ ıamos, armados de tiempo y paciencia, realizar la descripci´node la red nodo a nodo, conect´ndolos entre s´ definiendo cada uno de los carriles, curvas y a ı,
  • 113. 90 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS Figure 6.11: Escenario generado operativo en SUMO Figure 6.12: Campus externo y barrio anexo de la Universidad de Alcal´ de Henares arotondas. Afortunadamente, y como en el caso anterior, existen una serie de herramientasque nos facilitan este proceso. A continuaci´n pasamos a describir c´mo emplearlas. o o Lo primero que debemos hacer es localizar el escenario que deseamos describir en elnavegador de mapas open source por excelencia, OpenStreetMap. OpenStreetMap[11], (tambi´n conocido como OSM ), es un proyecto colaborativo para ecrear mapas libres y editables, un concepto muy pr´ximo a Wikipedia[12]. Una de las oventajas de OpenStreetMap es que, libre de derechos, podemos extraer los metadatosasociados a una zona geogr´fica y trabajar libremente con ellos. As´ pues, una vez en a ıel buscador de OpenStreetMap, en la secci´n ”exportar”, basta con seleccionar la opci´n o o”Datos formato OpenStreetMap XML”, ”seleccionar a mano otro ´rea” (si no deseamos aexportar toda la ventana) y confirmar (Figura 6.13). Inmediatamente comenzar´ la adescarga del archivo .xml que contiene la descripci´n de dicha zona. o El siguiente paso es convertir dicho archivo a un archivo de red (*.net.xml) v´lido para a
  • 114. 6.4. ESCENARIOS 91 Figure 6.13: Exportando datos de OpenStreetMapSUMO. Para ello, utilizaremos de nuevo la herramienta NETCONVERT, de la siguienteforma:netconvert --osm-files alcala.osm.xml -o alcala.net.xml Obtendremos el archivo de red que utilizaremos para trabajar con SUMO. En este punto volvemos a encontrarnos con una descripci´n de v´ compleja, con mul- o ıastitud de intersecciones y carriles, pero sin un archivo de rutas que defina el comportamientode cada veh´ ıculo. Basta con volver unas l´ ıneas atr´s y comprobar que debemos proceder ade la misma forma que con el archivo de red de Manhattan. Figure 6.14: Escenario final del campus externo UAH en SUMO Definimos un archivo de flujo que defina el n´mero de veh´ u ıculos que pondremos enescena, y desde un punto de partida (”alcala.flows.xml”):<flowdefs> <flow id=’’flow0’’ from=’’-50170608#0’’ begin=’’0’’ end=’’100’’ no=’’25’’ /></flowdefs> Y un archivo de configuraci´n para la herramienta JTRROUTER (”alcala.jtr.cfg”): o
  • 115. 92 ´ CHAPTER 6. ESPECIFICACION DE ESCENARIOS<configuration> <input net-file=’’alcala.net.xml’’ flow-definition=’’alcala.flows.xml’’ /> <output output-file=’’alcala.rou.xml’’ /> <processing continue-on-unbuild=’’true’’ turn-defaults=’’25,25,25,25’’ sinks =’’-50170573’’ /></configuration> Finalmente, utilizando JTRROUTER, obtendremos el archivo de rutas que necesitamospara generar la simulaci´n sobre este escenario: ojtrrouter -c alcala.jtr.cfg El resultado del escenario din´mico en SUMO se puede observar en la Figura 6.14. a
  • 116. Chapter 7 ´SIMULACION YRESULTADOS Uno de los puntos determinantes del proyecto se centra en los resultados. Debemosofrecer un tipo de resultado, bien un sistema funcional que cumpla con un objetivo de-terminado, bien una serie de muestras o valores que nos permitan extrapolarlos y obtenerciertas conclusiones. En nuestro caso, dado que estamos contemplando el env´ de men- ıosajes en difusi´n, en un entorno din´mico, en el que influye tanto la forma de la red como o adel entorno que rodea a la misma, debemos atender a valores relacionados con esos men-sajes, tiempo de vida media en escena, en funci´n del n´mero de veh´ o u ıculos, de la velocidadde estos, del escenario y su impacto, el n´mero de vehiculos ”ciegos” que no logran recibir ulos mismos. . . Por otra parte, este tipo de informaci´n, en un escenario como en el que estamos otrabajando (centr´monos ya en la propia simulaci´n bajo el entorno OMNET), requiere e ode ciertos ajustes para realizar correctamente las mediciones. Si observamos nuestro escenario de simulaci´n, desde el nivel m´s alto de abstracci´n, o a onos encontramos con la disposici´n de elementos que podemos ver en la figura 7.1. o Figure 7.1: Componentes b´sicos en una simulaci´n SUMO-OMNET a o Nos encontramos con tres m´dulos (manager, world y connectionManager ). Si es- otudi´ramos un ejemplo simple, en el que no utiliz´semos SUMO, ver´ a a ıamos en el escenarioalg´n elemento ”host” que es el que realiza, en nuestro caso, las funciones de comunicaci´n u o 93
  • 117. 94 ´ CHAPTER 7. SIMULACION Y RESULTADOSdentro de nuestros veh´ ıculos. Sin embargo, la particularidad de MIXIM es que un gestorsuperior (manager ) permite comunicarse con SUMO para obtener indicaciones de c´mo omover cada uno de nuestros veh´ ıculos (nuestros host) dentro de OMNET, ayud´ndose de alos otros dos m´dulos para manejar la comunicaci´n entre ellos y otro tipo de par´met- o o aros. En resumidas cuentas, no veremos directamente en este nivel el m´dulo que modela oel comportamiento de cada host, pues es instanciado de forma interna por el ”manager”,pero s´ debemos saber que existen. As´ y para ilustrar esta idea veamos la figura 7.2. ı ı, Figure 7.2: Manager controlador en OMNET Vemos entonces c´mo ”manager” indica a cada host c´mo debe comportarse en el o oescenario en base a las indicaciones que recibe del motor SUMO (que es realmente elsimulador de la red de veh´ ıculos). Y en este punto, y viendo el gr´fico, podemos pensar aque cada host es un m´dulo diferente, y que debemos crearlos todos, sin embargo (como ocabr´ esperar), son instancias de un unico m´dulo. (figura 7.3 - car.ned): ıa ´ o Figure 7.3: Componente ”car” en OMNET Estamos ya familiarizados con este m´dulo, que es el que contiene el protocolo 802.15.4 ocon nuestro propio nivel de aplicaci´n. Es en ese nivel de aplicaci´n donde hemos ido re- o oalizando las modificaciones, a˜adiendo nuestros algoritmos APAL, y donde manej´bamos n a ıamos y envi´bamos. Es en ese m´dulo (mi app layer) donde ten-los mensajes que recib´ a o
  • 118. 95emos acceso a los valores que coment´bamos anteriormente y que deben convertirse en alos resultados a mostrar. Y es en ese nivel de aplicaci´n donde podemos hacer uso de las oherramientas que nos ofrece OMNET para mostrar resultados estad´ ısticos. Sin embargo,no lo haremos as´ Veamos por qu´. ı. e Si creamos dentro de nuestro m´dulo ”mi app layer” las funciones necesarias para al- omacenar las estad´ısticas que deseamos, nos encontraremos con un n´mero de estad´ u ısticas”paralelas” equivalente al n´mero de host que tengamos en el escenario. Frente a esto, unecesitamos un observador, externo al host, que se instancie de forma independiente, yque pueda comunicarse con cada uno de los hosts. OMNET y MIXIM utilizan el concepto de ”blackboard” para este cometido. Siendom´s precisos, se trata de un ”tabl´n de anuncios” en el que un ”editor” puede publicar a oy un ”lector” puede suscribirse al tabl´n y ser avisado cuando el primero publique en el omismo. Podemos decir que es un canal ”bidireccional” a trav´s del cual pueden comuni- ecarse m´dulos independientes y ser alertados cuando suceden cambios. Sin embargo, en onuestro caso, podemos evitar el uso de esta soluci´n (que es algo m´s compleja), pues no o anecesitamos comunicaci´n bidireccional para mostar los resultados (se muestran y ya est´). o aAs´ pues, basta con crear un m´dulo externo, emplazado en el nivel superior del escenario, ı oaccesible a todos los ”hosts”, con m´todos determinados que permitan el almacenamiento ede estad´ısticas. As´ el panorama cambia, como podemos observar en la figura 7.4. ı, Figure 7.4: Componentes b´sicos + observador en OMNET a Qu´ valores debemos almacenar? e ˆ Tiempo medio que tarda en llegar un mensaje a los hosts de la red – en funci´n del n´mero de veh´ o u ıculos – en funci´n de la velocidad o – en funci´n del entorno (ver implementaci´n de simulaci´n de atenuaci´n) o o o o ˆ N´mero de veh´ u ıculos ciegos (no logran recibir mensaje) – en funci´n del tiempo m´ximo de vida del mensaje o a – en funci´n del n´mero de veh´ o u ıculos
  • 119. 96 ´ CHAPTER 7. SIMULACION Y RESULTADOS – en funci´n de la velocidad o – en funci´n del escenario (manhattan, ciudad real) o Para comprobar el correcto planteamiento y funcionamiento del observador que noshace un registro estad´ ıstico, vamos a partir de un caso b´sico. Una v´ con forma de a ıacuadrado, en el que inyectamos un tr´fico de 10 veh´ a ıculos que circulan en sentido horarioy que el primero es el unico que hace de emisor (figura ??). Obtendremos el tiempo medio ´en llegar a los veh´ ıculos. net.nod.xml:<nodes><node id="a" x="0.0" y="300" /><node id="b" x="300.0" y="300" /><node id="c" x="300.0" y="0" /><node id="d" x="0.0" y="0" /></nodes> net.edg.xml:<edges><edge id="ed_ab" fromnode="a" tonode="b" priority="1" nolanes="1" speed="11.111" /><edge id="ed_bc" fromnode="b" tonode="c" priority="1" nolanes="1" speed="11.111" /><edge id="ed_cd" fromnode="c" tonode="d" priority="1" nolanes="1" speed="11.111" /><edge id="ed_da" fromnode="d" tonode="a" priority="1" nolanes="1" speed="11.111" /></edges> net.rou.xml:<routes><route id="basica" multi ref="x" edges="ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da"/><flow id="flujo_basico" route="basica" begin="50" end="500" no="10"/></routes> A continuaci´n, debemos implementar tanto en nuestra capa de aplicaci´n como en o oel observador, las correspondientes funciones que permitan extraer el tiempo medio quetarda en llegar un mensaje a cada receptor, desde que el primer veh´ ıculo lo env´ Debemos ıa.tener en cuenta que este emisor realiza broadcast de un mensaje nuevo cada segundo y,por tanto, debemos diferenciar todos y cada uno de los mensajes que coexistan y calcularpara cada uno de ellos su tiempo medio de recepci´n y promediar el total. o Para ello, crearemos un vector que vaya guardando los tiempos medios que van acu-mul´ndose para cada uno de esos mensajes, que podremos identificar mediante su campo ade identificaci´n unico, y gracias al sello ”timestamp” de inicio que tambi´n se almacena o ´ een los mensajes en su respectivo campo. As´ pues, el flujo de trabajo para obtener el tiempo de vida que tarda un mensaje en ıllegar a un determinado host podemos verlo en la figura 7.6.
  • 120. 97 Figure 7.5: Escenario v´ cuadrada ıa As´ el observador en cuesti´n, con la funcionalidad simplificada a obtener el tiempo ı, omedio que un mensaje tarda en llegar a un receptor, es el siguiente: observador.h#ifndef MIXIM SOMMER OBSERVADOR H#define MIXIM SOMMER OBSERVADOR H#include <omnetpp.h>/*** TODO - Generated class*/{protected:virtual void initialize();virtual void handleMessage(cMessage *msg);virtual void finish();double valores_asociados[4][10000];int i_valores_asociados;cOutVector st_valor;public:void grabar_estadistica(double);void inserta_valor(double,int);//inserta_valor(valor,indice)void actualiza_valor(double,int);//actualiza_valor(valor,indice)double consulta_valor(int);//consulta_valor(indice)double haz_media();int existe_valor(int);};#endif observador.cc#include "observador.h"
  • 121. 98 ´ CHAPTER 7. SIMULACION Y RESULTADOS Figure 7.6: Diagrama de flujo del observadorDefine Module(Observador);void Observador::initialize(){// TODO - Generated method bodyst valor.setName("estadisticas");}void Observador::handleMessage(cMessage *msg){// TODO - Generated method body}void Observador::grabar estadistica(double valor){st valor.record(valor);}void Observador::inserta valor(double valor, int uid){int i,encontrado;i = 0;encontrado = 0;if(!existe valor(uid) && (valor > 0.0000001)){valores_asociados[0][i_valores_asociados]=valor;valores_asociados[1][i_valores_asociados]=uid;valores_asociados[2][i_valores_asociados]=1;EV << "valor asociado:" << valor << endl;i valores asociados ++;}else{if(valor > 0.0000001){while((i< i valores asociados)&&(!encontrado)){if(uid == valores asociados[1][i]) encontrado = 1; else i++;}EV << "el valor actualizado es:" << valores asociados[0][i] << endl;//n´ mero de actualizaciones de promedio (cuantos veh´ u ıculos han recibido dicho mensaje )valores asociados[2][i]=(valores asociados[2][i])+1;//actualizamos promedio para el mensaje que acabamos de recibir
  • 122. 99valores asociados[0][i]=(valores asociados[0][i] * (((valores asociados[2][i])-1)/ valores asociados[2][i]))+(valor/valores asociados[2][i]);EV << "junto con este nuevo:" << valor << endl;EV << "el n´mero de lecturas es:" << valores asociados[2][i] << endl; uEV << "y la nueva media es:" << valores asociados[0][i] << endl;}}}int Observador::existe valor(int uid){int i, encontrado;i=0;encontrado = 0;while((i< i valores asociados)&&(!encontrado)){if(uid == valores asociados[1][i]) encontrado = 1; else i++;}return encontrado;}double Observador::consulta valor(int uid){int i, encontrado;encontrado = 0;i = 0;while((i <= i valores asociados) && (!encontrado)){if(uid == valores asociados[1][i]) encontrado = 1; else i++;}if(encontrado) return valores asociados[0][i]; else return -1;}double Observador::haz media(){int i;double aux, aux1;aux = 0;for(i=0; i< i valores asociados; i++){aux = aux + valores asociados[0][i];EV << "valores asociados" << valores asociados[0][i] << endl;}aux1 = (aux / i valores asociados);return aux1;}/*** Finalizamos el m´dulo a trav´s de esta funci´n o e o**/void Observador::finish(){this->grabar_estadistica(this->haz_media());} As´ con este primer acercamiento a la obtenci´n de estad´ ı, o ısticas, definimos el siguienteescenario: Tiempo de simulaci´n = 3000 segundos y dimensiones de la v´ = 2500m x o ıa2500m. El resultado de la simulaci´n se refleja como el tiempo medio de recepci´n de o omensaje bajo la tabla 7.1 y la gr´fica de la figura 7.7 a Como se dijo en el punto anterior, entre los valores a estudiar, se encuentra el n´mero ude veh´ıculos ciegos (”blind vehicles”), esto es, el n´mero de veh´ u ıculos que no consiguenrecibir un mensaje de alerta concreto en el tiempo de vida de este ultimo. ´
  • 123. 100 ´ CHAPTER 7. SIMULACION Y RESULTADOS nº de veh´ıculos tiempo medio (segundos) aproximaci´n (ms) o 25 0.010148903914739 10 50 0.0094382959530603 9 100 0.08707856405782 80 150 0.11929866066083 119 200 0.17646911908468 176 250 0.16912641416451 169 300 0.19146343009296 191Tabla 7.1: Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o uveh´ ıculos) - broadcast simple - NO APALFigure 7.7: Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o uveh´ ıculos) - broadcast simple - NO APAL Conocer este par´metro nos permite deducir si el algoritmo de reenv´ es demasiado a ıoagresivo, lo que implica realizar pocos intentos de ”rebroadcast” y bajas probabilidadesde alcanzar veh´ıculos cercanos al ´rea de cobertura; o demasiado suave, donde el control asobre los reenv´ es menor y el problema de ”broadcast storming” aumenta. ıos As´ pues, necesitamos conocer, por cada mensaje que se genere, llevar el control de las ıveces que un veh´ ıculo lo recibe. Para ello, el observador debe ser avisado cada vez queun veh´ ıculo recibe un mensaje. El observador entonces anotar´ en el vector de valores atal suceso, relacionando la recepci´n de ese mensaje y el n´mero de veh´ o u ıculos que lo hanrecibido hasta entonces. Al final, obtendremos, por cada mensaje, el total de veh´ ıculosque recibieron cada uno de ellos, y podremos promediar entre el total de mensajes. Esquem´ticamente, podemos hacernos una idea del proceso descrito observando la afigura 7.8.
  • 124. 101 Figure 7.8: Diagrama de flujo del observador As´ como estructura de datos para llevar dicho control, unicamente utilizaremos una ı, ´tercera fila en nuestro array bidimensional para contabilizar el n´mero de veh´ u ıculos quehan le´ un mensaje con uid determinado, como puede observarse en la figura 7.9. ıdo Figure 7.9: Estructura del vector de registro de datos de veh´ ıculos A continuaci´n, en la tabla 7.2 podemos ver el muestreo realizado, manteniendo las ocondiciones de simulaci´n anteriores (v´ cuadrangular de 2500 x 2500 metros), en la que o ıavariamos, en cada simulaci´n, el n´mero de veh´ o u ıculos en circulaci´n, y su correspondiente ogr´fica en la figura 7.10 a Si observamos el gr´fico (fig. 7.10), vemos como para una baja densidad de veh´ a ıculos,el n´mero de ”blind vehicles” es bastante alto, llegando a cotas cercanas al 95œpara 80 uveh´ıculos. La raz´n es que el bajo n´mero de veh´ o u ıculos en proporci´n a las distancias oentre ellos facilita la existencia de zonas en sombra, donde los mensajes no alcanzan a losvecinos m´s pr´ximos, que se ven incapaces de reenviar hacia los m´s alejados del punto a o ade alerta. En cambio, mientras aumenta el n´mero de veh´ u ıculos en el escenario, esas zonasen sombra pueden rellenarse, permitiendo mayores cotas de alcance, pr´ximas al 15œpara o160 veh´ıculos. Sin embargo, es interesante observar c´mo, a partir de un cierto n´mero de o uveh´ıculos en escena, el algoritmo de reenv´ pierde fuerza y reaparece el ”broadcast storm ıoproblem”, donde las colisiones impiden que los mensajes alcancen finalmente su objetivo. Resumiendo, el n´mero de veh´ u ıculos ciegos depende fuertemente de la densidad detr´fico existente en nuestro escenario, disminuyendo cuando ´sta aumenta, hasta alcanzar a eun l´ ımite de saturaci´n determinado (broadcast storm problem). o
  • 125. 102 ´ CHAPTER 7. SIMULACION Y RESULTADOS nº medio de veh´ ıculos que nº de veh´ ıculos œ”blind vehicles” reciben mensaje 20 4.76 76.2 40 4.6 88.5 60 4.928 91.78 80 5.3 93.37 100 48.5 51.5 120 76.87 35.94 140 92.26 34.1 160 129.36 19.15 180 138.16 23.24 200 156.7 21.65 220 166.23 24.44 240 174.2 27.41 260 180.63 30.52Tabla 7.2: Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje dealerta (en funci´n del n´mero de veh´ o u ıculos) - broadcast simple - NO APAL Para obtener estos resultados, unicamente hemos modificado la clase ”observador”, ´a˜adiendo un nuevo vector de estad´ n ısticas (podr´ıamos haber utilizado sin problemas unescalar), a˜adiendo otro m´todo para obtener la media de estos veh´ n e ıculos ciegos, y modi-ficando el m´todo para guardar las estad´ e ısticas:double Observador::haz media valores(){int i;double aux, aux1;aux = 0;for(i=0; i< i valores asociados; i++){aux = aux + valores asociados[0][i];}aux1 = (aux / i valores asociados);return aux1;}double Observador::haz media bind vehicles(){int i;double aux, aux1;aux = 0;for(i=0; i< i valores asociados; i++){aux = aux + valores asociados[2][i];}aux1 = (aux / i valores asociados);return aux1;
  • 126. 103Figure 7.10: Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje dealerta (en funci´n del n´mero de veh´ o u ıculos) - broadcast simple - NO APAL}void Observador::grabar estadistica(double valor, double valor1){st valor.record(valor);st valor 02.record(valor1);}void Observador::finish(){this->grabar_estadistica(this->haz_media_valores(),this->haz_media_bind_vehicles());} Una vez definidos los dos escenarios, el siguiente paso ser´ obtener una serie de medi- adas en funci´n de unos determinados par´metros que nos permitan obtener ciertas con- o aclusiones. Para ello, en primer lugar, debemos establecer unos par´metros fijos, que no variar´n a aen ninguno de los dos escenarios: A continuaci´n se presentan los resultados para diferentes pruebas: o
  • 127. 104 ´ CHAPTER 7. SIMULACION Y RESULTADOS Par´metro a Valor Wireless Interfaz 802.15.4 Potencia de transmisi´n o 500 mW Modelo de movilidad Modelo de velocidad variable N´mero de veh´ u ıculos de alerta 1 Paquetes enviados por el/los ve- 1 por segundo h´ ıculo/s de alerta Algoritmo de control ”storm broadcast” APAL Velocidad m/s para pruebas con velocidad fija 15 m/s (54 km/h) Dimensiones escenario 2000m x 2000m Tiempo total de simulaci´no 3500 segundos Tiempo de inicio de env´ de ıo 1000 segundos mensajes de alerta Tabla 7.3: Par´metros de simulaci´n a o nº de veh´ıculos tiempo medio (segundos) 25 0.007072685627817 50 0.007199787745076 75 0.010987959991301 100 0.013574591837651 125 0.016334174503593 150 0.035179274952087 175 0.045466363075213 200 0.049251359616137 225 0.06505717896325 250 0.062109701641809 275 0.061436680713181 300 0.071436680713181Tabla 7.4: Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o uveh´ ıculos) - broadcast APAL7.1 Simulaci´n en v´ cuadrada o ıa7.1.1 APAL - Tiempo medio de recepci´n de mensaje de alerta o (en funci´n del n´ mero de veh´ o u ıculos) Observamos en estos resultados como, a medida que aumentamos el n´mero de ve- uh´ ıculos en circulaci´n, aumenta el tiempo medio de recepci´n de los paquetes de alerta. o oEste resultado es l´gico pues a mayor n´mero de veh´ o u ıculos, mayor probabilidad de que unpaquete deba atravesar m´s nodos de la red, con el consiguiente retardo que cada uno de aellos suma en el reenv´ del mismo. No obstante, aunque pueda esto significar que para un ıoaumento de veh´ ıculos el resultado global nos pueda parecer negativo, esto no es as´ como ıpodremos ver a continuaci´n. o
  • 128. 7.1. SIMULACION EN V´ CUADRADA ´ IA 105Figure 7.11: Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o uveh´ ıculos) - broadcast APAL7.1.2 APAL - Blind Vehicles - N´ mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´ mero de o u veh´ ıculos) As´ como observ´bamos en la gr´fica (7.10), podr´ pensarse que un retardo m´ ı, a a ıa ınimo,como el que se obtiene para un bajo n´mero de veh´ u ıculos en escena, ser´ preferible que ıaun retardo algo mayor como el que tenemos si nos aproximamos a la centena de veh´ ıculosactivos. Sin embargo, fij´ndonos en esta otra gr´fica (7.11), donde se muestra el porcentaje a ade veh´ıculos que no consiguen recibir el mensaje de alerta, la sensaci´n global cambia, y onos damos cuenta de que aunque el retardo aumente, para 225 veh´ ıculos activos el n´mero ude veh´ıculos ciegos disminuye por debajo del 25œ. Vemos por tanto una tendencia a la baja seg´n aumentamos el n´mero de veh´ u u ıculosen circulaci´n. Esto se debe a que para pocos veh´ o ıculos, los huecos existentes entre ellosimpiden una cobertura amplia en la que difundir los mensajes, y mejora seg´n aumenta ula densidad de veh´ıculos. Pero cabe se˜alar un punto de inflexi´n existente en los resultados, a partir de la n ocifra 225 veh´ıculos en circulaci´n, donde comienza a aumentar lentamente el n´mero de o uveh´ıculos ciegos. Este hecho pone de manifiesto el problema de ”broadcast storming” quese produce con un n´mero grande de veh´ u ıculos conviviendo en un determinado espacio.
  • 129. 106 ´ CHAPTER 7. SIMULACION Y RESULTADOS nº de veh´ıculos nº de veh´ ıculos no ciegos œ”blind vehicles” 25 2.71 89,16 50 4.08 91,84 75 7.48 90.0266666666667 100 13.75 86.25 125 18.63 85.096 150 50.36 66.4266666666667 175 85.68 51.04 200 129.3 35.35 225 193.31 14.0844444444444 250 208.35 16.66 275 214.8 21.8909090909091 300 228.64 23.7866666666667Tabla 7.5: Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje dealerta (en funci´n del n´mero de veh´ o u ıculos) - broadcast APAL velocidad (m/s) tiempo medio (segundos) 5 0.048343629270837 10 0.061024494525718 15 0.062833164664556 20 0.053831343588155 25 0.053874989359417 30 0.0426030364312 35 0.041898096643327Tabla 7.6: Tiempo medio de recepci´n de mensajes de alerta (en funci´n de la velocidad) o obroadcast APAL7.1.3 APAL - Tiempo medio de recepci´n de mensajes de alerta o (en funci´n de la velocidad) o El siguiente resultado (tabla 7.6) nos ofrece unos valores de eficacia de entrega, entiempo medio de entrega, en funci´n de la velocidad a la que se mueven los veh´ o ıculos.Para realizar esta prueba hemos seleccionado el n´mero de veh´ u ıculos en circulaci´n que oofrec´ menor n´mero de ”blind vehicles”, esto es 225 veh´ ıa u ıculos en escena. Observamos como para bajas velocidades (5 m/s) el tiempo medio de entrega es bajo,mientras que seg´n aumentamos la velocidad hasta los 15 m/s dicho valor aumenta para uvolver a disminuir. Estos resultados, lejos de ser concluyentes, podr´ darnos una idea ıande lo que realmente ocurre para diferentes velocidades. As´ podr´ ı, ıamos suponer que para velocidades pr´ximas a 30 m/s (100 km/h aprox.) ocada nodo puede estar facilitando la entrega a un nodo pr´ximo que, de no ser por la ovelocidad a la que se mueve, depender´ de un nodo intermedio para realizarla, con el con- ıasiguiente aumento de tiempo que esto conlleva. No obstante, estas conclusiones requerir´ ıanun estudio m´s profundo para extraer los motivos reales que originan estos tiempos de en- atrega.
  • 130. 7.1. SIMULACION EN V´ CUADRADA ´ IA 107Figure 7.12: Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje dealerta (en funci´n del n´mero de veh´ o u ıculos) - broadcast APAL velocidad (m/s) nº de vehiculos nº de v no ciegos œ”blind vehicles” 5 225 169.93 24.4755555555556 10 225 176.96 21.3511111111111 15 225 187.2 16.8 20 225 162.93 27.5866666666667 25 225 144.96 35.5733333333333 30 225 120.03 46.6533333333333 35 225 11 47,4044444444444Tabla 7.7: Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta(en funci´n de la velocidad) broadcast APAL o7.1.4 APAL - Blind Vehicles - N´ mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta (en funci´n de la velocidad) o Como para las primeras gr´ficas, vemos c´mo el n´mero de veh´ a o u ıculos ciegos nos ayuda acomprender mejor los resultados obtenidos sobre tiempos medios de entrega. A´n cuando usupon´ıamos que para velocidades mayores el tiempo medio de entrega disminu´ gracias ıaa que esas velocidades favorec´ dichos resultados, comparando con estos datos podemos ıandeducir que esa disminuci´n se debe a un n´mero mayor de veh´ o u ıculos que no reciben dichosmensajes, es decir, a altas velocidades, un veh´ ıculo tiene mayor dificultad para alcanzara sus vecinos. Esto es l´gico si pensamos que ´stos le acompa˜ar´n por menos tiempo o e n adebido a la rapidez con la que se mueven. Adem´s, como en la primera gr´fica, aqu´ tambi´n podemos ver un punto de inflexi´n a a ı e oque devuelve un mayor n´mero de veh´ u ıculos ciegos seg´n nos aproximamos hacia veloci- udades m´s lentas (v´ase tabla 7.7), a partir de los 15 m/s. Podr´ pensarse en esta gr´fica a e ıa acomo una simetr´ inversa de la anterior. En este caso, que los veh´ ıa ıculos se muevan m´s alentamente hace que el problema de ”broadcast storming” aumente, favoreciendo el incre-
  • 131. 108 ´ CHAPTER 7. SIMULACION Y RESULTADOSFigure 7.13: Tiempo medio de recepci´n de mensajes de alerta (en funci´n de la velocidad) o obroadcast APALmento de veh´ ıculos ciegos.7.2 Simulaci´n - Mapa campus externo UAH o Repetimos las mismas pruebas, pero esta vez para el escenario basado en el campusexterno de la Universidad de Alcal´ de Henares (v´ase tabla 7.8 y su respectiva gr´fica a e a7.15).7.2.1 APAL - Tiempo medio de recepci´n de mensaje de alerta o (en funci´n del n´ mero de veh´ o u ıculos)7.2.2 APAL - Blind Vehicles - N´ mero de veh´ u ıculos ”ciegos” que no reciben el mensaje de alerta (en funci´n del n´ mero de o u veh´ ıculos) Analizando conjuntamente la gr´fica de tiempos medios de recepci´n de mensajes y el a o ıculos ciegos en escena (v´ase figura 7.16), y compar´ndolo con los queporcentaje de veh´ e aobtuvimos en el escenario de ”red manhattan”, podemos observar c´mo en este caso el on´mero de veh´ u ıculos ciegos es menor, y que acusa una disminuci´n m´s temprana de ellos o a
  • 132. ´7.2. SIMULACION - MAPA CAMPUS EXTERNO UAH 109Figure 7.14: Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje dealerta (en funci´n de la velocidad) broadcast APAL o nº de veh´ıculos tiempo medio (segundos) 25 0.006970784380327 50 0.015033684924406 75 0.020233480086205 100 0.01832821694987 125 0.019000897152919 150 0.027706380111591 175 0.025834554016553 200 0.027218716558081 225 0.02595455744488 250 0.028664003185155 275 0.030286470339648 300 0.03243668071318Tabla 7.8: Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o uveh´ ıculos) en mapa urbano UAH - broadcast APALfrente a dicho escenario. Este hecho se debe principalmente a que en un escenario real,el n´mero de caminos posibles que puede tomar un veh´ u ıculo es mucho mayor que el quedetermina la rejilla manhattan, que obliga a un mayor n´mero de veh´ u ıculos a ir en unasola direcci´n (cuatro m´ximo), repartiendo de una forma m´s heterog´nea a los veh´ o a a e ıculosy dejando un mayor hueco entre ellos (para manhattan) que para el caso real que se con-templa en esta gr´fica, en la que los veh´ a ıcuos se distribuyen aleatoriamente, favoreciendo elalcance cuando hay pocos veh´ ıculos, y disminuyendo el problema de ”broadcast storming”cuando crece.
  • 133. 110 ´ CHAPTER 7. SIMULACION Y RESULTADOSFigure 7.15: Tiempo medio de recepci´n de mensaje de alerta (en funci´n del n´mero de o o uveh´ ıculos) en mapa urbano UAH - broadcast APAL7.2.3 Tiempo medio de recepci´n de mensaje de alerta (en funci´n o o de la velocidad) Si nos fijamos ahora en los resultados que obtenemos al variar la velocidad de losveh´ ıculos (tabla 7.10), observamos una gr´fica poco definida (figura 7.17), que no nos aindica concreto, a priori, del hecho de aumentar o disminuir la velocidad m´xima a la que ase mueven los mismos. No obstante, es una gr´fica coherente con las condiciones que un aescenario aleatorio y heterog´neo como es que se sirve en la simulaci´n impone. Al ofrecer e otantas v´ con tantos cruces, la velocidad de los veh´ ıas, ıculos realmente no va a mantenerseconstante y cercana al l´ımite que hemos marcado, y, por tanto, no podemos extraer unosresultados v´lidos de dicha gr´fica. a a7.2.4 APAL - Blind Vehicles - N´ mero de veh´ u ıculos ciegos que no reciben el mensaje de alerta (en funci´n de la velocidad) o De la misma forma, el gr´fico que nos indica el n´mero de veh´ a u ıculos ciegos (tabla 7.11y figura 7.18) genera valores incoherentes que llevan a confusi´n, aunque podemos deducir ocierto aumento del n´mero de veh´ u ıculos ciegos a medida que aumentamos la velocidad delos veh´ ıculos, de la misma forma que ocurr´ en el escenario de manhattan. ıa
  • 134. ´7.2. SIMULACION - MAPA CAMPUS EXTERNO UAH 111 nº de vehiculos nº de veh´ ıculos no ciegos œ”blind vehicles” 25 6.78 72.88 50 22.8 54.4 75 38.5 48.6666666666667 100 63.3 36.7 125 95.53 23.576 150 113.53 24.3133333333333 175 113.26 35.28 200 145.6 27.2 225 176.36 21.6177777777778 250 188.76 24.496 275 211 23.2727272727273 300 228.64 23.7866666666667Tabla 7.9: Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje dealerta (en funci´n del n´mero de veh´ o u ıculos) en mapa urbano UAH - broadcast APAL velocidad (m/s) tiempo medio (segundos) 5 0.018167114012302 10 0.026948991491393 15 0.018931593578406 20 0.024597942705083 25 0.023744718627626 30 0.020520994142238 35 0.025668026274513Tabla 7.10: Tiempo medio de recepci´n de mensajes de alerta (en funci´n de la velocidad) o oen mapa urbano UAH - broadcast APAL7.2.5 Obst´culos a Hasta ahora, las mediciones y estad´ ısticas que hab´ ıamos realizado se hab´ circun- ıanscrito a entornos con una visibilidad entre veh´ıculos directa, sin ning´n tipo de obst´culo u aque pudiera interferir en la recepci´n de los mensajes que se enviaran. No obstante, esta osituaci´n id´nea ser´ dif´ de encontrar en escenarios urbanos, donde la arquitectura im- o o a ıcilpone barreras f´ısicas que modifican el comportamiento de la se˜al, afectando en definitiva, na nuestra capacidad de recibir un determinado mensaje. As´ en primer lugar, deber´ ı, ıamosestablecer un par´metro o valor que nos indique en qu´ medida nuestra capacidad de a erecibir un mensaje ha sido alterada, en funci´n de la distancia entre emisor y receptor, ode la calidad del medio de transmisi´n, de los elementos que obstaculicen el camino que orecorre la se˜al de transmisi´n. . . n o Nos encontramos entonces con un par´metro que, en telecomunicaciones, nos per- amite determinar ese tipo de variaci´n en la se˜al frente a p´rdidas o interferencias. Este o n epar´metro es el decibelio (db), y representa la relaci´n existente entre la potencia de se˜al a o nen el emisor y la potencia de se˜al en el receptor : dB = 10 log10 (Ps/Pe) n Gracias a este par´metro podemos evaluar cuantitativamente en valores relativos la acalidad de nuestra se˜al en el receptor respecto a la del emisor. Sin embargo, el siguiente npaso es determinar qu´ factores y en qu´ medida influyen sobre dicha relaci´n. Las sim- e e o
  • 135. 112 ´ CHAPTER 7. SIMULACION Y RESULTADOSFigure 7.16: Blind Vehicles - N´mero de veh´ u ıculos ”ciegos” que no reciben el mensaje dealerta (en funci´n del n´mero de veh´ o u ıculos) en mapa urbano UAH - broadcast APAL velocidad (m/s) nº de v nº de v no ciegos œ”blind vehicles” 5 225 183.33 18.52 10 225 136.93 39.1422222222222 15 225 177.93 20.92 20 225 161.63 28.1644444444444 25 225 168.4 25.1555555555556 30 225 167.3 25.6444444444444 35 225 157.56 29.9733333333333Tabla 7.11: Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje dealerta (en funci´n de la velocidad) en mapa urbano UAH - broadcast APAL oulaciones en redes de comunicaci´n se ven influenciadas por p´rdida de se˜al debido a o e nlargas distancias, p´rdidas determin´ e ısticas a peque˜as escalas o atenuaciones por efectos nprobabil´ ısticos, por lo que el c´mputo total es normalmente calculado como la suma in- odependiente de procesos de atenuaci´n Lx. En este proyecto contemplaremos unicamente o ´dos tipos de factores de atenuaci´n sobre la se˜al de transmisi´n: o n o -Right Two-Ray Model En t´rminos simplificados, este tipo de p´rdida de se˜al viene dada por la forma en que e e nla onda se propaga (v´ase figura 7.19), como podemos observan en la imagen. Por un lado, eel receptor tiene una visi´n directa del emisor, a una distancia d, desde donde se recibe ola se˜al, pero, por otro lado, la misma se˜al se ve reflejada sobre la tierra, con un cierto n na´ngulo de reflexi´n, produciendo un retardo en la se˜al que origina un tipo de interferencia o n
  • 136. ´7.2. SIMULACION - MAPA CAMPUS EXTERNO UAH 113Figure 7.17: Tiempo medio de recepci´n de mensajes de alerta (en funci´n de la velocidad) o oen mapa urbano UAH - broadcast APALconocido como Two-Ray Interference, y que viene dado por la siguiente expresi´n: o d Cf reespace[dB] = 20lg(4π ) (7.1) λ -Attenuation per wall and attenuation per meter of penetration approaches Este tipo de p´rdida de se˜al viene determinado directamente por el entorno en el que e nnos encontremos, con los obst´culos que se dibujen alrededor de cada veh´ a ıculo y de suforma y composici´n. El valor de atenuaci´n que nos impone cada uno de los obst´culos o o aque pudi´ramos encontrarnos podr´ determinarse empleando algoritmos basados en ray- e ıatracing con gran exactitud y granularidad, sin embargo, podemos realizar aproximacionesbasadas en medidas emp´ ıricas anteriores. En este caso, nos apoyaremos en los estudiosrealizados por Christoph Sommer & Co. Univ. of Eralngen, Germany [REF ] en el cualdeterminan que la p´rdida de se˜al al atravesar un determinado obst´culo (un edificio e n acom´n en un ´rea urbana) tiene en cuenta el n´mero de paredes que se atraviesan mul- u a utiplicado por un factor de atenuaci´n (que para un edificio se aproxima a 9.6 dB) y el oespacio interno multiplicado por un factor de atenuaci´n aproximado a 0.45 dB/m. o
  • 137. 114 ´ CHAPTER 7. SIMULACION Y RESULTADOSFigure 7.18: Blind Vehicles - N´mero de veh´ u ıculos ciegos que no reciben el mensaje dealerta (en funci´n de la velocidad) en mapa urbano UAH - broadcast APAL o Figure 7.19: Right Two Ray Model De esta forma, nos encontramos ante la siguiente expresi´n: o Cobs[dB] = Bn + γdm (7.2) Con estos dos par´metros de atenuaci´n a tener en cuenta definimos un entorno de a osimulaci´n simple donde podamos comprobar dicha influencia en valores relativos dB. oPara ello, situamos dos veh´ıculos a una cierta distancia, uno de ellos fijos, y otro enmovimiento, donde, en un determinado momento un obst´culo se interpondr´ entre ambos, a acomo muestra la figura 7.20: Tras esta definici´n de escenario, debemos adaptar nuestro entorno de simulaci´n para o ohabilitar el registro de la p´rdida de se˜al por la influencia de obst´culos. e n a
  • 138. ´7.2. SIMULACION - MAPA CAMPUS EXTERNO UAH 115 Figure 7.20: Movimiento de veh´ ıculo para la comprobaci´n de atenuaci´n o o Figure 7.21: Proyecto Veins - Simulaci´n de obst´culos o aObst´culos en OMNET++ a Como comentamos en un cap´ ıtulo anterior, una de las ventajas de la elecci´n de OM- oNET++ como plataforma de simulaci´n de redes de comunicaciones es que se trata de ouna plataforma abierta, donde el desarrollo es libre y compartido. Gracias a esto podemos encontrarnos proyectos como el de Veins [64], un modelo desimulaci´n de obst´culos con soporte para varios frameworks, entre los cuales, OMNET++ o aMIXIM. As´ para activar las posibilidades que nos ofrece dicho modelo, realizaremos los si- ı,guientes pasos. En primer lugar, descargaremos la versi´n compatible con nuestro framework del sitio, oesto es, el modelo de simulaci´n para OMNET++ MIXIM. o Tras la descarga, necesitaremos copiar una serie de directorios y archivos a nuestroproyecto MIXIM. Entre estos archivos, nos encontramos: ˆ A˜adiremos a nuestro directorio modules, obstacle. n ˆ Copiamos phylayer.cc y phylayer.h ˆ A˜adiremos el m´dulo obstacle a nuestro scenario.ned n o ˆ Modificaremos omnet.ini
  • 139. 116 ´ CHAPTER 7. SIMULACION Y RESULTADOS ˆ A˜adimos test.obstacles.xml n Figure 7.22: Estadistica Por otro lado, debemos realizar ajustes m´s finos, relacionados con el c´digo existente a oen el m´dulo de obst´culos. o a As´ en obstacles.cc modificamos las siguientes l´ ı, ıneas:// calculate attenuation double totalDistance = senderPos.distance(receiverPos); double attenuation = (attenuationPerWall * numWalls) + (attenuationPerMeter * fractionInObstacle * totalDistance); EV << "Atenuaci´n: " << attenuation << " db " << endl; o return pow(10.0, -attenuation/10.0); por este otro:double totalDistance = senderPos.distance(receiverPos); double attenuation = (attenuationPerWall * numWalls) + (attenuationPerMeter * fractionInObstacle * totalDistance); EV << "Atenuaci´n: " << attenuation << " db " << endl; o return -attenuation; Reduciremos el nivel de ruido original, donde 50db y 1db era un valor demasiado alto:double attenuationPerWall = 9.2; /**< in dB */ double attenuationPerMeter = 0.32; /**< in dB / m */ if (type == "building") { attenuationPerWall = 9.2; attenuationPerMeter = 0.32; }
  • 140. ´7.2. SIMULACION - MAPA CAMPUS EXTERNO UAH 117 Figure 7.23: Matriz grid Manhattan de obst´culos a nº de vehic t medio (seg) t medio (seg) ”blind vehicles” 25 0.007209680001107 0.007072685627817 50 0.007617448143321 0.007199787745076 75 0.008395350651071 0.010987959991301 100 0.013129935217123 0.013574591837651 125 0.018938251818686 0.016334174503593 150 0.025972732589758 0.035179274952087 175 0.030080657313761 0.045466363075213 200 0.031529364457014 0.049251359616137 225 0.044340576195803 0.06505717896325 250 0.036982368803253 0.062109701641809 275 0.043089638515126 0.061436680713181 300 0.046655336079543 0.071436680713181 Tabla 7.12: Tiempo medio de recepci´n de mensajes con y sin obst´culos o a Por ultimo, para reflejar en los resultados las variaciones que introducen los obst´culos, ´ aa˜adiremos las siguientes l´ n ıneas para habilitar el plottingif (factor == 1){ aux = 100 -((10 * 2.4 * log(senderPos.distance(receiverPos)))); atenuacions.record(aux); }else{ atenuacions.record(factor); } return factor; El resultado de las mediciones es que se observa en la figura 7.22. Una vez comprobado que el modelo con obst´culos se comporta como esperamos, in- acluyendo los dos par´metros de atenuaci´n comentados, el siguiente paso es llevar dichos a ovalores al escenario con el que hemos venido trabajando hasta ahora.
  • 141. 118 ´ CHAPTER 7. SIMULACION Y RESULTADOS Figure 7.24: Tiempo medio de recepci´n de mensajes con y sin obst´culos o a En este sentido, podr´ıamos incluirlos tanto en el escenario de grid manhattan como enel escenario real del campus universitario de Alcal´, sin embargo, dado que la definici´n de a ola estructura que representa los obst´culos es compleja de elaborar, para el escenario real adel campus se hace demasiado laboriosa. No obstante, podemos obtener unos resultadosconcluyentes con el ”grid manhattan” como observamos en las estad´ ısticas que se presentana continuaci´n. o Para ello, hemos incluido en el grid manhattan una ret´ ıcula de obst´culos en los espacios aexistentes entre las v´ de circulaci´n como se muestra en la figura 7.23. ıas o En las gr´ficas anteriores se muestran los resultados obtenidos con obst´culos, y los a a nº de vehic nº de ”blind vehicles” œvehic no ciegos œ”blind vehicles” 25 2.52 89.92 89.16 50 4.51 90.98 91.84 75 5.45 92.7333333333333 90.02 100 12.62 87.38 86.25 125 19.16 84.672 85.09 150 35.43 76.38 66.42 175 44.33 74.6685714285714 51.04 200 48.03 75.985 35.35 225 99.03 55.9866666666667 14.08 250 104.13 58.348 16.66 275 144.8 47.3454545454545 21.89 300 141.73 52.7566666666667 23.78 Tabla 7.13: N´mero de veh´ u ıculos ciegos con y sin obst´culos a
  • 142. ´7.2. SIMULACION - MAPA CAMPUS EXTERNO UAH 119 Figure 7.25: N´mero de veh´ u ıculos ciegos con y sin obst´culos a velocidad (m/s) t medio (seg) t medio (seg) ”blind vehicles” 5 0.048370934391316 0.048343629270837 10 0.055500794271592 0.061024494525718 15 0.063731446790672 0.062833164664556 20 0.05123674211268 0.053831343588155 25 0.052311978312052 0.053874989359417 30 0.042951989775603 0.0426030364312 35 0.044822091702791 0.041898096643327Tabla 7.14: Tiempo medio de recepci´n de mensajes con y sin obst´culos en funci´n de la o a ovelocidadque se obtuvieron sin tenerlos en cuenta.
  • 143. 120 ´ CHAPTER 7. SIMULACION Y RESULTADOSFigure 7.26: Tiempo medio de recepci´n de mensajes con y sin obst´culos en funci´n de o a ola velocidad v(m/s) nº vehic nº ”blind vehic” œv no ciegos œ”blind vehi” 5 225 154.36 31.3955555555555 24.47 10 225 138.4 38.4888888888889 21.35 15 225 174.16 22.5955555555556 16.8 20 225 149.46 33.5733333333333 27.58 25 225 127.83 43.1866666666667 35.57 30 225 112.06 50.1955555555556 46.65 35 225 107.43 52.2533333333333 47.4 Tabla 7.15: N´mero de veh´ u ıculos ciegos con y sin obst´culos en funci´n de la velocidad a oFigure 7.27: N´mero de veh´ u ıculos ciegos con y sin obst´culos en funci´n de la velocidad a o
  • 144. Chapter 8SEGURIDAD EN REDESVANET BAJO PROTOCOLO802.15.4 Al trabajar con redes de comunicaci´n inal´mbricas nos enfrentamos con problemas o ade seguridad que pueden comprometer al sistema. Al igual que en una red tradicional decomunicaci´n, los requisitos de seguridad en una VANET son los siguientes (figura 8.1): o ˆ Confidencialidad : Propiedad de la informaci´n por la que se garantiza que est´ o a accesible unicamente a personal autorizado. ´ ˆ Integridad : Propiedad de la informaci´n por la que se garantiza que ´sta no se ve o e alterada o modificada por personal no autorizado. ˆ Disponibilidad : Propiedad que asegura y garantiza al usuario el uso del sistema en cualquier momento determinado. ˆ No repudio: No se puede negar la autor´ ıa. No obstante, las caracter´ısticas que imponen las redes VANET en cuanto a topolog´ ıadin´mica, falta de procesamiento centralizado, etc. dificultan el cumplimiento de estos arequisitos de seguridad. La pol´ıtica de seguridad a aplicar en un entorno ad-hoc depender´, aen gran media, de la aplicaci´n y del escenario concreto para los que se realiza el despliegue ode la red. Las propuestas de seguridad deben adaptarse a las necesidades espec´ ıficas quesurgen en el planteamiento de una u otra red de comunicaci´n. Para nuestro caso, redes oVANET definidas sobre la teor´ de redes ad-hoc, estas pol´ ıa ıticas de seguridad deber´nacubrir b´sicamente cuatro requisitos: control de acceso a la red, sistema de detecci´n de a ointrusos (IDS), seguridad de los protocolos de encaminamiento y servicios de gesti´n de oclaves. 121
  • 145. 122 CHAPTER 8. SEGURIDAD EN REDES VANET BAJO PROTOCOLO 802.15.4 Figure 8.1: Requisitos a cumplir en seguridad de la informaci´n o Estas pol´ ıticas de seguridad deber´n ser lo suficientemente robustas como para garan- atizar que un posible atacante sea incapaz de comprometer el sistema, entendiendo el papelde atacante como cualquier individuo o equipo que realice alguno de los siguientes ataquesb´sicos (principalmente). a Ataques b´sicos: a ˆ Falsificaci´n de la informaci´n: El atacante difunde informaci´n falsa o err´nea para o o o o que afecte al resto de los veh´ ıculos. ˆ Manipulaci´n de la informaci´n del sensor : Modificar su posici´n, direcci´n, ve- o o o o locidad, etc. para escapar de ciertas responsabilidades como por ejemplo, haber provocado un accidente. ˆ Denegaci´n de servicio: Utilizar un inhibidor de frecuencia para conseguir que un o veh´ ıculo no reciba ninguna se˜al de su entorno en una cierta zona. n ˆ Falsificaci´n de identidad. o ˆ Rastreado de veh´ıculos: Seguir la pista de un veh´ ıculo infect´ndolo con alg´n virus a u que monitorice el estado de dicho veh´ ıculo. Al igual que ocurre en redes tradicionales, las VANETs no quedan exentas de intru-siones externas y, por lo tanto, es necesario establecer un mecanismo de control de accesoa la red y sus servicios. Ante un ataque en el que un intruso acceda a los servicios dela red puede derivar en consecuencias catastr´ficas ya que, en las VANETs, los nodos oasumen tareas de gesti´n y encaminamiento, dado que no existe una entidad central que oasuma dicha responsabilidad. De esta forma, un intruso puede desviar el tr´fico durante ael encaminamiento o tener acceso a claves de identificaci´n.o
  • 146. 8.1. CONTROL DE ACCESO 123 Tanto en la capa de red como en la de aplicaci´n es necesario llevar a cabo un control ode acceso que impida que un nodo sin autorizaci´n sea capaz de recibir o encaminar oinformaci´n (nivel de red) o que pueda acceder a servicios cr´ o ıticos como ser´ el de gesti´n ıa ode claves (nivel de aplicaci´n). o As´ pues, parece determinante ofrecer una pol´ ı ıtica de control de acceso robusta. Veamosm´s detenidamente este aspecto. a8.1 Control de acceso A trav´s del control de acceso, un usuario puede acceder a la red y sus servicios tras un eproceso de identificaci´n y autorizaci´n. La forma en que se realiza este tipo de procesos o odepende en gran medida de las caracter´ ısticas de la red. As´ existen redes ad-hoc en la que ı,los servicios de autenticaci´n se encuentran centralizados, mientras que en otras redes estos oservicios se encuentran distribuidos. Esto supone la aplicaci´n de unos u otros mecanismos ode control de acceso. Si elegimos un mecanismo de control de acceso distribuido para lared, ser´ necesario un control de acceso basado en certificados digitales y autoridades acertificadoras. En otros esquemas con servicios centralizados se requiere una autenticaci´n obasada en usuario y contrase˜a. Es muy util hacer un estudio previo de las necesidades n ´de seguridad de la red a desplegar, de esta forma, se podr´n adecuar los mecanismos de acontrol de acceso a la red. Como primera l´ ınea de defensa, el control de acceso es una buena alternativa, sinembargo, debemos buscar soluciones en caso de que esta barrera se vea comprometida.As´ los sistemas de detecci´n de intrusos (IDS) podr´ protegernos en caso de que un ı, o ıanindividuo no autorizado accediera a la red. Para las redes VANETs, se presentan varias propuestas IDS, veamos las m´s intere- asantes:8.2 (IDS) Sistemas de detecci´n de intrusos o Una soluci´n basada en arquitecturas distribuidas y cooperativas para la detecci´n de o ointrusos, es la que se propone en [51]. En este sistema, un agente de monitorizaci´n SDI olanzado en cada nodo monitoriza todas las actividades locales que ocurren a su alrededor.Si el SDI detecta una intrusi´n a partir de las trazas locales inicia un procedimiento de orespuesta. Si se detecta una anomal´ pero que no hay evidencias formales de la intrusi´n ıa ose usa un protocolo cooperativo con los vecinos para determinar si la intrusi´n tuvo lugar oo no. Otra alternativa, contemplada en [52], tambi´n presenta un IDS distribuido pero op- etimizado para las redes VANET. En este caso, cada nodo no ejecuta un agente de moni-
  • 147. 124 CHAPTER 8. SEGURIDAD EN REDES VANET BAJO PROTOCOLO 802.15.4torizaci´n y control, sino que ofrecen el paso y alojamiento de agentes m´viles -entidades o osoftware aut´nomas, ligeras y din´micamente actualizables- que son capaces de desplazarse o apor la red y ejecutarse en ciertos nodos, de forma que minimizan el uso de los recursos,que en este tipo de redes suele ser limitado (ancho de banda, capacidad de proceso de losnodos. . . ). Es por ello que el empleo de t´cnicas de IDS debe realizarse previo estudio de las ecaracter´ ısticas de la aplicaci´n y del escenario en el que ´sta vaya a ejecutarse, debido o ea la sobrecarga que estos mecanismos pueden introducir, en t´rminos de procesamiento, etransmisi´n y almacenamiento en nodos. Si los requisitos de seguridad exigen fuertes ot´cnicas de control y detecci´n, y si los nodos disponen de suficiente capacidad y autonom´ e o ıapara soportar un IDS, entonces la elecci´n y aplicaci´n de este mecanismo de seguridad es o ojustificable.8.3 Cifrado y firmas digitales Si optamos por utilizar t´cnicas de cifrado y firmas digitales como mecanismo de se- eguridad, tendremos que hacer uso de claves criptogr´ficas. En esta situaci´n, las claves a ocriptogr´ficas deber´n ser compartidas entre los nodos y debe ofrecerse un mecanismo para a agestionar dichas claves. En este sentido, nos encontramos ante dos posibles configuraciones de nuestras redesVANET. Podemos permitir que nuestra propia red gestione de forma aut´noma las claves, oen cuyo caso nos encontrar´ ıamos con VANET auto organizadas; o bien podemos delegardicha gesti´n a una entidad externa de confianza para la gesti´n de estas claves, VANET o ocon gesti´n de claves externa. o En esquemas de VANETs pura, sin red de respaldo, es m´s apropiado usar un esquema ade gesti´n de clave que no depende de ninguna entidad externa. En cambio, si se dispone ode una red de respaldo, se puede optar por esquemas de tipos centralizados. Las soluciones las mas populares son: Para una red VANET pura: ˆ Gesti´n de claves en cadena de certificados. o ˆ Gesti´n de claves basada en movilidad. o Para un red VANET h´ ıbrida: ˆ Autoridades de certificaci´n distribu´ o ıdas. ˆ Gesti´n paralela de claves. o
  • 148. 8.3. CIFRADO Y FIRMAS DIGITALES 125Gesti´n de claves en cadena de certificados o Cada nodo genera su certificado, se distribuye y se almacena en cada nodo de la red.Si un nodo deja de fiarse de otro nodo, se puede pedir una renovaci´n del certificado. oDel mismo modo, si un nodo sospecha que su clave privada ha sido comprometida, puederevocar su propio certificado y generar otra clave privada.Gesti´n de claves basada en la movilidad o Se basa en un esquema de distribuci´n peer-to-peer de las claves de los nodos basada oen la movilidad de cada nodo. Se transmite una clave a un nodo seg´n la movilidad que utiene en un momento para que este nodo distribuya las claves a los nodos a su alcance. Serompe as´ la necesidad de tener una entidad externa para compartir las claves. ıAutoridades de certificaci´n distribuidas o Se basa en una entidad externa de certificaci´n que se encarga de distribuir las claves oa los nodos de la red. Esta entidad debe ser altamente segura para que ning´n atacante upueda tomar el control de ella y comprometer los mecanismos de certificaci´n. Se puede odistribuir los certificados de forma parcial o total. En un mecanismo de distribuci´n parcial de los certificados se elige un subconjunto de onodos llamados servidores a los cuales se transmiten las claves. Esos nodos deben disponerde una clave privada y una clave p´blica para que la entidad externa les pueda identificar ude forma un´ıvoca. Cada uno de los servidores genera una firma parcial utilizando su claveprivada que es enviada a un combinador, que puede ser cualquier servidor. El combinadorreconstruye as´ la firma digital. ı En un mecanismo de distribuci´n total de los certificados, la clave se distribuye a otodos los nodos de la red y requiere que un nodo use la entidad externa para contactar concualquier vecino. No es necesario el concepto de combinador ya que ser´ el propio nodo aqui´n reconstruye la firma digital del grupo. eGesti´n paralela de claves o Esta alternativa descrita en [53] se basa en una distribuci´n parcial de los certificados opor parte de una entidad externa y de un mecanismo de cadenas de certificados. Lapropuesta es conocida como Composite Key Management. La entidad externa distribuyeel certificado a nodos servidores y luego tiene lugar el mecanismo de cadenas de certificados.
  • 149. 126 CHAPTER 8. SEGURIDAD EN REDES VANET BAJO PROTOCOLO 802.15.48.4 ´ SOLUCION ADOPTADA - Autorizaci´n de certi- o ficaci´n distribu´ o ıda Apoy´ndonos en los trabajos de investigaci´n de Alexandre Viejo, Francesc Seb´, Josep a o eDomingo-Ferrer y Jesus Manj´n [50], optamos por un sistema de gesti´n de claves dis- o otribu´ ıdo, basado en agentes externos. El sistema ofrecer´ un mecanismo de seguridad y privacidad en el env´ de mensajes a ıosiempre que los agentes externos que gestionan los identificadores (se˜ales de tr´fico, dis- n apositivos espec´ ıficos, nodos certificados, . . . ) sean fiables. As´ estas se˜ales est´n facul- ı, n atadas para revocar identificadores y alertar a la red sobre nodos de dudosa fiabilidad ocuyas intenciones son entorpecer y comprometer al sistema. Se propone as´ un sistema basado en pseud´nimos v´lidos firmados por autoridades de ı o atr´fico que permiten identificar a usuarios fiables y distinguirlos de aque˜os que pudieran a nser da˜inos, en cuyo caso, su pseud´nimo queda marcado como ”revocado”, y cualquier n omensaje que env´ ser´ autom´ticamente identificado como no seguro. El sistema, adem´s, ıe a a aimpone una pol´ ıtica de renovaci´n de pseud´nimos para ofrecer al usuario un mayor nivel o ode privacidad, al exponer en menor grado el seguimiento y traceado por terceros.8.4.1 Propuesta Distinguimos en nuestra red VANET dos elementos principales: 1. Se˜ales de tr´fico o dispositivos espec´ n a ıficos. 2. Veh´ ıculos movi´ndose por nuestra zona de cobertura. e Las se˜ales de tr´fico se consideran nodos est´ticos y son gestionados por las autori- n a adades de tr´fico (DGT). a Suponemos que las se˜ales de tr´fico son nodos fiables, que no guardan informaci´n n a oacerca de los nodos de la red ni realizan actividades da˜inas en la misma. Estos nodos ntienen la capacidad de generar y almacenar una clave privada SKt, gestionada por laautoridad de tr´fico. La clave p´blica asociada es accesible, conocida y aceptada como a uv´lida por todos los dem´s nodos de la red. a a Cada veh´ ıculo est´ equipado con un dispositivo no manipulable (similar a una tarjeta ainteligente), que no puede ser desinstalado y que impide que el usuario modifique suidentificaci´n. o
  • 150. 8.4. SOLUCION ADOPTADA - AUTORIZACION DE CERTIFICACION DISTRIBU´ ´ ´ ´ IDA 127Transmisi´n de mensajes o Cuando transmitimos mensajes en nuestra red, ya sean mensajes de alerta o informa-tivos, estos ser´n enviados siguiendo la t´cnica de difusi´n uno-a-todos. As´ una se˜al de a e o ı, ntr´fico puede indicar a la red la existencia de un nodo no fiable o deshonesto de esta forma. aDe la misma manera, los veh´ ıculos deben indicar cada cierto tiempo si siguen o no activos,a trav´s de mensajes ”hello-beacons”, que ayudan a gestionar la propia red VANET. e Los mensajes transmitidos v´ broadcast por las se˜ales de tr´fico son de confianza, ıa n aesto es, est´n correctamente firmados y no utilizan pseud´nimo. a o En cambio, los veh´ ıculos s´ necesitan incorporar esta informaci´n en el env´ de sus ı o ıomensajes. Este pseud´nimo IDnode est´ formado por la concatenaci´n de cuatro valores, o a oa los cuales se le aplica la firma SKt. El primer campo es un valor v aleatorio. El segundo es una marca temporal que indicacu´ndo se gener´ dicho pseud´nimo. Y los otros dos campos son las dos claves p´blicas del a o o unodo (PKSnode, PKEnode), utilizadas para firmar y cifrar, respectivamente. Mediante eluso del sello temporal, podemos determinar, si ´sta es m´s antigua que un cierto tiempo e apreestablecido, si es o no un mensaje v´lido. a La tarjeta inteligente del veh´ ıculo contiene su Idnode actual y las claves secretas SKs,node, SKe, node. Gracias a estos datos, cualquier mensaje enviado por un veh´ ıculo es v´lido si su Idnode aes un pseud´nimo v´lido, esto es, si IDnode no ha sido marcado como ”revocado”. Para o alos mensajes ”hello-beacon”, aparte del pseud´nimo, se transmiten las coordenadas GPS oactuales del veh´ıculo, as´ como otros posibles datos, todo ello firmado con SKs,node : ıObtenci´n de un pseud´nimo o o Cuando una se˜al recibe un mensaje ”hello-beacon” que contiene un pseud´nimo ca- n oducado, es decir, el sello temporal ha expirado, ´sta avisa al propietario del mensaje a eactualizar su Idnode. Para ello, el nodo sigue los siguientes pasos: 1. Generaci´n de dos parejas de claves: (SKSnode’ , PKSnode’ ) (SKEnode’, PKEnode’ o ) 2. El nodo genera un nuevo pseud´nimo (figura: 8.2) o *vRandom’, timeStamp’, PKSnode’ y PKEnode’ son valores nuevos, y firmados con SKt antigua.
  • 151. 128 CHAPTER 8. SEGURIDAD EN REDES VANET BAJO PROTOCOLO 802.15.4 Figure 8.2: Nuevo pseud´nimo o Figure 8.3: Mensaje cifrado 3. El nodo env´ el mensaje cifrado de la figura 8.3 a la se˜al de tr´fico. ıa n a 4. La se˜al de tr´fico descifra el mensaje,verifica su contenido (en particular se asegura n a que Idnode no ha sido revocado por un mal comportamiento anterior) y genera el mensaje formado que se puede observar en la figura (8.4): Figure 8.4: Trama hello beacon 5. IDnode es enviado al veh´ ıculo cifrado bajo PKEnode’. 6. El veh´ıculo descifra el mensaje y obtiene su nuevo pseud´nimo Idnode . El sistema o descrito trabaja bajo el supuesto de que cada veh´ ıculo lleva implantado de f´brica a ´ un identificador inicial. Este identificador es firmado con SKt, pero no es un IDnode v´lido. Ser´ despu´s, cuando se comunique con una se˜al, cuando el pseud´nimo a a e n o ser´ actualizado. aBroadcast de mensajes veh´ ıculo-a-todos Un usuario que quiere enviar una alerta a la red selecciona el mensaje a enviar, con-catena el sello temporal y su pseud´nimo y firma el mensaje entero utilizando su clave oprivada. Un posible ejemplo de esta situaci´n se dar´ cuando un coche, atrapado en un atasco, o ıaalerta a los coches cercanos sobre esta situaci´n. Al recibir el mensaje, los otros coches overifican la validez del pseud´nimo. El mensaje se considera v´lido si el pseud´nimo no o a o
  • 152. 8.4. SOLUCION ADOPTADA - AUTORIZACION DE CERTIFICACION DISTRIBU´ ´ ´ ´ IDA 129ha sido revocado. Las se˜ales de tr´fico tienen dos maneras de decidir si un usuario es n adeshonesto o no: 1. Se considera que un mensaje es falso si hay al menos i (par´metro de seguridad) a mensajes de diferentes usuarios informando que un cierto mensaje es falso. 2. La segunda opci´n se basa en la posibilidad de que las se˜ales de tr´?co reciban o n a informaci´n directamente de la autoridad de tr´?co sobre situaciones peligrosas en o a la carretera. Un usuario que env´ informaci´n contradictoria con la fuente oficial ıe o ser´ considerado como deshonesto. a Una vez una se˜al detecta a un usuario deshonesto, notifica a toda la red dicha situaci´n n omediante broadcast.
  • 153. 130 CHAPTER 8. SEGURIDAD EN REDES VANET BAJO PROTOCOLO 802.15.4
  • 154. Chapter 9 ´IMPLEMENTACION ENARDUINO9.1 Arduino Arduino es una plataforma de hardware libre, basada en una placa con un microcon-trolador y un entorno de desarrollo, dise˜ada para facilitar el uso de la electr´nica en n oproyectos multidisciplinares (figura 9.1). Figure 9.1: Arduino Uno El hardware consiste en una placa con un microcontrolador Atmel AVR y puertosde entrada/salida. Los microcontroladores m´s usados son el Atmega168, Atmega328, aAtmega1280, ATmega8 por su sencillez y bajo coste que permiten el desarrollo de m´ltiples u 131
  • 155. 132 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINOdise˜os. Por otro lado el software consiste en un entorno de desarrollo que implementa el nlenguaje de programaci´n Processing/Wiring y el cargador de arranque (boot loader ) que ocorre en la placa. Arduino se puede utilizar para desarrollar objetos interactivos aut´nomos o puede oser conectado a software del ordenador (por ejemplo: Macromedia Flash, Processing,Max/MSP, Pure Data). Las placas se pueden montar a mano o adquirirse. El entorno dedesarrollo integrado libre se puede descargar gratuitamente. Al ser open-hardware, tanto su dise˜o como su distribuci´n es libre. Es decir, puede n outilizarse libremente para el desarrollo de cualquier tipo de proyecto sin haber adquiridoninguna licencia. El proyecto Arduino recibi´ una menci´n honor´ o o ıfica en la categor´ de Comunidades ıaDigital en el Prix Ars Electronica de 2006 [59]. Como hemos comentado, existen diferentes modelos disponibles, bien para construcci´n opropia, a partir de los dise˜os open-hardware que podemos encontrar directamente en el nsitio web [54], o bien adquiri´ndolos directamente en diferentes sitios en internet. e Para nuestro proyecto optamos por uno de los modelos m´s avanzados que podremos aencontrar, Arduino Uno. A continuaci´n detallamos sus caracter´ o ısticas:9.1.1 Visi´n general o El Arduino Uno es una placa con microcontrolador basada en el ATmega328 (). Tiene14 pines con entradas/salidas digitales (6 de las cuales pueden ser usadas como salidasPWM - Pulse Wave Modulation), 6 entradas anal´gicas, un cristal oscilador a 16Mhz, oconexi´n USB, entrada de alimentaci´n, una cabecera ISCP, y un bot´n de reset. Con- o o otiene todo lo necesario para utilizar el microcontrolador. Arduino Uno se diferencia desus predecesores en que no utiliza el circuito controlador FTDI USB-to-serial. Por el con-trario, cuenta con el circuito Atmega8U2 (Atmega8U2 hasta la revisi´n r2) que realiza las ofunciones de convertidor USB a serie.9.1.2 Alimentaci´n o Arduino Uno puede ser alimentado v´ la conexi´n USB o con una fuente de ali- ıa omentaci´n externa. El origen de la alimentaci´n se selecciona autom´ticamente. o o a Las fuentes de alimentaci´n externas (no-USB) pueden ser tanto un transformador o ouna bater´ El transformador se puede conectar usando un conector macho de 2.1mm ıa.con centro positivo en el conector hembra de la placa. Los cables de la bater´ puede ıaconectarse a los pines Gnd y Vin en los conectores de alimentaci´n (POWER) o
  • 156. 9.1. ARDUINO 133 Voltaje de funcionamiento 5V Voltaje de entrada (recomendado) 7-12V Voltaje de entrada (limite) 6-20V Pines E/S digitales 14 (6 proporcionan salida PWM) Pines de entrada anal´gica o 6 Intensidad por pin 40 mA Intensidad en pin 3.3V 50 mA Memoria Flash 32 KB SRAM 2 KB (ATmega328) EEPROM 1 KB (ATmega328) Velocidad de reloj 16 MHz Tabla 9.1: Microcontrolador ATmega328 La placa puede trabajar con una alimentaci´n externa de entre 6 a 20 voltios. Si el ovoltaje suministrado es inferior a 7V el pin de 5V puede proporcionar menos de 5 Voltiosy la placa puede volverse inestable, si se usan mas de 12V los reguladores de voltaje sepueden sobrecalentar y da˜ar la placa. El rango recomendado es de 7 a 12 voltios. n Los pines de alimentaci´n son los siguientes: o ˆ VIN La entrada de voltaje a la placa Arduino cando se esta usando una fuente externa de alimentaci´n (en opuesto a los 5 voltios de la conexi´n USB). Se puede o o proporcionar voltaje a trav´s de este pin, o, si se esta alimentado a trav´s de la e e conexi´n de 2.1mm , acceder a ella a trav´s de este pin. o e ˆ 5V La fuente de voltaje estabilizado usado para alimentar el microcontrolador y otros componentes de la placa. Esta puede provenir de VIN a trav´s de un regu- e lador integrado en la placa, o proporcionada directamente por el USB o otra fuente estabilizada de 5V. ˆ 3V3 Una fuente de voltaje a 3.3 voltios generada en el chip FTDI integrado en la placa. La corriente m´xima soportada 50mA. a ˆ GND Pines de toma de tierra.9.1.3 Memoria El ATmega328 tiene 32KB de memoria flash para almacenar c´digo (2KB son usados opara el arranque del sistema(bootloader ).El ATmega328 tiene 2 KB de memoria SRAM .El ATmega328 tiene 1KB de EEPROM , que puede a la cual se puede acceder para leero escribir con la librer´ EEPROM. ıa
  • 157. 134 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINO9.1.4 Entradas y Salidas Cada uno de los 14 pines digitales en Arduino Uno pueden utilizarse como entradas ocomo salidas usando las funciones pinMode(), digitalWrite(), y digitalRead() . LasE/S operan a 5 voltios. Cada pin puede proporcionar o recibir una intensidad m´xima de a40mA y tiene una resistencia interna (desconectada por defecto)de 20-50kOhms. Adem´s, aalgunos pines tienen funciones especializadas: ˆ Serie: 0 (RX) y 1 (TX) Usado para recibir (RX) transmitir (TX) datos a trav´s e de puerto serie TTL. Estos pins estan conectados a los pines correspondientes del chip FTDI USB-to-TTL. ˆ Interrupciones Externas: 2 y 3 Estos pines se pueden configurar para lanzar una interrupci´n en un valor LOW(0V), en flancos de subida o bajada (cambio de o LOW a HIGH(5V) o viceversa), o en cambios de valor. ˆ PWM: 3, 5, 6, 9, 10, y 11 Proporciona una salida PWM (Pulse Wave Modulation, modulaci´n de onda por pulsos) de 8 bits de resoluci´n (valores de 0 a 255) a trav´s o o e de la funci´n analogWrite(). o ˆ SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK) Estos pines proporcionan comunicaci´n SPI, que a pesar de que el hardware la proporcione actualmente no o esta incluido en el lenguaje Arduino. ˆ LED: 13 Hay un LED integrado en la placa conectado al pin digital 13, cuando este pin tiene un valor HIGH(5V) el LED se enciende y cuando este tiene un valor LOW(0V) este se apaga.Arduino Uno tiene 6 entradas anal´gicas, y cada una de ellas proporciona una resoluci´n de o o10bits (1024 valores). Por defecto se mide de tierra a 5 voltios, aunque es posible cambiarla cota superior de este rango usando el pin AREF y la funci´n analogReference(). o Adem´s algunos pines tienen funciones especializadas: a ˆ I2C: 4 (SDA) y 5 (SCL) Soporte del protocolo de comunicaciones I2C (TWI) usando la librer´ Wire. ıa Hay unos otros pines en la placa: ˆ AREF Voltaje de referencia para la entradas anal´gicas.Usado poranalogRefer- o ence(). ˆ Reset Suministrar un valor LOW(0V) para reiniciar el microcontrolador. T´ ıpica- mente usado para a˜adir un bot´n de reset a los shields que no dejan acceso a este n o bot´n en la placa. o
  • 158. 9.1. ARDUINO 1359.1.5 Comunicaciones Arduino Uno facilita en varios aspectos la comunicaci´n con el ordenador, otro Arduino ou otros microcontroladores. ATmega328 proporciona comunicaci´n v´ serie UART TTL o ıa(5V), disponible a trav´s de los pines digitales 0(RX) y 1(TX). Un chip FTDI FT232RL eintegrado en la placa canaliza esta comunicaci´n serie a traes del USB y los drivers FTDI o(incluidos en el software de Arduino) proporcionan un puerto serie virtual en el ordenador.El software incluye un monitor de puerto serie que permite enviar y recibir informaci´n otextual de la placa Arduino. Los LEDS RX y TX de la placa parpadearan cuando se detectecomunicaci´n transmitida trav´s del chip FTDI y la conexi´n USB (no parpadearan si se o e ousa la comunicaci´n serie a trav´s de los pines 0 y 1). o e La librer´ SoftwareSerial [55] permite comunicaci´n serie por cualquier par de pines ıa odigitales del Arduino Uno. ATmega328 tambi´n soporta la comunicaci´n I2C (TWI) y SPI . El software de Arduino e oincluye una librer´ Wire [56] para simplificar el uso el bus I2C. ıa9.1.6 Programaci´n o Arduino Uno se puede programar a trav´s del software Arduino [57]. Seleccionando e”Arduino Uno” del menu Tools > Board. El ATmega328 en las placas Arduino Uno vieneprecargado con un gestor de arranque (bootloader ) que permite cargar nuevo c´digo sin onecesidad de un programador por hardware externo. Se comunica utilizando el protocoloSTK500 original.9.1.7 Reinicio Autom´tico (Software) a En vez de necesitar reiniciar presionando f´ ısicamente el bot´n de reset antes de cargar, oArduino Uno esta dise˜ado de manera que es posible reiniciar por software desde el or- ndenador donde este conectado. Una de las lineas de control de flujo(DTR) del FT232RLesta conectada a la linea de reinicio del ATmega32 a trav´s de un condensador de 100 enanofaradios. Cuando la linea se pone a LOW(0V), la linea de reinicio tambi´n se pone a eLOW el tiempo suficiente para reiniciar el chip. El software de Arduino utiliza esta car-acter´ ıstica para permitir cargar los sketches (programas escritos para Arduino) con soloapretar un bot´n del entorno. Dado que el gestor de arranque tiene un lapso de tiempo opara ello, la activaci´n del DTR y la carga del sketch se coordinan perfectamente. o Esta configuraci´n tiene otras implicaciones. Cuando Arduino Uno se conecta a un oordenador con Mac OS X o Linux, esto reinicia la placa cada vez que se realiza unaconexi´n desde el software (v´ USB). El medio segundo aproximadamente posterior, el o ıagestor de arranque se esta ejecutando. A pesar de estar programado para ignorar datos malformateados intercepta los primeros bytes que se env´ a la placa justo despu´s de que se ıan eabra la conexi´n. Si un sketch ejecut´ndose en la placa recibe algun tipo de configuraci´n o a o
  • 159. 136 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINOinicial o otro tipo de informaci´n al inicio del programa, debemos asegurarnos de que el osoftware con el cual se comunica espera un segundo despu´s de abrir la conexi´n antes de e oenviar los datos. Arduino Uno contiene una pista que puede ser cortada para deshabilitar el auto-reset.Las terminaciones a cada lado pueden ser soldadas entre ellas para rehabilitarlo. Est´n aetiquetadas con ”RESET-EN”. Tambi´n podr´ deshabilitarse el auto-reset conectando una e aresistencia de 110 ohms desde el pin 5V al pin de reset.9.1.8 Protecci´n contra sobretensiones en USB o Arduino Uno tiene un multifusible reinicializable que protege la conexi´n USB de tu oordenador de cortocircuitos y sobretensiones. A aparte que la mayor´ de ordenadores ıaproporcionan su propia protecci´n interna, el fusible proporciona un capa extra de pro- otecci´n. Si mas de 500mA son detectados en el puerto USB, el fusible autom´ticamente o acorta la conexi´n hasta que el cortocircuito o la sobretensi´n desaparece. o o9.1.9 Caracter´ ısticas F´ ısicas La longitud y amplitud m´xima de la placa Arduino Uno es de 2.7 y 2.1 pulgadas arespectivamente, con el conector USB y la conexi´n de alimentaci´n sobresaliendo de o oestas dimensiones. Tres agujeros para fijaci´n con tornillos permiten colocar la placa en osuperficies y cajas. Ten en cuenta que la distancia entre los pines digitales 7 y 8 es 160mil (0,16”), no es m´ltiple de la separaci´n de 100 mil entre los otros pines. u o9.2 Configuraci´n Xbee para Arduino Uno o Como vimos en el Cap´ ıtulo 3, la tecnolog´ ZigBee/802.15.4 se presenta como una al- ıaternativa a las comunicaciones inal´mbricas de corto/medio alcance. Una implementaci´n a oconcreta est´ disponible en el mercado a trav´s de la empresa Digi [58] en su modelo XBee a eZNET 2.5 (tambi´n conocido como XBee PRO) 9.2. e Este m´dulo nos permitir´ realizar la comunicaci´n entre los diferentes Arduinos uti- o a olizando el env´ de datos como si de un puerto serie se tratase. As´ la definici´n de los ıo ı, opaquetes de datos y su gesti´n debemos hacerla nosotros. Los m´dulos XBee unicamente o o ´nos ofrecen el mecanismo de comunicaci´n, de una forma transparente, entre ellos. o No obstante, si bien para los Arduinos dicho proceso de comunicaci´n es transpar- oente, previamente deben configurarse los m´dulos XBee en funci´n de unos determinados o opar´metros y necesidades. a
  • 160. ´9.2. CONFIGURACION XBEE PARA ARDUINO UNO 137 Figure 9.2: XBee ZNET 2.59.2.1 Requisitos Cuando estudiamos un escenario de comunicaciones m´viles, como son los VANET, y onos aproximamos cuanto podamos al ´mbito urbano o interurbano real, nos encontramos aante un panorama que suele estar cacterizado por la aletoriedad y dinamismo del compor-tamiento de sus componentes. Es decir, un veh´ ıculo podr´ entrar en escena, tomar ciertas adecisiones impredecibles a lo largo de su tiempo de vida en dicho escenario, y desapareceral cabo de un tiempo no definido. Esta circunstancia hace que, en una topolog´ de comunicaci´n como la aqu´ descrita, ıa o ısea dif´ otorgar a un componente concreto, funciones de coordinaci´n de red, enrutado, ıcil oo control de seguridad. Ya vimos c´mo las topolog´ que impon´ la tecnolog´ ZigBee requer´ de un ele- o ıas ıa ıa ıanmento coordinador que llevara a cabo dichas funciones. Sin embargo, ante el requisito aqu´ mencionado (ning´n elemento, dada su volatilidad, ı udebe ser diferente al resto, esto es, coordinador) debemos encontrar una topolog´ que no ıarequiera dicho elemento coordinador. Gracias al modelo XBee ZNET 2.5, este tipo de arquitectura puede ser montada.9.2.2 Configuraci´n XBee XNET 2.5 - peer-to-peer o Como hemos comentado, antes de poder utilizar de forma transparente los m´dulos oXBee montados sobre nuestros Arduinos, tendremos que configurarlos para que todos secomporten como nodos finales de la red (sin un coordinador existente).
  • 161. 138 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINO As´ programaremos previamente cada m´dulo XBee ZNET 2.5, mediante un lector/e- ı, oscritor de m´dulos XBee (XBee explorator ) V´ase figura 9.3. o e Figure 9.3: XBee explorerPaso 1. Conexi´n del XBee al xplorer y preparaci´n del software o o En primer lugar, conectaremos el m´dulo XBee al m´dulo XBee explorer y lo conectare- o omos, v´ USB al equipo. Los dos LEDs del XBee debe encenderse y permanecer encendidos ıa(asumiendo que nuestro XBee est´ configurado como un dispositivo final/router y no existe aun Coordinador cercano). Descargamos el software X-CTU de Digi y lo instalaremos en nuestro equipo [60].Paso 2. Ejecutar X-CTU y conectar con XBee Ejecutaremos la aplicaci´n X-CTU. A continuaci´n nos aparecer´ una ventana como la o o aque podemos observar en la figura 9.4. Seleccionaremos el puerto COM en el que tenemosconectado nuestro m´dulo XBee explorer. Si no estamos seguros, podremos escanear cada ouno de los puertos f´cilmente seleccionando ”Test/Query”. a9.2.3 Actualizaci´n de firmware o Una vez que hayamos conectado correctamente con nuestro m´dulo XBee, el siguiente opaso ser´ grabar una configuraci´n de firmware que nos permita establecer nuestro m´dulo a o o
  • 162. ´9.2. CONFIGURACION XBEE PARA ARDUINO UNO 139 Figure 9.4: X-CTU Pantalla principalcomo un dispositivo final (ROUTER/END DEVICE AT. Siempre intentaremos actualizardicha versi´n de firmware a la ultima que nos ofrezca el proveedor. Para ello haciendo o ´clic en ”Modem Configuration” y a continuaci´n, en ”Download new versions...” nos ase- oguraremos de tener la ultima versi´n actualizada del firmware. ´ o El siguiente paso ser´ comprobar qu´ tipo y versi´n de firmware tiene nuestro XBee. a e oPara ello, haciendo clic en ”Read”, nos mostrar´ la versi´n del firmware grabada en nuestro a om´dulo junto con los valores concretos de configuraci´n asociados a ella. o o En este paso, es posible que nuestro m´dulo contenga justamente la versi´n de firmware o oque necesitamos. No obstante, para asegurarnos de que grabamos la versi´n correcta, oseleccionaremos, del listado disponible, ”ZNet 2.5 Router /End Device AT” (figura 9.5). El tipo de firmware seleccionado establece una serie de valores de configuraci´n al om´dulo XBee que le otorgan el car´cter de router /dispositivo final de forma autom´tica. o a a Sin embargo, hay ciertos valores que tendremos que establecer manualmente para con-seguir la topolog´ peer-to-peer que mencionamos anteriormente, esto es, sin un dispositivo ıa
  • 163. 140 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINO Figure 9.5: X-CTU Pantalla selecci´n de firmware ocoordinador. As´ seleccionando el par´metro ”NI - node identifier”, configuraremos un nombre con- ı, acreto para cada uno de nuestros XBee (algo as´ como ”node01”). ı Otro de los par´metros que podr´ a ıamos configurar ser´ el ”PAN ID”, que permite dis- ıatinguir o evitar que m´dulos XBee ajenos a nuestra red entren en la misma. En cualquier ocaso, todos nuestros m´dulos que entren a formar parte de la red, deben llevar el mismo o”PAN ID”. De la misma forma, el par´metro ”Channel ID” tambi´n debe ser el mismo para todos a elos m´dulos de nuestra red. o El siguiente par de par´metros ser´n cr´ a a ıticos a la hora de dotar a la topolog´ de red ıaXBee el car´cter peer-to-peer buscado. Se trata de los valores de la direcci´n de difusi´n a o o(broadcast), ”DH” y ”DL” que deben adquirir los siguientes valores: ”DH” = 0x00000000 y”DL” = 0x0000FFFF.
  • 164. 9.3. GPS 1419.2.4 Probando comunicaci´n entre los m´dulos XBee o o Para asegurarnos de la correcta configuraci´n de los m´dulos XBee, podemos realizar o ouna sencilla prueba en la que, mediante uno de los m´dulox XBee conectados a la placa de oexploraci´n y, a su vez, a un equipo, mantener dicho m´dulo a la escucha monitorizando o osu puerto serie. Por otro lado, utilizando el otro par XBee instalado sobre un Arduino, crearemos unsketch que realizar´ un polling de env´ a trav´s del puerto serie con una cadena de texto a ıo eindicando dicho proceso de prueba:#define ledPin 13byte pinState = 0;void setup() { pinMode(ledPin, OUTPUT); Serial.begin(9600);}void loop() { Serial.println("testing..."); // toggle an LED just so you see the thing’s alive. toggle(13); delay(1000);}void toggle(int pinNum) { // set the LED pin using the pinState variable: digitalWrite(pinNum, pinState); // if pinState = 0, set it to 1, and vice versa: pinState = !pinState;}9.3 GPS Una vez tenemos listos nuestros m´dulos XBee para ser instalados en las placas Ar- oduino, con capacidad de comunicaci´n entre ellos, el siguiente paso ser´ el desarrollo del o aalgoritmo de comunicaci´n de alertas que estudiamos en cap´ o ıtulos anteriores. No obstante,terminaremos de configurar la parte relativa al hardware centr´ndonos en el ultimo aspecto a ´necesario para la realizaci´n de un sistema b´sico de alertas, esto es, la geolocalizaci´n. o a o As´ cada Arduino, aparte de disponer de un m´dulo de comunicaci´n inal´mbrica, ı, o o adebe ser capaz de conecer su posici´n geogr´fica, para poder estimar la distancia a la que o ase est´n emitiendo posibles alertas de terceros. a Para ello, utilizaremos m´dulos GPS EM-406A SiRF III [61], compactos, precisos y of´ciles de instalar en nuestra placa Arduino a El modelo EM-406A SiRF III est´ basado en el chipset SiRF StarIII. Basado en un amodelo predecesor, incluye novedades como regulaci´n de voltaje integrada, indicador LED ode estado, memoria RAM de respaldo y antena GPS integrada, montado sobre una placacon interfaz cableada de 6 pines.
  • 165. 142 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINO Figure 9.6: GPS EM-406A SiRF III Las caracter´ ısticas t´cnicas son las siguientes: e ˆ Receptor de 20 canales ˆ Alta sensibilidad: -159dBm ˆ Precisi´n 10m / 5m con WAAS o ˆ Hot Start: 1s ˆ Warm Start: 38s ˆ Cold Start: 42s ˆ consumo 70mA a 4.5-6.5V ˆ Protocolo de comunicaci´n NMEA 0183 y SiRF binario o ˆ Comunicaci´n serie TTL o9.3.1 Instalaci´n o Dado que nuestro m´dulo de comunicaci´n inal´mbrica XBee es montado directamente o o aa la placa Arduino a trav´s de un dockshield y que ocupar´ el puerto serie, debemos montar e ael m´dulo GPS de tal manera que no entre en conflicto con el m´dulo XBee. o o
  • 166. 9.3. GPS 143 Arduino permite, a trav´s de una librer´ virtualizar un puerto serie en cualquiera de e ıa,los pines digitales restantes disponibles. El proceso de configuraci´n es sencillo, unica- o ´mente debemos descargar la librer´ ”SoftwareSerial” (en las ultimas versiones de Arduino ıa ´Software viene por defecto en el framework [55]), incluirla en nuestro sketch y configurarlos pines que ser´n utilizados como ”rx” y ”tx” en la comunicaci´n serie, as´ como configurar a o ıposibles par´metros como la velocidad de transmisi´n. a o As´ el esquema de conexi´n que montaremos ser´ el que podemos observar en la figura ı, o a9.7. Figure 9.7: Esquema de instalaci´n GPS en Arduino o Bajo este esquema de instalaci´n, y recordando, de nuevo, que el puerto serie f´ o ısicoestar´ ocupado por el m´dulo XBee, emplearemos la ya mencionada librer´ ”Softserial”. a o ıaAs´ dado que hemos instalado la conexi´n serie del m´dulo GPS en los pines 2 y 3 para rx ı, o oy tx respectivamente, la configuraci´n inicial de dichos pines, para hacer efectivo el canal ode comunicaci´n, junto con la configuraci´n de los pines de alimentaci´n 4 (ground ) y 5 o o o(+V) respectivamente. Por otro lado, el m´dulo GPS debe ser configurado al inicio, en relaci´n al tipo de o oprotocolo elegido a utilizar para la comunicaci´n de datos, activaci´n de checksum, . . . o o As´ nuestra configuraci´n queda como sigue: ı, oSoftwareSerial mySerial(2, 3);int Vgps = 5;int Ggps = 4;mySerial.begin(4800); //Activamos GPS pinMode(Vgps, OUTPUT); pinMode(Ggps, OUTPUT); digitalWrite(Vgps,HIGH); digitalWrite(Ggps,LOW);
  • 167. 144 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINO delay(1000); Tras esta configuraci´n, el GPS estar´ enviando informaci´n cont´ o a o ınua sobre la posici´n ogeogr´fica en la que se encuentra Arduino con una frecuencia de 1 mensaje por segundo. aDicho mensaje cumplir´ con el formato que establece el protocolo NMEA [62] a As´ un ejemplo de este tipo de mensajes es el siguiente: ı,$ GPGGA, 123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M *47 Donde tenemos los siguientes par´metros: a ˆ GGA Global Position System Fix Data ˆ 123519 Posici´n tomada a las 12:35:19 UTC o ˆ 4807.038,N Latitud 48 grados 07.038’ N ˆ 01131.000,E Longitud 11 grados 31.000’ E ˆ 1 Calidad de la posici´n (0 = invalid, 1 = GPS fix (SPS), 2 = DGPS fix, 3 = PPS fix, o 4 = Real Time Kinematic, 5 = Float RTK, 6 = estimaci´n , 7 = Modo de entrada o manual, 8 = Modo simulado) ˆ 08 Numero de sat´lites activos e ˆ 0.9 Diluci´n horizontal de la posici´n o o ˆ 545.4,M Altitud, en metros, sobre el nivel del mar ˆ 46.9,M Altura de geoide sobre el elipsoide - WGS84 ˆ (campo vac´ tiempo, en segundos, desde la ultima actualizaci´n DGPS ıo) ´ o ˆ (campo vac´ n´mero ID de la estaci´n DGPS ıo) u o ˆ *47 checksum, siempre comienza con asterisco Este mensaje despu´s deber´ ser tratado en nuestro sketch para extraer las coordenadas e ageogr´ficas, marca temporal y posibles valores que necesitemos para aportar informaci´n a osuficiente para el correcto funcionamiento del programa principal.9.4 Sistema de alertas en carretera - APAL - b´sico a Llegados a este punto, y como objetivo final de este proyecto de final de carrera, re-alizaremos una aproximaci´n hacia una soluci´n b´sica de Sistema de Alertas en Carretera, o o abasado en el algoritmo de control de broadcast storming APAL, adaptado, e implementadoen el microcontrolador Open Hardware - Open Software Arduino.
  • 168. ´9.4. SISTEMA DE ALERTAS EN CARRETERA - APAL - BASICO 145 Si bien el objetivo inicial del proyecto pasaba por un sistema funcional completo, difer-entes limitaciones han hecho necesiario diferentes adaptaciones que se reflejan, tanto enlimitaciones funcionales (forma de presentaci´n de las alertas, tipo de alertas y datos a oregistrar, ...) como limitaciones relativas a la capacidad de c´mputo y eficiencia del mismo o(n´mero de alertas a procesar en paralelo, precisi´n y filtrado de alertas, ...). u o No obstante, dada la evoluci´n y mejora constante que sufren las plataformas de mi- ocrocontrol como Arduino, es interesante seguir prestando atenci´n a las posibles soluciones oque podamos desarrollar de cara a mejorar este tipo de sistemas, y quiz´ podamos contar, aen un tiempo relativamente corto, de dispositivos con mayor capacidad que nos permitanmejorar dichas soluciones y solventar las limitaciones comentadas. Figure 9.8: SACAR simplificado De esta forma, y como prototipo simplificado del sistema SACAR, podemos observaren la figura 9.8 el montaje realizado sobre el par de plataformas f´ ısicas Arduino. As´ se presenta un par de dispositivos Arduino (A y B) donde, ambos comparten la ı,misma implementaci´n del sistema APAL adaptado con ligeras variantes. o El dispositivo A realizar´ las funciones de veh´ a ıculo especial, en este caso, veh´ ıculo deemergencia, que debe informar al resto de veh´ ıculos sobre su posici´n y tipo de alerta que oest´ emitiendo. Si bien este veh´ a ıculo deber´ de moverse en una situaci´n real, nosotros ıa onos limitaremos a fijar su posici´n de forma manual en un par de coordenadas geogr´ficas. o a Por su parte, el dispositivo B cuenta con un m´dulo GPS que le permite conocer su oposici´n y, por tanto, podr´ determinar a qu´ distancia se encuentra de ´l el veh´ o a e e ıculo deemergencias A.
  • 169. 146 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINO De esta forma, el par de dispositivos establece una comunicaci´n inal´mbrica, haciendo o auso del algoritmo adaptado APAL para redifusi´n y control de broadcast storming, y donde oel veh´ ıculo B podr´ estar informado de las alertas que env´ el dispositivo A. a ıe9.4.1 Algoritmo APAL adaptado Como hab´ ıamos se˜alado anteriormente, el algoritmo APAL debe ser adaptado a las nrestricciones que impone la plataforma Arduino. Dichas adaptaciones tienen que ver con limitaciones de capacidad y procesamiento. As´ cuando en un equipo de computaci´n potente, como puede ser un PC, disponemos ı, ode capacidades de procesamiento en paralelo, en un sistema embebido como es el micro-controlador Arduino, dicha capacidad se pierde, y la ejecuci´n secuencial se vuelve nuestra ounica alternativa.´ De esta forma, un hecho tan insignificante como podr´ ser el mantenerse a la escucha, ıaen un fragmento de tiempo determinado, de los mensajes que el dispositivo pueda recibir,y procesarlos en ese mismo per´ ıodo de tiempo, se vuelve un problema a resolver y, en ciertomodo, a adaptarse a ´l. e Por ello, una de las caracter´ ısticas que determina nuestro algoritmo adaptado APALser´ la incapacidad de procesar mensajes de diferente procedencia, centr´ndose unica- a a ´mente, en la escucha de aquellos que haya podido identificar previamente y, en ese per´ ıodode procesamiento, ser´ necesario realizar ”microciclos” de procesamiento que no bloqueen ala recepci´n de los mismos. o Podr´ ıamos pensar, entonces, en un algoritmo APAL que no se ejecuta como un unico´bloque capaz de instanciarse as´ mismo para procesar toda la informaci´n y estar a la ı oescucha de los mensajes que lleguen de los diferentes veh´ ıculos. Por contra, el algoritmoest´ muy modularizado, y realiza peque˜as pasadas que engloban todos los peque˜os a n nm´dulos, para evitar que diferentes funciones bloqueen a las dem´s. o a A continuaci´n, en la figura 9.9 se muestra el diagrama de flujo simplificado de nuestro oalgoritmo integrado en los m´dulos Arduino. o//Incluimos librer´a donde se define el formato de nuestro paquete de datos ı#include "packet.h"//Incluimos librer´a para usar GPS en softserial ı#include <SoftwareSerial.h>#include <stdio.h>int firstSensor = 0; // first analog sensorint secondSensor = 0; // second analog sensorint thirdSensor = 0; // digital sensorint inByte = 0; // incoming serial byte//Vars APALdouble countTime = 0;
  • 170. ´9.4. SISTEMA DE ALERTAS EN CARRETERA - APAL - BASICO 147 Figure 9.9: APAL - SACAR adaptadoint duplicateNumber = 0;int counterDuplicateNumber = 0;double delta; //random 1 - 100;double pi; //random 0.7 - 0.9long int beta = 3 * 1000;int sigma = 5;long int APALtimer = 0;boolean inProcess = false;//13r200406A8A16|173854.467|40.5110258562|-3.3503258228|3;packet mipaquete = {5,{"13A200406A8A16","173854.467","40.5110258562","-3.3503258228","3" }};packet resetPacket = {5,{}};packet temporalAlert = resetPacket;packet outter = {5,{"99","99","99","99","99"}};//Control temporallong int controlClock;char commandbuffer[50];char gpsBuffer[150];int indexBuffer;int gpsIndexBuffer;//------------ Variables para lectura de GPS ---------------------------SoftwareSerial mySerial(2, 3);int Vgps = 5;int Ggps = 4;// GPS parser para SRIF STAR III 406a#define BUFFSIZ 90char buffer[BUFFSIZ];char *parseptr;
  • 171. 148 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINOchar buffidx;int latitude dd, longitude dd;double latitude, latitude aux, longitude, longitude aux,altitude;char latdir, longdir;char status;String serialize(packet p paquete){ String aux; for(int i = 0; i<(p paquete.length-1); i++){ aux += p paquete.data[i] + "|"; } aux += p paquete.data[p paquete.length-1] + ";"; return aux;}void broadcastAlert(packet p packet, boolean p force){ String aux2; if(((controlClock + 1000) < millis())|| p force){ aux2 = serialize(p packet); Serial.println( aux2 ); controlClock = millis(); }}packet parsePackets(String p packet){ String aux1 ,aux2 = "" ; int auxi = 0; aux2.concat(p packet); packet auxPacket; auxPacket.length = 5; for(auxi=0; auxi < 4; auxi++){ aux1 = aux2.substring(0,aux2.indexOf(’|’)); auxPacket.data[auxi] = aux1; aux1 = aux2.substring(aux2.indexOf(’|’)+1,aux2.length()); aux2 = aux1; } aux1 = aux2.substring(0,aux2.indexOf(’;’)); auxPacket.data[4] = aux1; return auxPacket;}boolean exist(packet p outter){ if((temporalAlert.data[0]==p outter.data[0])&&(temporalAlert.data[1] == p outter.data [1])){ return true; }else{ return false; }}boolean receivePacket(){ while(Serial.available()){ commandbuffer[indexBuffer] = (char) Serial.read(); if(commandbuffer[indexBuffer] == ’;’){ commandbuffer[indexBuffer] = ’0’; outter = parsePackets(commandbuffer); indexBuffer = 0; Serial.println(outter.data[0]); return true; }else{ indexBuffer++; }
  • 172. ´9.4. SISTEMA DE ALERTAS EN CARRETERA - APAL - BASICO 149 }}void APAL(){ long int currentTimer = millis(); boolean incomingPacket = false; boolean existPacket = false; boolean auxpi = 0; receiveGPSPacket(); incomingPacket = receivePacket(); existPacket = exist(outter); if(incomingPacket){ processAlert(outter); } if(incomingPacket && !existPacket){ delta = random(100, 10001); delta /=100; pi = random(70, 91); pi /= 100; countTime = 0; APALtimer = currentTimer + delta; temporalAlert = outter; duplicateNumber = 0; inProcess = true; }else{ if(inProcess){ if((countTime < beta) && (duplicateNumber < sigma)){ if((APALtimer > currentTimer)&&(incomingPacket)&&(existPacket)){ counterDuplicateNumber++; } if((APALtimer < currentTimer)){//Cuando expire delta if(counterDuplicateNumber > 0){ duplicateNumber = duplicateNumber + counterDuplicateNumber; pi = pi/duplicateNumber; delta = delta * duplicateNumber; }else{ auxpi = random(70, 91); auxpi /= 100; if(auxpi <= pi){ broadcastAlert(outter,true);//Rebroadcast con probbilidad pi } } APALtimer = currentTimer + delta; countTime = countTime + delta; counterDuplicateNumber = 0; } }else{ temporalAlert = resetPacket; inProcess = false; } } }}void processAlert(packet p packet){ Serial.println("Alerta recibida"); Serial.print("Distancia a emisor: "); Serial.print(distanciaGeodesica(p packet.data[2].toFloat(),p packet.data[3].toFloat() ,40.512918237259,-3.347471952438)); Serial.println(" metros"); Serial.print("Tipo de alerta: "); switch(p packet.data[4].toInt()){ case 1: Serial.println("Veh´culo de emergencia"); ı case 2: Serial.print("Accidente");
  • 173. 150 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINO case 3: Serial.print("Retenciones"); }}double distanciaGeodesica(double lat1, double long1, double lat2, double long2){ double degtorad = 0.01745329; double radtodeg = 57.29577951; double dlong, dvalue, dd, m; dlong = (long1 - long2); dvalue = (sin(lat1 * degtorad) * sin(lat2 * degtorad)) + (cos(lat1 * degtorad) * cos(lat2 * degtorad) * cos(dlong * degtorad)); dd = acos(dvalue) * radtodeg; m = (dd * 111.302 * 1000)/2; return m;}//Funcion para lectura de latitudedouble read lat(char in string[90], char *pointer){ // check if $GPRMC (global positioning fixed data) int latitude dd; double latitude aux, latitude; char latdir; if (strncmp(in string, "$GPGGA",6) == 0) { //Posicionamos detr´s de la cadena $GPGGA, y saltamos la hora a pointer = in string+7; pointer = strchr(pointer, ’,’) + 1; status = pointer[0]; // Captura de latitude y longitude // Extraemos valor de latitude latitude aux = parsedecimal(pointer); latitude dd = latitude aux; latitude dd /= 100; latitude = latitude dd + ((latitude aux - (latitude dd * 100)) / 60); //Leemos referencia norte o sur pointer = strchr(pointer, ’,’) + 1; // read latitude N/S data if (pointer[0] != ’,’) { latdir = pointer[0]; } if (latdir == ’S’) latitude *= -1; return latitude; }}double read longitude(char in string[90], char *pointer){ int longitude dd; double longitude aux, longitude; char longdir; // Extraemos valor de longitude if (strncmp(in string, "$GPGGA",6) == 0) { //Posicionamos detr´s de la cadena $GPGGA, y saltamos la hora a pointer = in string+7; //Saltamos latitude pointer = strchr(pointer, ’,’) + 1;
  • 174. ´9.4. SISTEMA DE ALERTAS EN CARRETERA - APAL - BASICO 151 status = pointer[0]; pointer = strchr(pointer, ’,’) + 1; if (pointer[0] != ’,’) { latdir = pointer[0]; } //Leemos longitude pointer = strchr(pointer, ’,’)+1; longitude aux = parsedecimal(pointer); longitude dd = longitude aux; longitude dd /= 100; longitude = longitude dd + ((longitude aux - (longitude dd * 100)) / 60); //Leemos referencia este u oeste pointer = strchr(pointer, ’,’)+1; // read longitude E/W data if (pointer[0] != ’,’) { longdir = pointer[0]; } //Saltamos los campos position fix, satellites used, y HDOP pointer = strchr(pointer, ’,’)+1; pointer = strchr(pointer, ’,’)+1; pointer = strchr(pointer, ’,’)+1; //Leemos altura en metros parseptr = strchr(pointer, ’,’)+1; altitude = parsedecimal(pointer); if (longdir == ’W’)longitude *= -1; return longitude; } } void receiveGPSPacket(){ packet alertOut; while(mySerial.available()){ gpsBuffer[gpsIndexBuffer] = (char) mySerial.read(); if(gpsBuffer[gpsIndexBuffer] == ’r’){ gpsBuffer[gpsIndexBuffer] = ’0’; //outter = parsePackets(commandbuffer); gpsIndexBuffer = 0; Serial.print("13r200406A8A16|"); Serial.print(millis()); Serial.print("|"); Serial.print(read lat(gpsBuffer,parseptr),4); Serial.print("|"); Serial.print(read longitude(gpsBuffer,parseptr),4); Serial.println("|3;"); //Serial.println(outter.data[0]); }else{ gpsIndexBuffer++; } } }//------------------------------------------------------void setup(){ // start serial port at 9600 bps:
  • 175. 152 ´ CHAPTER 9. IMPLEMENTACION EN ARDUINO Serial.begin(19200); mySerial.begin(4800); //Activamos GPS pinMode(Vgps, OUTPUT); pinMode(Ggps, OUTPUT); digitalWrite(Vgps,HIGH); digitalWrite(Ggps,LOW); delay(1000); //Imprimimos titulo Serial.println("GPS parser"); //Configuramos GPS mySerial.println("$PSRF103,01,00,00,01*25"); mySerial.println("$PSRF103,02,00,00,01*26"); mySerial.println("$PSRF103,03,00,00,01*27"); mySerial.println("$PSRF103,04,00,00,01*20"); mySerial.println("$PSRF103,04,00,00,01*21"); controlClock = millis(); Serial.println();}void loop(){ APAL();}//----------------- Funciones para lectura y parseo de GPS -----------------------double parsedecimal(char *str) { double d = 0;char aux str[BUFFSIZ]; int i = 0; while (str[0] != 0) { if (((str[0] > ’9’) || (str[0] < ’0’))&&(str[0]!=’.’)){ aux str[i]=’0’; return atof(aux str); } aux str[i]=str[0]; str++; i++; } return atof(aux str);}void readline(void) { char c; buffidx = 0; while (1) { c=mySerial.read(); if (c == -1) continue; //Serial.print(c); if (c == ’n’) continue; if ((buffidx == BUFFSIZ-1) || (c == ’r’)) { buffer[buffidx] = 0; return; } buffer[buffidx++]= c; }}
  • 176. Chapter 10CONCLUSIONES Una vez presentada la problem´tica existente, esto es, la falta de intercomunicaci´n a oentre veh´ıculos, se llev´ a cabo un proceso de investigaci´n de la situaci´n actual y las o o oalternativas que pod´ ıamos tomar para corregir la deficiencia se˜alada. As´ en nuestro n ı,caso, optamos por presentar un sistema de comunicaci´n entre veh´ o ıculos (tecnolog´ in- ıaal´mbrica ”vehicle to vehicle’)’ basado en el protocolo 802.15.4, comunmente conocida acomo tecnolog´ inal´mbrica zigBee. Tras acercarnos al tipo de tecnolog´ que usar´ ıa a ıa ıamosen nuestro sistema de alertas, y previo al desarrollo del mismo, continuamos en el procesode investigaci´n desplegando y adaptando una serie de herramientas de simulaci´n que nos o opermitieran llevar a cabo aproximaciones de algoritmos de distribuci´n de la informaci´n o osobre el protocolo zigBee en diferentes entornos que pusieran de manifiesto el porqu´ de su eempleo en el sistema f´ ısico que finalmente desarrollar´ ıamos. Para poder realizar ese tipode argumentaciones se realizaron una serie de tomas de datos para facilitar la compren-si´n y la elecci´n de uno u otro algoritmo. As´ se estudiaron situaciones y escenarios en o o ı,los cuales el algoritmo aplicado APAL (Adaptive Probability Alert Protocol ) favorec´ la ıadifusi´n de mensajes evitando el colapso del sistema por problemas asociados al broadcast o(broadcast storming). En una segunda fase, y en base a las conclusiones obtenidas en la primera parte delproyecto, llevamos a cabo un desarrollo ligero del sistema de alertas utilizando la tec-nolog´ seleccionada, esto es, difusi´n de alertas mediante el empleo de tecnolog´ inal´m- ıa o ıa abrica 802.15.4 y l´gica de gesti´n con el uso del algoritmo APAL, todo ello montado sobre o osistemas embebidos, de bajo coste, famosos por su alta flexibilidad tanto en tecnolog´ so- ıasportadas como en flexibilidad en desarrollo de l´gica de control, esto es microcontroladores oAtmega en su versi´n comercial m´s famosa, la serie Arduino. o a Prestando atenci´n al camino recorrido en el desarrollo de este proyecto, poniendo la omirada en los objetivos que se presentaron al inicio y observando el punto alcanzado al finaldel mismo, podemos concluir que hemos realizado el viaje siguiendo muy de cerca la l´ ıneaque marcamos. No obstante se ha puesto de manifiesto que en la elaboraci´n de cualquier oproyecto aparecer´n terceros elementos que nos obliguen a tomar decisiones, problemas ano esperados que pongan a prueba nuestra capacidad de adaptaci´n y resoluci´n, y lo o om´s importante de todo, aprender de cada una de esas situaciones que a fin de cuenta se a 153
  • 177. 154 CHAPTER 10. CONCLUSIONEStraducen en experiencia y conocimiento.
  • 178. Chapter 11TRABAJO FUTURO A partir de este punto, tomando como referencia un sistema de alertas en carreterabasado en la tecnolog´ inal´mbrica ZigBee - xBee sobre plataformas de desarrollo Arduino, ıa alas opciones de desarrollo son muy amplias. Por un lado, tenemos en cuenta que existen multitud de plataformas de desarrollosimilares a Arduino, en cuanto a funcionalidad, potencia, o coste. As´ si contar con dis- ı,positivos hardware m´s potentes, como pueden ser los nuevos Raspberry, cuya potencia ase asemeja a un equipo personal pero con caracter´ ısticas de programaci´n openSource e ointerfaces de comunicaci´n similares a los de Arduino, hacen interesante enfocar la evolu- oci´n del sistema hacia protocolos de paso de mensajes m´s seguros, m´s eficaces, donde o a ase puedan aplicar procesos de c´lculo relacionados con la geograf´ en la cual se mueve un a ıaveh´ıculo para distinguir situaciones que le afecten o no a ´l directamente. e Podr´ adem´s, incluirse elementos externos que se conecten a internet, y mantengan ıa auna cobertura m´s amplia y capaz de ofrecer datos que puedan vivir en la nube aumentando ael potencial de este tipo de sistemas. Como vemos, las capacidades son infinitas. 155
  • 179. 156 CHAPTER 11. TRABAJO FUTURO
  • 180. Bibliography [1] Cuatro siglos en cuatro ruedas. Emiliano Cernuschi. Montevideo. 2005. [2] Modelos de proyeccion del parque vehicular. Romulo A. Chumacero, Jorge A. Quiroz, Avance, Santiago 2007. [3] Tingvall, C. et al (2003) The effectiveness of ESP (Electronic Stability Program) in reducing real-life accidents. ESV Paper 261, 18th ESV Conference, Nagoya , 2003. [4] Architecture of the Dedicated Short-Range Communications (DSRC) Protocol. Chris- tian Cseh. Department of Computer Science, Informatik IV Aachen University of Technology (RWTH), Germany. [5] Arduino http://www.arduino.cc/es/ [6] Plan de desarrollo urbano de Manhattan, 1811. Gouverneur Morris, John Ruther- furd y Simeon De Witt. http://en.wikipedia.org/wiki/Commissioners’_Plan_ of_1811 [7] Distancia Manhattan. http://es.wikipedia.org/wiki/Geometr%C3%ADa_taxicab [8] NETCONVERT. http://sourceforge.net/apps/mediawiki/sumo/index.php? title=NETCONVERT [9] MOVE. http://lens.csie.ncku.edu.tw/Joomla_version/index.php/ research-projects/past/18-rapid-vanet[10] JTRROUTER.http://sourceforge.net/apps/mediawiki/sumo/index.php? title=JTRROUTER[11] Openstreetmap. http://www.openstreetmap.org/[12] Wikipedia. http://es.wikipedia.org/wiki/Wikipedia:Portada[13] IEEE 802.11: WIRELESS LOCAL AREA NETWORKS (LANs)http://standards. ieee.org/getieee802/download/802.11-2007.pdf[14] IEEE 802.11n: WIRELESS LOCAL AREA NETWORKS http://standards.ieee. org/getieee802/download/802.11n-2009.pdf[15] IEEE Computer Society, ”Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs)” Septiembre, 2006. http://standards.ieee.org/getieee802/download/ 802.15.4-2006.pdf 157
  • 181. 158 BIBLIOGRAPHY[16] ZigBee Alliance, ”ZigBee Specification”, Enero, 2008.[17] Pol´ ıgonos de Thiessen. http://es.wikipedia.org/wiki/Pol%C3%ADgonos_de_ Thiessen[18] McTrans. Traffic Software Integrated System-Corridor Simulation (TSIS-CORSIM). Center for Microcomputers in Transportation (McTrans), 2011. http://mctrans.ce. ufl.edu/featured/tsis/[19] Quadstone Paramics, 2011. http://www.paramicsonline.com/[20] Capra L, Emmerich W, Mascolo C. Carisma: context-aware reflective middleware system for mobile applications. IEEE Transactions on Software Engineering 2003; 29: 929-945.[21] VISSIM, 2012. http://www.vissim.com/[22] Scalable Network Technologies. Qualnet. Scalable Network Technologies, Inc., 2006.[23] OPNET Technologies, 2011. http://www.opnet.com/[24] Krajzewicz D, Rossel C. Simulation of Urban MObility (SUMO). German Aerospace Centre, 2011. http://sumo.sourceforge.net/index.shtml[25] MOVE (MObility model generator for VEhicular networks): Rapid Generation of Realistic Simulation for VANET, 2011. http://lens.csie.ncku.edu.tw/Joomla_ version/index.php/research-projects/past/18-rapid-vanet[26] Martinez FJ, Cano JC, Calafate CT, Manzoni P. Citymob: a mobility model pattern generator for VANETs. In IEEE Vehicular Networks and Applications Workshop (Vehi-Mobi, held with ICC), Beijing, China, May 2008.[27] STRAW - STreet RAndom Waypoint - vehiclar mobility model for network sim- ulations (e.g., car networks), 2012. http://www.aqualab.cs.northwestern.edu/ projects/STRAW/index.php[28] FreeSim, 2011. http://www.freewaysimulator.com/[29] Mori H, Kitaoka H, Teramoto E. Traffic simulation for predicting traffic situations at expo 2005. RD Review of Toyota CRDL 2006; 41(4): 45-51.[30] Haerri J, Fiore M, Fethi F, Bonnet C. VanetMobiSim: generating realistic mobility patterns for VANETs. Institut Eur´com and Politecnico Di Torino, 2011. http:// e vanet.eurecom.fr/[31] Fall K, Varadhan K. ns notes and documents. The VINT Project, UC Berkeley, LBL, USC/ISI, and Xerox PARC, February 2000.[32] Martin J. GloMoSim. Global mobile information systems simulation library. UCLA Parallel Computing Laboratory, 2011. http://pcl.cs.ucla.edu/projects/ glomosim/[33] Walsh K, Sirer EG. A staged network simulator (SNS). Computer Science Depart- ment, Cornell University, 2011. http://www.cs.cornell.edu/people/egs/sns/[34] JiST/SWANS: Java in Simulation Time/Scalable Wireless Ad hoc Network Simulator, 2011. http://jist.ece.cornell.edu/[35] The Georgia Tech Network Simulator (GTNetS), 2011. http://www.ece.gatech. edu/research/labs/MANIACS/GTNetS/
  • 182. BIBLIOGRAPHY 159[36] Piorkowski M, Raya M, Lugo AL, Papadimitratos P, Grossglauser M, Hubaux J-P. TraNS (Traffic and Network Simulation Environment). Ecole Polytechnique F´d´rale e e de Lausanne, EPFL, Switzerland, 2011. http://trans.epfl.ch/[37] NCTUns 5.0, 2011. http://nsl10.csie.nctu.edu.tw/[38] Mangharam R, Weller D, Rajkumar R, Mudalige P, Bai F. GrooveNet: A Hybrid Simulator for Vehicle-to-Vehicle Networks. Carnegie Mellon University, 2006.[39] MobiREAL, 2011. http://www.mobireal.net/[40] Choffnes DR, Bustamante FE. Modelling vehicular traffic and mobility for vehicular wireless networks. Technichal Report, Department of Computer Science, Northwest- ern University, NWU-CS-05-03, July 2005.[41] Nagel K, Schleicher A. Microscopic traffic modeling on parallel high performance computers. Parallel Computing 1994; 20: 125-146.[42] Krauss S. Microscopic modeling of traffic flow: investigation of collision free vehicle dynamics. Ph.D. Dissertation, 1998.[43] Treiber M, Hennecke A, Helbing D. Congested traffic states in empirical observations and microscopic simulations. Physical Review E 2000; 62: 1805.[44] Fiore M, Haerri J, Filali F, Bonnet C. Vehicular mobility simulation for VANETS. In Proceedings of the 40th Annual Simulation Symposium (ANSS 2007), Norfolk, Virginia, March 2007.[45] Car-to-car cooperation for vehicular ad-hoc networks. An AquaLab Project, 2002. http://www.aqualab.cs.northwestern.edu/projects/C3.html[46] Chen Q, Schmidt-Eisenlohr F, Jiang D, Torrent-Moreno M, Delgrossi L, Hartenstein H. Overhaul of ieee 802.11 modeling and simulation in ns-2. In MSWiM07: Proceed- ings of the 10th ACM Symposium on Modeling, Analysis, and Simulation of Wireless and Mobile Systems. ACM: New York, NY, USA, 2007; 159-168.[47] UCLA Parallel Computing Laboratory. Parsec: Parallel Simulation Environment for Complex Systems, 2008. http://pcl.cs.ucla.edu/projects/parsec/[48] Walsh K, Sirer EG. Staged simulation: A general technique for improving simulation scale and performance. ACM Transactions on Modeling and Computer Simulation 2004; 14(2): 170-195.[49] OMNeT++, extensible, modular, component-based C++ simulation library and framework. 2011. http://www.omnetpp.org/[50] Comunicaciones Privadas en Redes Ad-hoc Vehiculares. Alexandre Viejo, Francesc Seb´, Josep Domingo-Ferrer, Jes´s Manj´n. Universitat Rovira i Virgili. http:// e u o crises2-deim.urv.cat/docs/publications/conferences/577.pdf[51] Intrusion detection in wireless ad-hoc networks. Y. Zhang, W. Lee.2000.[52] Intrusion detection using mobile agents in wireless ad-hoc networks, IEEE WorkShop. Kachiriski, R. Guha. 2002.[53] Composite Key Management for Ad-hoc Networks. Seung Yi, Robin Kravets. Dept of Computer Science, University of Illinois, 2004[54] Arduino http://arduino.cc/es
  • 183. 160 BIBLIOGRAPHY[55] Librer´ SoftSerial http://www.arduino.cc/en/Reference/SoftwareSerial ıa[56] Librer´ Wire http://arduino.cc/es/Reference/Wire ıa[57] Arduino Software http://arduino.cc/es/Main/Software[58] Digi International Inc. http://www.digi.com[59] Prix Ars Electronica. 2006 http://www.aec.at/en/prix/honorary2006.asp[60] X-CTU software from Digi. http://www.digi.com/support/productdetail?pid= 3261&osvid=57&type=cabling[61] EM-406A SiRF III GPS Module http://www.sparkfun.com/products/465[62] NMEA Protocol http://www.nmea.org/content/nmea_standards/nmea_083_v_ 400.asp[63] APAL An Adaptative Alert Message Dissemination Protocol for VANET Im- prove Road Safety. Kanistorn Suriyapaiboonwattana, Chotipat Pornavalai, Goutam Chakraborty.[64] Simple Obstacle Model for the OMNeT++ INET Framework and MiXiM http:// veins.car2x.org/documentation/modules/obstacles/