Diseño de un concentrador para aplicaciones de redes...
109
DISEÑO DE UN CONCENTRADOR PARA APLICACIONES DE REDES DE SENSORES CON CAPACIDADES DE RECONFIGURACIÓN DE PARÁMETROS POR SOFTWARE CLAUDIA ESPERANZA SEGURA CANO MIGUEL ANGEL SASTOQUE CARO UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA ELECTRÓNICA BOGOTÁ 2016
Transcript of Diseño de un concentrador para aplicaciones de redes...
DISEÑO DE UN CONCENTRADOR PARA APLICACIONES DE REDES DE SENSORES CON CAPACIDADES DE RECONFIGURACIÓN DE PARÁMETROS POR SOFTWARE
CLAUDIA ESPERANZA SEGURA CANO MIGUEL ANGEL SASTOQUE CARO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA ELECTRÓNICA
BOGOTÁ 2016
DISEÑO DE UN CONCENTRADOR PARA APLICACIONES DE REDES DE SENSORES CON CAPACIDADES DE RECONFIGURACIÓN DE PARÁMETROS POR SOFTWARE
CLAUDIA ESPERANZA SEGURA CANO 20092005096
MIGUEL ANGEL SASTOQUE CARO
20101005072
TRABAJO DE GRADO PARA OPTAR POR EL TÍTULO DE INGENIERO ELECTRÓNICO
GUSTAVO ADOLFO PUERTO LEGUIZAMÓN DOCENTE DE PLANTA FACULTAD DE INGENIERÍA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS PHD EN TELECOMUNICACIONES
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA ELECTRÓNICA
BOGOTÁ 2016
3
DEDICATORIA
Dedico este trabajo a mi mamá y mis hermanos a quienes quiero mostrarles que la vida puede
ser mejor si uno se lo propone. A mi tío Luis Alejandro Segura y a Felipe Augusto Zúñiga
Gonzales por creer en mí, por todo su apoyo y porque permitieron que la vida siempre fuera
mejor. A Miguel Angel Sastoque por su colaboración a lo largo de este proceso académico
ayudándome a ser cada vez mejor. A todos ustedes dedico este trabajo, pues con su apoyo pude
lograr alcanzar esta meta.
Dedico este trabajo a mis padres y mis hermanos por su apoyo y sacrificio. A Claudia Segura
por su apoyo y comprensión en los momentos más difíciles. Al ingeniero Gustavo Puerto
por ofrecerme la oportunidad de trabajar en este proyecto, por la guia y el soporte brindado
durante la realización de este trabajo.
4
AGRADECIMIENTOS
En primer lugar, se quiere hacer un reconocimiento muy especial al Doctor Gustavo Puerto por
habernos brindado todo su apoyo y disposición para llevar a cabo este proyecto. También al
grupo LIMER y su director Carlos Suárez por su apoyo y críticas constructivas que aportaron
de gran manera. Al grupo LAMIC por haber facilitado los espacios físicos que hicieron posible
el desarrollo del proyecto. A la Universidad Distrital Francisco José de Caldas, por haber creado
los espacios y las capacidades necesarias durante estos años de estudio. A Colciencias por haber
contribuido con los recursos económicos para la adquisición de las herramientas de desarrollo.
Y por supuesto a nuestras familias, y amigos que nos dieron su apoyo incondicional.
5
CONTENIDO
1. INTRODUCCIÓN ............................................................................................................................................. 11
2. OBJETIVOS ....................................................................................................................................................... 12
2.1 OBJETIVO GENERAL ................................................................................................................................. 12
2.2 OBJETIVOS ESPECÍFICOS ........................................................................................................................ 12
3. PLANTEAMIENTO DEL PROBLEMA ...................................................................................................... 13
3.1 DEFINICIÓN DEL PROBLEMA ............................................................................................................... 13
3.2 JUSTIFICACIÓN ........................................................................................................................................... 13
3.3 HIPÓTESIS..................................................................................................................................................... 14
4. ALCANCES Y LIMITACIONES .................................................................................................................... 15
4.1 ALCANCES ..................................................................................................................................................... 15
4.2 LIMITACIONES ............................................................................................................................................ 15
5. ESTADO DEL ARTE ....................................................................................................................................... 16
5.1 RADIO DEFINIDA POR SOFTWARE .................................................................................................... 16
5.1.1 La Radio Cognitiva ........................................................................................................................... 16
5.1.2 Características de la Radio Definida por Software ............................................................. 17
5.2 REDES DE SENSORES INALÁMBRICOS ............................................................................................. 18
5.2.1 Entornos de Aplicación de las Redes de Sensores y sus Problemas ............................ 19
5.2.2 Sistemas móviles de seguimiento .............................................................................................. 26
5.2.3 Perspectiva de las Redes de Sensores ...................................................................................... 27
5.3 OPORTUNIDADES DE INTEGRACIÓN ................................................................................................ 28
5.4 TRABAJOS RELACIONADOS................................................................................................................... 29
6. ANÁLISIS TÉCNICO DEL PROTOCOLO ZIGBEE ................................................................................. 31
6.1 CONFIGURACIÓN DE LOS MÓDULOS XBEE .................................................................................... 33
6.2 CAPA DE APLICACIÓN ............................................................................................................................. 35
6.3 CAPA DE RED ............................................................................................................................................... 36
6.4 CAPA DE ENLACE ....................................................................................................................................... 38
6.5 CAPA FÍSICA ................................................................................................................................................. 40
6.5.1 Trama de la Capa Física ................................................................................................................. 40
6.5.2 Codificación y Modulación ............................................................................................................ 41
6.5.3 Asignación de canales ..................................................................................................................... 43
7. DESARROLLO E IMPLEMENTACIÓN .................................................................................................... 44
7.1 HERRAMIENTAS DE DESARROLLO ................................................................................................... 44
6
7.1.1 Software ............................................................................................................................................... 44
7.1.2 Hardware ............................................................................................................................................. 49
7.1.3 Tarjeta de desarrollo USRP B210 .............................................................................................. 50
7.2 ENTORNO DE APLICACIÓN A IMPLEMENTAR .............................................................................. 52
7.3 NODOS XBEE ................................................................................................................................................ 53
7.4 CONCENTRADOR ....................................................................................................................................... 55
7.4.1 Capa Física del Xbee ........................................................................................................................ 56
7.4.2 Capa de Enlace del Xbee ................................................................................................................ 61
7.4.3 Capa de Red del Xbee ...................................................................................................................... 62
7.4.4 Capa de Aplicación del Xbee ......................................................................................................... 62
8. VALIDACIÓN DEL SISTEMA ...................................................................................................................... 64
8.1 VALIDACIÓN FUNCIONAL DE LOS BLOQUES ................................................................................ 64
8.2 RESULTADOS DEL LQI Y PER ............................................................................................................... 73
8.2.1 Medición de la Calidad del Enlace.............................................................................................. 73
8.2.2 Medición de la Tasa de Paquetes Erróneos ........................................................................... 74
8.3 PRUEBAS IMPLEMENTADAS ................................................................................................................ 74
8.4 PROBLEMÁTICAS EN EL DESARROLLO ........................................................................................... 78
9. CONCLUSIONES ............................................................................................................................................. 80
10. APORTES .......................................................................................................................................................... 81
10.1 CARÁCTER INNOVADOR Y FUNCIONAL DE LA PROPUESTA .................................................. 81
10.2 GENERACIÓN DE CONOCIMIENTO..................................................................................................... 81
10.3 IMPACTOS ..................................................................................................................................................... 82
11. TRABAJO FUTURO ........................................................................................................................................ 84
12. BIBLIOGRAFÍA ............................................................................................................................................... 85
13. ANEXOS ............................................................................................................................................................. 88
13.1 CÓDIGO NODOS XBEE .............................................................................................................................. 88
13.2 CÓDIGOS CAPA DE APLICACIÓN XBEE EN GNU RADIO ............................................................ 92
13.2.1 XML Rx App ......................................................................................................................................... 92
13.2.2 Python Rx App ................................................................................................................................... 92
13.2.3 XML Tx App ......................................................................................................................................... 93
13.2.4 Python Tx App.................................................................................................................................... 94
13.3 CÓDIGOS CAPA DE RED XBEE EN GNU RADIO .............................................................................. 95
13.3.1 XML Rx Nwk ........................................................................................................................................ 95
13.3.2 Python Rx Nwk .................................................................................................................................. 95
13.3.3 ML Tx Nwk ........................................................................................................................................... 96
7
13.3.4 Python Tx Nwk .................................................................................................................................. 97
13.4 CÓDIGOS CAPA MAC XBEE EN GNU RADIO .................................................................................... 98
13.4.1 XML Rx Mac ......................................................................................................................................... 98
13.4.2 Python Rx Mac ................................................................................................................................... 99
13.4.3 XML Tx MAC ...................................................................................................................................... 100
13.4.4 Python Tx Mac ................................................................................................................................. 100
13.5 INTERFAZ DE USUARIO CONCENTRADOR ................................................................................... 102
13.5.1 Gráfica Temperatura Xbee .......................................................................................................... 102
13.5.2 Código python flujograma........................................................................................................... 103
LISTA DE TABLAS
Tabla 1. Trama de aplicación. ............................................................................................................................... 35 Tabla 2. Sub trama de control para la capa de aplicación......................................................................... 35 Tabla 3. Tipos de trama para la trama de aplicación. ................................................................................. 35 Tabla 4. Modos de entrega. .................................................................................................................................... 35 Tabla 5. Trama de red. ............................................................................................................................................. 36 Tabla 6. Sub-trama del campo de control para la trama de red. ............................................................ 36 Tabla 7. Tipo de trama para la capa de red. .................................................................................................... 37 Tabla 8. Versiones del protocolo ZigBee .......................................................................................................... 37 Tabla 9. Valores para la habilitación o inhabilitación del descubrimiento de ruta ....................... 37 Tabla 10. Trama MAC............................................................................................................................................... 38 Tabla 11. Sub-trama de control de la trama MAC ........................................................................................ 39 Tabla 12. Tipos de trama para la trama MAC ................................................................................................ 39 Tabla 13. Modos de direccionamiento destino y fuente............................................................................ 39 Tabla 14. Trama de capa Física ............................................................................................................................ 40 Tabla 15. Comandos del campo de longitud de trama ............................................................................... 41 Tabla 16. Comparación, características y costos de tarjetas de desarrollo. ...................................... 50 Tabla 17. Especificaciones de la configuración de los nodos .................................................................. 52 Tabla 18. Tabla para el bloque Chunk to Symbols ....................................................................................... 58 Tabla 19. Tasas de muestreo. .............................................................................................................................. 58 Tabla 20. Secuencia e bits para la recuperación de los símbolos desde los chips .......................... 60 Tabla 21. Mensaje enviado desde los módulos Xbee al concentrador ................................................ 63 Tabla 22. Pruebas de transmisión y recepción del sistema ..................................................................... 74 Tabla 23. Parámetros de configuración del sistema. .................................................................................. 74 Tabla 24. Resultados de la medida del LQI ..................................................................................................... 77 Tabla 25. Resultados de la medida del PER .................................................................................................... 77
8
LISTA DE FIGURAS
Figura 1. Diagrama de bloques funcionales de un equipo RDS [8] ....................................................... 16 Figura 2. Relación entre Radio Cognitiva y Radio definida por Software [9]. .................................. 17 Figura 3. Esquema básico de una red de sensores. ..................................................................................... 19 Figura 4. Diagrama funcional de un nodo de sensado. .............................................................................. 19 Figura 5. Esquema organizacional de las redes inalámbricas según su cobertura. ....................... 31 Figura 6. Diagrama de capas del protocolo ZigBee [59] ............................................................................ 32 Figura 7. Tramas de las capas del protocolo ZigBee ................................................................................... 32 Figura 8. Dispositivos Xbee S2 que se implementan en este trabajo ................................................... 33 Figura 9. Información propia de cada dispositivo ....................................................................................... 33 Figura 10. Trama API para Xbee S2 ................................................................................................................... 34 Figura 11. Diagrama de modulación y propagación. .................................................................................. 41 Figura 12. Conversión de símbolos a chips.[61] ........................................................................................... 42 Figura 13. Forma de medio pulso de onda sinusoidal ............................................................................... 43 Figura 14. Canales en el estándar IEEE 802.15.4 [62] ............................................................................... 43 Figura 15. Interfaz gráfica de usuario de GRC ............................................................................................... 45 Figura 16. Verificación funcionalidad bloque Square_ff ............................................................................ 48 Figura 17. Tarjeta USRP B210 .............................................................................................................................. 50 Figura 18. Antena de la USRP ............................................................................................................................... 51 Figura 19. Flujograma con bloques para el uso de la tarjeta B210. ...................................................... 52 Figura 20. Esquema de la implementación red de sensores ................................................................... 53 Figura 21.Elementos básicos del nodo ............................................................................................................ 53 Figura 22. Diagrama de flujo del software del microcontrolador ......................................................... 54 Figura 23. Diagrama esquemático Nodo. ......................................................................................................... 54 Figura 24. Simulación diseño PCB. ..................................................................................................................... 55 Figura 25. Nodo Xbee con LCD y sensor de temperatura implementado. ......................................... 55 Figura 26. Bloque de recepción de la capa física .......................................................................................... 57 Figura 27. Diagrama de bloques del Transmisor OQPSK .......................................................................... 57 Figura 28. Bloque de recepción de capa física O-QPSK .............................................................................. 59 Figura 29. Flujograma del bloque de recepción de capa física O-QPSK .............................................. 59 Figura 30. Diagrama de flujo del funcionamiento del bloque ‘Packet Sink’ ....................................... 61 Figura 31. Bloque de transmisión de la capa de enlace ............................................................................. 61 Figura 32. Bloque de recepción de la capa de enlace ................................................................................. 62 Figura 33. Bloque de transmisión de la capa de red ................................................................................... 62 Figura 34. Bloque de recepción de la capa de red........................................................................................ 62 Figura 35. Módulo de transmisión de la capa de aplicación .................................................................... 63 Figura 36. Capa de aplicación en recepción de los módulos Xbee ........................................................ 63 Figura 37. Pruebas entre el concentrador y los nodos Xbee ................................................................... 64 Figura 38. Mensajes enviados y recibidos en los nodos Xbee ................................................................. 64 Figura 39. Flujograma de transmisión y recepción para las tramas ZigBee ..................................... 65 Figura 40. Datos de salida de la capa física de recepción ......................................................................... 66 Figura 41. Datos de salida de la capa de enlace de recepción ................................................................. 66 Figura 42. Datos de salida de la capa de red en recepción ....................................................................... 67 Figura 43. Datos de salida de la capa de red en recepción ....................................................................... 67 Figura 44. Datos de salida del bloque message strobe ............................................................................... 68 Figura 45. Datos de salida de la capa de aplicación para transmisión ................................................ 69 Figura 46. Datos de salida de la capa de red para transmisión .............................................................. 69
9
Figura 47. Datos de salida de la capa de enlace para transmisión ........................................................ 70 Figura 48. Trama PPDU modulada y codificada ........................................................................................... 70 Figura 49. Señal de espectro del canal se transmisión de los datos PPDU ........................................ 71 Figura 50. Interfaz gráfica de usuario. .............................................................................................................. 71 Figura 51. Ventanas de configuración de parámetros ............................................................................... 72 Figura 52. Medidas realizadas a 8 m ................................................................................................................. 75 Figura 53. Medidas realizadas a 32 m ............................................................................................................... 75 Figura 54. Resultados de la señal con una tasa de muestreo a 4 Msps ............................................... 76 Figura 55. Resultados de la señal con una tasa de muestreo a 4 Msps ............................................... 76 Figura 56. Resultados de la medida del PER .................................................................................................. 77 Figura 57. Resultados de la medida del LQI ................................................................................................... 78
10
RESUMEN
A lo largo de este trabajo se presenta el proceso de diseño de un concentrador que implementa funcionalidades de radio definida por software, para comunicar redes de sensores inalámbricos compuestas por dispositivos Xbee. Inicialmente se realiza una revisión del estado del arte de las redes de sensores y sus problemáticas. En ellas se encuentran oportunidades para la implementación de los conceptos de radio definida por software que permite solucionar gran parte de las necesidades encontradas. Luego de un análisis de las herramientas de desarrollo se decide utilizar la tarjeta USRP B210 con el software libre GNU Radio.
Adicionalmente, se realiza un análisis detallado del protocolo de capas que implementan los módulos Xbee, se analizan las tramas que implementan, los campos que las conforman y las funcionalidades de radio que se implementan en los dispositivos a partir de hardware. Con base en dicho análisis se elaboran y ejecutan bloques de transmisión y recepción para cada una de las capas en el software libre GNU radio. Para comprobar que los bloques elaborados tienen un correcto funcionamiento y cumplen las funciones que se definen en las especificaciones, se realizan lecturas en las salidas de cada uno de los bloques. También se realizan pruebas que permiten verificar que en el desarrollo se implementan funcionalidades de radio a partir de software, para ello se elabora una interfaz gráfica que permite modificar parámetros de forma dinámica. Finalmente se hacen mediciones del indicador de la calidad de enlace y del error de paquetes para determinar la eficiencia que tiene este desarrollo.
ABSTRACT
The design of a gateway that incorporates some concepts of software defined radio (SDR) in wireless sensor networks with Xbee modules is presented in this work. At first, a state of the art about wireless sensor network and their associated problems was carried out in order to find opportunities to implement SDR functionalities to solve the requirements within the environment of a wireless sensor networks. Also, the analysis of development tool is presented, in addition a USRP B210 with GNU Radio is used. Furthermore, a detailed analysis of Xbee layer protocol is presented, including frames fields and hardware capabilities. According with this analysis, transmission and reception functional blocks are developed in GNU Radio. In order to verify the functionality, each one is tested and output values can be monitored. Finally, experimental tests are carried out using a graphic user interface with capabilities of modifying parameters dynamically. Finally, LQI and PER measurements are performed.
11
1. INTRODUCCIÓN
La sociedad moderna demanda cada vez más el acceso a la información, convirtiendo las telecomunicaciones en una de las áreas del conocimiento más dinámicas y de mayor interés en los últimos tiempos. Hoy en día, las telecomunicaciones se enfrentan a nuevos desafíos. El aumento de las velocidades de transferencia de información, así como el uso eficiente del espectro ocupa el interés de la industria y académicos[1]. Al mismo tiempo, se ha experimentado un crecimiento significativo en el uso de Redes de Sensores Inalámbricas (RSI) en el campo de la automatización industrial y del hogar, control de procesos, monitoreo agrícola, asistencia médica, transporte público, sistemas de atención en emergencias, entre otros. Las RSI se integran cada vez más a las actividades cotidianas mejorando y optimizando diversas labores. Todo este desarrollo ha permitido ir materializando conceptos como el de “Internet of the Things” [2], en donde las RSI se integran en el esquema ya conocido como TCP/IP.
Bajo este escenario, el concepto de Radio Definida por Software (RDS) toma gran importancia debido a las técnicas de acceso dinámico al espectro que permite ésta tecnología. Por otra parte, la capacidad de versatilidad y convergencia de RDS brinda nuevas opciones para atender los requerimientos de la cantidad de servicios y aplicaciones que siguen apareciendo dentro de las comunicaciones inalámbricas [1,2].
Con este desarrollo se quiere hacer un acercamiento a las RSI desde un enfoque de integración con RDS. Por consiguiente, se presenta una revisión actual de las RSI resaltando su importancia, sus aplicaciones en diferentes campos, sus problemas y necesidades; se introduce el concepto de RDS, sus características, los sistemas de desarrollo disponibles y finalmente se aborda la implementación del RDS en una red de sensores inalámbrica.
12
2. OBJETIVOS
2.1 OBJETIVO GENERAL
Diseñar un concentrador (Gateway) sobre una plataforma de desarrollo, que implemente conceptos de RDS en un entorno en red de sensores inalámbricos.
2.2 OBJETIVOS ESPECÍFICOS
Identificar las diferentes configuraciones de redes de sensores susceptibles de integrar sistemas electrónicos basados en radio definida por software.
Identificar la plataforma hardware apropiada para la implementación de un concentrador de redes de sensores con funcionalidades radio definida por software.
Establecer las variables de radio definida por software apropiadas para implementar en un Gateway para redes de sensores inalámbricas.
Implementar los bloques digitales de comunicación que conforman el Gateway en una plataforma de desarrollo e incorporar una de las variables radio definida por software identificadas.
Evaluar el sistema desarrollado en términos de su incorporación a diferentes entornos de sensado.
13
3. PLANTEAMIENTO DEL PROBLEMA
3.1 DEFINICIÓN DEL PROBLEMA
Las redes de sensores inalámbricas se han implementado con mayor frecuencia en diferentes campos como la agricultura, la industria y la medicina, durante los últimos años. En cada uno de estos entornos las necesidades son diferentes, de manera que es necesario implementar un hardware específico para cada aplicación, que cumpla con los requerimientos exigidos, aun así, las condiciones de los lugares resultan ser muy variables, dificultando el diseño de la red. En algunos casos resulta provechoso conocer la información de cada nodo en tiempo real.
Estos esquemas no satisfacen las exigencias del mercado, pues son poco flexibles y escalables con las modificaciones que pueda requerir la red a mediano y largo plazo, por ejemplo cambios en la topología, inclusión de más nodos o interoperabilidad con otros estándares de comunicación, demandando una inversión significativa en tiempo y dinero para rediseñar la red, de manera que se adecue a las nuevas exigencias.
En ese orden de ideas el proyecto contempla en primer lugar la robustez e interoperabilidad como variables de gran impacto del trabajo propuesto. Será también necesario tener en cuenta aspectos como la funcionalidad, la cobertura, el costo, aclarando que tendrán menor relevancia dentro del desarrollo. En términos de la cuantificación de estas variables se tendrá que verificar la correcta transmisión de datos desde los sensores hasta el nodo central, también se contabilizará el número de sistemas diferentes con los que el dispositivo central podrá comunicarse.
3.2 JUSTIFICACIÓN
La gran cantidad de aplicaciones que se están concibiendo para las Redes de Sensores Inalámbricos, en materia agrícola, salud, transporte, movilidad, seguridad, entre otros; hacen de RDS una solución que podría abarcar la mayoría de problemas, permitiendo la convergencia, la adaptabilidad y la robustez en las redes de sensores inalámbricas a implementar.
Los conceptos relacionados con la Radio Definida por Software son de gran interés en el campo de las comunicaciones inalámbricas, dada su reciente aparición los trabajos realizados en el área enriquecerán la base de conocimiento en la implementación de esta tecnología.
La utilización de una plataforma de desarrollo reconfigurable permite la implementación de los bloques funcionales, sin necesidad de adquirir un hardware diferente.
Este tipo de diseño abre la puerta a un gran rango de aplicaciones en donde existen diferentes tecnologías o estándares y se requiere convergencia a nivel de procesamiento para cada una de ellas a fin de reducir costos de despliegue. Asimismo, la reconfiguración de elementos del sistema de transmisión permite que el dispositivo sea robusto en entornos de utilización en donde se tienen condiciones variables de trabajo debido a ruido o interferencias electromagnéticas.
14
Debido al creciente auge que está tomando “el internet de las cosas”, se han hecho estudios sobre diferentes posibilidades de implementar una plataforma que permita obtener la información de los dispositivos en tiempo real, de manera confiable. Radio Definida por Software es hasta el momento el sistema que presenta mayor robustez en el análisis y monitoreo de los datos[3-5].
3.3 HIPÓTESIS
La integración de las características de Radio definida por Software en un Gateway, permitirá la sustitución de elementos de hardware a través de software generando flexibilidad en un entorno de redes de sensores, además de utilizar de manera más eficiente el canal de transmisión y de integrar diferentes estándares. Estas características darán mayor robustez para las Redes de Sensores Inalámbricas.
15
4. ALCANCES Y LIMITACIONES
4.1 ALCANCES
Con la realización de este proyecto se espera hacer un aporte en la validación del paradigma de la Radio definida por Software aplicado a redes de sensores, que sirva como base de conocimiento para investigaciones futuras donde se realicen implementaciones con la plataforma de desarrollo utilizada.
Así mismo, el proyecto tendrá como fin, el diseño y la implementación de un dispositivo que sirva como puerta de enlace entre dos sistemas de comunicaciones diferentes. El dispositivo no será completamente autónomo, pero tendrá la posibilidad de ajustar los parámetros de transmisión (frecuencia, modulación y codificación), para establecer comunicación con diferentes dispositivos dentro de una red de sensores.
Los resultados de este trabajo tienen proyectado además de una validación del funcionamiento del dispositivo concentrador, un análisis de operación en un entorno de redes de sensores.
Por otra parte cabe aclarar que este desarrollo tiene una finalidad académica e investigativa, sin embargo, se quiere enfocar en una aplicación práctica que se encuentre dentro de la revisión de necesidades de las redes de sensores.
4.2 LIMITACIONES
El desarrollo del presente proyecto está limitado a la comprobación de comunicación y validación de funcionamiento y propiedades de un concentrador o Gateway para redes de sensores con capacidades de Radio definida por Software en un entorno de pruebas de laboratorio, el presente proyecto no incluye la realización de pruebas de campo ligadas a una aplicación específica ni comercialización del sistema desarrollado.
16
5. ESTADO DEL ARTE
5.1 RADIO DEFINIDA POR SOFTWARE
El término “Software Radio” fue utilizado a comienzos de la década de los 90’s por Joseph Mitola III para referirse a un tipo de radio que era capaz de implementar diferentes estándares de comunicaciones desde un mismo hardware, para esto, designaba las funciones de modulación y codificación de la señal a partir del software [6]. La radio por software busca trabajar la señal en su mayor parte en el dominio digital para poder delegar algunas funciones del hardware al software, para esto se utilizan conversores análogos a digital (ADC) y digital a análogo (DAC). En la figura 1 se muestra un diagrama de bloques funcional de un equipo de radio definida por software (RDS), donde se muestran tres secciones importantes. La sección RF que recibe y envía la señal al medio, compuesta en esencia por la antena y amplificadores de radio frecuencia. La sección IF se encarga de cambiar de dominio a la señal, es decir, en el caso de un receptor la señal pasa del dominio análogo al digital, así mismo se lleva la frecuencia de trabajo a una frecuencia intermedia por medio de los módulos Digital Down-Converter (DDC). Por último, la sección de banda base es donde se procesa la señal para demodular y decodificar, y así extraer la información [7].
Figura 1. Diagrama de bloques funcionales de un equipo RDS [8]
5.1.1 La Radio Cognitiva
El concepto inicial de radio cognitiva hace referencia a un ente autónomo capaz de identificar alguna situación específica en un canal de comunicaciones y adaptarse a las nuevas exigencias que se requieran por parte del usuario. En este sentido, la radio cognitiva puede solucionar muchos de los inconvenientes que se presentan en las comunicaciones actuales; por ejemplo, el acceso dinámico al espectro por parte de usuarios no licenciados dentro de frecuencias subutilizadas; el cambio de canales de frecuencia debido a altos niveles de interferencia dentro de las ya asignadas bandas libres, mantener altos niveles de calidad de servicio sin importar las condiciones del medio, garantizando la fiabilidad de los datos.
Básicamente RDS es el núcleo que soporta la construcción de la radio cognitiva, RDS es la tecnología de hardware que es capaz de implementar funciones de reconfiguración de
N
RF Front-End
ADC
DDC
Procesador
Sección RF Sección IF Sección BB
M
DAC
DUC
17
diferentes parámetros de la capa física del sistema comunicaciones, RDS soporta diferentes estándares (GSM, EDGE, Wi-Fi, WiMax, WCDMA) y múltiples técnicas de acceso al medio (TDMA, CDMA, OFDMA, SDMA). En ese sentido la radio cognitiva utiliza las herramientas que le brinda RDS como base para adaptarse al sistema, ésta debe tomar decisiones de forma autónoma y coherente con las necesidades del ambiente y para esto es necesario la implementación de un motor cognitivo que mediante algoritmos determine la mejor forma de proceder. En este sentido se podría decir que la radio cognitiva es la implementación de RDS de forma adecuada mediante esquemas de inteligencia artificial que permitan dotar de características de aprendizaje y resolución de problemas complejos al sistema [9]. En la figura 2 se puede ilustrar de mejor manera este concepto.
Motor
Cognitivo
Sensado
del entorno
Funciones de
Capa Superior
SDR
Radio Cognitiva
Figura 2. Relación entre Radio Cognitiva y Radio definida por Software [9].
5.1.2 Características de la Radio Definida por Software
RDS es una tecnología que surgió con el objetivo de brindar una plataforma que tuviera características de adaptabilidad e interoperabilidad en un ambiente desconocido, en sus inicios, la idea fue concebida dentro de un proyecto militar que buscaba la integración de 10 tecnologías de comunicaciones que funcionaban a principio de la década de los 90. No obstante, RDS causó un gran interés desde la industria y la academia, debido a todos los beneficios que podría traer en términos de convergencia de las redes de comunicaciones. Algunas de las características que se buscan alcanzar bajo la tecnología de RDS de acuerdo a [8, 10-12] son:
Interoperabilidad, la razón principal de RDS, en vista que la mayoría de las funcionalidades de los equipos recaen en el software, surge la posibilidad de cambiar estándares, bandas de operación, y finalmente aplicaciones con un mismo dispositivo.
Escalabilidad, uno de los problemas de los aparatos electrónicos es que cada vez tienen que ser reemplazados con mayor prontitud, ya sea por la misma dinámica del mercado que sugiere unos requerimientos distintos o por la utilización de nuevos estándares en la industria. En este sentido tener un dispositivo que se pueda actualizar a dichos cambios simplemente por software sin necesidad de cambiar el equipo, brinda una oportunidad bastante significativa en términos de reducción de costos. Aspectos como el mantenimiento de un sistema de comunicaciones, la inclusión de nuevos elementos dentro de la red, la actualización de los equipos debido a la exigencia de nuevos requerimientos, e incluso la certificación de los equipos; son tareas que eventualmente podrían acarrear costos elevados. Estos costos serán disminuidos si los sistemas se pueden implementar mediante software.
18
Adaptabilidad y robustez, en general se pueda afirmar que en un sistema de comunicaciones lo más importante es asegurar que la información llegue al receptor sin errores, es por esto que se presta tanta atención a los presupuestos de potencia y ancho de banda en el diseño de los sistemas de comunicaciones. Para esto es de vital importancia identificar claramente el medio por el cual será transmitido el mensaje; sin embargo, en escenarios donde el ambiente es desconocido, de difícil acceso, o presentan cambios abruptos en su comportamiento y es necesario entablar un canal de comunicaciones confiable a toda costa, sería de gran ayuda tener una plataforma que permita adaptarse al ambiente con tal de asegurar la recepción de los datos.
Eficiencia, una de las áreas de gran interés por parte del gobierno, industria y usuarios, es el uso eficiente del espectro. El espectro electromagnético es un recurso invaluable dentro de las comunicaciones inalámbricas, la cantidad de dinero que circula por concepto de asignación de uso del espectro es considerable. A partir de esta premisa es que surge el concepto de radio cognitiva y una de sus principales aplicaciones es precisamente utilizar zonas del espectro ya asignadas a usuarios nuevos sin incurrir en interferencias.
Económico, si bien es cierto en la actualidad el costo de un equipo que tengan las propiedades de RDS es considerablemente más elevado con respecto a uno que no las tenga, la tendencia es que esta diferencia se reduzca en los próximos años debido al gran auge que han tenido dentro de la industria y la academia. Desde otra perspectiva, el diseño y construcción de un equipo de telecomunicaciones requiere de un proceso de certificación de sus funcionalidades que claramente genera un costo; si por alguna razón el sistema inicialmente planteado necesita modificarse, probablemente tendrán que adquirirse nuevos equipos, de manera que necesitarán certificarse nuevamente. Si este proceso se repite varias veces llegará al punto en que la solución de ingeniería a lo largo del tiempo habrá sido más costosa que una que se pueda actualizar por software. Adicionalmente es importante revisar el impacto que tiene la fabricación de los equipos electrónicos en el medio ambiente, la obsolescencia programada es una problemática que nos afecta directamente a nosotros y a las futuras generaciones, entonces RDS como plataforma reutilizable y adaptable permite contrarrestar estos efectos.
5.2 REDES DE SENSORES INALÁMBRICOS
La significativa reducción de costos en los micro controladores, el incremento de la capacidad de procesamiento de la información, la reducción en el consumo de energía de los dispositivos electrónicos así como la aparición de tecnologías inalámbricas en bandas libres como ZigBee, Bluetooth o WiMAX ha generado que se integren las RSI en aplicaciones industriales y en general en la vida cotidiana de las personas. Tanto es así que al día de hoy se pueden encontrar redes de sensores en lugares muy diversos, por ejemplo, procesos de manufactura y de producción, sistemas de cultivo agrícolas, sistemas de transporte público, sistemas de vigilancia de personal en edificios, sistemas de control y automatización en hogares, oficinas e industrias, servicios de asistencia médica personal, sistemas de asistencia a crisis y a desastres naturales, entre otros[13, 14].
En general se puede afirmar que las RSI presentan un esquema que contiene varios nodos de sensado organizados de acuerdo a las necesidades y por lo menos un dispositivo central encargado de administrar la red (coordinador) que puede hacer las veces de Gateway para interconectar la red con otras redes o interfaces con distintos estándares. En la figura 3 se muestra un esquema general de una red de sensores, mientras que en la figura 4 se expone la
19
estructura general de un nodo de sensado. En la práctica los nodos de sensado utilizan solo algunos de los módulos mostrados debido a que son utilizados para aplicaciones específicas donde por ejemplo no es necesaria una interfaz de usuario, o los actuadores.
Nodo
Gateway
Figura 3. Esquema básico de una red de sensores.
Procesador
y
MemoriaInterfaz
Usuario
Comuni-
caciones
Sensado
Módulo 1
Módulo 2
Módulo 3
Actuadores
Módulo 1
Módulo 2
Módulo 3
ADC
PWM
I/O
DAC
Figura 4. Diagrama funcional de un nodo de sensado.
5.2.1 Entornos de Aplicación de las Redes de Sensores y sus Problemas
Las aplicaciones de las redes de sensores han tenido un aumento significativo en los últimos años, en áreas como la automatización de hogares, oficinas y sectores industriales, también han aparecido nuevos entornos de aplicación como en la asistencia médica y asistencia a desastres. A continuación se hace mención de algunos trabajos representativos de las áreas de aplicación más significativas de las RSI y se reconocen sus problemáticas [14-16].
5.2.1.1 Inmótica La automatización de espacios se presenta para diferentes fines como lo es el manejo eficiente de los recursos, la seguridad, el confort y el entretenimiento. Existe un gran número de empresas que desarrollan y/o comercializan productos enfocados a la inmótica como Control4 [17], con soluciones alámbricas e inalámbricas enfocadas a un mercado con altos ingresos económicos.
20
La inmótica permite brindar aspectos de seguridad mediante la utilización de cámaras, sensores de presencia, alarmas e identificadores que permiten alertar en caso de situaciones anómalas, los tags RFID han comenzado a utilizarse en oficinas y centros comerciales. También, se ofrece a la automatización como estrategia para el uso eficiente de la electricidad, controlando la conexión de los electrodomésticos y la luminosidad del ambiente dependiendo de las necesidades. Pero sin duda, el enfoque principal es el de confort, ofreciendo la posibilidad de controlar la temperatura, luminosidad, música y video al alcance de un teléfono inteligente o TV. En relación a las tecnologías inalámbricas utilizadas, ZigBee, WiFi, Bluetooth, RF son de mayor uso debido a características de consumo de potencia, compatibilidad, y facilidad de instalación [18].
Desde la perspectiva académica se han hecho implementaciones basadas en la construcción de un dispositivo tipo Gateway que administre la red y que sea capaz de manejar diferentes estándares en capa física a nivel de una red de área personal WPAN. La interoperabilidad de la red está en función de las interfaces de usuario que se deseen manejar, sin embargo hay una tendencia a la conexión de estas redes a Internet, así que 802.3 [19] y 802.11 [20], [21] son utilizados en conjunto con aplicativos en páginas WEB para proporcionar una administración remota. En [21] adicionalmente se utiliza la técnica de WSDL (Web Services Description Language) y SOAP (Simple Object Access Protocol) para hacer una conexión virtual entre los nodos y un servidor web en donde el servidor identifica a cada dispositivo con una dirección IP.
En otros casos, la interfaz de usuario se realiza con aplicaciones en dispositivos móviles o computadores por lo que el Gateway debe comunicarse mediante Bluetooth y GSM [22], en otras soluciones la interfaz de usuario se realiza mediante una LCD y un teclado o pantalla táctil conectada directamente al microcontrolador principal [23], en este caso particular, la red utiliza comunicación RF para habilitar o deshabilitar la conexión de electrodomésticos. Otros trabajos proponen estrategias nuevas como en [24], donde se muestra una arquitectura que permite integrar ZigBee dentro del framework OSGI (Open Service Gateway Initiative), en donde el sistema se basa en el mismo principio de funcionamiento de un servidor proxy, la solicitud de nuevos eventos como el desarrollo de ellos mismos son administrados por un dispositivo central que actualiza permanentemente la lista de servicios disponibles.
Cabe resaltar que todas estas propuestas utilizan alguna versión de ZigBee para las comunicaciones dentro red inalámbrica de sensores, y usan microcontroladores de 16 o 32 bits de fabricantes como PIC, Freescale y Texas Instruments [19]-[24].
Problemáticas
El principal inconveniente es la falta de estandarización que existe entre las soluciones comerciales, estos sistemas no son compatibles aun cuando la mayoría se basan en 802.15.4. Los servicios multimedia son comunicados generalmente por conexiones con cable debido a que las soluciones inalámbricas tienen inconvenientes en ancho de banda y fiabilidad para mejorar aspectos de calidad del servicio. Desde otro punto de vista, teniendo en cuenta que los sistemas de fibra óptica se extienden cada vez más, ya se habla de servicios de fibra hasta la casa (FTTH), son pocas las propuestas de integración de estas tecnologías que tengan en cuenta este hecho como se hace en [25].
21
Se puede decir que las propuestas académicas se basan en la utilización de ZigBee, debido a sus características de bajo consumo y facilidad de implementación, sin embargo, hace falta profundizar en los niveles de la calidad de servicio de estos esquemas y la integración con servicios de multimedia, teniendo en cuenta que las soluciones pretenden tener un enfoque comercial. Así mismo, en necesario realizar análisis de integración eficiente con sistemas que cada aparecen en un futuro cercano como UWB (Ultra Wide Band) y WBSN (Wireless Body Sensor Networks).
5.2.1.2 Agricultura En la agricultura las redes de sensores se muestran como una herramienta que permite mejorar los procesos de cuidado de los cultivos, mediante el monitoreo permanente las variables ambientales y la automatización de algunas tareas de forma remota. Términos como agricultura de precisión o inteligente se le han atribuido a este tipo de sistemas, quienes han permitido incrementar la productividad y la calidad de los cultivos. Algunas de las ventajas de estos sistemas incluyen entre otros servicios poder administrar de forma organizada, eficiente, automática y remota la distribución de agua y nutrientes necesarios a segmentos específicos del terreno; prevención y detección temprana de enfermedades y ahorro de recursos como agua, fertilizantes y personal. Algunos de los parámetros físicos que se monitorean son temperatura, humedad, presión, velocidad y dirección del viento, intensidad lumínica, nivel de agua, permitividad dieléctrica, conductividad, salinidad, acides, actividad fotosintética, y niveles de hidrógeno y dióxido de carbono, entre otros. Parámetros que se obtienen sobre el ambiente, el suelo y/o el cultivo [15]. Algunas implementaciones realizadas se presentan a continuación.
En [26], implementan una red de sensores para monitoreo de temperatura, humedad, intensidad de radiación y flujo fotosensible que cuentan con conexión GSM, para una plantación de café en Colombia, resaltan varios problemas de desvanecimiento de la señal que sugiere replantear topología y/o protocolo de comunicaciones. En sistemas de riego, como en [27] donde se desarrolla un sistema de riego automático dentro de una gran extensión de área en Murcia España en el cual se puede monitorear y controlar el flujo de agua que se suministra al terreno, se destaca un ahorro de agua entre el 30% y 60%.
También en sistemas de suministro de fertilizante como en [28], donde desarrollan un controlador de suministro variable de fertilizante en una plantación de soya en la región de Heilongjiang en China de manera que un computador instalado en un tractor utiliza un GPS para identificar el lugar en que se encuentra y suministrar la cantidad de fertilizante necesaria en esa zona, así mismo, en [29], desarrollan un sistema de soporte de decisión de suministro de fertilizante utilizando sensores que se conectan por WiFi y a su vez integran un servicio GPS para posicionamiento, los sensores se encargan de recolectar información de la tierra como la humedad, CO2, nivel de PH, temperatura, entre otros; el algoritmo está basado en la prueba “3414” que utiliza cuatro niveles de cantidad posible para suministrar, tres factores de determinación (Nitrógeno, Potasio y fosforo) y 14 posibles programas de fertilización [30].
Para el control de plagas donde a partir de la identificación de ciertos rasgos característicos de las plagas en cultivos y regiones particulares se puede realizar una atención temprana a los segmentos de la plantación afectada como se plantea en [31]. En los viñedos también hay oportunidad para las redes de sensores, en [32] implementan una red con 65 nodos la cual está
22
encargada de realizar mediciones de temperatura durante un periodo de seis meses, estos datos son sin duda de gran importancia dentro del registro de calidad que se hace durante la fabricación de vinos, y otras bebidas donde el control de la temperatura y humedad es de vital importancia; esta investigación estaba orientada a como la implementación de RSI llega a ser rentable y asegura un retorno de la inversión, y permitió descubrir una variación del 35% de la temperatura dentro del mismo viñedo, producto de la geografía del terreno. Este hecho es un inconveniente ya que la falta de homogeneidad en las condiciones ambientales produce variaciones en la calidad y perfil de las uvas cosechadas.
Así mismo, la utilización de las redes de sensores es frecuentemente utilizada en invernaderos donde las condiciones ambientales aparte de ser monitoreadas pueden ser controladas con mayor facilidad, por lo que las redes de sensores apoyan a los sistemas de control de temperatura, humedad e iluminación. Por ejemplo en [33], se crea una red de sensores que permite monitorear y controlar las variables de forma distribuida a través de internet en un invernadero en Portugal. En [34], desarrollan un sistema inteligente de administración de energía donde se monitorea la luz interna y externa del invernadero, la humedad relativa, la concentración de CO2, la temperatura interna y externa, además se implementan dos controladores difusos para lograr ajustar la temperatura interna a la deseada, con actuadores en las ventanas, luces artificiales, válvulas de agua y calentadores. El estado del arte en esta aplicación en general indica que este tipo de proyectos son desarrollados en distintas partes del mundo, siempre buscando las condiciones adecuadas para diferentes cultivos en particular.
Problemáticas
Se presenta la dificultad de no contar con soluciones generales en este campo. Cada aplicación en específico implica un desarrollo y esfuerzo particular dependiendo de los requerimientos y del caso de estudio. La eficiencia en el consumo de energía es uno de los mayores inconvenientes y de más relevancia para redes numerosas y de difícil acceso. Estrategias que permitan extender el ciclo de vida de los nodos son necesarias, se requiere mayor eficiencia en la utilización de los recursos. Generalmente se requieren abarcar grandes longitudes de tierra así que el diseño de dispositivos tipo Gateway debe considerarse con un enfoque diferente a las redes tipo WPAN. Se proyecta un aumento significativo en el número de nodos en este tipo de redes por lo que esquemas de enrutamiento y mantenimiento deben ser revisados con mayor detenimiento y eficiencia [15].
5.2.1.3 Automatización industrial Las redes de sensores que se implementan en los entornos industriales están enfocadas en primer lugar a apoyar los procesos de control y producción. En segundo lugar, a monitorear las condiciones generales del entorno de trabajo para alertar cualquier situación fuera de lo normal, ya sea de forma cíclica o por eventos. En tercer lugar, con fines de mantenimiento preventivo, monitoreando el estado de las máquinas para detectar cambios en el rendimiento. Finalmente permiten realizar seguimiento de los productos dentro de la cadena de producción, distribución e incluso ventas [35].
Actualmente, muchas de estas funciones se realizan con implementaciones cableadas debido a las limitaciones de las redes inalámbricas en cuanto a operación en tiempo real y a las interferencias electromagnéticas que se presentan en estos entornos ruidosos, producto de
23
motores, soldadoras y fundidoras. Además de esto, los equipos deben someterse a condiciones exigentes de temperatura, humedad y vibraciones, por lo que deben estar construidos con estándares industriales. Por otra parte, los esquemas de comunicación utilizados trabajan bajo esquemas TCP/IP con elementos como los PLC en sistemas SCADA. Aun así, se han desarrollado estándares inalámbricos como Wireless Hart e ISA100.11 que buscan ser más robustos. Adicionalmente, esquemas basados en ZigBee y 6LoWPAN llegan a ser de interés debido a su costo y conectividad.
En [36], se implementa una red de sensores en una planta de semiconductores para monitorear los efectos de las vibraciones en los motores y así anticipar fallos que pueden ser evitados mediante mantenimiento, ahorrando futuros costos. El sistema implementa plataformas comerciales como la Mica Mote y la Intel Mote, que se conectan al nodo central mediante WiFi. La red se prueba a 916MHz y 400MHz logrando valores de disponibilidad superiores al 90%. En [37], implementan una red basada en 802.15.4 dentro de un ambiente de una petrolera, se utiliza 802.11 para comunicar la red. El proyecto mide los retardos que están entre (80-250) ms. También hace mediciones de RSSI (Received Signal Strength Indicator) y de LQI (Link Quality Indicator) para evaluar la calidad del canal de comunicaciones. En [38], proponen la utilización de etiquetas pasivas basadas en UHF-RFID (Ultra High Frecuency - RFID) dentro de la industria del papel, para mejorar todo el proceso dentro de la cadena de producción almacenamiento y distribución. En este caso, el tag se diseña en el mismo carrete que contiene al papel con una antena omnidireccional tipo microstrip en un sustrato lo suficientemente delgado para doblarse dentro del carrete.
Problemáticas
El principal inconveniente es el entorno hostil en que se realizan este tipo de redes. Los esquemas de comunicaciones deben realizarse para que la transmisión de datos sea fiable, por lo que se sugieren implementar esquemas de redundancia y robustez. Sin embargo estas técnicas hacen que se aumenten los retardos de las señales de control, hecho que no es deseable en procesos críticos en tiempo real. Otro efecto negativo que aparece a partir de los retardos, es el denominado Jitter, fenómeno que indica variaciones en los retardos, causando serios problemas en la sincronización de eventos, y en una anticipación de los tiempos de retraso en las cadenas de producción [39]. Por esta razón las redes de sensores inalámbricas no se utilizan por el momento como elementos principales en el monitoreo de los procesos síncronos dentro del proceso de producción. Sino que se encargan de aspectos de monitoreo secundario de variables en el entorno de trabajo.
Por otra parte, aspectos de calidad de servicio y de seguridad de la información son de vital importancia dentro de este tipo de redes, en donde se debe asegurar un comportamiento adecuado del sistema con unas probabilidades de fallo mínimas. Esquemas de mantenimiento de la red que no generen discontinuidades en la producción deben ser tenidos en cuenta. Las arquitecturas de los nodos deben ser diseñadas e implementadas de manera eficiente para que logren satisfacer estos requerimientos teniendo presente que se tienen recursos limitados en energía, memoria y procesamiento [40].
Desde otro punto de vista, la implementación de la tecnología RFID dentro de toda la cadena de producción comienza a ser una solución interesante dentro del manejo de grandes inventarios, permitiendo desarrollar esquemas más eficientes en almacenamiento y distribución de los productos, representando ahorros en personal, tiempo y dinero.
24
5.2.1.4 Sistemas de asistencia médica En el campo de la asistencia médica las redes de sensores pretenden ofrecer soluciones que permitan mejorar los tiempos de respuesta en situaciones de emergencia que pudieran involucrar la vida de las personas. Así mismo, permiten tener una relación más cercana entre el paciente y el doctor aun cuando el paciente no se encuentre en un centro de asistencia. También son adecuadas en casos donde se necesite tener una vigilancia de pacientes con limitaciones físicas o cognitivas, o de poblaciones específicas como lo son los bebés y los adultos mayores. En el campo del deporte, se ha demostrado como el monitoreo de señales corporales permite realizar correcciones oportunas de los movimientos, haciendo que el deportista tenga un mayor desarrollo. Por otra parte, cada vez toma más importancia en el mercado los instrumentos médicos de medición, como termómetros o tensiómetros con conectividad inalámbrica a teléfonos y relojes inteligentes.
En [41], desarrollan cinco prototipos que brindan soluciones generales en salud. El primero es un sistema que detecta la posición del bebé al momento de dormir y alerta cuando el niño está en posición boca abajo para prevenir la muerte súbita del infante. El segundo es un sistema de monitoreo de temperatura que se encuentra inmerso en la manta con la que se cubre al niño. El siguiente es un sistema de monitoreo en tiempo real de signos vitales en una camisa, el desarrollo está enfocado hacia los bomberos debido a las complicaciones cardiacas que se suelen presentar por su actividad laborar, sin embargo, es también apto para otros ambientes y situaciones generales. También realizan un prototipo de un tensiómetro que registra y visualiza la presión arterial y el ritmo cardiaco en una interfaz gráfica en el computador. Finalmente, desarrollan un dispositivo capaz de reconocer algunos sonidos representativos de situaciones relevantes, como lo es el timbre de una puerta, el llanto de un bebe o la activación de alguna alarma para alertar mediante un mensaje a personas con discapacidad auditiva.
En [42], desarrollan un sistema que registra la distribución de presión de las pisadas al momento de caminar, de manera que se puede hacer un seguimiento más efectivo a los procesos de recuperación de movilidad en personas que han sufrido de discapacidades temporales. El sistema integra los sensores de presión en unas plantillas para los zapatos modificadas y los transmite de forma inalámbrica a un celular utilizando el protocolo ANT, que opera en la banda libre de 2.4 GHz. Posteriormente los datos pueden ser enviados por internet o por otras interfaces a computadores para revisar los datos monitoreados.
En [43], desarrollan un prototipo de monitoreo y registro las actividades de un grupo de personas de avanzada edad, que permite alertar en caso de emergencia a médicos, y encargados. El sistema busca integrar sensores corporales de temperatura, presión arterial, acelerómetros, entre otros, para identificar el estado de la persona. También utiliza sensores de temperatura, humedad y presencia dentro de la casa donde se desarrollan las actividades diarias para deducir la actividad que realizan. Por otra parte, el sistema integra dispositivos tipo Gateway que se encargan de reunir la información proveniente de los nodos, y reportarla por diferentes interfaces como por ejemplo WiFi, Ethernet, GSM.
Problemáticas
Este tipo de sistemas deben ser lo suficientemente robustos para mantener la comunicación en casos de emergencia. En el caso de los esquemas donde se integran las redes de sensores
25
corporales y las redes domóticas, deben revisarse los posibles efectos de interferencia que podría existir debido a la gran cantidad de elementos que se pudieran presentar en espacios como los hospitales. También, aparecen nuevos protocolos como ANT que están enfocados a este tipo de aplicaciones, motivo que sugiere que los desarrollos realizados bajo estándares de Bluetooth o ZigBee pueden no ser los más adecuados en términos de eficiencia energética y calidad del servicio. Por otra parte, se evidencia un interés general a la implementación de estas tecnologías, sin embargo, poco se habla con respecto a la reutilización y adaptación de los instrumentos médicos que ya se dispongan en los centros de asistencia.
5.2.1.5 Sistemas de monitoreo Las redes de sensores inalámbricas en general permiten el monitoreo de deferentes parámetros ambientales característicos de cada entorno para generalmente con fines de investigación y sistemas de alerta temprana. El uso de estos sistemas permite realizar implementaciones de monitoreo a un costo mucho más bajo que mediante instrumentos especializados. Característica que es una gran ventaja en poblaciones con bajos recursos. Estos esquemas se pueden encontrar generalmente en lugares de difícil acceso que poseen un interés particular en ser estudiados.
Por ejemplo, en Ecuador implementan una red de monitoreo de la actividad sísmica en la periferia de un volcán llamado El Reventador. Para ello se utilizaron por 3 semanas 16 nodos equipados con acelerómetros, los dispositivos fueron ubicados con separaciones de 200 a 400 metros entre sí, bajo un esquema de comunicación multi-hop [44]. En [45], se hace un registro del macro-clima de un árbol de secoya que mide cerca de 70 metros. Se utilizan nodos cada 2 m, lo cuales miden la temperatura, la humedad relativa y actividad fotosintética cada 5 minutos y con elle realizan un estudio del macro-clima a partir de un análisis multidimensional.
Por otra parte, se ha sugerido recientemente la utilización de sistemas de monitoreo en el mar para aplicaciones de registro de actividades sísmicas y monitoreo de los ecosistemas submarinos en general. En [46], se implementa una red de sensores subacuáticos para el monitoreo y estudio de arrecifes. Se usan 10 nodos estáticos que recolectan información de temperatura, presión además de imágenes en escala de grises en un tamaño de 255x143 pixeles. Los datos son obtenidos y almacenados cada 10 minutos por 5 días continuos, luego estos son recolectados por medio de unos vehículos subacuáticos autónomos que deben acercarse a una distancia menor de 8 metros para poder comunicarse de forma inalámbrica con cada uno de los nodos recolectando un cantidad cercana a 7 MB por nodo. Para la transferencia de la información se implementan y evalúan dos estrategias, en primer lugar una comunicación ultrasónica como es frecuente en este tipo de sistemas, que cuenta con una velocidad de 320 Kb/s, haciendo que la transferencia se demore cerca de 21 segundos, tiempo en que el consumo de potencia es muy elevado. En segundo lugar, se propone una comunicación a través de enlaces ópticos que es mucho más rápida y presenta ventajas no solo en consumo de potencia, sino que en costo, y en radio de cobertura de transmisión, alcanzando tasas de transmisión efectivas por encima del 96%, cifra que representa el doble de lo logrado en el sistema ultrasónico para la misma distancia.
Así mismo, se han propuesto sistemas de monitoreo y vigilancia del entorno marino como en [47], donde se analizan una arquitectura de sensado acuática que utiliza una comunicación por cable desde una boya en la superficie hasta diferentes tipos de sensores ubicados a diferentes
26
distancias bajo el agua. Los nodos en la superficie se conectan con los demás de forma inalámbrica por medio de ondas electromagnéticas en radio frecuencia como las demás redes de sensores. Estos sistemas presentan un nuevo campo de apoyo para la investigación y desarrollo de nuevas aplicaciones como se señala en [48], que indica entre otros inconvenientes los tiempos de latencia y las pérdidas de paquetes en la transmisión de los datos.
Por otra parte, con la aparición de Smart grids y los sistemas descentralizados de generación de energía eléctrica, aparece un campo nuevo en donde es importante tener una continua comunicación entre la central de energía y el usuario local para efectos de poder monitorear los niveles de consumo de energía eléctrica y la calidad de la misma en términos de consumo y generación de la misma, permitiendo detectar y alertar a los interesados fallos en los sistemas, o anormalidades que impliquen una revisión y mantenimiento de los equipos [49]. Se han propuesto algunos esquemas de red que tiene en cuenta las redes domóticas como base de integración de los sistemas de monitoreo de energía con los usuarios y que facilitarían interfaces de usuario ya implementadas [50].
Problemáticas
El uso de las redes de sensores trae consigo nuevas posibilidades para la investigación en escenarios donde antes no era posible llegar por los costos que esto implicaba. Nuevos escenarios aparecen en este plano, muchos de ellos de difícil acceso y con condiciones no muy favorables para la comunicación inalámbrica. Aun cuando las condiciones son particulares para cada ambiente, se encuentra que la mayoría de entornos son de difícil acceso, por esta razón, los sistemas deben ser lo suficientemente eficientes en cuanto a consumo de energía para que la inversión realizada se pueda justificar en un mediano o largo plazo. Nuevas interfaces de comunicaciones aparecen, no solo el espectro electromagnético, así que es importante considerar otros esquemas como el ultrasonido. La cobertura es uno de los aspectos más importantes que requieren estas aplicaciones, para esto, se deben explorar alternativas diferentes de la banda de 2.4 GHz, dependiendo de la cantidad de información que se desee transmitir.
En algunos casos, la transmisión en instantánea de los datos es una prioridad, en otro, puede que lo más relevante sea la tasa de transmisión, o la cobertura, todo depende del entorno, y la aplicación. Aun así, siempre es necesario realizar algún proceso de caracterización del canal de comunicaciones y verificar la funcionalidad del canal en términos de efectividad en paquetes recibidos.
5.2.2 Sistemas móviles de seguimiento
La reciente aparición de los vehículos autónomos ha traído una seria de problemáticas técnicas y normativas que están en proceso de solución. Es de gran importancia que estos sistemas estén permanentemente reportando su estado y posición para evitar accidentes. En este sentido, la comunicación con otros vehículos y con elementos estáticos de control como las señales de tránsito, es uno de los aspectos de mayor atención, sobre todo al momento de evitar accidentes que involucren vidas humanas. El escenario de estos sistemas de comunicaciones es más complejo que el de otros ambientes, los aspectos de movilidad a velocidades que pueden llegar a los 120 Km/h, así como la gran cantidad de nodos dentro de una misma área, no hace viable la implementación de estándares tradicionales como ZigBee u 802.11. Razón por la cual, han aparecido protocolos como CALM y DSRC, que permitan mitigar los problemas de
27
desvanecimiento por multi-trayectoria [51], y mejorar los esquemas de enrutamiento multi-hop y hop-by hop [52].
5.2.3 Perspectiva de las Redes de Sensores
Se encuentra un desarrollo y un avance muy dinámico en los últimos años. Las capacidades de memoria y procesamiento de los dispositivos han dado la posibilidad de integrar librerías y lenguajes de alto nivel, creando una curva de aprendizaje mucho más rápida para los usuarios no familiarizados con el desarrollo de aplicaciones en sistemas embebidos. Han aparecido herramientas como “TinyOs” y “mbed” enfocadas a la utilización de software de código abierto impulsadas por comunidades enteras, con la idea de la utilización de un mismo lenguaje para diferentes herramientas de hardware, desligando en cierta medida el software del hardware. Esta tendencia, aunque no permite un diseño eficiente de los sistemas en cuanto a la utilización de los recursos y por ende al consumo energético, trae consigo disminución en los tiempos de aprendizaje y desarrollo.
Como ya se ha detallado, las redes inalámbricas de sensores pueden abarcar campos de aplicación muy diversos, en donde cada caso en específico requiere de unas consideraciones particulares para que el diseño del sistema no solo cumpla con los requerimientos de la red, sino que lo haga de forma eficiente. En el caso de las comunicaciones entre estos dispositivos, se encuentra que las soluciones utilizadas, son en mayor medida sistemas comerciales que implementan estándares como ZigBee, Bluetooth u 802.11.g entre muchas otras posibilidades. Sin embargo, es importante señalar el nivel de flexibilidad de cada uno de ellos a la hora de configurar el diseño de la red, en términos de cobertura, tasa de transmisión, potencia de transmisión, esquemas de enrutamiento, frecuencia de operación, entre otras características que el diseñador debe elegir apropiadamente o que simplemente se ve obligado a escoger en el mercado. Algunas de las soluciones encontradas implementan equipos que integran procesamiento y comunicación, tales como Telos B mote, T mote sky, entre otros, cuyos precios varían entre 70 y 110 €, por nodo sin tener en cuenta los sensores ni el programador, en dado caso que se necesite [53].
Desde otra perspectiva, es importante decir, que el diseño de las redes de sensores debe corresponder con un enfoque de costo beneficio, que adicionalmente sea representativo económicamente a mediano y largo plazo. Muchos de los trabajos aquí mencionados no hacen referencia a los costos de diseño e implementación del proyecto y solo algunos enfocan las aplicaciones de tal manera que represente una oportunidad de negocio.
Los sistemas inalámbricos ofrecen ventajas comparativas con respectos a los sistemas alámbricas, como el costo y tiempo de implementación, además de ser más adecuados para aplicaciones de movilidad, o donde no se cuente con la infraestructura necesaria. Sin embargo, aparecen diferentes problemas como el desvanecimiento de la señal, la interferencia y el ruido en el canal, la sincronización entre la comunicación de los dispositivos, los retardos y el problema del efecto Jitter que en dados casos puede ser crítico. Por estas circunstancias, al día de hoy muchas de las tareas que hace algunos años se estimaba se pudieran realizar de forma inalámbrica, al día de hoy se siguen llevando a cabo por interfaces con cable.
Los esfuerzos de los productores de dispositivos electrónicos están encaminados a encontrar soluciones que permitan mejorar los sistemas de almacenamiento y consumo de energía para alargar la vida útil de los nodos. Muchos trabajos realizan esfuerzos por encontrar estrategias
28
de optimización en capa de red y capas superiores de los dispositivos, con el fin de reducir el consumo energético, sobretodo proyectando escenarios con mayor número de nodos y en algunos casos, con mayor flujo de información.
Así mismo, han aparecido nuevos estándares de comunicaciones como WirelessHart, que buscan disminuir los tiempos de retardo de la señal y aumentar la fiabilidad del sistema de comunicación. Igualmente, la aparición de estándares como 6LoWPAN refleja una tendencia a la convergencia entre las redes de sensores y la conectividad con Internet bajo el esquema de IPv6, acorde con el paradigma denominado “Internet of the Things”. Otro aspecto que se puede denominar como tendencia, es el concepto de redes heterogéneas. Como ya se ha mencionado, la mayor parte de aplicaciones se basan en una red de sensores que recolecta y administra algún tipo de información para luego ser enviada hasta el usuario mediante una interfaz diferente, ya sea vía WEB o mediante dispositivos inteligentes por Bluetooth, entre otros.
Aparecen aplicaciones nuevas que requieren unas características específicas, como un mayor ancho de banda para transmisión de multimedia. Hasta el momento este sector se ha atendido desde las soluciones que ofrece WiFi, aunque también otros estándares como USB inalámbrico y UWB atacan este campo. Actualmente han surgido esquemas novedosos en el mercado como lo es ANT para redes de sensores corporales, CALM y DSRC para comunicaciones entre vehículos autónomos, Wireless Hart e ISA100.11 para sistemas industriales, RFID-UHF en esquemas de procesos de producción e identificación de productos. Cada uno de ellos requiere de la utilización de un hardware específico, que en el plano de las redes convergentes, conlleva a la utilización de dispositivos tipo Gateway que permitan relacionar diferentes interfaces de comunicación.
5.3 OPORTUNIDADES DE INTEGRACIÓN
La radio definida por software es un concepto de gran atractivo para la comunidad académica debido a la diversidad de aplicaciones que se pueden desarrollar en diferentes campos. Es también una tecnología que involucra conceptos en el área de telecomunicaciones, comunicaciones digitales, programación, procesamiento digital de señales, telemática y uso de herramientas de software libres. Por tal motivo, trabajar con estos sistemas brinda la posibilidad de reforzar muchas de las temáticas que se imparten en las aulas universitarias. Su utilización dentro de la academia, es sin duda, una oportunidad para estudiantes y profesores de llevar a la práctica los conceptos teóricos vistos en clase.
Los costos en las tarjetas de desarrollo que permiten implementar las funcionalidades de RDS han disminuido considerablemente en los últimos años, haciendo asequible su utilización en más centros de enseñanza y por parte de aficionados. Dispositivos como RTL-SDR (20 dólares) tienen un interesante nicho de mercado y su capacidad de integración con dispositivos como Raspberry pi, por ejemplo, hace prever un incremento en los proyectos y aplicaciones en diferentes áreas.
De acuerdo con la revisión del estado del arte de las redes de sensores realizada, se encuentra que cada aplicación desarrollada implica la solución de unos requerimientos particulares, y que en muchos casos, no se atienden de forma eficiente en software y hardware. Aun cuando han aparecido diferentes estándares enfocados a alguna problemática en particular, estos esquemas no son lo suficientemente flexibles para logar un diseño eficiente en todas las
29
aplicaciones. Por tal motivo, una plataforma que pueda reconfigurarse en términos de capa física, de enlace, de red y capas superiores, permitiría adecuarse a cada aplicación de forma adecuada, mediante el mismo hardware. Los esquemas de modulación, codificación, encriptación, enrutamiento, corrección de errores, técnicas de acceso al medio, calidad de servicio, entre otros, podrán ser evaluados, encontrando una mejor solución de acuerdo a los requerimientos de la red.
Para que estos sistemas tengan una oportunidad en el ámbito comercial, además de reducir sus costos como se ha venido presentando, estos sistemas deberán integrar conceptos como “Programación en el Aire”, que permita realizar actualizaciones de software en los dispositivos, de acuerdo al desempeño que se desee en la red. Estos dispositivos tendrán que ser compatibles con el amplio mercado de sensores ya existentes, diseñados para tarjetas como Arduino o las tarjetas de desarrollo de Texas Instruments. También es importante tener una facilidad en cuanto a las herramientas de programación que se dispongan, por lo que deberán implementarse sistemas de software libre en entornos operativos como Windows de manera que su utilización no se limite a usuarios LINUX. En este sentido, la estrategia de generar compiladores libres en la WEB utilizada por “mbed” permitiría aumentar la cantidad de usuarios que trabajen sobre estas plataformas.
Algunos trabajos sugieren tácitamente la utilización de la radio definida por software en aplicaciones de las redes heterogéneas optimizadas, como en la asistencia médica, redes corporales, redes de distribución energéticas y sistemas de comunicaciones para atención de emergencias. Esto de acuerdo a las características de adaptabilidad, convergencia e interoperabilidad, robustez y escalabilidad que ofrece la RDS.
Sin embargo, quedan algunos desafíos técnicos y normativos, que deberán atenderse en el futuro próximo. Por ejemplo, la utilización de frecuencias licenciadas a partir del acceso dinámico de usuarios no licenciados, así como, el incremento de las capacidades de procesamiento y la cantidad de bloques lógicos que se dispongan en los sistemas empotrados.
5.4 TRABAJOS RELACIONADOS
La integración de las redes de sensores y la radio definida por software es una idea que se ha planteado previamente por diferentes investigadores. Muchos de los trabajos relacionados fueron realizados en el software libre GNU Radio y en algunas de las versiones de las tarjetas de desarrollo de Ettus Research. Es importante señalar el trabajo realizado por Thomas Schmid de la UCLA quien implementó la capa física del estándar 802.15.4 en una tarjeta USRP1 con GNURadio [54]. El objetivo de dicho trabajo era comunicar una estación central configurada en GNURadio v3.6 con dispositivos Telos B mote. Estos dispositivos se comunican mediante el transceptor de Texas Instruments CC2420 e implementan capa física y capa de enlace. Este primer desarrollo sirvió como referencia para muchos trabajos posteriores, que buscaban mejorar los resultados obtenidos o extender el desarrollo a otros esquemas de comunicaciones.
En la Universidad de Innsbruck, Austria, se han actualizado las librerías del esquema 802.15.4 para la versión de GNURadio 3.7, también han mejorado el aspecto gráfico en la programación, de manera que tienen bloques funcionales para las capas físicas O-QPSK PHY y CSS PHY y para la capa de enlace 802.15.4. Cada bloque implementa las funcionalidades de transmisión y recepción, y la información se puede almacenar en formato PCAP para poder analizarse desde
30
la aplicación Wireshark [55]. [55]. Este trabajo, al igual que el de Tomas Schmit, es realizado con los dispositivos Telos B mote, los cuales fueron programados a partir del sistema operativo Contiki que es compatible con los microcontroladores MSP430 de los dispositivos. Es importante resaltar que uno de los autores B. Bloessl, es el encargado de administrar la librería gr-ieee802_15_4 para GNU Radio, y es un usuario muy activo en los foros de soporte. A partir de estos trabajos, han aparecido múltiples desarrollos en diferentes lugares del mundo. Uno de los desarrollos más relevantes se encuentra en el Instituto de tecnologías de comunicación de Ulm en Alemania [56], para este se utiliza el software OpenBTS que permite disponer de una BTS (Base Transceiver Station) de telefonía celular operando en la tarjeta de desarrollo USRP1 y USRP2 en las bandas GSM de 800/900 MHz y 1800/1900 MHz. Con el objeto de utilizar una sola antena y de disponer de una conexión con un analizador de espectro externo que permita monitorear la frecuencia de la señal de salida del dispositivo USRP, se diseña un circulador en RF que se integra con la tarjeta de desarrollo. En el Royal Institute of Technology en Suecia [57], se implementa una red de sensores heterogénea que integra nodos de T-mote con el transceptor CC2420 operando a una frecuencia de 2,4 GHz y los nodos MSB430 que disponen del transceptor CC1020, estos funcionan a frecuencias de 450 MHz y 900 MHz. Estos dispositivos utilizan Contiki como Sistema Operativo (SO) de los nodos. Por otra parte, en la universidad de Aalborg en Dinamarca [58], se implementa una comunicación entre dos nodos con transceptor CC2500 en donde el dispositivo USRP funciona como un repetidor, este trabajo fue realizado en Matlab.
En el Instituto Politécnico de Virginia, en Estados Unidos [59], se realiza una comparación entre la implementación de la capa física de 802.15.4 en la FPGA Spartan3-A de la USRPN210 y un receptor multicanal 802.15.4 en una FPGA externa Virtex 5. Para este trabajo, se utilizaron herramientas como GNU Radio, Matlab, y Xilinx ISE, de manera que fue posible comprobar la cantidad de recursos que se utilizaban en la FPGA al programar la tarjeta con Xlinx ISE y con GNURadio, siendo mucho más eficiente la primera de estas.
En proponen una nueva arquitectura para los nodos, integrando hardware que hace posible la implementación de RDS. En este se utilizan las tarjetas de desarrollo USRP1 como concentrador de una red de sensores que trabaja en 802.15.4.
31
6. ANÁLISIS TÉCNICO DEL PROTOCOLO ZIGBEE
Las comunicaciones inalámbricas han evolucionado de forma dinámica y creciente en los últimos años. Su desarrollo y fortalecimiento ha estado ligado al trabajo de cientos de empresas que se han organizado para trabajar en estándares unificados que permitan la masificación de este tipo de tecnologías, mediante la construcción de equipos compatibles.
Los grupos de trabajo IEEE están organizados de acuerdo a características de cobertura, ancho de banda y funcionalidades específicas de las redes de comunicaciones, haciendo un recorrido desde las Redes de área personal (WPAN), pasando por las redes locales (WLAN) y las de área ancha (WWAN) hasta las regionales (WRAN), como se muestra en la Figura 5.
Para el caso de las redes de sensores, los grupos de trabajo más relevantes son 802.11 y 802.15, donde el trabajo está principalmente orientado a las redes de área personales incluyendo las redes de área corporal (WBAN). En este trabajo se implementan redes de área personal con una baja tasa de datos como es el caso de ZigBee.
WPAN < 10m
WLAN < 150m
WWAN < 50Km
WRAN < 100Km
802.11 (a, b, g, n, ac, ad, af) à WiFi
802.16 à WiMAXCDMA / GSM / EDGE / 3G /HSPA / LTE
802.22 àTVWSDVB-T, T2
802.15 .1 Bluetooth .3 High Bw à UWB, USB inalám .4 Low Bw à ( ZigBee, WirelessHART, 6LoWPAN, ISA100, MiWii (PIC)) .5 Mesh à ZigBee Pro .6 WBANRFID à Pasivo, Activo (LF-HF-UHF)
Figura 5. Esquema organizacional de las redes inalámbricas según su cobertura.
ZigBee es un estándar de comunicaciones inalámbricas diseñado por la alianza ZigBee, conformada por varias industrias, en su mayoría fabricantes de semiconductores. Esta alianza trabaja en conjunto con IEEE para asegurar una integración completa y operativa del protocolo de comunicación con un funcionamiento vía radio y bidireccional. Debido a que el software de red está muy estructurado para establecer una red de comunicación ya sea inalámbrica o cableada, se recurre al concepto de capas de red para reducir la complejidad de diseño. El nombre, número de capas, contenido y función difieren de una red a otra.
El protocolo de capas ZigBee está basado en el modelo de referencia de interconexión de sistemas abiertos (OSI). El modelo OSI cuenta con siete capas, sin embargo el estándar ZigBee implementa solamente cuatro de ellas, capa física, capa de enlace, capa de red y capa de aplicación, puesto que son las capas esenciales para obtener una red inalámbrica con consumo de baja potencia y baja transferencia de datos.
32
Cada capa se comunica con la capa adyacente mediante el punto de acceso de servicio (SAP), cada SAP cuenta con un número de primitivas de servicio para lograr la funcionalidad requerida. [61]
Figura 7. Tramas de las capas del protocolo ZigBee
La alianza ZigBee cuenta oficialmente con tres diferentes estándares de especificaciones, que son bajo las que operan la mayoría de dispositivos existentes. La primera versión de especificaciones que se implementó es conocida como ZigBee-2003, estas especificaciones se
Figura 6. Diagrama de capas del protocolo ZigBee [59]
33
basan en el estándar IEEE 802.15.4, esta es la versión más simple y quedan pocos dispositivos que funcionen bajo dicho estándar. El segundo estándar se conoce como ZigBee-2006. El último estándar publicado por alianza ZigBee es estándar ZigBee-PRO.
En esta implementación se dispone de unos dispositivos de Digi International, con referencia Xbee S2, que se muestran en la figura 8. En la parte posterior del dispositivo se encuentra información como la fecha de expedición, la dirección IEEE de 64bits que es generada por fábrica y la referencia del dispositivo. Como se muestra en la figura 9, la referencia de estos dispositivos es XB24-Z7CIT-004, con esta referencia se obtiene el tipo de radio con el que trabaja este dispositivo. Para este caso la referencia del radio es EM250. Este radio es elaborado por la industria Silicon Lab, que hace parte de la alianza ZigBee. Por lo tanto implementa el estándar IEEE 802.15.4 para capa física y de enlace, mientras para capa de red y de aplicación este dispositivo implementa las especificaciones ZigBee-2006.
Figura 8. Dispositivos Xbee S2 que se implementan en este trabajo
Figura 9. Información propia de cada dispositivo
6.1 CONFIGURACIÓN DE LOS MÓDULOS XBEE
La capa superior es la capa de aplicación, que es propia de cada fabricante, sin embargo para lograr una comunicación con dispositivos de otras fábricas, debe cumplir ciertos comandos.
En la hoja de especificaciones que emite Digi International para los dispositivos Xbee serie 2, se especifica la trama API, como se muestra en las figura 10. Estas tramas se pueden generar mediante un microcontrolador externo o algún programa desarrollado para este objetivo.
34
Figura 10. Trama API para Xbee S2
Para las pruebas de transmisión y recepción entre los dispositivos Xbee S2 se utiliza el software Xctu, se genera un mensaje “1234”; la trama recibida se muestra a continuación,
Receive Packet (API 1)
7E 00 11 90 00 13 A2 00 40 54 EF 4A 00 00 02 32 30 2C 34 10 19
Bandera de inicio: 7E Longitud de la trama: 00 11 (17) Tipo de trama: 90 (paquete de recepción) Dirección fuente de 64 bits: 00 13 A2 00 40 54 EF 4A Dirección fuente de 16 bit: 00 00 Opciones de recepción: 02 Datos: 31 32 33 34 35 Suma de comprobación: 19 Normalmente se tiende a confundir esta trama con la trama de aplicación. Sin embargo, al realizar algunas pruebas se comprobó que esta no es la trama de aplicación que el dispositivo encapsula y envía de manera inalámbrica. Estos datos están diseñados por el fabricante para realizar una comunicación entre el microcontrolador interno y el transceptor, para este caso el EM250 que componen el dispositivo.
Para este trabajo, se realizaron varias pruebas comunicando la tarjeta USRP con los módulos Xbee hasta lograr exitosamente la comunicación de forma bidireccional. A continuación se presenta y se explica cada campo que compone la trama en cada una de las capas. Todos los campos y posibles valores que puedan tomar las tramas están definidas en las especificaciones ZigBee para capa de red y aplicación, y por el estándar IEEE 802.15.4 para capa física y de enlace. En este manuscrito se detallan únicamente los valores y comandos de las tramas requeridos para el desarrollo e implementación del proyecto.
35
6.2 CAPA DE APLICACIÓN
En la tabla 1 se presenta la trama de aplicación que envía el módulo Xbee S2 de manera inalámbrica. En la primera fila se especifica la cantidad de bytes que ocupa cada campo para enviar una trama de datos.
Bytes 1 1 2 2 1 1 variable
Frame control field Dest. Endpoint Cluster ID Profile ID Src. Endpoint Counter Payload
40 E8 0011 C105 E8 01 48 6F 6C 61
61 61 61
Tabla 1. Trama de aplicación.
Frame control: en la tabla 2 se detalla la integración del campo de control para la capa de aplicación, que tiene una longitud total de un Byte. La primera fila indica la posición de los bits que ocupa cada campo.
Bits 0,1 2,3 4 5 6 7
Frame type Delivery mode Ack Format Security Ack. request Reserved
00 00 0 0 1 0
Tabla 2. Sub trama de control para la capa de aplicación.
Frame type: en este campo se indica el tipo de trama que se está enviando. En la tabla 3 se indican los posibles tipos de trama y su respectivo valor.
Tipo de trama Valor en binario
Datos 00
Comando 01
Reconocimiento 10
reservado 11 Tabla 3. Tipos de trama para la trama de aplicación.
Delivery mode: indica el modo de entrega del mensaje, las opciones de transmisión se indican en la tabla 4.
Modo de entrega Valor en binario
Entrega unicast normal 00
Reservado 01
Broadcast 10
Grupo de direccionamiento 11
Tabla 4. Modos de entrega.
Ack Format: este bit indica si los campos destination endpoint, cluster identifier, profile identifier y source endpoint deben estar presentes en el reconocimiento de esta trama, así que si el bit es igual a 0, se trata de una trama de datos, si el valor es 1, es una trama de comando.
36
Security: para este trabajo no se activa ningún comando de seguridad así que el valor es 0.
Acknowledge Request: el requerimiento de reconocimiento le indica al dispositivo receptor si requiere o no enviar una trama de reconocimiento cuando reciba la trama, el valor 1 determina que este debe hacerlo.
Dest Endpoint: para este caso el valor del nodo final del destinatario es 0xE8, que es el mismo valor para el campo Src Endpoint.
Cluster ID: el valor del identificador del clúster que es tomado por el dispositivo receptor para el proceso de filtrado y la interpretación del mensaje.
Profile ID: Específica el perfil del ZigBee para el que se destina la trama, en este caso el valor es 0xC105.
Counter: es un contador añadido a cada trama de aplicación, que se incrementa cada vez que se transmite una trama. Esto evita la recepción de tramas duplicadas.
Payload: en este campo está el mensaje a enviar en valores hexadecimales, en este caso el mensaje enviado es “Holaaaa”. La trama completa de aplicación obtenida es 40 E8 11 00 05 C1 E8 01 48 6F 6C 61 61 61 61
6.3 CAPA DE RED
Las tramas de aplicación obtenidas, pasan a disposición de la capa de red, donde se encapsula la información proveniente de la capa de aplicación y toda la información necesaria para la comunicación en la red, esto es conocido como trama de red como se muestra en la tabla 5.
Bytes 2 2 2 1 1 8 8 variable
Frame control
Dest Add
Src Add
Radio sequen number
Des IEEE add Src IEEE add APDU
1848 0000 ECD0 1E 71 0013A200407C47D9 0013A2004093AF9F 40 E8 11 0…
Tabla 5. Trama de red.
Cada uno de los campos que componen esta trama se explica a continuación.
Frame control: el campo de control de trama está conformada por la sub-trama que se indica en la tabla 6.
Bits 0,1 2,3,4,5 6,7 8 9 10 11 12 13,14,15
Fram Type Version DR MF Sec SR DIEEE SIEEE Reservado
00 0100 00 0 0 0 1 1 000 Tabla 6. Sub-trama del campo de control para la trama de red.
Frame Type: en este campo se debe especificar qué tipo de trama es la que se envía, en la tabla 7 se indica el tipo de trama y su respectivo valor.
37
Tipo de trama Valor en binario
Datos 00
Comando 01 Tabla 7. Tipo de trama para la capa de red.
Protocol version: este campo determina la versión del protocolo que está utilizando el dispositivo. En la tabla 8 se ilustra las posibles versiones y el valor que tomaría este campo.
Versión del protocolo Valor en binario
ZigBee-2003 01
ZigBee-2006/ PRO 10
ZigBee green power 11 Tabla 8. Versiones del protocolo ZigBee
Discover Route (DR): este campo controla las operaciones del descubrimiento de ruta para el tránsito de esta trama. Los posibles valores que puede tomar este campo se describen en la tabla 9. Para esta prueba el valor de este comando es 00, debido a que la red implementa una topología uno a uno.
Descubrimiento de ruta Valor en binario
Suprimir el descubrimiento de ruta 00
Habilitación del descubrimiento de ruta 01
Reservado 10, 11
Tabla 9. Valores para la habilitación o inhabilitación del descubrimiento de ruta
Multicast flag (MF): la bandera multicast puede tomar dos valores. Si el valor de este campo es 0, indica que esta trama puede ser unicast, como es el caso específico de esta trama, o broadcast. Si el valor es 1, indica que la transmisión es multicast, esto activa algunos campos que no serán tratados en este trabajo debido al tipo que no se relacionan con la implementación.
Security (sec): este campo no se habilita debido a que no se trabaja implementación alguna sobre seguridad, por lo tanto el valor que toma es 0.
Source route: el valor de este campo es 1, únicamente cuando la sub-trama de ruta de origen está presente en el encabezado de red, para este caso el valor es 0.
Destination IEEE Address: este campo determina si se activa el campo de la dirección IEEE de 64 bits del dispositivo o no, eso depende del tipo de trama. Para este caso, es necesario poner dicha dirección, por tanto el valor de este campo es 1.
Source IEEE Address: en este campo se especifica con un valor igual a uno, si en la trama se requiere indicar la dirección fuente IEEE, como en este ejemplo. Si se tratara de una transmisión broadcast, el valor que toma este campo es cero.
El campo de control controla el tipo de la trama por ende los campos de la misma. Para este caso se utilizaron los siguientes campos.
38
Destination Address: el campo dirección de destino contiene la dirección de 16 bits del dispositivo receptor. Para esta aplicación, la dirección de destino es 0x0000, pues la trama se está enviando desde un nodo final a un coordinador. En el caso de una transmisión broadcast, el valor de esta dirección es 0xFFFF.
Source Address: En este campo especifica la dirección de 16 bits del dispositivo transmisor, esta varía según la configuración del dispositivo, asi por ejemplo si el dispositivo que transmite fue configurado previamente como coordinador, el valor de este campo es 0x0000. Para este caso específico, el valor del campo es 0xECD0, pues se está transmitiendo la trama desde el nodo final y esta fue la dirección asignada.
Radio: Este campo determina el número límite de radios entre los que puede transmitirse la trama. Cada vez que un dispositivo recibe la trama, debe decrementar este valor en uno.
Sequence Number: el valor del número de secuencia debe aumentar cada vez que se transmite una nueva trama.
Destination IEEE Address: en el campo de direccionamiento de destino IEEE se declara la dirección de 64 bits. Este campo no debe estar presente cuando se trata de una transmisión broadcast o multicast.
Source IEEE Address: en este campo se muestra en la dirección fuente IEEE de 64 bits. Al igual que en el dirección IEEE de destino, esta dirección debe ser coherente con lo que se especifique en la dirección de 16 bits.
APDU: el campo de unidad de datos del protocolo de aplicación (APDU), de su sigla en inglés, contiene el encapsulamiento de la trama de aplicación, para este ejemplo el contenido de dicho campo es: 40 E8 11 00 05 C1 E8 01 48 6F 6C 61 61 61 61.
Así, la trama final que se obtiene desde la capa de red es: 48 18 00 00 D0 EC 1E 71 D9 47 7C 40 00 A2 13 00 9F AF 93 40 00 A2 13 00 40 E8 11 00 05 C1 E8 01 48 6F 6C 61 61 61 61
Para la implementación de la capa de red desde el concentrador, en este trabajo para las tramas a transmitir, los campos de dirección fuente de 16 bits y la dirección fuente IEEE de 64 bits son determinados por el usuario.
6.4 CAPA DE ENLACE
La trama de datos es enviada a la capa de enlace desde la capa de red, estos datos se empaquetan dentro de la trama MAC, como se muestra en la tabla 10.
Bytes 2 1 2 2 2 Variable 2
Frame control
Sequence number
Destination PAN ID
Destination address
Source address
NPDU FCS
8861 CF 8B41 0000 ECD0 48 18 00 00 D0 EC… 00 EB
Tabla 10. Trama MAC
39
Frame control: La trama de control está compuesta por diferentes campos que se especifican en la tabla 11.
Bits 0,1,2 3 4 5 6 7,8,9 10,11 12,13 14,15
Frame Type Sec FP Ack Req PAN ID comp Reser DAM Frame version SAM
100 0 0 1 1 000 01 00 01
Tabla 11. Sub-trama de control de la trama MAC
Frame type: en el estándar IEEE 802.15.4 define cuatro diferentes tipos de trama que puede enviar y procesar los dispositivos ZigBee, como se muestra en la tabla 12. En este campo se define cuál de estas tramas será enviada.
Tipo de trama Valor en binario
Beacon 000
Datos 001
Reconocimiento 010
Comando MAC 011
Reservado 100-111
Tabla 12. Tipos de trama para la trama MAC
Security: Este campo define si se habilitan o no los comandos de seguridad. Para este ejemplo no se hace, por consiguiente el valor es cero.
Frame Pending: este campo precisa si el dispositivo que envía la trama tiene más datos para enviar al destinatario.
Acknowledge Request: el requerimiento de reconocimiento le indica al dispositivo receptor si requiere o no enviar una trama de reconocimiento cuando reciba la trama, el valor 1 determina que este debe hacerlo.
PAN ID Compression: este campo especifica si la trama MAC a enviar contiene solo uno de los campos de identificación PAN cuando ambas direcciones, origen y destino están presentes, la trama debe contener el PAN ID destino, el PAN ID fuente se asume igual al de destino.
Destination Addressing Mode: están definidos cuatro modos de direccionamiento para estos dispositivos, que se indican en la tabla 13.
Modo de direccionamiento Valor en binario
PAN Id y dirección no están presentes 00
Reservado 01
Dirección corta de 16 bits 10
Dirección extendida de 64 bits 11
Tabla 13. Modos de direccionamiento destino y fuente
40
Frame Version: este campo especifica el número de la versión correspondiente a la trama. Si el valor de este campo es 0x00, indica que la trama es compatible con IEEE 802.15.4-2003, el valor 0x01 indica que es una trama IEEE 802.15.4; el resto de valores están reservados.
Source Addressing Mode: los modos de direccionamiento que puede tomar este campo, se indican en la tabla 13.
Sequence Number: Especifica el identificador de secuencia para la trama.
Destination PAN Identifier: este campo se incluye solo si el modo dirección de destino de la trama de control es diferente de cero, en este se especifica el PAN ID de destino.
Destination Address: este campo puede tener una longitud de 2 o de 8 bytes, en este se especifica la dirección del receptor, esta dirección debe ser coherente con el valor especificado en el campo de modo de direccionamiento de destino en la trama de control.
Source Address: este campo puede tener una longitud de 2 o de 8 bytes, en este se especifica la dirección del dispositivo fuente, esta dirección debe ser coherente con el valor especificado en el campo de modo de direccionamiento fuente en la trama de control.
NPDU: la unidad de datos del protocolo de red (NPDU), de su sigla en inglés, es el campo donde se encuentra encapsulada la trama que le entrega la capa de red a la capa MAC. A continuación se muestra la trama NPDU del ejemplo que se ha venido trabajando.
48 18 00 00 D0 EC 1E 6F D9 47 7C 40 00 A2 13 00 9F AF 93 40 00 A2 13 00 40 E8 11 00 05 C1 E8 00 48 6F 6C 61 61 61 61
FCS: El chequeo de secuencia de la trama (FCS) es el campo donde se encuentra el resultado del código de redundancia cíclica que se realiza sobre el encabezado y la carga útil de la capa MAC. Para este caso el valor de este caso es 00EB.
6.5 CAPA FÍSICA
6.5.1 Trama de la Capa Física
La capa física almacena los datos que le permiten al receptor sincronizar la trama, por consiguiente, esos valores no se ven en la trama recibida, pero deben ser puestos en la trama de envío como se muestra en la tabla 14, de lo contrario los dispositivos no podrán comunicarse.
Bytes 4 1 1 Variable
Preamble SFD Frame length MPDU
00 00 00 00 A7 32 48 18 00 00 D0 EC 1E 6F D9 4… Tabla 14. Trama de capa Física
Preamble: El campo del preámbulo es usado por el radio receptor para identificar el inicio del paquete. La longitud de este campo depende de la frecuencia y el tipo de modulación que se utilicen. Para este trabajo, los dispositivos que se implementan, trabajan en la banda de 2.4 GHz, con una modulación O-QPSK; esto implica que el campo del preámbulo tiene una longitud de 4 Bytes.
41
SFD: el delimitador de inicio de la trama (SFD), indica el final del encabezado de sincronización y el inicio de la trama de datos. El estándar IEEE 802.15.4 determina que el valor de este campo es 0xA7, excepto para los dispositivos que manejan modulación ASK.
Frame length: en este campo se indica el número de Bytes que constituyen la trama. La tabla 15 resume el tipo de carga útil y su respectivo valor de la longitud de trama.
Carga útil Valor de la longitud de trama
Reservado 0-4
MPDU (reconocimiento) 5
Reservado 6-8
MPDU 9 en adelante
Tabla 15. Comandos del campo de longitud de trama
MPDU: la unidad de datos del protocolo de la capa MAC (MPDU), comprende la trama de datos que envía la capa MAC a la capa física, que para este ejemplo es:
61 88 C9 41 8B 00 00 D0 EC 48 18 00 00 D0 EC 1E 6F D9 47 7C 40 00 A2 13 00 9F AF 93 40 00 A2 13 00 40 E8 11 00 05 C1 E8 00 48 6F 6C 61 61 61 61 00 EB.
La trama completa que debe ser enviada se conoce con el nombre de unidad de datos del protocolo de la capa física (PPDU). A continuación se enseña la trama completa que se obtiene en del ejemplo.
00 00 00 00 A7 32 61 88 C9 41 8B 00 00 D0 EC 48 18 00 00 D0 EC 1E 6F D9 47 7C 40 00 A2 13 00 9F AF 93 40 00 A2 13 00 40 E8 11 00 05 C1 E8 00 48 6F 6C 61 61 61 61 00 EB.
6.5.2 Codificación y Modulación
El formato PPDU pasa al proceso de codificación mediante las funciones de modulación y propagación, como se muestra en la figura 11. En esta parte del proceso, los bits individuales son agrupados para formar símbolos, con estos se forman chips que son modulados, amplificados y transmitidos. El estándar IEEE 802.15.4 especifica que la tasa de datos de los bits del PPDU debe ser de 250 Kb/s si el dispositivo trabaja en la banda de frecuencia de 2.4 GHz.
Figura 11. Diagrama de modulación y propagación.
Para formar un símbolo se agrupan cada 4 bits del PPDU, enviando primero el bit menos significativo. Cada símbolo es representado por un código pseudo-ortogonal de 32 bits
0000
Bit a Símbolo
Símbolo aChip
Forma de pulso sinusoidal de media onda
PPDU Q
IModulador
O-QPSK
250 Kbps 62,5 KSps 2 Mchip/s 1 MSps
1 MSps
0 1100...11' (1+j),(-1-j) (1+j)'
42
denominado chip, como estrategia para disminuir la perdida de paquetes que se produce por diferentes factores como el ruido y la interferencia inter símbolo, esta es la manera de implementar una codificación de tipo DSSS (espectro ensanchado de secuencia directa). En la figura 12 se muestra cada uno de los 16 símbolos con su respectivo chip.
En el bloque del modulador, los bits de cada chip son modulados en fase y cuadratura, de manera que los bits pares (𝐶0, 𝐶2, 𝐶4 … 𝐶30) se modulan en fase y bits impares (𝐶1, 𝐶3, 𝐶5 … 𝐶31) se modulan en cuadratura con un ángulo de desfase de 90 grados. Este desfase se produce mediante el retardo de la señal por un periodo de 0,5 us.
Para la etapa de modulación, el estándar IEEE 802.15.4 establece el uso de la modulación por desplazamiento de fase en cuadratura escalonada (OQPSK) si se opera a una frecuencia de 2.4 GHz. En la modulación OQPSK la señal en cuadratura Q(t) está desfasada π/2 con respecto la señal en fase I(t).
Esto reduce a gran escala la amplitud modulada en la señal OQPSK, debido a que ocurre una máxima transición de fase de 90 grados para la señal, a diferencia de los 180 grados que se requieren para la modulación QPSK, pues los datos de I y Q no pueden cambiar simultáneamente debido al corrimiento que presentan. Las señales I(t) y Q(t) son procesadas para formar el pulso de media onda sinusoidal. Así el valor ‘1’ tomará media forma de onda sinusoidal positiva, mientras el ‘0’ tomará la forma de media onda sinusoidal negativa. Este proceso se muestra en la figura 13.
Figura 12. Conversión de símbolos a chips.[61]
43
I
Q
1
1
0
-1
0
-1
1
0
-1
1
0
-1
1 1 0 1
1 10 0
Figura 13. Forma de medio pulso de onda sinusoidal
Estas formas de onda son descritas por la ecuación (1)
𝑃(𝑡) = {sin(𝜋
𝑡
2𝑇𝑐) 0 ≤ 𝑡 ≤ 2𝑇𝑐
0 𝑒𝑛 𝑜𝑡𝑟𝑜 𝑐𝑎𝑠𝑜 Ecuación (1)
6.5.3 Asignación de canales
En la figura 14 se muestra la asignación de canales en el estándar IEEE 802.15.4. Actualmente se usan los canales de la página 0 a la 2 para las bandas de 868/915 MHz y 2.4 GHz. Los canales de las páginas 3 a la 31 se encuentran reservados para futuras implementaciones. Cada página puede tener máximo 26 canales, la frecuencia central de cada canal puede ser calculada a partir la ecuación (2).
𝑓𝑐(𝑀𝐻𝑧) = 2405 + 5(𝑐𝑎𝑛𝑎𝑙 − 11) Ecuación (2)
Figura 14. Canales en el estándar IEEE 802.15.4 [62]
44
7. DESARROLLO E IMPLEMENTACIÓN
7.1 HERRAMIENTAS DE DESARROLLO
E En esta sección se muestra un análisis de las diferentes herramientas que permiten la implementación de sistemas RDS, se describen las características y prestaciones del hardware y software seleccionadas para este desarrollo y se detalla el manejo de estos.
7.1.1 Software
Para este proyecto el software seleccionado debe permitir realizar funciones específicas requeridas por el usuario. Por esta razón, se han preseleccionado tres programas que tienen un enfoque hacia la investigación y el desarrollo.
Matlab: algunas de las ventajas de utilizar este programa son, la familiaridad en su uso, la amplia gama de herramientas para procesamiento de señales que se disponen y la posibilidad de integrarse con Xilinx de manera que el desarrollo de aplicaciones directamente en la FPGA pueda realizarse de manera más rápida. No obstante, se requiere comprar la licencia del programa. LabView: es un software desarrollado por National Instruments que cuenta con soporte para
las tarjetas de Ettus en el desarrollo de aplicaciones, ofrece una amplia variedad de módulos de procesamiento, el manejo del software puede realizarse desde diagramas de flujo. Sin embargo, el programa también requiere de licencia. GNU Radio Companion (GRC): es un software de código libre y abierto, diseñado para el
desarrollo e implementación de sistemas de radio definida por software. Cuenta con una licencia GNU General Public License (GPL) versión 3. GNU Radio, es nativa de sistemas operativos Linux y aunque se encuentran versiones para Windows y Mac, no son del todo estables. Adicionalmente, GNU Radio tiene la posibilidad de exportar archivos en formatos que pueden ser utilizados por programas como Matlab, Octave, WireShark. El desarrollo de bloques de GNU Radio se basa en la programación en leguajes como Python 2 y C++ en el paradigma de programación orientada a objetos. En cuanto a la documentación, cabe mencionar que está enfocada a usuarios con un nivel intermedio, además, al ser de código abierto no está centralizada [63].
Teniendo en cuenta estas características, se decidió utilizar el software GNU Radio para la realización de este proyecto. Pues aún con sus dificultades, el hecho de ser de código abierto y tener una licencia libre va de la mano con el enfoque académico del proyecto.
7.1.1.1 GNU Radio Companion GNU Radio Companion (GRC) es un software que se proveen de librerías basadas en Python y en C++ para procesar las señales. Cuenta con una interfaz gráfica similar a la de Simulink de Matlab, donde se conectan los bloques funcionales de forma estructurada, esto es conocido como flujogramas. Cada vez que se compila un flujograma, se crea un archivo *.py que posteriormente es ejecutado por el sistema operativo. Tener el flujograma completamente descrito en un código en Python, permite hacer uso de muchas librerías para el procesamiento de señales y visualización gráfica como Numpy, WxPython y PyQt, entre muchas otras.
45
En la figura 15 se puede apreciar la interfaz de GRC. Esta interfaz dispone de un repositorio de bloques funcionales (Derecha), que son los que permiten programar el procesamiento y visualización de las señales. En el costado inferior se encuentra la sección de consola, donde aparece el registro de los eventos al momento de compilar el programa. En la parte central se encuentra el flujograma, en donde se conectan los bloques funcionales y se configuran las opciones generales del proyecto.
Figura 15. Interfaz gráfica de usuario de GRC
7.1.1.2 Instalación GNU Radio Companion Existen dos métodos para la instalación de GRC, el método manual y un método semiautomático que se basa en un script, este script descarga, instala y configura todas las librarías y paquetes necesarios para el correcto funcionamiento de GRC, de manera automática, por eso es el método más recomendado. Las etapas de instalación de GRC son:
Instalación de prerrequisitos (Librerías, herramientas de desarrollo) Instalación y configuración de GRC Instalación y configuración de los UHD (universal Hardware Driver)
Las herramientas de compilación necesarias para la ejecución de GRC son: g++, git, make, cmake, sdcc, guile, ccache. Adicionalmente, tener las herramientas de Octave (Procesamiento) y Doxigen (documentación) serán de gran utilidad.
Las librerías requeridas son: python-dev, SWIG, FFTW 3.X (libfftw3-dev), cppunit (libcppunit-dev), Boost 1.35, GSL GNU Scientific Library (libgsl0-dev), libusb and libusb-dev, ALSA (alsa-base, libasound2 and libasound2-dev), python-numpy, python-cheetah and python-lxml, python-wxgtk2.8 and python-numpy, (python-qt4, python-qwt5-qt4, libqt4-opengl-dev, libqwt5-qt4-dev, libfontconfig1-dev, libxrender-dev, libxi-dev), libsdl1.2-dev, python-scipy, python-matplotlib y python-tk.
46
El proceso aquí indicado se realizó para un equipo de cómputo con las siguientes características:
Sistema Operativo Ubuntu 14.04 LTS x64. Procesador Intel Core I5-4210U, CPU 1.7 GHz – 2.4 GHz. Memoria RAM 6.00 GB USB 3.0 SS Versión del software GRC 3.7.7.1
Instalación GRC por el Script Para tener una instalación exitosa con el script se debe tener una buena conexión a Internet, una velocidad de descarga superior a 3 Mbps y disponer de mínimo 4 horas. Este tiempo depende de la velocidad de conexión y de la disponibilidad de los servidores en donde se encuentran alojados los repositorios. Para ejecutar el Script se deben seguir los siguientes pasos:
Actualizar las listas de los repositorios de Ubuntu y algunas librerías con el comando >> $ sudo apt-get update && apt-get upgrade
Verificar que se tenga habilitado “Community maintained free and open-source software” (Universe). - Software & Update // Ubuntu Software/ Community maintained free and open-source software. Ejecutar el Script, para esto se tienen dos opciones, una opción es descargar directamente el
Script y dar permisos de ejecución, con el comando >> $ wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && ./build-gnuradio -
verbose all.
En este proceso también se instalan los UHD de las tarjetas de desarrollo de Ettus Research y los Firmware de las FPGAs, que quedan alojados en la carpeta: /usr/local/share/uhd/images.
Preguntas y Problemas frecuentes En algunos casos los repositorios no están disponibles, o la conexión a internet puede caerse, generando fallas en la instalación. La herramienta “verbose logging to stdout” permite al usuario hacer un seguimiento del proceso que se está ejecutando y de las fallas que puedan presentarse. Para implementar esta herramienta, al final de la sentencia que ejecuta el script se adiciona “–verbose all”.
En el caso particular de la versión de Ubuntu 14.04 el script detalla la instalación de un paquete llamado libzmq, que ya no está disponible, en su lugar se debe instalar libzmq1. Entonces, una opción que permite solucionar este inconveniente es modificar la línea 524 y renombrarlo (debido a que el script se encuentra en constante modificación puede que no sea precisamente ese número de línea).
7.1.1.3 Creación de bloques funcionales en GRC En los siguientes pasos se resume la creación de un nuevo módulo [64].
Crear Nuevo Módulo (Categoría), en terminal $ gr_modtool newmod “Nuevo_Modulo”
Cambiar de directorio $ cd gr-Nuevo_modulo
Crear Bloque
47
$ gr-modtool add -t sync -l cpp
Configurar la creación del bloque $ gr-tutorial$ gr_modtool add -t sync -l cpp
GNU Radio module name identified: Nuevo_Modulo
Language: cpp
Enter name of block/code square_ff
Enter valid argument list, including default arguments: float valor
Add Python QA code? [Y/n] N
Add C++ QA code? [Y/n] N
Modificar el archivo Square_ff.XML que se encuentra en gr-Nuevo_Modulo /grc, en este se deberá modificar los espacios sink, source y parameter, indicando el nombre deseado para el puerto y el tipo de dato.
<param>
<name>Valor DC</name>
<key>valor</key>
<type>float</type>
</param>
<sink>
<name>in</name>
<type>float</type>
</sink>
<source>
<name>out</name>
<type>float </type>
</source>
<doc>
Descripción del módulo…
</doc>
Abrir Square_ff.cc dentro de la carpeta de gr-Nuevo_Modulo / Lib y modificar los paramentos
que tengan las indicaciones <++>. Agregar dentro del constructor el valor del parámetro externo.
// The private constructor
add_dc_ff_impl::square_ff_impl(float valor)
: gr::sync_block("add_dc_ff",
gr::io_signature::make(1, 1, sizeof(float)),
gr::io_signature::make(1, 1, sizeof(float))),
d_valor(valor)
El procesamiento se realiza en la función Work(). Se deben modificar los espacios que contengan los símbolos <++> con el tipo de variables y el código del procesamiento debe introducirse dentro de un ciclo for, como se indica a continuación.
48
// Do <+signal processing+>
for(int i = 0; i < noutput_items; i++)
{
out[i] = in[i]*in[i]+d_valor;
}
return noutput_items;
Modificar el archivo “square_ff.h” y declarar como atributo privado d_valor. En la parte de
atributos públicos declarar las funciones valor() y set_valor(float valor). Antes de la función Work().
private:
float d_valor;
…
float valor() const { return d_valor; }
void set_valor(float valor) { d_valor = valor; }
Compilar la librería, para esto hay que ubicarse dentro del directorio gr-Nuevo_Modulo y colocar los siguientes comandos en el terminal:
$ mkdir build
$ cd build/
$ cmake ..
$ make clean && make
$ sudo make install
$ sudo ldconfig
Una de las pruebas que se implementa, es la creación del módulo Square_ff, este módulo toma la señal de entrada, la eleva al cuadrado y le añade un valor offset como parámetro externo. En la figura 16 se muestra como desde el GRC se puede importar el bloque Square_ff y poner en funcionamiento.
Figura 16. Verificación funcionalidad bloque Square_ff
49
7.1.2 Hardware
El hardware de una plataforma capaz de implementar conceptos de Radio Definida por Software, debe disponer de una arquitectura como la que se describe en la figura 1 de la sección 5.1.
El módulo RF Front-end, conocido también como “Daugther Board” o tarjeta hija, cuenta con un filtro pasa bajo que elimina el ruido y un amplificador para aumentar el nivel de potencia de la señal. Su función principal es trasladar la información de la señal, desde la frecuencia de la portadora a una frecuencia intermedia que puede variar entre 0 Hz y el ancho de banda de la tarjeta. Algunas versiones de las tarjetas de desarrollo diseñan la tarjeta hija como un elemento aislado que debe ser incorporado a la tarjeta principal. Sin embargo, las nuevas referencias de tarjetas de desarrollo integran esta y las demás etapas en una sola tarjeta, como consecuencias hay una reducción en los costos a cambio de la inserción de niveles de ruido e interferencia adicionales.
El módulo ADC se encarga de digitalizar la señal análoga, en este proceso se debe tener en cuenta parámetros como la cantidad de bits y la tasa máxima de muestreo, ya que éstos cumplen un papel importante en la disminución de errores por cuantización de la señal y permiten utilizar mayores anchos de banda. Cabe resaltar que el teorema de Nyquist contempla que para una señal con componentes reales, la tasa de muestreo 𝑓𝑠, debe ser mayor o igual al ancho de banda en banda base de una señal con información 𝑓𝑠 ≥ 2𝐵𝑏𝑏𝑅 . Sin embargo, cuando se trabajan señales con muestras en fase y cuadratura que se representan como señales complejas, la frecuencia de muestreo debe ser mayor o igual al ancho de banda de la señal en banda base𝑓𝑠 ≥𝐵𝑏𝑏𝐶 . En la tabla 16, se puede evidenciar que la tasa máxima de muestreo del ADC no siempre corresponde con alguna de estas dos relaciones, debido a que algunos de los sistemas son half dúplex, otros son SISO (una entrada una salida) y otros son MIMO 2x2 (2 entradas y 2 salidas).
La señal digitalizada pasa por los bloques DDC (Conversión Digital hacia abajo), estos bloques bajan la señal en frecuencia a banda base, para que pueda ser procesada. En algunos casos este proceso se realiza en una FPGA, en un DSP o en un computador, debido a que no todas las tarjetas tienen la posibilidad de elegir su núcleo de procesamiento. En general todas las herramientas están en la capacidad de trabajar con software que genera la interfaz entre el computador y la tarjeta, recargando el procesamiento en el computador. Para este caso el software programa un firmware, encargado de establecer la conexión para el flujo de datos entre los módulos ADC, DCA, DDC y DUP, hacia la interfaz disponible para conectarse con el computador. En este sentido, el uso de recursos de la FPGA no es muy elevado. En contraste, si el procesamiento se recarga en la FPGA, el software debe modificar el firmware base de la misma. Este proceso será mucho más eficiente en términos de procesamiento, pues permite realizar tareas en paralelo, utilizando más o menos recursos de la FPGA dependiendo de la implementación. Para esto se requiere conocer detalladamente las especificaciones de la FPGA y de sus periféricos. En la tabla 16 se indica la oferta de tarjetas de desarrollo con éstas características, algunas con más o menos prestaciones.
50
Tabla 16. Comparación, características y costos de tarjetas de desarrollo.
Haciendo un análisis de las especificaciones técnicas, el costo-beneficio y la funcionalidad se determinó adquirir la tarjeta de desarrollo USRP B210 de Ettus.
7.1.3 Tarjeta de desarrollo USRP B210
La tarjeta USRP B210, figura 17, dispone de un sistema 2x2 que permite poner en funcionamiento aplicaciones en diferentes bandas de frecuencia simultáneamente. La tasa de muestreo es suficiente para el entorno de aplicación de las redes de sensores. La interfaz con el computador es USB 3.0, si el computador solo dispone de la interfaz USB 2.0, la tarjeta también será reconocida pero la velocidad de transferencia de datos será menor. El rango de frecuencias de trabajo es de 70 MHz hasta los 6 GHz.
3
2
1
4
5
6
7
8
10
9
11
1. GPS2. Antena GPS3. CLK externo 10MHz4. USB3.0 SS5. PPS6. 5 VDC 3A7. Debug FPGA (Jatg, Mirror y GPIO)8. RF A:TX/RX 9. RF A:RX210. RF B:TX/RX11. RF B:RX2
Figura 17. Tarjeta USRP B210
Board USRP1 USRP B210 USRP B200 USRP N210SDR-RTL
RTL2832UHack RF one Blade RF
BW/ MHz 16 56 56 50 3,2 20 28
Full duplex si si si si Solo Rx Half si
Interfaz USB 2.0 HS USB 3,0 USB 3,0 Gbit Ethernet USB 2.0 HS USB 2.0 HS USB 3,0
V int /Mbps 480 5000 5000 1000 480 480 5000
MIMO 2 RX - 2 TX 2 RX - 2 TX 1 RX - 1 TX 2 RX - 2 TX 1 Rx 1 Rx ó 1 Tx 2 RX - 2 TX
ADC 12 bit - 64 MS/s 12 bit - 61.4 MS/s 12 bit - 61.4 MS/s 14 bit - 100 MS/s 8 bit - 3,2 MS/s 8 bit - 20 MS/s 12 bit - 40 MS/s
DAC 14 bit - 128 MS/s 12 bit - 61.4 MS/s 12 bit - 61.4 MS/s 16 bit - 400 MS/s ~ 8 bit - 20 MS/s 16 bit - 38 MS/s
F / GHz 0.4-4.4 @SBX 0.07 - 6 0.07 - 6 0.4-4.4 @SBX 0.024 - 1.776 0.03 - 6 0.3 - 3.8
FPGA Altera CycloneSpartan 6
XC6SLX150 FPGA
Spartan 6
XC6SLX75 FPGA
Spartan 3A-DSP
3400
8051
+demoduladorCPLD Altera Cyclone IV
Costo 2.000.000$ 3.115.000$ 1.890.000$ 4.862.000$ $ 30.000 $ 720.000 $ 1.560.000
Costo ad 1.700.000$ 300.000$ 300.000$ 1.700.000$ $ - $ 72.000 $ 600.000
Total + IVA 4.292.000$ 3.961.400$ 2.540.400$ 7.611.920$ $ 34.800 $ 918.720 $ 2.505.600
Pagína
http://www.ettus.co
m/product/details/U
SRPPKG
http://www.ettus.co
m/product/details/U
B210-KIT
http://www.ettus.co
m/product/details/
UB200-KIT
http://www.ettus.c
om/product/details
/UN210-KIT
http://www.rtl-
sdr.com/buy-rtl-
sdr-dvb-t-
dongles/
http://greatscot
tgadgets.com/h
ackrf/
http://nuand.com/
51
La USRP requiere de antenas para poder realizar la transmisión y recepción de señales, para este trabajo se eligió una antena Logarítmica periódica que trabaja en un rango de frecuencia entre 850-6500 MHz, como se muestra en la figura 18.
Figura 18. Antena de la USRP
En la figura 19, se presenta un flujograma que permite enviar y recibir señales mediante la tarjeta USRP B210. Los bloques principales que permiten la transmisión y recepción de las señales son UHD: USRP Source que actúa como receptor de la señal, y UHD: USRP Sink, que permite la transmisión de la señal. En cada uno de estos bloques se debe configurar una serie de parámetros para lograr transmitir y recibir exitosamente, que se especifican a continuación
Device addr: Identificador del dispositivo, si se deja en blanco utilizará la primera que encuentre [“type: b200”, o “serial: 3094DBA”, o ”product: B210”]
Sync: en este campo se escoge la fuente del reloj para la tarjeta, puede ser por [PPS, GPS, 10 MHz o por default]. Este parámetro es importante cuando se tienen comunicadas varias tarjetas entre sí.
Num Mboard: especifica el número de tarjetas conectadas al PC [1].
MB0: SubDev Spec: permite la configuración de los RF Front ends, se indica si el sistema es 1x1 [A:A ; A:B ; A:AB ; A:BA ], ó 2x2 [A:A A:B].
Num channels: permite elegir el número de canales [1] o [2].
Ch0: Antena: este campo indica el Puerto RF en donde se conectará la antena [TX/RX o RX2] ver tarjeta.
Ch0: Gain (dB): en este campo se especifica la ganancia. Para el puerto RX2 el límite superior es de 76.0 dB, para el puerto Tx/Rx es de 89.8 dB, sin embargo, en rangos menores a 15 m es suficiente con una ganancia entre 10 y 25 dB.
52
Figura 19. Flujograma con bloques para el uso de la tarjeta B210.
7.2 ENTORNO DE APLICACIÓN A IMPLEMENTAR
De acuerdo a la revisión del estado del arte, existe una amplia gama de aplicaciones para las redes de sensores, cada una de ellas con requerimientos muy particulares, por tal motivo se implementa una aplicación de carácter demostrativo en donde se involucran algunos de los requerimientos comúnmente solicitados.
En este trabajo se implementa un concentrador que comunica una red de sensores compuesta por dos dispositivos Xbee. Estos módulos están configurados como coordinadores, trabajando en una frecuencia diferente y con un pan ID diferente, para evitar que los dos dispositivos pueden comunicarse entre ellos, simulando así dos diferentes entornos de redes ZigBee. Estas configuraciones se detallan en la tabla 17.
Modulo Configuración
Xbee N°1 Xbee N°2
Referencia Xbee S2 Xbee S2 PRO
Dirección 0x0013A200407C47D9 0x0013A20040546F4A
Modo Coordinador Coordinador
Pan ID 0x6CFD 0x4987
Canal 11 22
Frecuencia central 2405 MHz 2460 MHz
Versión del protocolo ZigBee-2006 ZigBee-2006
Modo de transmisión Broadcast Broadcast
Dirección de destino 0xFFFF 0xFFFF
Tipo de modulación O-QPSK O-QPSK
Tipo de codificación DSSS DSSS
Funcionalidad Transmisión y recepción Transmisión y recepción
Tasa de bits 250 Kbps 250 Kbps
Tabla 17. Especificaciones de la configuración de los nodos
53
Como eje central de la red se encuentra el dispositivo concentrador capaz de comunicarse con cada uno de los nodos. Para lograrlo, el dispositivo debe reconfigurar parámetros de frecuencia de operación, tipo de modulación, direccionamiento y tipo de red, tipo de protocolo, codificación y tasa de bits. En la figura 20 se muestra el esquema de la red de sensores que se plantea implementar.
Figura 20. Esquema de la implementación red de sensores
7.3 NODOS XBEE
Para el proyecto se diseñan dos nodos que puedan transmitir y recibir mensajes hacia y desde el concentrador central. Para poder comprobar estas funcionalidades, en cada nodo se hace uso de un microcontrolador MSP4302553, un sensor de temperatura LM35, una pantalla LCD 2x16 y una fuente de alimentación, como se muestra en la figura 21.
BAT
MSP430
2553
XbeeLM35
LCD 2x16
ADC
I/O
UART
+3.3V
Figura 21.Elementos básicos del nodo
El programa que se implementa dentro del microcontrolador, fue desarrollado en el software Code Composer Studio. El diagrama de flujo de dicho programa se presenta en la figura 22, en este se especifica cómo después de inicializar los puertos y las configuraciones básicas para el funcionamiento, se inicializa la LCD, la configuración de la interrupción del temporizador para que se realice cada 100 ms y la interrupción por recepción del puerto UART para que muestre en la LCD el mensaje que se le está enviando. Finalmente el nodo queda en modo de bajo consumo (LPM) esperando que alguna de las interrupciones lo active. Aunque el timer se activa cada 100 ms, se establece que tome las muestras del ADC, las muestre en pantalla y las envíe por el Xbee cada 4 s. El código completo se presenta en el anexo 14.1.
54
Figura 22. Diagrama de flujo del software del microcontrolador
Una vez desarrollado el código se realiza el diseño del montaje, el diagrama esquemático de este se muestra en la figura 23. Se verifica el correcto funcionamiento del esquemático implementándolo en protoboard para luego poder realizar el circuito impreso en la herramienta Eagle que se enseña en la figura 24. Finalmente en la figura 25, se presenta una fotografía del montaje del circuito impreso en funcionamiento.
Figura 23. Diagrama esquemático Nodo.
Watch dog off MCLK = 1MHzPuertos: entrada/salida
Inicializacion de la LCD
LCD muestra msj inicial
Configuración time ISR 4s
Configuracion UART ISR RX
Habilita interrupción
INICIO
Modo de bajo consumo
msj_rx = UART_rx
Muestra msj_rx en LCD línea 2
Interrupción UART
Modo de bajo consumo
Lectura del ADC
Acondicionamiento
Envía datos de T° al Xbee
Interrupcion Timer
Modo de bajo consumo
Muestra T° en la LCD línea 2
55
Figura 24. Simulación diseño PCB.
Figura 25. Nodo Xbee con LCD y sensor de temperatura implementado.
7.4 CONCENTRADOR
En este trabajo se diseñaron e implementaron en software los bloques funcionales del sistema de comunicaciones para la red. En esta sección se explica el desarrollo de cada uno de los bloques requeridos y las consideraciones necesarias para cumplir con las especificaciones IEEE 802.15.4 y ZigBee-2006.
Durante la revisión de trabajos relacionados se encontraron algunas librerías elaboradas en GNU Radio que implementan las capas O-QPSK PHY , CSS PHY y la capa de enlace del estándar IEEE 802.15.4 [54, 55]. Estas librerías fueron elaboradas por los investigadores Thomas Scmith,
56
Bastian Boessl y Felix Wunsch. Estos desarrollos fueron un gran aporte dentro de los espacios académicos, investigativos e industriales, pues generaron un fuerte impacto tecnológico, permitieron un avance de gran escala dentro del desarrollo de las redes de sensores inalámbricas y por supuesto sirvieron como referencia para el diseño de los bloques que se realizaron en este proyecto. La diferencia entre los bloques desarrollados aquí y en los bloques desarrollados por el investigador Bastian Boessl radica en la estructura. Para este trabajo los bloques son diseñados bajo la misma jerarquía del modelo OSI, las funcionalidades de transmisión y recepción se implementan separadamente. Adicionalmente, algunos de los bloques efectuados para esta aplicación implementan parámetros dinámicos. Por otra parte, se debe mencionar que la mayoría de estos bloques utilizan mensajes tipo PMT para la comunicación entre ellos, esto implica unas modificaciones adicionales, por ejemplo, si se programa con C++, el formato PMT se debe convertir a vectores. Si la programación se hace en Python, el formato PMT se debe convertir en listas o arreglos de vectores numpy.
Es recomendable instalar las librerías ieee802_15_4 y foo en este tipo de desarrollos, pues son librerías muy completas y pueden resultar de gran utilidad. Para la instalación de este tipo de librerías al igual que para las librerías personales se utilizan los siguientes comandos.
$ $ cd nombre de la librería
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install
$ sudo ldconfig
7.4.1 Capa Física del Xbee
Como ya se mencionó, los módulos Xbee utilizados en este proyecto trabajan en la banda de frecuencia de 2.4 GHz e implementan el estándar IEEE 802.15.4, en donde se definen dos tipos de capa física para esta banda de frecuencia, el CSS PHY que utiliza la técnica CSS (Chirp Spread Spectrum) para codificar los datos, e implementa una modulación DQPSK (Modulación por desplazamiento de fase en cuadratura de polarización dual). El otro tipo de capa física se conoce como O-QPSK PHY, en este se implementa una modulación O-QPSK y una codificación DSSS (espectro ensanchado por secuencia directa). En la documentación técnica de los módulos no se especifica cuál de estas dos versiones se implementa en los dispositivos. Esta información se precisa en la hoja de datos del radio de los módulos. Para este caso el radio EM250 de Silicon Labs trabaja con la versión O-QPSK PHY [65].
Las características de capa física están descritas detalladamente en la sección 6.5. Para poder implementar el esquema de la figura 11 se hace uso de los bloques que se disponen en GNU Radio y eventualmente se reutiliza algún bloque de las librerías Ieee802_15_4 y Foo.
Para crear el bloque de transmisión de la capa física, se utiliza la opción de GNU Radio de bloques jerárquicos. En la figura 26 se presenta la imagen del bloque completo de recepción de capa física. Los bloques de procesamiento del flujograma que componen el bloque de recepción de la capa física se muestran en la figura 27.
57
Figura 26. Bloque de recepción de la capa física
Figura 27. Diagrama de bloques del Transmisor OQPSK
El bloque “Acces Code Prefixer” se encarga de adicionar el preámbulo (4 bytes), el Indicador de Inicio de Trama (1 byte) y la longitud del paquete a la trama (1 byte) que viene desde la capa de enlace (MPDU), a todo este arreglo se le conoce como PPDU. Estos datos vienen en formato PMT, por lo tanto se deben convertir a vectores para poder adicionar los encabezados de la capa física. Luego, el bloque “PDU to Tagged Stream” se encarga de convertir los mensajes PMT a Stream tipo byte para que los demás bloques puedan reconocer los paquetes que envían. A partir de esto se realiza el proceso de codificación y modulación.
De la misma forma como se especifica en la sección 6.5 los bits del PPDU son agrupados de a cuatro en cuatro generando 16 diferentes símbolos. Cada uno de los símbolos tiene un correspondiente chip de 32 bits, cuyas muestras pares corresponden a los símbolos en fase, y las impares a los símbolos en cuadratura. Este proceso se realiza dentro de los bloques “Packet to unpacket” y “Chunks to Symbols”. Este último está configurado con una tabla con las muestras en fase y en cuadratura para 16 símbolos, como se muestra en la tabla 18.
Una vez generadas las señales I y Q, se deben formar los pulsos de media onda seno para cada una de ellas. Para esto se crea un vector con las muestras de la media onda seno almacenadas. Este procedimiento se realiza con el bloque “Vector source” y en el bloque “Repeat”, estos bloques deben contener la misma cantidad de elementos y la misma cantidad de muestras por símbolo.
Para entender la relación entre el número de muestras por símbolo y la tasa de muestreo, hay que recordar que la norma indica una tasa de bits constante de 250 Kbps para el PPDU. Después del proceso de codificación en Chips y la modulación de los símbolos I y Q, la tasa de bits se incrementa en un factor de 4, produciendo una tasa de símbolos constante de 1 MSim/s para las señales I y Q, de manera que la cantidad de muestras de los símbolos puede calcularse
58
mediante la ecuación (3). También se debe implementar el desfase de 𝜋/2 de la señal Q con respecto a I, desfasamiento que se representa con un retardo de medio tiempo de símbolo, que a su vez debe tener una representación en muestras, las muestras del retardo están relacionadas con la ecuación (4).
𝑀𝑠𝑖𝑚 = 𝑇𝑎𝑠𝑎 𝑑𝑒 𝑀𝑢𝑒𝑠𝑡
𝑇𝑎𝑠𝑎 𝑑𝑒 𝑆𝑖𝑚𝑏=
𝑇𝑎𝑠𝑎 𝑑𝑒 𝑀𝑢𝑒𝑠𝑡 (𝑀𝑠𝑝𝑠)
1 MSim/s Ecuación (3)
𝑑𝑒𝑙𝑎𝑦𝑠𝑎𝑚 = 𝑀𝑠𝑖𝑚
2 Ecuación (4)
Sim Muestras (I+jQ)
𝑆0 (1+1j), (-1+1j), (1-1j), (-1+1j), (1+1j), (-1-1j), (-1-1j), (1+1j), (-1+1j), (-1+1j), (-1-1j), (1-1j), (-1-1j), (1-1j), (1+1j), (1-1j),
𝑆1 (1-1j), (-1-1j), (1+1j), (-1-1j), (1-1j), (-1+1j), (-1+1j), (1-1j), (-1-1j), (-1-1j), (-1+1j), (1+1j), (-1+1j), (1+1j), (1-1j), (1+1j),
𝑆2 (-1+1j), (-1+1j), (-1-1j), (1-1j), (-1-1j), (1-1j), (1+1j), (1-1j), (1+1j), (-1+1j), (1-1j), (-1+1j), (1+1j), (-1-1j), (-1-1j), (1+1j),
𝑆3 (-1-1j), (-1-1j), (-1+1j), (1+1j), (-1+1j), (1+1j), (1-1j), (1+1j), (1-1j), (-1-1j), (1+1j), (-1-1j), (1-1j), (-1+1j), (-1+1j), (1-1j),
𝑆4 (-1-1j), (1-1j), (1+1j), (1-1j), (1+1j), (-1+1j), (1-1j), (-1+1j), (1+1j), (-1-1j), (-1-1j), (1+1j), (-1+1j), (-1+1j), (-1-1j), (1-1j),
𝑆5 (-1+1j), (1+1j), (1-1j), (1+1j), (1-1j), (-1-1j), (1+1j), (-1-1j), (1-1j), (-1+1j), (-1+1j), (1-1j), (-1-1j), (-1-1j), (-1+1j), (1+1j),
𝑆6 (1+1j), (-1-1j), (-1-1j), (1+1j), (-1+1j), (-1+1j), (-1-1j), (1-1j), (-1-1j), (1-1j), (1+1j), (1-1j), (1+1j), (-1+1j), (1-1j), (-1+1j),
𝑆7 (1-1j), (-1+1j), (-1+1j), (1-1j), (-1-1j), (-1-1j), (-1+1j), (1+1j), (-1+1j), (1+1j), (1-1j), (1+1j), (1-1j), (-1-1j), (1+1j), (-1-1j),
𝑆8 (1+1j), (1-1j), (1+1j), (-1+1j), (1-1j), (-1+1j), (1+1j), (-1-1j), (-1-1j), (1+1j), (-1+1j), (-1+1j), (-1-1j), (1-1j), (-1-1j), (1-1j),
𝑆9 (1-1j), (1+1j), (1-1j), (-1-1j), (1+1j), (-1-1j), (1-1j), (-1+1j), (-1+1j), (1-1j), (-1-1j), (-1-1j), (-1+1j), (1+1j), (-1+1j), (1+1j),
𝑆10 (-1-1j), (1+1j), (-1+1j), (-1+1j), (-1-1j), (1-1j), (-1-1j), (1-1j), (1+1j), (1-1j), (1+1j), (-1+1j), (1-1j), (-1+1j), (1+1j), (-1-1j),
𝑆11 (-1+1j), (1-1j), (-1-1j), (-1-1j), (-1+1j), (1+1j), (-1+1j), (1+1j), (1-1j), (1+1j), (1-1j), (-1-1j), (1+1j), (-1-1j), (1-1j), (-1+1j),
𝑆12 (-1-1j), (1-1j), (-1-1j), (1-1j), (1+1j), (1-1j), (1+1j), (-1+1j), (1-1j), (-1+1j), (1+1j), (-1-1j), (-1-1j), (1+1j), (-1+1j), (-1+1j),
𝑆13 (-1+1j), (1+1j), (-1+1j), (1+1j), (1-1j), (1+1j), (1-1j), (-1-1j), (1+1j), (-1-1j), (1-1j), (-1+1j), (-1+1j), (1-1j), (-1-1j), (-1-1j),
𝑆14 (1-1j), (-1+1j), (1+1j), (-1-1j), (-1-1j), (1+1j), (-1+1j), (-1+1j), (-1-1j), (1-1j), (-1-1j), (1-1j), (1+1j), (1-1j), (1+1j), (-1+1j),
𝑆15 (1+1j), (-1-1j), (1-1j), (-1+1j), (-1+1j), (1-1j), (-1-1j), (-1-1j), (-1+1j), (1+1j), (-1+1j), (1+1j), (1-1j), (1+1j), (1-1j), (-1-1j)
Tabla 18. Tabla para el bloque Chunk to Symbols
En la tabla 19 se puede observar como la variación de la tasa de muestreo afecta, tanto la cantidad de muestras por símbolo como la cantidad de muestras en las que se retarda la señal Q con respecto a I. Es importante tener en cuenta que el ancho de banda de la señal de salida del transmisor es de 2 MHz y siendo ésta una señal compleja, la tasa de mínima de muestreo de la tarjeta USRP debe ser de 2 MS/s.
Tasa de muestreo (MS/s) 1 2 4 5 6 8 10 12 16
Muestras por símbolo I & Q 1 2 4 5 6 8 10 12 16
Muestras de retardo 0,5 1 2 2,5 3 4 5 6 8
Muestras Clock M&M 0,5 1 2 2,5 3 4 5 6 8
Múltiplo PDU length 32 64 128 160 192 256 320 384 512
Tabla 19. Tasas de muestreo.
Por último, el bloque “Burst Tagger”, es el encargado de ajustar el tamaño del “Stream” o ráfaga de datos para obtener un paquete de 512 bytes, debido a que éste es el tamaño de los paquetes que se envían desde la interfaz USB hacia la USRP. Para esto, se adicionan ‘0’ hasta completar el tamaño del paqute. Adicionalemente, el bloque agrega las etiquetas "tx_sob" y "tx_eob" para
59
indicar el inicio y el final del paquete. Éstos se leen como metadatos que desde la USRP y se utilizan para controlar el flujo de datos transmitidos. En la tabla 19 se consignan los valores que debe tomar el múltiplo del PDU para diferentes tasas de muestreo de acuerdo a la ecuación (5). En el caso de utilizar una tasa de muestreo de 4 MS/s el valor multiplocador será de 128 para conseguir los 512 bytes.
𝑀𝑢𝑙𝑡𝑃𝐷𝑈 = 32 x 𝑀𝑠𝑖𝑚 Ecuación (5)
En la figura 28 se muestra el bloque jerárquico de recepción de la capa física O-QPSK. Este bloque está compuesto internamente por un flujograma, que a su vez está compuesto por unos bloques de procesamiento como se indica en la figura 29.
Figura 28. Bloque de recepción de capa física O-QPSK
Figura 29. Flujograma del bloque de recepción de capa física O-QPSK
El bloque “Power Squelch” se utiliza para reducir el costo computacional del procesamiento. Para lograrlo, este utiliza un umbral que se establece en -50 dB. Así, si la señal que llega no supera este umbral, esta no es procesada por ninguno de los bloques posteriores. Luego, el bloque “Quadrature Demod” permite obtener la diferencia de fase entre la señal I y la señal Q como se indica en la ecuación (6).
𝜑[𝑛] = 𝐴𝑟𝑔(𝐼[𝑛] ∗ 𝑐𝑜𝑛𝑗(𝑄[𝑛])) Ecuación (6)
El bloque “single pole IIF filter” implementa la función de transferencia de un filtro pasa bajos de primer orden con respuesta infinita al impulso y que tiene un polo en (1 − 𝛼), como se describe en la ecuación (7). Este filtro es sintonizado a una frecuencia de 100 Hz, que permite eliminar el nivel DC de la señal. La frecuencia de corte del filtro se calcula mediante la ecuación (8).
60
𝐻(𝑧) =𝛼
1−(1−𝛼)𝑍−1 Ecuación (7)
𝑓𝑐 =𝛼
(1−𝛼)2𝜋∆𝑇 Ecuación (8)
Donde 𝛼 = 160 ∗ 10−6 y ∆𝑇 = 3.25 𝑢𝑠 representa el tiempo entre muestras.
Posteriormente se utiliza el bloque Clock Recovery MM para el proceso de sincronización de los símbolos. En este bloque se implementa el algoritmo de Mueller & Müller [66]. Este algoritmo está diseñado para estimar la diferencia de fase del símbolo. De manera que permite encontrar el instante del inicio del símbolo. Para conseguirlo, es necesario especificar adecuadamente el valor de Omega, que es el número de muestras por chips en este caso. Como la tasa de chips es de 2 MChips/s, el doble de los símbolos I y Q, la cantidad de muestras por chips se reduce a la mitad como se muestra en la tabla 18. Luego de haber sincronizado el instante de inicio de los chips, éstos se deben convertir a símbolos, para esto se implementa el bloque “Packet Sink” desde la librería gr-ieee802.15.4. Este bloque está diseñado para buscar el preámbulo que son 8 símbolos 𝑆0 cada uno con 32 bits. Para identificar los símbolos, dentro del bloque se compara el chip actual bit a bit con cada uno de los 16 símbolos previamente almacenados, que se muestran en la tabla 20 [67]. Durante ésta comparación se guarda el resultado que mayor número de coincidencias encuentre siempre y cuando supere un umbral de comparaciones exitosas, definido mediante el parámetro externo Theshold. El valor del umbral debe ser un valor entre (1-32). Para este caso se establece en 10.
Sim Chips decimal 𝑆0 1100000011101111010111001101100 1618456172 𝑆1 1001110000001110111101011100110 1309113062 𝑆2 1101100111000000111011110101110 1826650030 𝑆3 1100110110011100000011101111010 1724778362 𝑆4 0101110011011001110000001110111 778887287 𝑆5 1111010111001101100111000000111 2061946375 𝑆6 1110111101011100110110011100000 2007919840 𝑆7 0000111011110101110011011001110 125494990 𝑆8 0011111100010000101000110010011 529027475 𝑆9 0110001111110001000010100011001 838370585 𝑆10 0010011000111111000100001010001 320833617 𝑆11 0011001001100011111100010000101 422705285 𝑆12 1010001100100110001111110001000 1368596360 𝑆13 0000101000110010011000111111000 85537272 𝑆14 0001000010100011001001100011111 139563807 𝑆15 1111000100001010001100100110001 2021988657
Tabla 20. Secuencia e bits para la recuperación de los símbolos desde los chips
El diagrama de flujo del funcionamiento general del bloque ‘Packet Sink’ se presenta en la figura 30. Una vez identificado el preámbulo, se debe encontrar el inicio de trama 0xA7 (𝑆10, 𝑆7), luego se debe identificar la longitud del paquete MPDU para así poder decodificar cada uno de los bytes siguientes. Finalmente el arreglo es enviado en formato PMT.
61
Figura 30. Diagrama de flujo del funcionamiento del bloque ‘Packet Sink’
7.4.2 Capa de Enlace del Xbee
Las especificaciones de la capa de enlace o capa Mac están determinadas por el estándar IEEE 802.15.4, los aspectos relevantes de dichas especificaciones se detallan en la sección 6.4. Para este proyecto se desarrolla el bloque “Tx MAC 802.15.4”, que se encarga de encapsular los datos provenientes de la capa de red, ver figura 31. El bloque utiliza dos parámetros externos, el Pan ID (2 bytes) y Source Add (2 bytes) que indican la dirección de destino que se le asigna al concentrador. El parámetro Pan ID se configura de forma dinámica, esto quiere decir que aun cuando se esté corriendo el programa, se puede cambiar el valor de este campo y ejecutar los cambios. Este hecho vale la pena mencionarlo debido a que los bloques creados utilizan el paradigma de programación orientada a objetos y para asignar un parámetro externo se debe crear un método público que actualice el valor cada vez que éste sea cambiado. Adicionalmente, en esta capa se introduce el campo FCS (Frame Check Sequence) que se utiliza para comprobar la veracidad del paquete. Este campo es imprescindible y debe realizarse adecuadamente para que los módulos Xbee no descarten los paquetes recibidos. El código en Python y el Xml utilizados para el desarrollo de este bloque se presenta en el anexo 13.4.
Figura 31. Bloque de transmisión de la capa de enlace
Para la recepción, se crea el módulo que se muestra en la figura 32. Con este bloque se obtienen los valores de los campos de Frame Control (2 bytes), Sequence Number (2 bytes), Pan ID (2 bytes), Source Add (2 bytes), y FCS (2 bytes). La información del campo Surce Address se utiliza para detectar el origen del paquete, compararlo y rechazar los paquetes que son generados por el mismo concentrador. El campo FSC que se recibe se compara con el FCS calculado a partir de
Inicio
Encuentra Preambulo?
Encuentra SFD?
L = Frame Length
cont== L? Enviar Buf[]
Buf[cont]=Paquete[i]
Cont++
PMT Metadata (LQI)
No
No
No
Si
Si
Si
62
los bits recibidos del MPDU, generando así la medición de la tasa de errores de paquetes (PER). El código Python y Xml se presentan en el anexo 13.4.
Figura 32. Bloque de recepción de la capa de enlace
7.4.3 Capa de Red del Xbee
La capa de red de los módulos Xbee están definidas por el estándar ZigBee 2006 que se detalla en la sección 6.3. En esta capa se encuentran los campos de las direcciones de destino. Para este desarrollo se decidió implementar un mensaje tipo broadcast tanto para transmitir como para recibir, sin embargo, la realización de mensajes unicast y multicast es totalmente factible. Como el mensaje es tipo broadcast, en la trama de control se especifica que no necesita ir el campo de dirección IEEE de destino de 64 bits. Para la dirección de destino de 16 bits se utiliza 0xFFFF que indica mensaje broadcast. La dirección del concentrador de 16 y de 64 bits la escoge el usuario desde el GNU Radio. En la figura 33 se muestra el bloque desarrollado para adicionar los campos de esta capa.
Figura 33. Bloque de transmisión de la capa de red
Para el proceso de recepción se implementa el bloque de la figura 34, que toma los campos de direccionamiento, dejando la carga útil de la capa de red que luego se envía a la capa de aplicación. Para este desarrollo no se implementó algún tipo de control en esta capa, sin embargo, se podría hacer dependiendo de la aplicación que se requiera. El código Python y Xml de los bloques se presenta en el anexo 13.3.
Figura 34. Bloque de recepción de la capa de red.
7.4.4 Capa de Aplicación del Xbee
Las especificaciones de la capa de aplicación están definidas por el estándar ZigBee, como se detalla en la sección 6.2 para los módulos Xbee S2 y Xbee S2 PRO. En esta capa se encapsula el mensaje que se genera desde el usuario mediante el módulo disponible en GNU Radio “Message Strobe”, que envía el mensaje periódicamente. Para que el módulo funcione correctamente, el mensaje debe almacenarse en una variable del tipo PMT, para ello es necesario realizar una conversión del formato utilizando la sentencia pmt.intern(Mensaje), donde “Mensaje” es la variable tipo srting que el usuario ingresa desde la interfaz gráfica. Éste valor se actualiza de forma dinámica.
63
El módulo Tx App_Xbee de la figura 35 se encarga de adicionar los valores de la capa de aplicación necesarios para que se pueda comunicar con los módulos Xbee. Estos valores son propios de cada fabricante de dispositivos.
Figura 35. Módulo de transmisión de la capa de aplicación
En el proceso de recepción se implementa el bloque que se muestra en la figura 36. La función de este bloque es extraer la carga útil de la capa de aplicación, que contiene el mensaje proveniente de los módulos Xbee. El mensaje está compuesto por los campos señalados en la tabla 21, donde el campo de origen contiene el valor 0x01 para indicar la procedencia del módulo Xbee No. 1, y con 0x02 para el módulo No. 2. Como la información que se recibe es un valor de temperatura, es de interés graficarla con respecto al tiempo. Para esto, es necesario utilizar el módulo “Socket PDU”, que permite crear un servidor UDP en un puerto, especificado por el usuario. El servidor UDP entonces envía los datos de temperatura a todos los clientes UDP que se encuentren conectados. El código Python y Xml de los bloques Rx App Xbee y Tx App Xbee se encuentra en el anexo 13.2.
Origen Decena Temp Unidad Temp Coma Decimal 0x01 0x32 0x35 0x2C 0x34
Tabla 21. Mensaje enviado desde los módulos Xbee al concentrador
Figura 36. Capa de aplicación en recepción de los módulos Xbee
64
8. VALIDACIÓN DEL SISTEMA
8.1 VALIDACIÓN FUNCIONAL DE LOS BLOQUES
Para la realización de las pruebas se activó cada uno de los nodos Xbee como dos diferentes entornos de red, con los parámetros indicados en la tabla 17. Desde el concentrador se envían y reciben mensajes de los nodos como se indica en la figura 37.
Figura 37. Pruebas entre el concentrador y los nodos Xbee
En la figura 38 se puede observar los datos de temperatura que envía el nodo en la primera línea y el mensaje que recibe desde la USRP que se muestra en la segunda línea de la LCD
.
Figura 38. Mensajes enviados y recibidos en los nodos Xbee
Para enviar los datos desde el concentrador se ejecuta el programa diseñado en GNU radio que se muestra en la figura 39. El programa está compuesto por bloques diseñados para cada una
65
de las capas de los módulos Xbee. Los bloques que se muestran en el lado derecho de la figura realizan el proceso de transmisión, mientras los bloques del costado izquierdo realizan el proceso de recepción.
Figura 39. Flujograma de transmisión y recepción para las tramas ZigBee
El objetivo principal del programa, es realizar una correcta transmisión y recepción de las tramas de los módulos Xbee. Hay que señalar que esto podría haberse realizado mediante un solo bloque, implicando menor cantidad de trabajo para los autores. Sin embargo, en este desarrollo, se decidió implementar cada capa en un bloque independiente, permitiendo flexibilidad y escalabilidad para el proyecto, de manera que si la alianza ZigBee decide realizar cambios en su protocolo y sacar una nueva versión, como ocurrió entre los protocolos ZigBee-2003 y ZigBee-2006, no es necesario cambiar todo el programa, sencillamente se reemplaza o se modifica el bloque de la capa que resulte afectada. Estos bloques son reutilizables, así por ejemplo, si se trabaja con un dispositivo que se basa en el protocolo IEEE 802.15.4 o el protocolo de dicho dispositivo trabaja con alguna de las capas aquí realizadas, se pueden tomar las capas que se requieran y acoplarlas de acuerdo a los requerimientos del dispositivo.
Por estas razones es necesario validar que cada uno de los bloques realiza un correcto funcionamiento de acuerdo a las especificaciones de operación que le corresponden a la capa. Para esta prueba se utilizó el bloque “Message Debug” que está disponible dentro de las herramientas del programa GRC. Este bloque imprime en la consola los datos que le ingresan, por eso es conectado en la salida de cada uno de los bloques, permitiendo leer y analizar los datos procesados.
66
Para los mensajes de recepción, se realiza un desencapsulamiento de datos en cada una de las tramas, hasta llegar a la trama de aplicación y obtener el mensaje enviado por el nodo, así que la prueba se realizó en el orden ascendente de las capas.
Figura 40. Datos de salida de la capa física de recepción
En la figura 40 se muestran los datos obtenidos en la salida de la capa física. Como se puede apreciar en la gráfica, de los datos que tiene la trama completa, solo se obtiene el campo de la longitud de la trama y el campo MPDU, esto ocurre debido a que los datos de preámbulo y SFD fueron utilizados para obtener la sincronización de la trama.
Figura 41. Datos de salida de la capa de enlace de recepción
67
En la figura 41 se muestra la prueba realizada en la salida del bloque de la capa MAC. Comparando los datos obtenidos en la consola con respecto a los de la figura 40, se puede observar que los datos de esta parte de la prueba ya no tienen los 9 Bytes correspondientes al encabezado de la trama MAC.
Figura 42. Datos de salida de la capa de red en recepción
En la figura 42, con el bloque “Message Debug” se toman los datos de salida de la capa de red que son mostrados en la consola de GRC. Se puede notar que este bloque prescindió de los 16 Bytes correspondientes a los campos “Frame control”, “Destination address”, “Source Address”, “Radio”, “Sequen number” y “Destinaton IEEE Address” del encabezado de la trama de red.
Figura 43. Datos de salida de la capa de red en recepción
68
En la figura 43, se muestra la prueba realizada en la capa de aplicación. En la salida de éste se obtienen los datos de temperatura que envía el nodo Xbee en formato Ascii. Este bloque eliminó los Bytes correspondientes al encabezado de la trama de aplicación. Adicionalmente, se utiliza el bloque “Socket PDU” para crear un servidor UDP que transmite los datos del mensaje en el puerto ‘10001’ de la dirección local ‘127.0.0.1’.
Para verificar el proceso de transmisión, contrario al proceso de recepción, se realiza la verificación de los bloque partiendo desde la capa de aplicación hasta llegar a la capa física.
En la figura 44 se muestra las pruebas realizadas en el bloque de aplicación para transmisión. En la imagen se observa que se implementó un bloque “Message Strobe”, este bloque genera periódicamente los mensajes predefinidos por el usuario que son enviados a la capa de aplicación. En la salida de este bloque se conecta el bloque “Message Debug”, permitiendo ver el mensaje predeterminado en la consola.
Figura 44. Datos de salida del bloque message strobe
En la figura 45 se muestra la salida de los datos de la capa de aplicación. Como se puede ver, esta capa adicionó los 8 Bytes correspondientes al encabezado de la trama de aplicación, convirtió los datos de mensaje de formato ascii a hexadecimal, encapsuló la trama para enviarla a la capa de red.
En la salida de datos de la capa de red, figura 46, se encuentran los datos que debe introducir esta capa, como el campo de control, el campo de la dirección de destino que para este caso es dirección broadcast, dirección fuente, radio, el valor correspondiente al número de secuencia, la dirección IEEE y el APDU.
69
Figura 45. Datos de salida de la capa de aplicación para transmisión
Figura 46. Datos de salida de la capa de red para transmisión
En la figura 47 se muestra la salida de datos de la capa de enlace. En los datos de la consola se ilustra como este bloque anexa y encapsula los datos correspondientes al encabezado de la MAC junto a los datos obtenidos desde la trama de red.
70
Figura 47. Datos de salida de la capa de enlace para transmisión
La capa física incluye y encapsula los bytes de preámbulo, la bandera de inicio y la longitud de la trama dentro del PPDU, luego codifica y modula estos datos para enviarlos hacia la USRP, como se muestra en la figura 48. En la figura 49 se muestra el espectro del canal de transmisión de los datos de la trama que se envía, con un ancho de banda de 4 MHz.
Teniendo en cuenta la facilidad de uso de la herramienta “Message Debug”, dentro de la elaboración de los bloques se programaron las variables de entrada y salida en formato PMT, pues es el formato que lee con facilidad el bloque “Message Debug”, además permite que los bloques desarrollados sean compatibles con la mayoría de herramientas del entorno GRC.
Con estas pruebas se comprobó que cada capa cumple sus funciones correspondientes correctamente. A partir de éste ejercicio, se pudo validar el contenido de las tramas de cada una de las capas, contrastando continuamente con las especificaciones.
Figura 48. Trama PPDU modulada y codificada
71
Figura 49. Señal de espectro del canal se transmisión de los datos PPDU
Después de comprobar que cada uno de los bloques del programa cumple su tarea correctamente de acuerdo a las especificaciones, se implementó una interfaz gráfica de usuario, que se muestra en la figura 50. Esta interfaz fue elaborada dentro de GNU Radio con ayuda de las herramientas Wx GUI, a excepción de la ventana que muestra los datos de temperatura, que fue elaborada en un script de Python. Esta interfaz se diseñó para permitirle al usuario configurar parámetros como Frecuencia de operación, squelch, ganancia Front-end, tipo de modulo y mensaje de manera sencilla, sin tener que ingresar a modificar el código manualmente.
Figura 50. Interfaz gráfica de usuario.
El campo “Modulo Xbee” de la interfaz gráfica, permite seleccionar entre uno de los dos tipos de módulos que se implementaron en este proyecto, Xbee o Xbee PRO. Los campos de frecuencia de operación, squelch y ganancia Front-end se pueden modificar fácil y rápidamente mediante los deslizadores, aun si el programa se está ejecutando. El valor que se especifique en
72
los campos de ganancias se determina la ganancia de transmisión y recepción de la USRP B210. El campo mensaje permite al usuario configurar los datos de información que desee enviar a cada uno de los coordinadores Xbee. La ventana de espectro, permite visualizar el espectro de las señales en el canal de frecuencia que se esté utilizando, el espectro tiene un ancho de banda de 4 MHz. En la ventana del terminal se muestran los valores de temperatura que envían los nodos. En la ventana figure 1 se grafican los datos de temperatura con respecto al tiempo, para la visualización de los datos de temperatura que se transmiten desde los módulos Xbee, se desarrolló un script en Python que crea un cliente UDP para conectarse en el mismo puerto que el servidor configurado en capa de aplicación. Tanto el cliente como el servidor deben tener el mismo número del puerto, que en este caso es 10000. El script que se presenta en el anexo 13.5.1 identifica la procedencia de la trama gracias al encabezado y la gráfica en relación al tiempo del sistema.
La interfaz gráfica permite configurar los parámetros dinámicos que se deben modificar con mayor frecuencia. Sin embargo estos no son los únicos parámetros que se pueden configurar. Como se muestra en la figura 51 en la ventana donde se ejecutan los bloques del programa, se encuentran unas etiquetas que permiten configurar parámetros como direccionamiento IEEE fuente y destino, canal de operación PAN ID, tasa de muestreo y los parámetros que se pueden configurar en la interfaz de usuario desarrollada. Para modificar dichos campos se debe ingresar a las propiedades de la etiqueta y cambiar los datos que se encuentren dentro del campo value. En la figura se muestra el ejemplo para las propiedades del PAN ID, que está configurado para los dos diferentes nodos.
Figura 51. Ventanas de configuración de parámetros
73
8.2 RESULTADOS DEL LQI Y PER
Para evaluar el aspecto funcional del concentrador, inicialmente se hace una valoración cualitativa de la ejecución de las funcionalidades de transmisión y recepción de paquetes con los nodos de sensores. El proceso de transmisión y recepción se controla adecuadamente en cada una de las capas del modelo de comunicaciones, de tal manera que es posible transmitir y recibir un mensaje desde el concentrador hacia cada uno de los nodos y viceversa. Para lograr este objetivo fue necesario controlar parámetros como el canal de operación dentro de la banda de frecuencia de 2,4 GHz, la identificación de la red de destino con el campo “Pan ID”, el modo de entrega broadcast de la información, los valores de capa de aplicación para los módulos Xbee, y por último la información de carga útil. Todo esto bajo el marco estricto de las especificaciones de los estándares que definen el formato del paquete de datos.
A partir de las pruebas realizadas, se pudo comprobar que el concentrador es capaz de enviar información a cada uno de los nodos, configurados con diferentes canales de frecuencia y en diferentes redes; esto se puede evidenciar en la pantalla LCD de los nodos. También es capaz de recibir la información desde cada uno de los nodos y hacer una medición de la calidad del enlace y de la tasa de paquetes erróneos. El proceso de transmisión y recepción se hace de forma simultánea dentro del mismo canal de operación. No obstante, la comunicación con los nodos se realiza a partir de la conmutación entre los dos canales de operación de cada una de las redes implementadas. Esto se desarrolló así, para evidenciar la capacidad de reconfiguración de los parámetros del sistema de comunicaciones durante la ejecución en tiempo real. Es importante mencionar que también es factible realizar una implementación que opere de manera continua y simultánea, para dos canales de comunicaciones, ya que la herramienta de desarrollo presenta un sistema de transmisión y recepción 2x2. Así mismo, se podría utilizar la totalidad del ancho de banda de la tarjeta para muestrear canales de operación contiguos, teniendo presente que el ancho de banda de cada canal es de 2 MHz y se encuentran separados uno de otro 5 MHz.
La evaluación de las funcionalidades de recepción se presenta con las métricas del indicador de calidad del enlace y la tasa de errores de los paquetes recibidos como se muestra a continuación.
8.2.1 Medición de la Calidad del Enlace
El LQI (Link Quality Indicator), es un parámetro que indica la calidad del enlace con base en la identificación de los símbolos recibidos. El estándar IEEE 802.15.4 especifica que el LQI debe representarse por un valor que este en un rango entre 0x00 y 0xFF, siendo 0x00 un indicador de mala calidad y 0xFF un indicador de buena calidad de enlace. El estándar también especifica que para la recepción de un mismo paquete deben realizarse mínimo 8 mediciones del LQI. Para medir el LQI de las tramas obtenidas en este proyecto se tomaron los 8 símbolos siguientes a la bandera de inicio de trama, se registró la cantidad de chips bien identificados dentro de cada símbolo. Se compara uno a uno, los chips recibidos con los chips que están almacenados en la tabla, así si todos los datos comparados coinciden, el valor máximo es 32, este valor disminuye en la medida que los chips comparados no coincidan, este algoritmo es conocido como Distancia Hamming. Cuando no hay problemas de interferencia y los datos llegan correctamente el LQI indica un valor de 256 que se normaliza a 255 para que ocupe un espacio de 8 bits. En el caso que no se identifiquen adecuadamente algunos símbolos, el valor del indicador comenzará a reducirse. La ecuación que define el enlace de la calidad, implementada en este proyecto, se describe en la ecuación (9).
74
LQI = 255 – distancia Hamming(𝑆0, 𝑆1, … , 𝑆7) Ecuación (9)
8.2.2 Medición de la Tasa de Paquetes Erróneos
El PER (Packet Error Ratio) indica la cantidad de paquetes erróneos en la recepción. El cálculo de este parámetro se hace mediante la ecuación (10)
𝑃𝐸𝑅 =𝑃_𝑒𝑟𝑟
𝑃_𝑟𝑥 Ecuación (10)
Donde 𝑃_𝑒𝑟𝑟 indica la cantidad de paquetes erroneos, 𝑃_𝑟𝑥 representa el número total de paquetes recibidos. El estándar IEEE 802.15.4 define un PER de 1% para una relación de señal a ruido entre 5 dB y 6 dB. Para el sistema desarrollado se realizó una verificación de la validez del paquete recibido en la capa de enlace. Para esto, se comparó el campo FCS del mensaje recibido con el valor del FCS calculado. Si estos valores coinciden, el paquete es válido, de lo contrario, el paquete es erróneo.
8.3 PRUEBAS IMPLEMENTADAS
Para comprobar el funcionamiento de transmisión y recepción del sistema se variaron parámetros como la distancia y la tasa de muestreo. En la tabla 22 se muestran los resultados obtenidos en dicha prueba.
Tasa de muestreo
(MSps) Tx Rx
1 - -
2 - ok
4 ok ok
5 - -
6 ok ok
8 ok ok
16 Sobreprocesamiento
Tabla 22. Pruebas de transmisión y recepción del sistema
Debido a que las pruebas fueron exitosas en recepción para las tasas de muestreo de 2, 4, 6 y 8 MSps, las pruebas para medir el LQI y el PER se hicieron solamente para dichas tasas mientras el sistema se configuró con los parámetros que se muestran en la tabla 23.
N° paquetes Ganancia de Tx Ganancia de Rx Squelch Periodo de Tx
300 45 dB 37 dB - 50 dB 1 s
Tabla 23. Parámetros de configuración del sistema.
Estas pruebas se realizaron a 2 m, 8 m, 16 m, 32 m y 64 m como se muestra en las figura 52 y en la figura 53. Cuando se realizaron las pruebas a 64 metros, debido a los obstáculos que estaban en medio de los dispositivos, la interferencia corrompió los paquetes superando el 1% que se indica en las especificaciones.
75
Figura 52. Medidas realizadas a 8 m
Figura 53. Medidas realizadas a 32 m
76
En las figura 54 y en la figura 55 se muestra el espectro de la señal y los resultados del indicador LQI y de la medida PER. En la figura 55 se observa una cadena de ‘o’ que indican que el sistema tiene problemas de sobre procesamiento. Esto se debe a que la tasa de muestreo es muy alta y el sistema toma más tiempo en los procesos de demodulación y decodificación, de manera que cuando llegan más datos, el equipo está ocupado y estos se pierden.
Figura 54. Resultados de la señal con una tasa de muestreo a 4 Msps
Figura 55. Resultados de la señal con una tasa de muestreo a 4 Msps
Los promedios de los resultados de estas pruebas se muestran en las tablas 24 y 25. Estos promedios son graficados y se muestran en las figuras 56 y 57.
77
Tasa de muestreo Distancia
2 Msps 4Msps 6 Msps 8 Msps
2 252 241 245 250
8 253 243 253 253
16 243 246 247 245,96
32 247,21 241,08 242,01 241,08
64 242,22 248,41 241,79 243,63
Tabla 24. Resultados de la medida del LQI
Tasa de muestreo Distancia
2 Msps (%) 4Msps (%) 6 Msps (%) 8 Msps (%)
2 0 0 0 0
8 0 0 0 0
16 0 0 0 0,33
32 0,33 0,67 0,67 1,00
64 6,67 3,00 10,00 13,00
Tabla 25. Resultados de la medida del PER
Figura 56. Resultados de la medida del PER
78
Figura 57. Resultados de la medida del LQI
8.4 PROBLEMÁTICAS EN EL DESARROLLO
Para poder llevar a cabo el desarrollo de este proyecto fue necesario solucionar una serie de problemáticas técnicas y conceptuales. En esta sección, se pretende explicar brevemente cuales fueron y aportar nuestra experiencia para que sirva de apoyo a trabajos futuros.
Las herramientas de desarrollo: para la ejecución del proyecto se utilizaron diferentes herramientas de desarrollo, algunas ya utilizadas y otras totalmente nuevas. Así que, se requirió de tiempo para el aprendizaje de las mismas. GNU Radio es una herramienta de software libre que está soportada por una comunidad principalmente de investigadores y aficionados. Sus funcionalidades pueden llegar a ser muy versátiles, pero requieren de una concepción clara del manejo de lenguajes de programación como Python y C++ ambos orientados a objetos, dentro de entornos Linux. La documentación está enfocada hacia usuarios de nivel intermedio y muchas veces no es lo suficientemente completa para llevarse una idea general del funcionamiento de los bloques, así que mucho del progreso, dependerá de la capacidad de exploración que se tenga. De igual manera, el soporte está basado en la integración y relación con otros usuarios, por ende será importante aprender a buscar y realizar preguntas en foros para desarrolladores. Ésta es una comunidad que no es muy grande, pero está creciendo continuamente.
Otro elemento importante a resaltar es la capacidad de exploración que se debe desarrollar. Luego de haber abordado la etapa de aprendizaje, es frecuente encontrarse con problemas que impiden la ejecución de algún objetivo, y es importante determinar la procedencia del error, si se trata de un fallo del manejo de archivos en Linux, o de una mala línea de código de programación en C++ o Python, o si de un error en algún concepto del funcionamiento de los streams y tags en GNU Radio. Adicionalmente, hay una limitación con respecto a las herramientas de GNU Radio para la verificación de algunas funcionalidades, haciendo que muchas veces sea necesario realizar el análisis en herramientas de terceros como Octave o Matlab.
79
Implementación de los conceptos teóricos: es importante mencionar que la realización de este tipo de proyectos requiere del uso de una gran cantidad de conceptos y conocimientos del área de las comunicaciones, la telemática, el procesamiento de señales, la programación de varios lenguajes programación y uso de herramientas libres. En este sentido, se debe realizar un esfuerzo en todas estas áreas a la hora de proponer soluciones para poder ejecutar el desarrollo del proyecto.
Implementación técnica: Uno de los problemas fue el manejo de datos en GNU Radio. Lo primero que hay que decir es que GNU Radio implementa dos formas para manejar la información, los Stream que son las ráfagas de datos que se trasmiten de bloque a bloque en formato complejo, float o byte entre otros. El la funcionalidad de estos bloques se encuentra dentro de la función work() o general_work() de cada uno. Por otra parte, también existen los bloques que generan mensajes o etiquetas que se pueden agregar a los Streams o no. Estas etiquetas o Tags se utilizan como metadatos que sirven de información para el control de flujo de los datos. Ahora bien, estos datos utilizan un tipo de dato poco utilizado que se conoce como PMT (Polimorfic type), dentro de los cuales existen variaciones entre ellos como los diccionarios que es un concepto de Python o los BLOBS (Binary Large Objects). Hecho que hay que tener presente cuando se diseñan los bloques que utilicen los Tags como fuente principal de información.
Otro elemento a mencionar, fue la dificultad para verificar el contenido de la capa de aplicación de los módulos Xbee, ya que ésta información no es publicada por el fabricante. También hubo inconvenientes a la hora de transmitir los mensajes hacia los módulos Xbee, debido a que no se estaba generando adecuadamente el campo FCS que se usa para validar la integridad del paquete y el Xbee no aceptaba la información.
80
9. CONCLUSIONES
A partir de la investigación realizada sobre el estado del arte de las redes de sensores y la radio definida por software, se evidenció cómo estas tecnologías tienen un mayor uso y una mayor importancia en diferentes entornos de aplicación en la vida cotidiana. Se encontró que algunas de las problemáticas de las redes de sensores como eficiencia, heterogeneidad, robustez, escalabilidad y flexibilidad, pueden solucionarse mediante las funcionalidades que ofrece la radio definida por software.
Se identificaron las posibles herramientas de software y hardware, que permiten implementar funcionalidades de radio definida por software, y así llevar a cabo el diseño e implementación del dispositivo concentrador para redes de sensores heterogéneas.
Se identificó, analizó e implementó mediante software cada capa para el sistema de comunicaciones estandarizado ZigBee, que se basa en la arquitectura del modelo OSI. Cada capa fue implementada en un bloque de manera estructurada, tanto para transmisión como para recepción, permitiendo así la flexibilidad y escalabilidad del sistema desarrollado.
Se demostró que es viable implementar un sistema de comunicaciones estandarizado, a partir de las funcionalidades de radio definida por software. De manera que fue posible controlar parámetros como la frecuencia de operación, la modulación O-QPSK, la codificación DSSS, el identificador de la red (PAN ID), las direcciones de origen y destino del mensaje, así como el tipo de mensaje y la información que se envía a los nodos.
Los bloques diseñados fueron probados en un entorno de redes de sensores reales en condiciones controlas. Se validó la funcionalidad de los procesos de transmisión y recepción de los paquetes entre los nodos de sensores y el concentrador. Adicionalmente, se registraron las mediciones del indicador de calidad del enlace LQI, y de la tasa de paquetes erróneos PER. Realizadas estas pruebas, se concluye que el sistema funciona adecuadamente y es capaz de comunicarse con un equipo comercial que implemente el estándar ZigBee.
81
10. APORTES
10.1 CARÁCTER INNOVADOR Y FUNCIONAL DE LA PROPUESTA
En la revisión del estado del arte se evidenció, cómo las redes de sensores cobran mayor importancia dentro de las aplicaciones de uso cotidiano en diferentes campos de trabajo. Sin embargo, dichas aplicaciones siguen presentando una serie de problemáticas. En esta sección también se muestra como la radio definida por software permite obtener funcionalidades de escalabilidad, flexibilidad, adaptabilidad e interoperabilidad, de manera que la implementación de estos conceptos dentro de las redes de sensores permitiría solucionar muchas de estas problemáticas. Por eso este trabajo busca demostrar que es posible implementar sistemas estandarizados con herramientas hardware y software disponibles, diseñadas para desarrollo de radio definida por software.
En la sección de trabajos relacionados se indica como algunos autores han abordado esta temática implementando funcionalidades que se limitan a la capa física y capa de enlace para el módulo Telos B-mote. En este trabajo se estudian, analizan e implementan las 4 capas de la arquitectura del protocolo ZigBee para el módulo de comunicaciones Xbee S2. La implementación de dichas capas se elaboran, cada una en un bloque diferente y de forma separada entre la transmisión y la recepción para cada una de las capas, de manera que sea más fácil realizar la interpretación y el seguimiento de cada una de ellas.
El desarrollo de este trabajo se fundamentó en la realización de cinco principales tareas:
Estudio de las tecnologías de software y hardware disponibles, de sus alcances y funcionalidades para determinar cuáles eran las más adecuadas para operar como plataforma base en éste desarrollado.
Análisis de los dispositivos que se implementan para la red de sensores y un profundo estudio y comprensión de los estándares que los regulan.
Estudio y aprendizaje del entorno de desarrollo GNU radio y de los lenguajes de programación como Python y C++ que permiten el diseño y ejecución de bloques personalizados.
Elaboración de bloques que cumplen funcionalidades de cada una de las capas del protocolo ZigBee para la transmisión y recepción de datos.
Validación del correcto funcionamiento de cada uno de los bloques y del sistema en su totalidad.
10.2 GENERACIÓN DE CONOCIMIENTO
Este trabajo fue propuesto elaborado y supervisado por integrantes del grupo de investigación LIMER de la Universidad Distrital Francisco José de Caldas. Con este proyecto se busca crear y fortalecer una nueva línea de investigación, por consiguiente se espera que este trabajo sirva como base para futuros proyectos. En este orden de ideas, la documentación que aquí se realiza es lo más específica, clara y detallada posible con el objetivo de transmitir los conocimientos adquiridos en esta experiencia de manera precisa. Así, las personas que se involucren en esta área, podrán hacerlo de forma rápida y podrán escalar en los desarrollos realizados.
82
Para la realización de este trabajo se exploraron herramientas de desarrollo basadas en software libre, con el fin de impulsar su uso dentro del ámbito académico con fines colaborativos. Las librerías desarrolladas para GNU Radio se encuentran disponibles en un repositorio público de github en la siguiente dirección:
https://github.com/EsperanzaSegura/gr-WSN
La radio definida por software es una temática nueva que está tomando fuerza dentro del entorno académico e industrial y se alimenta de los aportes que realice la comunidad global. Así que está abierta a la investigación e implementación de nuevos desarrollos en diversos campos de aplicación. Uno de los propósitos de esta implementación es la exploración de nuevas aplicaciones para la radio definida por software, así que se espera haber contribuido en el proceso de crecimiento de esta temática y poder colaborar con todos los proyectos que puedan surgir a partir de este, dentro de la comunidad nacional e internacional.
10.3 IMPACTOS
El principal impacto de este trabajo es la generación de conocimiento. La realización de este proyecto permitió fortalecer el área de investigación y desarrollo de los autores y del grupo de investigación. Con este trabajo se permitió construir una base sólida dentro del análisis del protocolo 802.15.4 y ZigBee, ambos muy importantes y utilizados en múltiples aplicaciones de diferentes entornos. Se espera poder publicar los resultados de este proyecto para beneficio de la comunidad académica y que el continuo desarrollo e investigación en esta área permita obtener un hardware de implementación a un menor costo, un software mejor documentado y con una amplia variedad de herramientas que permitan implementaciones comerciales de bajo costo, alto rendimiento, robustez, escalabilidad y que permita la convergencia de los diferentes estándares de comunicación que emplean los diferentes dispositivos.
Los proyectos de implementación de radio definida por software permiten aplicar una gran variedad de conocimientos en áreas de las comunicaciones, el procesamiento digital de señales y el manejo de herramientas de software libre. Desde una perspectiva personal consideramos que estas herramientas deberían ser utilizadas dentro de la formación académica como elemento de refuerzo de los conceptos teóricos, permitiendo a los estudiantes comprender e implementar los conceptos de las áreas ya mencionadas.
Durante la realización de este proyecto, se evidenció la vulnerabilidad que persiste en las redes inalámbricas. Con el uso de las herramientas adecuadas se puede extraer información de una red e incluso suplantar los dispositivos que integran la red sin ser percibidos. Este hecho nos hace tomar conciencia de la importancia de implementar las funciones de seguridad dentro de una red inalámbrica para proteger la información. Por otra parte, estas herramientas podrían utilizarse para incrementar los niveles de seguridad de una red inalámbrica.
La implementación de la radio definida por software permite reducir la cantidad de basura electrónica generada, pues las herramientas de hardware que la integran son reutilizables y se pueden actualizar para adaptarse a nuevos esquemas y nuevos requerimientos mediante el software, evitando el desuso de la herramienta. Cabe resaltar que la mayoría de los dispositivos actuales tiene una cantidad de funcionalidades limitadas, esto impide la reutilización, de los sistemas acortando su tiempo de vida útil. Si las nuevas tecnologías implementaran los
83
conceptos de la tecnología RDS, los dispositivos podrían realizar diferentes tareas y ser reutilizables disminuyendo notoriamente la cantidad de dispositivos fabricados y por ende desechados.
84
11. TRABAJO FUTURO
El aumento en la demanda de redes de sensores inalámbricas, exige una continua evolución de las tecnologías de desarrollo. El análisis y la implementación del protocolo de los dispositivos ZigBee realizados facilitan el estudio, análisis e implementación de otros estándares de la industria en el campo de las redes de sensores, tal como WirlessHart, 6LowPAN, Zwave entre otros. Los cuales implementan la misma capa física y la misma capa de enlace con algunas particularidades.
Este trabajo implementa la transmisión y recepción del paquete de datos. Un trabajo complementario a este sería el desarrollo y funcionalidad de las tramas que permiten el control de acceso al medio de los módulos ZigBee, tales como trama Beacon, trama de reconocimiento y trama de comando.
Este proyecto impulsa el desarrollo de la tecnología de radio definida por software de manera que se puedan implementar tanto en las redes de sensores como en otras tecnologías de comunicación. Por tal motivo el trabajo realizado puede servir de base para la creación de bloques funcionales en Python y C++ que posteriormente se podrán implementar en otros proyectos.
La implementación de este trabajo permitió la integración de gran parte de los conocimientos, adquiridos a lo largo de la carrera. Se propone que el uso de las herramientas aquí utilizadas se lleve a los espacios académicos, para que la comunidad universitaria pueda ir tomando parte del trabajo colaborativo en el desarrollo de esta temática y lleve a la práctica muchos de los conceptos teóricos reforzando el proceso de aprendizaje.
En el área de las comunicaciones, los parámetros de robustez y seguridad son temáticas muy importantes. Para trabajos futuros se podrían desarrollar funcionalidades más robustas en cuanto a las técnicas de acceso al medio y seguridad, por ejemplo.
85
12. BIBLIOGRAFÍA
[1] A. M. Mousa, “Prospective of fifth generation mobile communications,” International Journal of Next-Generation Networks (IJNGN), vol. 4, no. 3, pp. 1-30, 2012.
[2] L. Mainetti, L. Patrono, and A. Vilei, "Evolution of wireless sensor networks towards the internet of things: A survey." pp. 1-6.
[3] P. Ferrari, A. Flammini, and E. Sisinni, “New Architecture for a Wireless Smart Sensor Based on a Software-Defined Radio,” Instrumentation and Measurement, IEEE Transactions on, vol. 60, no. 6, pp. 2133 - 2141, Junio, 2011.
[4] J. Mitola, “The software radio architecture,” Communications Magazine, IEEE, vol. 33, no. 5, pp. 26 - 38, May, 1995.
[5] J. R. Humphries, Malocha, D., "Software Defned Radio for Passive Sensor Interrogation." pp. 270-273.
[6] J. Mitola III, “Software radios: Survey, critical evaluation and future directions,” Aerospace and Electronic Systems Magazine, IEEE, vol. 8, no. 4, pp. 25-36, 1993.
[7] J. Mitola, “The software radio architecture,” Communications Magazine, IEEE, vol. 33, no. 5, pp. 26-38, 1995.
[8] A. Galvis, C. Ceballos, L. De Sanctis, A. Moreno, and D. Posada, “SDR+ MIH: la fórmula para lograr la total coexistencia e interoperabilidad en el mundo inalámbrico,” Investigaciones Aplicadas, vol. 1, no. 1, pp. 28-38, 2007.
[9] H. Arslan, "Cognitive radio, software defined radio, and adaptive wireless systems," pp. 111-112: Springer, 2007.
[10] J. H. A. Rentería, and A. N. Cadavid, “Radio cognitiva–Estado del arte,” Sistemas & Telemática, vol. 9, no. 16, pp. 31-53, 2011.
[11] J. R. Machado-Fernández, “Software Defined Radio: Basic Principles and Applications,” FACULTAD DE INGENIERÍA, vol. 24, no. 38, pp. 79-96, 2014.
[12] B. Nunes, M. Mendonca, X. Nguyen, K. Obraczka, and T. Turletti, “A survey of software-defined networking: Past, present, and future of programmable networks,” 2014.
[13] M. A. Mahmood, W. K. Seah, and I. Welch, “Reliability in Wireless Sensor Networks: A Survey and Challenges Ahead,” Computer Networks, 2015.
[14] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless sensor network survey,” Computer networks, vol. 52, no. 12, pp. 2292-2330, 2008.
[15] A. Z. Abbasi, N. Islam, and Z. A. Shaikh, “A review of wireless sensors and networks' applications in agriculture,” Computer Standards & Interfaces, vol. 36, no. 2, pp. 263-270, 2014.
[16] U. Prathap, D. Shenoy, K. Venugopal, and L. Patnaik, "Wireless sensor networks applications and routing protocols: survey and research challenges." pp. 49-56.
[17] C. Corporation. "Home Automation and Smart Home Systems," 2015; [En linea] Disponible: http://www.control4.com. [Visto :10 - Abril - 2015].
[18] M. Chen, J. Wan, S. González, X. Liao, and V. C. Leung, “A survey of recent developments in home M2M networks,” Communications Surveys & Tutorials, IEEE, vol. 16, no. 1, pp. 98-114, 2014.
[19] G. De Silva, L. De Silva, P. Ishara, M. Kumara, and T. Ginige, "SmartBee; Multichannel Access ZigBee Gateway with Plug and Play Device Interface for Smart Home/Office Automation." pp. 251-256.
[20] K. Gill, S.-H. Yang, F. Yao, and X. Lu, “A zigbee-based home automation system,” Consumer Electronics, IEEE Transactions on, vol. 55, no. 2, pp. 422-430, 2009.
[21] W. Wang, Y.-X. Zou, G. Shi, and Y. Zhu, "A web service based gateway architecture for wireless sensor networks." pp. 1160-1163.
[22] F. Ding, G. Song, J. Li, and A. Song, "A ZigBee Based Mesh Network for Home Control System." pp. 744-748.
[23] I.-K. Hwang, D.-s. Lee, and J.-w. Baek, “Home network configuring scheme for all electric appliances using ZigBee-based integrated remote controller,” Consumer Electronics, IEEE Transactions on, vol. 55, no. 3, pp. 1300-1307, 2009.
86
[24] Y.-G. Ha, “Dynamic integration of zigbee home networks into home gateways using OSGI service registry,” Consumer Electronics, IEEE Transactions on, vol. 55, no. 2, pp. 470-476, 2009.
[25] B. Shishkin, D. Pfeil, D. Nguyen, K. Wanuga, J. Chacko, J. Johnson, N. Kandasamy, T. P. Kurzweg, and K. R. Dandekar, "SDC testbed: Software defined communications testbed for wireless radio and optical networking." pp. 300-306.
[26] F. A. Urbano-Molano, “Redes de Sensores Inalámbricos Aplicadas a Optimización en Agricultura de Precisión para Cultivos de Café en Colombia,” Journal de Ciencia e Ingenierıa, vol. 5, no. 1, pp. 46-52, 2013.
[27] M. Damas, A. Prados, F. Gómez, and G. Olivares, “HidroBus® system: fieldbus for integrated management of extensive areas of irrigated land,” Microprocessors and Microsystems, vol. 25, no. 3, pp. 177-184, 2001.
[28] W. Xinzhong, and W. Xi, "Design and test of variable-rate fertilization control device of precision planter for soybean." pp. 95-98.
[29] J. He, J. Wang, D. He, J. Dong, and Y. Wang, “The design and implementation of an integrated optimal fertilization decision support system,” Mathematical and Computer Modelling, vol. 54, no. 3, pp. 1167-1174, 2011.
[30] Y. Hou, and S. Chen, “Summarization of fertilization model research,” Chinese Journal of Soil Science, vol. 35, no. 4, pp. 493-501, 2004.
[31] E.-C. Oerke, R. Gerhards, G. Menz, and R. A. Sikora, Precision Crop Protection-The challenge and use of heterogeneity: Springer, 2010.
[32] R. Beckwith, D. Teibel, and P. Bowen, "Report from the field: results from an agricultural wireless sensor network." pp. 471-478.
[33] C. Serodio, J. B. Cunha, R. Morais, C. Couto, and J. Monteiro, “A networked platform for agricultural management systems,” Computers and Electronics in Agriculture, vol. 31, no. 1, pp. 75-90, 2001.
[34] D. Kolokotsa, G. Saridakis, K. Dalamagkidis, S. Dolianitis, and I. Kaliakatsos, “Development of an intelligent indoor environment and energy management system for greenhouses,” Energy Conversion and Management, vol. 51, no. 1, pp. 155-168, 2010.
[35] A. Flammini, P. Ferrari, D. Marioli, E. Sisinni, and A. Taroni, "Sensor networks for industrial applications." pp. 1-15.
[36] L. Krishnamurthy, R. Adler, P. Buonadonna, J. Chhabra, M. Flanigan, N. Kushalnagar, L. Nachman, and M. Yarvis, "Design and deployment of industrial sensor networks: experiences from a semiconductor plant and the north sea." pp. 64-75.
[37] I. Johnstone, J. Nicholson, B. Shehzad, and J. Slipp, "Experiences from a wireless sensor network deployment in a petroleum environment." pp. 382-387.
[38] A. Lehto, J. Nummela, L. Ukkonen, L. Sydanheimo, and M. Kivikoski, “Passive UHF RFID in paper industry: Challenges, benefits and the application environment,” Automation Science and Engineering, IEEE Transactions on, vol. 6, no. 1, pp. 66-79, 2009.
[39] A. Flammini, P. Ferrari, D. Marioli, E. Sisinni, and A. Taroni, “Wired and wireless sensor networks for industrial applications,” Microelectronics Journal, vol. 40, no. 9, pp. 1322-1336, 2009.
[40] V. C. Gungor, and G. P. Hancke, “Industrial wireless sensor networks: Challenges, design principles, and technical approaches,” Industrial Electronics, IEEE Transactions on, vol. 56, no. 10, pp. 4258-4265, 2009.
[41] C. R. Baker, K. Armijo, S. Belka, M. Benhabib, V. Bhargava, N. Burkhart, A. Der Minassians, G. Dervisoglu, L. Gutnik, and M. B. Haick, "Wireless sensor networks for home health care." pp. 832-837.
[42] A. Johansson, W. Shen, and Y. Xu, "An ANT based wireless body sensor biofeedback network for medical e-health care." pp. 1-5.
[43] H. Huo, Y. Xu, H. Yan, S. Mubeen, and H. Zhang, "An elderly health care system using wireless sensor networks at home." pp. 158-163.
[44] G. Werner-Allen, K. Lorincz, M. Ruiz, O. Marcillo, J. Johnson, J. Lees, and M. Welsh, “Deploying a wireless sensor network on an active volcano,” Internet Computing, IEEE, vol. 10, no. 2, pp. 18-25, 2006.
87
[45] G. Tolle, J. Polastre, R. Szewczyk, D. Culler, N. Turner, K. Tu, S. Burgess, T. Dawson, P. Buonadonna, and D. Gay, "A macroscope in the redwoods." pp. 51-63.
[46] I. Vasilescu, K. Kotay, D. Rus, M. Dunbabin, and P. Corke, "Data collection, storage, and retrieval with an underwater sensor network." pp. 154-165.
[47] J. Heidemann, W. Ye, J. Wills, A. Syed, and Y. Li, "Research challenges and applications for underwater sensor networking." pp. 228-235.
[48] E. Cayirci, H. Tezcan, Y. Dogan, and V. Coskun, “Wireless sensor networks for underwater survelliance systems,” Ad Hoc Networks, vol. 4, no. 4, pp. 431-446, 2006.
[49] V. C. Gungor, B. Lu, and G. P. Hancke, “Opportunities and challenges of wireless sensor networks in smart grid,” Industrial Electronics, IEEE Transactions on, vol. 57, no. 10, pp. 3557-3564, 2010.
[50] M. EL Brak, S. EL Brak, M. Essaaidi, and D. Benhaddou, "Wireless Sensor Network applications in smart grid." pp. 587-592.
[51] M. L. Sichitiu, and M. Kihl, “Inter-vehicle communication systems: a survey,” Communications Surveys & Tutorials, IEEE, vol. 10, no. 2, pp. 88-105, 2008.
[52] S. Edwards, G. Evans, P. Blythe, D. Brennan, and K. Selvarajah, “Wireless technology applications to enhance traveller safety,” Intelligent Transport Systems, IET, vol. 6, no. 3, pp. 328-335, 2012.
[53] Advanticsys. "Advanticsys, products, wireless sensor networks," 2015; [En linea] Disponible: http://www.advanticsys.com/shop/wireless-sensor-networks-802154-mote-modules-c-7_3.html. [Visto :10 - Abril - 2015].
[54] T. Schmid, "Gnu radio 802.15. 4 en-and decoding," Department of Electrical Engineering, University of California, 2006.
[55] B. Bloessl, C. Leitner, F. Dressler, and C. Sommer, “A GNU Radio-based IEEE 802.15. 4 Testbed,” 12. GI/ITG FACHGESPRÄCH SENSORNETZE, pp. 37, 2013.
[56] M. Fähnle, “Software-Defined Radio with GNU Radio and USRP/2 hardware frontend: setup and FM/GSM applications,” Hochschule Ulm University of Applied Sciences, Institute of Communication Technology, 2010.
[57] Y. Li, “Integrating Software Defined Radio into Wireless Sensor Network.” [58] J. S. Nielsen, and B. Freund-Hansen, “SDR Platform for Wireless Cooperative Protocols,” Thesis
accepted and used in Fall 2009 & Spring, 2010. [59] J.-O. Jeong, “Hybrid FPGA and GPP Implementation of IEEE 802.15. 4 Physical Layer,” Virginia
Polytechnic Institute and State University, 2012. [60] P. Ferrari, A. Flammini, and E. Sisinni, “New architecture for a wireless smart sensor based on a
software-defined radio,” Instrumentation and Measurement, IEEE Transactions on, vol. 60, no. 6, pp. 2133-2141, 2011.
[61] Z. Alliance, "Zigbee specification," 2006. [62] S. Farahani, ZigBee wireless networks and transceivers: newnes, 2011. [63] G. R. Companion. "GNU Radio Companion," 2015; [En linea] Disponible:
http://www.gnuradio.org. [Visto :10 - Marzo - 2015]. [64] G. R. Companion. "Out-of-tree modules," 2015; [En linea] Disponible:
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules. [Visto :10 - Marzo - 2015].
[65] E. U. Guide, “EM250 User Guide,” 2012. [66] K. H. Mueller, and M. Müller, “Timing recovery in digital synchronous data receivers,”
Communications, IEEE Transactions on, vol. 24, no. 5, pp. 516-531, 1976. [67] J. Notor, A. Caviglia, and G. Levy, “CMOS RFIC architectures for IEEE 802.15. 4 networks,” Cadence
Design Systems, Inc, vol. 41, 2003.
88
13. ANEXOS
13.1 CÓDIGO NODOS XBEE
Código desarrollado para cada uno de los nodos con módulos Xbee con microcontrolador MSP4302553 mediante Code Composer Studio. ////////////////////////////////////////////////////////////////////////////// // LCD Xbee, ADC nodo Rx ISR & Time ISR // Miguel Angel Sastoque y Claudia Segura ////////////////////////////////////////////////////////////////////////////// #include <msp430.h> #include <msp430g2553.h> //------------// // Definiciones // Pines LCD // #define LCD_DIR P2DIR #define LCD_OUT P2OUT #define LCD_IN P2IN #define LCD_D4 BIT0 #define LCD_D5 BIT1 #define LCD_D6 BIT2 #define LCD_D7 BIT3 #define LCD_RS BIT4 #define LCD_EN BIT5 #define LCD_RW BIT6 #define READ LCD_OUT = LCD_OUT | LCD_RW // define WR high #define WRITE LCD_OUT = LCD_OUT &(~LCD_RW) // define WR low #define DATA LCD_OUT = LCD_OUT | LCD_RS // define RS high #define COMMAND LCD_OUT = LCD_OUT &(~LCD_RS) // define RS low // Definicion de Comandos LCD // #define CLEAR_DIS 0x01 //0b00000001 //Borrar display #define MOD_SET 0x06 //0b00000110 //1,INCREMENTAR->1, NO DESPLAZA->0 #define DIS_ON 0x0E //0b00001110 //1,Display ON->1, cursor Off->0, cursor Estático->0 #define FUN_SET 0x28 //0b00101000 //1,B4=0->DATOS 4 BIT,B3=1-> HABILITA 2 LINEAS, B2=0-> MATIZ 5X7 ,X,X #define LINE1 0x80 //0b10000000 //UBICAR CURSOR LINEA 1 #define LINE2 0xC0 //0b11000000 //UBICAR CURSOR LINEA 2 //------------// // Variables // volatile long cref; volatile int pos_l2; //-------------// // Protptipos // void lcd_write(void); void lcd_read(void); void lcd_busy(void); void lcd_command(unsigned char); void lcd_data(unsigned char); void lcd_string(char *); void lcd_init(void); void lcd_uart(int); void uart_tx_string(char []); //--------------------// // Programa Principal // int main(void)
89
{ WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer // Configura Reloj MCLK a 1MHz BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; // Config Timer CCTL0 = CCIE; // CCR0 Interrupcion Habilitada TACTL = TASSEL_2 + MC_1 + ID_3; // SMCLK/8, upmode,/8.TCLK = 8us ciclo --> 8*12500 = 100ms CCR0 = 12500; // Valor Max 65535 ---> 100ms // Config ADC P1SEL |= BIT0; //ADC Input pin P1.0 ADC10CTL1 = INCH_0 + ADC10DIV_2; //Comience CH0, MCLK, /2, 1CH conversion, S&H source ADC10 ADC10CTL0 = SREF_0 + ADC10SHT_3 +ADC10ON + ADC10IE; //ref vss-vcc, 4ADCclk S&H, Adc ON, ADC int on ADC10AE0 |= BIT0; // Bit P1.0 // Config UART P1SEL |= BIT1 + BIT2; //Set P1.1 and P1.2 to RX to TX P1SEL2 |= BIT1 + BIT2; UCA0CTL1 |= UCSSEL_2; // SMCLK UCA0BR0 = 0x68; // 1MHz 9600 UCA0BR1 = 0x00; // 1MHz 9600 UCA0MCTL = UCBRS_1; //Modulation UCA0CTL1 &= ~UCSWRST; // **Comienza USCI** UC0IE |= UCA0RXIE; // Enable USCI_A0 RX interrupt // Activar Pines 2.6 y 2.7 como salidas P2SEL &= ~(BIT6 + BIT7); P2DIR |= BIT6 + BIT7; P2OUT &= ~(BIT6 + BIT7); //2.6 y 2.7 = 0 // Valores iniciales cref = 0; pos_l2 = 0; // Inicializar LCD lcd_init(); lcd_command(LINE1); lcd_string("Temp: "); lcd_data(0xDF); lcd_string("C"); __enable_interrupt(); // Activa interrupciones for(;;){ } } //----------------// // Funciones LCD // // Flanco de bajada Enable --> Write void lcd_write(void) { LCD_OUT |= LCD_EN; //enable=1; __delay_cycles(100); //100us LCD_OUT &=~ LCD_EN; //enable=0; } // Flanco de subida Enable --> Read void lcd_read(void) { LCD_OUT &=~ LCD_EN; //enable=0; __delay_cycles(100); //100us LCD_OUT |= LCD_EN; //enable=1; }
90
// Verificar si LCD está Ocupada void lcd_busy(void) { LCD_DIR &= ~(LCD_D7); //LCD_D7 entrada while((LCD_IN & LCD_D7)==1) // Mientras el D7==1 { lcd_read(); //Lectura } LCD_DIR |= LCD_D7; //LCD_D7 salida } // Envio de comando >>4 y enmascaramiento depende de los bits P2.(0,1,2,3) void lcd_command(unsigned char cmd) { lcd_busy(); WRITE; COMMAND; LCD_OUT = (LCD_OUT & 0xF0)|((cmd>>4) & 0x0F); // Parte alta lcd_write(); // Escritura LCD_OUT = (LCD_OUT & 0xF0)|(cmd & 0x0F); // Parte baja lcd_write(); // Escritura } // Envio de dato. >>4 y enmascaramiento depende de los bits P2.(0,1,2,3) void lcd_data(unsigned char cmd) { lcd_busy(); WRITE; DATA; LCD_OUT = (LCD_OUT & 0xF0)|((cmd>>4) & 0x0F); // Parte alta lcd_write(); // Escritura LCD_OUT = (LCD_OUT & 0xF0)|(cmd & 0x0F); // Parte bana lcd_write(); // Escritura } // Envio de string void lcd_string(char *s) { while(*s) { lcd_data(*s); s++; } } void lcd_init(void) { LCD_DIR |= 0xFF; LCD_OUT &= ~(LCD_RS + LCD_RW + LCD_EN + LCD_D4 + LCD_D5 + LCD_D6 + LCD_D7); __delay_cycles(15000); //15ms LCD_OUT = LCD_D5 + LCD_D4; lcd_write(); __delay_cycles(4100); //4.1ms LCD_OUT = LCD_D5 + LCD_D4; lcd_write(); __delay_cycles(100); //100us LCD_OUT = LCD_D5 + LCD_D4; lcd_write(); __delay_cycles(100); //100us LCD_OUT = LCD_D5; lcd_write(); __delay_cycles(100); //100us LCD_OUT = LCD_D5; lcd_write(); __delay_cycles(4100); //4.1ms----
91
LCD_OUT = LCD_D7; lcd_write(); __delay_cycles(4100); //4.1ms LCD_OUT = 0x00; lcd_write(); __delay_cycles(4100); //4.1ms LCD_OUT = LCD_D7 + LCD_D6 + LCD_D5; lcd_write(); } // Envio de string void uart_tx_string(char s[]) { int i=0; while(s[i] != 0x13) { while (!(IFG2 & UCA0TXIFG)); // Espera hasta Buff TX listo UCA0TXBUF = s[i]; // Transmitir i++; } } // Envio Entero por UART y por LCD void lcd_uart(int a) { int num_d, num_u,num_c; int res; num_d = a/100; res = a%100; num_u = res/10; num_c = res%10; lcd_data(0x30+num_d); lcd_data(0x30+num_u); lcd_string(","); lcd_data(0x30+num_c); char tx_buff[] = {0x01,0x30+num_d,0x30+num_u,0x2C,0x30+num_c,0x10,0x13}; uart_tx_string( tx_buff); } //----------------------------------------------------// //----------------- INTERRUPCIONES -------------------// //----------------------------------------------------// // Interrupcion RX #pragma vector=USCIAB0RX_VECTOR __interrupt void USCI0RX_ISR(void) { if (pos_l2>15) { pos_l2=0; } char rx_data = UCA0RXBUF; lcd_command(LINE2+pos_l2); lcd_data(rx_data); pos_l2++; } // ADC10 interrupt service routine #pragma vector=ADC10_VECTOR __interrupt void ADC10_ISR(void) { int ValADC = ADC10MEM; int temp =(ValADC*33)/10; lcd_command(LINE1+5); lcd_uart(temp); P2OUT ^= BIT7;
92
} // Timer A0 interrupt service routine #pragma vector = TIMER0_A0_VECTOR //Interrupcion cada 100ms __interrupt void Timer_A (void) { if(cref >= 40) //Contador N*100ms -->40-->4s { ADC10CTL0 |= ENC | ADC10SC; // Comienzo Conversión cref = 0; } cref++; } ////////////////////////////////////////////////////////////////////////////
13.2 CÓDIGOS CAPA DE APLICACIÓN XBEE EN GNU RADIO
13.2.1 XML Rx App
<?xml version="1.0"?> <block> <name>Rx App: Xbee</name> <key>RSI_rx_app_xbee</key> <category>RSI</category> <import>import RSI</import> <make>RSI.rx_app_xbee()</make> <sink> <name>in</name> <type>message</type> </sink> <source> <name>out</name> <type>message</type> </source> <doc> Descripción: Desempaqueta la capa de Aplicación utilizada por los módulos Xbee S2 con el transciever EM250 de Digi in: [pmt pair] desde "Rx Nwk" out: [pmt pair] a "MSJ" Parámetros: Ninguno </doc> </block>
13.2.2 Python Rx App
""" Módulo Rx App Xbee - Miguel Sastoque & Claudia Segura """ import numpy as np import string import pmt import struct from gnuradio import gr from gnuradio import digital
93
class rx_app_xbee(gr.sync_block): def __init__(self): gr.sync_block.__init__(self, name="rx_app_xbee", in_sig=[], out_sig=[]) self.message_port_register_in(pmt.intern("in")) self.message_port_register_out(pmt.intern("out")) self.set_msg_handler(pmt.intern("in"), self.deframe_MSJ) #Funcion def deframe_MSJ(self,msg_pmt): if pmt.is_blob(msg_pmt): blob = msg_pmt #print "is blob" elif pmt.is_pair(msg_pmt): blob = pmt.cdr(msg_pmt) #print "is pair" else: print "Formato desconocido" return data_np = pmt.to_python(blob) #numpy.ndarray data_py = data_np.tolist() #python list #print "Paquete",data_py,data_py.__class__ index = 8 del data_py[:index] # FC (1),DesEP(1),Cluster(2),Profile(2),SourEP(1),Counter(1) #print "DEPACKED-->",data_p # Crea un PMT vacio: send_pmt = pmt.make_u8vector(len(data_py), ord(' ')) # Copiar caracteres al u8vector: for i in range(len(data_py)): pmt.u8vector_set(send_pmt, i, data_py[i]) # Send the message: self.message_port_pub(pmt.intern('out'), pmt.cons(pmt.PMT_NIL, send_pmt))
13.2.3 XML Tx App
<?xml version="1.0"?> <block> <name>Tx App: Xbee</name> <key>RSI_tx_app_xbee</key> <category>RSI</category> <import>import RSI</import> <make>RSI.tx_app_xbee()</make> <sink> <name>in</name> <type>message</type> </sink> <source> <name>out</name> <type>message</type> </source> <doc> Descripción: Adiciona capa de aplicación utiliziada en xbee s2
94
in: [pmt symbol] desde "Message Debug" out: [pmt pair] a "Tx NWK" Parámetros: Ninguno </doc> </block>
13.2.4 Python Tx App
""" Módulo Tx App Xbee - Miguel Sastoque & Claudia Segura """ import string import pmt import struct from gnuradio import gr from gnuradio import digital # Variable Global count_app = [0] class tx_app_xbee(gr.sync_block): def __init__(self): gr.sync_block.__init__(self, name="tx_app_xbee", in_sig=[], out_sig=[]) self.message_port_register_in(pmt.intern("in")) self.message_port_register_out(pmt.intern("out")) self.set_msg_handler(pmt.intern("in"), self.make_APDU) #Funcion make_APDU def make_APDU(self,msg_pmt): # Toma Pmt Symbol a String y luego a list msg_pmt = pmt.symbol_to_string(msg_pmt) msg = [ord(c) for c in msg_pmt] global count_app count_app[0] = count_app[0] +1 if count_app[0] > 254: count_app[0] = 0 Src_EP = [0xE8] # Source endpoint Profile = [0x05,0xC1] # Profile ID LSB-MSB Cluster = [0x11,0x00] # Cluster ID LSB-MSB Dst_EP = [0xE8] # Destination endpoint FC_A = [0x04] # Frame Control APP APDU = FC_A + Dst_EP + Cluster + Profile + Src_EP + count_app + msg # Crea PMT vacio send_pmt = pmt.make_u8vector(len(APDU), ord(' ')) # Copia Caracteres a u8vector: for i in range(len(APDU)): pmt.u8vector_set(send_pmt, i, APDU[i]) # Envia mensaje: self.message_port_pub(pmt.intern('out'), pmt.cons(pmt.PMT_NIL, send_pmt))
95
13.3 CÓDIGOS CAPA DE RED XBEE EN GNU RADIO
13.3.1 XML Rx Nwk
<?xml version="1.0"?> <block> <name>Rx Nwk: ZigBee</name> <key>RSI_rx_nwk_zigbee</key> <category>RSI</category> <import>import RSI</import> <make>RSI.rx_nwk_zigbee()</make> <sink> <name>in</name> <type>message</type> </sink> <source> <name>out</name> <type>message</type> </source> <doc> Descripción: Desempaqueta la capa de Red especificada en el estandar ZigBee 2006. in: [pmt pair] desde "Rx Mac" out: [pmt pair] a "Rx App" Parámetros: Ninguno </doc> </block>
13.3.2 Python Rx Nwk
""" Módulo Rx Nwk Zigbee- Miguel Sastoque & Claudia Segura """ import numpy as np import string import pmt import struct from gnuradio import gr from gnuradio import digital class rx_nwk_zigbee(gr.sync_block): def __init__(self): gr.sync_block.__init__(self, name="rx_nwk_zigbee", in_sig=[], out_sig=[]) self.message_port_register_in(pmt.intern("in")) self.message_port_register_out(pmt.intern("out")) self.set_msg_handler(pmt.intern("in"), self.deframe_APDU) #Funcion def deframe_APDU(self,msg_pmt):
96
if pmt.is_blob(msg_pmt): blob = msg_pmt #print "is blob" elif pmt.is_pair(msg_pmt): blob = pmt.cdr(msg_pmt) #print "is pair" else: print "Formato desconocido" return data_np = pmt.to_python(blob) #numpy.ndarray data_py = data_np.tolist() #python list #print "Paquete",data_py,data_py.__class__ if data_py[2:4]==[0xFF,0xFF]: index = 16 else: index = 24 del data_py[:index] # FC(2),Dst_Add(2),Src_Add(2),Radio(1),Sec_N(1),X->Dst_IEEE(8), Src_IEEE(8) #print "DEPACKED-->",data_py # Crea un PMT vacio: send_pmt = pmt.make_u8vector(len(data_py), ord(' ')) # Copy all characters to the u8vector: for i in range(len(data_py)): pmt.u8vector_set(send_pmt, i, data_py[i]) # Send the message: self.message_port_pub(pmt.intern('out'), pmt.cons(pmt.PMT_NIL, send_pmt))
13.3.3 ML Tx Nwk
<?xml version="1.0"?> <block> <name>Tx Nwk: Zigbee</name> <key>RSI_tx_nwk_zigbee</key> <category>RSI</category> <import>import RSI</import> <make>RSI.tx_nwk_zigbee($SrcAddN, $SrcIeeeN)</make> <param> <name>Source Add 16bit</name> <key>SrcAddN</key> <type>raw</type> </param> <param> <name>Source Add IEEE 64bit</name> <key>SrcIeeeN</key> <type>raw</type> </param> <sink> <name>in</name> <type>message</type> </sink> <source> <name>out</name>
97
<type>message</type> </source> <doc> Descripción: Adiciona capa de Red especificada en el estandar Zigbee 2006. Transmisión tipo Broadcast in: [pmt pair] desde "Tx App" out: [pmt pair] a "Tx Mac" Parámetros: SrcAddN: [list N=2] LSB primero ej.[0x2B,0x1A] SrcIeeeN: [list N=8] LSB primero ej.[0x12,0xAF,0x93,0x40,0x00,0xA2,0x13,0x00] </doc> </block>
13.3.4 Python Tx Nwk
""" Módulo Rx Nwk Zigbee- Miguel Sastoque & Claudia Segura """ import numpy as np import string import pmt import struct from gnuradio import gr from gnuradio import digital # Variable Global Seq_Num = [0] class tx_nwk_zigbee(gr.sync_block): """ docstring for block tx_nwk_zigbee """ def __init__(self, SrcAddN,SrcIeeeN): #Variables externas Parametros self.SrcAddN = SrcAddN self.SrcIeeeN = SrcIeeeN gr.sync_block.__init__(self, name="tx_nwk_zigbee", in_sig=[], out_sig=[]) self.message_port_register_in(pmt.intern("in")) self.message_port_register_out(pmt.intern("out")) self.set_msg_handler(pmt.intern("in"), self.make_NPDU) #Funcion def make_NPDU(self,msg_pmt): if pmt.is_blob(msg_pmt): blob = msg_pmt #print "is blob" elif pmt.is_pair(msg_pmt): blob = pmt.cdr(msg_pmt) #print "is pair" else: print "Formato desconocido"
98
return # Toma Pmt pair a numpyarray y luego a list data_np = pmt.to_python(blob) #numpy.ndarray apdu = data_np.tolist() #python list Src_Ieee = self.SrcIeeeN # la dir del USRP de 64 bit puede ser cualquiera global Seq_Num Seq_Num[0] = Seq_Num[0] +1 if Seq_Num[0] > 254: Seq_Num[0] = 0 Radio = [0x1E] # Saltos Max del mensaje Src_Add = self.SrcAddN # Puede ser cualquiera Dst_Add = [0xFF,0xFF] # Coordinador 00 00 / #broadcast FF FF FC_N = [0x08,0x10] # Frame Control LSB-MSB NPDU = FC_N + Dst_Add + Src_Add + Radio + Seq_Num + Src_Ieee + apdu # Crea PMT vacio send_pmt = pmt.make_u8vector(len(NPDU), ord(' ')) # Copia Caracteres a u8vector: for i in range(len(NPDU)): pmt.u8vector_set(send_pmt, i, NPDU[i]) # Envia mensaje: self.message_port_pub(pmt.intern('out'), pmt.cons(pmt.PMT_NIL, send_pmt))
13.4 CÓDIGOS CAPA MAC XBEE EN GNU RADIO
13.4.1 XML Rx Mac
<?xml version="1.0"?> <block> <name>Rx Mac: 802.15.4</name> <key>RSI_rx_mac_802_15_4</key> <category>RSI</category> <import>import RSI</import> <make>RSI.rx_mac_802_15_4()</make> <sink> <name>in</name> <type>message</type> </sink> <source> <name>out</name> <type>message</type> </source> <doc> Descripción: Des empaqueta la capa de Enlace especificada en el estandar IEEE 802.15.4 2006. Revisa FCS y calcula LQI in: [pmt pair] desde "Rx Phy" out: [pmt pair] a "Rx Nwk" Parámetros: Ninguno
99
</doc> </block>
13.4.2 Python Rx Mac
""" Módulo Rx MAC 802.15.4 - Miguel Sastoque & Claudia Segura """ import numpy as np import string import pmt import struct from gnuradio import gr from gnuradio import digital class rx_mac_802_15_4(gr.sync_block): def __init__(self): gr.sync_block.__init__(self, name="rx_mac_802_15_4", in_sig=[], out_sig=[]) self.message_port_register_in(pmt.intern("in")) self.message_port_register_out(pmt.intern("out")) self.set_msg_handler(pmt.intern("in"), self.deframe_NPDU) #Funcion def deframe_NPDU(self,msg_pmt): if pmt.is_blob(msg_pmt): blob = msg_pmt #print "is blob" elif pmt.is_pair(msg_pmt): blob = pmt.cdr(msg_pmt) #print "is pair" else: print "Formato desconocido" return data_np = pmt.to_python(blob) #numpy.ndarray data_py = data_np.tolist() #python list #print "Paquete",data_py,data_py.__class__ index = 9 del data_py[:index] # FC(2),Sec_N(1),PanID(2),Dst_Add(2),Src_Add(2) del data_py[-2],data_py[-1] #FCS #print "DEPACKED-->",data_py # Crea un PMT vacio: send_pmt = pmt.make_u8vector(len(data_py), ord(' ')) # Copy all characters to the u8vector: for i in range(len(data_py)): pmt.u8vector_set(send_pmt, i, data_py[i]) # Send the message: self.message_port_pub(pmt.intern('out'), pmt.cons(pmt.PMT_NIL, send_pmt))
100
13.4.3 XML Tx MAC
<?xml version="1.0"?> <block> <name>Tx Mac: 802.15.4</name> <key>RSI_tx_mac_802_15_4</key> <category>RSI</category> <import>import RSI</import> <make>RSI.tx_mac_802_15_4($PanId, $SrcAddM)</make> <callback>set_PanId($PanId)</callback> <param> <name>PanId</name> <key>PanId</key> <type>raw</type> </param> <param> <name>Source Add 16bit</name> <key>SrcAddM</key> <type>raw</type> </param> <sink> <name>in</name> <type>message</type> </sink> <source> <name>out</name> <type>message</type> </source> <doc> Descripción: Adiciona capa de Enlace especificada en el estandar IEEE 802.15.4 2006. Calcula FCS in: [pmt pair] desde "Tx Nwk" out: [pmt pair] a "Tx Phy" Parámetros: PanId: [list N=2] LSB primero ej.[0xCD,0xAB] SrcAddN: [list N=2] LSB primero ej.[0x2B,0x1A] </doc> </block>
13.4.4 Python Tx Mac
""" Módulo Tx Mac Ieee 802.15.4- Miguel Sastoque & Claudia Segura """ import numpy as np import string import pmt import struct from gnuradio import gr from gnuradio import digital # Variable Global
101
Seq_M = [0] class tx_mac_802_15_4(gr.sync_block): """ docstring for block tx_mac_802_15_4 """ def __init__(self, PanId,SrcAddM): #Variables externas Parametros self.SrcAddM = SrcAddM self.PanId = PanId gr.sync_block.__init__(self, name="tx_mac_802_15_4", in_sig=[], out_sig=[]) self.message_port_register_in(pmt.intern("in")) self.message_port_register_out(pmt.intern("out")) self.set_msg_handler(pmt.intern("in"), self.make_MPDU) #Funcion """ Metodo actualizar variable necestia agregar callback en xml""" def set_PanId(self,new_val): self.PanId = new_val def reflect(self,crc, bitnum): # Refleja el LSB 'bitnum' del 'crc' j=1 crcout=0 for b in range(bitnum): i=1<<(bitnum-1-b) if crc & i: crcout |= j j <<= 1 return crcout def crc16(self,p): #string crc = 0 for i in range(len(p)): c = p[i] c = self.reflect(ord(c), 8) j=0x80 for b in range(16): bit = crc & 0x8000 crc <<= 1 crc &=0xFFFF if c & j: crc |= 1 if bit: crc ^= 0x1021 j>>=1 if j == 0: break for i in range(16): bit = crc & 0x8000 crc <<= 1 if bit: crc ^= 0x1021 crc = self.reflect(crc, 16) return crc def make_MPDU(self,msg_pmt):
102
if pmt.is_blob(msg_pmt): blob = msg_pmt #print "is blob" elif pmt.is_pair(msg_pmt): blob = pmt.cdr(msg_pmt) #print "is pair" else: print "Formato desconocido" return # Toma Pmt pair a numpyarray y luego a list data_np = pmt.to_python(blob) #numpy.ndarray npdu = data_np.tolist() #python list Src_Add = self.SrcAddM # Dir 16 bit id de la red Dst_Add = [0xFF,0xFF] # Coordinador 00 00 / #broadcast FF FF Pan_Id = self.PanId # PanID que estabece el coordinador LSB -MSB global Seq_M Seq_M[0] = Seq_M[0] +1 if Seq_M[0] > 254: Seq_M[0] = 0 FC_M = [0x41,0x88] #Frame control Mac LSB-MSB to_fcs = FC_M + Seq_M + Pan_Id + Dst_Add + Src_Add + npdu s_to_fcs = struct.pack('B'*len(to_fcs), *to_fcs) # Convierte List a String a = self.crc16(s_to_fcs) #Calcula FCS FCS= [a & 0xFF,(a>>8)&0xFF] MPDU = FC_M + Seq_M + Pan_Id + Dst_Add + Src_Add + npdu + FCS send_pmt = pmt.make_u8vector(len(MPDU), ord(' ')) # Crea PMT vacio for i in range(len(MPDU)): pmt.u8vector_set(send_pmt, i, MPDU[i]) # Copia Caracteres a u8vector: # Envia mensaje: self.message_port_pub(pmt.intern('out'), pmt.cons(pmt.PMT_NIL, send_pmt))
13.5 INTERFAZ DE USUARIO CONCENTRADOR
13.5.1 Gráfica Temperatura Xbee
########################################################################### #!/usr/bin/env python """ Plot Xbee Temperatura- Miguel Sastoque & Claudia Segura """ import numpy as np import time from matplotlib import pyplot as plt import matplotlib.animation as animation from matplotlib.widgets import Button from socket import * from struct import * from random import randint plt.close('all') sock = socket(AF_INET, SOCK_DGRAM)
103
sock.sendto("hello", ("127.0.0.1", 10000)) start_time = time.time() plt.ion() # grafica animada tam=30 ydata1 = [0] * tam #cantidad ydata2 = [0] * tam #cantidad ax1=plt.axes() ax1.legend() # make plot line1, = plt.plot(ydata1,'ro-',label='XbeeS2') line2, = plt.plot(ydata2,'bo-',label='XbeePro') plt.ylim([-5,35]) plt.grid(True) plt.xlabel('Tiempo[s]') plt.ylabel('Temperatura [C]') plt.legend() run=True while(run): data = sock.recv(200) cur_time = int(time.time()-start_time) if data[0]==0: valor1 = 10*(data[1]-0x30) +(data[2]-0x30) +0.1*(data[4]-0x30) valor2 = 0 elif data[0]==1: valor1 = 0 valor2 = 10*(data[1]-0x30) +(data[2]-0x30) +0.1*(data[4]-0x30) print "XbeeS2--> T=",valor1,"C", "XbeePRO--> T=",valor2,"C", " t:",cur_time,"s" plt.xlim([cur_time-len(ydata1),cur_time]) ydata1.append(valor1) #actializa valor lista agrega nuevo valor del ydata1[0] line1.set_xdata(np.linspace(cur_time-len(ydata1),cur_time,len(ydata1))) line1.set_ydata(ydata1) # update the data ydata2.append(valor2) #actializa valor lista agrega nuevo valor del ydata2[0] line2.set_xdata(np.linspace(cur_time-len(ydata2),cur_time,len(ydata2))) line2.set_ydata(ydata2) # update the data plt.draw() # update the plot ###########################################################################
13.5.2 Código python flujograma
#!/usr/bin/env python2 ################################################## # GNU Radio Python Flow Graph # Title: WSN Xbee & Chronos # Generated: Tue Jan 19 17:27:50 2016 ################################################## if __name__ == '__main__':
104
import ctypes import sys if sys.platform.startswith('linux'): try: x11 = ctypes.cdll.LoadLibrary('libX11.so') x11.XInitThreads() except: print "Warning: failed to XInitThreads()" import os import sys sys.path.append(os.environ.get('GRC_HIER_PATH', os.path.expanduser('~/.grc_gnuradio'))) from gnuradio import blocks from gnuradio import eng_notation from gnuradio import gr from gnuradio import uhd from gnuradio import wxgui from gnuradio.eng_option import eng_option from gnuradio.filter import firdes from gnuradio.wxgui import forms from gnuradio.wxgui import scopesink2 from grc_gnuradio import wxgui as grc_wxgui from optparse import OptionParser from rx_phy_oqpsk import rx_phy_oqpsk from tx_phy_oqpsk import tx_phy_oqpsk import WSN import pmt import time import wx class WSN_Xbee_Chronos(grc_wxgui.top_block_gui): def __init__(self): grc_wxgui.top_block_gui.__init__(self, title="WSN Xbee & Chronos") _icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png" self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY)) ################################################## # Variables ################################################## self.TAB = TAB = 1 self.v_panid = v_panid = [0xFD,0x6C] if TAB==0 else [0x87,0x49] self.channel = channel = 11 if TAB==0 else 22 self.v_srcieee = v_srcieee = [0x12,0x34,0x56,0x40,0x00,0xA2,0x13,0x00] self.v_srcadd = v_srcadd = [0x12,0x34] self.squelch_lv = squelch_lv = -50 self.samp_rate = samp_rate = 4e6 self.msj = msj = "1234567890" self.labe_text = labe_text = v_panid self.gain = gain = 50 self.frec = frec = 2405e6 +5e6*(channel-11) ################################################## # Blocks ################################################## _squelch_lv_sizer = wx.BoxSizer(wx.VERTICAL) self._squelch_lv_text_box = forms.text_box( parent=self.GetWin(),
105
sizer=_squelch_lv_sizer, value=self.squelch_lv, callback=self.set_squelch_lv, label="Squelch [db]", converter=forms.float_converter(), proportion=0, ) self._squelch_lv_slider = forms.slider( parent=self.GetWin(), sizer=_squelch_lv_sizer, value=self.squelch_lv, callback=self.set_squelch_lv, minimum=-90, maximum=-30, num_steps=40, style=wx.SL_HORIZONTAL, cast=float, proportion=1, ) self.GridAdd(_squelch_lv_sizer, 3, 1, 2, 1) self._msj_text_box = forms.text_box( parent=self.GetWin(), value=self.msj, callback=self.set_msj, label="Mensaje", converter=forms.str_converter(), ) self.GridAdd(self._msj_text_box, 5, 3, 2, 1) _gain_sizer = wx.BoxSizer(wx.VERTICAL) self._gain_text_box = forms.text_box( parent=self.GetWin(), sizer=_gain_sizer, value=self.gain, callback=self.set_gain, label="Ganancia FrontEnd", converter=forms.float_converter(), proportion=0, ) self._gain_slider = forms.slider( parent=self.GetWin(), sizer=_gain_sizer, value=self.gain, callback=self.set_gain, minimum=0, maximum=70, num_steps=200, style=wx.SL_HORIZONTAL, cast=float, proportion=1, ) self.GridAdd(_gain_sizer, 3, 3, 2, 1) _frec_sizer = wx.BoxSizer(wx.VERTICAL) self._frec_text_box = forms.text_box( parent=self.GetWin(), sizer=_frec_sizer, value=self.frec, callback=self.set_frec, label="Fc", converter=forms.float_converter(),
106
proportion=0, ) self._frec_slider = forms.slider( parent=self.GetWin(), sizer=_frec_sizer, value=self.frec, callback=self.set_frec, minimum=2405e6, maximum=2480e6, num_steps=15, style=wx.SL_HORIZONTAL, cast=float, proportion=1, ) self.GridAdd(_frec_sizer, 5, 1, 2, 1) self.wxgui_scopesink2_0 = scopesink2.scope_sink_c( self.GetWin(), title="Simbolos OQPSK", sample_rate=samp_rate, v_scale=0, v_offset=0, t_scale=1/samp_rate, ac_couple=False, xy_mode=False, num_inputs=1, trig_mode=wxgui.TRIG_MODE_AUTO, y_axis_label="Amplitud", ) self.Add(self.wxgui_scopesink2_0.win) self.uhd_usrp_source_0 = uhd.usrp_source( ",".join(("type=b200", "")), uhd.stream_args( cpu_format="fc32", channels=range(1), ), ) self.uhd_usrp_source_0.set_subdev_spec("A:A", 0) self.uhd_usrp_source_0.set_samp_rate(samp_rate) self.uhd_usrp_source_0.set_center_freq(frec, 0) self.uhd_usrp_source_0.set_gain(gain-20, 0) self.uhd_usrp_source_0.set_antenna("RX2", 0) self.uhd_usrp_source_0.set_bandwidth(samp_rate, 0) self.uhd_usrp_sink_0 = uhd.usrp_sink( ",".join(("type=b200", "")), uhd.stream_args( cpu_format="fc32", channels=range(1), ), ) self.uhd_usrp_sink_0.set_subdev_spec("A:A", 0) self.uhd_usrp_sink_0.set_samp_rate(samp_rate) self.uhd_usrp_sink_0.set_center_freq(frec, 0) self.uhd_usrp_sink_0.set_gain(gain, 0) self.uhd_usrp_sink_0.set_antenna("TX/RX", 0) self.uhd_usrp_sink_0.set_bandwidth(samp_rate, 0) self.tx_phy_oqpsk_0 = tx_phy_oqpsk( samp_rate=4e6, ) self.rx_phy_oqpsk_0 = rx_phy_oqpsk(
107
samp_rate=4e6, squ=squelch_lv, ) self._labe_text_static_text = forms.static_text( parent=self.GetWin(), value=self.labe_text, callback=self.set_labe_text, label="PanId", converter=forms.str_converter(), ) self.GridAdd(self._labe_text_static_text, 1, 3, 2, 1) self.blocks_socket_pdu_0_0 = blocks.socket_pdu("UDP_SERVER", "", "10001", 200, False) self.blocks_message_strobe_0_0_0 = blocks.message_strobe(pmt.to_pmt(msj), 200) self.blocks_message_debug_0 = blocks.message_debug() self.WSN_tx_nwk_zigbee_0_0 = WSN.tx_nwk_zigbee(v_srcadd, v_srcieee) self.WSN_tx_mac_802_15_4_0 = WSN.tx_mac_802_15_4(v_panid, v_srcadd) self.WSN_tx_app_xbee_0_0 = WSN.tx_app_xbee() self.WSN_rx_nwk_zigbee_0 = WSN.rx_nwk_zigbee() self.WSN_rx_mac_802_15_4_0 = WSN.rx_mac_802_15_4(v_srcadd) self.WSN_rx_app_xbee_0 = WSN.rx_app_xbee() self._TAB_chooser = forms.drop_down( parent=self.GetWin(), value=self.TAB, callback=self.set_TAB, label="Modulo Xbee", choices=[0,1], labels=["Xbee s2", "Xbee PRO"], ) self.GridAdd(self._TAB_chooser, 1, 1, 2, 1) ################################################## # Connections ################################################## self.msg_connect((self.WSN_rx_app_xbee_0, 'out'), (self.blocks_socket_pdu_0_0, 'pdus')) self.msg_connect((self.WSN_rx_mac_802_15_4_0, 'out'), (self.WSN_rx_nwk_zigbee_0, 'in')) self.msg_connect((self.WSN_rx_nwk_zigbee_0, 'out'), (self.WSN_rx_app_xbee_0, 'in')) self.msg_connect((self.WSN_tx_app_xbee_0_0, 'out'), (self.WSN_tx_nwk_zigbee_0_0, 'in')) self.msg_connect((self.WSN_tx_mac_802_15_4_0, 'out'), (self.tx_phy_oqpsk_0, 'From_Mac')) self.msg_connect((self.WSN_tx_nwk_zigbee_0_0, 'out'), (self.WSN_tx_mac_802_15_4_0, 'in')) self.msg_connect((self.blocks_message_strobe_0_0_0, 'strobe'), (self.WSN_tx_app_xbee_0_0, 'in')) self.msg_connect((self.blocks_socket_pdu_0_0, 'pdus'), (self.WSN_rx_app_xbee_0, 'in')) self.msg_connect((self.rx_phy_oqpsk_0, 'to_Mac'), (self.WSN_rx_mac_802_15_4_0, 'in')) self.connect((self.tx_phy_oqpsk_0, 0), (self.uhd_usrp_sink_0, 0)) self.connect((self.uhd_usrp_source_0, 0), (self.rx_phy_oqpsk_0, 0)) self.connect((self.uhd_usrp_source_0, 0), (self.wxgui_scopesink2_0, 0)) def get_TAB(self): return self.TAB
108
def set_TAB(self, TAB): self.TAB = TAB self.set_v_panid([0xFD,0x6C] if self.TAB==0 else [0x87,0x49]) self.set_channel(11 if self.TAB==0 else 22) self._TAB_chooser.set_value(self.TAB) def get_v_panid(self): return self.v_panid def set_v_panid(self, v_panid): self.v_panid = v_panid self.WSN_tx_mac_802_15_4_0.set_PanId(self.v_panid) self.set_labe_text(self.v_panid) def get_channel(self): return self.channel def set_channel(self, channel): self.channel = channel self.set_frec(2405e6 +5e6*(self.channel-11)) def get_v_srcieee(self): return self.v_srcieee def set_v_srcieee(self, v_srcieee): self.v_srcieee = v_srcieee def get_v_srcadd(self): return self.v_srcadd def set_v_srcadd(self, v_srcadd): self.v_srcadd = v_srcadd def get_squelch_lv(self): return self.squelch_lv def set_squelch_lv(self, squelch_lv): self.squelch_lv = squelch_lv self._squelch_lv_slider.set_value(self.squelch_lv) self._squelch_lv_text_box.set_value(self.squelch_lv) self.rx_phy_oqpsk_0.set_squ(self.squelch_lv) def get_samp_rate(self): return self.samp_rate def set_samp_rate(self, samp_rate): self.samp_rate = samp_rate self.uhd_usrp_sink_0.set_samp_rate(self.samp_rate) self.uhd_usrp_sink_0.set_bandwidth(self.samp_rate, 0) self.wxgui_scopesink2_0.set_sample_rate(self.samp_rate) self.uhd_usrp_source_0.set_samp_rate(self.samp_rate) self.uhd_usrp_source_0.set_bandwidth(self.samp_rate, 0) def get_msj(self): return self.msj def set_msj(self, msj): self.msj = msj
109
self.blocks_message_strobe_0_0_0.set_msg(pmt.to_pmt(self.msj)) self._msj_text_box.set_value(self.msj) def get_labe_text(self): return self.labe_text def set_labe_text(self, labe_text): self.labe_text = labe_text self._labe_text_static_text.set_value(self.labe_text) def get_gain(self): return self.gain def set_gain(self, gain): self.gain = gain self.uhd_usrp_sink_0.set_gain(self.gain, 0) self._gain_slider.set_value(self.gain) self._gain_text_box.set_value(self.gain) self.uhd_usrp_source_0.set_gain(self.gain-20, 0) def get_frec(self): return self.frec def set_frec(self, frec): self.frec = frec self.uhd_usrp_sink_0.set_center_freq(self.frec, 0) self._frec_slider.set_value(self.frec) self._frec_text_box.set_value(self.frec) self.uhd_usrp_source_0.set_center_freq(self.frec, 0) if __name__ == '__main__': parser = OptionParser(option_class=eng_option, usage="%prog: [options]") (options, args) = parser.parse_args() tb = WSN_Xbee_Chronos() tb.Start(True) tb.Wait()
