Centro de Investigacion y de Estudios Avanzados del Instituto Politecnico Nacional

Unidad Zacatenco Departamento de Computacin o

Mecanismo seguro de recoleccin de datos utilizando o nodos mviles en redes inalmbricas de sensores o a

Tesis que presenta Ivn Cabrera Altamirano a para obtener el grado de Maestro en Ciencias en Computacin o

Director de la tesis Dr. Francisco Rodr guez Henr quez

Mxico, D.F. e Diciembre 2010

Agradecimientos
Gracias a mis padres, Constantino Cabrera y Gloria Altamirano, a mis hermanos, Lina, Omar, Ale y Susy, a las gemelas, Paulina y Carolina y a todos mis familiares cercanos por todo el apoyo brindado a travs de los aos. e n A mi esposa Blanca, por la paciencia, sacricio y apoyo que ha mostrado en los momentos ms dif a ciles y por la excelente compa y buenos momentos que hemos vivido juntos. na A mi director de tesis, Dr. Francisco Rodr guez Henr quez, le agradezco por su ayuda y orientacin incondicional durante mi estancia en el CINVESTAV. o A mis revisores de tesis, Dr. Luis Gerardo de la Fraga y Dr. Jos Guadalupe Rodr e guez Garc por sus invaluables comentarios que ayudaron a enriquecer este trabajo de tesis. a A todos los doctores con los que tuve oportunidad de cursar alguna materia (Dr. Adriano de Luca, Dr. Arturo D Dr. Jorge Buenabad, Dr. Pedro Mej Dr. Dominique Deaz, a, couchant, Dra. Sonia Mendoza, Dr. Jos Guadalupe Rodr e guez, Dr. Francisco Rodr guez, Dr. Luis Gerardo de la Fraga, Dr. Gabriel Ram rez), ya que han aportado mucho a mi formacin profesional. o A todo el personal del Departamento de Computacin, en especial a Sof Reza, a Felipa o a Rosas y Erika R por su ayuda y gran compromiso al momento de realizar su trabajo. os, A mis amigos en el CINVESTAV, que lograron que la estancia en el instituto fuese muy agradable. Al Centro de Investigacin y de Estudios Avanzados del IPN (CINVESTAV-IPN) por o abrirme las puertas de una gran institucin para la realizacin de estudios de posgrado. o o Al Consejo Nacional de Ciencia y Tecnolog (CONACyT) por la beca otorgada para a completar mis estudios de maestr y al proyecto SEP-CONACYT 60240 por otorgarme a el apoyo econmico para la realizacin de viajes a congresos internacionales. o o

Resumen Las redes inalmbricas de sensores son una tecnolog emergente que puede ser ampliaa a mente utilizada para la creacin de aplicaciones novedosas en diversas reas del conocio a miento. Sin embargo an cuando esta tecnolog parece ser una excelente solucin para u a o un amplio rango de escenarios, stas introducen nuevos retos de diseo que los encargados e n de implementar los nuevos sistemas deben afrontar. Vale recordar que estas redes basan su operacin en diminutos dispositivos llamados nodos, los cuales estn restringidos en o a poder de cmputo, memoria y energ o a. En este trabajo de tesis se presenta un mecanismo seguro de recoleccin de datos para o redes inalmbricas de sensores, donde a travs del anlisis realizado hemos identicado a e a caracter sticas altamente deseables para un mecanismo de recoleccin de datos. Entre los o requisitos ms importantes podemos encontrar: escalabilidad, seguridad, diversidad de a sensores, entre otros. Otra caracter stica muy importante de este trabajo es que los nodos pueden ser mviles, para cumplir con este requerimiento hemos incorporado funciones de o posicionamiento global. Despus de haber realizado el anlisis de los requerimientos procedimos a proponer e a una arquitectura de recoleccin, tipos de datos y nodos, un procedimiento de reenv de o o paquetes, y los componentes del mecanismo de recoleccin, como son nodos, puertas de o enlace y servidores. Finalmente se describen detalles de la implementacin de todos los o componentes del mecanismo de recoleccin. o Adems en este trabajo de tesis se presentan tres posibles aplicaciones potenciales, se a da una descripcin de ellas y se comenta como es que el mecanismo de recoleccin de o o datos puede aplicarse para dar forma a la aplicacin. o

Abstract Wireless sensor network is an emerging technology that can be widely used for the creation of new applications in various elds of knowledge. But even though this technology seems to be an excellent solution for a wide range of scenarios, it also introduces new design challenges that those implementing the new systems must face. It is worth to mention that these networks base their operations on tiny devices called nodes, which are restricted in computing power, memory and energy. This thesis presents a secure mechanism of data collection for wireless sensor networks, where through a careful analysis we have identied highly desirable characteristics for a data collection mechanism. Among the most important requirements, we have found: scalability, security, diversity of sensors, among others. Another very important feature of this work is that nodes can be mobile; to meet this requirement we have incorporated global positioning capabilities. After having completed the requirements analysis we proceeded to propose an architecture, that recollects data by means of several classes of nodes, a packet forwarding process, and components of the collection mechanism, such as nodes, gateways and servers. Later, we describe details of the implementation of all components that form part of the main architecture. Finally, in this thesis we propose three potential application scenarios, a description of each one is given and we also discuss how the mechanism of data collection can be applied.

 Indice general
1 Introduccin o Introduccin o 2 Antecedentes 2.1 2.2 2.3 Tercera era de la computacin . . . . . . . . . . . . . . . . . . . . . . . . . o Tecnolog inalmbricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . as a Redes inalmbricas de sensores . . . . . . . . . . . . . . . . . . . . . . . . a 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 Escenarios tipicos y aplicaciones . . . . . . . . . . . . . . . . . . . . Sensores y adquisicin de datos . . . . . . . . . . . . . . . . . . . . o 1 1 3 3 4 6 8 9

Movilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Retos de diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 n Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 19

3 Tecnolog utilizada a 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5

Anlisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 a Red Inalmbrica de Sensores . . . . . . . . . . . . . . . . . . . . . . 20 a Software empotrado . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Software de aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . 24 o Algoritmos de cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Red Inalmbrica de Sensores . . . . . . . . . . . . . . . . . . . . . . 30 a Software empotrado . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Software de aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . 34 o Algoritmos de cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Otros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 iii

Plataforma elegida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Arquitectura 4.1 4.2 4.1.1 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.2.9

37

Anlisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 a Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Paquete de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Tipos de nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Tipos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Reenv de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . 42 o Nodo de lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Nodo de reenv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 o Nodo de procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . 45 Puerta de enlace simple . . . . . . . . . . . . . . . . . . . . . . . . 45 Puerta de enlace avanzada . . . . . . . . . . . . . . . . . . . . . . . 46 Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 n

4.2.10 Servidor de almacenamiento . . . . . . . . . . . . . . . . . . . . . . 47 4.2.11 Servidor de consulta . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5 Desarrollo 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 5.2 5.2.1 49 Nodo de lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Nodo de reenv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 o Nodo de procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . 65 Puerta de enlace simple . . . . . . . . . . . . . . . . . . . . . . . . 66 Puerta de enlace avanzada . . . . . . . . . . . . . . . . . . . . . . . 68 Servidor de almacenamiento . . . . . . . . . . . . . . . . . . . . . . 69 Servidor de consulta . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Problemas presentados y su solucin . . . . . . . . . . . . . . . . . 75 o 77

Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 o

Pruebas y resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6 Aplicaciones Potenciales 6.1 6.2 6.3

Sistema de informacin mdica . . . . . . . . . . . . . . . . . . . . . . . . 77 o e Sistema de seguimiento para atletas . . . . . . . . . . . . . . . . . . . . . . 79 Sistema de inventarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 85

7 Conclusiones y Trabajo Futuro 7.1

Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 iv

A Anexo A A.1 Compilacin y carga del programa en los nodos . . o A.2 Instalacin del compilador para arquitecturas ARM o A.3 Cambio del baudrate en los nodos MICAZ . . . . . A.4 Interfaces de comunicacin en los nodos MICAZ . . o A.4.1 Interfaz I2C . . . . . . . . . . . . . . . . . . A.4.2 Interfaz SPI . . . . . . . . . . . . . . . . . . A.4.3 Interfaz UART . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

89 89 90 91 92 92 92 94

vi

 Indice de guras
2.1 2.2 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Comparativa de tecnolog inalmbricas. . . . . . . . . . . . . . . . . . . . as a 6

Ruteo alterado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Comunicacin sin cifrado travs de un canal inseguro. . . . . . . . . . . . . 26 o e Comunicacin con cifrado a travs de un canal inseguro. . . . . . . . . . . 27 o e Esquema para el cifrado de datos. . . . . . . . . . . . . . . . . . . . . . . . 29 Esquema para el descifrado de datos. . . . . . . . . . . . . . . . . . . . . . 30 Nodo MICAZ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Puerta de enlace MIB520. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Puerta de enlace MIB600. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Puerta de enlace NB100. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Tarjeta de sensores MDA100. . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.10 Tarjeta de sensores MTS420CC. . . . . . . . . . . . . . . . . . . . . . . . . 33 3.11 Modulo de lectura RFID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1 4.2 4.3 4.4 4.5 4.6 5.1 5.2 5.3 5.4 5.5 5.6 Arquitectura del mecanismo de recoleccin. . . . . . . . . . . . . . . . . . . 40 o Estructura del paquete de datos. . . . . . . . . . . . . . . . . . . . . . . . . 41 Esquema de reenv de paquetes. . . . . . . . . . . . . . . . . . . . . . . . 43 o Nodo de lectura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Puerta de enlace simple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Peticin de almacenamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . 46 o Mquina de estados para el nodo de lectura. . . . . . . . . . . . . . . . . . 50 a Implementacin del cifrado CBC. . . . . . . . . . . . . . . . . . . . . . . . 51 o Estructura de la mquina de estados para el nodo de lectura. . . . . . . . . 51 a Arquitectura del nodo MICAZ . . . . . . . . . . . . . . . . . . . . . . . . . 52 Segmento de cdigo en nesC que inicializa el modulo GPS . . . . . . . . . 54 o Inicializacin del modulo GPS vista en un analizador lgico. . . . . . . . . 55 o o vii

5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26 5.27 5.28 6.1 6.2 6.3 A.1 A.2 A.3 A.4 A.5

Ejemplo de mensajes generados por el GPS en formato NMEA 0183 . . . Segmento de cdigo en nesC que interpreta el mensaje $GPGLL proveo niente del modulo GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocolo de comunicacin para el sensor de humedad. Imagen original [12]. o Implementacin de la rutina SecuenciaInicio para el sensor SHT11. . . . . o Implementacin de la rutina EnviaDireccion para el sensor SHT11. . . . . o Implementacin de la rutina LeeBit para el sensor SHT11. . . . . . . . . . o Implementacin de la rutina LeeSensor para el sensor SHT11. . . . . . . . o Circuito utilizado para adaptar los niveles de voltaje. . . . . . . . . . . . . Implementacin de la peticin de lectura. . . . . . . . . . . . . . . . . . . . o o Implementacin del evento recibe. . . . . . . . . . . . . . . . . . . . . . . . o Implementacin del evento completado para el temporizador. . . . . . . . . o Implementacin del evento recibe para el nodo de procesamiento. . . . . . o Peticin de almacenamiento para puerta de enlace simple. . . . . . . . . . o Env de peticin por el puerto serial. . . . . . . . . . . . . . . . . . . . . . o o Formato de los datos recibidos. . . . . . . . . . . . . . . . . . . . . . . . . Peticin de almacenamiento para puerta de enlace avanzada. . . . . . . . . o Envio de datos al servidor remoto a travs de un socket. . . . . . . . . . . . e Pseudocdigo que recupera los datos de la peticin remota y los almacena. o o Estructura del programa que muestra los datos almacenados. . . . . . . . . Estructura del programa que muestra los datos almacenados en un mapa. . Datos recolectados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapa generado con los datos recolectados. . . . . . . . . . . . . . . . . . .

55 56 57 58 58 59 59 61 63 64 65 66 67 67 68 69 69 71 72 73 74 74

Esquema simplicado para la aplicacin de informacin mdica. . . . . . . 79 o o e Esquema simplicado para la aplicacin de seguimiento para atletas. . . . . 81 o Esquema simplicado para la aplicacin de levantamiento de inventarios. . 83 o Comando para compilar y cargar los programas en los Estructura del archivo makele . . . . . . . . . . . . Formato de las seales de comunicacin en I2C. . . . n o Formato de las seales de comunicacin en SPI. . . . n o Formato de las seales de comunicacin en UART. . . n o nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 89 93 94 95

viii

 Indice de tablas
3.1 4.1 4.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 Lenguajes de programacin disponibles para todas las arquitecturas. . . . . 22 o Tipos de nodos denidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Tipos de datos denidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Seales del interruptor electrnico U7 y U9 . . . . . . . . . . . . . . . . n o Distribucin de terminales en la tarjeta de sensores MDA100. . . . . . . . o Peticin para leer un identicador [19]. . . . . . . . . . . . . . . . . . . . o Respuesta del modulo de lectura cuando se ha encontrado un identicador [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Respuesta del modulo de lectura cuando no se ha encontrado un identicador [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estructura de la tabla Registros. . . . . . . . . . . . . . . . . . . . . . . . Problemas presentados en est tesis y su solucin. . . . . . . . . . . . . . a o . 53 . 61 . 62 . 62 . 63 . 70 . 75

A.1 Conguracin del baudrate para el microcontrolador Atmel ATMEGA128. . 91 o A.2 Componentes en nesC para las principales interfaces de comunicacin . . . 96 o

ix

Cap tulo 1 Introduccin o

Una red inalmbrica de sensores es una infraestructura compuesta por nodos de sensaa do equipados con procesadores limitados en conjunto con capacidades de comunicacin o inalmbrica limitadas. A pesar de estas limitaciones, las redes inalmbricas de sensores a a ofrecen relativamente bajas tasas de transmisin en enlaces de corto alcance, ultra bajo o consumo de energ y bajo costo total. Estas caracter a sticas permiten que un administrador de sistemas tenga capacidad de instrumentar y vigilar eventos f sicos, as como la oportunidad de reaccionar contra diferentes incidentes y los fenmenos que pueden ocurrir o en el ambiente que se encuentra bajo observacin. o Aun cuando existen tecnolog bastante utiles, como las redes inalmbricas de senas a sores, actualmente el uso de sistemas de captura automtica de informacin tiene poca a o difusin, por lo que este trabajo presenta el anlisis, diseo e implementacin de un mecao a n o nismo seguro de recoleccin de datos geo-referenciados utilizando nodos mviles en redes o o inalmbricas de sensores. a El mecanismo seguro de recoleccin presentado en este trabajo tiene la caracter o stica de ser escalable, ya que los nodos pueden entrar y salir en cualquier momento de la red sin necesidad de realizar conguraciones especiales. Adems pueden realizar su trabajo a fuera de l nea y cuando se encuentre una conexin disponible, pueden enviar los datos o recolectados previamente. Adems el mecanismo debe ser capaz de poder ser adaptado a a una gran variedad de sensores sin sufrir cambios en su funcionamiento y/o estructura. Por ultimo, este mecanismo deber ser capaz de operar con la m a nima intervencin del o ser humano. 1

Cuando la informacin haya sido capturada y recolectada, sta ser almacenada en o e a una base de datos central, para que pueda ser utilizada por algn otro componente de u software y dar forma a una aplicacin o sistema de informacin. En este desarrollo se o o incluye la utilizacin de funciones criptogrcas para proveer servicios de seguridad a los o a componentes del sistema. El resto de este documento est descrito a continuacin. El cap a o tulo 2 presenta los antecedentes tericos sobre los cuales est fundamentado nuestro trabajo. Despus, en el o a e cap tulo 3, se analiza y presenta la tecnolog utilizada en este trabajo. En el cap a tulo 4 se presenta la arquitectura del mecanismo de recoleccin, cubriendo dos elementos fundao mentales, el anlisis y el desarrollo. El cap a tulo 5 presenta la etapa de implementacin y de o resultados obtenidos. El cap tulo 5 presenta tres aplicaciones potenciales de este trabajo. Despus, en el cap e tulo 6 abordamos las conclusiones y el trabajo a futuro. Finalmente, se presenta el anexo A con detalles de conguracin e instalacin. o o

Cap tulo 2 Antecedentes

El objetivo del presente cap tulo es realizar un anlisis y presentar las propuestas ms a a relevantes en el rea donde el presente trabajo de tesis se encuentra suscrito. a

2.1

Tercera era de la computacin o

Las cosas estn cambiando continuamente en el mundo de la computacin. Todo ema o pez con la era del mainframe: hace unos 30 aos, estos grandes dispositivos se utilizarn o n o ampliamente, por ejemplo, en las universidades. Muchos estudiantes y profesores hicieron uso de una computadora central unica que compart entre ellos. Cabe mencionar que an estos equipos ten un alto costo, un poder de cmputo limitado y una gran cantidad de an o de mantenimiento debido a las dimensiones del sistema. La tecnolog avanz tal y como estaba previsto por la ley de Moore y fue as que a o entramos en la segunda era de la computacin. Esta era, que an est presente pero que o u a poco a poco va llegando a su nal, est caracterizada por la computadora personal, donde a sta es ms barata y ms pequea, y cada vez ms asequible. Muy a menudo, el usuario e a a n a promedio tiene acceso y utiliza ms de una computadora, estas mquinas estn presentes a a a ahora en casi cualquier hogar y lugar de trabajo. Pero, en este entorno familiar, las cosas empiezan a cambiar y la tercera era de la computacin gana ms y ms terreno cada d Los avances tecnolgicos provocan que las o a a a. o computadoras personales, se vuelvan ms pequeas y baratas. Los equipos de escritorio a n 3

tienden a ser sustituidos por computadoras porttiles y otros dispositivos mviles. Lo que a o antes era un telfono celular convencional ahora es un dispositivo mucho ms sosticado e a (incorporando, por ejemplo, una cmara digital o una pantalla de alta resolucin) con a o mayores capacidades de comunicacin [53]. o El principal factor que est inuyendo en la nueva transicin es la disponibilidad de a o tecnolog inalmbricas de comunicacin [33]. Los usuarios estn utilizando ampliamente as a o a dispositivos inalmbricos de comunicacin debido a su independencia de equipos jos. El a o xito y la disponibilidad de Internet trajo an ms independencia al usuario: los datos e u a ahora podrn estar disponibles independientemente de la ubicacin f a o sica del dueo. n Los avances en la tecnolog no se detienen aqu los microprocesadores se han hecho ms a : a pequeos y baratos, por lo que ahora se encuentran en casi cualquier dispositivo que nos n rodea en el hogar, como un reloj despertador o un aparato electrodomstico. Los esfuerzos e actuales se concentran para que estos dispositivos interacten entre s y se organicen en u redes ad-hoc para cumplir con objetivos espec cos de manera ms rpida y ms conable. a a a Esto es, de hecho, la tercera era de la computacin prevista hace dos dcadas por Mark o e Weiser [51]. El mundo de la computacin ubicua tiene una visin contraria sobre el uso o o de poder de cmputo: en lugar de tener muchos de usuarios reunidos alrededor de una o computadora central, ahora cada usuario utiliza los servicios de varias redes inmersas en el medio ambiente.

2.2

Tecnolog inalmbricas as a

El nmero creciente de sistemas de control y de monitoreo presentes en casi cualquier u dispositivo electrnico, y el amplio requerimiento de conectividad en estos sistemas ha o causado un cuello de botella en el desarrollo de los mismos [29]. Adems, es pertinente a recordar que los fabricantes de dispositivos electrnicos utilizan diferentes interfaces de o comunicacin, ya sea estndares o propietarias, para la comunicacin entre componentes o a o en los sistemas anteriormente mencionados.

Los enlaces de comunicacin en sistemas electrnicos de control y de monitoreo, son o o comnmente cableados, ya que ello permite un intercambio de informacin conable entre u o los diferentes componentes del sistema. Un caso especial, ocurre cuando los perifricos se e encuentran fuera del dispositivo de control, pues el cableado requerido trae problemas como: costo de instalacin, seguridad, conveniencia, factibilidad, entre otros. o

La tecnolog inalmbrica es la solucin obvia para superar los inconvenientes descria a o tos con anterioridad, an cuando esta solucin implica un nuevo conjunto de retos, por u o ejemplo, propagacin de la seal, interferencia, seguridad, regulaciones y otros. La tecnoo n log para superar estos problemas existe, pero normalmente con complejidad agregada a causando un incremento en el costo del sistema.

Ciertamente, muchas aplicaciones pueden pagar el costo de agregar un sistema de comunicacin inalmbrica de gama alta, por ejemplo, un telfono celular, redes de area o a e local, entre otros. Contrariamente, muchas otras aplicaciones pueden resultar ser factibles o verse mejoradas si una solucin de comunicacin inalmbrica estndar de bajo costo se o o a a encuentra disponible.

Una red inalmbrica de area personal con una baja tasa de transmisin, es una red a o diseada para las comunicaciones sin cables, de corto alcance, de bajo costo y de muy n bajo consumo de potencia. Esta denicin est en desacuerdo con la tendencia actual en o a tecnolog inalmbricas, cuyo enfoque suele darse en el desarrollo de sistemas de comuas a nicaciones con un alto rendimiento y gran volumen de procesamiento de datos, as como una calidad de servicio mejorada [29].

Como se mencion anteriormente, existen diferentes tecnolog para la comunicacin o as o inalmbrica (e.g. Zigbee, Bluetooth, IEEE 802.11, WiMax, 3G, etc), cada una de ellas a diseada para un propsito espec n o co y con caracter sticas de trabajo muy diferentes, tal y como lo muestra la gura 2.1 [49].

Figura 2.1: Comparativa de tecnolog inalmbricas. as a

2.3

Redes inalmbricas de sensores a

Las redes inalmbricas de sensores es el nombre genrico bajo el cual se conoce a una a e amplia gama de dispositivos de cmputo empotrado. Bsicamente, cualquier conjunto de o a dispositivos equipados con un procesador, con capacidades de sensado y comunicacin y o con la capacidad de organizarse en una red creada de manera ad hoc se consideran dentro de esta categor [53]. a La adicin de capacidades de comunicacin inalmbrica a los sensores ha aumentado su o o a funcionalidad dramticamente. Las redes inalmbricas de sensores brindan capacidades a a de monitoreo lo que cambi para siempre la forma en la que se recogen datos del meo dio ambiente. Por ejemplo, la grabacin de actividad geolgica, monitoreo de propiedad o o 6

qu micas o biolgicas, o el monitoreo de fenmenos ambientales como la lluvia. o o El enfoque anterior fue: grandes y robustos dispositivos eran necesarios para construir los equipos de sensado, sin olvidar una fuente de gran potencia y capacidades locales de almacenamiento de datos. Un equipo de cient cos ten que viajar hasta el destino del oba jeto a ser monitoreado, colocar los aparatos caros en las posiciones predenidas, y calibrar todos los sensores. Luego, era necesario volver despus de un cierto tiempo para recoger los e datos recolectados. Si por desgracia exist algn fallo en el hardware, entonces nada pod a u a hacerse al respecto, ya que la informacin recolectada sobre el fenmeno se habr perdido. o o a El nuevo enfoque consiste en la construccin de dispositivos de sensado de bajo coso to y de pequeo tamao, con alta eciencia energtica. Como cientos o incluso miles de n n e estos dispositivos se van a desplegar, las limitaciones de conabilidad para ellos pierden importancia. No hay almacenamiento local de datos, ya que la informacin se procesar a o a nivel local y luego se transmitir v radio a uno o ms puntos de acceso conectado a a a a una red informtica. La calibracin individual de cada nodo sensor ya no es necesaria, ya a o que puede llevarse a cabo mediante algoritmos localizados [52]. La instalacin tambin o e ser ms fcil, colocando de forma aleatoria los nodos (por ejemplo, estos se pueden tirar a a a desde un avin) para el seguimiento de una regin geogrca. o o a Teniendo en cuenta este ejemplo, podemos proveer una descripcin general de un nodo o sensor. El nombre de nodo sensor (o mote) se utiliza para describir un pequeo dispositin vo que tiene comunicacin inalmbrica de corto alcance, un pequeo procesador y varios o a n sensores. Puede ser alimentado por bater y su funcin principal es recoger datos de as o un fenmeno, colaborar con sus vecinos, y enviar sus datos (incluso pre-procesando la o informacin o tomando decisiones) hasta el punto nal, si as lo requiere. Esto es posible o gracias a su procesador, adems, contiene el cdigo que permite la comunicacin entre a o o nodos y la puesta en marcha, mantenimiento, y la reconguracin de la red inalmbrica. o a Cuando se hace referencia a la comunicacin inalmbrica, tenemos en mente sobre todo o a la comunicacin por radio (otros medios como la ecograf luz visible o infrarroja, etc. o a, tambin pueden ser utilizados [50]). e Las redes inalmbricas de sensores son una de las herramientas ms importantes de a a la tercera era de la computacin. Estos son los dispositivos ms sencillos, teniendo como o a objetivo principal la vigilancia del medio y la alerta de los principales acontecimientos 7

que estn sucediendo. Con base en la observacin reportada por estos instrumentos, los a o humanos y las mquinas pueden tomar decisiones y actuar en consecuencia. a

2.3.1

Escenarios tipicos y aplicaciones

En este momento, existe una gran variedad de sensores, stos se han desarrollado para e monitorear casi todos los aspectos del medio ambiente: las condiciones de iluminacin, o temperatura, humedad, presin, la presencia o ausencia de qu o micos o biolgicos diversos, o deteccin de presencia y movimiento, etc. o Mediante la creacin de redes con un gran nmero de sensores y su despliegue en el o u interior del fenmeno a estudiar, se obtiene una herramienta de monitoreo ms potente o a que al tener un solo sensor. Las redes inalmbricas de sensores se pueden clasicar sobre una base de complejidad a de las aplicaciones [27]:

Almacenamiento inteligente: cada elemento a ser controlado dentro de un almacn e es etiquetado con un pequeo dispositivo, estas etiquetas son supervisadas por el n sensor jo que se encuentra incrustado en las paredes y estanter Con base en los as. datos le dos, el conocimiento de la posicin de los sensores y el tiempo de la comuo nicacin, la red de sensores ofrece informacin sobre el trco de mercanc en el o o a as interior del edicio, crea inventarios automticos e incluso realiza las correlaciones a de largo plazo entre los datos le dos.

Desde el punto de vista de la complejidad, este escenario requiere un m nimo de complejidad. Los nodos de sensores son colocados en posiciones jas, de una manera ms a o menos al azar. La zona de despliegue es de fcil acceso y algunas infraestructuras a (por ejemplo, fuentes de alimentacin y equipos) ya existen. En esta categor poo a, demos incluir el escenario de un supermercado moderno, donde los productos seleccionados de los clientes se identican automticamente a la salida del supermercado. a

 Monitoreo ambiental. Esta es el rea ms amplia de aplicaciones previstas hasta a a ahora. Una aplicacin particular de esta categor es el monitoreo de desastres. Los o a nodos de sensores son desplegados en las zonas afectadas y estos puede ayudar a los humanos a estimar los efectos de la catstrofe, construir mapas de las zonas seguras, a y dirigir las acciones humanas hacia las regiones afectadas. Un gran nmero de aplicaciones en esta categor se enfocan al control de la fauu a na. Este escenario tiene una mayor complejidad. La zona de despliegue ya no es accesible de manera fcil y ya no es seguro para los nodos de sensores. Apenas a hay infraestructuras actuales, los nodos deben ser diseminados en forma aleatoria y la red puede contener nodos mviles, tambin ser necesario desplegar un mayor o e a nmero de nodos. u Redes de sensores de gran escala: el escenario de una gran ciudad donde todos los autos tienen sensores integrados. Estos nodos de sensores se comunican entre s y recopilan informacin sobre el trco, rutas y condiciones especiales de trco. Por o a a un lado, la nueva informacin est disponible para el conductor de cada veh o a culo. Por otro lado, una visin global de toda la ciudad tambin puede estar disponible. o e Las dos principales limitaciones que caracterizan este escenario son el gran nmero u de nodos y su alta movilidad. Los algoritmos empleados necesidan ser escalables y hacer frente a una red con topolog en cambio continuo. a

2.3.2

Sensores y adquisicin de datos o

Los sensores son la interfaz con el mundo real, ellos recolectan la informacin necesaria y o stos son monitoreados por la unidad de procesamiento central. Las plataformas pueden e estar construidas en una forma modular de modo que una variedad de sensores puedan ser usados en la misma red. La tecnolog para el sensado y control incluye sensores de campo elctrico y campo a e magntico; sensores de radio frecuencia, sensores opticos, opto-electrnicos e infrarrojos; e o radares, lseres; sensores de localizacin y navegacin; sensores s a o o smicos; sensores ambientales (viento, humedad, calor); sensores bioqu micos. Los sensores de hoy pueden ser descritos como inteligentes, esto es, dispositivos baratos equipados con varios sensores, que son de bajo costo y bajo consumo.

La mayor de las plataformas de redes inalmbricas de sensores incluyen la posibilidad a a de agregar nuevos dispositivos de lectura a la plataforma de cmputo, esto nos ofrece la o posibilidad de ampliar las capacidades de sensado.

2.3.3

Movilidad

Las redes inalmbricas de sensores se caracterizan por tener topolog muy dinmicas, a as a inducida por las uctuaciones en la conectividad inalmbrica. Sin embargo, algunas aplia caciones pueden introducir un grado an mayor de dinamismo, debido a la necesidad de u apoyar f sicamente a dispositivos mviles [39]. La movilidad puede (o no) manifestarse de o diferentes maneras: En las aplicaciones estticas, no se mueven los nodos una vez desplegados. Esto es, con a mucho, el caso ms comn en las implementaciones actuales. a u Algunas aplicaciones utilizan dispositivos de sensado conectados a entidades mviles o (por ejemplo, robots o animales) o capaz de moverse de forma autnoma (por ejemplo, o el proyecto nodos XYZ [40]). Un caso t pico es el seguimiento de animales en donde los sensores estn conectados a los animales, como en el proyecto ZebraNet [32]. a Algunas aplicaciones explotan los receptores mviles: los nodos pueden ser jos o no: o el aspecto clave es que la recopilacin de datos se realiza de forma oportunista cuando se o mueve el receptor en la proximidad de los sensores [48].

2.3.4

Retos de dise o n

Al disear un sensor de una red inalmbrica se enfrenta por un lado la simplicidad del n a hardware subyacente, y, por otra parte, los requisitos que deben cumplirse. Para satisfacerlos, nuevas estrategias y nuevos conjuntos de protocolos se han de desarrollar. A continuacin, vamos a abordar los principales desaf que estn presentes en el campo o os a de redes inalmbricas de sensores. Las l a neas de investigacin implicadas y las cuestiones o pendientes que an deben ser respondidas se presentarn tambin. En primer lugar, una u a e 10

descripcin de alto nivel de los objetivos actuales de las redes de sensores pueden sintetio zarse como:

Larga vida: El nodo sensor debe ser capaz de vivir el mayor tiempo posible con sus propias bater Esta limitacin se puede traducir a un consumo energtico infeas. o e rior a 100 mW. La condicin surge de la suposicin de que los nodos sensores se o o desplegarn en un entorno hostil donde el mantenimiento es imposible o tiene un a precio prohibitivo. El tiempo de vida de un nodo espec ca el periodo de tiempo que ste funciona con dos bater de tamao AA, que comnmente debe ser de un e as n u par de aos. Este objetivo slo puede lograrse mediante la aplicacin de una estricta n o o pol tica de consumo de potencia, la cual har uso de los modos de ahorro de energ a a.

Tamao pequeo: El tamao del dispositivo debe ser inferior a 1 mm3 . Este l n n n mite dio el nombre a los nodos sensores de polvo inteligente, un nombre que da una idea muy intuitiva sobre el diseo nal. Recientemente, el procesador y la radio se n ha integrado en un chip con una tamao de aproximadamente 1 mm3 . Lo que queda n es la antena, los propios sensores, y la bater Los avances se requieren en cada uno a. de estos tres campos para poder cumplir con esta limitacin de diseo. o n

Bajo costo: La tercera limitacin de alto nivel de diseo es el precio de estos disposio n tivos. Para alentar el despliegue a gran escala, esta tecnolog debe ser ms barata, a a lo que signica que los precios de los dispositivos deben estar en el rango de centavos.

2.3.5

Seguridad

La seguridad y la privacidad son aspectos importantes para la computacin en general, o sin embargo para sistemas basados en redes inalmbricas de sensores, estos retos se ina crementan dada la dinmica, espontaneidad, heterogeneidad y naturaleza invisible de la a aplicacin [36]. o El desarrollo de sistemas seguros con redes inalmbricas de sensores es un area que a ha sido poco explorada, ya que al utilizar un medio de transmisin no guiado, como lo o es el aire, se encuentran sujetos a diversos ataques, los cuales pueden variar de acuerdo 11

a la aplicacin, por parte de entidades maliciosas. Adems, estos dispositivos no tienen o a la suciente capacidad de cmputo para ejecutar algoritmos criptogrcos utilizados en o a aplicaciones cliente - servidor. Los mecanismos existentes de autenticacin, estn diseados para pocas asociaciones o a n de amplia duracin entre un usuario y un dispositivo, hecho que no sucede en las aplicao ciones basadas en redes de sensores, ya que por la dinmica de la red, una operacin de a o autenticacin puede ocurrir repetidas ocasiones en un lapso pequeo de tiempo, lo cual o n implica que una signicativa porcin de tiempo el nodo estar ejecutando algn algoritmo o a u criptogrco, situacin que puede dar lugar a un comportamiento no deseado. a o Otro aspecto importante de seguridad en este tipo de sistemas, es la privacidad donde emergen nuevos desaf ya que estas aplicaciones pueden recopilar datos acerca de los os, usuarios, incluyendo informacin de localizacin, actividad, personas que los acompaan, o o n voz, video, datos biolgicos, entre otros. Si estos sistemas se encuentran inmersos en el o medio ambiente, es comn que la gente ignore que se estn recopilando datos acerca de u a su comportamiento. Es importante mencionar que este tipo de aplicaciones no pueden conar en un acceso continuo a servidores, ya que como se coment anteriormente, estas aplicaciones son o frecuentemente desconectadas, por lo que es dif implementar un esquema de seguridad cil que involucre una conexin remota. o Por ultimo, la naturaleza de estos sistemas, crea la necesidad para un nuevo tipo de seguridad basada en la localizacin del nodo y en el contexto de operacin, y no en el o o usuario. Por ejemplo, autorizar una transaccin slo si el nodo solicitante se encuentra en o o un rea determinada. a En cuanto al area de seguridad, hemos estudiado varios art culos [23, 34, 38, 44, 47, 53], los cuales nos ofrecen un panorama general del anlisis desarrollado previamente y de a algunas propuestas efectuadas por otros investigadores. Cuando pensamos en aspectos de seguridad en redes inalmbricas de sensores, una de las preguntas principales que nos a vienen a la mente, es cules son las diferencias entre la seguridad en redes de sensores y a la seguridad en general? [53]

12

Los siguientes objetivos son considerados como esenciales: autenticidad de entidades y mensajes, integridad de datos, condencialidad, control de acceso y no repudio de actos de comunicacin [47]. o La autenticidad de entidades se reere al procedimiento utilizado para vericar que la identidad de los participantes en un acto de comunicacin es verdadera, mientras que para o los mensajes signica que existe una forma de comprobar que ste ha sido generado por e el remitente y no por un atacante. Un mecanismo que nos garantiza que los datos no han sido alterados (de forma voluntaria o involuntaria) es la integridad de datos, el cual nos asegura que los datos recibidos coinciden con los datos enviados. Un servicio fundamental cuando se transmiten datos sensibles (e.g. contraseas, nmeros de tarjetas de crdito, entre otros) es el de la conn u e dencialidad, el cual nos asegura que la informacin transmitida no puede ser vista por o entidades ajenas. El control de acceso consiste en que unicamente los usuarios autorizados puedan hacer uso del sistema. Por ultimo, el no repudio es un servicio de seguridad que impide a un usuario retractarse de un acto de comunicacin (e.g. una transaccin en l o o nea). Bsicamente, stos son los mismos objetivos que necesitan ser asegurados en redes a e inalmbricas de sensores (quiz con excepcin del no repudio, que es el de menos inters, a a o e debido al nivel en el cual operan las redes de sensores). Desde un punto de vista muy general, uno podr llegar a la conclusin de que la sea o guridad en las redes inalmbricas de sensores no agrega mucho a lo que sabemos de la a seguridad en general, y que los mismos mtodos se pueden aplicar en redes de sensoe res, como en redes tradicionales y/o inalmbricas. Sin embargo, una consideracin ms a o a cercana revela varias diferencias en los or genes de ambos tipos de redes, por lo que las caracter sticas espec cas de las redes inalmbricas de sensores hacen que el uso directo a de tcnicas de seguridad conocidas no sean necesariamente apropiadas. e La seguridad en redes inalmbricas de sensores es un rea de investigacin de inters a a o e por las siguientes razones [53]: Los nodos de la red de sensores se despliegan bajo condiciones particularmente dif ciles, ya que una gran cantidad de nodos pueden ser distribuidos sobre un area 13

geogrca, suponemos que por lo menos algunos nodos podrn ser capturados y a a comprometidos por un atacante. Las restricciones de poder de cmputo, memoria y energ presentes en los nodos, o a los ponen en desventaja con potenciales atacantes debido a la gran diferencia de recursos disponibles. En la referencia [34], los autores proveen una descripcin de ataques y contramedidas o referentes al enrutamiento en redes inalmbricas de sensores. a Uno de los principales ataques en este tipo de redes es la insercin de informacin de o o enrutamiento suplantada o alterada, esto es con la nalidad de modicar la topolog de a la red, permitiendo que el trco se pueda atraer o repeler. En la gura 2.2 inciso a) a podemos observar la topolog normal de operacin en una red inalmbrica de sensores, a o a en el inciso b) de la misma gura la red ha sido particionada por el equipo A un atacante causando una desconexin momentnea en la red, por ultimo en el inciso c) el atacante o a ha puesto en operacin el equipo B el cual se comunica directamente con el equipo A o proporcionando conectividad entre todos los nodos de acuerdo a la topolog original. Sin a embargo, toda la informacin que se transmita podr ser vista y/o alterada por el atacante. o a

Figura 2.2: Ruteo alterado.

Otro procedimiento utilizado consiste en la creacin de mensajes de reconocimiento o (ACK ) para hacer creer a otros que el estado de conexin de un nodo es diferente a su o estado real. Un mecanismo ms sosticado consiste en el reenv selectivo por medio de a o un atasco deliberado, esto en conjunto con la creacin de nodos que absorben el trco y o a lo reenv a un nodo en especico, permite un control sobre la informacin que se env y an o a 14

la que se descarta. Adems se ha mostrado [34] que la simulacin de mltiples identidades a o u (Sybil attacks), permite reducir la efectividad de esquemas tolerantes a fallos. El ultimo de los ataques descritos se basa en el env de supuestos mensajes de sincron (hello o a shouting), en donde el atacante env o responde mensajes con una energ mayor, para a a engaar a otro nodo y que ste crea que son vecinos (debido a un mayor nivel de potencia). n e De acuerdo con los autores del art culo [34], los problemas de seguridad referentes a la creacin de mensajes de reconocimiento e informacin de ruteo, pueden controlarse de o o forma efectiva utilizando mecanismos de autenticacin del origen de los datos as como la o aplicacin de esquemas de condencialidad en los datos a nivel enlace. o En el art culo Security Protocols for Sensor Networks [44], se discuten los requerimientos y se propone un conjunto de protocolos para proveer servicios de seguridad de forma eciente en redes de sensores. Los principales retos en el diseo de estos protocolos vienen n dados por las restricciones presentes en estos dispositivos y por el hecho de que estos pueden ser capturados por atacantes. Se considera que algunas alternativas, tales como la criptograf asimtrica conllevan un alto costo computacional, lo cual las hace inadecuadas a e para este tipo de dispositivos. En este trabajo propone dos protocolos principales de seguridad: Sensor Network Encryption Protocol (SNEP) para realizar seguridad de extremo-aextremo de forma eciente. El protocolo TESLA, para autenticar las comunicaciones basadas en multidifusin. o Las principales decisiones de diseo en el desarrollo de estos protocolos fueron enfon cados en evitar el uso de criptograf asimtrica, mediante la construccin de todas las a e o primitivas de criptograf basadas en un sencillo cifrador por bloques, y con la explotaa cin de tareas en comn para reducir el exceso de comunicaciones cuando esto sea posible. o u En [38], los autores extienden la idea del protocolo TESLA para solucionar algunos problemas de escalabilidad presentados en el trabajo descrito anteriormente. El manejo de las llaves es comnmente una de las partes ms dif u a ciles al momento de implementar comunicaciones seguras [53]. El conjunto de protocolos de seguridad no pueden ofrecer proteccin alguna si las llaves caen en manos de atacantes. o

15

El protocolo SNEP [44], incluye la propuesta de un protocolo simple y tradicional para el manejo de llaves, que permite que dos nodos de sensores obtengan una llave secreta compartida con la ayuda de la estacin base. o A continuacin se tratar el tema del manejo de llaves [47], el cual comprende las o a siguientes tareas: Generacin de llaves: es la creacin de las llaves que se utilizarn para el proceo o a so de cifrado/descifrado. Tales llaves deben crearse ejecutando un proceso con la utilizacin de nmeros aleatorios, o por lo menos nmeros pseudo-aleatorios. En o u u caso contrario, los atacantes pueden crear sus propias llaves ejecutando el mismo proceso. Si se decide utilizar nmeros pseudo-aleatorios es importante inicializar la u generacin de la secuencia con un nmero verdaderamente aleatorio. o u Distribucin de llaves: es la entrega de las llaves al lugar (o entidad) que har uso o a de ellas. En escenarios simples, las llaves pueden ser distribuidas de forma directa. Si los nodos se encuentran f sicamente alejados y se utilizan algoritmos de cifrado simtricos, el canal de comunicacin necesita ser protegido mediante cifrado. Por lo e o tanto, una llave es necesaria para la distribucin de llaves. Esta necesidad implica o la introduccin de lo que se conoce como jerarqu de llaves. o a Almacenamiento de llaves: cuando se implemente esta funcionalidad se deben tomar medidas para evitar que las llaves sean le das por usuarios no autorizados. Recuperacin de llaves: es la reconstruccin de llaves cuando stas han sido perdio o e das o comprometidas. La manera ms simple de instrumentar este mecanismo es a mantener una copia de todas las llaves en un lugar seguro. Sin embargo, esto crea un posible problema de seguridad, ya que es necesaria una garant absoluta de que a las llaves no sern robadas. a Invalidacin de llaves: es una tarea muy importante del manejo de llaves, especialo mente en los mtodos de criptograf asimtrica. Si la llave privada ha sido revelada, e a e su correspondiente llave pblica debe ser publicada como invlida. En redes de sensou a res la invalidacin de llaves se espera que sea una operacin absolutamente eciente, o o dado que la posibilidad de que un nodo sea capturado y comprometido es bastante alta. 16

 Destruccin de llaves no requeridas: esta operacin es necesaria con el propsito o o o de asegurar que los mensajes cifrados con estas llaves no puedan ser en un futuro descifrados por personas no autorizadas. Es importante asegurarnos que todas las copias de las llaves sean completamente destruidas, de manera que no puedan volver a ser le das, aun con la utilizacin de tcnicas sosticadas de recuperacin de datos. o e o Aunado a las consideraciones anteriores, es necesario especicar algunos requerimientos en particular para el manejo de llaves para esquemas de redes de sensores [23], entre los que destacan: Vulnerabilidad de los nodos a ser capturados. Desconocimiento previo de la conguracin de despliegue de los nodos. o Dispositivos con restricciones. Topolog dinmica de la red. a a

2.4

Trabajos relacionados

El primer articulo estudiado [42], consiste en la utilizacin de redes inalmbricas de seno a sores para la localizacin vehicular, su objetivo es el de localizar un veh o culo equipado con un transceptor de radio frecuencia compatible con el estndar IEEE 802.15.4. En el a esquema propuesto por el autor existen tres tipos de nodos: los automviles a localizar, o los cuales poseen un nodo, los autobuses que transitan por una ruta ja, tambin llamae dos nodos mviles, que tienen como funcin recolectar datos de otros nodos utilizando o o un esquema automvil-a-automvil y los nodos jos, que se encuentran en lugares bien o o denidos (e.g. las paradas de la ruta de autobuses). Una caracter stica muy importante en este tipo de redes inalmbricas, es que los noa dos se unen y dejan la red inalmbrica en cualquier momento. Cuando los nodos mviles a o y los nodos jos entran en contacto debido a su cercan se transmite un mensaje al a, servidor del sistema de localizacin que contiene el identicador del nodo mvil y el ideno o ticador del nodo jo, por lo tanto la localizacin del veh o culo es actualizada en el sistema. Cuando la informacin de localizacin de un veh o o culo cambia, se actualiza la posicin o del autobs en pantalla, y se almacena para ser utilizada por bitcoras y reportes. El u a 17

servidor tambin transmite informacin basada en la localizacin que es util para el pae o o sajero en el nodo mvil colocado en un autobs. La informacin transmitida est basada o u o a en la localizacin actual del autobs, como pueden ser nombres de complejos tur o u sticos y edicios principales. El siguiente trabajo analizado [41] consiste en la realizacin de una estructura para o diseminar y reunir informacin acerca de veh o culos que se encuentran en camino, el cual puede ser de utilidad al momento de manejar en situaciones de neblina, lluvia o para encontrar una ruta optima en un viaje largo. Un sistema basado en posicionamiento global slo ofrece una vista esttica del mapa, o a mientras que el trabajo propuesto por el autor ofrece una perspectiva dinmica, la cual a se complementa con la informacin recibida del sistema de posicionamiento global. Este o sistema al integrarse con informacin georeferenciada puede proveer la funcionalidad de o un planicador de rutas en tiempo real. Este trabajo est basado en un computadora de mano Compaq iPAQ (expandida con a 2 slots PCMCIA) con una distribucin de GNU/Linux, un receptor del sistema de posio cionamiento global (GPS ), una tarjeta de red inalmbrica compatible con IEEE 802.11b, a una tarjeta PCMCIA de 2 puertos seriales y de una interfaz OBDI-II. Una desventaja del trabajo [42] es que para que la localizacin del veh o culo pueda efectuarse en cualquier punto, es necesario contar con una infraestructura de red inalmbrica a de cobertura amplia (e.g. a lo largo y ancho de la ciudad). Referente al sistema presentado en [41] podemos destacar que ocupa varios elementos de hardware, lo cual inevitablemente incrementa el costo de la aplicacin, adems de basar su red inalmbrica en el estndar o a a a IEEE 802.11b, siendo que este fu diseado para sistemas con alto volumen de transfee n rencia de datos y no para sistemas orientados a la recoleccin de datos. o

18

Cap tulo 3 Tecnolog utilizada a

En este cap tulo se describe la tecnolog utilizada para la realizacin de este trabajo. a o En la primera seccin se realiza un anlisis de todas las categor correspondientes a o a as este trabajo (redes inalmbricas de sensores, software empotrado, software de aplicacin a o y algoritmos de cifrado). Despus, en la segunda seccin, se dene una plataforma de e o trabajo y se describe a detalle. Finalmente, en la ultima seccin, se presentan algunos o otros componentes utilizados en la realizacin de este trabajo, principalmente utiles para o el desarrollo y las pruebas.

3.1

Anlisis a

Esta seccin presenta un anlisis de las opciones ms importantes de desarrollo para las o a a categor que este trabajo cubre. as Las categor en las cuales trabajaremos se describen a continuacin: as o 1. Red inalmbrica de sensores: a esta categor pertenecen los dispositivos electrnia a o cos que conforman la red inalmbrica de sensores, como son los nodos, las puertas a de enlace, entre otros.

2. Software empotrado: a esta categor pertenecen los programas que son ejecutados a por los dispositivos de la red inalmbrica de sensores. Tambin es comnmente coa e u nocido como rmware.

19

3. Software de aplicacin: este es el software que ejecutan los servidores para acceder o y/o modicar las bases de datos.

4. Algoritmos de cifrado: este es el algoritmo que utilizaremos para realizar el cifrado de los datos y proveer los servicios de seguridad para los nodos del sistema.

3.1.1

Red Inalmbrica de Sensores a

A continuacin se presenta un anlisis de la diferentes alternativas de hardware para redes o a inalmbricas de sensores. Inicialmente se mencionan las plataformas ms representativas a a del rea, para despus hacer una descripcin en base a la composicin de sus elementos. a e o o Existen una gran cantidad de plataformas para redes inalmbricas de sensores tanto a en productos comerciales como en prototipos de investigacin tales como: Crossbow [6], o Body Sensor Node [2], BTNodes [4], EYES [5], SunSPOT [9], Meshnetics [7], Scatter [8], XBee [10] y Arduino [3]. Sin embargo, los componentes utilizados en todas las plataformas anteriores no dieren drsticamente. Muchas de estas plataformas usan el microcontrolaa dor de 16 bits MSP430 de Texas Instruments o un microcontrolador de 8 bits de la familia Atmel ATMEGA. Una excepcin notable es la plataforma SunSPOT la cual utiliza mio crocontroladores de la familia ARM9. Las frecuencias de trabajo para estos procesadores van desde 8 MHz hasta arriba de 200 MHz, es importante recordar que el consumo de potencia del procesador est relacionado linealmente con la frecuencia de operacin [24]. a o La cantidad de memoria voltil va desde 2 KB hasta 512 KB. Normalmente esta mea moria se utiliza para almacenar los variables utilizadas durante la ejecucin del programa. o El cdigo binario del programa se almacena en la memoria dedicada, que va desde 32 KB o hasta 128 KB. Adems, los nodos son a menudo equipados con dispositivos de almacenaa miento externo, por ejemplo, circuitos electrnicos de memoria ash, cuyo tamao var o n a desde 128 KB hasta 4 MB. En cuanto al hardware utilizado para enviar y recibir datos de forma digital, la mayor a de las plataformas trabajan en la banda ISM de 2,4 GHz, y son compatibles con IEEE 802.15.4, por ejemplo, el circuito integrado CC2420 de Chipcon. Las soluciones alternativas operan en la banda de 868/916 MHz, por ejemplo, utilizando el circuito integrado 20

transmisor-receptor CC1000 de Chipcon o en otros casos utilizan interfaces Bluetooth. Todas las plataformas estn diseadas para ser operadas a bater por lo que en genea n as, ral consideran componentes que ofrecen bajos consumos de potencia para poder trabajar de forma autnoma durante periodos de tiempo extendidos sin la necesidad de reemplazar o su fuente de alimentacin. o Respecto a los sensores, cada plataforma tiene dispositivos de sensado espec cos para la aplicacin que fueron diseados y adems con frecuencia permite la adicin de nuevos o n a o dispositivos de sensado. La diversidad de sensores es una de las caracter sticas que marcan mayor diferencia entre las plataformas, ya que mientras algunas plataformas cuentan con tarjetas de adquisicin de datos con gran variedad de sensores [6] existen otras plataforo mas donde los sensores no forman parte del dispositivo y estos deben ser aadidos de n forma externa [10].

3.1.2

Software empotrado

Esta categor merece atencin especial ya que analiza las herramientas disponibles para a o producir el programa que se ejecutar en los nodos de la red inalmbrica de sensores. Se a a le conoce como software empotrado a todo aquel programa que va integrado dentro de un dispositivo electrnico, i.e. microcontrolador. El principal uso del software empotrado o no es en el campo de las tecnolog de informacin, sino ms bien est pensando para as o a a interactuar con el mundo real. Este software se escribe para sistemas que no son las t picas computadoras de escritorio que todo mundo conoce sino que el cdigo binario queda o inmerso en los circuitos electrnicos que podemos encontrar en autos, telfonos, equipo de o e audio, robots, juguetes, sistemas de seguridad, marcapasos, televisiones aunque tambin e es utilizado en aplicaciones muy sosticadas como son aviones, misiles, sistemas de control industrial, entre otros [37]. Para poder realizar un anlisis de las diversas opciones de software empotrado pria mero debemos denir las arquitecturas de los procesadores utilizados en los nodos. Las arquitecturas de los procesadores para las cuales analizaremos las diversas opciones de herramientas de desarrollo son: Atmel AVR, Texas Instruments MSP430 y ARM9. Con esta eleccin cubrimos una gran cantidad de microcontroladores presentes en redes inalmbrio a 21

cas de sensores, tal y como fue descrito en la seccin 3.1.1. o Los lenguajes de programacin disponibles para estas arquitecturas son: ensamblador, o C y nesC. El lenguaje ensamblador es un lenguaje de bajo nivel utilizado para escribir programas y constituye la representacin ms directa del cdigo mquina espec o a o a co para cada procesador siendo este legible para un programador. El lenguaje C es un lenguaje estructurado de propsito general, aunque es muy comn que este sea utilizado para escrio u bir sistemas operativos y/o otras utiler debido a un gran potencia, adems de permitir as a manipulaciones a bajo nivel [35]. nesC es un lenguaje de programacin para sistemas emo potrados en red como los motes, adems implementa un modelo de programacin basado a o en la ejecucin de eventos. Este lenguaje soporta concurrencia y simplica el desarrollo o de la aplicacin, optimiza el tamao del cdigo objeto y elimina fuentes de errores poteno n o ciales, como lo son la asignacin de memoria dinmica y la deteccin de condiciones de o a o carrera en tiempo de compilacin [28]. o

Lenguaje de Programacin o

Ventajas

Desventajas

Ensamblador

Control total del dispositivo

Dif de programar cil No hay portabilidad

Facilidad de programar Eciencia media-alta Gran portabilidad

nesC

Portabilidad

Eciencia media

Tabla 3.1: Lenguajes de programacin disponibles para o todas las arquitecturas.

La tabla 3.1 muestra una comparativa de lenguajes de programacin, es importante o 22

mencionar que los lenguajes listados en la tabla son soportados por todas las arquitecturas analizadas en la presente seccin. El lenguaje ensamblador es soportado por todas o las arquitecturas, aunque cada arquitectura tiene su propia denicin para este lenguaje, o mientras que el lenguaje C y nesC son los mismos para cualquier arquitectura aunque podr existir diferencias m an nimas dependiendo del compilador utilizado. Aparte de los lenguajes de programacin disponibles para la programacin en redes o o inalmbricas de sensores otro componente fundamental es el sistema operativo para los a nodos. Estos sistemas son t picamente menos complejos que los sistemas operativos de propsito general dado los requerimientos especiales de las redes inalambricas de sensores o y por que los recursos disponibles en estos dispositivos son claramente ms limitados. a En general las aplicaciones que utilizan nodos de sensores son menos interactivas que las aplicaciones para equipos de escritorio. Gracias a esto el sistema operativo no necesita incluir soporte para interfaces de usuario. TinyOS es el primer sistema operativo espec camente diseado para redes inalmbrin a cas de sensores, este sistema operativo tiene un modelo de programacin de aplicaciones o orientado a eventos. Varias caracter sticas importantes que inuyeron en el diseo de nesC n incluyen: una arquitectura basada en componentes, un modelo de concurrencia simple basado en eventos y las operaciones de fase dividida (split-phase) [31]. Contiki es un sistema operativo ligero con soporte para la carga dinmica de programas a y servicios. Este sistema fue diseado alrededor de un ncleo orientado a eventos pero de n u forma opcional provee multitarea preferente que puede ser aplicada a procesos individuales [26]. MANTIS es un sistema orientado al bajo consumo de recursos, posee un planicador de tareas eciente en cuestiones de energ adems solo ocupa unos 500 Bytes de memoria a, a RAM y 14KB de memoria ash. Provee capacidades multitarea preferente. Se encuentra disponible para las plataformas de MICA2 y MICAz de Crossbow, entre otras [21]. LiteOS es un sistema operativo con abstraccin de tipo UNIX, incluye un sistema de o archivos jerrquico y la posibilidad de interactuar con el sistemas a travs de una interfaz a e de comandos (shell ) de forma inalmbrica, el ncleo soporta la adicin de mdulos de a u o o forma dinmica y proporciona una ejecucin multitarea de forma nativa, los programas a o 23

se pueden realizar bajo el paradigma orientado a objetos [22].

3.1.3

Software de aplicacin o

En esta categor analizaremos brevemente el software de aplicacin utilizado para tres a o propsitos principales: para la ejecucin en el servidor de programas que generan pginas o o a dinmicas, de servidores Web y de servidores de base de datos. Respecto a los opciones a de lenguajes utilizadas en la ejecucin de programas para pgina dinmicas tenemos a 3 o a a principales: lenguaje ASP, lenguaje PHP y lenguaje JSP. La primera opcin, el lenguaje ASP, es producida por Microsoft. La programacin se o o realiza bajo el entorno .NET. T picamente se conecta fcilmente con servidores de bases a de datos tipo Microsoft SQL. Una desventaja es que la mayor compatibilidad de este lenguaje es con productos Microsoft. La segunda opcin, el lenguaje PHP, es mantenida por la comunicad de software libre o y es ampliamente usado en Internet. El lenguaje tiene sintaxis especica. Tiene muchas opciones de conexin con otros programas y/o servicios. o La tercera opcin, el lenguaje JSP, es producida por Sun Microsystems (ahora parte de o Oracle), es libre y la programacin se realiza en el lenguaje Java. Tiene muchas opciones o de conexin con otros programas y/o servicios. o Respecto a los servidores Web tenemos menos opciones, donde el mercado est dividido a en 2 principales productos: Servidor IIS. Este servidor es producido por Microsoft y es altamente compatible con el lenguaje ASP.

24

Servidor Apache. Este servidor es producido por la fundacin Apache, es libre y bastano te utilizado en Internet. Soporta al lenguaje PHP y al lenguaje JSP con sus respectivas adecuaciones. Por ultimo pasamos a los motores de bases de datos. Microsoft SQL, es un servidor de base de datos producido y soportado por Microsoft. Es un producto bastante estable y muy utilizado por las soluciones implementadas con productos Microsoft y tecnolog .NET. a MySQL, es un servidor de base de datos producido por Oracle. Existen versiones libres y de pago. Es ampliamente utilizado por las soluciones construidas con herramientas y tecnolog de cdigo abierto. a o

3.1.4

Algoritmos de cifrado

Dentro de la criptograf existen 2 grandes areas: criptograf simtrica y criptograf a a e a asimtrica. A continuacin se describen ambos. e o Los sistemas de cifrado simtrico tambin son conocidos como sistemas de clave simtrie e e ca, de clave secreta o de clave unica. Podemos explicar mejor el concepto de criptograf a simtrica presentado un problema fcil de entender: tenemos dos usuarios, Alicia y Beto, e a que quieren comunicarse a travs de un canal inseguro. El canal de comunicacin es slo e o o un trmino general para el enlace de comunicacin: este canal puede ser el Internet, una e o porcin de aire para el caso de los telfonos celulares o la comunicacin inalmbrica en una o e o a red local, entre otros. El problema real comienza con la entidad maliciosa, quin tiene ace ceso al canal, por ejemplo, interviniendo un ruteador de Internet o escuchando las seales n de radio en una comunicacin inalmbrica. Obviamente, hay muchas situaciones en las que o a Alicia y Beto preeren comunicarse sin que sean escuchados por una tercera entidad. Por ejemplo, si Alicia y Beto son dos ocinas de un fabricante de automviles, y se transmio ten los documentos que contienen la estrategia de negocio para la introduccin de nuevos o modelos de automviles en los prximos aos, estos documentos no deben caer en manos o o n de sus competidores. El escenario descrito anteriormente puede observarse en la gura 3.1.

25

Figura 3.1: Comunicacin sin cifrado travs de un canal inseguro. o e

En esta situacin, la criptograf simtrica ofrece una potente solucin: Alicia cifra su o a e o mensaje x utilizando un algoritmo simtrico, resultado el texto cifrado y. Beto recibe el e texto cifrado y descifra el mensaje. El descifrado es, por tanto, la inversa del proceso de cifrado. Cul es la ventaja? Si tenemos un algoritmo fuerte de cifrado, Oscar ver el a a texto cifrado como bits aleatorios y no contendr informacin que sea util. a o Las variables x, y, k que se aparecen en la gura 3.2 son importantes en criptograf y a tienen nombres especiales: x es conocido como el texto plano o texto en claro. y es conocido como el texto cifrado. k es conocido como la llave secreta. El conjunto de todas las posibles llaves secretas es llamado el espacio de llaves. Es importante recordar que el sistema necesita de un canal seguro para la distribucin o de llaves entre Alicia y Beto. La criptograf asimtrica esta basada en la siguiente idea, introducida por Die y a e Hellman en 1976 [25]: no es necesario que la llave utilizada por la entidad que cifra el mensaje (i.e. Alicia) sea secreta. La parte crucial es que Beto, el receptor, slo pueda o descifrar el mensaje con una llave secreta. Beto publica una llave de cifrado pblica que todo el mundo puede conocer. Beto tamu bin tiene llave secreta correspondiente, que utiliza para el descifrado. Por lo tanto la llave e de Beto consta de dos partes, kpublica y kprivada .

26

Figura 3.2: Comunicacin con cifrado a travs de un canal inseguro. o e

El esquema de comunicacin segura bajo un canal hostil utilizando criptograf asimtrio a e ca es idntico al esquema donde se utiliza criptograf simtrica, con la unica diferencia e a e es que para la distribucin de llaves no se necesita de un canal seguro ya que las llaves o utilizadas para el cifrado (i.e. llaves pblicas) pueden ser conocidas por cualquier entidad. u Dado que los esquemas de cifrado asimtrico hacen uso de recursos de computo mayoe res y de que los recursos disponibles en los dispositivos de hardware que utilizaremos son limitados, a partir de este momento para propsitos de este trabajo hemos tomado como o unica opcin a la criptograf simtrica para proveer los servicios de seguridad a los o a e componentes del mecanismo de recoleccin presentado en este trabajo. o Los principales cifradores simtricos son DES y AES, los cuales describiremos a contie nuacin. o DES ha sido por mucho el cifrador por bloques ms popular en los ultimos 30 aos. a n Aunque hoy en d no es considerado seguro contra un atacante de fuerza bruta dado que a el espacio de llaves en DES es pequeo. El proceso conocido como 3DES, que consiste en n cifrar tres veces en la con el algoritmo DES, es considerado como un cifrador muy seguro, el cual es ampliamente utilizado en la actualidad. DES utiliza un tamao de bloque de n 64 bits para el texto en claro y texto cifrado, mientras que considera una longitud de 56 bits para la llave secreta. AES es el algoritmo de cifrado simtrico ms empleado en la actualidad, ste fue dee a e clarado estndar de NIST en Octubre de 2000, siendo el sustituto habitual de algoritmo a 27

DES. Est basado en el algoritmo de Rijndael. Hasta la fecha, el mejor ataque conocido a contra AES es el ataque de fuerza bruta. El tamao de bloque es de 128 bits, mientras n que el tamao de sus posibles llaves son de 128, 192 y 256 bits. n Los modos de operacin permiten el uso repetido y seguro de un cifrador por bloques o con una sola llave. Un sistema de cifrado por bloques por s mismo slo permite el cifrado o de un bloque de datos. Cuando el mensaje a cifrar es de longitud variable, los datos deben dividirse en bloques de longitud igual al tamao de lo bloques permitidos por el cifrador. n Normalmente, el ultimo bloque deben ser ampliado para que coincida con la longitud de cifrado, utilizando un esquema de relleno adecuado. Un modo de operacin describe el o proceso de cifrar cada uno de estos bloques, y generalmente utiliza un valor de entrada inicial aleatorio, conocido como vector de inicializacin (IV), para proveer mayor segurio dad al cifrado resultante. Los principales modos de operacin para un cifrador por bloques son [43]: o Electronic Codebook (ECB ). Este es el modo de operacin ms simple, el mensaje es o a dividido en bloques y cada bloque se cifra de forma independiente. Tiene la desventaja de que bloques de texto plano idnticos generar bloques cifrados idnticos, por lo que este e e modo no oculta los patrones de datos t picos en archivos de imagen, por ejemplo, lo cual no provee condencial de forma efectiva. Cipher Feedback (CFB ). Este modo permite cifrar la informacin en unidades inferiores o al tamao del bloque y adems convierte al cifrador en una unidad de cifrado por ujo de n a datos, este modo suele utilizarse para cifrar caracteres individuales. Estas caracter sticas permiten aprovechar totalmente la capacidad de transmisin del canal de comunicaciones, o manteniendo adems un nivel de seguridad adecuado. a Output Feedback (OFB ). Funciona al igual que el modo de operacin CFB, pero ste o e utiliza como entradas sus propias salidas, por lo tanto no depende del texto. Counter (CTR). Al igual que los modos de operacin OFB y CFB, este modo convierte o una unidad de cifrado por bloques en una unidad de cifrado por ujo de datos. Genera el siguiente bloque cifrando valores sucesivos de un contador. El contador puede ser cualquier funcin sencilla que produzca una secuencia de nmeros donde los resultados se o u 28

repiten con muy baja frecuencia. Si bien la operacin ms usada es un contador, el modo o a CTR tiene caracter sticas similares al OFB, pero permite tambin usar una propiedad de e aleatoriedad. Galois Counter Mode (GCM ). Es un modo de operacin para cifradores por bloque, el o cual utiliza un algoritmo de cifrado que permite proveer los servicios de condencialidad y autenticacin. Para el cifrado utiliza el modo de operacin CTR. o o En el modo de operacin CBC los bloques cifrados se encuentran encadenados de tal o manera que el texto cifrado depende no slo de bloque de entrada sino tambin de todos o e los bloques de texto plano anteriores. En segundo lugar, el cifrado tiene forma aleatoria por la utilizacin del vector de inicializacin (IV) [43]. En el art o o culo [30] se presenta el diseo de un generador de nmeros aleatorios que pudiese ser utilizado para generar el n u vector de inicializacin. o

Figura 3.3: Esquema para el cifrado de datos.

El texto cifrado yi , que es el resultado del cifrado del texto plano xi , se retro-alimenta a la entrada del cifrador y se realiza la operacin XOR con el bloque de texto plano subseo cuente xi+1 . Esta suma XOR se cifra, dando el siguiente texto cifrado yi+1 , que se puede utilizar para cifrar xi+2 , y as sucesivamente. Para el caso del primer bloque la operacin o XOR se realiza con el vector de inicializacin previamente mencionado, tal y como lo o indica la gura 3.3.

29

El procedimiento detallado en la gura 3.3 es utilizado para proveer el servicio de condencialidad, adicionalmente con el propsito de proporcionar el servicio de auo tenticacin haremos uso del esquema conocido como CBC-MAC. La autenticacin del o o mensaje es lograda agregando a los datos un bloque extra de informacin, i.e. conteniendo o el nmero de bloques previos, y cifrando de la misma manera como lo hacemos cuando u utilizamos el esquema de cifrado CBC.

Figura 3.4: Esquema para el descifrado de datos.

El descifrado de los datos en modo CBC lo podemos observar en la gura 3.4, bsicaa mente es el mismo principio que para el cifrado de datos, donde el unico cambio son las entradas y salidas a las diferentes etapas del esquema de cifrado.

3.2

Plataforma elegida

En esta seccin se describe la opcin elegida para cada categor denida en la seccin 3.1. o o a o

3.2.1

Red Inalmbrica de Sensores a

La red inalmbrica de sensores que utilizaremos en este trabajo fue adquirida de la marca a Crossbow. Elegimos estos componentes por la arquitectura de sus nodos y la gran variedad de sensores disponibles. Otro factor determinante fue la disponibilidad de la puerta 30

de enlace avanzada, que es una computadora empotrada que permite ejecutar el sistema operativo GNU/Linux, lo cual facilita la ejecucin de programas avanzados. o Los componentes que utilizaremos en este trabajo se describen a mayor detalle en la presente seccin. o Nodos: pertenecientes a la familia MICAZ de Crossbow, estos nodos estn compuestos a por un microcontrolador Atmel ATMEGA128, un radio digital Chipcon CC2420, antena y bater Este nodo se muestra en la gura 3.5. as.

Figura 3.5: Nodo MICAZ.

Puertas de enlace: se utilizaron tres modelos diferentes, todos ellos del fabricante Crossbow. Crossbow MIB520 : permite la programacin y conexin de un nodo MICAZ con una o o computadora personal a travs del bus serie universal. Esta puerta de enlace se muestra e en la gura 3.6.

Figura 3.6: Puerta de enlace MIB520.

Crossbow MIB600 : permite empotrar un nodo MICAZ, y permitir que el nodo se comunique a travs de un red Ethernet. Esta puerta de enlace se muestra en la gura 3.7. e 31

Figura 3.7: Puerta de enlace MIB600.

Crossbow NB100 : es una computadora empotrada que funciona bajo el sistema operativo GNU/Linux, cuenta con un procesador Intel XScale IXP420 a 266 Mhz, 32MB de memoria de acceso aleatorio (RAM), memoria ash de 8MB, conectividad USB 2.0, red Ethernet 10/100, puerto serial. Esta puerta de enlace se muestra en la gura 3.8.

Figura 3.8: Puerta de enlace NB100.

Tarjeta de sensores Crossbow MDA100 : se utiliz esta tarjeta para poder interconectar o el modulo de lectura de RFID a travs del area destinada a prototipos. Esta tarjeta de e sensores se puede observar en la gura 3.9.

Figura 3.9: Tarjeta de sensores MDA100.

Tarjeta de sensores Crossbow MTS420CC : se utiliz esta tarjeta para tener un receptor o del sistema de posicionamiento global (GPS ) y los siguientes sensores: humedad, temperatura, iluminacin, aceleracin, presin. Est tarjeta de sensores se puede observar en la o o o a 32

gura 3.10

Figura 3.10: Tarjeta de sensores MTS420CC.

Sensores adicionales: en este trabajo se presenta el desarrollo de controladores de dispositivo para diferentes sensores, uno de ellos es un modulo de lectura RFID, como el que se presenta en la gura 3.11.

Figura 3.11: Modulo de lectura RFID.

3.2.2

Software empotrado

En este trabajo elegimos como lenguaje de programacin para aplicaciones empotradas a o nesC, dado que permite una programacin sencilla y exible compatible entre una gran o variedad de hardware para redes inalambricas de sensores, adems de ser un lenguaje muy a utilizado para este tipo de tareas. Un punto de gran importancia para ser elegido es la amplia documentacin disponible de este lenguaje [46]. Al haber elegido a nesC como el o lenguaje de programacin para est categor elegimos por consecuencia a TinyOS como o a a, el sistema operativo para los nodos.

33

Para el caso de la puerta de enlace avanzada, la cual se ejecuta sobre la computadora empotrada Crossbow NB100 el lenguaje de programacin utilizado es el lenguaje C. Dao do que la arquitectura de la computadora empotrada es diferente a la arquitectura de la computadora de desarrollo es diferente, debemos de utilizar un compilador cruzado para la arquitectura destino, en este caso ARM. En el anexo A, se explica en mayor detalle del proceso de instalacin del compilador cruzado bajo el sistema operativo GNU/Linux. o

3.2.3

Software de aplicacin o

El servidor de almacenamiento y de consulta, se disearon sobre una computadora de esn critorio con el sistema operativo GNU/Linux con el servidor Web Apache, base de datos MySQL e intrprete de PHP. Se realiz esta eleccin por ser una combinacin bastante e o o o utilizada hoy en d [45], y que adems en su totalidad est basada en software libre, con a a a resultados bastante aceptables.

3.2.4

Algoritmos de cifrado

Como se mencion en la seccin 3.1.4, la utilizacin de algoritmos de cifrado asimtricos o o o e no ser contemplada para dispositivos con restricciones en capacidad de cmputo, por lo a o tanto la unica eleccin factible es la criptograf simtrica. Dentro de los sistemas de ci o a e frado simtrico, una buena eleccin es escoger el algoritmo AES como sistema de cifrado, e o adems de que el radio digital CC2420 utilizado en los nodos que anteriormente hemos a elegido posee un cifrador AES por hardware, lo cual permite que el cifrado se realize de forma eciente. Sin embargo, aun cuando disponible este sistema de cifrado en hardware, al momento de la realizacin de este trabajo no exist la biblioteca o funcin para hacer o a o uso de este, tal y como se describe en la seccin 5.2.1. o El modo de operacin CBC fue escogido ya que con este podemos cifrar varios bloques o de datos de forma encadenada, lo cual permite que un mismo texto en claro resulte en un texto cifrado diferente, adems de que podemos obtener una cdigo de autenticacin de a o o mensaje al agregar un nuevo bloque al nal de los bloques de datos, todo esto ejecutndoa se sin agregar tiempos signicativos de procesamiento.

34

3.2.5

Otros

Finalmente, como parte de los equipos de pruebas, hicimos uso de un analizador lgico o para poder observar las seales digitales generadas por los nodos cuando se comunican n con las tarjetas de sensores. Este tipo de herramientas son de gran utilidad ya que nos permite ver el comportamiento de mltiples seales digitales en un intervalo de tiempo. u n Sin estas herramientas ser imposible ver el comportamiento de dichas seales y por lo a n tanto el proceso de depuracin de los programas ser bastante tedioso. o a

35

36

Cap tulo 4 Arquitectura

En este cap tulo se presenta el anlisis y diseo del mecanismo seguro de recoleccin de a n o datos. En la primera seccin, correspondiente al anlisis, se describen los requerimientos o a que el mecanismo de recoleccin debe cumplir, despus en la segunda seccin se propone o e o una arquitectura de recoleccin, se denen el paquete de datos, los tipos de nodos y los o tipos de datos, se detalla el procedimiento de reenv de paquetes y nalmente se describe o el diseo de cada uno de los elementos propuestos en la arquitectura de recoleccin. n o

4.1

Anlisis a

En esta seccin identicamos y describimos los parmetros de funcionamiento deseados o a para el mecanismo de recoleccin. Este anlisis es de gran importancia ya que nos sero a vir para poder realizar un diseo adecuado y funcional. a n El mecanismo de recoleccin presentado en este trabajo tiene la nalidad de leer dao tos provenientes de sensores para su posterior reenv a otros nodos con el objetivo de o alcanzar un servidor de almacenamiento y as permitir que aplicaciones que ocupen pro cesos de recoleccin de datos puedan ser fcilmente implementadas por ingenieros y/o o a cient cos que no son expertos en el rea de redes inalmbricas de sensores. Trabajos a a similares a estos se han implementado bajo otras arquitecturas y tecnologias [41] [42], sin embargo no han considerado proporcionar servicios de seguridad para las comunicaciones.

37

Este trabajo retoma algunas de las ideas presentados en los trabajos similares a este y las extiende para dar forma al mecanismo seguro de recoleccin de datos con nodos o mviles en redes inalmbricas de sensores. o a

4.1.1

Requerimientos

Los principales requerimientos que deber cumplir el mecanismo de recoleccin son los a o siguientes: Almacenamiento temporal. La informacin recolectada por los nodos de lectura deo ber ser almacenada de forma temporal en caso de que no haya sido transmitida inmea diatamente despus de haber sido recolectada. Los nodos debern tener la capacidad de e a proveer almacenamiento no voltil, este almacenamiento ser de utilidad cuando las baa a ter se agoten. as Diversidad de sensores. El mecanismo de recoleccin deber tener la capacidad de adapo a tarse a un amplio tipo de escenarios y/o aplicaciones, por lo tanto ste deber ser capaz de e a transportar datos recolectados por cualquier tipo de sensor. En caso de que exista algn u otro tipo de dato este se deber poder agregar al mecanismo de recoleccin. a o Escalabilidad. Los nodos podrn entrar o salir en cualquier momento de la red, por lo a que unirse o separarse del mecanismo de recoleccin deber ser lo ms sencillo posible. Por o a a lo tanto, nuestra solucin deber ser capaz de hacer frente a este tipo de caracter o a sticas. A n de permitir la escalabilidad, el mecanismo de recoleccin deber incluir un procedio a miento de reenv de paquetes que ayudar a agregar ms nodos de sensores a la red. o a a Movilidad. La mayor de los nodos debern tener la facilidad de cambiar su posicin en a a o cualquier momento, por lo tanto debern ser operados a bater y dependiendo del tipo a as de nodo, debern tener un sistema de posicionamiento para registrar la posicin donde a o los datos fueron recabados.

38

Seguridad. Los datos recolectados y transmitidos debern viajar de forma segura por a la red de nodos inalmbricos, por lo tanto se aplicaran algoritmos criptogrcos. Los a a servicios de seguridad que debern ser soportados por el mecanismo de recoleccin son: a o condencialidad, autenticidad e integridad.

4.2

Dise o n

En esta seccin se presenta el diseo que se ha realizado en base a los requerimientos, o n esta es una arquitectura de recoleccin de datos que est compuesta por: nodos de leco a tura, nodos de reenv nodos de procesamiento, puertas de enlace (simple o avanzada), o, y servidores de almacenamiento. El esquema que presenta la arquitectura de recoleccin o diseada se muestra en la gura 4.1. n Adicionalmente a los componentes antes mencionados se contempla un servidor de consulta, es importante mencionar que este servidor de consulta no forma parte del mecanismo de recoleccin, sin embargo se incluye dentro de la propuesta para ilustrar que o el mecanismo de recoleccin funciona adecuadamente. Este servidor se congura acuerdo o a la aplicacin nal y se pueden agregar los que sean necesarios. o Esta arquitectura de recoleccin es de tipo jerrquico ya que fue diseada pensando en o a n que la informacin de los nodos circule desde los nodos con jerarqu ms baja (nodos de o a a lectura) hasta los nodos con jerarqu ms alta (nodos de procesamiento) y no en forma a a contraria. En las siguientes sub-secciones describimos detalladamente el funcionamiento de cada elemento de la arquitectura.

4.2.1

Paquete de datos

Los datos sensados por los nodos de lectura son utilizados para conformar un paquete de datos, como el que se describe en la gura 4.2. La estructura de este paquete de datos, es comn para todos los nodos y adems es genrica para todo tipo de aplicaciones. u a e

39

Figura 4.1: Arquitectura del mecanismo de recoleccin. o

La descripcin de cada campo se presenta a continuacin. El parmetro de Tiempo Vida o o a especica el nmero de saltos restantes o de intentos de reenv antes de que el paquete u o sea descartado. En segundo lugar, el parmetro Tipo Nodo indica el tipo de nodo que a origina el paquete de datos. Despus, el parmetro Tipo Datos dene el tipo de datos e a que transporta este paquete de datos. El cuarto lugar, tenemos al parmetro Identicaa dor Nodo Fuente este indica el identicador del nodo que origin el paquete de datos. o En quinto lugar est el parmetro Identicador Nodo Puerta el cual especica el identia a cador del nodo por donde el paquete se enlaza con otra red. Despus, en sexto lugar se e dene el parmetro conocido como Identicador Mensaje el cual almacena el identicador a unico del mensaje que se transporta. En sptimo lugar, tenemos el parmetro Datos el e a cual est destinado a guardar la informacin que se recolecta. Por ultimo, tenemos al a o parmetro Suma Vericacion el cual es un bloque utilizado para vericar la integridad y a autenticidad de los datos recolectados. Los campos indicados en negritas sern sometidos a a algoritmos criptogrcos para cifrar su contenido. a 40

1. typedef nx struct message sensor { 2. char Tiempo Vida; 3. char Tipo Nodo; 4. char Tipo Datos; 5. char Identicador Nodo Fuente; 6. char Identicador Nodo Puerta; 7. char Identicador Mensaje[2]; 8. char Datos A[13]; 9. char Datos B[13]; 10. char Datos C[17]; 11. char Suma Vericacion[16]; 10. } message sensor t;

Figura 4.2: Estructura del paquete de datos.

Los campos que no han sido cifrados viajan de esta forma ya que son necesarios para ejecutar el procedimiento de reenv de paquetes, si estos campos viajasen cifrados se o tendr que descifrar el paquete de datos para poder efectuar el reenv y actualizacin a o o a n del parmetro T iempo V ida, lo cual repercutir en el desempeo del sistema al tener que a ejecutar ms veces los algoritmos de cifrado y descifrado. a En el paquete de datos se encuentran cifrados un total de 64 bytes, formando 4 bloques de 16 bytes cada uno, ms 2 bytes sin cifrar, por lo tanto el tamao total del paquete de a n datos es de 66 bytes.

4.2.2

Tipos de nodos

De acuerdo a la arquitectura de recoleccin presentada en la gura 4.1 existen diversos o tipos de nodos. La tabla 4.1 muestra los tipos de nodos que se han denido, el campo Tipo de la tabla 4.1 corresponde con el campo Tipo Nodo del paquete de datos presentado en la seccin 4.2.1. o

41

Tipo Identicador NODO LECTURA 0x01 NODO REENVIO 0x02 NODO PROCESAMIENTO 0x03 Tabla 4.1: Tipos de nodos denidos.

4.2.3

Tipos de datos

Con el objetivo de cumplir el requerimiento de diversidad de sensores presentado en la seccin 4.1.1, el mecanismo de recoleccin tiene la capacidad de manejar diversos tipos o o de datos. En la tabla 4.2 se muestran los tipos de datos previamente denidos. Los tipos de datos reservados se apartan con el propsito de permitir que el mecanismo pueda ser o extendido a ms tipos de datos/sensores. a

Tipo GPS GPS + TEMPERATURA GPS + HUMEDAD GPS + TEMPERATURA + HUMEDAD GPS + RFID Reservados

Identicador 0x21 0x22 0x23 0x24 0x25 0x26-0x2F

Tabla 4.2: Tipos de datos denidos.

El campo Tipo de la tabla 4.2 corresponde con el campo Tipo Datos del paquete de datos denido en la seccin 4.2.1. o

4.2.4

Reenv de paquetes o

A continuacin se describe el procedimiento de reenv de paquetes, este procedimiento o o se ha denido con el objetivo de cumplir con el requerimiento de escalabilidad, ya que permite que ms nodos puedan agregarse al mecanismo de recoleccin sin necesidad de a o ser congurados previamente con una direccin fuente/destino en espec o co. Esto da la 42

facilidad de que cualquier tipo de nodo sea energizado y ste comience a capturar y se e una al mecanismo de recoleccin. o Los nodos de jerarqu ms baja (nodos de lectura) recaban datos a travs de sus sena a e sores, conforman paquetes de datos y los reenv a otros nodos de jerarqu ms alta an a a (nodos de reenv o nodos de procesamiento). De acuerdo a la arquitectura presentada con o anterioridad los nodos de lectura no pueden comunicarse con otros nodos de lectura. Los nodos de reenv van almacenando los paquetes recibidos y cuando es posible mandan o, estos paquetes a otros nodos de reenv o nodos de procesamiento. Finalmente, los nodos o de procesamiento estn conectados a una puerta de enlace (simple o avanzada), la cual a recibe el paquete de datos y se encarga de procesarlos para su posterior almacenamiento. Los paquetes de datos circulan desde los nodos de nivel ms bajo hasta los nodos de a nivel ms alto y no de forma contraria. Adems todos los nodos poseen mecanismos para a a desechar paquetes que ya han sido almacenados por mucho tiempo, a travs del parmetro e a de tiempo de vida, el cual especica el nmero mximo de saltos o de intentos de reenv u a o que un paquete puede permitir.

Figura 4.3: Esquema de reenv de paquetes. o

En la gura 4.3 podemos ver los nodos de lectura como los nodos de color azul, a los nodos de reenv como los de color verde y nalmente a los nodos de procesamiento como o los de color rojo.

43

4.2.5

Nodo de lectura

El primer elemento de la arquitectura de recoleccin presentada en la seccin 4.2 es el o o nodo de lectura. Este dispositivo de lectura se encuentra conformado por un nodo MICAZ en conjunto con una tarjeta de sensores MTS420CC que se interconectan entre s a travs e de los conectores de expansin presentes en ambos componentes, tal y como se ilustra en o la gura 4.4. El nodo de lectura y su tarjeta de sensado pueden recabar informacin de o humedad, temperatura, presin, luminosidad, aceleracin y posicin global. o o o

Figura 4.4: Nodo de lectura.

El nodo de lectura se comunica con los sensores a travs de interfaces de comunicacin e o seriales (s ncronas o as ncronas), tales como I2C, SPI, UART, ests interfaces de comua nicacin serial se describen a mayor detalle en el Anexo A en la pgina 92. El primer o a paso consiste en realizar la inicializacin del sensor a travs de los comandos destinados o e para ello, enviar una peticin y esperar una respuesta. Cuando se ha recibido la respuesta o del sensor se guarda para armar un paquete de datos y aplicar los algoritmos criptogrcos. a Este nodo se encarga de realizar lecturas de los sensores cada cierto intervalo de tiempo, conformar con los datos le dos un paquete de datos y nalmente realizar el cifrado de la informacin. Para realizar la funcin de cifrado se utiliza el cifrador simtrico AES en o o e modo de operacin CBC. Es importante recordar que la funcin de cifrado se ejecuta en o o hardware, espec camente en el circuito integrado CC2420 presente en todos los nodos. Para mayor detalle acerca de los diferentes modos de operacin del cifrador AES consulte o 44

la seccin 3.1.4. o

4.2.6

Nodo de reenv o

El segundo elemento de la arquitectura de recoleccin presentada en la seccin 4.2 es el o o nodo de reenv Este nodo se encarga de recibir paquetes de datos provenientes de nodos o. de lectura o nodos de reenv es decir de nodos de menor jerarqu ya que ha recibido o, a, el paquete de datos lo intenta reenviar a otro nodo de igual o mayor jerarqu sino tiene a, nodo alguno a su alcance conserva el paquete de datos para intentar reenviarlo posteriormente, por cada intento de reenv se descuenta una unidad a la mtrica de tiempo de o e vida. Cuando se ha enviado el paquete de datos, lo elimina de su memoria para liberar el espacio ocupado. Este tipo de nodo no hace uso de las tarjetas de sensores ni de elementos adicionales.

4.2.7

Nodo de procesamiento

El tercer elemento de la arquitectura de recoleccin presentada en la seccin 4.2 es el o o nodo de procesamiento. Este nodo se encarga de recibir paquetes de datos v radio y a los reenv a una puerta de enlace (simple o avanzada) para que los paquetes puedan ser a procesados. Debido al poder de cmputo necesario y a la gran cantidad de paquetes que o un nodo de procesamiento puede recibir, este nodo no ejecutar ningn tipo de funcin a u o adicional.

4.2.8

Puerta de enlace simple

El siguiente elemento de la arquitectura de recoleccin presentada en la seccin 4.2 es la o o puerta de enlace, sta puede ser simple o avanzada. En esta seccin se presenta el diseo e o n de la puerta de enlace simple. Esta puerta de enlace se conecta con un nodo de procesamiento para realizar funciones bsicas de almacenamiento a los paquetes de datos recibidos. Dado su poder de cmputo a o limitado, este componente est imposibilitado para realizar funciones avanzadas i.e. funa ciones criptogrcas, por lo que solo se limita a realizar peticiones de almacenamiento a 45

al servidor correspondiente. La gura 4.5 muestra la estructura de una puerta de enlace simple.

Figura 4.5: Puerta de enlace simple.

Las peticiones de almacenamiento se efectan por medio del protocolo HTTP, como se u muestra en la gura 4.6.

http://servidor/almacena.php?bloque1=ww&bloque2=xx&bloque3=yy&bloque4=zz

Figura 4.6: Peticin de almacenamiento. o La puerta de enlace simple utilizar una puerta de enlace Crossbow MIB600, la cual a permite empotrar un nodo programado en nesC y congurarse para acceder a la red a travs de su puerto Ethernet. e

4.2.9

Puerta de enlace avanzada

En esta seccin se presenta el diseo de la puerta de enlace avanzada. Esta puerta de o n enlace se conecta con un nodo de procesamiento para realizar funciones avanzadas de procesamiento a los paquetes de datos recibidos. Una de sus tarea es la de realizar el 46

descifrado de datos, tal y como se observa en la gura 3.4, para posteriormente enviar una peticin de almacenamiento al servidor correspondiente. o La peticin de almacenamiento se efecta de la misma forma que en la seccin anterior. o u o Ver gura 4.6. Adems puede ejecutar otras funciones avanzadas tales como: compresin de datos, a o almacenamiento y consulta temporal, entre otras. La puerta de enlace avanzada utilizar una computadora empotrada Crossbow NB100, a la cual es capaz de ejecutar el sistema operativo GNU/Linux y ejecutar programas avanzados escritos en lenguaje C. La diferencia en hardware entre ambas puertas de enlace es signicativa, ya que para el caso de la puerta de enlace simple, solo es posible realizar conguraciones para iniciar conexiones a la red de forma automtica, mientras que en la puerta de enlace avanzada a es posible realizar programas completos en lenguaje C.

4.2.10

Servidor de almacenamiento

Este servidor tiene el propsito de almacenar los datos enviados por la puerta de enlace, o para tales nes contiene un motor de base de datos relacional. La manera en que recibe los datos desde la puerta de enlace es a travs de la ejecucin e o de un programa de pgina dinmica, el cual recibe los datos a travs de la URL y del a a e mtodo GET. e Al recibir los datos verica que el mismo mensaje no haya sido insertado anteriormente, esto lo verica mediante el identicador de mensaje y del cdigo de autenticacin de o o mensaje. Si este mensaje no ha sido guardado, lo inserta en la base de datos o en caso contrario lo descarta.

47

4.2.11

Servidor de consulta

Este servidor tiene el propsito de mostrar los datos almacenados posteriormente. Tiene o dos formas de consulta, a travs de una tabla o a travs de un mapa, que nos sirve para e e indicar donde han sido recolectados los datos. Como se ha mencionado anteriormente, el servidor de consulta no forma parte del mecanismo de recoleccin, solamente es utilizado con nes de vericacin de resultados. o o Este servidor es completamente dependiente de la aplicacin nal del mecanismo de o recoleccin. o

48

Cap tulo 5 Desarrollo

Este cap tulo trata sobre la implementacin del mecanismo de recoleccin. En la primera o o seccin, correspondiente a implementacin, se proporciona una descripcin detallada de o o o todos los componentes desarrollados. En la segunda y ultima seccin se presentan las o pruebas realizadas al sistema con sus correspondientes resultados. Adems se incluye la a descripcin de los problemas ms importantes que se presentaron al realizar este trabajo o a de tesis. Finalmente, se presenta algunos resultados adicionales como lo son 2 art culos publicados.

5.1

Implementacin o

En esta seccin se describen las implementaciones de cada uno de los componentes del o mecanismo de recoleccin. Comenzaremos por los nodos (de lectura, de reenv de proo o, cesamiento), luego trataremos las puertas de enlace (simple y avanzada) y por ultimo los servidores (de almacenamiento y de consulta).

5.1.1

Nodo de lectura

En esta seccin se explica la implementacin del primer componente de la arquitectura o o diseada en la seccin 4.2, componente mejor conocido como nodo de lectura. n o Recordemos que este tipo de nodo es una entidad encargada de realizar lecturas por medio de sus sensores integrados, de conformar un paquete de datos y de aplicar algorit49

mos criptogrcos para proveer servicios de seguridad. Este nodo es el de jerarqu mas a a baja dentro del mecanismo de recoleccin. o El nodo de lectura se ha modelado utilizando una mquina de estados nitos, como a la que se muestra en la gura 5.1. El primer estado consiste en realizar la lectura de los sensores, a travs de las funciones de lectura diseadas con tal objetivo, los siguientes e n cuatro estados realizan el cifrado de los datos en modo CBC, tal y como se explico en la seccin 4.2.5, nalmente se env el mensaje a travs del radio digital. o a e

Figura 5.1: Mquina de estados para el nodo de lectura. a

En la gura 5.2 observamos la estructura de la funcin que ejecuta el esquema de cifrado o CBC. El primer paso es realizar la operacin lgica XOR a los vectores aesT extoP lanoi o o y aesT emporal, el resultado es utilizado para cifrar el vector aesT extoP lanoi , despus e el vector aesT emporal adquiere el valor del vector aesT extoCif radoi , despus de esto la e secuencia se repite. Para el bloque 1, el vector aesT emporal se carga con el vector aesIV . En la gura 5.3 observamos la estructura de la mquina de estados anteriormente proa puesta. El primer estado consiste en la lectura de los sensores, mientras los cuatro estados siguientes son utilizados para generar la secuencia usada en el modo de operacin CBC o para el cifrado AES, en el ultimo estado el mensaje es enviado a travs del radio digital. e 50

1. aesT emporal aesIV ; 2. ejecuta{ 3. aesResultado xor(aesT extoP lanoi , aesT emporal); 4. resultado cif rar(aesResultado, aesT extoP lanoi , aesT extoCif radoi ); 5. aesT emporal aesT extoCif radoi ; 6. } mientras(resultado es diferente de CIFRADO SATISFACTORIO);

Figura 5.2: Implementacin del cifrado CBC. o Al nalizar la accin correspondiente a cada estado, es establecida la variable estadoSio guiente con el identicador del siguiente estado a ejecutar.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

si(estado es igual a LEE SEN SORES){ leeSensores(); estadoSiguiente CIF RA BLOQU E1; }sino si(estado es igual a CIF RA BLOQU E1){ cif raBloque(1); estadoSiguiente CIF RA BLOQU E2; }sino si(estado es igual a CIF RA BLOQU E2){ cif raBloque(2); estadoSiguiente CIF RA BLOQU E3; }sino si(estado es igual a CIF RA BLOQU E3){ cif raBloque(3); estadoSiguiente CIF RA BLOQU E4; }sino si(estado es igual a CIF RA BLOQU E4){ cif raBloque(4); estadoSiguiente EN V IA M EN SAJE; }sino si(estado es igual a EN V IA M EN SAJE){ enviaM ensaje(); estadoSiguiente LEE SEN SORES; }

Figura 5.3: Estructura de la mquina de estados para el nodo de lectura. a

Controladores de dispositivo A continuacin se describe el proceso de escritura de nuevos controladores de dispositivo o para los nodos MICAZ. Primero, se describe la arquitectura de un nodo MICAZ, luego la forma en la que se interconectan los sensores al nodo, despus se discute de forma general e la utilizacin de cualquier sensor y nalmente se presenta el diseo de controladores de o n dispositivo para diferentes tres tipos de sensores. 51

La arquitectura de un nodo MICAZ se presenta en la gura 5.4. El componente principal del nodo es un microcontrolador Atmel ATMEGA128, este un procesador de 8 bits, posee arquitectura RISC, y es capaz de ejecutar una instruccin por ciclo de reloj. Tiene o 128KB de memoria ash (memoria de programa), tiene una memoria RAM de 4KB y una memoria EEPROM de 4KB. Este procesador tiene entradas y salidas digitales, un convertidor analgico - digital de 10 bits con 8 canales, adems tiene interfaces de comunicacin o a o seriales como I2C, SPI y UART. El segundo componente ms importante de este nodo a es el radio digital CC2420, el cual es utilizado para las comunicaciones inalmbricas del a nodo. Es interconectado con el nodo a travs una interfaz de comunicacin serial s e o ncrona como SPI. Por ultimo tenemos una memoria de almacenamiento no voltil de 512 KB. a

Figura 5.4: Arquitectura del nodo MICAZ

Uno de los factores ms importantes al interconectar un sensor a un microprocesador es a la interfaz mediante la cual se comunicaran, hoy en d existen una gran variedad, ya sea a de formato serial o paralelo, s ncrono o as ncrono, estndares o propietarias, entre otras. a Dado que la interconexin juega un papel fundamental para el desarrollo de controladores o de dispositivo en la seccin A.4 se describen de manera breve las principales interfaces de o comunicacin presentes en un nodo MICAZ utiles para efectuar un enlace de datos con o una unidad de sensado. 52

Tarjeta de sensado Crossbow MTS420CC.

La tarjeta MTS420CC de Crossbow, es una tarjeta de sensado que contiene: Receptor GPS marca UBLOX mod. LEA-4A [11]. Sensor de humedad y temperatura marca Sensirion mod. SHT11 [12]. Sensor de presin baromtrica y temperatura marca Intersema mod. MS5534C [17]. o e Sensor de luz marca TAOS mod. TLS2550 [18]. Acelermetro de 2 ejes marca Analog Devices mod. ADXL202JE [13]. o Debido a la gran diversidad de sensores presentes, el consumo de potencia de esta tarjeta puede ser bastante elevado, por lo tanto cuenta con 2 interruptores electrnicos de o 8 canales cada uno. Los interruptores electrnicos son de la marca Analog Devices y el o modelo es ADG715 [14]. Estos dispositivos se interconectan al nodo mediante la interfaz I2C. Los canales de los interruptores electrnico se detallan en la tabla 5.1. o

Canal 1 2 3 4 5 6 7 8

Seal (U7) n LIGHT POWER PRESSURE POWER HUMIDITY POWER EEPROM POWER ACCEL POWER GPS POWER GPS ENABLE

Canal 1 2 3 4 5 6 7 8

Seal (U9) n GPS RX GPS TX PRESSURE SCLK PRESSURE DIN PRESSURE DOUT HUMIDITY SCK HUMIDITY DATA

Tabla 5.1: Seales del interruptor electrnico U7 y U9 n o

Los interruptores electrnicos estn denotados por U7 el cual posee la direccin 0x48 o a o y por U9 el cual posee la direccin 0x49. Para activar el modulo GPS es necesario seguir o la siguiente rutina de inicializacin, primero hay que activar los canales GPS ENABLE o y GPS POWER enviando el dato 0x80 a la direccin del circuito integrado U7, despus o e hay que activar los canales GPS RX y GPS TX enviando el dato 0x03 a la direccin del o 53

circuito integrado U9 tal y como se muestra en la gura 5.5, la cual contiene el segmento de cdigo en nesC que inicializa el mdulo GPS. o o

1. if (estado == ENERGIA_GPS) { 2. Energia[0] = 0x80; 3. if (call I2C.write(START|STOP,0x48,1,Energia)==SUCCESS){ 4. atomic { 5. estado = DATOS_GPS; 6. } 7. } 8. } else if (estado == DATOS_GPS) { 9. Datos[0] = 0x03; 10. if (call I2C.write(START|STOP,0x49,1,Datos)==SUCCESS){ 11. atomic { 12. estado = FIN_GPS; 13. } 14. } 15. } else if (estado == FIN_GPS) { 16. atomic { 17. estado = FIN_INICIALIZACION; 18. } 19. wait(); 20. call MilliTimer.startPeriodic(1); 21. } Figura 5.5: Segmento de cdigo en nesC que inicializa el modulo GPS o En la gura 5.6 se muestra la captura de las seales SDA y SCL realizada con un anan lizador lgico, podemos ver que la ejecucin del segmento de cdigo anterior es vlida, ya o o o a que despus de cada peticin recibimos la seal de reconocimiento (ACK ) por parte del e o n perifrico. e El siguiente paso para la realizacin del controlador es interpretar la informacin recio o bida el modulo GPS, de acuerdo a las especicaciones del fabricante este dispositivo de posicionamiento global genera sus respuestas en base al estndar NMEA 0183, entre otros. a Este estndar es una combinacin de una especicacin a nivel elctrico con una especia o o e cacin para el intercambio de datos entre dispositivos electrnicos, en especial mar o o timos. Los datos son transmitidos desde un emisor a mltiples receptores por medio protocolo de u comunicacin serial basado texto en ASCII. En la capa de aplicacin el estndar tambin o o a e 54

Figura 5.6: Inicializacin del modulo GPS vista en un analizador lgico. o o

dene el contenido de cada tipo de mensaje para que los receptores puedan interpretarlo correctamente. Un ejemplo de los mensajes generados en formato NMEA 0183 por este receptor GPS se pueden observar en la gura 5.7.

$GP GSV, 2, 1, 07, 23, 02, 284, , 22, 32, 126, 41, 14, 26, 054, 37, 03, 01, 197, 78 $GP GSV, 2, 2, 07, 26, 05, 074, 25, 16, 34, 164, 47, 31, 62, 006, 37 4F $GP GLL, 1932.98922, N, 09913.25898, W, 033153.00, A, A 71 $GP ZDA, 033153.00, 09, 01, 2010, 00, 00 6A $GP RM C, 033154.00, A, 1932.98922, N, 09913.25901, W, 0.009, , 090110, , , A 6E $GP V T G, , T, , M, 0.009, N, 0.016, K, A 2D $GP GGA, 033154.00, 1932.98922, N, 09913.25901, W, 1, 04, 4.04, 2293.0, , , , , 68 $GP GSA, A, 3, 22, 14, 16, 31, , , , , , , , , 7.97, 4.04, 6.87 02

Figura 5.7: Ejemplo de mensajes generados por el GPS en formato NMEA 0183 A continuacin, en la gura 5.8 observamos el cdigo fuente en nesC que es capaz de o o reconocer el mensaje de tipo $GPGGL. El segmento de cdigo mostrado con anterioridad reconoce el mensaje de de tipo $GPo GLL, donde este mismo esquema se puede aplicar para todos los mensajes enviados por el modulo de posicionamiento global. En las primeras tres l neas, reconoce que se trata de un mensaje con terminacin GLL, a partir de este punto comienza a leer los datos recibidos o y los almacena dentro de las localidades de memoria destinada para el dato de Latitud, esto ocurre hasta que recibe un delimitador de campo, en esta ocasin representado por o el s mbolo coma. Despus se adquiere el dato correspondiente a Longitud (no mostrado e 55

1. if (GPS_Message[GPS_Counter+2] == G){ 2. if (GPS_Message[GPS_Counter+3] == L){ 3. if (GPS_Message[GPS_Counter+4] == L){ 4. GPS_Counter = GPS_Counter + 6; 5. GPS_tLatitud_counter = 1; 6. while (GPS_Message[GPS_Counter] != ,){ 7. GPS_tLatitud[GPS_tLatitud_counter] = 8. GPS_Message[GPS_Counter]; 9. GPS_Counter = GPS_Counter + 1; 10. GPS_tLatitud_counter = 11. GPS_tLatitud_counter + 1; 12. } 13. GPS_Counter = GPS_Counter + 1; 14. if (GPS_Message[GPS_Counter] == N) { 15. GPS_tLatitud[0] = +; 16. else if (GPS_Message[GPS_Counter] == S){ 17. GPS_tLatitud[0] = -; 18. } 19. while (GPS_Message[GPS_Counter] != ,){ 20. GPS_Counter = GPS_Counter + 1; 21. } 22. } 23. } 24. } Figura 5.8: Segmento de cdigo en nesC que interpreta el mensaje $GPGLL proveniente o del modulo GPS en el cdigo anterior). El resto de los campos y mensajes se pueden procesar de la misma o manera en que se ha procesado el presente mensaje. A continuacin se describe la implementacin realizada para poder utilizar el sensor o o de humedad Sensirion mod. SHT11. Este sensor est presente en la tarjeta Crossbow a MTS420CC y se conecta al nodo MICAZ a travs de una interfaz serial s e ncrona, la cual no es ninguna de las descritas en la seccin A.4. En este caso tenemos una interfaz proo pietaria, que sigue un protocolo de comunicacin mostrado en la gura 5.9. o

56

Figura 5.9: Protocolo de comunicacin para el sensor de humedad. Imagen original [12]. o

El primer paso para iniciar comunicacin este sensor es generar una secuencia de inicio o lo cual se logra, llevando la seal CLK a alto, luego asignando la seal DATA a bajo, n n enseguida completando el ciclo de reloj e iniciando uno nuevo, despus llevando la seal e n DATA con valor alto y nalmente terminando el segundo ciclo de reloj. El siguiente paso, es enviar la direccin y el comando al sensor. La direccin consta de o o 3 bits y en este caso corresponden a 000, por lo cual tendremos que generar tres ciclos de reloj y en cada uno de ellos enviar bit a bit la direccin necesario, dado que los 3 bits o son igual a 0, la seal DATA no sufrir cambios durante el env de los tres ciclos de reloj. n a o Para enviar el comando se hace de la misma forma que con el env de la direccin, o o sin embargo como aqu si tenemos bits iguales a 1, en el correspondiente ciclo de reloj debemos llevar la seal DATA al valor de 1 regresarlo al valor de 0 al nalizar el ciclo n de reloj. Al siguiente ciclo de reloj recibiremos una secuencia de ACK, para avisarnos que el sensor ha recibido la direccin y el comando, esta secuencia es lograda por el sensor o llevando la seal DATA a valor bajo durante un ciclo de reloj. n
2

57

Despus de haber completado la secuencia descrita en el prrafo anterior debemos espee a rar a que el sensor realice la medida, que para 12 bits el tiempo de espera es de aprox. 80 ms. Mientras el sensor se encuentra tomando la medida de humedad, lleva la seal DATA n a valor alto, enseguida de que ha terminado de tomar la medida de humedad, el sensor lleva la seal DATA a valor bajo. Para realizar la lectura, se deben enviar 16 seales de n n reloj, donde las cuatro primeras no son utilizadas y las 12 restantes se ocupan para leer el dato de humedad en cada ciclo de reloj. Por cada byte recibido de datos se debe generar la secuencia de ACK. El siguiente paso, el cual es opcional, consiste en leer del sensor la suma de vericacin del valor leido anteriormente, con el n de vericar que existan o errores en la transmisin de los datos. o En la gura 5.10 se muestra la rutina SecuenciaInicio la cual es utilizada para informar al sensor que debe iniciar una nueva lectura. Despus, en la gura 5.11, se muestra la e rutina EnviaDireccion utilizada para enviar la direccin al sensor, la implementacin de o o la rutina EnviaComando no se muestra ya que es muy similar a la rutina EnviaDireccion. 1. void SecuenciaInicio () { 2. call HumiditySCK.set(); 3. call HumidityDATA.clr(); 4. call HumiditySCK.clr(); 5. call HumiditySCK.set(); 6. call HumidityDATA.makeInput(); 7. call HumiditySCK.clr(); 8. call HumidityDATA.makeOutput(); 9. call HumidityDATA.clr(); }

espera(); espera(); espera(); espera(); espera(); espera();

Figura 5.10: Implementacin de la rutina SecuenciaInicio para el sensor SHT11. o

1. 2. 3. 4. 5. 6. 7.

void EnviaDireccion() { call HumiditySCK.set(); call HumiditySCK.clr(); call HumiditySCK.set(); call HumiditySCK.clr(); call HumiditySCK.set(); call HumiditySCK.clr();

espera(); espera(); espera(); espera(); espera(); espera(); }

Figura 5.11: Implementacin de la rutina EnviaDireccion para el sensor SHT11. o 58

En la gura 5.12 se muestra la rutina LeeBit, la cual es utilizada para leer un bit datos, sta rutina es principalmente utilizada por la rutina LeeSensor, mostrada en la gura e 5.13, para leer el dato de humedad generado por el sensor y para la rutina LeeCRC (no mostrada), que lee el cdigo CRC-8 que env el sensor. o a

1. uint8_t leeBit(){ 2. uint8_t Bit; 3. call HumiditySCK.clr(); 4. Bit = call HumidityDATA.get(); 5. call HumiditySCK.set(); 6. call HumiditySCK.clr(); 7. return Bit; }

espera(); espera(); espera();

Figura 5.12: Implementacin de la rutina LeeBit para el sensor SHT11. o

1. void LeeSensor(){ 2. leeBit(); leeBit(); leeBit(); leeBit(); 3. bit = leeBit() * 2048; mHumedad += bit; 4. bit = leeBit() * 1024; mHumedad += bit; 5. bit = leeBit() * 512; mHumedad += bit; 6. bit = leeBit() * 256; mHumedad += bit; 7. wait(); sendACK(); wait(); 8. bit = leeBit() * 128; mHumedad += bit; 9. bit = leeBit() * 64; mHumedad += bit; 10. bit = leeBit() * 32; mHumedad += bit; 11. bit = leeBit() * 16; mHumedad += bit; 12. bit = leeBit() * 8; mHumedad += bit; 13. bit = leeBit() * 4; mHumedad += bit; 14. bit = leeBit() * 2; mHumedad += bit; 15. bit = leeBit() * 1; mHumedad += bit; } Figura 5.13: Implementacin de la rutina LeeSensor para el sensor SHT11. o

59

Lector de RFID En esta seccin se describe la incorporacin de un lector de radio frecuencia a un nodo o o MICAZ para generar un nodo de lectura con capacidad de adquirir datos v RFID. a Se utiliz un lector de baja frecuencia de la marca Texas Instruments modelo MRD1. o Este componente lee los identicadores de RFID que se encuentran cercanos al area de la antena y env los datos adquiridos por un enlace serial (congurado como 8N1@9600bps) a al nodo responsable de controlar los dispositivos sensores. Los identicadores (o tambin e conocidos como etiquetas) son reconocidos por el lector de RFID al ser aproximados al area de lectura, estos identicadores son de tipo pasivo y tienen un nmero unico de 64 u bits. La conexin se realiz mediante el puerto serie del nodo MICAZ y el puerto serie preo o sente en el lector de RFID. Un punto importante a destacar, es que el nodo MICAZ maneja un voltaje de alimentacin de 3V, mientras que el lector de RFID maneja un o voltaje de alimentacin de 5V, por lo tanto para que los componentes se puedan intercoo nectar es necesario hacer una conversin de voltajes entre las seales que manejan estos o n componentes. El lector de RFID debe recibir como seal de entrada, una seal codicada serialmente n n con nivel de voltaje de 5V, pero la seal de TX del nodo MICAZ es de 3V, sin embargo n la conexin se puede efectuar ya que el valor de 3V es reconocido como un valor lgico de o o estado alto (1) por el lector de RFID. La seal que hay que adaptar es la transmisin n o (TX ) del modulo de lectura RFID, o tambin se puede ver como la seal de recepcin e n o (RX ) del nodo MICAZ. El acoplamiento entre dispositivos se realiz mediante un circuito o resistivo, mostrado en la gura 5.14, en su conguracin divisor de voltaje, este circuito o recibe a su entrada 5V y a la salida produce 3V. La conexin entre el nodo MICAZ y el modulo lector de radio frecuencia se realiz a o o travs de una tarjeta de sensores MDA100, como la mostrada en la gura 3.9. Esta tarjeta e de sensores tiene la distribucin de terminales mostrada en la tabla 5.2 o

60

Figura 5.14: Circuito utilizado para adaptar los niveles de voltaje.

A 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 GND OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN GND OPEN OPEN OPEN

B GND OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN OPEN GND OPEN OPEN OPEN

E VCC ADC2 ADC1* ADC0 THERM PWR THRU1 THRU2 RSTN RSTN PWM1B OPEN OPEN OPEN VCC OPEN OPEN OPEN

F VCC PW0 PW1* PW2 PW3 PW4 PW5 PW6 ADC7 ADC6 ADC5 ADC4 ADC3 VCC OPEN OPEN OPEN

GND VCC USART1 CK INT3 UART0 RX INT2* UART0 TX INT1 SPI SCK INT0 USART1 RX BAT MON USART1 TX LED3 I2C CLK LED2 I2C DATA LED1 PWM0 RD PWM1A WR AC+ ALE ACPW7 GND VCC OPEN OPEN OPEN OPEN OPEN OPEN

Tabla 5.2: Distribucin de terminales en la tarjeta de o sensores MDA100.

61

La comunicacin con el lector de radio frecuencia se basa en el principio de peticin o o - respuesta, es decir para obtener datos desde el equipo lector, el nodo debe enviar un comando de peticin, esperar un determinado tiempo y leer la respuesta enviada por el o modulo de lectura. La tabla 5.3 muestra la estructura del comando de lectura que el nodo debe generar.

Byte Valor 0 1 2 3 4 0x01 0x02 0x08 0x32 0x38

Comentario

Descripcin o

Byte de inicio * Longitud Dos bytes siguientes excepto el ultimo. Comando(1) Ejecuta un comando y un periodo de carga. Datos(1) Duracin del periodo de carga I: 50 ms. o Suma de vericacin XOR a los bytes anteriores excepto el primero. o Tabla 5.3: Peticin para leer un identicador [19]. o

A continuacin, la tabla 5.4 muestra la estructura del comando devuelto por el modulo o lector cuando ha procesado una peticin de lectura y ha encontrado un identicador cero cano al area de lectura.

Byte Valor 0 1 2 3 4 5 6 7 8 9 10 11 0x01 0x09 0x0C 0x64 0x58 0x4C 0x00 0x00 0x00 0x00 0x00 0x7B

Comentario

Descripcin o

Byte de inicio * Longitud 9 bytes siguiente excepto el ultimo. Estado Identicador solo lectura valido. Datos(1) Datos de identicacin (LSB ). o Datos(2) Datos de identicacin. o ... ... ... ... ... ... ... ... Datos(7) Datos de identicacin. o Datos(8) Datos de identicacin (MSB ). o Suma de vericacin XOR a los bytes anteriores excepto el primero. o Tabla 5.4: Respuesta del modulo de lectura cuando se ha encontrado un identicador [19]. 62

Por ultimo, la tabla 5.5 muestra la estructura del comando devuelto por el modulo lector cuando ha procesado una peticin de lectura y no se ha encontrado un identicador o cercano al area de lectura.

Byte Valor 0 1 2 3 0x01 0x01 0x03 0x02

Comentario

Descripcin o

Byte de inicio * Longitud Un byte despus excepto el ultimo. e Estado Otro, no hay byte de inicio. Suma de vericacin XOR a los bytes anteriores excepto el primero. o Tabla 5.5: Respuesta del modulo de lectura cuando no se ha encontrado un identicador [19].

La gura 5.15 muestra la implementacin del comando mostrado en la tabla 5.3. o 1. event void Temporizador.fired() { 2. char peticionLectura[5]={0x01,0x02,0x08,0x32,0x38}; 3. call UartStream.send(peticionLectura,5); 4. } Figura 5.15: Implementacin de la peticin de lectura. o o

5.1.2

Nodo de reenv o

El segundo componente implementado de la arquitectura diseada y mostrada anteriorn mente es el nodo de reenv El propsito de este tipo de nodos es de recibir paquetes de o. o datos desde nodos de jerarqu ms baja o igual, vericar que estos paquetes aun sean a a vlidos, y reenviarlos a nodos de jerarqu igual o mayor. a a La implementacin del nodo de reenv se basa principalmente en el evento de recepcin o o o de mensaje, al ocurrir este evento, se recibe el mensaje, se checan los campos de tipo de mensaje y tiempo de vida del mensaje y se reenv el mensaje si procede, en caso contrario a el mensaje se descarta.

63

El pseudocdigo mostrado en la gura 5.16 implementa la funcionalidad antes mencioo nada.

1. evento mensaje t* recibe (mensaje t T emp, void Datos, entero T amano) { 2. 3. mensaje M ensajeRecibido Datos; 4. 5. T ipoN odo M ensajeRecibido.T ipo N odo; 6. T iempoV ida M ensajeRecibido.T iempo V ida; 7. 8. si (T iempoV ida 1 es mayor que 0) { 9. si(T ipoN odo es igual a N ODO LECT OR o 10. T ipoN odo es igual a N ODO REEN V IO) { 10. mensaje M ensajeEnviar; 11. M ensajeEnviar M ensajeRecibido; 12. M ensaje LIST O; 13. } 14. } 15. regresa T emporal; 16. }

Figura 5.16: Implementacin del evento recibe. o

Adems se hace uso de un temporizador para enviar el mensaje previamente prepaa rado para reenv tal y como se muestra en la gura 5.17. Cuando el mensaje ha sido o, correctamente procesado por el evento de mensaje recibido se genera una seal para que n al completar un temporizador ste sea enviado. e

Al entrar a la rutina que procesa el evento completado del temporizador se intenta enviar los mensajes que han sido almacenados, despus en caso de tener mensajes listos e para ser enviados se procede a ejecutar la rutina que realiza el env del mensaje, en caso o de que un mensaje no se haya podido enviar satisfactoriamente, ste se almacena para su e posterior difusin. o

64

1. evento temporizador.completado() { 2. si (Mensaje es igual a LISTO) { 3. enviaMensajesPendientes(); 4. si (Radio.Envia() es igual a EN V IADO) { 4. Enviado V ERDADERO; 5. } sino { 4. Enviado P EN DIEN T E; 7. almacenaM ensaje(); 8. } 6. } 7. }

Figura 5.17: Implementacin del evento completado para el temporizador. o

5.1.3

Nodo de procesamiento

El tercer componente implementado de la arquitectura de recoleccin de datos es el nodo o de procesamiento. El propsito de este tipo de nodos es de recibir paquetes de datos proo venientes de nodos de reenv Al recibir estos paquetes desde los nodos de reenv los o. o, direcciona inmediatamente a una puerta de enlace (simple o avanzada). Dependiendo del tipo de puerta de enlace es el procesamiento que se realiza.

Al igual que en el nodo de reenv presentado en la seccin anterior, este componente o, o basa su implementacin en el evento de recepcin de mensaje. Al activarse este evento, o o se recibe el mensaje y se env a la puerta de enlace avanzada en formato de cadena de a texto, con los bloques separados por comas.

La estructura del evento recibe se muestra en la gura 5.18. Al entrar al evento generado por la recepcin de un mensaje, lo primero que se hace es recuperar el mensaje o recibido, despus ste se divide en 4 bloques de 16 bytes de longitud por bloque. Despus, e e e con los bloques recibidos se genera una peticin que se enviar a travs del puerto serial o a e del nodo de procesamiento a una puerta de enlace.

65

1. evento mensaje t* recibe (mensaje t T emp, void Datos, entero t T am) { 2. 3. mensajeM ensajeRecibido Datos; 4. 5. copia memoria(Bloque1, M ensajeRecibido, 16); 6. copia memoria(Bloque2, M ensajeRecibido, 16); 7. copia memoria(Bloque3, M ensajeRecibido, 16); 8. copia memoria(Bloque4, M ensajeRecibido, 16); 9. 10. generaP eticion(Datos); 11. U ART.envia(Datos, tamano(Datos)); 12. regresa T emp; 13. }

Figura 5.18: Implementacin del evento recibe para el nodo de procesamiento. o

5.1.4

Puerta de enlace simple

El cuarto componente implementado de la arquitectura de recoleccin de datos es la puero ta de enlace simple. El propsito de esta puerta es de procesar paquetes en conjunto con el o nodo de procesamiento para su posterior almacenamiento en un servidor remoto a travs e de una peticin basada en el protocolo HTTP. o Dado que las capacidades de cmputo de este tipo de dispositivos son limitadas, la o puerta de enlace simple solamente podr recibir paquetes y formular la peticin del almaa o cenamiento al servidor remoto, es decir no tiene la capacidad para hacer un procesamiento del paquete de datos recibido. Adems hay que recordar que la puerta de enlace simple a junto con el nodo de procesamiento es el punto de acceso para paquetes provenientes de los nodos de jerarqu ms baja, por lo que deseamos que est disponible para procesar a a e paquetes la mayor parte del tiempo. Para la implementacin de este componente se utiliz la puerta de enlace Ethernet, de la o o marca Crossbow, modelo MIB600, la cual est compuesta por un mdulo Ethernet modelo a o Micro de la marca Lantronix [16]. Este mdulo Micro, tiene un servidor y dos clientes o empotrados, uno para cada puerto serial, el cual se puede congurar como RS232, RS422 u RS485. El puerto serial 1 del mdulo Micro se encuentra directamente conectado a la o 66

interfaz UART del nodo MICAZ, mientras que el puerto serial 2 se encuentra conectado al programador de nodos, lo cual permite que la reprogramacin se haga de forma remota. o Para sta puerta de enlace utilizamos el puerto serial 1, el que se encuentra directae mente conectado a la UART del nodo MICAZ. El servidor remoto utilizado es http: //www.embedded.com.mx, al que le corresponde la direccin IP 216.108.239.146 en el o puerto 80. Se utiliz el modo autostart para iniciar automticamente una conexin de o a o datos. El env de la peticin remota, ya que se ha iniciado la conexin, se hace a travs o o o e de un programa en lenguaje PHP, utilizando el protocolo HTTP como medio de transporte. El formato de la peticin que se env cuando nos hemos conectado se muestra en o a la gura 5.19.

GET http://www.embedded.com.mx/almacenaSimple.php? bloque1=&bloque2=&bloque3=&bloque4= HTTP/1.0 Accept: */* Accept: text/html

Figura 5.19: Peticin de almacenamiento para puerta de enlace simple. o

La instruccin que se muestra en la gura 5.20, realiza el env de la peticin en el nodo o o o hacia el servidor remoto. Esto es mediante el env de la cadena de texto request por el o puerto serial.

1. UART.envia(peticion, tamano(peticion));

Figura 5.20: Env de peticin por el puerto serial. o o

67

5.1.5

Puerta de enlace avanzada

El quinto componente implementado de la arquitectura de recoleccin de datos es la puero ta de enlace avanzada. El propsito de esta puerta de enlace es de procesar paquetes en o conjunto con el nodo de procesamiento para su posterior almacenamiento en un servidor remoto a travs de una peticin basada en el protocolo HTTP. e o Dado que la puerta de enlace avanzada es capaz de ejecutar programas ms complea jos, como se describi en la seccin 3.2.1, tenemos una computadora empotrada la cual o o ejecuta el sistema operativo GNU/Linux. Esta computadora posee el procesador Intel XScale IXP420, el cual es totalmente compatible con el conjunto de instrucciones ARM V5T. Nuestra aplicacin para la puerta de enlace avanzada fue desarrollada en lenguaje C. o Dado que la arquitectura del equipo de desarrollo, x86 es nuestro caso, es diferente a la arquitectura de la computadora empotrada donde se ejecutar la puerta de enlace avana zada requerimos hacer uso del proceso de compilacin cruzada. o Esta puerta de enlace ser encargada de recibir paquetes de datos desde nodos de a procesamiento, ejecutar la funcin de descifrado sobre estos, conformar la peticin de alo o macenamiento y enviarla al servidor correspondiente. El formato de los datos que recibe la puerta de enlace avanzada se muestra en la gura 5.21.

BLOQUE1,BLOQUE2,BLOQUE3,BLOQUE4 Figura 5.21: Formato de los datos recibidos. La peticin de almacenamiento la podemos observar en la gura 5.22. o Finalmente, para enviar la peticin de almacenamiento se realiza a travs de una coo e nexin directa al servidor remoto por medio de un socket. La estructura del programa o que cumple con este propsito se muestra en la gura 5.23, el pseudocdigo mostrado o o en sta gura realiza el env de una peticin a un servidor remoto, est compuesto por e o o a una funcin llamada enviaPeticion, el cual toma 2 parmetros, el servidor remoto y o a la peticin a enviar. Despus, en las l o e neas de pseudocdigo 2 a 3, se crea el socket, si o ocurri un error la funcin termina aqu En la l o o , nea de pseudocdigo 4 se obtiene la dio 68

GET http://www.embedded.com.mx/almacenaAvanzado.php?latitud=&longitud= &altitud=&data=&nids=&nidg=&ntype=&dtype=&mid=&checksum HTTP/1.0 Accept: */* Accept: text/html

Figura 5.22: Peticin de almacenamiento para puerta de enlace avanzada. o reccin del servidor remoto al utilizar la funcin obtieneHost. Despus, entre las l o o e neas de pseudocdigo 6 y 7 se completan algunos parmetros de la conexin, i.e. tipo de socket, o a o direcciones, puertos. La conexin con el servidor remoto se ejecuta en la l o nea de pseudocdigo 8. Finalmente, se realiza la escritura de la peticin en la l o o nea de pseudocdigo 9. o

1. enviaPeticion(Servidor, P eticion) { 2. sock socket(...); 3. si(sock es menor a 0) regresa error; 4. servidor obtieneHost(Servidor); 5. si(servidor es igual a NULO) regresa error; 6. servidord.direccion servidor; 7. servidord.puerto 80; 8. si(conecta(sock, servidord, tamano(servidord)) es menor a 0) regresa error; 9. si(escribe(sock, peticion, tamano(peticion)) es menor a 0) regresa error; 10. }

Figura 5.23: Envio de datos al servidor remoto a travs de un socket. e

5.1.6

Servidor de almacenamiento

El sexto componente implementado de la arquitectura de recoleccin de datos es el servidor o de almacenamiento. El propsito de este servidor es proveer almacenamiento permanente o a los datos capturados por el mecanismo de recoleccin. En este servidor se encuentra un o programa en lenguaje PHP que se encarga de extraer los datos de la peticin originada o por la puerta de enlace, convertirlos al formato correcto y almacenarlos en una base de 69

datos MySQL. La estructura de la tabla Registros contenida en la base de datos principal se muestra en la tabla 5.6.

Campo ID LATITUD LONGITUD ALTITUD DATOS TIEMPO NIDS NIDG TIPON TIPOD MID CHECKSUM

Tipo int(11) texto texto texto texto tiempo texto texto texto texto texto texto

Nulo Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Valor por omisin o NULO NULO NULO NULO NULO ACTUAL NULO NULO NULO NULO NULO NULO

Comentarios Identicador del registro Datos del GPS Datos del GPS Datos del GPS Datos recolectados Hora de almacenamiento Nodo origen Nodo de entrada Tipo de nodo Tipo de paquete de datos Identicador del mensaje Suma de vericacin o

Tabla 5.6: Estructura de la tabla Registros.

La estructura del programa principal del servidor de almacenamiento se muestra en la gura 5.24, denominado almacena.php. Las l nea de pseudocdigo 1 y 2 muestran la o conexin al servidor remoto, en la l o nea de pseudocdigo 3 se reciben los datos provenieno tes del nodo de procesamiento, los datos del GPS se convierten de formato en la l nea 4, nalmente se realiza la peticin de almacenamiento en la l o nea de pseudocdigo 5. o

La ejecucin del programa anterior no genera respuesta alguna. Los programas y esqueo mas mostrados en esta seccin corresponden para la puerta de enlace avanzada, respecto o a los programas que se ejecutan para la puerta de enlace simple, siguen el mismo principio y estructura.

70

1. 2. 3. 4. 5.

conexion conecta bd(servidor, usuario, contrasena); seleccioma bd(basedatos, conexion); parametros P ARAM ET ROS HT T P ; convierte unidades GP S(); consulta(IN SERT A en TABLA (...) valores (parametros));

Figura 5.24: Pseudocdigo que recupera los datos de la peticin remota y los almacena. o o

5.1.7

Servidor de consulta

El sptimo componente implementado es el servidor de consulta. El propsito de este e o servidor es desplegar los datos capturados por el mecanismo de recoleccin de una foro ma clara y sencilla con el n de vericar que los datos generados por el mecanismo de recoleccin sean correctos. Para poder cumplir con su propsito este servidor ejecuta dos o o programas en lenguaje PHP. El primer programa, denominado consulta.php, extrae de la base de datos los registros almacenados y los presenta a travs de una pgina HTTP. La estructura de este programa e a es mostrada en la gura 5.25, las instrucciones mostradas en las l neas de pseudocdigo o 1 al 3 se utilizan para realizar la conexin a una base de datos y ejecutar una consulta. o Entre la l nea de pseudocdigo 4 y 8 se extraen los datos resultantes de la consulta y se o anexan a la pgina HTML que posteriormente ser mostrada por el navegador. a a El segundo programa, denominado mapa.php, el cual hace uso de la API de Google Maps, extrae los datos almacenados, toma la informacin geogrca y genera un mapa o a con la informacin. La estructura de este programa se muestra en la gura 5.26. En el o pseudocdigo mostrado la conexin y la consulta a la base de datos se realizan en las o o l neas de pseudocdigo 1 al 3, mientras que en las l o neas de pseudocdigo 6 al 8 se extraen o los registros de la base de datos y se insertan en la pgina generada. a

71

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

conexion conecta bd(servidor, usuario, contrasena); selecciona bd(basedatos, conexion); resultado consulta(SELECCION A DESDE T ABLA, conexion); si (la obtieneArreglo(resultado)){ imprime nombres de parmetros; a ejecuta{ imprime valores de parmetros; a } mientras ( la obtieneArreglo(resultado)); } sino { imprime La base de datos se encuentra vacia!; }

Figura 5.25: Estructura del programa que muestra los datos almacenados.

5.2

Pruebas y resultados

La implementacin descrita en este cap o tulo fue evaluada en un ambiente controlado y funcion como se esperaba. Las pruebas realizadas muestran que la distancia entre nodos o fue de 7 a 8 metros pero de acuerdo con otros experimentos realizados la distancia puede llegar a alcanzar ms de 15 m. Otros equipos transmitiendo y recibiendo en la misma a banda de frecuencia estuvieron operando al mismo tiempo (WiFi y Bluetooth) con signos menores de interferencia. Los controladores de dispositivo desarrollados(ver seccin 4.2.5, o pgina 44) han funcionado de manera adecuada. a Todos los componentes del mecanismo de recoleccin han sido probados de forma ino dividual y en conjunto. Primero, se han probado de forma individual para vericar que su funcin la desempean adecuadamente y segundo se han probado en conjunto pao n ra vericar que el mecanismo de recoleccin funciona como se ha planeado. Al tratarse o de nodos que ejecutan un programa empotrado y que no poseen una salida estndar es a complicado presentar el resultado de las pruebas ejecutadas en cada componente. Sin embargo, si es posible mostrar los resultados de las pruebas ejecutadas sobre el mecanismo de recoleccin, y por consecuencia asumimos que el funcionamiento de los componentes o es adecuado. En caso de que algunos componentes fallasen el mecanismo de recoleccin o dejar de funcionar y el error ser evidente. a a La forma en cmo podemos vericar los datos generados por el mecanismo de recoleccin o o 72

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

conexion conecta bd(servidor, usuario, contrasena); selecciona bd(basedatos, conexion); resultado consulta(SELECCION A DESDE T ABLA, conexion); si(f ila obtieneArreglo(resultado)){ Agrega encabezados necesarios para Google Maps ejecuta { Agrega puntos al mapa. }mientras(f ila obtieneArreglo(resultado)); } sino imprime La base de datos se encuentra vacia!; }

Figura 5.26: Estructura del programa que muestra los datos almacenados en un mapa.

es mediante la ejecucin de los programas residentes en el servidor de consulta. As por o ejemplo, la salida generada por el programa consulta.php se muestra en la gura 5.27. El programa mencionado anteriormente se encuentra almacenado en un servidor remoto y es accesible mediante la siguiente direccin: http://www.embedded.com.mx/consulta.php. o El otro programa que podemos ejecutar en el servidor de consulta es el llamado mapa.php el cual nos muestra en un mapa la informacin generada por el mecanismo de o recoleccin. La salida generada por este programa la podemos observar en la gura 5.28. o Adems para vericar que los servicios de seguridad funcionan adecuadamente se proa cedi a programar un nodo adicional, al cual llamamos Nodo Esp este nodo ejecuta o a un programa que se encuentra escuchando en modo continuo y desplegando los datos en pantalla (a travs de una puerta de enlace USB ). Con este nodo pudimos vericar que e los datos se cifraban correctamente bajo el modo de operacin CBC. o El tiempo que le toma al circuito integrado CC2420 cifrar un bloque de 16 bits es de aproximadamente 0.45 ms (incluyendo la escritura de la llave, del texto plano y la recuperacin del texto cifrado). Para conformar el esquema de cifrado CBC es necesario cifrar o 4 bloques y realizar operaciones lgicas adicionales. El tiempo que toma ejecutar una o funcin de cifrado en modo CBC es de aproximadamente 10.3 ms, esto es por que adems o a debemos considerar los retrasos de tiempo concernientes al sistema operativo, como son 73

Figura 5.27: Datos recolectados.

Figura 5.28: Mapa generado con los datos recolectados.

74

manejo de eventos, interrupciones, cambios de contexto, entre otros. Consideramos que realizando un mejor ejercicio de programacin este tiempo puede verse reducido a poco o ms de 8 ms. a

5.2.1

Problemas presentados y su solucin o

La tabla 5.7 muestra los problemas ms importantes que se presentan al realizar la tesis a y su respectiva solucin. o

Problema

Solucin o

Los controladores de dispositivo para Disear un controlador para la tarjeta n la tarjeta MTS420CC se encuentran MTS420CC para el mdulo de posicionamiento o incompletos. global GPS. Ver seccin 5.1.1. o

El programa de recepcin de datos o desarrollado para una computadora personal no se ha podido compilar para la puerta de enlace avanzada, ya que las librer utilizadas no as se pudieron generar para la arquitectura ARM.

Escribir un programa que reciba datos datos por el puerto serial y compilarlo para la arquitectura ARM. Ver seccin 5.1.5. o

El modulo de seguridad AES del circuito integrado CC2420 no est a siendo utilizado por TinyOS.

Escribir un programa que haga uso de las funciones de seguridad por hardware provistas por el circuito integrado CC2420. Ver seccin 5.1.1. o

Tabla 5.7: Problemas presentados en est tesis y su solua cin. o

75

76

Cap tulo 6 Aplicaciones Potenciales

Este cap tulo presenta tres aplicaciones potenciales para el mecanismo de recoleccin de o datos desarrollado en esta tesis. A continuacin se describen las posibles aplicaciones o haciendo nfasis en como el mecanismo de recoleccin puede aplicarse a estas propuestas. e o

6.1

Sistema de informacin mdica o e

Este sistema tiene como propsito recolectar informacin de pacientes que estn siendo o o a atendidos en un hospital. Como parte de los procedimientos mdicos, existe informacin sobre el paciente que dee o be ser sensada y enviada cada intervalo de tiempo, por ejemplo, temperatura, presin o arterial, frecuencia cardiaca, etc. Adicionalmente, esta informacin debe ser almacenada o y en algunos casos capturada para que se pueda llevar un registro satisfactorio del paciente. Los datos recolectados pueden ser de gran utilidad para el diagnostico, curacin y o prevencin de enfermedades. o Los pacientes en un hospital comnmente se encuentran en una habitacin, donde peru o manecen la mayor parte del tiempo, ya sea sentados o acostados, sin embargo durante su estancia pueden requerir visitar otras zonas del hospital, por ejemplo: quirfanos, salas de o recuperacin, terapia intensiva, laboratorio, etc. Por esta razn los pacientes no podr o o an hacer uso de dispositivos de recoleccin (nodos de lectura) que requieran de algn o u cableado, adems por seguridad del paciente, cualquier dispositivo elctrico/electrnico a e o debe estar aislado de la red elctrica, en nuestro caso al ser una solucin operada por bae o 77

ter este requerimiento se cumple a la perfeccin. El nodo de lectura se podr anexar as, o a al paciente al momento de su ingreso al hospital, y retirar este equipo cuando el paciente sea dado de alta. Los nodos de lectura utilizar sensores de temperatura, de presin arterial, de an o frecuencia cardiaca, entre otros. Para que los datos de estos sensores puedan ser transportados por el mecanismo de recoleccin ser necesario denir nuevos tipos de datos. o a Es importante recordar que el mecanismo de recoleccin permite aadir nuevos tipos de o n datos, para las lecturas provenientes de diferentes tipos de sensores, y que stos sean ene viados por el mismo mecanismo de recoleccin sin necesidad de alterar la programacin o o de los dems componentes del sistema. a La condencialidad y autenticidad de los datos del paciente es vital, ya que la informacin mdica debe ser tratada en secreto y solo debe ser conocida por el paciente o e y los mdicos que le atiendan. Es importante mencionar que aun cuando la informacin e o sea recolectada por mltiples entidades, esta no puede ser consultada ms que por las u a entidades autorizadas. Los mdicos, enfermeras y dems personal del hospital, pueden actuar como nodos de e a reenv ya que stos se encuentran en movimiento continuo en gran parte de las zonas o, e del hospital, por lo cual se puede cubrir ms area con menos nodos. Estos nodos de reenv a o tienen la capacidad de almacenar informacin de bastantes pacientes ya que cuentan con o una memoria no voltil de amplia capacidad. a Los nodos de procesamiento pueden ser jos o encontrarse incrustados en mobiliarios del hospital, que pueden ser jos o mviles. En conjunto con los nodos de procesamieno to tendr amos puertas de enlace avanzadas, para que reciban los paquetes de datos cifrados y ejecuten los algoritmos criptogrcos correspondientes para obtener los datos a descifrados. Los servidores pueden encontrarse junto a otros equipos de cmputo o en o un lugar diferente. Para completar el sistema ser necesario el desarrollo de una aplicacin para adminisa o trar la informacin de los pacientes, la cual se conectar a la base de datos del servidor de o a almacenamiento para ejecutar consultas e insertar datos en tablas diseadas de acuerdo n al sistema administrativo. En este sistema se podr manejar toda la informacin del paa o 78

ciente, consultar su historial cl nico, analizar su comportamiento a travs de parmetros e a mdicos, ver estad e sticas, o incluso generar alertas cuando se detecten situaciones de riesgo. La gura 6.1 muestra un esquema simplicado de la aplicacin de monitoreo mdico. o e

Figura 6.1: Esquema simplicado para la aplicacin de informacin mdica. o o e

6.2

Sistema de seguimiento para atletas

Este sistema puede ser utilizado para recolectar informacin de atletas en eventos deporo tivos. Los datos que pueden ser recolectados de competidores deportivos pueden incluir: tiempos de carrera, velocidad de desplazamiento, cantidad de pasos ejecutados, adems de a parmetros del atleta como: temperatura, ritmo cardiaco, presin arterial. Esta informaa o 79

cin recolectada puede ser de gran importancia para los atletas y sus entrenadores con el o n de proporcionar un mejor entrenamiento y en un futuro un mejor rendimiento. Adems a se pueden detectar problemas potenciales de salud, ya que es posible monitorear el estado del atleta durante el evento. An cuando los datos transmitidos no son totalmente sensibles, es deseable que stos u e no puedan ser conocidos por otras entidades, como por ejemplo la competencia, por lo que los servicios de seguridad provistos por el mecanismo de recoleccin deben ser utilizados. o El mecanismo de recoleccin puede ser utilizado en eventos deportivos de duracin proo o longada y en un area geogrca extensa, pero limitada, como por ejemplo en un maratn a o o medio maratn. Dada la caracter o stica de la aplicacin es imposible pensar en equipos o de lectura cableados. Los atletas actuarn como los nodos de lectura, ya que en este caso son los objea tos a monitorear. Los nodos de lectura utilizar sensores de temperatura, de presin an o arterial, de frecuencia cardiaca, de aceleracin, entre otros. Para que los datos de estos o sensores puedan ser transportados por el mecanismo de recoleccin ser necesario denir o a nuevos tipos de datos. Al igual que en la aplicacin anterior, es posible denir nuevos o tipos de datos a recolectar. Los nodos de reenv pueden estar jos o mviles a travs del camino, como en o o e entrenadores o veh culos de auxilio presentes en este tipo de eventos. Los nodos de procesamiento pueden ser jos o encontrarse instalados en los puntos donde se encuentran los equipos de los atletas, en puntos de salida y de llegada. Se utilizar puertas de enlace an avanzadas en conjunto con los nodos de procesamiento para manejar informacin cifrada o y tener el poder de cmputo necesario para procesar los paquetes. Los servidores pueden o encontrarse junto a otros equipos o en un lugar diferente. Para completar el sistema ser necesario el desarrollo de una aplicacin para adminisa o trar la informacin de los atletas, la cual se conectar a la base de datos del servidor o a de almacenamiento para extraer la informacin de los participantes. Este sistema podr o a manejar toda la informacin del atleta, consultar su historial deportivo, analizar su desemo peo, ver estad n sticas, o incluso generar alertas cuando se detecten anomal as.

80

La gura 6.2 muestra un esquema simplicado de la aplicacin de seguimiento para o atletas.

Figura 6.2: Esquema simplicado para la aplicacin de seguimiento para atletas. o

6.3

Sistema de inventarios

Este sistema tiene la nalidad de recolectar informacin concerniente a inventarios en o grandes bodegas. La tarea de realizar un inventario es una tarea ardua, s se realiza mediante los procedi mientos clsicos, es decir ver el producto, tomar nota de la cantidad existente y proceder a con el siguiente producto, para despus capturar toda la informacin y concentrarla en e o grandes bases de datos. Sin embargo, si hacemos uso de la tecnolog esta tarea puede a, ser completada en un tiempo visiblemente inferior. 81

Adems, al hacer uso de la tecnolog facilitamos las etapas posteriores a la recoleca a, cin de datos, por ejemplo en el procesamiento y consolidacin de la informacin. Por o o o ultimo, si la tecnolog de recoleccin est correctamente diseada y es utilizada de forma a o a n adecuada podremos observar que la cantidad de errores asociada con malas lecturas se podr reducir drsticamente. a a La manera en que nuestro mecanismo se puede aplicar a este escenario, es dando a las personas encargadas de levantar el inventario estaciones de lectura provistas de sensores adecuados para esta tarea, por ejemplo sensores con tecnolog RFID. Estos a operadores tendrn la misin de capturar todos los productos en determinadas areas asiga o nadas con anterioridad. Los nodos de lectura utilizar sensores de RFID, sensores de posicionamiento gloan bal, entre otros. Los nodos de reenv pueden estar inmersos en estructuras jas o mviles, como por o o ejemplo montacargas, ya que estos veh culos se encuentran en movimiento dentro de los almacenes. Los nodos de procesamiento pueden estar en localidad jas, por donde los nodos mviles circulen constantemente. o Al igual que en las otras aplicacin, los servidores pueden estar junto con otros equio pos de cmputo. o En este caso, es deseable que la informacin que sea capturada sea lo ms conable o a posible, es decir que no venga alterada ni generada por entidades maliciosas, por lo tanto se puede hacer uso de los servicios de autenticacin, mientras que el servicio de cono dencialidad puede quedar como opcional, a consideracin del usuario del mecanismo. o Como parte nal de este sistema, har falta una aplicacin para administrar y controa o lar los inventarios, para conocer la existencia o no de ciertos productos, todo esto con la nalidad de mejorar el movimiento de mercanc as. La gura 6.3 muestra un esquema simplicado de la aplicacin de levantamiento de o inventarios. 82

Figura 6.3: Esquema simplicado para la aplicacin de levantamiento de inventarios. o

83

84

Cap tulo 7 Conclusiones y Trabajo Futuro

En este trabajo se presento el anlisis, diseo e implementacin de un mecanismo seguro a n o de recoleccin de datos, el conjunto de pruebas que se han realizado hasta el momento o demuestran que el mecanismo de recoleccin funciona adecuadamente. El resultado de o este trabajo permitir que en un futuro el desarrollo de aplicaciones que ocupen tcnia e cas de recoleccin de datos sea ms sencillo, es as que ingenieros y cient o a cos de otras areas pueden crear aplicaciones que involucren recoleccin de datos sin ser expertos en o programacin de sistemas empotrados, en redes inalmbricas de sensores, en redes de o a computadoras, en manejo de servidores, entre otras areas relacionadas con este trabajo. La arquitectura propuesta incluye diversas categor de nodos, como son: nodos de as lectura, nodos de reenv y nodos de procesamiento. Adems se han denido dos tipos o a de puerta de enlace (simple y avanzada), esto es para interconectar la red inalmbrica de a sensores con otro tipo de red (i.e. una red Ethernet). Finalmente se han denido servidores para almacenamiento de datos y de consulta de datos recolectados por el mecanismo diseado e implementado en este trabajo. n La escalabilidad en este mecanismo juega un papel muy importante ya que permite que las aplicaciones puedan expandirse sin necesidad de reprogramar los nodos. La seguridad juega un papel muy importante y en este mecanismo ha sido contemplada desde sus primeras etapas. Otros requerimientos como la diversidad de sensores est contemplada ya a que el mecanismo puede agregar ms sensores sin alterar su arquitectura ni la estructura a de sus paquetes, por lo cual agregar un sensor ms al nodo es un proceso relativamente a sencillo. 85

Otro aspecto de bastante inters en este trabajo, es que a excepcin de los servidores e o (que pueden encontrarse en Internet), todo el mecanismo est programado sobre equipos a de cmputo empotrados, los cuales tienen un consumo de potencia muy bajo y en general o no requieren ventilacin, pudiendo ser operados a bater en su totalidad, esto nos pero as mite movilidad en nuestras aplicaciones, ya que no dependemos en ningn momento de u equipos de computo con cableado asociado. Se han propuesto tres posibles aplicaciones del mecanismo de recoleccin, stas son: o e sistema de informacin mdica, sistema de seguimiento para atletas y sistema de inventao e rios. En las propuestas realizadas se incluyen las ideas principales de como el mecanismo de recoleccin diseado puede ser aplicado para dar forma a estos sistemas. o n Los principios bsicos de funcionamiento del mecanismo de recoleccin presentado en a o este trabajo han sido presentados en el art culo de congreso internacional [20]. Otro trabajo publicado por el autor de sta tesis, es el art e culo [30] donde se describe el diseo n e implementacin de un generador de numeros aleatorios, util para algunas rutinas cripo togrcas. Adems derivado del art a a culo [30], se realiz una presentacin en la sesin de o o o posters en un congreso internacional.

7.1

Trabajo futuro

El trabajo a futuro que implica el desarrollo de este mecanismo de recoleccin se puede o resumir en los siguientes puntos: 1. Evaluar el mecanismo a gran escala, en areas extendidas, con una mayor cantidad de nodos, con una metodolog de evaluacin previamente denida (i.e. cantidad de a o paquetes enviados vs. cantidad de paquetes recibidos, velocidad mxima de desplaa zamiento al momento de efectuar recoleccin y env de paquetes de datos). o o 2. Construir bibliotecas de software que permitan que el mecanismo de recoleccin o pueda ser utilizado como componente.

3. Aplicar tcnicas de fusin de sensores para obtener mejores datos a partir de una e o 86

mayor cantidad de nodos.

4. Construir una interfaz grca de usuario que permita seleccionar los parmetros de a a operacin del mecanismo de recoleccin y que programe automticamente los nodos o o a con las opciones escogidas.

5. Proponer una solucin eciente para el problema de distribucin de llaves para las o o comunicaciones seguras.

6. Implementar un sistema que haga uso del mecanismo de recoleccin y evaluar su o desempeo. n

87

88

Apndice A e Anexo A
A.1 Compilacin y carga del programa en los nodos o

La compilacin y la carga de programas en los nodos es llevado a cabo por el comando o mostrado en la gura A.1. make micaz install,id mibXXX, /dev/ttyX Figura A.1: Comando para compilar y cargar los programas en los nodos La sentencia make invoca al comando del mismo nombre, el primer campo especica la plataforma destino (MICA, MICA2, MICAZ ), mientras que el segunda indica la opcin a o ejecutar (install o reinstall ), el tercero establece el identicador del nodo, el cuarto selecciona el tipo de programador (MIB510, MIB520, MIB600 ), nalmente el quinto provee la ruta del puerto a utilizar. Este comando debe ser ejecutado en el directorio de cada aplicacin, donde se encuentre el archivo Makele. La estructura del archivo makele se o muestra en la gura A.2.

COMPONENT = nombre_del_componente CFLAGS += -I$(TOSDIR)/lib/printf MSG_SIZE = tamano_del_paquete_de_datos include $(MAKERULES) Figura A.2: Estructura del archivo makele

89

A.2

Instalacin del compilador para arquitecturas ARM o

El proceso de generacin del conjunto de herramientas de compilacin cruzada es un o o proceso dif de lograr, que requiere bastantes conocimientos del sistema, y una gran cil cantidad de dependencias de paquetes, de versiones especicas de algn compilador. Si u bien es cierto que existen scripts que nos ahorran mucho no deja ser un proceso dif y cil en ocasiones muy tardado. A continuacin se describe la instalacin de un compilador cruzado para la arquitectura o o ARM que se encuentra disponible libremente en la red [1]. El compilador quedar instalado en $HOME/crosstool a

1. Crear directorio del compilador cruzado: mkdir $HOME/crosstool/

2. Obtener el conjunto de herramientas de compilacin cruzada: o wget ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7200-linux/ cross-toolchains/crosstool-linux-gcc-4.0.1-glibc-2.3.5.tar.bz2

3. Extraer el contenido del archivo obtenido: tar xvf crosstool-linux-gcc-4.0.1-glibc-2.3.5.tar.bz2 -C $HOME/crosstool

4. Agregar la ruta del compilador cruzado a la variable de ambiente PATH: PATH=$HOME/crosstool/opt/crosstool/gcc-4.0.1-glibc-2.3.5/ arm-unknown-linux-gnu/bin/:$PATH

El llamado al compilador cruzado ser de la siguiente manera: a arm-linux-unknown-gcc fuentes.c -o objeto.o

90

A.3

Cambio del baudrate en los nodos MICAZ

Algunos nodos MICAZ deben ser capaces de comunicarse mediante un enlace serial con la puerta de enlace a un mismo baudrate, por ello es necesario modicar el archivo y agregar los valores adecuados del registro de conguracin para el baudrate requerido a o la frecuencia de trabajo. Estos valores fueron tomados de las hojas de especicaciones del microcontrolador Atmel ATMEGA128. La gura A.1 muestra los diferentes valores que los registros de conguracin pueden tomar cuando la frecuencia de trabajo es 7.3728 o Mhz [15].

Baudrate U2X = 0 U2X = 1 bps UBRR Error UBRR Error 2400 191 0.0 % 383 0.0 % 4800 95 0.0 % 191 0.0 % 9600 47 0.0 % 95 0.0 % 14.4k 31 0.0 % 63 0.0 % 28.8k 23 0.0 % 31 0.0 % 38.4k 11 0.0 % 23 0.0 % 57.6k 7 0.0 % 15 0.0 % 76.8k 5 0.0 % 11 0.0 % 115.2k 3 0.0 % 7 0.0 % Tabla A.1: Conguracin del baudrate para el microcono trolador Atmel ATMEGA128.

91

A.4
A.4.1

Interfaces de comunicacin en los nodos MICAZ o

Interfaz I2C

I2C es un bus de comunicaciones seriales s ncronas, su nombre viene de Inter-Integrated Circuit. La velocidad es de 100Kbits por segundo en el modo estndar, aunque tambin a e permite velocidades de 3.4 Mbit/s. Es un bus muy utilizado, principalmente para comunicar microcontroladores y sus perifricos en sistemas empotrados aunque en general es e utilizado para comunicar circuitos integrados entre s que normalmente residen en un mis mo circuito impreso. La principal caracter stica de I2C es que utiliza dos seales para transmitir la inforn macin: una seal para los datos y otra seal de reloj. Tambin es necesaria una tercera o n n e seal, pero esta slo es la referencia. Las l n o neas se llaman: SDA (datos) y SCL (reloj). Este bus permite la existencia de dispositivos maestros y esclavos, donde pueden existir hasta 128 dispositivos, ya que las direcciones de cada dispositivo estn compuestas por 7 a bits. La seal de datos es bidireccional, por la l n nea de datos, el maestro realiza los env os y por la misma l nea de datos recibe la respuesta. En la gura A.3 se muestra el formato de la seales utilizadas en la interfaz de comunin cacin I2C. El primer comando que debe usarse en este bus de comunicaciones es el Start, o ste se da cuando la l e nea de datos SDA pasa a nivel bajo mientras que la l nea de reloj SCL se encuentra en nivel alto. Los siguientes 8 bits indican la direccin del dispositivo o esclavo a utilizar y la operacin a realizar (leer o escribir), al nalizar la escritura de estos o 8 bits el dispositivo esclavo debe enviar una seal de reconocimiento, despus de recibir n e esta seal el dispositivo maestro est listo para enviar la direccin del registro que desea n a o leer o escribir. Despus en caso de elegir una operacin de escritura se debe enviar el dato e o a escribir en el registro antes seleccionado. El ultimo comando en este bus de comunicaciones es conocido como stop, el cual se da cuando la l nea de datos SDA pasa a nivel alto mientras que la l nea de reloj SCL se mantiene en alto.

A.4.2

Interfaz SPI

SPI es una interfaz de comunicacin serial s o ncrona, opera en modo full dplex. Los dispou sitivos que utilizan SPI utilizan el modo maestro - esclavo, donde el dispositivo maestro 92

Figura A.3: Formato de las seales de comunicacin en I2C. n o

inicia la comunicacin al enviar un paquete de datos, este bus permite la conexin de o o mltiples esclavos. A diferencia del bus I2C referido anteriormente, este bus no utiliza u un esquema de direccionamiento, por lo que la eleccin del dispositivo esclavo ocurre a o travs de la l e nea de seleccin provista en cada uno de estos dispositivos. No existe un o nmero mximo de dispositivos esclavos presentes en el bus, ya que solo uno se encuentra u a activado a la vez.

Esta interfaz est compuesta por dos seales de datos, conocidas como MOSI (Masa n ter Output Slave Input) y MISO (Master Input Slave Output), CS (Chip Select), de una seal de reloj (CLK ) y nalmente de una seal de referencia, o mejor conocida como tierra. n n

La operacin de esta interfaz de comunicacin comienza cuando el dispositivo maestro o o habilita al dispositivo esclavo llevando la l nea de seleccin de nivel alto a nivel bajo. Al o escribirse un dato en el bus, a travs de la seal MOSI automticamente se genera la seal e n a n de reloj correspondiente para sincronizar las comunicaciones. Al completarse el env de o un comando al dispositivo esclavo ste responde con los datos solicitados al escribir los e datos en la seal MISO, la cual se mantiene en estado de alta impedancia hasta antes de n responder con los datos requeridos. La operacin antes descrita puede observarse en la o gura A.4.

93

Figura A.4: Formato de las seales de comunicacin en SPI. n o

A.4.3

Interfaz UART

Es una interfaz de comunicacin serial as o ncrona para enlaces de datos. Esta interfaz es muy comn en los microcontroladores actuales, y es usado principalmente para comuniu carse con otros dispositivos externos. Utiliza una codicacin serial para los datos, a una o velocidad y formato congurable. Esta interfaz de comunicacin est compuesta por dos seales, la primera conocida coo a n mo transmisin o TX, y la segunda conocida como recepcin o RX. A diferencia de las o o interfaces presentadas previamente, esta interfase es as ncrona ya que no tiene una seal n de reloj. Por ultimo es necesaria la seal de referencia o tierra. n En esta interfaz de comunicacin no existe una seal de reloj para la sincronizacin o n o de los datos, el ancho de la seal se dene a travs del parmetro conocido como baun e a drate, donde el ancho del pulso por bit es igual a 1/baudrate. Los datos se transeren en secuencias de 8 bits, con sealizaciones para indicar el inicio y n de la transmisin, n o opcionalmente se puede hacer uso de un chequeo de datos por la paridad de los datos transmitidos. El lenguaje de programacin nesC posee los componentes necesarios para efectuar coo municaciones mediante las principales interfaces de comunicacin antes descritas, en la o tabla A.2 se muestra cada interfaz con su respectivo componente. En caso de que el sensor 94

Figura A.5: Formato de las seales de comunicacin en UART. n o

a comunicar con el nodo utilice una interfaz de comunicacin no estndar, sta se puede o a e implementar a nivel de software, si ste es el caso se debe consultar la hoja de datos del e componente para poder obtener mayor informacin respecto a las secuencias de inicialio zacin, control y manipulacin del sensor. o o

95

Interfaz I2C SPI UART

Componente Atm128I2CMasterC Atm128Uart0C Atm128SpiC

Tabla A.2: Componentes en nesC para las principales interfaces de comunicacin o

96

Bibliograf a
[1] Gcc v4.0.1 with glibc v2.3.5 for arm, Nov. 2010, ftp://ftp.embeddedarm.com/ts-armsbc/ts-7200-linux/cross-toolchains/crosstool-linux-gcc-4.0.1-glibc-2.3.5.tar.bz2. [2] Body sensor networks nodes, Nov. 2010, http://vip.doc.ic.ac.uk/bsn/index.php?article=926. [3] Arduino sensor node platform, Nov. 2010, http://www.arduino.cc. [4] Btnodes - a distributed environment for prototyping ad hoc networks, Nov. 2010, http://www.btnode.ethz.ch/. [5] Eyes - energy ecient sensor networks, Nov. 2010, http://www.eyes.eu.org/. [6] Memsic - powerful sensing http://www.memsic.com/. solutions for a better life, Nov. 2010,

[7] Meshnetics - easy wireless for things, Nov. 2010, http://www.meshnetics.com/. [8] Scatterweb - the self conguring wireless communication platform, Nov. 2010, http://www.scatterweb.com/index.en.html. [9] Sun spot world, Nov. 2010, http://www.sunspotworld.com/. [10] Xbee - making wireless m2m easy, Nov. 2010, www.digi.com/getXBee. [11] LEA-4A - ANTARIS 4 GPS Modules Datasheet. UBLOX, Switzerland, 2007. [12] SHT11 - Humidity and Temperature Sensor Datasheet. Sensirion, Switzerland, 2010. [13] ADXL202JE - Low-Cost +/-2g Dual-Axis Accelerometer with Duty Cycle Output Datasheet. Analog Devices, United States of America, 2000. [14] ADG715 - CMOS, Low Voltage Serially Controlled, Octal SPST Switches Datasheet. Analog Devices, United States of America, 2002. 97

[15] ATMEGA128 - 8-bit AVR Microcontroller with 128K Bytes In-System Programmable Flash Datasheet. Atmel, United States of America, 2004. [16] Micro - Ethernet Embedded Device Server. Lantronix, United States of America, 2006. [17] MS5534C - Barometer Module Datasheet. Intersema, United States of America, 2007. [18] TLS2550 - Ambient Light Sensor with SMBus Interface Datasheet. Texas Advanced Optoelectronics Solutions, United States of America, 2007. [19] TIRIS Micro-reader Module Reference Guide - RI-STU-MRD1. 3rd. Edition, Texas Instruments, USA, 2000. [20] I. C. Altamirano and F. R. Henr quez. A scalable intelligent room based on wireless sensor networks and rds. CCE2010, 2010. [21] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald, A. Torgerson, and R. Han. Mantis os: An embedded multithreaded operating system for wireless micro sensor platforms. pages 563579, 2005. [22] Q. Cao, T. F. Abdelzaher, J. A. Stankovic, and T. He. The liteos operating system: Towards unix-like abstractions for wireless sensor networks. In International Conference on Information Processing in Sensor Networks, pages 233244, 2008. [23] H. Chan, A. Perrig, and D. X. Song. Random key predistribution schemes for sensor networks. In IEEE Symposium on Security and Privacy, pages 197225. IEEE Computer Society, 2003. [24] M. de Alba Rosano, I. Cabrera-Altamirano, and C. Ortega-Otero. Estimacin del o consumo de potencia dinmica en un microprocesador superscalar. EINVIE05, pages a 251260, 2005. [25] W. Die and M. E. Hellman. New directions in cryptography. 1976. [26] A. Dunkels, B. Grnvall, and T. Voigt. Contiki - a lightweight and exible operating o system for tiny networked sensors. In LCN, pages 455462, 2004. [27] D. Estrin, R. Govindan, J. Heidemann, and S. Kumar. Next century challenges: Scalable coordination in sensor networks. pages 263270, 1999. 98

[28] D. Gay, P. Levis, J. R. von Behren, M. Welsh, E. A. Brewer, and D. E. Culler. The nesc language: A holistic approach to networked embedded systems. In PLDI, pages 111, 2003. [29] J. A. Gutierrez, E. H. Callaway, and J. Raymond L. Barret. Low-Rate Wireless Personal Area Networks - Enabling Wireless Sensors with IEEE 802.15.4. 2nd. Eidition, IEEE Press, USA, 2007. [30] R. E. Henr quez, I. Cabrera, and D. Chakraborty. On the analysis of a practical crypto-system in the limited access model. CCE2010, 2010. [31] J. L. Hill, R. Szewczyk, A. Woo, S. Hollar, D. E. Culler, and K. S. J. Pister. System architecture directions for networked sensors. In ASPLOS, pages 93104, 2000. [32] P. Juang, H. Oki, Y. Wang, M. Martonosi, L.-S. Peh, and D. Rubenstein. Energyecient computing for wildlife tracking: design tradeos and early experiences with zebranet. In ASPLOS, pages 96107, 2002. [33] J. M. Kahn, R. H. Katz, and K. S. J. Pister. Next century challenges: Mobile networking for smart dust. In MOBICOM, pages 271278, 1999. [34] C. Karlof and D. Wagner. Secure routing in wireless sensor networks: attacks and countermeasures. Ad Hoc Networks, 1(2-3):293315, 2003. [35] B. W. Kernighan and D. M. Ritchie. The C Programming Language. 2nd. Edition, Prentice Hall, USA, 1988. [36] J. Krumm. Ubiquitous Computing Fundamentals. 1st. Edition, Chapman & Hall, USA, 2009. [37] E. A. Lee. Embedded software. Advances in Computers, 56:5697, 2002. [38] D. Liu and P.Ning. Multilevel tesla: Broadcast authentication for distributed sensor networks. ACM Trans. Embedded Comput. Syst., 3(4):800836, 2004. [39] M. Luca and P. G. Pietro. Programming wireless sensor networks: Fundamental concepts and state of the art. ACM Computing Surveys, 2010. [40] D. Lymberopoulos and A. Savvides. Xyz: a motion-enabled, power aware sensor node platform for distributed sensor network applications. In International Conference on Information Processing in Sensor Networks, pages 449454. IEEE, 2005. 99

 [41] T.Nadeem, S. D. C. Liao, and L. Iftode. Tracview: trac data dissemination using car-to-car communication. Mobile Computing and Communications Review, pages 619, 2004. [42] S. Oh. The vehicle location tracking system using wireless network. In T.-J. Cham, J. Cai, C. Dorai, D. Rajan, T.-S. Chua, and L.-T. Chia, editors, MMM (2), volume 4352 of Lecture Notes in Computer Science, pages 651661. Springer, 2007. [43] C. Paar and J. Pelzl. Understanding Cryptography: A Textbook for Students and Practitioners. Springer-Verlag New York Inc, 2010. [44] A. Perrig, R. Szewczyk, V. Wen, and D. E. Culler. Spins: Security protocols for sensor networks. Wireless Networks, 8(5):521534, 2002. [45] U. Ramana. Some experiments with the performance of lamp architecture. Computer and Information Technology, International Conference on, 0:916921, 2005. [46] B. Rubio, M. D and J. M. Troya. Programming approaches and challenges for az, wireless sensor networks. In ICSNC, page 36, 2007. [47] G. Schfer. Security in Fixed and Wireless Networks. 1st. Edition, John Wiley and a Sons, USA, 2004. [48] R. C. Shah, S. Roy, S. Jain, and W. Brunette. Data mules: modeling and analysis of a three-tier architecture for sparse sensor networks. Ad Hoc Networks, 1(2-3):215233, 2003. [49] K. Sohraby, D. Minoli, and T. Znati. Wireless Sensor Networks - Technology, Protocols and Applications. 1st. Edition, Wiley-Interscience, USA, 2007. [50] R. Want, A. Hopper, V. Falcao, and J. Gibbons. The active badge location system. ACM Trans. Inf. Syst., 10(1):91102, 1992. [51] M. Weiser. The computer for the 21st century. Scientic American, 265(3):6675, January 1991. [52] K. Whitehouse, , and D. Culler. Calibration as parameter estimation in sensor networks. In WSNA 02: Proceedings of the 1st ACM international workshop on Wireless sensor networks and applications, pages 5967, New York, NY, USA, 2002. ACM. [53] R. Zurawski. Networked Embedded Systems. 2nd. Edition, CRC-PRESS, USA, 2009. 100

Glosario
AES Advanced Encryption Standard. 24, 30, 37, 43, 62 API Application Programming Interface. 58 ARM Advanced RISC Machine. 29, 55, 62, 74 ASCII American Standard Code for Information Interchange. 46 ASP Active Server Pages. 21 CBC Cipher-Block Chaining Mode. 25, 30, 37, 42, 60 CFB Cipher Feedback Mode. 24, 25 CS Chip Select. 77 CTR Counter Mode. 25 DES Data Encryption Standard. 24 ECB Electronic Codebook. 24 EEPROM Electrically Erasable Programmable Read-Only Memory. 43 GCM Galois Counter Mode. 25 GHz Gigahertz. 18 GNU GNU is not Unix. 27, 29, 55 GPS Global Positioning System. 15, 28, 4446, 57, 62 HTML HyperText Markup Language. 58 101

HTTP HyperText Transfer Protocol. 38, 54, 55, 58 I2C Inter-Integrated Circuit. 37, 43, 44, 76, 79 IIS Internet Information Services. 21 ISM Industrial, scientic and medical. 18 JSP Java Server Pages. 21 KB Kilobyte. 18, 43 MB Megabyte. 18 MHz Megahertz. 18 MISO Master Input Slave Output. 77 MOSI Master Output Slave Input. 77 ms milisecond. 60 mW miliWatt. 9 OFB Output Feedback Mode. 25 PCMCIA Personal Computer Memory Card International Association. 15 PHP HyperText Preprocessor. 21, 29, 54, 56, 58 RAM Random Access Memory. 21, 43 RFID Radio Frequency Identication. 28, 35, 47, 48, 68, 69 RISC Reduced Instruction Set Computer. 43 SCL Serial Clock. 45, 76 SDA Serial Data. 45, 76 SPI Serial Peripheral Interface. 37, 43, 76, 79 102

UART Universal Asynchronous Receiver Transceiver. 37, 43, 54, 79 URL Uniform Resource Locator. 40 USB Universal Serial Bus. 60 XOR Exclusive OR. 25

103