Trabajo Fin de Grado Grado en Ingeniería de las …bibing.us.es/proyectos/abreproy/90714/fichero/...2016/07/08 · -La demostración o comparación del modelos LNSM-DV en métodos

Equation Chapter 1 Section 1

Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación

Modelo de estimación de la distancia en interiores basado en medida RSSI en una WSN

Autor: Mª Eugenia López García Tutor: Mª José Madero Ayora

Dep. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería

Universidad de Sevilla Sevilla, 2016

iii

Proyecto Fin de Carrera Ingeniería de Telecomunicación

Modelo de estimación de la distancia en interiores basado en medida RSSI en una WSN

Autor:

Mª Eugenia López García

Tutor:

Mª José Madero Ayora Profesor titular

Dep. de Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería

Universidad de Sevilla Sevilla, 2016

v

Proyecto Fin de Carrera: Modelo de estimación de la distancia en interiores basado en medida RSSI en una WSN

Autor: Mª Eugenia López García

Tutor: Mª José Madero Ayora

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2016

El Secretario del Tribunal

vii

A mi familia

A mis amigas y amigos

A mis maestros

ix

Agradecimientos

De todos es sabido que la palabra “Gracias” hace cuanto menos a una persona un poco más humilde. Hoy quiero rozar el límite máximo de esta virtud. Llegado a este punto que tan lejos vemos, casi inalcanzable a veces. A la cabeza del mérito para conseguir llegar hasta aquí se encuentran mis padres y hermanos. Figuras imprescindibles en mi camino para apoyarme, escuchar mis llantos y llenarme de fuerzas en los momentos más duros. Papá y Mamá, gracias por no dejarme nunca tirar la toalla. Y para los que son como de la familia, aquellos que me han ayudado a hacerlo todo mucho más sencillo.

A mis amigas y amigos, de Universidad y de Colegio Mayor. Dije que los nombraría a todos, pero no quisiera dejarme a nadie atrás por descuido. Sabéis a quiénes me refiero y sabéis que sois lo más valioso de esta etapa.

A todos mis profesores de Universidad y en especial a Mª José Madero, tutora de este TFG que tanto ha estado ahí recordándome que podía con todo y más.

María Eugenia López García.

Sevilla, 2016

xi

Resumen

En este trabajo se ha propuesto un modelo de sombra log-normal con la variación dinámica para redes inalámbricas de sensores. Para llevarlo a cabo, nos apoyamos en los métodos ya conocidos de estimación del alcance basados en RSSI para dar lugar a una serie de ecuaciones matemáticas. Estas ecuaciones serán las responsables de dar como resultado, a través del método LS una serie de valores específicos a los coeficientes del modelo haciendo que éstos sean capaces de ajustarse dinámicamente de acuerdo a los cambios del medio.

Para conseguirlo, hemos empleado material hardware y software facilitado por la Escuela Técnica Superior de Ingenieros de Sevilla. En sus instalaciones de laboratorio, hemos realizado las medidas necesarias que han sido procesadas a través de código ejecutado bajo software TinyOS.

Con los datos recopilados, y gracias al software matemático ampliamente visto en sesiones prácticas de múltiples asignaturas de la titulación Grado en Ingeniería de las Tecnologías de las Telecomunicaciones llamado Matlab, hemos codificado una función capaz de llevar a cabo todos los cálculos que el método de los mínimos cuadrados LS precisa.

Con todo esto, hemos realizado una breve alusión a los resultados obtenidos y presentación de nuevos horizontes abiertos.

xiii

Índice

Agradecimientos ix

Resumen xi

Índice xiii

ÍndicedeTablas xvi

ÍndicedeFiguras xviii

1 Introducción 11.1. Objetivos 11.2. Alcance 11.3.Estructuradelamemoria 2

2 Entornodetrabajo 32.1 IntroducciónaWSN 32.2 Hardware 4

2.2.1 ProcesadoryplataformaradioMPR2400CA 62.2.2 PlacassensorasMTS300CA 82.2.3 PlacassensorasMTS310CA 92.2.4 PlacassensorasMDA300CA 102.2.5 TableroMIB520 112.2.6 TableroMIB600 132.2.7 IEEE802.15.4 13

2.3 Software 142.3.1. TinyOS 152.3.2. nesC 16

3 Localizacióneninteriores 273.1 Aspectosgeneralesdelocalizaciónenredesinalámbricasdesensores. 27

3.1.1 Introducción 273.2 ModelodemedidadeladistanciabasadoenRSSIenWSN 29

3.2.1 LNSM-DV 293.3 EstimacióndelalcancebasadaenRSSI 30

3.3.1 PrincipiosdeestimacióndelalcancebasadaenRSSI 303.3.2 ModelodeestimacióndelalcancebasadoenRSSI 30

3.4 Mejoradelmodelodesombralogarítmico-normal. 313.4.1 Mejoradelaauto-adaptabilidaddevaloresGaussianosenLNSM 32

3.5 Realizacióndeadaptabilidaddeloscoeficientesenelmodelodesombralogarítmico-normal 343.5.1 Métododeregresióndemínimoscuadrados 34

3.6 Análisisexperimentalenelartículodereferencia 383.6.1 Datos,procesoexperimentalyanálisis. 39

4 Desarrollo 434.1 Análisisdeentorno 43

4.1.1 MaterialEmpleado 434.1.2 Entorno 43

4.2 Descripcióngeneral 444.2.1 Motatransmisora 454.2.2 Motareceptora 454.2.3 Estaciónbase 454.2.4 Potenciayfrecuenciadeemisión 464.2.5 Fasedetomadedatos 504.2.6 Fasedemedidayrealizacióndelmodelo 54

4.3 Resultados 58

5 Conclusionesylíneasfuturasdetrabajo 715.1.1 Conclusiones 715.1.2 Líneasfuturasdetrabajo 72

6 Anexo 73

Bibliogragía 85

xv

Índice de Tablas

Tabla 3-1. Coeficientes empleados en LNSM. 39

Tabla 4-1. Tabla de equivalencia de nivel de transmisión con sus respectivas potencias. 49

Tabla 4-2. Tabla resumen conversión plataforma-velocidad. 52

xvii

Índice de Figuras

Figura 2-1. Componentes Mote-Kit2400 5

Figura 2-2. MPR2420CA 6

Figura 2-3. Diagrama de bloques MPR2400 CA 7

Figura 2-4. Módulo RF2420 8

Figura 2-5. Conexionado de pines de las placas sensoras MTS300CA 9

Figura 2-6. Vista frontal de las placas sensoras MDA300CA [3]. 10

Figura 2-7. Diagrama de bloques MDA300 CA 10

Figura 2-8 Placa programadora MIB520 11

Figura 2-9. MIB520 con mota micaZ acoplada 11

Figura 2-10. Esquemático/Conexionado de la placa programadora MIB520 12

Figura 2-11. Estación Base 13

Figura 2-12. Distribución de canales IEEE 802.15.4 14

Figura 2-13. Esquema de aplicación vista como un conjunto de componentes interconectados entre sí. [16] 17

Figura 2-14. Diagrama comandos y eventos. [9] 18

Figura 2-15. Pasos en la compilación de una aplicación TinyOS. [17] 18

Figura 3-1. Relación intensidad de potencia recibida y distancia. 32

Figura 3-2. Evolución de la varianza RSSI con la distancia. 33

Figura 3-3. Representación polinómica de coeficientes indeterminados. 35

Figura 3-4. Ecuación matricial de la solución teórica desarrollada. 36

Figura 3-5. Ecuación matricial a través de la matriz pseudoinversa. 36

Figura 3-6. Relación de la intensidad de potencia recibida y distancia en entornos interiores. 40

Figura 3-7. Relación de la intensidad de potencia recibida y distancia en entornos exteriores. 41

Figura 4-1. Distribución de ficheros por carpetas. 44

Figura 4-2. Distribución de canales de las distintas tecnologías 47

Figura 4-3. Interferencia Wifi - ZigBee 48

xix

Figura 4-4. Esquema del banco de desarrollo 50

Figura 4-5. Resultados obtenidos en la medida inicial (d=0.4 m). 59

Figura 4-6. Resultados obtenidos en la medida intermedia (d=3.2 m) 60

Figura 4-7. Resultados obtenidos en la medida más lejana (d=6 m). 61

Figura 4-9. Diagrama transmisión (Tx) y recepción (Rx) en espacio libre. 61

Figura 4-10. Ensanchamiento del frente de onda en función del parámetro r. [28] 62

Figura 4-11. Representación del total de datos de pérdidas de potencia transmitida (PL) frente a la distancia. 63

Figura 4-12. Representación de potencia recibida (PR) frente a la distancia. 64

Figura 4-13. Representación de media (Lb(dB)) de pérdidas de potencia transmitida (PL(d)) frente a la distancia. 65

Figura 4-14. Representación conjunta de media y total de pérdidas de potencia transmitida (PL(d)) frente a la distancia. 66

Figura 4-15. Representación de medida de varianza (V) frente a la distancia. 67

Figura 4-16. Curva de movimiento de varianza real y aproximada frente a la distancia. 68

1

1 INTRODUCCIÓN

ste trabajo constituye la continuación de dos proyectos titulados “Localización en interiores usando redes inalámbricas de sensores: Implementación práctica” realizado por Miguel Villagrán Marín e “Implementación de algoritmos distribuidos basados en kernel sobre redes de sensores inalámbricas”

realizado por Juan Alfonso Garrido Castellano. Además, el contenido de este trabajo está basado en el artículo de investigación “Modelo de medida de la distancia basado en RSSI en WSN” escrito por los autores Jiuqiang Xu, Wei Liu, Fenggao Lang, Yuanyuan Xhang y Cheglong Wang.

Si bien la introducción constituye la primera aproximación del lector al tema que vamos a desarrollar, la amplia base de este proyecto será tratada más en detalle en el capítulo 2.

En los siguientes subapartados diferenciamos el fin último de este trabajo junto con aquellas consideraciones o estudios que no son materia de este trabajo.

Listaremos la composición de esta memoria y el por qué de cada una de las partes en las que se ha dividido el trabajo

1.1. Objetivos

A través de la lectura de este trabajo se busca que se comprenda la importancia y la alta aplicabilidad de los sistemas de redes inalámbricos.

A lo largo de todo el trabajo consideraremos que el lector posee conocimientos básicos en sistemas de redes sencillos y en matemáticas, siendo un plus el conocimiento de las redes inalámbricas.

Esta memoria tiene como finalidad la puesta en marcha de una red básica mediante una plataforma de sensores comerciales de bajo coste y sencillo manejo.

El fín útimo de los capítulos es conseguir demostrar con la ayuda de esta red la eficacia y la puesta en marcha de un modelo altamente eficaz frente a los modelos descritos teóricamente en este trabajo y empleados comunmente con anterioridad. Se prueba cómo el sistema que describiremos es capaz de reducir la probabilidad de error en la estimación de la distancia.

Tras la completa lectura de este documento, se hace notable que el tema de los sensores es muy amplio y extenso.

1.2. Alcance

Si bien este trabajo tiene por objeto cumplir con el objetivo resumido en el apartado 1.1, se ha visto necesario para su aclaración indicar que no se han incluido en el contenido ciertas tareas o opciones, como pueden ser las siguientes:

- La modificación en la topología de la red.

- La comprobación del funcionamiento más o menos óptimo empleando otras familias de sensores.

- La aplicación o conocimiento de un software diferente al visto en las sesiones prácticas de radiocomunicación durante los estudios de Grado en Ingeniería de las Tecnologías de las Telecomunicaciones para el cálculo en las pérdidas de potencia recibida.

- Del mismo modo, el uso de un software matemático más o menos potente para la realización de

E

Introducción

2

cálculos a través del método de mínimos cuadrados y el tratamiento con matrices.

- La compilación o ejecución en otros lenguajes de programación diseñados para la computación de redes de sensores inalámbricos.

- El empleo o la comparación con otros protocolos con menor o mayor nivel de confidencialidad, autenticación o encriptación para evitar captación de datos por parte de terceros.

- La demostración o comparación del modelos LNSM-DV en métodos exteriores debido a las complicaciones que esto puede implicar.

1.3. Estructura de la memoria

Este trabajo se vertebra en una lista de títulos que hacen visible el seguimiento de un orden lógico y progresivo de la estructura para facilitar la comprensión del estudio.

El proyecto llega descrito bajo el título “Modelo de estimación de la distancia en interiores basado en medida RSSI en una WSN”. Se ha seleccionado un tema como éste, puesto que se ubica dentro de los actuales sistemas emergentes, lo que me ha servido para ampliar mi visión en las tecnologías actuales y las tendencias de futura implantación.

Tras el título, nos hemos encontrado con una serie de índices y sus correspondientes enumeraciones de página.

Apartados y subapartados se han enumerado para poder referenciar la información que ha ido apareciendo en párrafos anteriores de forma cruzada.

Como primera toma de contacto, comenzamos exponiendo brevemente el significado del término “redes inalámbricas de sensores” y detallamos el hardware de los dispositivos sin demasiada profundidad, puesto que no es el objetivo principal de este trabajo conocer los componentes electrónicos de cada uno de ellos.

Acto seguido, continuaremos con la presentación y exposición de la parte software. Tratamos de introducir ligeramete el funcionamiento del sistema operativo TinyOS y sus componentes mas importantes. En particular nos centramos en el dialecto del lenguaje de programación de C conocido como nesC. Elegimos nesC por ser uno de los más indicados para sistemas con limitaciones de memoria. Simplificamos su explicación a través de grafos y un ejemplo demo usado típicamente para la mejora de su entendimiento.

Una vez tengamos claros todos los materiales tanto físicos como abstractos necesarios para la implementación de la aplicación, desarrollamos y argumentamos el análisis del artículo de investigación mencionado al principio de este capítulo. En un primer momento nos centraremos en la lectura de las técnicas de localización existentes y los métodos empleados en las redes de sensores inalámbricas. En una siguiente parte, llevaremos a cabo la implementación de una aplicación de mejora en la estimación de distancia mediante el cálculo de parámetros autoajustables según el entorno. En esta, se presentan el método, las técnicas, los instrumentos y las fuentes utilizadas en la investigación. Las dificultades metodológicas y los modos de afrontarlas.

Como parte esencial del trabajo y como uno de los últimos contenidos de este, hemos procurado recordar el itinerario de la investigación, la validación o no del modelo seguido inicial a través del artículo de investigación, los interrogantes no resueltos y reflexiones propias, entre otras.

Bibliográficamente, se enumera el listado de fuentes a las que han recurrido.

Y como último contenido y a modo de lectura opcional, el Anexo, con la intención de liberar al texto de contenido no imprescindible para la comprensión del contexto.

3

2 ENTORNO DE TRABAJO

no de los mayores atractivos en el mundo tecnológico actual es el de tener la posibilidad de conectar dispositivos en ausencia de cableado [18]. A ello se debe su alta velocidad de evolución en los últimos años.

2.1 Introducción a WSN

Las siglas WSN (Wireless Sensor Networks) hacen referencia a las redes de sensores inalámbricas, área reconocida según el MIT (Instituto Tecnológico de Massachusetts) como una de las 10 redes más emergentes del futuro. Se trata de una red tipo PAN (Personal Area Network) compuesta por sensores, “nodos” o “motas” que prescinden de cableado. De esta forma permiten formar redes ad hoc sin infraestructura visible ni administración central. Dicha característica las hace atractivas para su uso en aquellas localizaciones de difícil acceso y en las que es necesaria la toma de datos de múltiples ubicaciones. Difieren del resto de redes convenciales en que poseen un punto de acceso capaz de gestionar la comunicación entre todos los nodos existentes en dicha red.

Una WSN permite capturar datos de un determinado entorno, realizar su procesamiento y posterior clasificación. Pudiendo incluso activar una serie de actuadores en respuesta a estímulos, como sería por ejemplo sobrepasar un cierto valor umbral.

Los nodos o motas son unidades computacionales con capacidad de procesamiento, memoria e interfaz de comunicación entre las distintas motas distribuidas en el espacio. Cada una de ellas está compuesta normalmente por un transmisor radio o dispositivo de comunicaciones inalámbricas, microcontrolador y una fuente de alimentación (generalmente se trata de una batería), y por uno o más sensores que pueden realizar tanto tareas de recepción como de transmisión de datos. El tamaño de dichos sensores va en relación con el coste y la sofisticación del nodo.

Además de por su facilidad de despliegue y su gestión eficiente de la energía, otra de las características más destacables de los nodos de sensores es su alta autonomía. Definida como la capacidad de autoconfiguración en el caso de que alguno de los nodos deje de funcionar, pudiéndo seguir un camino alternativo para la transmisión de información hacia el nodo destino.

Si hablamos de desventajas, podríamos clasificarlas en dos grandes grupos. En uno de ellos encontraríamos la limitación hardware en cuanto a autonomía de batería o su exposición a numerosos fallos, como ausencia de control directo humano. Por lo que deben de tener la suficiente energía como para maximizar la vida útil. En cuanto a las desventajas software hay que tener en cuenta que debe incluir algoritmos sencillos y de rápida ejecución, eficientes algoritmos para el enrutamiento y protocolos de acceso que proporcionan un bajo consumo de energía.

Al contrario de lo que ocurre con las redes tradicionales, la precisión de las redes de sensores dependerá de lo extensa que sea la aplicación y de la coordinación existente entre sus motas.

Como ya se ha indicado, los nodos usados en las redes de sensores pueden alojar sensores que midan variables (humedad, temperatura, presión, vibración, cobertura…) y sean enviadas a la estación base para su tratamiento.

Aunque un sensor es capaz de procesar una cantidad limitada de información, en coordinación con un conjunto de más nodos, es capaz de realizar medidas físicas en gran detalle, anticipándose a las necesidades humanas y mejorando el comportamiento de los sistemas.

Las WSN pueden presentarse en numerosas configuraciones (estrella, malla e híbrida). Sin embargo se hace interesante conectarlas a otras redes para permitir su acceso remoto.

U

Entorno de trabajo

4

Originariamente, las redes inalámbricas despertaron gran atención entre los investigadores del ámbito militar que vieron la posibilidad de facilitar no sólo la navegación o comunicación, sino también la localización de bunques enemigos durante las guerras con la utilización del conocido “SONAR” (técnica basada en la emisión de impulsos sonoros bajo agua que actuaban de modo similar a las señales radar) [4]

Actualmente, su uso no sólo está orientado a aplicaciones militares:

-Agrícolas: Se prevé que la implantación de redes de sensores se haga con mayor rapidez en este sector: en el que estas redes benefician a la agricultura mediante el ahorro en costes en cuanto al uso de agua y pesticidas necesarios. Además de prever posibles cambios climatológicos, como heladas, permitiendo así la pronta actuación preservando el entorno.

Para percatarnos de los beneficios causados, es interesante mencionar que en los últimos años se ha implantado la conocida “Agricultura de precisión” como consecuencia de la presencia de las TIC y que han permitido la optimización del rendimiento en explotaciones a través del preciso conocimiento del medio como el control de plagas y enfermedades. [5]

-Industriales: Planificación de recursos empresariales, comunicación inalámbrica o cableada, cadenas de producción…

-Médicas.

-Domótica/Hogar Inteligente.

-Entornos ambientales: Protección y mantenimiento de zonas naturales o de interés turístico.

-Monitorización del entorno: Tráfico, seguridad, medidas para la optimización de servicios locales…

-Localización.

-Aplicaciones civiles y militares: El empleo de la arquitectura software Irisnet es un buen ejemplo de ello (Intel). Se trata de una herramienta mundial de gestión de acceso a redes de sensores que ha permitido llevar a cabo aplicaciones como vigilancia de niños o personas mayores, seguridad, observatorios terrestres y marítimos…[6]

Una de las principales casas en tecnologías para redes inalámbricas es Crosssbow, capaz de dar solución en redes mediante desarrollo hardware y software. Entre sus numerosos productos, se encuentran los módulos Micaz, empleados a lo largo de éste trabajo para el estudio preciso de medidas de distancia.

2.2 Hardware

Para la realización de nuestro proyecto usaremos el kit comercial Mote-Kit2400 empleado para desarrollo, pruebas de medida e implementación de redes de sensores inalámbricos profundamente arraigadas.

Estos módulos pertenecen a la familia de componentes MICAz, cuya frecuencia de trabajo es de 2.4 GHz. Ofrecen una alta velocidad en transmisión de datos (250 kbps).

Utiliza el método de espectro ensanchado por secuencia directa (DSSS) como método de codificación, haciendo uso de un código de pseudorruido de forma que se reduce notablemente la densidad espectral de potencia y se aumenta el ancho de banda. Esto permite que la señal sea camuflada entre el ruido y sólo pueda ser decodificada por el receptor deseado.

La plataforma que vamos a emplear se corresponde con una de las plataformas con mayor número de limitaciones hardware.

5 Modelo de estimación de la distancia en interiores basado en medida RSSI en una WSN

Figura 2-1. Componentes Mote-Kit2400

Su uso está ligado a aplicaciones como:

- Monitorización y seguridad en construcciones Industriales y Residenciales

- Redes automovilísticas

- Consumo electrónico inteligente

- Sistemas y sensores en redes Zigbee

En detalle, este kit está compuesto por los módulos:

- 8 Plataformas con Procesador Radio MICAz (MPR2400CA)

- 4 placas sensoras MTS310CA con termómetro, fotocélula, acelerómetro, sensor magnético, micrófono y zumbador.

- 3 placas sensoras MTS300CA con termómetro, fotocélula, micrófono y zumbador.

- 1 placa sensora MDA300CA con termómetro y medidor de la humedad.

- 1 tablero MIB600 con interfaz Ethernet.

- 1 tarjeta MIB520 con interfaz DB-9 (macho-hembra) y cable RS-232.

- 1 carcasa MDA300CA indoor MDA300.

- Software (Incluye Manual Hardware de Usuario) para el desarrollo de aplicaciones e instalación del sistema operativo TinyOS.

Además necesitaremos de:

- 1 PC con sistema operativo Linux.

Entorno de trabajo

6

2.2.1 Procesador y plataforma radio MPR2400CA

Las motas se comunican entre sí a través del canal radio, enviando y recibiendo mensajes a una frecuencia previamente fijada. Para ello, son necesarios una serie de elementos integrados en el módulo MPR2400CA.

El MPR2400 de Texas Instrument está basado en el controlador de baja potencia Atmel ATmega128L y trabaja en el rango de los 2400MHz-2483.5MHz.

Además, la placa dispone de 3 leds accesibles al usuario para uso en forma de bandera, para facilitar las pruebas o el aviso en la ocurrencia de algún evento.

Figura 2-2. MPR2420CA

Donde la numeración hace referencia a:

1. Antena para comunicación radio, ZigBee (802.15.4)

2. Microprocesador ATMEL Mega128L

3. Conector de expansión de 51 pin macho para periféricos

4. LEDs: rojo, verde y amarillo

5. Interruptor ON/OFF


Figura 2-3. Diagrama de bloques MPR2400 CA

Emplea como transceptor radio el dispositivo de bajo coste Chipcon CC2420, lo que le aporta interesantes características en el ámbito de las comunicaciones inalámbricas como:

- Capacidad anti-interferencia de canal adyacente

- Modulación O-QPSK

- Alta sensibilidad

- Bajo consumo

- Programación de potencia de salida controlable

- Los bytes en RX y TX siguen un esquema de funcionamiento de cola FIFO (First In First Out, es decir, el primer byte en recibirse a la entrada, es el primer byte en llegar a la salida)

- Interfaz SPI de fácil configuración

- Antena PCB con un alcance de entre 20-50 metros en línea recta.

Entorno de trabajo

8

Figura 2-4. Módulo RF2420

El conector de expansión de 51 pines de las motas MICAz es capaz de soportar entradas analógicas, digitales, I2C, SPI e interfaces UART. Interfaces que facilitan la conexión a una amplia variedad de periféricos externos.

2.2.2 Placas sensoras MTS300CA

Placas sensoras con una amplia variedad de modos de detección, lo que facilita su uso y las hace eficientes para un gran número de aplicaciones (detección en vehículos, detección sísmica, aplicaciones robóticas…).

- Microfono para medición y grabación acústica.

- Timbre de 4 kHz de frecuencia.

- Luz y Temperatura

- Acelerómetro

- Magnetómetro

- Fotocélula


Figura 2-5. Conexionado de pines de las placas sensoras MTS300CA

2.2.3 Placas sensoras MTS310CA

Similares a las placas de sensores MTS300CA. Con mismo esquemático de conexiones, salvo que además la placa sensora MTS310CA incluye:

- Magnetómetro de dos ejes Honeywell HMC1002

- Acelerómetro de dispositivos analógicos ADXL202JE

Entorno de trabajo

10

2.2.4 Placas sensoras MDA300CA

Se trata de una tarjeta de adquisición de datos que permite la interconexión de distintos tipos de sensores a la red en la que se trabaja tanto para MICAz como para MICA2.

Figura 2-6. Vista frontal de las placas sensoras MDA300CA [3].

Figura 2-7. Diagrama de bloques MDA300 CA

Versátil en áreas que van desde medidas de parámetros medioambientales, monitorización del hábitat, control en ámbito de la agricultura, análisis de suelos hasta control de procesos a distancia.

Dispone de 17 salidas, de las cuales 11 de ellas son para salidas analógicas y diferenciales mientras que las otras 6 son para salidas digitales. Aunque éstas 6 podrían emplearse como pines I/O. Además posee 3 pines de 2.5, 3.3 y 5V.


2.2.5 Tablero MIB520

Figura 2-8 Placa programadora MIB520

También conocida como programming board o mota programadora. En este proyecto resulta de gran utilidad para permitir cargar código en las dos motas empleadas, tanto transmisora como receptora.

Posee dos puertos serie con funciones diferenciadas. Mientras uno de ellos es usado para la programación como se indica en el párrafo anterior, el otro es destinado como puerto de salida realizando la función de puerta de enlace entre las motas y el PC. En nuestro caso, el puerto de salida nos será útil para obtener los valores calculados de potencia recibida.

En la Figura 2-9 se muestra el modo de acoplo de una mota MICAz para su programación gracias al conector de 51 pines.

Figura 2-9. MIB520 con mota micaZ acoplada

Entorno de trabajo

12

Figura 2-10. Esquemático/Conexionado de la placa programadora MIB520

El programador incorpora 3 LEDs que nos indican si la placa está conectada a corriente (LED verde) y si están cargando los datos en la mota acoplada (LED rojo). Además, incorpora un interruptor para deshabilitar la transmisión serie y un botón de reset.

La placa se alimenta a 5 voltios y unos 50 mA de corriente. La mota acoplada se alimenta a través de la placa programadora conectada al PC mediante USB.

Permite la agregación de los datos de redes de sensores en un PC, así como otras plataformas de ordenador estándar.

Soporta distintos tipos de baterías, aunque su elección es importante para cubrir las necesidades energéticas de las motas y su misión de despliegue.

Posee un procesador a bordo para programar el procesador radio (ISP) de la mota (AtMega16L). También se encarga de monitorizar el valor del voltaje, desactivando la programación si el nivel de tensión no se encuentra en el rango requerido. El procesador se conecta a dos LEDs, uno verde etiquetado como “SP PWR” que informa sobre el estado de energía de la MIB520, y otro rojo etiquetado como “ISP” para indicar el control del puerto serie por parte de la MIB520. Este último parpadeará también cada vez que se pulse el botón RESET para indicar evento.


2.2.6 Tablero MIB600

También conocido como Estación Base (Gateway). En el caso de existir Gateway, recoge los datos obtenidos por éste en la red de sensores.

Se trata de un elemento destinado a la interconexión de redes de sensores y una red TCP/IP. Este tablero de programación con interfaz Ethernet (10/100 Base-T) posibilita la conexión desde un PC.

El dispositivo contiene en una plataforma 4.5” × 2.25:

- Una mota MICA2 con conector de 54 pines (J1).

- Tarjeta con puerto JTAG (J12).

- Servidor serie IP TCP.

- Programador compatible con UISP STK500.

- Regulador de potencia.

- Suministro de alimentación a través de Ethernet (POE).

Figura 2-11. Estación Base

La placa de la estación base empleada en el proyecto realizado se encuentra recubierta de un cuerpo protector de plástico.

2.2.7 IEEE 802.15.4

Las redes inalámbricas de área personal se desarrollan bajo el estándar ZigBee IEEE 802.15.4, el cuál surge de entre un grupo de protocolos simples con el objetivo de proporcionar comunicaciones seguras con flexibilidad en la red, bajo costo y bajo consumo de energía gracias al envío de datos de baja tasa.

Basada en la técnica de acceso al canal con prevención de colisiones CSMA/CD (Carrier Sense Multiple Acces with Collision Detection). Se trata de un protocolo mejorado de acceso a medio compartido mediante el cúal es posible “escuchar” el medio para detectar si existen recursos libres para transmitir en el momento deseado.

Entorno de trabajo

14

ElestándarIEEE 802.15.4 especifica en total 27 canales semidúplex a través de 3 bandas de frecuencias sin licencias dependiendo del área geográfica donde nos encontremos. La distribución de los canales se representa en la Figura 2-12.

Figura 2-12. Distribución de canales IEEE 802.15.4

Tal y como indica el estándar, la transmisión se organiza en tramas, aunque pueden variar en función de la finalidad. Existen 4 estructuras de trama, cada una de ellas conocida como PPDU (Unidad de Datos de Protocolo Físico): una trama de baliza, una trama de asentimiento o ACK, y un marco de comandos MAC. [7]

Como se muestra en la Figura 2-12, hemos dividido la canalización en dos grupos distinguidos. En función de la frecuencia transmitida, se empleará una u otra velocidad de transmisión. Es decir, la transmisión se realiza a 20 kbps para el caso de las frecuencias 915/868 MHz, mientras que aumenta a 250 kbps para frecuencias en el rango de 2.4 GHz.

Las redes ZigBee permiten hasta un total de 255 nodos. Aunque puede parecer un gran número de nodos, es interesante tener en cuenta que el transmisor ZigBee se encuentra “dormido” durante gran parte del tiempo como medida para el ahorro de energía.

2.3 Software

Para llevar a cabo nuestra aplicación necesitaremos un sistema operativo Ubuntu 8.04 y TinyOS 2.1.

Un sistema operativo (OS) se podría definir como el programa que permite la comunicación entre el hardware existente del ordenador y el usuario. Permite coordinar diversos recursos del sistema (disco duro, memoria, dispositivos periféricos) y acceder a ellos mediante numerosas interfaces.

La plataforma MICAz corre sobre TinyOS 1.1.7. de código abierto y versiones posteriores. Además de ser compatible con las redes en malla software Crossbow, ofrece herramientas de desarrollo transversales, servidor middleware para integración de red de empresa e interfaz de usuario al cliente para el análisis y configuración.


Actualmente existen varios sistemas operativos basados en redes de sensores. En esta sección discutimos sobre TinyOS y su lenguaje de programación, nesC.

2.3.1. TinyOS

Aunque se puede ver como un sistema operativo de código abierto diseñado exclusivamente para su manejo en redes inalámbricas de sensores, realmente es un entorno de programación altamente modular para sistemas integrados con funciones específicas en ciertas aplicaciones diseñado por la Universidad de Berkeley. De tal forma que se minimice la cantidad de código en cada aplicación para tener en cuenta las limitaciones en cuanto a memoria de los sensores. Además, también tiene en cuenta las limitaciones de energía y su alto nivel de ocurrencia.

Para satisfacer dicho requisito de gestión en la eficiencia y ahorro de energía, emplea un modelo a eventos. Mientras que satisface el requisito de la modularidad como veremos más adelante y de forma más extensa, a través de un modelo a componentes. [8]

Incluye una amplia librería de drivers, herramientas de adquisición de datos, protocolos de red y servicios distribuidos implementados para su uso.

Además, soporta diferentes plataformas de nodos de sensores, arquitecturas bases para el desarrollo de aplicaciones.

Está organizado en capas y escrito en el lenguaje de programación nesC. A pesar de que su sistema nativo sea Linux, es instalable en distintos sistemas operativos de propósito general. Las plataformas apoyadas son Linux (RedHat 9), Windows 2000, y Windows XP [9]

La ejecución de nuestra aplicación la haremos sobre el sistema operativo Ubuntu. Para ello, utilizamos una imagen virtual pre-cofigurada de Xubuntu.

Si buscamos instalarlo en un entorno Windows, deberemos instalar el emulador Cygwin para obtener una interfaz basada en línea de comandos, similar a lo que sucede en Unix para disponer de las herramientas necesarias para desarrollar e implementar una red de sensores. Al instalar el sistema TinyOs en nuestra estación de trabajo, se genera una estructura de directorios de la forma /opt/TinyOs-x.y.x donde “x.y.z” denota la versión del sistema que hallamos instalado.

Además de este directorio, en TinyOS podemos comprobar que se forma una estructura de directorios dada por:

• /apps: es el directorio de desarrollo por defecto para las nuevas aplicaciones. • /support: contiene el código fuente del Toolchain. • /tos: subdivido en:

o /chips: información acerca de los microcontroladores más usuales. o /interfaces: almacena el código que define las interfaces o /lib: contiene componentes e interfaces del sistema y de las distintas plataformas

soportadas por TinyOS. o /platforms: particulariza los códigos genéricos de algunos componentes en los específicos

necesarios para cada plataforma permitiendo su ejecución. o /sensorboards: ficheros específicos de cada una de las placas sensoras que componen el

kit empleado. o /system: contiene los componentes primitivos que proporciona TinyOS. o /types: incluye los tipos que se usan en las primitivas de TinyOS.

Una vez instalado y correctamente configurado, TinyOs proporciona el compilador y los comandos necesarios para poder compilar e instalar aplicaciones en nodos inalámbricos.

En la programación de sensores podemos encontrar una variedad de lenguajes de programación para generar y depurar código, como:

- NesC: lenguaje que utilizamos para nuestras motas, directamente relacionado con TinyOS.

Entorno de trabajo

16

- Protothreads: específicamente diseñado para la programación concurrente, provee hilos de dos bytes como base de funcionamiento.

- SNACK: facilita el diseño de componentes para redes de sensores inalámbricas, sobre todo cuando la información o cálculo a manejar es muy voluminoso, complicado con nesC, este lenguaje hace su programación más eficiente. Luego es un buen sustituto de nesC para crear librerías de alto nivel a combinar con las aplicaciones más eficientes.

- C@t: iniciales que hincan computación en un punto del espacio en el tiempo (Computation at a point in space (@) Time)

- DCL: Lenguaje de composición distribuido (Distributed Compositional Language) - GalsC: diseñado para ser usado enTinyGALS, es un lenguaje programado mediante el modelo

orientado a tarea, fácil de depurar, permite concurrencia y es compatible con los módulos nesC de TinyOS

- SQTL (Sensor Query and Tasking Language): como su nombre indica es una interesante herramienta para realizar consultas sobre redes de motas.

En nuestro caso emplearemos el lenguaje de programación nesC que describiremos más adelante.

2.3.2. nesC

NesC, proveniente de las siglas “network embedded systems C”, red de sistemas embebidos C (en español)

Perteneciente a la familia de lenguajes de programación conocidos como “lenguajes orientados a componentes”. Se trata de un dialecto estructurado del lenguaje de programación C destinado a sistemas embebidos. Algunas herramientas en Java y Bash completan su uso. Orientación a componentes se refiere al modo en el que se conciben las aplicaciones definidas.

NesC contiene un subconjunto de características de las librerías de C con algunos comandos y eventos adicionales que ayudan a mejorar la eficiencia de los programas escritos en el lenguaje. De hecho, nesC posee los espacios de nombres de C.

Además posee variadas herramientas que ayudan el estudio y desarrollo de aplicaciones para las redes de sensores, que van desde aplicaciones para la obtención y manejo de datos, hasta sistemas completos de simulación.

Se distinguen dos tipos de componentes según formen parte de TinyOS o sean desarrollados por el programador. A los primeros se les conoce como componentes nativos y permiten llevar a cabo las principales funcionalidades de las motas. Los segundos, por otro lado, generan funcionalidades específicas según la aplicación que se desarrolle y se les conoce como componentes no nativos.

Al provenir del lenguaje de programación C, tratamos los tipos de datos existentes en éste, además de contar con los siguientes:

- uint16_t es un entero sin signo de 16 BIT - uint8_t es un entero sin signo de 8 BIT - bool es un booleano con los posibles valores (TRUE, FALSE) - result_t es un booleano con los posibles valores SUCCES y FAIL

Un programa típico nesC se compone de 3 secciones: interfaz, uno o varios módulos y un archivo de configuración que muestra las conexiones entre los distintos módulos. Todo componente debe de poseer éstas 3 secciones obligatoriamente, aunque estén vacías.

- Interfaces. En la definición se declara su nombre, comandos y eventos. Todo ello en un fichero con extensión *.nc. Dicho de otro modo, este fichero define el modo de interacción bidireccional entre dos componentes, a los que llamaremos proveedor y usuario. Por lo que se definen como su único punto


de acceso.

Las interacciones a través de interfaces se especifican a través de dos conjuntos de funciones:

o Comandos, estos son llamadas de función desde el usuario al componente de capas inferiores de proveedor para poder enviar órdenes al componente desde el exterior. El proveedor de una interfaz implementa los comandos, mientras que el que las utiliza implementa los eventos.

o Eventos, llamadas de función desde el proveedor al componente de usuario de capas superiores, para que el componente pueda enviar notificaciones hacia el exterior, a otros componentes conectados a él, es decir, al hardware.

Es importante darse cuenta de que como hemos indicado arriba, al ser las interfaces bidireccionales que especifican un conjunto de funciones para ser implementado por el proveedor de la interfaz (comandos) y un conjunto para ser implementado por el usuario de la interfaz (eventos), podemos emplear una única interfaz para representar una completa y compleja interacción entre componentes.

Los componentes se encuentran estáticamente vinculados entre sí a través de sus interfaces. Esto aumenta la eficiencia en tiempo de ejecución, ayudando a conseguir un diseño robusto, y permitiendo un mejor análisis estático de programas. nesC está diseñado bajo la expectativa de que el código será generado por los compiladores de todo el programa. Esto también debe permitir una mejor generación de código y análisis. [10]

• Módulos. Componente que implementa una o más interfaces, por lo que puede implementar una o más funcionalidades. Se estructura en 3 partes: Provides (interfaces que provee), Uses (interfaces que usa) y Implementation (comportamiento del modulo)

• Configuración. Archivo formado por módulos. Indica cómo se encuentran conectados los componentes entre sí. Generalmente se deja vacío.

Figura 2-13. Esquema de aplicación vista como un conjunto de componentes interconectados entre sí. [16]

Entorno de trabajo

18

TinyOS es el entorno de tiempo de ejecución de los programas de nesC. El comportamiento de un programa nesC está por lo tanto muy relacionada con el modelo de ejecución de interrupción impulsada de TinyOS. Las tareas son cálculos diferidos, los cuales están programados en orden FIFO (First in, First out). El modelo de concurrencia de nesC está basado en la ejecución completa de tareas (se ejecutan hasta su finalización, es decir, sólo después de completar una tarea, puede iniciarse la ejecución de una nueva tarea) y manejadores de interrupciones que permiten interrumpir dichas tareas en caso de que fuese necesario.

Figura 2-15. Pasos en la compilación de una aplicación TinyOS. [17]

También se podría decir que los componentes se estructuran en 2 ficheros (por convenio) llamados “configuración e implementación” y “módulos”, además de las librerías (.h) que puedan usar.

Estos dos ficheros tienen extensión .nc. Para nombrarlos se sigue el convenio de usar el mismo nombre para ambos, acabando el fichero de módulos con una “M” al final.

Por ejemplo, “miaplicacion.nc” (fichero de configuración e implementación)

Figura 2-14. Diagrama comandos y eventos. [9]


“miaplicacionAppC.nc” (fichero de módulos)

Un componente puede ser una configuración o un modulo. A continuación veremos las dos formas de especificarlo:

- Especificación de un componente como un módulo

Archivo nesC de “miaplicacionAppC.nc”:

includes [nombre de librerías y .h si es necesario]

module [nombre del modulo] {

Uses {}

Provides {}

}

Implementation {}

En Provides se especificarán las interfaces que proporciona el componente (el modulo tendrá que tener implementadas las funciones de dicha interfaz).

En Uses se especifican las interfaces que va a usar el modulo (en la parte de Wiring se establece qué modulo proporciona dicha interfaz).

En Implementation debemos definir el comportamiento de la aplicación. Esta parte como mínimo debe incluir:

- Las variables globales - Las funciones de las interfaces que proporciona (Provides) - Los eventos de las interfaces que utiliza (Uses)

En un módulo puede haber varios Uses y varios Provides ya que pueden usar o proveer varias interfaces.

Estos Uses y Provides se pueden especificar en grupo o con varias instrucciones simples:

Uses {

Interface X: Uses interface X:

Interface Y: Uses interface Y:

}

Si usamos una interfaz (Uses):

- Podemos llamar a sus métodos. - Tenemos que implementar los eventos que se van a producir por utilizar la interfaz. - Hay que realizar el Wiring en el fichero correspondiente para indicar quien proporciona la interfaz.

Cuando especificamos un componente como un modulo, se debe incluir en la parte de Implementation{} de este, todos los comandos o eventos provistos por ese modulo, así como también los comandos de las interfaces que provea y todos los eventos de los interfaces que use.

Un modulo puede llamar a cualquiera de sus comandos y señalar cualquiera de sus eventos.

Entorno de trabajo

20

- Especificación de un componente como una configuración

Un componente se enlaza a otros a través de sus interfaces. Estos enlaces se definen en la parte de Wiring (Implementation) de este archivo de configuración, con la instrucción ->. Más adelante se detallan las variantes para enlazar interfaces.

Suponiendo que se desee enlazar el componente nombre1 con el componente nombre2, cuyos interfaces respectivos son interfaz1 e interfaz2, el wiring se haría de la siguiente forma:

Archivo nesC de “miaplicacion.nc”:

includes [nombre de librerías y .h si es necesario]

configuration [nombre de la configuración] {}

Implementation{

Components nombre1, nombre2:

nombre1. interfaz1-> nombre2. interfaz2:

}

Podemos diferenciar dos tipos de componentes, según sean proporcionados por TinyOS, en cuyo caso hablaremos de componentes Primitivos, o proporcionados por alguna librería o aplicación. En éste último caso hablaremos de componentes Compuestos.

Los componentes usados para interconexionado (InterNetworking) son los componentes primitivos para redes. Estos se basan en un paquete TOSMsg.

Entre este tipo de componentes, se encuentran los componentes GenericComm y GenericCommPromiscuous, que son usados para enviar y recibir paquetes por radio o UART y proporcionan las interfaces SendMsg y RecibeMsg (para envío y recepción).

Su comportamiento es similar al de un switch (si reciben un paquete con dirección UART lo envían por el puerto serie y si reciben otra dirección lo envían por radio).

Otro componente de gran utilidad es el componente TimerC, que ofrece funciones de temporización mediante la interfaz Timer parametrizada.

Timer.nc

interface Timer { command result_t start (char type, uint32_t interval): command result_t stop(): event result_t fired(): }

En este ejemplo vemos cómo la interfaz Timer implementa los comandos start() y stop() y el evento fired(). El comando start() especifica el tipo de temporizador y el intervalo en que expirará el temporizador. La unidad del argumento intervalo es milisegundo.

Los tipos válidos son TIMER_REPEAT y TIMER_ONE_SHOT. Un temporizador de un solo disparo termina después del intervalo especificado, mientras que un temporizador de repetición sigue y sigue hasta que es detenido por el comando stop(). La aplicación sabrá que su temporizador ha expirado al recibir el evento:


event result_t fired():

A continuación, trataremos la configuración de interfaces. Las interfaces se especifican por tipos de interfaces, de la forma:

Archivo nesC:

interface X {

command tipo_devuelto nombreComando(lista de parámetros):

event tipo_devuelto nombreEvento(lista de parámetros):

}:

Dentro de la especificación de la interfaz se deben definir las declaraciones de las funciones usando command o event para los comandos o los eventos tal como describimos. En caso contrario ocurrirá un error en tiempo de compilación.

Un ejemplo de interfaz simple, que emplearemos en nuestro código sería:

interface SendMsg {

command result_t send(uint16_t addr, uint8_t length, TOS_MsgPtr msg):

event result_t sendDone(TOS_MsgPtr msg, result_t success):

}

Para aclarar las diferencias entre “comandos y eventos” podemos decir que los componentes proveedores del tipo de interfaz SendMsg deberán implementar el comando send, mientras que los usuarios de esta interfaz implementarán el evento sendDone.

Declarar una instancia de una interfaz es tan sencillo como usar la palabra reservada “interface”:

interface X [lista de parámetros opcional]:

Otra opción sería:

interface X as X:

interface X as Y:

donde X e Y se refieren al nombre de la instancia.

Algunas interfaces especiales y útiles en el desarrollo de éste proyecto son las interfaces de transmisión y recepción:

- Interfaz SplitControl. Sirve para arrancar o parar el módulo radio. Proporciona un comando para inicializar el módulo radio, y otro para pararlo. Esta interfaz obliga a tener las funciones Init(), Start() y Stop()

o Void Init(): Se ejecutará al arrancar el sistema. Inicializa las variables globales y llama a los métodos init() de los componentes que utiliza

o Void start(): Se ejecutará después del init() y cuando el sistema pase de off a on. Arranca los temporizadores y llama a los métodos start() de los componentes que utiliza

o Void stop(): Se ejecutará cuando se apague el sistema o se suspenda. Llama a los métodos stop() de los componentes que utiliza.

Entorno de trabajo

22

- Interfaz Packet. Proporciona varias utilidades a través de comandos: borrar el contenido de un mensaje, conocer el tamaño de la carga útil o establecer un puntero a la misma.

- Interfaz AMSend. Es la interfaz básica de envío de un mensaje con una dirección de destino. Esta

dirección se asigna a cada nodo en el momento de compilar la aplicación.

- Interfaz Receive. Es la interfaz básica para recepción de mensajes. Tiene un evento que indica la recepción de un nuevo mensaje, y comandos para establecer un puntero a la carga útil y obtener su tamaño.

- Interfaz PacketAcknowledgements. Proporciona un mecanismo de asentimientos ACK de

recepción de paquetes. Estas cinco interfaces proporcionan comunicación 802.15.4, es decir, a nivel de capa de enlace. Esto implica que sólo se controla la comunicación entre nodos adyacentes, no teniendo capacidad para establecer rutas de red correspondientes a un protocolo de nivel 3.

- Interfaz SendMsg. Si usamos la interfaz SendMsg de un componente GenericComm podemos usar la función: Send (addres, long_datos, TOSMsg) que envía el paquete TOSMsg (que debe ser una variable global) a la dirección indicada addres. Pero se debe implementar el evento SendDone().

Del paquete TOSMsg solo se rellena el campo Data (con una estructura del tipo de mensaje que se haya elegido).

- Interfaz ReceiveMsg. Si usamos la interfaz ReceiveMsg de un componente no podemos usar ninguna función, pero sí hay que implementar el evento de recibir un mensaje. Se recibe un mensaje en el caso de que la dirección destino del mensaje coincida con nuestro TOS_LOCAL_ADDRESS o sea un mensaje de difusión, TOS_BCAST_ADDR. En el caso de ser el componente GenericCommPromicouos siempre recibimos todos los mensajes, sea cual sea la dirección destino.

Los comandos y eventos proporcionados por estos componentes son los siguientes:

- Comando SplitControl.Start: inicializa el módulo radio. - Comando SplitControl.Stop: detiene el módulo radio. - Evento SplitControl.StartDone: se activa cuando se ha terminado la inicialización del módulo

radio, y si ha sido satisfactoria o no. - Comando AMSend.Send: se encarga de enviar un mensaje. Genera el evento AMSend.sendDone,

cuando el mensaje ha sido enviado (pero no necesariamente recibido por el destino). - Evento AMSend.sendDone: se activa cuando se ha enviado el mensaje al canal radio. - Evento Receive.receive: se activa cuando se ha recibido un nuevo paquete por la interfaz radio. - Comando Packet.getPayload: obtiene la dirección de memoria correspondiente a los datos del

mensaje, sin cabeceras. - Comando PacketAcknowledgements.requestAck: sirve para solicitar un servicio de transmisión

con asentimiento de entrega de mensaje. - Comando PacketAcknowledgements.wasAcked: sirve para comprobar si se ha recibido

asentimiento de un mensaje enviado anteriormente.

- Llamadas a comandos y señalización de eventos

Un comando X puede llamarse con la instrucción: call X (. . .). Un comando parametrizado Y, con n parámetros de interfaz es llamado call Y [e1, e2... en] (. . .).

Un evento X puede señalarse con la instrucción: signal X (. . .). Un evento parametrizado Y, con n parámetros de interfaz [e1, e2... en] es llamado signal Y [e1, e2... en] (. . .).


La ejecución de comandos y eventos es inmediata. Las actuales implementaciones de comandos y eventos ejecutadas por las expresiones call y signal dependen de las declaraciones de las interconexiones (wiring) en las configuraciones del programa. Estas declaraciones pueden especificar que 0, 1 o más implementaciones tienen que ser ejecutadas.

Un módulo puede especificar una implementación por defecto para un comando o evento X que use y que sea llamado o señalizado.

Las implementaciones por defecto se ejecutan cuando el módulo no está conectado a ninguna implementación del evento o comando cuado éste se señale o se llame. Para definir un comando o evento por defecto se añade la palabra “default” delante de la palabra “command” o “event”.

- Tareas

Una tarea es un contexto de ejecución que corre hasta completarse en background, sin interferir en otros eventos del sistema.

Para definir una tarea y su función se usa: task void myTask() {...}. Es posible declarar antes la tarea sin devolver argumentos: task void myTask(). Para llamar a la tarea e iniciarla usaremos: post myTask().

Esta última llamada devuelve un unsigned char con valor 1 si la tarea fue planificada correctamente para una ejecución independiente, y 0 en cualquier otro caso.

- Concurrencia en nesC

El diccionario define la palabra concurrencia como: coincidir en el espacio o en el tiempo dos o más personas o cosas. En Informática, se habla de concurrencia cuando hay una existencia simultánea de varios procesos en ejecución.

NesC asume un modelo de ejecución que consiste en ejecución para completar las tareas (el cómputo en curso) y manejadores de interrupción que son señalados asíncronamente por hardware.

Una planificación de nesC puede ejecutar las tareas en cualquier orden, pero se debe cumplir la regla de ejecutar-para-completar.

Como éste es un modelo de ejecución concurrente, los programas de nesc son susceptibles de condiciones de competición, en particular de competición entre datos en estados. El compilador de nesC avisa de potenciales competiciones de datos en el programa en tiempo de compilación.

Formalmente se divide el código de nesC en dos partes, código síncrono (SC) y código asíncrono (AC). El SC es código (funciones, comandos, eventos, tareas) solo alcanzable desde las tareas. El AC es código alcanzable al menos por un manejador de interrupciones [11].

NesC reporta errores de compilación por cualquier comando o evento que sea AC y no haya sido declarado como tal. Es decir, con la palabra reservada “async”. Esto asegura que el código que no fue escrito para ejecutar de forma segura en un manejador de interrupciones, no sea llamado de forma inadvertida.

2.3.1.1 Ejemplo de aplicación nesC: Blink

Recordamos que una aplicación en nesC se compone de al menos 3 ficheros:

- Fichero de implementación o Wiring. Se decide que la interfaz que usa una aplicación es la que proporciona un componente.

- Fichero de configuración. Permite la configuración del componente. Usado generalmente para crear librerías.

- Makefile. Se trata del código C que define el comportamiento de la aplicación. Se estructura en 3

Entorno de trabajo

24

partes: Provides (interfaces que provee), Uses (Interfaces que usa) y Implementation (comportamiento del módulo).

El programa "Blink" es un programa de prueba que se encuentra en apps / Blink en el árbol de TinyOS. Esta aplicación simplemente hace que los LEDs conmuten de modo que simule un contador binario que se incrementa con una frecuencia de 0,25 Hz.

La aplicación se compone de dos componentes: un módulo, llamado “BlinkAppC.nc”, y una configuración, llamado "Blink.nc". Blink.nc se utiliza para conectar el módulo de BlinkAppC.nc a otros componentes que la aplicación pueda requerir [12].

2.3.1.1.1 FicherodeconfiguraciónBlink.nc configuration Blink {

implementation { components Main, BlinkM, SingleTimer, LedsC: Main.StdControl -> BlinkM.StdControl: Main.StdControl -> SingleTimer.StdControl: BlinkM.Timer -> SingleTimer.Timer: BlinkM.Leds -> LedsC: }

}

Podemos observar que la línea que contiene “components” especifica el conjunto de componentes que se referencian en esta configuración, en éste caso Main, BlinkM, SingleTimer y LedsC y tres instancias del componente TimerMilliC identificadas como Timer0, Timer1 y Timer2. TimerMilliC es un componente genérico y, a diferencia de los no genéricos, puede ser instanciado más de una vez. Los componentes genéricos pueden recibir como argumentos tanto variables como constantes, aunque en éste ejemplo no es necesario. A cada una de las instancias se le asigna un identificador con la palabra clave as.

El resto de la aplicación consiste en conectar interfaces utilizadas por los componentes a las interfaces proporcionadas por otros.

Main es un componente que se ejecuta por primera vez en una aplicación de TinyOS. Para ser precisos, el comando Main.StdControl.init() es el primer comando ejecutado en TinyOS seguido de Main.StdControl.start (). El resto de Blink.nc consiste en ensamblar las interfaces usadas por el componente BlinkC a las interfaces provistas por los componentes MainC, TimerMilliC y LedsC. La línea del código: BlinkC.Leds -> LedsC: Ensambla la interfaz Leds usada por el componente BlinkC con la interfaz Leds provista por el componente LedsC. O, del mismo modo, la sentencia: BlinkC -> MainC.Boot: Ensambla la interfaz Boot usada por el componente BlinkC con la interfaz Boot provista por el omponente MainC.

2.3.1.1.2 Códigodecomponentetipomódulo


module BlinkM {

uses interface Timer<TMilli> as Timer0: uses interface Timer<TMilli> as Timer1: uses interface Timer<TMilli> as Timer2: uses interface Leds: uses interface Boot:

} implementation {

event void Boot.booted() {

call Timer0.startPeriodic(250): call Timer1.startPeriodic(500): call Timer2.startPeriodic(1000):

} event void Timer0.fired() {

call Leds.led0Toggle(): } event void Timer1.fired() {

call Leds.led1Toggle(): } event void Timer2.fired() {

call Leds.led2Toggle(): }

}

En la primera parte del código vemos cómo con la palabra clave module, refiere a que el archivo es un componente de tipo módulo llamado BlinkM y declara las interfaces que proporciona y las que usa, la cuales fueron previamente ensambladas en el archivo de configuración visto más arriba. El componente BlinkM usa tres instancias de la interfaz Timer<TMilli> a las que se han asignado los nombres numerados Timer0, Timer1 y Timer2, así como la interfaz Leds y la interfaz Boot. También conocida como interfaz de arranque.

En la segunda parte del código, se implementan los eventos de la aplicación y se realizan las llamadas a los comandos. BlinkC puede llamar y hacer uso de cualquier comando declarado en las interfaces que usa (indicadas en el párrafo anterior) y, además, debe implementar cualquier evento declarado en éstas. Es por ello por lo que implementa el evento Boot.booted(), incluido en la interfaz Boot, y el evento TimerX.fired(), contenido en cada una de las instancias de la interfaz Timer. La interfaz Leds, sin embargo, no declara ningún evento por lo que directamente se pueden invocar sus comandos con la palabra reservada call.

Visto éste último fichero, caemos en la cuenta de que nesC usa el operador “->” para determinar las relaciones existentes entre las interfaces. Así, el componente que usa una interfaz se encuentra a la izquierda, mientras que el componente que proporciona la interfaz está a la derecha del operador.

Entorno de trabajo

26

27

3 LOCALIZACIÓN EN INTERIORES

a localización es un problema fundamental en el diseño de redes de sensores inalámbricos. Ubicar la información puede ser utilizado en muchas aplicaciones de redes de sensores inalámbricos, como en eventos que impliquen detección, seguimiento de objetivos, monitorización ambiental…

Por otra parte, la información de ubicación también puede ser utilizada en diferentes protocolos de red con el objetivo de mejorar el rendimiento de las redes de sensores, tales como los paquetes de enrutamiento, el control de la topología de la red y la cobertura utilizando métodos geométricos.

Se optó por dotar a los sensores de configuración manual de ubicaciones ya que proporcionar a las redes de sensores con configuración aleatoria, implementación ad hoc, o redes de sensores móviles con un sistema de posicionamiento global (GPS) es caro y no resulta factible para redes de sensores de gran escala. Además de la limitación en duración de la batería de los nodos sensores empleados.

Otro punto en contra del posicionamiento global es que no es viable en entornos interiores debido a edificios que pueden bloquear las señales satelitales.

Por lo tanto, es importante desarrollar métodos de localización asequibles en los que los nodos sensores pueden calcular sus posiciones mediante el intercambio de información con algunos nodos cuya posición sea conocida. En este capítulo se ofrece una visión general de la localización mediante la introducción de métodos diseñados para redes de sensores inalámbricos.

Tanto fundamentos teóricos como desafíos de investigación son introducidos para dar soluciones a la localización a través de mediciones de distancia, ya sea nodo a nodo o mediante mediciones angulares.

3.1 Aspectos generales de localización en redes inalámbricas de sensores.

3.1.1 Introducción

La principal tarea de localización en redes de sensores inalámbricos es obtener la ubicación absoluta o relativa, para encontrar de modo preciso o aproximado la localización de cada sensor.

La información de localización obtenida es útil o incluso necesaria en muchos casos:

- Proporcionar información sobre la ubicación de un determinado evento cuando se detecta por los sensores.

- Proporcionar una secuencia de ubicaciones para el seguimiento de un objeto en movimiento mediante redes de sensores.

- La determinación de la calidad de la cobertura de todos los sensores activos utilizando sus posiciones.

- El control de la topología de la red basado en técnicas geométricas para mantener la conectividad y ahorrar energía.

- La toma de decisiones de enrutamiento basado en las posiciones del nodo actual, sus vecinos, y el destino mediante el enrutamiento basado en condiciones de reducir la sobrecarga de enrutamiento.

- Lograr el equilibrio de carga en los protocolos de enrutamiento mediante la difusión del tráfico basado en información de ubicación.

- Proporcionar información sobre la ubicación del usuario para varios servicios basados en la localización, como la búsqueda de servidores o impresoras cercanas.

- Apoyo de difusión geográfica.

L

Localización en interiores

28

Por todo esto, se han propuesto un gran número de métodos de localización clasificados principalmente en dos categorías: métodos de localización basados en alcance e independientes del alcance.

3.1.1.1 Métodos basados en alcance de la localización.

Entre los métodos de localización basados en alcance se encuentran:

- Método basado en la intensidad de la señal recibida (RSS, Received Signal Strength). Cuando las señales viajan en medios de comunicación, su fuerza disminuye con el aumento de la distancia que recorren. De acuerdo con este hecho, la señal indicadora de fuerza recibida en el receptor se puede utilizar para el cálculo de la distancia entre el receptor y el transmisor. La ventaja del método basado en RSS es que los nodos sensores no necesitan hardware adicional ni ninguna sobrecarga de comunicación adicional. Sin embargo, existe el inconveniente de la exactitud del método basado en RSS, puesto que está limitada por la exactitud del modelo de pérdida de trayecto. Hay que tener en cuenta algunos efectos incontrolables tales como desvanecimiento por trayectos múltiples, sombras y el terreno.

- Método basado en hora de llegada (ToA, Time of Arrival Signal). Estima la distancia entre dos nodos vecinos cualesquiera midiendo el tiempo que la señal tarda en viajar entre los nodos. Si conocemos la velocidad de propagación, la distancia es fácilmente calculable multiplicando la velocidad por el tiempo. Generalmente éste método es empleado en señales cuya velocidad de propagación es baja, como las ondas de sonido y ultrasonido. La resolución de ondas de radio inalámbricas no es del todo precisa. Por lo general, los métodos de ToA necesitan sincronización de tiempo.

- Método basado en diferencia de tiempo de llegada (TDoA, Time Difference Of Arrival). El método TDoA es similar al método ToA porque ambos utilizan el tiempo que la señal tarda en viajar entre dos nodos. A diferencia de ToA, TDoA emplea dos tipos de señales que viajan a diferentes velocidades, tales como señales de ultrasonido y RF, para superar la necesidad de sincronización explícita. Comparando con ToA, TDoA generalmente puede lograr una mayor precisión, pero necesita al menos dos tipos de emisores y receptores en cada nodo.

- Método basado en la diferencia de frecuencia de llegada (FDOA, Frequency-Difference Of Arrival). FDOA es una de las técnicas para lograr la ubicación precisa del emisor. Se trata de la medición de la diferencia entre la frecuencia recibida en dos receptores de un solo transmisor. Puesto que la diferencia en la frecuencia recibida es causada por las diferencias en el desplazamiento Doppler, FDOA es también llamado el Doppler diferencial.

Los tres métodos anteriores se centran en la medición directa de la distancia, pero existe otro método alternativo que se basa en medir ángulos para los nodos de referencia (cuyas posiciones son conocidas).

- Método basado en el ángulo de llegada (AoA, Angle of arrival). Los métodos basados en AoA suelen utilizar antenas direccionales o redes de antenas para medir el ángulo de una línea de conexión entre el dispositivo y el nodo de referencia. En un espacio de dos dimensiones, la angulación necesita dos mediciones de ángulos (ángulos a dos nodos de referencia) y una medición de la longitud (tales como la distancia entre dos nodos de referencia) para localizar un nodo. [13]

3.1.1.2 Métodos independientes del alcance

Los métodos independientes del alcance no emplean las anteriores técnicas de medición, sino que usan métodos alternativos, como la basada en contador de saltos de zona para localizar los nodos.

Debemos de tener en cuenta que para cumplir los requisitos de localización de grandes redes de sensores inalámbricos, los métodos de localización deben ser exactos (es decir, con pequeñas diferencias entre las posiciones estimadas y las verdaderas posiciones), distribuidos (es decir, que no dependan de la infraestructura centralizada), sólidos (es decir, capaz de medir los errores) y eficientes (es decir, teniendo poco coste computacional y que supongan pequeños gastos generales de comunicación).

Sin embargo, los métodos actuales generalmente pueden satisfacer tan sólo uno o algunos de estos requisitos.


Una de las grandes ventajas de estos métodos es que no requieren hardware adicional para llevar a cabo la medición de distancias entre los distintos nodos.

- DV-Hop. Un ejemplo de método independiente del alcance es el método basado en el vector de distancia donde cada sensor sólo es capaz de comunicarse con sus nodos vecinos inmediatos. Este método propuesto emplea un mecanismo en el cual un nodo baliza difunde un mensaje con posiciones de todas las balizas con un contador de saltos (hop count) inicializado con valor 1. Cada nodo receptor almacena el mínimo valor de contador de cada baliza entre todos los mensajes recibidos, ignorando aquellos cuyos contadores posean valores más altos que los que tiene almacenados. De esta forma los mensajes van fluyendo a través de la red de modo que el contador irá incrementando su valor en cada salto realizado. Con éste método conseguimos que todos los nodos de la red obtengan la distancia más corta medida en saltos [20].

3.2 Modelo de medida de la distancia basado en RSSI en WSN

En el presente Trabajo Fin de Grado se implementará el método propuesto por los autores Jiuqiang Xu, Wei Liu, Fenggao Lang, Yuanyuan Xhang y Cheglong Wang en un artículo titulado “Modelo de medida de la distancia basado en RSSI en WSN” que fue publicado en 2010 en la revista Wireless Sensor Network [19]. En este apartado se hará una revisión de dicho método.

RSSI son las siglas de “Indicador de fuerza de señal recibida” usadas en tecnologías inalámbricas. Y se refiere a una escala de referencia para medir el nivel de potencia de las señales recibidas.

Con el desarrollo de las tecnologías para determinar el alcance y posicionamiento en las redes de sensores inalámbricos (WSN), se hace casi necesario encontrar una relación matemática entre los valores RSSI y la distancia. Además, el modelo debe ser capaz de autoajustarse frente a los posibles cambios del entorno, reduciendo el error del punto más lejano.

El artículo de Xu y otros está basado en los estudios realizados hasta el momento de su publicación sobre el modelo de propagación RSSI con el objetivo de conseguir máxima precisión y auto-adaptabilidad.

Se señalan 3 tipos de modelos de propagación de la señal RSSI para redes de sensores inalámbricos:

- Modelo de espacio libre. Aplicable en los siguientes casos:

o La distancia de transmisión es mayor que el tamaño de antena y que la longitud de onda de la señal portadora.

o No existen obstáculos en el camino entre transmisores y receptores.

- Modelo de propagación de dos rayos. Se trata de un modelo muy exacto en entornos microcelulares urbanos y es aplicable en los siguientes casos:

o La distancia de transmisión es de alrededor unos pocos de kilómetros.

o La altura de las antenas transmisora o receptora son de más de 50 metros.

- Modelo de sombra log-normal (LNSM, log-normal shadowing model). Es un modelo de propagación más general, siendo adecuado para entornos en interiores como en exteriores, ya que posee parámetros configurables en dependencia del tipo de entorno en el que nos encontremos.

3.2.1 LNSM-DV

La información contenida en este documento se asienta sobre la base de los estudios de los modelos actuales de propagación de RSSI.

Como un modelo más general de propagación de la señal, el modelo de propagación logarítmico-normal puede describir mejor la relación entre los valores RSSI y la distancia. Sin embargo, mediante datos experimentales, se encontró que la varianza del valor RSSI cambia regularmente con la distancia. Por eso, se propuso la función relación entre la varianza RSSI y la distancia, estableciéndose el modelo logarítmico-normal con varianza dinámica (LNSM-DV, log-normal shadowing model with dynamic variance).

Usando el método de los mínimos cuadrados (LS) para estimar parámetros en el modelo, se consiguió que los


30

parámetros fueran capaces de ajustarse dinámicamente de acuerdo a cambios en el entorno.

Los resultados experimentales muestran que LNSM-DV reduce aún más la probabilidad de error y posee una mayor capacidad de auto-adaptabilidad en comparación con el modelo original LNSM convirtiéndose en un modelo de gran precisión. Éste permite ser ajustado dinámicamente de acuerdo a cambios medioambientales.

3.3 Estimación del alcance basada en RSSI

Tecnologías como TOA, TDOA, AOA, en la actualidad de uso general presentan características comunes con la tecnología RSSI. Todas ellas necesitan menos sobrecarga de comunicación, una menor complejidad en su implementación y un bajo coste. Por todo ello, se adecuan muy bien a los nodos de redes de sensores inalámbricos, que disponen de potencia limitada.

3.3.1 Principios de estimación del alcance basada en RSSI

El principio de estimación del alcance basada en RSSI consiste en establecer una relación matemática mediante ecuaciones entre la potencia trasmitida y recibida de redes inalámbricas y la distancia existente entre dichos nodos. Esta relación es descrita en (3–1)

𝑃𝑟∝𝑃𝑡1𝑑

! (3–1)

Donde los parámetros empleados se sustituyen por: potencia recibida y transmitida de las señales inalámbricas, distancia entre nodos y factor de transmisión.

Empleando 10 veces el logaritmo en base 10 a ambos lados de la igualdad, obtenemos la ecuación (3–2):

10 log Pr = 10 log𝑃𝑡 − 10𝑛𝑙𝑜𝑔(𝑑) (3–2)

Y convertimos la expresión de la potencia en dBm, o lo que es lo mismo, en la ecuación (3–3):

Pr 𝑑𝐵𝑚 = 𝐴 − 10𝑛𝑙𝑜𝑔(𝑑) (3–3)

3.3.2 Modelo de estimación del alcance basado en RSSI

El modelo de estimación del alcance basado en RSSI emplea, como hemos indicado en el apartado 3.2 los 3 tipos de modelos de propagación RSSI. A continuación, detallamos las fórmulas que determinan la relación entre potencia trasmitida y distancia en cada uno de ellos.

- Modelo de espacio libre. Suponiendo que la potencia de transmisión de la señal inalámbrica es Pt, la potencia de las señales recibidas de los nodos localizados en la distancia de d pueden ser determinados por las siguientes fórmulas:


Pr (𝑑) =𝑃𝑡𝐺𝑡𝐺𝑟λ!

(4𝜋!)𝑑!𝐿 (3–4)

Donde un valor normal para Gt, Gr y L es 1, por lo que podremos simplificar en la expresión dada por (3–5), ecuación que describe la fórmula de atenuación de señal usando una expresión logarítmica.

𝑃𝐿 𝑑𝐵 = 10𝑙𝑜𝑔𝑃𝑡𝑃𝑟

= −10 𝑙𝑜𝑔λ!

(4𝜋!)𝑑! (3–5)

- Modelo de propagación de dos rayos o modelo de Tierra plana. La potencia recibida es determinada por las siguientes fórmulas:

Pr (𝑑𝐵) = 𝑃𝑡𝐺𝑡𝐺𝑟h!!h!

!

𝑑! (3–6)

Donde ℎ! hace referencia a la altura de la antena transmisora y ℎ! a la de la altura de la antena receptora.

𝑃𝐿 𝑑𝐵 = 40𝑙𝑜𝑔𝑑 – (10 log𝐺! + 10𝑙𝑜𝑔𝐺! + 20𝑙𝑜𝑔ℎ! + 20𝑙𝑜𝑔ℎ!) (3–7)

En la ecuación (3–7) observamos cómo la pérdida básica de propagación aumenta con la distancia con un exponente n = 4.

- Modelo de sombra log-normal (LNSM). El modelo logarítmico- normal es adecuado tanto para ambientes interiores y exteriores. El modelo ofrece una serie de parámetros que pueden configurarse según diferentes medios. La fórmula de cálculo es la siguiente:

𝑃𝐿 𝑑 𝑑𝐵 = 𝑃𝐿 𝑑 + 𝑋! = 𝑃𝐿 𝑑! + 10𝜂𝑙𝑜𝑔𝑑𝑑!

+ 𝑋! (3–8)

Donde:

𝑑! es la distancia de referencia cercano a la tierra.

𝜂 es un índice de pérdida de propagación.

𝑋! es por otro lado, una variable aleatoria Gaussiana de media cero, útil para describir la interferencia producida en las señales RSSI.

3.4 Mejora del modelo de sombra logarítmico-normal.

En la práctica, es indispensable ajustar 𝑃𝐿 𝑑! , 𝜂 y 𝑋! de acuerdo al tipo de entorno en el que estemos trabajando.

Se busca una función de relación de varianza σ y una distancia de propagación de la señal d para números aleatorios Gaussianos de media cero y usar el método de mínimos cuadrados LS para estimar los coeficientes que permitan mejorar la auto-adaptabilidad del modelo.


32

3.4.1 Mejora de la auto-adaptabilidad de valores Gaussianos en LNSM

En un experimento se recogió alrededor de un centenar de grupos de datos intensidad de señal-distancia (RSSI, d) por nodos MICAz en distintos puntos de distancia desde 0.61 a 1 metro, de los cuáles se seleccionan 20 grupos de datos para realizar curvas de representación.

En la Figura 3-1 se puede observar cómo, mientras que hasta los 3 metros no se aprecia gran diferencia entre las curvas, entre los 3 y 5 metros muestran una mayor dispersión, aunque se mantiene una tendencia creciente con el incremento de la distancia d y a partir de esta distancia hasta los 6 metros las curvas pasan a tener una menor dispersión y un crecimiento más lento. Por esto, podemos decir que la dispersión de los valores de RSSI muestra una cierta regularidad con los cambios de la distancia.

Para describir cómo se producen las variaciones RSSI con la distancia, se hace un experimento para conseguir las muestras de varianza de 100 valores de RSSI recogidos a determinadas distancias. Los cambios de la varianza con la distancia se muestran en forma de cajas cuadradas verdes en la Figura 3-2.

Por lo tanto, podemos extraer la conclusión de que, en las redes inalámbricas de sensores, las varianzas de las muestras tomadas se pueden utilizar para descubrir cómo se producen las variaciones de las señales de intensidad de la potencia recibida por los nodos MICAz a lo largo de la distancia.

Figura 3-1. Relación intensidad de potencia recibida y distancia.

A través de un software de analítica predictiva SPSS se aproximó la función de relación de distancia y varianza de la siguiente manera:

𝜎! d = − 0.0461𝑑! + 0.4830 𝑑! − 0.4583d + 0.3998 (3–9)


Cuyas soluciones se representan a través de la curva roja en la ¡Error! No se encuentra el origen de la referencia.

Figura 3-2. Evolución de la varianza RSSI con la distancia.

Queda reflejado que la representación es análoga a la de Figura 3-1. Relación intensidad de potencia recibida y distancia.

Establecemos 𝑋 como una variable aleatoria Gaussiana. Como 𝑋! en la ecuación (3–8) es una variable aleatoria de media cero y σ es la varianza de la población, podemos expresar las ecuaciones:

𝐷 𝑋! = 𝜎!

𝐸 𝑋! = 0

Y de lo comentado anteriormente, deducimos que:

𝐷 𝜎𝑋 = 𝜎!

𝐸 𝜎𝑋 = 0

Por ello, en (3–8) podremos sustituir la variable 𝑋! por 𝜎𝑋, quedando:


34


+ 𝜎𝑋 (3–10)

Para conseguir la universalidad en la expresión dada por (3–9) reemplazamos los datos numéricos por coeficientes, para que quede una ecuación tal que:

𝜎! d = a𝑑! + b 𝑑! − cd + e (3–11)

Usando 𝜎! (muestra de la varianza RSSI) como una aproximación de la varianza de población ԑ, reducimos a la ecuación dada por (3–12)

𝜎 d = a𝑑! + b 𝑑! − cd + e (3–12)

Introduciendo la ecuación (3–12) en (3–8)


+ 𝜎 d 𝑋! (3–13)

Las ecuaciones anteriores (3–12) y (3–13) son las ecuaciones del modelo que estamos describiendo como modelo mejorado sombra logarítmico normal.

3.5 Realización de adaptabilidad de los coeficientes en el modelo de sombra logarítmico-normal

La auto-adaptabilidad del modelo está pensada para mostrar que tanto la función de varianza Gaussiana como los coeficientes 𝑃𝐿 𝑑! , 𝜂, a, b, c y e pueden ser ajustados dinámicamente en función del entorno.

LS es ampliamente utilizado en el análisis de regresión por su simplicidad y pequeña cantidad de computación necesaria. Recordamos que el método de mínimos cuadrados LS se basa en la minimización de la suma de los errores cuadráticos medios.

3.5.1 Método de regresión de mínimos cuadrados

Este método desarrollado por Karl Gauss entre los siglos XVIII y XIX nos permite crear una función lineal (función de regresión) capaz de describir el comportamiento de una variable dependiente Y en función de una o más variables independientes X. Dicha función de regresión se obtiene ajustando las observaciones a la función elegida (lineal, parabólica, exponencial…) mediante el método de mínimos cuadrados [14].

La regresión establece la relación entre dos variables. El método restringe una de las variables a un valor constante con el objetivo de observar las variaciones que produce en la otra variable. Así, podremos predecir el valor de una variable en función de valores dados a la otra variable mediante el estudio del comportamiento de una variable para obtener información sobre otra variable.

Como hemos indicado anteriormente, si hablásemos de un caso concreto en el que tratamos dos variables, siendo una de ellas (X) variable independiente y la otra (Y) la dependiente hablamos de regresión de Y


sobre X. Usando esta nomenclatura, somos capaces de dar un ejemplo: los ingenieros forestales utilizan la regresión de la altura de los árboles sobre su diámetro, lo cual significa que midiendo el diámetro (variable independiente) y reemplazando su valor en una relación definida según la clase de árbol se obtiene la altura, y aun sin necesidad de cálculos aprecian la altura utilizando gráficas de la función de dependencia, altura = función del diámetro [15].

Realmente lo que se consigue con este método es calcular la mejor aproximación posible de un conjunto de valores experimentales a través de una función polinómica de grado m.

𝑦 = 𝑎mxm + am-1xm-1 + … + a1x + a0 (3–14)

Donde am, am-1, am-2… son los coeficientes a calcular. Puesto que trabajamos con datos provenientes de la experiencia, inevitablemente arrastraremos errores experimentales que no satisfacen al completo la ecuación. Por eso dotamos a la expresión de un coeficiente de error.

Figura 3-3. Representación polinómica de coeficientes indeterminados.

Ahora, la distancia de cada punto del gráfico al polinomio tendrá la expresión que aparece en la Figura 3-3. Para obtener una idea de la aproximación del polinomio con los datos experimentales, calculemos la suma de las distancias de cada punto del gráfico al polinomio elevada al cuadrado. La misma estará dada por la siguiente expresión:

𝐸 = ԑ!!!! i

2 = (𝑛𝑖=1 𝑎mxm + am-1xm-1 + … + a1x + a0 - yi) 2 (3–15)

Podemos ver cómo la desviación cuadrática de los puntos respecto al polinomio es una función del polinomio. Nuestro objetivo es obtener aquel polinomio formado por un conjunto de coeficientes (en este caso representados por la letra a y subíndices enumerados) que se encuentra lo más cerca posible de los puntos experimentales. Imponiendo condiciones de extremos formadas por derivadas parciales homogéneas:

!"!!!

(am, am-1, …, a0) = 0 !"!!!

(am, am-1, …, a0) = 0 (3–16)


36

⋮ !"!!!

(am, am-1, …, a0) = 0 Calculando dichas variables parciales de la expresión E como función de cada una de las am+1 variables aj, j = 0, 1…, m, y reordenando obtenemos:

𝑦!!!! i = an 𝑥!

!!! im + an-1 𝑥!

!!! im-1 + … + a1 𝑥!

!!! i + ao 𝑥!!!! i

0

⋮ 𝑦!

!!! ixij = am 𝑥!

!!! im+j + am-1 𝑥!

!!! im -1+j + … + a1 𝑥!

!!! i1+j + ao 𝑥!

!!! ij

𝑦!!!! ixi

m = am 𝑥!

!!! im+j + am-1 𝑥!

!!! im -1+m + … + a1 𝑥!

!!! i1+m + ao 𝑥!

!!! im

(3–17)

O, escrito de otro modo y para ganar mayor claridad podemos expresarlo en forma matricial:

Figura 3-4. Ecuación matricial de la solución teórica desarrollada.

Cuyos coeficientes pueden ser calculados teniendo en cuenta el despeje de la Figura 3-5 empleando un software matemático.


Figura 3-5. Ecuación matricial a través de la matriz pseudoinversa.

Empleando dicho algoritmo, renombramos la fórmula empleada en (3–13) a (3–18)

𝑟 = 𝑓 + 10𝜂 log(𝑑𝑑𝑜) + ԑ (3–18)

En la que se han introducido los parámetros:

r = PL(d)(dB)

f = PL(d)

ԑ = 𝜎 𝑑 𝑋.

𝑑𝑜 es la referencia de tierra cercana que en el artículo estudiado se fija al valor 0.2.

Reordenando los parámetros de la fórmula en (3–18) obtenemos:

ԑ = 𝑟 − 𝑓 + 10𝜂 log(𝑑𝑑𝑜) (3–19)

Atendiendo al principio de minimización de suma de error cuadrático medio:

𝐽 = (!!!! ԑi) 2 = (!

!!! 𝑟 − 𝑓 + 10𝜂 log( !!") )2 (3–20)

A continuación, realizaremos dos derivadas parciales que conjuntamente emplearemos para resolver las incógnitas de nuestro problema:


38

- Realizando la derivada parcial de J con respecto a 𝜂 e igualando éste cálculo a 0 es fácilmente desmostrable que:

10𝜂 (!!!! log (!"

!"))2 + f log (!"

!")!

!!! - ri log (!"!")!

!!! = 0 (3–21)

- Del mismo modo, realizando la derivada parcial de J con respecto a 𝑓 e igualando éste cálculo a 0 es fácilmente desmostrable que

𝜂 (!!!! 10 log (!"

!")) + n f − ri !

!!! = 0 (3–22)

Luego, las ecuaciones mostradas en (3–21) y (3–22) constituyen las ecuaciones simultáneas lineales capaces de resolver los coeficientes (f, 𝜂 ) dados en la fórmula (3–18).

Partiendo de la ecuación mostrada en (3–12), podemos obtener una modificada si sustituimos 𝜎 d por y. Y puesto que vamos a aproximar dicho valor por una ecuación de coeficientes, añadiremos un factor de error para su ajuste llamado e.

𝑦 = 𝑎𝑑3 + bd2 + cd + e + ԑ (3–23)

Y modificando el orden de operandos:

ԑ = y − 𝑎𝑑3 - bd2 - cd - e (3–24)

Al igual que hemos empleado en la ecuación (3–20) el ajuste de mínimos cuadrados, volvemos a usar dicha técnica:

𝐽 = (!!!! ԑi) 2 = (!

!!! 𝑦i – adi3 – bdi

2 – cdi –e) 2 (3–25)

Ya que el procedimiento es el mismo, recordamos que a continuación el siguiente paso es realizar la derivada parcial de J con respecto a cada uno de los párametros a resolver: a, b, c, y e, respectivamente igualando a 0 sus resultados, de modo para cada una de las derivadas obtengamos una ecuación distinta:

𝑎 𝑑!! + 𝑏 𝑑!

!!

!!!

!

!!!

+ 𝑐 𝑑!! + 𝑒 𝑑!

! − 𝑦!𝑑!!

!

!!!

!

!!!

!

!!!

= 0

𝑎 𝑑!! + 𝑏 𝑑!

!!

!!!

!

!!!

+ 𝑐 𝑑!! + 𝑒 𝑑!

! − 𝑦!𝑑!!

!

!!!

!

!!!

!

!!!

= 0

(3–26)


𝑎 𝑑!! + 𝑏 𝑑!

!!

!!!

!

!!!

+ 𝑐 𝑑!! + 𝑒 𝑑! − 𝑦!𝑑!

!

!!!

!

!!!

!

!!!

= 0

𝑎 𝑑!! + 𝑏 𝑑!

!!

!!!

!

!!!

+ 𝑐 𝑑! + 𝑛𝑒 − 𝑦!

!

!!!

!

!!!

= 0

En la práctica cuando el medio experimental es modificado, los coeficientes en (3–12) y (3–13) pueden ser resueltos mediante (3–26).

3.6 Análisis experimental en el artículo de referencia

Como hemos indicado bajo el título de hardware, los nodos MICAz se componen del módulo de comunicación CC2420 con una enorme capacidad de alcance. El núcleo del nodo es el microcontrolador Atmega 128 de bajo consumo y alta velocidad.

3.6.1 Datos, proceso experimental y análisis.

Para el proceso se emplearon dos nodos baliza y un nodo de estación base, todos ellos a 0 metros de distancia del suelo. Se eligieron dos ubicaciones, una de ellas de 30 m. de longitud y 10 m. de ancho en espacio abierto y otra de 15 m. de longitud y 10 m. de anchura en interior. Se recopilaron datos mediante envío y recepción de señales entre ambos nodos, asignando el nodo baliza 1 como nodo de envío de datos y el nodo baliza 2 como nodo encargado de la recepción de los mismos. Al mismo tiempo que el nodo baliza 2 recibe los datos del emisor, los envía hacía el nodo de la estación base, el cuál, conectado a una computadora se hace responsable de su procesamiento.

El nodo baliza 2 recogió unos 100 datos RSSI (dBm) en cada uno de los puntos a distintas distancias. En el momento en el que el nodo de la estación base recibe los datos de las señales RSSI, convierte los valores de la señal en una expresión dada en dB por:

𝑅𝑆𝑆𝐼 𝑑𝐵 = 10 𝑙𝑜𝑔𝑃!𝑃!

(3–27)

La cual es pasada al equipo host, que calcula el promedio de los valores RSSI (dB) para cada punto de la distancia para obtener un grupo de muestras (d, RSSI(dB)) y calcular la varianza de las muestras de RSSI(dB) para obtener grupos (d, 𝜎!) para cada punto de la distancia.

En el experimento realizado en el artículo de Xu y otros se distingue entre entorno de interior y exterior:

- En entorno de interior. Se obtuvieron lo valores:

o 𝑃𝐿 𝑑! = 40.9951

o 𝜂 = 3.5306

o 𝑎 = -0.0493

o 𝑏 = 0.3938

o 𝑐 = -0.5599

o 𝑒 = 0.4745


40

Así, se consiguieron todos los valores necesarios en LNSM-DV. Los coeficientes en LNSM se establecieron conforme a la Tabla 3-1.

Tabla 3-1. Coeficientes empleados en LNSM.

𝑃𝐿 𝑑! 𝜂 𝜎

41 3 2

Figura 3-6. Relación de la intensidad de potencia recibida y distancia en entornos interiores.

En entorno de exterior. Obtenemos lo valores:

o 𝑃𝐿 𝑑! = 41.1320

o 𝜂 = 2.8306

o 𝑎 = -0.0415

o 𝑏 = 0,4103

o 𝑐 = -0,5411

o 𝑒 = 0,4521

Del mismo modo al anterior, hemos conseguido todos los valores necesarios en LNSM-DV, mientras que los


coeficientes en LNSM se han establecido conforme a la Tabla 3-1.

De acuerdo con los datos del par (d, RSSI(dB)) y los obtenidos anteriormente, se extrajeron las curvas de RSSI para valores de la distancia d en la Figura 3-7.

Figura 3-7. Relación de la intensidad de potencia recibida y distancia en entornos exteriores.

A la vista de las figuras anteriores, vemos que la curva de LNSM-DV puede cambiar dinámicamente con el cambio de los ambientes interiores y exteriores, y la dispersión o las variaciones producidas en la misma son consistentes con la curva trazada a través de los datos recogidos.

Sin embargo, la curva trazada a través de LNSM (a partir de los valores de la Tabla 3-1) no puede cambiar dinámicamente con diferentes ambientes observando las grandes desviaciones que se producen en su recorrido alrededor de los datos recogidos.

Esto es así puesto que los coeficientes y la varianza σ de números aleatorios Gaussianos en LNSM tienen su base en la experiencia siendo número fijos, pero la varianza σ de números aleatorios Gaussianos en LNSM-DV puede cambiar de modo dinámico con la distancia.

El modelo LS de mínimos cuadrados es usado para estimar los coeficientes en LNSM-DV de acuerdo al tipo de entorno, confiriéndole así una característica de auto-adaptabilidad. Luego, LNSM-DV en comparación con LNSM puede describir mejor la relación entre la distancia y el valor RSSI de las señales recibidas por los nodos MICAz. Se establece además el modelo LNSM-DV por su precisión de alcance y precisión de posicionamiento.

El uso de LS para estimar los coeficientes de LNSM-DV necesita recoger un gran número de los datos de la muestra, y asegurar que los datos sean diferentes, lo que debe ser considerado con la investigación sobre el diseño de los nodos.


42


45

4 DESARROLLO

The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point.

Claude Shannon, 1948

n este capítulo se analiza todo el desarrollo práctico que ha sido fundamental para poner en funcionamiento un modelo que describa una curva de varianza de las pérdidas de potencia recibida por las motas y con capacidad para conseguir auto adaptabilidad con el entorno en el que se desarrolla.

El objetivo último de nuestra aplicación es pues, demostrar la eficacia del modelo estudiado tomando como únicos datos los valores de potencia recibida por la mota receptora de potencia para cada uno de los valores de distancia que dista de la mota transmisora.

4.1 Análisis de entorno

4.1.1 Material Empleado

No todo el hardware descrito en el apartado 2.2 es empleado en el desarrollo práctico de este trabajo. Se ha implementado una red compuesta por:

- 2 Motas MICAz. Cada una con una placa sensora MPR2400CA como la mostrada en la Figura 2-2. Una de ellas se empleará como mota sensora y la otra como mota piloto.

- Estación Base o Gateway con puerto USB.

- Mota programadora con tablero MIB520 y cable conector USB a PC que le sirve de alimentación.

- Ordenador con software TinyOS corriendo sobre entorno Linux como estación de trabajo.

4.1.2 Entorno

Para la realización de pruebas y medidas finales se ha hecho uso del pasillo de los laboratorios del departamento de Teoría de la Señal y Comunicaciones de la Escuela Técnica Superior de Ingeniería, es decir, de laboratorios L3 situados en la planta primera. Del cuál tan solo necesitaremos 6 metros de longitud para acercarnos al modelo experimental realizado en el modelo descrito en el artículo del apartado 3.2 de este documento.

Puesto que se encuentra pavimentado con baldosas de 40 cm de longitud, se toma como punto de referencia el límite de una baldosa cualquiera donde fijaremos la mota transmisora. La mota receptora, por su parte la iremos moviendo longitudinalmente alejándola de la transmisora de 40 en 40 cm por cada grupo de medidas tomadas hasta alcanzar los 6 metros. De este modo, como vemos en la ecuación (4–1) se harán un total de 15 grupos de medidas hasta alcanzar el objetivo.

60.40

= 15 (4–1)

E

Desarrollo

46

4.2 Descripción general

Se busca insertar código en una serie de motas con el fín de obtener una aplicación capaz de leer el valor RSSI y transmitirlo al PC a través de su puerto serie. Si bien esto es posible con el uso único de una mota transmisora y una estación base, en este trabajo se ha empleado el código de la mota transmisora (SendingMote) para programar dos motas, que diferenciaremos con los nombres de mota tranmisora y mota receptora.

Una de las motas se encontrará acoplada a la placa programadora (también conocida como controladora), por lo que, sin necesidad de baterías, podrá tomar alimentación de ésta. Mientras que la segunda mota se irá alejando en cada prueba de medida.

El programa diseñado en NesC permite que la mota acoplada en la placa programadora (mota piloto en la Figura 4-4) active el módulo radio cada vez que se enciende e inicie el Timer hasta su expiración (se ha programado con el valor por defecto de 250 ms), momento en el que el módulo radio envía en difusión un mensaje que define la estructura en la que los nodos almacenarán los valores de potencia recibida. El mensaje enviado, además de definir la estructura con las variables, es el que utiliza el nodo receptor para obtener la potencia con la que recibe los mensajes procedentes del nodo transmisor.

Este mensaje es reenviado a la estación base para procesar los datos obtenidos en las medidas a través del puerto USB y de una aplicación en C#.

Para obtener una visión global, se han estructurado los ficheros en Figura 4-1, que a modo de esquema:

Figura 4-1. Distribución de ficheros por carpetas.

apps

SendingMote RssiBase

ApplicationDefinitions.h

SendingMoteAppC.nc

SendingMote.nc

Makefile

RssiBaseAppC.nc

BaseStationC.nc

Makefile

RssiBase.nc

C.nc

AppJava

RssiMsg.java

RssiDemo.java

Makefile

ApplicationDefinitions.h


Para percatarnos del momento en el que tiene lugar cada uno de los mensajes enviados en difusión haremos conmutar el led rojo. Por lo que, si toda la interfaz LEDS funciona correctamente, veremos un continuo parpardeo en la placa de las motas.

4.2.1 Mota transmisora

También llamada piloto en la Figura 4-4 para diferenciarlo de la mota receptora, aunque funcionalmente son iguales.

El código de componente tipo módulo correspondiente a la mota transmisora se encuentra distribuido entre los siguientes archivos:

- ApplicationDefinitions.h: determina el intervalo de tiempo con el que el nodo envía los mensajes en difusión. En nuestro caso se encuentra fijado a 250 ms.

- SendingMote.nc: Archivo de configuración encargado de ensamblar los componentes necesarios para la aplicación.

- SendingMoteAppC.nc: Componente de tipo módulo. Es bueno recordar a través de la Figura 4-4 y la Figura 2-14 la interacción existente entre los distintos componentes con los posibles comandos y eventos existentes.

En este fichero se especifican además de las interfaces usadas, el comportamiento del bloque módulo. En este caso, se llaman a 5 eventos:

• Boot.booted: booted() es la única interfaz presentada por el componente Boot. Señala cuando el sistema arranca correctamente.

• RadioControl.startDone: activa el módulo radio.

• RadioControl.stopDone: detiene el módulo radio.

• SendTimer.fired: debido a que éste componente usa una instancia de la interfaz Timer, debe de implementar una interfaz de la instancia Timer.fired().

• RssiMsgSend.sendDone: indica si la solicitud de envío de mensaje ha sido aceptada.

- Makefile: indica las reglas de compilación al sistema.

4.2.2 Mota receptora

Se obvia el código empleado para la programación de dicha mota al ser idéntico al de la mota transmisora.

4.2.3 Estación base

La principal función de la estación base es la de retransmitir por su puerto USB al ordenador al que se encuentra conectado todo aquello que recibe de algún nodo transmisor. Esta permite recolectar datos de la red, monitorizar el tráfico y enviar comandos a los motes. Para la comunicación con la red se emplea en el PC una interfaz basada en el lenguaje de programación Java.

La aplicación se encuentra compuesta por un componente tipo módulo, un componente de configuración y un Makefile.

- ApplicationDefinitions.h: determina el intervalo de tiempo con el que el nodo envía los mensajes en difusión. En nuestro caso se encuentra fijado a 250 ms.

Desarrollo

48

- RssiBase.nc: componente de configuración que ensambla los componentes necesarios para la aplicación.

- RssiBaseAppC.nc: componente de tipo módulo. En él se encuentran especificadas las funciones desarrolladas en la aplicación. Contiene el comando encargado de devolver el valor rssi de un paquete dado. Define las distintas partes del mensaje y detecta el uso de una plataforma radio inválida imprimiendo un mensaje de error.

event bool RssiMsgIntercept.forward(message_t *msg, void *payload, uint8_t len){

RssiMsg *rssiMsg = (RssiMsg*) payload;

rssiMsg->rssi = getRssi(msg);

return TRUE;

}

- Makefile: indica las reglas de compilación al sistema.

RssiBase es la aplicación que se pondrá en un nodo conectado al puerto serie y leerá efectivamente el valor RSSI recibido por una de las motas (que hemos denotado como receptora, aunque realmente su función es también la de mota transmisora cada 250 ms) por eso lo hemos llamado estación base. Está formada por macros capaces de trabajar correctamente con los chips CC2420 o CC1000 [21]. Los valores de RSSI obtenidos a través del comando getRssi corresponden al valor de un registro que contiene signo. Luego al valor obtenido se debería de restar 256, puesto que las potencias recibidas siempre tendrán signo negativo ya que el rango de potencias de transmisión en MICAz va de –25 dBm a 0 dBm, por lo que restando pérdidas de Friis jamás podremos obtener un valor positivo. Resumiendo, para obtener el valor real de potencia recibida, se usará la fórmula

𝑃𝑅𝑋 = 𝑅𝑆𝑆𝐼!"# + 𝑅𝑆𝑆𝐼!""#$% [dBm] (4–2)

donde el manual del chip empleado, es decir, CC2420 indica usar un valor de offset de – 45.

4.2.4 Potencia y frecuencia de emisión

Como ya sabemos, la capa física es la capa que se encuentra más próxima al medio físico de transmisión y es la que se encarga de enviar y recibir los mensajes a través del medio radio.

Es importante señalar que la capa física del Chipcon CC2420 utiliza distintas configuraciones según la frecuencia en la que trabaje. Además, el alcance de la potencia de transmisión también se ve influido por la frecuencia, puesto que la señal presenta más atenuación trabajando a mayores frecuencias, al igual que ocurre con el incremento de la temperatura o de la distancia.

ZigBee opera en la banda de 2.4 GHz sin licencia. Esta es la banda que se comparte entre los principales estándares inalámbricos que son WiFi y Bluetooth como se muestra en la Figura 4-2. En ella se aprecia que Bluetooth tiene un efecto insignificante sobre la interferencia de redes ZigBee, sin embargo, se debe de tratar la coexistencia de WiFi y ZigBee en el mismo entorno. Esto ocurre como resultado de que el organismo regulador de las comunicaciones en España llamado Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información junto con el resto de organismos a nivel internacional crearon una banda a nivel global denominada ISMB (Industrial Scientific and Medical Band) en la cuál se decidió la liberación de dicha


banda y su uso público sin ningún tipo de coste para cualquier tipo de red por lo que la asignación de ancho de banda no puede ser garantizada.

Para evitar problemas graves que puedan conducir a una degradación del rendimiento, dejando caer distintos paquetes de redes y dando lugar al mal funcionamiento de la red en cuestión, es necesaria una planificación de recursos. [22]

Figura 4-2. Distribución de canales de las distintas tecnologías

Como acabamos de ver y recordaremos del apartado 2.3.8 en el que se detalla la distribución de canales IEEE 802.15.4, la banda de 2.4 GHz (empleada en el módulo radio MPR2400CA usado en este trabajo final de grado) es la que dispone de más ancho de banda. Dicha banda se encuentra dividida en 16 canales de 2 MHz cada uno, contando con una separación entre canales adyacentes de 5 MHz, para evitar así la interferencia co-canal [23].

En la frecuencia de emisión, el mayor problema que podemos encontrarnos es la posible interferencia con redes WiFi ya que las bandas de frecuencia de ambos sistemas están solapadas al compartir parte del espectro. Esto hace que la elección de los canales deba hacerse cuidadosamente para lograr el mínimo de interferencias [24].

En la Figura 4-3 podemos ver y comparar cuanta energía y en qué frecuencias opera la interfaz radio en ambas tecnologías inalámbricas. Como se muestra, no se emite en un solo canal, sino que ocupan varias bandas de frecuencia. La asignación del canal de radio se hace en el centro de la banda de frecuencias. Podemos observar también que el canal WiFi es bastante más ancho que el canal ZigBee, lo que quiere decir que WiFi ocupa más espectro de radio frecuencia que ZigBee.

Desarrollo

50

Figura 4-3. Interferencia Wifi - ZigBee

De la misma forma que el 802.15.4, los canales de WiFi se regulan a nivel regional:

- En Europa están disponibles los canales 1 al 13. - En EE. UU. el mayor canal permitido en la banda de 2.4GHz es el 11.

Por tanto, en EE.UU resulta óptimo configurar las redes que trabajen con 802.15.4 en el canal 26 (incluso el 25), puesto que la banda disponible para WiFi se reduce a 2.401 GHz – 2.473 GHz (suma de la longitud total de los arcos). Como podemos apreciar en la Figura 4-3, los canales 25 y 26 son los menos afectados, puesto que no comparten banda con WiFi, aunque también sufren solape con los canales 12 y 13 de WiFi si bien en menos medida al tratarse de canales con menor uso. En cuanto se introducen los canales 12 y 13 (regulación europea), la banda de frecuencias que presentan interferencias crece, y es necesario realizar un mapa de asignación de canales para hallar los que presentan menor interferencia con el 802.15.4. Además, observamos que se produce interferencia cocanal en el espectro de frecuencias de todos los canales de la especificación IEEE 802.11b/g (WiFi) a excepción de los canales 1, 6 y 11 (marcados en negrita). Es por eso que en éstos canales se encuentran la mayoría de las redes.

Para que todos ellos sean capaces de transmitir a la vez, trabajan en subfranjas distintas. La banda ISMB de los 2.4 GHz abarca desde los 2400 MHz hasta los 2480 MHz, es decir, tiene un ancho de banda total de 80 MHz que las distintas tecnologías pueden usar para modular su señal.

La forma de repartir esos 80 MHz en canales es mediante la técnica conocida como FDMA (Frequency Division Multiple Access).

Cada una de las tecnologías crea canales de un ancho de banda determinado:

- WiFi: como hemos dicho, cuenta con 12 canales de 22 MHz cada uno (la mayoría de ellos solapados) aunque suele transmitir en los canales 1, 6 y 11 sin interferencias.


- ZigBee: 16 canales con un ancho de banda de 5 MHz por canal, por lo que pueden estar

perfectamente distribuidos sin necesidad de interferirse entre ellos.

- Bluetooth: 79 canales de 1 MHz cada uno, de forma que tampoco encuentran solapamiento entre sus canales.

Adicionalmente, todas ellas intentan no transmitir a la vez, sino usar intervalos de tiempo muy pequeños (del orden de microsegundos) para realizar los envíos de información.

Wifi y ZigBee conocen el momento en el cual pueden iniciar la transmisión a través de continuas medidas de la intensidad del campo electromagnético que se está generado en esa zona. Así cuando detectan que baja de un determinado umbral es cuando podrán transmitir su mensaje con una probabilidad alta de éxito y sin interferencias, técnica empleada por la mayoría de tecnologías que emplean DSSS (Direct Sequence Spread Spectrum).

Por otro lado, Bluetooth lo que hace es esparcir su mensaje en diminutas señales que son enviados en frecuencias muy próximas entre sí. Esta técnica realiza multiplexación de señal en subcanales y es conocida como FHSS (Frequency Hopping Spread Sequence).

Tras toda esta explicación, queda claro que la transmisión será más óptima cuanto más nos aproximemos al canal 26. Por lo que fijamos la frecuencia de emisión a 2480 MHz.

En cuando a la potencia de emisión de los paquetes de los nodos, sabemos que es configurable dentro de un rango de valores, cuyos valores en el caso de nuestras motas con su correspondiente traducción en valores numéricos de programación de nodos queda representada en la Tabla 4-1.

Tabla 4-1. Tabla de equivalencia de nivel de transmisión con sus respectivas potencias.

Aunque los nodos están relativamente cerca (recordemos de 0.4 a 6 metros), es posible que, debido a la atenuación de las paredes de los pasillos de laboratorios, la señal proveniente del nodo transmisor (piloto) en un punto dado se atenúe demasiado como para no alcanzar el umbral mínimo de recepción del nodo receptor. Si esto sucediera, no podríamos tomar medida de la potencia recibida de dicho nodo y como consecuencia no seríamos capaces de extraer el modelo de variabilidad de la varianza para esa medida en concreto [25]. Se puede evitar llegar a esta situación seleccionando la potencia máxima de emisión a 0 dBm con la ventaja de que con este valor de potencia obtendremos la mayor área de cobertura posible. Tanto la potencia como la frecuencia de emisión se pueden configurar en el archivo CC2420.h contenido en la ruta /tos/chips/cc2420/. Por defecto, la potencia de emisión es de 0 dBm y el canal de transmisión es el 26. Abriendo el fichero con un editor de texto, efectivamente vemos los valores correspondientes al canal radio 26 y a la potencia de transmisión de 0 dBm.

#ifndef CC2420_DEF_CHANNEL #define CC2420_DEF_CHANNEL 26

Desarrollo

52

#endif #ifndef CC2420_DEF_RFPOWER #define CC2420_DEF_RFPOWER 31 #endif

4.2.5 Fase de toma de datos

Esta fase consiste en la toma de medidas de parámetros RSSI en el nodo receptor cuando este varía su posición y como consecuencia su distancia con respecto al nodo transmisor o piloto.

Situaremos ambos nodos, tanto transmisor como receptor en posiciones libres de obstáculos y a la misma altura (ras de suelo).

El primer paso es desplegar la pequeña red de sensores mostrada en la Figura 4-4 en la que el nodo transmisor o piloto se encuentra conectado alimentado por la placa programadora a través de conexión USB, al igual que la estación base al PC. El nodo receptor lo iremos alejando en distancias múltiplos de 0.4 metros (0.4 m, 0.8m, 1´2m, 1’6m…) de forma lineal desde el nodo transmisor.

Para obtener un estudio detallado y con cierta exactitud, hemos decidido realizar un total de 20 medidas de RSSI para cada una de las 15 distancias en las que situaremos nuestros nodos. Esto dará lugar a un total de 300 medidas de potencia.

Figura 4-4. Esquema del banco de desarrollo

De esta manera, digamos que obtendremos una pequeña base de datos formada por un conjunto de duplas del tipo: [distancia, vector de potencia]. Analizando esta base de datos, la distancia sólo variará su valor por cada serie de 20 medidas de potencia.


Este proceso se repetirá en cada una de las distancias de modo que al final obtendremos una matriz de 15 filas x 20 columnas.

Una vez que el nodo receptor recibe el valor RSSI, entra en juego la estación base, teniendo en cuenta que el nivel básico de abstracción para la comunicación realizada entre el PC-gateway es un paquete fuente. Dicho de otro modo, se trata de un medio sobre el que cualquier aplicación puede enviar y recibir datos.

BaseStation es una utilidad de TinyOS que sirve para que la estación base, una vez programada con esta aplicación, actúa como puente entre el puerto serie y la red de sensores. Es decir, cuando se reciba un paquete por el puerto serie, ésta lo retransmitirá vía radio y cuando el paquete se reciba por la interfaz radio en la estación base, ésta lo reenviará por el puerto serie al PC.

Para llevar a cabo la explicación del proceso de medida se vuelve necesaria una introducción acerca de los procesos de compilación y ejecución de aplicaciones nesC. Por ello, antes de continuar leyendo, se recomienda la lectura del apartado 4.2.5.1 en el que se describe paso a paso los comandos necesarios para la compilación de cualquier aplicación.

TinyOS emplea un parámetro opcional en la mayoría de sus herramientas de comunicación para especificar el paquete fuente.

Este parámetro opcional se representa como –comm. Existe la posibilidad de fijar la opción –comm y así se evita la necesidad de escribirla en cada sentencia de ejecución. Para fijar el parámetro –comm se utiliza una variable de entorno llamada MOTECOM. Si no especificamos la opción –comm en la orden de ejecución de un programa, el sistema buscará los parámetros del puerto y la velocidad en esta variable de entorno.

Por ejemplo, con una mota MICAz como estación base, podríamos monitorizar lo que se está recibiendo usando la herramienta Listen junto con el comando -comm:

$ java net.tinyos.tools.Listen –comm serial@/dev/ttyUSB0:micaz

donde hemos supuesto que ttyUSB0 es el puerto serie virtual para programación. Para ver el funcionamiento de este comando podemos compilar e instalar la aplicación /apps/tests/TestSerial en una mota. Esta aplicación envía un paquete al puerto serie cada segundo y cuando lo recibe muestra el número de secuencia del paquete en los LEDs.

La salida por pantalla será similar a la siguiente:

00 FF FF 04 22 06 00 02 00 01

00 FF FF 04 22 06 00 02 00 02

00 FF FF 04 22 06 00 02 00 03

00 FF FF 04 22 06 00 02 00 04

00 FF FF 04 22 06 00 02 00 05

00 FF FF 04 22 06 00 02 00 06

00 FF FF 04 22 06 00 02 00 07

00 FF FF 04 22 06 00 02 00 08

00 FF FF 04 22 06 00 02 00 09

00 FF FF 04 22 06 00 02 00 0A

00 FF FF 04 22 06 00 02 00 0B

Listen únicamente imprime los paquetes que se reciben de la mota, que son los mismos que se reenvían por el puerto serie. Recordar que la información se enviaba en tipo message_t que contenía la estructura que habíamos definido para almacenar el contador y el identificador del nodo. Por tanto, cada paquete que se reciba contiene múltiples campos:

Desarrollo

54

- Byte (00) indicador de paquete tipo AM (Active Message) siguiendo el estándar de TinyOS por lo que se basa en el envio de paquete TOSMsg con una estructura específica que no trataremos aquí. [27]

- El resto de bytes, restando los últimos 4 bytes de campos genérticos Active Message. Éstos se encuentran definidos en el fichero /tinyos-2.1/tos/lib/serial/Serial.h.

Una vez instalado el programa en la mota, necesitamos ejecutar la aplicación Java que se ha generado durante la compilación usando el siguiente comando:

$ java TestSerial –comm serial@/dev/ttyUSB1:micaz

El formato para definir el puerto fuente es el siguiente:

serial@<PORT>:<SPEED>

En lugar de especificar la velocidad numéricamente, se puede indicar la plataforma con la que se está trabajando y el sistema se encarga de convertirlo automáticamente. En el caso de la arquitectura MICAz, la velocidad es de 57600 baudios. El archivo del sistema donde están especificadas las conversiones plataforma-velocidad es /support/sdk/java/net/tinyos/packet/BaudRate.java.

A modo de cuadro resumen, en la Tabla 4-2 se muestra un resumen con las principales conversiones plataforma-velocidad de transmisión de datos.

Tabla 4-2. Tabla resumen conversión plataforma-velocidad.

Plataforma Velocidad

telos 115200

telosb 115200

tmote 115200

micaz 57600

mica2 57600

mica2dot 19200

eyes 115200

Siguiendo dicha tabla, sería idéntico indicar:

$ export MOTECOM=serial@COM1:micaz

$ export MOTECOM=serial@COM1:57600

A la hora de la ejecución es importante tener en cuenta que cada vez que conectamos la placa programadora a una mota o directamente la estación base al PC mediante conexión USB, se crean dos puertos, llamémosle X y X+1, donde X sería el puerto empleado para la programación y aquel con identificador un valor mayor el empleado para realizar la comunicación con el PC.


La secuencia comentada anteriormente ($ java TestSerial –comm serial@/dev/ttyUSB1:micaz) hará que el sistema se resincronice con las motas e imprima los valores decimales referentes a las potencias Rssi dadas en dBm.

Al terminar de realizar todas las medidas es recomendable usar la siguiente secuencia para no forzar que las próximas aplicaciones usadas usen el mismo puerto serie para obtener paquetes.

$ unset MOTECOM

Es sencillo obtener errores de ejecución. Algunos de los más comunes son:

- Mala conexión a los puertos del PC.

- Si no se usa adecuadamente el comando –comm como en el caso de que se indique un puerto serie erróneo.

- Si no se posee instalado el paquete javax.comm

- Indicación de una tasa de transmisión mayor de la que la estación base pueda procesar.

4.2.5.1 Comandos básicos en Tinyos para la compilación

El primer paso es compilar cada una de las aplicaciones vistas en la Figura 4-1. Para ello debemos de conocer el puerto serie de cada uno de los dispositivos conectados. Esto lo podremos obtener a partir de la ejecución del comando motelist, que nos devolverá en todo momento una lista de todos los dispositivos y sus respectivos puertos COM asociados. [26]

En el caso de la compilación del código SendingMote hemos obtenido /dev/ttyUSB0 como puerto serie. Realizar la compilación es tan simple como ejecutar en el fichero de la aplicación el comando make seguido de la plataforma sobre la que estemos trabajando:

$ make micaz

Con este comando primeramente se compila el código mediante nesC, a través del cual obtenemos un código fuente estándar en C y posteriormente conseguimos el código binario siguiendo la arquitectura de la mota específica.

El archivo binario generado es empleado para programar la mota mediante:

$ make <plataforma> reinstall, <identificador opcional> <tarjeta Ethernet>,<PORT>

que en nuestro caso quedará como:

$ make micaz reinstall,1 mib520

donde:

- El comando reinstall indica que se instale con el código binario compilado en la acción previa.

- El 1 que le sigue en la secuencia corresponde a la dirección AM e indica el identificador único de la mota a la que nos referimos.

- Mib520 referencia a la plataforma empleada.

- /dev/ttyUSB0 es el puerto serie virtual devuelto por motelist.

También podemos compilar e instalar en una misma orden mediante:

$ make micaz, install,1 mib520, /dev/ttyUSB0

La salida obtenida deberá de asemejarse a la obtenida en el ejemplo dado por la aplicación que comentaremos mas adelante llamada TestSerial:

mig java -target=telosb -I%T/lib/oski -java-classname=TestSerialMsg TestSerial.h TestSerialMsg -o TestSerialMsg.java javac *.java compiling TestSerialAppC to a telosb binary ncc -o build/telosb/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x66

Desarrollo

56

-Wnesc-all -DCC2420_DEF_CHANNEL=19 -target=telosb -fnesc-cfile=build/telosb/app.c -board= -I%T/lib/oski TestSerialAppC.nc -lm compiled TestSerialAppC to build/telosb/main.exe 6300 bytes in ROM 281 bytes in RAM msp430-objcopy --output-target=ihex build/telosb/main.exe build/telosb/main.ihex writing TOS image

En el caso en el que queramos borrar toda compilación realizada, es suficiente con ejecutar la orden:

$ make clean

El último paso necesario para que la aplicación corra en la mota es realizar la ejecución del fichero java devuelto.

4.2.6 Fase de medida y realización del modelo

Una vez obtenida esta base de datos, se ha buscado realizar un algoritmo matemático que demuestre el modelo matemático desarrollado en el apartado 3.3. Para ello, hemos elegido emplear el software matemático MATLAB (MATrix LABoratory), herramienta que fue diseñada hacia los años 70 por la reconocida empresa MathWorks dotando de un entorno interactivo al cálculo matemático. Gracias a ella podremos implementar un algoritmo que manipule matrices realizando cálculos que a mano resultarían complejos y obteniendo la representación gráfica de los resultados obtenidos [27].

Como primer paso, hemos formado mediante combinación de vectores una matriz de tamaño 15 filas x 20 columnas a la que hemos denominado PR_DBM. Cada fila i = 1, 2, 3, … 15 enumera las distintas distancias a las que se han realizado las medidas. Mientras que cada columna j = 1, 2, 3, …20 enumera el total de medidas anotadas para cada una de las distancias i.

Estableciendo el metro como unidad de medida definimos el vector

d = [0.4 0.8 1.2 1.6 2.0 2.4 2.8 3.2 3.6 4.0 4.4 4.8 5.2 5.6 6.0]; con todas las distancias empleadas.

Por otro lado, es necesario fijar la variable 𝑑𝑜 (distancia de referencia) al valor 0.2 tal y como vimos en el apartado 3.5.1, ya que nos resultará útil para los próximos cálculos.

Con las siguientes sentencias nos bastará para definir los vectores que serán usados en las siguientes representaciones.

En la primera sentencia se ha incorporado el signo negativo puesto que el cálculo realizado es posible para valores positivos de potencia recibida. Es por eso que eliminamos el signo negativo tras multiplicarlo por otro signo negativo. PL_DB=(-PR_DBM); PL_DB_columnas = PL_DB'; PR_DBM_columnas = PR_DBM';

for i=1:15 PR(1,i)=mean(PR_DBM_columnas(:,i)); PL(1,i)=mean(PL_DB_columnas(:,i)); V(1,i)=var(PL_DB_columnas(:,i)); end


Para hacer esto posible, se ha empleado un bucle for que recorre una a una cada fila de la matriz transpuesta PL_DB.

j=1; for d1=0.4:0.4:6.0

hold on plot(d1,PL_DB(j,:),'s') title(' Total de datos de pérdidas de potencia transmitida ') xlabel('d (m) ') ylabel('Lb (dB) ') hold off j=j+1;

end

El formato de la representación anterior y de las dos próximas se ha dado con las siguientes líneas de código que permiten señalar mediante puntos de color azulado los datos, mientras que en línea discontinua rojo se marca la trayectoria que enlaza dos puntos sucesivos.

figure plot(d,PR, '--ro','linewidth',2,'markersize',6,'markeredgecolor','b','markerfacecolor','b') title(' Potencia recibida ') xlabel('d (m) ') ylabel('Pr (dBm) ')

Por otro lado, la pérdida básica de propagación (Lb) o también conocida como relación entre potencia transmitida y potencia recibida (PL(d)) es fácilmente calculable negando los datos de la potencia recibida. Esto es así si atendemos a que la potencia transmitida es de 0 dBm, lo que hará que cualquier valor negativo que le restamos, sea convertido a positivo.

Por último, el cálculo de la varianza muestral resulta también sencillo a través de otro de los comandos estadísticos más utiles (var), que muestra el cuadrado de la desviación típica.

Recordamos que en la ecuación (3–13) en la que describíamos una de las ecuaciones para la definición del modelo de sombra logarítmico normal, diferenciábamos en 2 sumandos 𝑃𝐿 𝑑 + 𝑋! (representados en la Figura 4-11 y Figura 4-12 repectivamente) el valor de la atenuación de señal 𝑃𝐿 𝑑 𝑑𝐵 , siendo uno de ellos correspondiente al valor de la media y otro al valor de su varianza respecto de la media.; y que para realizar un ajuste más exacto lo podíamos sustituir por los operadores 𝑃𝐿 𝑑! + 10𝜂𝑙𝑜𝑔 !

!!+ 𝜎 d 𝑋!.

Esta, junto con la ecuación (3–12), nos ofrece los coeficientes necesarios para la descripción del modelo. Consecuentemente, para determinarlos empleamos el método regresivo detallado en el apartado 3.5.1 hasta obtener la forma matricial a través de la matriz pseudoinversaFigura 3-5. Conseguirlo en Matlab es tan sencillo como definir cada una de las matrices mostradas en la Figura 3-5, a las que hemos denotado del siguiente modo y llevado al lenguaje matemático en el orden citado:

- Siguiendo la nomenclatura de la ecuación (3–12) hemos denotado por theta (𝜎) al vector columna de coeficientes indeterminados. theta=[eta;f;a;b;c;e];

- La matriz de ecuaciones lineales es identificada como X. Los componentes de la matriz son calculados gracias al comando sum () cuya función es sumar cada columna de la matriz o vector fila y representar el resultado como un único valor.

Desarrollo

58

Para formar la matriz X se ha tenido en cuenta la serie de ecuaciones desde (3-21) hasta (3–26). Desarrollando todos los sumatorios que las componen se conforman unas expresiones demasiado extensas para incluir en este documento. Sin embargo, diremos que en la matriz X incluiremos sólo aquellos componentes dependientes de algunos de los coeficientes indeterminados del vector theta. Las posiciones de la matriz que ocupan valor 0 son aquellas que no dependen del algún parámetro en el orden: eta, f, a, b, c, e. En otras palabras, en el vector: X=[X11A X12 0 0 0 0;X21 X22 0 0 0 0;0 0 X33 X34 X35 X36;0 0 X43 X44 X45 X46;0 0 X53 X54 X55 X56;0 0 X63 X64 X65 X66] vemos que en la primera fila los valores de las posiciones correspondientes a las 3º, 4º, 5º y 6º columna se encuentra vacías. Con esto queremos decir que la ecuación expresada en la primera fila (la correspondiente a la ecuación en (3-21) no contiene operandos dependientes de a, b, c ni e). Del mismo modo se han ido desarrollando el resto de ecuaciones, teniendo en cuenta que la primera columna corresponde a los valores que se encuentran multiplicando al primer coeficiente independiente, es decir, a. La segunda columna corresponde a los valores que se encuentran multiplicando al segundo coeficiente independiente, es decir, b. Y así sucesivamente.

for n=1:1:15

x11(n)=(log10(d(n)/do)).^2; X11=sum(x11); x12(n)=log10(d(n)/do); X12=sum(x12); x21(n)=10*log10(d(n)/do); X21=sum(x21); X22=15; X66=X22; x33(n)=d(n).^6; X33=sum(x33); x34(n)=d(n).^5; X34=sum(x34); X43=X34; x35(n)=d(n).^4; X35=sum(x35); X44=X35; X53=X44; x36(n)=d(n).^3; X36=sum(x36); X45=X36; X54=X45; X63=X54; x46(n)=d(n).^2; X46=sum(x46); X55=X46; X64=X55; x56(n)=d(n); X56=sum(x56); X65=X56;

End X11A=10*X11;


X=[X11A X12 0 0 0 0;X21 X22 0 0 0 0;0 0 X33 X34 X35 X36;0 0 X43 X44 X45 X46;0 0 X53 X54 X55 X56;0 0 X63 X64 X65 X66]

- El vector columna que contiene los coeficientes independientes determinados como B donde, de nuevo, hacemos uso del comando sum() para desarrollar los sumatorios.

for n=1:1:15

b1(n)=PL(1,n).*log10(d(n)/do); B1=sum(b1); b2(n)=PL(1,n); B2=sum(b2); b3(n)=V(1,n)*(d(1,n)^3); B3=sum(b3); b4(n)=V(1,n)*(d(1,n)^2); B4=sum(b4); b5(n)=V(1,n)*d(1,n); B5=sum(b5); b6(n)=V(1,n); B6=sum(b6);

end

B=[B1;B2;B3;B4;B5;B6]

Hasta el punto citado, se ha descrito el procedimiento para formar los datos necesarios. A continuación, se ha simplificado la resolución del problema a través de la aplicación cuya matriz es (At A)-1At. Esta recibe el nombre de matriz pseudo-inversa Moore-Penrose o matriz generalizada de A y su técnica de obtención de basa en el conocimiento de la inversa de las matrices cuadradas.

Se trata de un método altamente empleado en resolución de sistemas de ecuaciones lineales donde se encuentran más ecuaciones que incógnitas.

Para el caso más sencillo aplicable, imaginemos y = A x, donde se supone conocido tanto y (vector) como A (matriz) y se busca conocer x (vector). Si la matriz A fuera cuadrada, resolver el sistema quedaría simplificado mediante el uso de la matriz inversa A-1. Sin embardo, no es posible computar la matriz inversa para el caso en el que se cuenta con una matriz no cuadrada.

Siempre que m > n (número de filas > número de columnas): AT A = I. Igualdad que no se cumple en el orden inverso: AT A ≠ I.

y = A x

AT y ≈ ATA x

AT y ≈ 𝐼 𝑥

AT y ≈ 𝑥

(4–3)

Está implementada en Matlab a través del comando pinv(A)ó A\b. Este operador es útil también en el caso de encontrarnos con un sistema con defecto de ecuaciones. El tratamiento de este tipo de problemas suele omitirse en la mayoría de cursos de álgebra en ingeniería, sin embargo, tiene una gran utilidad en cálculo numérico y es una herramienta relativamente importante.

Tal y como se ha comentado, se implementa la siguiente solución, donde X correspondería a A según el último ejemplo seguido, theta correspondería a x y B correspondería a y. Así se consiguen obtener todos los valores de coeficientes indeterminados bajo el mismo vector theta.

Desarrollo

60

theta=pinv(X)*B a=theta(3); b=theta(4); c=theta(5); e=theta(6);

A pesar de que cada elemento de dicho vector resulta útil para comprobar el correcto funcionamiento del modelo, realmente resultan interesantes los valores de los parámetros a, b, c, e para analizar la evolución de la aproximación de la función de varianza con respecto al vector distancia.

x=0:0.4:6.0; y=a*(x.^3)+b*(x.^2)+c*x+e;

4.3 Resultados

Se ha contado con un entorno de desarrollo muy simple bajo el que simular el algoritmo visto en el apartado 3.2 donde describíamos el articulado publicado por Jiuqiang Xu, Wei Liu, Fenggao Lang, Yuanyuan Xhang y Cheglong Wang titulado “Modelo de medida de la distancia basado en RSSI en WSN”.

Recordamos que nuestros resultados han sido obtenidos en un entorno en el que no contábamos con más obstáculos que las paredes del pasillo con el fin de obtener valores de potencia lo más exactos posibles.

En la fase previa a los cálculos, monitorizamos el comportamiento de la red mediante la observación de los datos enviados a través del puerto serie del gateway. La salida del programa insertado en la pasarela es devuelta directamente a la salida de comandos.

Al contar con 20 medidas para cada una de las 15 distancias establecidas como mínimas, se han recolectado 15 vectores en los que hemos insertado las primeras 20 medidas obtenidas tras arrancar la conexión radio entre las motas.

En las próximas capturas se hace visible el hecho de que los resultados no siempre varían dentro del mismo rango. Esto se debe a que la seguridad en este tipo de redes no está resuelta. El término inalámbrico está asociado a “poco fiable e inseguro”. Esta expresión viene justificada por el hecho de que la tecnología es inherentemente insegura debido a su estrecha relación con el entorno físico (un nodo sensor puede ser fácilmente accessible, y lo datos son enviados a través de un medio inalámbrico).

En este apartado se recolectan algunas de las medidas obtenidas en los puntos más significativos del proceso de desarrollo donde la evolución en los valores de potencia recibida por la mota gateway resulta más clara a simple vista.


Figura 4-5. Resultados obtenidos en la medida inicial (d=0.4 m).

En la Figura 4-5, se muestran las medidas correspondientes para el valor d(1) del vector de distancia.

Desarrollo

62

Figura 4-6. Resultados obtenidos en la medida intermedia (d=3.2 m)

En laFigura 4-6, se muestran las medidas correspondientes para el valor d(8) del vector de distancia.


Figura 4-7. Resultados obtenidos en la medida más lejana (d=6 m).

En todos los casos anteriores, y aquellos que se han omitido, se ha dejado un tiempo de espera entre cada una de las ejecuciones para estabilizar la recepción de paquetes con el minimo de interferencias. De este modo la respuesta entre una medida y la siguiente difieren lo menos posible.

Para corroborar los resultados extraídos Rssi se ha tomado como referencia la propagación en espacio libre. Lo hemos supuesto así puesto que a primera vista desconocemos los obstáculos a los que nos enfrentamos en el medio. Hay que tener en cuenta que, de este modo, los valores teóricos obtenidos serán si bien aproximados, pero nunca exactamente igual a los prácticos.

Tratándose por lo tanto de una comunicación punto a punto, como si de antenas isótropas se tratara, separadas una distancia R.

Figura 4-8. Diagrama transmisión (Tx) y recepción (Rx) en espacio libre.

Desarrollo

64

Sabemos que la potencia de la señal transmitida se distribuye sobre un frente de onda cuya área va en aumento conforme nos alejamos del transmisor. Esto es lo que hace que la densidad de potencia disminuya en lo que se conoce como pérdida en el espacio libre.

Figura 4-9. Ensanchamiento del frente de onda en función del parámetro r. [28]

Se supone una antena omnidireccional transmitiendo a PT W, sin pérdidas y con la antena receptora en campo lejano respecto a la transmisora. La potencia captada por la receptora a una distancia R viene dada por:

𝑃𝑟 = 𝐺𝑡𝐺𝑟( !!!"

)2 Pt (4–4)

Tratando el concepto de pérdidas como el cociente entre la potencia transmitida y la potencia recibida:

𝐿𝑏 = !"!"

(4–5)

𝐿𝑏 𝑑𝐵 = 20 𝑙𝑜𝑔 !!"!

(4–6)

Se define la ecuación de Friis para espacio libre como en la siguiente ecuación:

𝐿𝑏 𝑑𝐵 = 32.45 + 20 log 𝑓 𝑀𝐻𝑧 + 20 log 𝑑(𝑘𝑚) (4–7)

Resolviendo para las siguientes figuras: Figura 4-5, Figura 4-6 y Figura 4-7:

Para la comprobación de los datos correspondientes a la Figura 4-5, a distancia 0.4 m:

𝐿𝑏 𝑑𝐵 = 32.45 + 20 log 2480 + 20 log 0.0004 = 32.3801 dB

Comprobamos del mismo modo con el resto de casos:

Para la Figura 4-6, a distancia 3.2 m:

𝐿𝑏 𝑑𝐵 = 32.45 + 20 log 2480 + 20 log 0.0032 = 50.4419 dB

Para la Figura 4-7, a distancia 6 m:

𝐿𝑏 𝑑𝐵 = 32.45 + 20 log 2480 + 20 log 0.006 = 55.90202 dB


Los cálculos realizados suponen una burda aproximación si no se tienen en cuenta el tipo de entorno o los obstáculos existentes. Por ello no se corresponden exactamente con las capturas obtenidas.

Las conversiones para las unidades de medida han sido posibles teniendo en cuenta que la potencia de referencia es de 1 mW. Esto es así porque una señal con una fortaleza de 0 dBm tiene 1 mW de energía.

Gráficamente, las pérdidas básicas de propagación presentan un comportamiento como el que se muestra en la Figura 4-10. En ella queda reflejado que para un mismo valor del vector distancia, es común que la potencia que se reciba se repita en la mayoría de los casos. Este hecho es evidente en medidas como la tomada para la distancia correspondiente a d = 4.8 m, o dicho de otro modo, para d(12)

Debido a que el valor obtenido en PL_DB (11,j) para cualquier valor de j es siempre el mismo, en la siguiente gráfica parece realizarse tan solo la representación de un valor a través del símbolo rectangular en tono anaranjado alrededor de la medida d = 4.8 m en el eje horizontal. Sin embargo, este hecho señala que todos los valores de la fila 11 del vector PL_DB poseen exactamente el mismo valor de potencia.

Figura 4-10. Representación del total de datos de pérdidas de potencia transmitida (PL) frente a la distancia.

Desarrollo

66

Como se puede ver, la tendencia de la respuesta en la potencia tiene sentido con los cálculos teóricos mediante la ecuación de Friis. Se ha visto que conforme más distantes se encuentran la mota receptora de la mota transmisora, más significativas se hacen las pérdidas de transmisión.

Sin embargo, realmente daremos importancia a la representación de pérdidas de transmisión frente a distancia, más que al simple cálculo de potencia recibida. Para la cual se ha elegido la media (mean) de las columnas de la matriz transpuesta de valores de potencias recibidas (PR_DBM).

Figura 4-11. Representación de potencia recibida (PR) frente a la distancia.


Por otro lado, las pérdidas de potencia transmitida no son más que series de valores obtenidos como la negación de la potencia recibida. Esta afirmación es verdadera en cuanto que calculamos las pérdidas de potencia transmitida como la diferencia entre potencia transmitida y media de potencia recibida. Donde la potencia transmitida la fijamos a 0 dBm según explicábamos en la Tabla 4-1.

Figura 4-12. Representación de media (Lb(dB)) de pérdidas de potencia transmitida (PL(d)) frente a la distancia.

Desarrollo

68

Podríamos comprobar la similitud entre la Figura 4-12 y la Figura 4-10 con tan sólo superponerlas. Es el modo más sencillo de estimar que los cálculos matemáticos de la media de las pérdidas de potencia transmitida tienen sentido.

Figura 4-13. Representación conjunta de media y total de pérdidas de potencia transmitida (PL(d)) frente a la

distancia.


De la gráfica anterior, deducimos que la función que define las pérdidas de potencia transmitida no sigue un comportamiento lineal, sino que en ocasiones alterna al alza y a la baja con lo que no sería un crecimiento lineal. Debemos de tener en cuenta que, a pesar de extraer medidas en un entorno libre de obstáculos, las mismas paredes pueden absorber parte de la señal que se transmite.

Figura 4-14. Representación de medida de varianza (V) frente a la distancia.

Desarrollo

70

En la Figura 4-15, se recurre a la representación bajo un mismo grafo de la curva de varianza medida a través de línea discontinua y puntos azules junto a la curva dada por el modelo aproximado en línea continua color cyan.

Figura 4-15. Curva de movimiento de varianza real y aproximada frente a la distancia.

La Figura 4-15 debería de asemejarse de forma cercana a la vista en la Figura 3-2. En los siguientes párrafos se comentan en profundidad el por qué de los resultados obtenidos, donde se puede dar explicación a las diferencias existentes entre el modelo real y el obtenido matemáticamente.

En el apartado 4.2.6 hablábamos sobre el procedimiento empleado a través de software matemático. Sin embargo, no hemos dado valor a cada una de las variables empleadas o los resultados de cada una de las funciones ejecutadas.

Tras realizar los cálculos correspondientes llegamos a la solución de la pseudoinversa que encontramos en la ecuación (4-3). La solución a este sistema nos devolverá los valores exactos que justificarán que el procedimiento empleado a través de LNSM-DV es el más adecuado por poseer las características más precisas.

Numéricamente, hemos obtenido los siguientes valores para los coeficientes indeterminados:

- f = 𝑃𝐿 𝑑! : 35.1532


- eta = 𝜂: 2.1850

- a: 0.0784

- b: -0.7457

- c: 1.6689

- e: 0.9649

Como último paso para comprobación de que los resultados suponen una buena estimación, hemos comprobado que se asemejen a los extraídos en el artículo de referencia para el modelo de entorno interior del apartado 3.6.1:

- 𝑃𝐿 𝑑! = 40.9951

- 𝜂 = 3.5306

- 𝑎 = -0.0493

- 𝑏 = 0.3938

- 𝑐 = -0.5599

- 𝑒 = 0.4745

Los valores de los coeficientes a, b, c y e obtenidos son menores que los esperados, no obstante, pertenecen al mismo rango que los tomados como referencia.

Por otro lado, el parámetro eta= 𝜂 = 2.185 es coherente con el hecho de que el pasillo es lo que más se parece a espacio libre según experiencias anteriores en prácticas y trabajos desarrollados en este medio.

Por otro lado, ya hemos visto según los modelos tanto en interiores como exterior que el valor del coeficiente f o 𝑃𝐿 𝑑! que parece estar en un rango de entre 40-41 dB. En nuestro caso, el parámetro 𝑃𝐿 𝑑! = 35.15 está dentro de lo posible.

Para salir de dudas, hemos supuesto d0 = 40 cm. Si realizamos el cálculo, salen unas pérdidas de espacio libre (LFS Lost free space) de 32.38 dB.

LFS = 32.45 + 20 log (2480) + 20 log (0.0004) = 32.38 dB (4–8)

Si pensamos en el significado de LFS, es deicr, en la pérdida básica para la distancia d0, un valor de 35 puede resultar más que razonable contando siempre con las posibles fuentes de perturbación en un pasillo

Si bien, en la Figura 4-15 se pueda cuestionar la existencia de relación entre ambas gráficas, existe una explicación. Teóricamente, los cálculos matemáticos del valor de la varianza en las pérdidas de potencia en este caso saltan de modo exagerado con respecto a los valores anteriores o posteriores. Este hecho causa que el polinomio de tercer grado empleado como modelo de ajuste no sea capaz de seguir estos cambios bruscos de comportamiento.

Desarrollo

72

73

5 CONCLUSIONES Y LÍNEAS FUTURAS DE TRABAJO

5.1.1 Conclusiones

En este proyecto nos hemos centrado principalmente en el proceso de medidas de distancia a través de un modelo mejorado que utiliza como principal objeto de medida la potencia recibida por sensores MicaZ.

Como hemos comentado anteriormente, es posible añadir numerosas mejoras y funcionalidades que no hemos abordado en este trabajo.

Del mismo modo, no se ha tratado de ajustar el sistema a su máxima aproximación, sino que tan solo se ha buscado demostrar que el estudio realizado a través de un articulo científico es real y aplicable a sistemas actuales.

Aunque la exactitud del sistema no sea elevada, podemos aumentar la misma si ajustamos mediante un polinomio de mayor orden dadas las características tan cambiantes de la varianza con la distancia. Como incoveniente, daríamos lugar a un sistema de ecuaciones más complejo y con mayor número de incógnitas.

Otra forma de reducir el error cometido en la estimación de un polinomio de ajuste de mínimos cuadrados es usar un número elevado de muestras para los cálculos estadísticos previos de media y varianza.

La aproximación de funciones puede convertirse en un amplio problema de modelado según las restricciones que queramos seguir.

Además, es interesante darse cuenta de que, si se rehicieran las medidas de potencia recibida bajo otras condiciones ambientales, los cálculos podrían simplificarse o dificultarse en gran medida.

Los datos experimentales vienen siempre afectados por errores de medida. Errores que pueden ser sistemáticos o aleatorios.

Los errores sistemáticos son debidos al sistema o aparato de medida y, por lo general, sólo actúan en una dirección. Tienen un numero reducido de causas y normalmente pueden detectarse fácilmente comparando con otras medidas conocidas o mediante un proceso de calibración.

Los errores aleatorios por su parte tienen un número más elevado de causas. Se pueden representar como una suma de variables aleatorias. En numerosos, son casos difíciles de identificar por separado y capaces de contribuir aleatoriamente en cada medida de forma independiente. Aquí radica el problema, en aquellas circunstancias en las que pequeñas contribuciones producen grandes errores aleatorios surgidos como la suma de todas las pequeñas causas independientes.

Pese a que contamos con desventajas importantes, como la duración de las baterías que afecta directamente a la autonomía del sistema, el sistema constituye un mecanismo de fácil instalación, económica y con una necesidad mínima de mantenimiento. Esto hace que sea una buena opción a considerar en el desarrollo de aplicaciones similares.

La localización y medición exacta de la posición es un elemento esencial y fundamental en el problema de redes de sensores inalámbricos.

Ya se conocen estudios de varios métodos de localización representativos de los métodos basados en el alcance de la localización y de los métodos de alcance libre. Hablamos de métodos que son bastantes diferentes en precisión, distribución o centralización.

Se habla en numerosos artículos y páginas informativas de cómo las redes de sensores son una sustancial fuente de beneficios para campos como son el de la seguridad, el medio ambiente y el ámbito sanitario. Aunque de entre todas las aplicaciones que nos ofertan las redes de sensores se dice que el campo donde más

Conclusiones y líneas futuras de trabajo

74

futuro y mayor desarrollo han tenido las redes de sensores es sin duda el de la domótica. Esto puede deberse a que permite repartir por la vivienda tantos módulos ZigBee como queramos conectados a sensores y si se desea a pequeños actuadores.

Nodos que se encuentren dentro o fuera de una edificación pueden comunicarse entre ellos o con una red externa a través de cualquier tecnología de comunicación inalámbrica o incluso, vía satélite. Son posibles un gran número de aplicaciones mediante la interconexión y comunicación de tantos tipos de redes como se nos pueda ocurrir.

Sin embargo, hay un desafío mayor que el de desarrollar y normalizar el uso de ZigBee en nuestro entorno. Este se centra en investigar y desarrollar la evolución del hardware, las soluciones en red y el software para soportar las nuevas tecnologías.

Además de todas las ventajas ya mencionadas, recordamos la gran cantidad de energía que somos capaces de ahorrar en este tipo de redes. Pues el consumo, uno de los problemas de la actual sociedad española debido a los altos costes en combustible y electricidad a los que nos enfrentamos día a día, es mínimo en redes ZigBee. Esto es así, recordamos debido a dos razones principales:

- La pasividad de los nodos finales, aquellos que sólo despiertan y actúan en el momento preciso de realizar una determinada acción.

- La simplicidad de la información intercambiada. El código empleado en estas aplicaciones resulta bastante manajable.

Según afirman, en un futuro no demasiado lejano, la tecnología inalámbrica sustituirá poco a poca a la transmisión tradicional a través de cualquier medio físico. El objetivo que se busca con esto es el de incrementar la comodidad del usuario y realizar de forma sencilla las tareas diarias que puedan resultar monótonas.

5.1.2 Líneas futuras de trabajo

En este Trabajo Fin de Grado se estudia la estimación de la distancia y la evolución de la varianza en los valores RSSI según un método capaz de adaptarse al entorno en el que nos encontremos.

A este podemos sumarle gran utilidad ideando aplicaciones a través de la funcionalidad de cálculo de distancia con autoadaptabilidad. Como por ejemplo podría ser el de desarrollar aplicaciones de seguridad para control de distancia (lejanía-cercanía) de bebés o niños de corta edad e incluso de personas mayores. A través de esta, solo necesitaríamos como hemos visto 3 nodos.

A modo de ejemplo, empleando un nodo sensor transmisor de potencia y que portaría el sujeto (el niño o persona de tercera edad) a modo de pulsera, colgante o como parte de la indumentaria y de una sola pieza. Un segundo nodo receptor fijado en una posición deseada. Y el tercer nodo sería el que haría la función de estación base y que sería capaz de comunicarse con un equipo. El equipo debería de poder ser capaz de traducir la potencia recibida en medida de distancia exacta y como hemos dicho, adaptable al medio. En este sencillo ejemplo, la aplicación ubicada en el equipo podría ser capaz de dar una señal de alarma en caso de superar un cierto umbral de distancia, lo que indicaría que el individuo se aleja demasiado de la zona de control. Y en caso de que así lo deseemos, activar un actuador como respuesta.

A través de la capacidad de adaptación del sistema, podríamos emplearlo tanto en medios interiores como exteriores.

75

6 ANEXO

Como anexo a este trabajo fin de grado se facilita el código empleado en el desarrollo de parte del trabajo de laboratorio.

Así, el contenido de los archivos de código fuente almacenados en el directorio SendingMote es el siguiente:

- SendingMote

o ApplicationDefinitions.h

#ifndef APPLICATIONDEFINITIONS_H__

#define APPLICATIONDEFINITIONS_H__

enum {

SEND_INTERVAL_MS = 250

};

#endif //APPLICATIONDEFINITIONS_H__

o SendingMote.nc

#include "ApplicationDefinitions.h"

#include "RssiDemoMessages.h"

module SendingMoteC {

uses interface Boot;

uses interface Timer<TMilli> as SendTimer;

uses interface AMSend as RssiMsgSend;

uses interface SplitControl as RadioControl;

} implementation {

message_t msg;

event void Boot.booted(){

call RadioControl.start();

}

event void RadioControl.startDone(error_t result){

call SendTimer.startPeriodic(SEND_INTERVAL_MS);

}

Anexo

76

event void RadioControl.stopDone(error_t result){}

event void SendTimer.fired(){

call RssiMsgSend.send(AM_BROADCAST_ADDR, &msg, sizeof(RssiMsg));

}

event void RssiMsgSend.sendDone(message_t *m, error_t error){}

}

o SendingMoteAppC.nc


configuration SendingMoteAppC {

} implementation {

components ActiveMessageC, MainC;

components new AMSenderC(AM_RSSIMSG) as RssiMsgSender;

components new TimerMilliC() as SendTimer;

components SendingMoteC as App;

App.Boot -> MainC;

App.SendTimer -> SendTimer;

App.RssiMsgSend -> RssiMsgSender;

App.RadioControl -> ActiveMessageC;

}

o Makefile

COMPONENT=SendingMoteAppC

INCLUDES= -I..

CFLAGS += $(INCLUDES)

Include$(MAKERULES)


El código fuente correspondiente al directorio RssiBase es el siguiente:

- RssiBase

o ApplicationDefinitions.h

#ifndef APPLICATIONDEFINITIONS_H__

#define APPLICATIONDEFINITIONS_H__

enum {

SEND_INTERVAL_MS = 250

};

#endif //APPLICATIONDEFINITIONS_H__

o RssiBase.nc

#include "ApplicationDefinitions.h"


module RssiBaseC {

uses interface Intercept as RssiMsgIntercept;

#ifdef __CC2420_H__

uses interface CC2420Packet;

#elif defined(TDA5250_MESSAGE_H)

uses interface Tda5250Packet;

#else

uses interface PacketField<uint8_t> as PacketRSSI;

#endif

} implementation {

uint16_t getRssi(message_t *msg);

event bool RssiMsgIntercept.forward(message_t *msg, void *payload, uint8_t len) {

RssiMsg *rssiMsg = (RssiMsg*) payload;

rssiMsg->rssi = getRssi(msg);

return TRUE;

}

#ifdef __CC2420_H__

uint16_t getRssi(message_t *msg){

return (uint16_t) call CC2420Packet.getRssi(msg);

Anexo

78

}

#elif defined(CC1K_RADIO_MSG_H)


cc1000_metadata_t *md =(cc1000_metadata_t*) msg->metadata;

return md->strength_or_preamble;

}

#elif defined(PLATFORM_IRIS)


if(call PacketRSSI.isSet(msg))

return (uint16_t) call PacketRSSI.get(msg);

else

return 0xFFFF;

}



return call Tda5250Packet.getSnr(msg);

}

#else

#error Radio chip not supported! This demo currently works only \

for motes with CC1000, CC2420, RF230 or TDA5250 radios.

#endif

}

o RssiBaseAppC.nc


#include "message.h"

configuration RssiBaseAppC {

} implementation {

components BaseStationC;

components RssiBaseC as App;

#ifdef __CC2420_H__

components CC2420ActiveMessageC;


App -> CC2420ActiveMessageC.CC2420Packet;

#elif defined(PLATFORM_IRIS)

components RF2xxActiveMessageC;

App -> RF2xxActiveMessageC.PacketRSSI;


components Tda5250ActiveMessageC;

App -> Tda5250ActiveMessageC.Tda5250Packet;

#endif

App-> BaseStationC.RadioIntercept[AM_RSSIMSG];

}

o Makefile

COMPONENT=RssiBaseAppC

INCLUDES= -I../InterceptBase

CFLAGS += $(INCLUDES)

ifneq ($(filter iris,$(MAKECMDGOALS)),)

CFLAGS += -DRF230_RSSI_ENERGY

endif

include $(MAKERULES)

El código fuente correspondiente al directorio AppJava es el siguiente:

- AppJava

o RssiMsg.java

/** Create a new RssiMsg of size 2. */

public RssiMsg() {

super(DEFAULT_MESSAGE_SIZE);

amTypeSet(AM_TYPE);

Anexo

80

}

/** Create a new RssiMsg of the given data_length. */

public RssiMsg(int data_length) {

super(data_length);

amTypeSet(AM_TYPE);

}

/**

* Create a new RssiMsg with the given data_length

* and base offset.

*/

public RssiMsg(int data_length, int base_offset) {

super(data_length, base_offset);

amTypeSet(AM_TYPE);

}

/**

* Create a new RssiMsg using the given byte array

* as backing store.

*/

public RssiMsg(byte[] data) {

super(data);

amTypeSet(AM_TYPE);

}

/**


* as backing store, with the given base offset.

*/

public RssiMsg(byte[] data, int base_offset) {

super(data, base_offset);

amTypeSet(AM_TYPE);

}

/**


* as backing store, with the given base offset and data length.


*/

public RssiMsg(byte[] data, int base_offset, int data_length) {

super(data, base_offset, data_length);

amTypeSet(AM_TYPE);

}

/**

* Create a new RssiMsg embedded in the given message

* at the given base offset.

*/

public RssiMsg(net.tinyos.message.Message msg, int base_offset) {

super(msg, base_offset, DEFAULT_MESSAGE_SIZE);

amTypeSet(AM_TYPE);

}

/**

* Create a new RssiMsg embedded in the given message

* at the given base offset and length.

*/

public RssiMsg(net.tinyos.message.Message msg, int base_offset, int data_length) {

super(msg, base_offset, data_length);

amTypeSet(AM_TYPE);

}

/**

/* Return a String representation of this message. Includes the

* message type name and the non-indexed field values.

*/

public String toString() {

String s = "Message <RssiMsg> \n";

try {

s += " [rssi=0x"+Long.toHexString(get_rssi())+"]\n";

} catch (ArrayIndexOutOfBoundsException aioobe) { /* Skip field */ }

return s;

}

Anexo

82

/**

* Return whether the field 'rssi' is signed (true).

*/

public static boolean isSigned_rssi() {

return true;

}

/**

* Return whether the field 'rssi' is an array (false).

*/

public static boolean isArray_rssi() {

return false;

}

/**

* Return the offset (in bytes) of the field 'rssi'

*/

public static int offset_rssi() {

return (0 / 8);

}

/**

* Return the offset (in bits) of the field 'rssi'

*/

public static int offsetBits_rssi() {

return 0;

}

/**

* Return the value (as a short) of the field 'rssi'

*/

public short get_rssi() {

return (short)getSIntBEElement(offsetBits_rssi(), 16);

}

/**

* Set the value of the field 'rssi'

*/


public void set_rssi(short value) {

setSIntBEElement(offsetBits_rssi(), 16, value);

}

/**

* Return the size, in bytes, of the field 'rssi'

*/

public static int size_rssi() {

return (16 / 8);

}

/**

* Return the size, in bits, of the field 'rssi'

*/

public static int sizeBits_rssi() {

return 16;

}

}

o RssiDemo.java

import java.io.IOException;

import net.tinyos.message.*;

import net.tinyos.packet.*;

import net.tinyos.util.*;

public class RssiDemo implements MessageListener {

private MoteIF moteIF;

public RssiDemo(MoteIF moteIF) {

this.moteIF = moteIF;

this.moteIF.registerListener(new RssiMsg(), this);

}

public void messageReceived(int to, Message message) {

double rssi_dbm;

RssiMsg msg = (RssiMsg) message;

Anexo

84

int source = message.getSerialPacket().get_header_src();

rssi_dbm = (double)(msg.get_rssi()) - 45;

System.out.println("Rssi Message received from node " + source + ": Rssi = " + rssi_dbm);

}

private static void usage() {

System.err.println("usage: RssiDemo [-comm <source>]");

}

public static void main(String[] args) throws Exception {

String source = null;

if (args.length == 2) {

if (!args[0].equals("-comm")) {

usage();

System.exit(1);

}

source = args[1];

}

else if (args.length != 0) {

usage();

System.exit(1);

}

PhoenixSource phoenix;

if (source == null) {

phoenix = BuildSource.makePhoenix(PrintStreamMessenger.err);

}

else {

phoenix = BuildSource.makePhoenix(source, PrintStreamMessenger.err);

}

MoteIF mif = new MoteIF(phoenix);

RssiDemo serial = new RssiDemo(mif);

}

}


o Makefile

all: RssiDemo.class

RssiMsg.class: RssiMsg.java

javac $<RssiDemo.class: RssiDemo.java RssiMsg.java javac $^

RssiMsg.java: ../RssiDemoMessages.h

mig java -target=null -java-classname=RssiMsg $< RssiMsg -o $@

Anexo

86

87

BIBLIOGRAGÍA

[1] Bibing.us.es/proyectos :TinyOS, tarjeta de adquisición de datos..

[2] http://www.openautomation.net/page/productos/id/30/title/MIB510-Serial-Gateway: MIB510 hardware

[3] Trabajo fin de carrera de José López López y Sergio Mena Doce. Título: Desarrollo de un demostrador para evaluar técnicas Cross-Layer en sistemas de comunicaciones inalámbricos UPC.

[4]https://riunet.upv.es/bitstream/handle/10251/8592/PFC%20%20DESARROLLO%20DE%20APLICACIONES%20BASADAS%20EN%20WSN.pdf : Desarrollo de Aplicaciones basadas en WSN.

[5] http://www.revistaambienta.es/WebAmbienta/marm/Dinamicas/secciones/articulos/AP.htm

[6] WSN.pdf

[7] Chiara Buratti, Marco Martalò, Roberto Verdone, Gianluigi Ferrari, Sensor network with IEEE 802.15.4 Systems.

[8] Fabrizio Saponaro, SO de fuentes abiertas desarrollado para redes inalámbricas de sensores empotrados (Universidad de Granada)

[9] José Ulloa Suárez, Estudio y Análisis de las Características de TinyOS.

[10] Manchun Zheng, Jun Sun, Yang Liu, Jin Song Dong and Yu Gu, Toward a Model Checker for NesC and Wireless Sensor Networks. Singapore University of Technology and Design.

[11] Manual de Nesc 1.1

[12] http://www.tinyos.net/tinyos-1.x/doc/tutorial/lesson1.html, tutorial lesson. Lesson 1: Getting Started with TinyOS and nesC

[13] YuWang and Lin Li, Chapter 10, RFID AND SENSOR NETWORKS: Architectures, Protocols, Security and Integrations

[14] https://sites.google.com/site/numerictron/unidad-4/4-3-regresion-por-minimos-cuadrados-lineal-y-cuadratica

[15] http://www.monografias.com/trabajos86/analisis-regresion-parabola-minimos-cuadros/analisis-regresion-parabola-minimos-cuadros.shtml#ixzz3uKQhVjUW

[16] Manual de NesC 1.1

[17] bibing.us.es

[18] http://user.informatik.uni-goettingen.de/~sensorlab/Hardware.php#mda300ca

[19] http://www.SciRP.org/journal/wsn

[20] http://www.dsi.uclm.es/personal/EvaMariaGarcia/docs/2008-Curso Verano.pdf

[21] Sara Berzosa Calpe. Proyecto Fin de Carrera. Optimización de un protocolo de encaminamiento en redes de sensores IEEE 802.15.4.

[22] http://ddalkiel.blogspot.com.es/p/sintesis.html

[23] Jose Manuel Linares Arenas. Proyecto Fin de Carrera. Simulación e Implementación de una red de sensores inalámbrica multisalto para la medición de consumo energético en un edificio.

[24] Sebastián Román Maroto Cantillo. Desarrollo de aplicaciones basadas en WSN.

[25] Miguel Villagrán Marín. Localización en interiores usando redes inalámbricas de sensores: Implementación práctica.

Bibliogragía

88

[26]http://profesores.elo.utfsm.cl/~agv/elo323/2s10/Assignment/TinyOSWin/Instalar%20TinyOS%20sobre%20Windows.html

[27]http://es.mathworks.com/products/matlab/

[28]http://en.wikipedia.org/wiki/Inverse_square

Documents

Trabajo Fin de Grado Grado en Ingeniería de las …bibing.us.es/proyectos/abreproy/90714/fichero/...2016/07/08 · -La demostración o comparación del modelos LNSM-DV en métodos