Despliegue de redes inalámbricas de sensores con Contiki

Equation Chapter 1 Section 1 Proyecto Fin de Máster Máster en Ingeniería Electrónica Robótica y Automática Despliegue de redes inalámbricas de sensores con Contiki Autor: Pablo Montero García Tutor: Juan José Murillo Fuentes Dpto. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 iii Proyecto Fin de Máster Máster Ingeniería Electrónica Robótica y Automática Despliegue de redes inalámbricas de sensores con Contiki Autor: Pablo Montero García Tutor: Juan José Murillo Fuentes Profesor titular Dpto. de Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 v Proyecto Fin de Máster: Despliegue de redes inalámbricas de sensores con Contiki Autor: Pablo Montero García Tutor: Juan José Murillo Fuentes El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2020 El Secretario del Tribunal vii A mi familia y amigos ix Agradecimientos Juan José Murillo Fuentes Subdirección de Comunicaciones y Recursos Comunes Sevilla, 2020 Índice de Figuras Figura 1. Redes inalámbricas atendiendo a la tasa de datos y a su cobertura geográfica. 1 Figura 2. Dominios de Aplicación de las Redes Inalámbricas de Sensores (WSNs). 3 Figura 3. Logotipo Contiki-NG. 6 Figura 4. Enrutado RPL. 6 Figura 5. Comparativa entre TCP y UDP. 8 Figura 6. Trama UDP. 9 Figura 7. Plataforma RE-Mote. 10 Figura 8. Pinout de la platafoma RE-Mote revisión b. 11 Figura 9. Conexiones y puertos externos de la RE-Mote rev b. 12 Figura 10. Pines de conexiónes Molex. 12 Figura 11. Dispositivo Orion Ethernet Router. 13 Figura 12. Pinout del Router Orion. 14 Figura 13. Estructura de una aplicación LAMP. 15 Figura 14. Servidor HTTP Apache. 15 Figura 15. Tipos de bases de datos. 17 Figura 16. Jerarquía en aplicaciones de MySQL. 18 Figura 17. Consulta de base de datos mediante sentencias. 19 Figura 18. Ventana de configuración de VirtualBox. 22 Figura 19. Descarga del compilador ARM. 22 Figura 20. Descargar de Contiki-NG. 23 Figura 21. Descarga de orden ant para Cooja. 23 Figura 22. Ubicación de carpeta "contiki-ng". 23 Figura 23. Inclusiones en el archivo "build.xml". 24 Figura 24 . Descarga de archivos MSPSim. 24 Figura 25. Instancias UDP. 24 Figura 26. Función de recepción UDP. 25 Figura 27. Envío de mensaje UDP. 25 Figura 28 Código de envio UDP y comprobación de ruta. 26 Figura 29. Compilación de programa desde el terminal. 26 Figura 30. Selección de conexión USB de la plataforma. 27 Figura 31. Carga de programa desde el terminal. 27 Figura 32. Conexión serial desde el terminal. 27 Figura 33. Modificación del programa "udp-client-temp.c". 28 Figura 34. Inicio de Cooja. 28 Figura 35. Creación de simulación. 29 Figura 36. Ventana principal de Cooja. 29 xvii Figura 37. Creación de los nodos para simulación. 30 Figura 38. Ubicación de nodos. 30 Figura 39. Información de inicialización del nodo. 31 Figura 40. Transmisión de mensaje. 31 Figura 41. Reenvio de mensajes en la red. 32 Figura 42. Comprobación de batería. 32 Figura 43. Mensajes recibidos en la mota servidor. 33 Figura 44. Jerarquíca de llamadas a funciones httpd. 34 Figura 45. Definición de macros ADD y SEND. 34 Figura 46. Compilación para plataforma sky. 34 Figura 47. Comunicación y rutado de la red. 35 Figura 48. Conexión con el border-router en simulación. 35 Figura 49. Prueba de dirección IPv6. 35 Figura 50. Información de rutado para el usuario. 36 Figura 51. Conexión con el border-router. 36 Figura 52. Definición de funciones para http-socket. 37 Figura 53. Menú de selección de dispositivos. 38 Figura 54. Conexión router-ordenador. 38 Figura 55. Interfaces habilitadas. 39 Figura 56. Instalación del paquete Apache2. 40 Figura 57. Estado del servidor Apache. 40 Figura 58. Ejemplos de consultas SQL. 41 Figura 59. Modificación de archivos de configuración de Apache2. 42 Figura 60. Coexistencia de HTML y PHP. 43 Figura 61. Estructura de la aplicación web. 44 Figura 62. Ventana de acceso. 44 Figura 63. Ventana principal 45 Figura 64. Pestaña de mapa. 45 Figura 65. Pestaña de gráficas. 46 Figura 66. Pestaña de información. 46 Figura 67. Ubicación de la aplicación web. 46 Figura 68. Manipulación de la base de datos desde el terminal Linux. 47 Figura 69. Recepción de mensajes de las motas en el router. 47 Figura 70. Visualización de la red desde la aplicación web. 48 Figura 71. Visualización de datos. 48 1 1 INTRODUCCIÓN Las redes de computadores han llegado a ser una parte esencial de la vida cotidiana: permiten tener comunicaciones personales, chatear con amigos, gestionar correo electrónico, transmitir fotos y videos y navegar por Internet. Esas mismas redes también permiten el desarrollo de aplicaciones de negocios, gestionar transferencias bancarias y monitorizar y operar plantas de manera remota. Facilitan las operacions logísticas y permiten comprar y vender objetos y servicios por Internet, que se reciben en casa u ordenadores personales en unos pocos días (en algunos casos horas o minutos). También permiten conectar objetos: sensores, electrodomésticos, consolas, etc., así como conectar periféricos y enlazar computadores entre sí , y conectarlos a Internet. Muchas de estas redes son cableadas y otras inalámbricas. La conexión por cables proporciona una mayor fiabilidad en las comunicaciones y, en ocasiones, un mayor ancho de banda dedicado, con un elevado coste de instalación y de mantenimiento de las infraestructuras. Las comunicaciones inalámbricas son menos costosas de instalar y desplegar, pero su propia naturaleza ubicua las hace menos seguras y más sensibles a interferencia. A pesar de estas limitaciones, propias de las redes inalámbricas, éstas forman parte de nuestra vida diaria, y términos como Bluetooth, WiFi y 4G son familiares incluso para los que desconocen por completo el funcionamiento de las tecnologías que los soportan. Figura 1. Redes inalámbricas atendiendo a la tasa de datos y a su cobertura geográfica. La Figura 1 muestra de una manera esquemática las principales tecnologías que dan soporte a las comunicaciones inalámbricas más extendidas, distribuyéndolas en función de su cobertura geográfica y de la tasa de datos que soportan. En algunos casos se indica el nombre del estándar que las soporta, en otros casos se usan los nombres, comerciales o populares, con el que se las conoce. 1.1 Redes Inalámbricas de Sensores Redes Inalámbricas Sensoriales (Wireless Sensor Networks o WSNs) se definen como un conjunto de sensores y actuadores autónomos que emplean una infraestructura de comunicación inalámbrica, destinados a monitorizar y controlar las condiciones físicas y ambientales en localizaciones diversas, y que de una manera cooperativa pasan sus datos a través de la red hasta una localización central, o pasan las órdenes a través de la red hasta un determinado actuador. A cada uno de los elementos que forman parte de la red de comunicaciones los llamaremos nodos de la red. Un nodo puede tener varios sensores y actuadores, aunque lo normal es que tengan uno sólo, o un número muy limitado de ellos. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 2 Aunque no todas las WSNs tienen todas estas características a la vez, las WSNs generalmente precisan una baja tasa de datos y tienen alcances limitados, por lo que son redes LR-WPANs (Low-Rate Wireless Personal Area Network). Otras características de estas redes son:  El número de nodos es de unas decenas o centenas; como mucho, algunos millares.  Los nodos son autónomos, por lo que necesitan limitar su consumo de manera que puedan funcionar un tiempo suficiente alimentados por baterías, o por sistemas de extracción de energía del ambiente (energy harvesters).  Los nodos no tienen una elevada capacidad de procesamiento, por lo que tanto las aplicaciones de control local de sensores y actuadores, como los algoritmos y protocolos de gestión de las comunicaciones deben ser tan simples como sea posible. Con respecto a los nodos, éstos pueden desempeñar varias funciones:  Función terminal gestionando los sensores y actuadores que tiene instalado y pasando la información de los sensores (recibiendo los comandos a los actuadores) a través de otros nodos de la red. A estos nodos se les denomina Nodos Terminales (Terminal Nodes) o Nodos Sensores (Sensor Nodes).  Función de retransmisión de la información de un nodo a otro hasta alcanzar su destino final. A estos nodos se les denomina Nodos Enrutadores (Routers)  Función de sumidero de información y/o de pasarela con un computador central o con otras redes. A estos nodos se les llama Nodos Fuente (Sink Nodes) o Estaciones Base (Base Stations), según el caso. En la práctica, un mismo nodo, dependiendo de su programación o del estado de la red en un momento dado, puede actuar como un Terminal, un Router o una Estación Base. Cada Nodo Terminal está equipado con un sensor o actuador (o un grupo de ellos), un procesador que gestiona la programación y operación de los sensores o actuadores, y un terminal radio que permite enlazar el nodo con el resto de la red inalámbrica. Los datos procedentes de los sensores (las órdenes destinadas a los actuadores) son recogidos en (enviados desde) el Nodo Sumidero o en la Estación Base, que se comunica con el sistema de supervisión y control, bien en modo local, bien de forma remota a través de una LAN, MAN o WAN. Los Nodos Sensores no tienen, en la mayor parte de los casos, una localización específica. En algunos casos, incluso, son distribuidos de forma más o menos aleatoria para cubrir amplios espacios. 1.2 Aplicaciones de las WSNs La Figura 2 muestra los principales dominios de aplicación de las WSNs, que podemos clasificar en: Aplicaciones de Seguimiento Remoto y Aplicaciones de Monitorización Remota, cada una de ellas con aplicaciones en interior (Indoor) y exterior (Outdoor). Cuando se habla de Seguimiento se considera que el nodo se encuentra en movimiento y se desea seguir su trayectoria, posicionándolo en un entorno, que puede ser fijo o variable. El problema de Seguimiento tiene aplicaciones militares (seguimiento de blancos y del movimiento de tropas amigas o enemigas), de medio ambiente (seguimiento de animales en granjas o en grandes espacios naturales), o en transporte (seguimiento de contenedores en cadenas logísticas, seguimiento de vehículos en grandes instalaciones, etc.). En aplicaciones de interior se puede pensar en el seguimiento de pacientes o de ancianos en hospitales y residencias, seguimiento de grandes equipos en instalaciones singulares como almacenes y hospitales, o seguimiento de vehículos autónomos en cadenas de fabricación. En cuanto a las aplicaciones de monitorización y control, destacan la detección temprana de incendios en bosques y parques naturales, la monitorización de las condiciones de las cargas en los procesos logísticos, o la monitorización de variables físicas (temperatura, humedad, texturas, dimensiones, etc.) en los procesos de fabricación. En entornos de interior, se puede monitorizar las condiciones de seguridad (detección de incendios, contaminación, etc.) en edificios e instalaciones o las variables fisiológicas de pacientes o deportistas. También cabe pensar en otras aplicaciones industriales y logísticas. 3 3 Despliegue de redes inalámbricas de sensores con Contiki Figura 2. Dominios de Aplicación de las Redes Inalámbricas de Sensores (WSNs). 5 2 TECNOLOGÍAS En este apartado se exponen las principales tecnologías, plataformas y herramientas utilizadas en el desarrollo del proyecto y que suponen los componentes principales y de mayor interés de este. En el proyecto se han empleado principalmente varios componentes, tanto software como hardware:  Contiki-NG: sistema operativo para dispositivos con bajas prestaciones optimizado para redes de comunicación inalámbricas y aplicaciones de bajo consumo. Además, se exponen los puntos más importantes de comunicación en red que implementa este sistema operativo como son el protocolo de comunicación y el enrutado de dispositivos.  Plataformas Zolertia: dispositivos hardware basados en microcontroladores de gran rendimiento con interfaces de comunicación inalámbricas, especialmente pensados para inplementación y gestión de redes de bajo consumo. Las plataformas a utilizar son RE-Mote revisión b y Router Ethernet Orion.  Servidor LAMP: Una pila de software muy extendida en servicios web que combina las funciones de Apache, MySQL y PHP sobre un sistema operativo basado en Linux para cubrir todas las necesidades de un portal web básico. 2.1 Contiki-NG Contiki-NG (1) es un sistema operativo para dispositivos con recursos limitados en Internet of Things. Contiki-NG contiene una pila de comunicación IPv6 de baja potencia que cumple con RFC, lo que permite la conectividad a Internet. El sistema se ejecuta en una variedad de plataformas basadas en arquitecturas energéticamente eficientes, como ARM Cortex-M3 / M4 y Texas Instruments MSP430. La huella del código es del orden de 100 kB, y el uso de la memoria se puede configurar para que sea tan bajo como 10 kB. El código fuente está disponible como código abierto con una licencia BSD de 3 cláusulas. En 2017, Contiki-NG comenzó como una bifurcación del sistema operativo Contiki con los siguientes objetivos:  Centrarse en una comunicación IPv6 confiable (confiable y segura) basada en estándares;  Centrarse en las plataformas modernas de IoT, p. ARM Cortex M3 y otras MCU de 32 bits;  Modernizar la estructura, configuración, registro y plataformas, para reflejar los objetivos anteriores;  Mejore la documentación, tanto el código API, la descripción del módulo y los tutoriales;  Implemente un proceso de desarrollo más ágil, con una inclusión más fácil de nuevas características y con lanzamientos periódicos. Los aspectos más interesantes a profundizar en este proyecto son aquellos relacionados con las comunicaciones inalámbricas, las cuales se basan, entre otras capas del protocolo de comunicación, en comunicaciones UDP y enrutamiento con RPL. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 6 Figura 3. Logotipo Contiki-NG (de (1)). 2.1.1 Enrutamiento con RPL RPL (2) (Routing Protocol for Loosy and Low-power) es un protocolo de enrutamiento IPv6 para redes con pérdidas y de baja potencia especificado en RFC 6550, que se implementa en la pila de red IPv6 de Contiki-NG. RPL crea y mantiene una topología DODAG (Destinated Orientated Directed Acyclic Graph) que se origina en un nodo raíz RPL designado, que generalmente también sirve como un enrutador de borde a Internet. La información de enrutamiento se difunde a través de balizas de difusión de forma periódica. La topología se construye de acuerdo con un objetivo determinado mediante una función objetivo. Tal objetivo puede ser minimizar el recuento estimado de transmisión (Estimated Transmision Count, ETX) en la ruta desde el nodo a la raíz RPL, como lo es en las implementaciones de las dos Funciones Objetivos que admite, MRHOF y 0F0. RPL admite diferentes sentidos de tráfico:  Enrutamiento ascendente: de cualquier nodo a una raíz.  Enrutamiento hacia abajo: desde la raíz a cualquier nodo.  Enrutamiento de cualquiera a cualquier: donde el tráfico fluye entre pares arbitrarios de nodos en el DODAG al enrutar hacia arriba a su ancestro común más cercano (o la raíz en modo de no almacenamiento) en el DODAG, y luego hacia abajo al nodo de destino. Figura 4. Enrutado RPL (de (2)). 7 Despliegue de redes inalámbricas de sensores con Contiki Todo el enrutamiento ascendente se maneja haciendo que cada nodo en la ruta de tráfico reenvíe a través de un padre preferido, como en la Figura 4. El enrutamiento hacia abajo se puede manejar con dos tipos diferentes de modos: modo sin almacenamiento y modo de almacenamiento. Para el modo sin almacenamiento, se utiliza el enrutamiento de origen IPv6, lo que significa que los nodos no tienen que almacenar tablas de enrutamiento para los nodos debajo de ellos en el DODAG. Por otro lado, los paquetes pueden agrandarse si hay muchos saltos a lo largo de la ruta, cuyas direcciones tendrían que incrustarse en el encabezado de enrutamiento de origen. Para el modo de almacenamiento, las tablas de enrutamiento se almacenan en cada nodo, lo que puede imponer una huella de memoria significativa en redes grandes y ser difícil de mantener de manera consistente, pero por otro lado no hay necesidad de encabezados de enrutamiento de origen potencialmente grandes en los paquetes IPv6. Contiki-NG dispone de dos implementaciones diferentes de RPL (2):  RPL Classic: RPL Classic es la continuación de la implementación original de RPL de Contiki: ContikiRPL. Esta implementación se creó ya en 2009, mientras que el estándar RPL todavía estaba en desarrollo. A lo largo de los años, se ha agregado una gran cantidad de funcionalidades al RPL, como soporte para múltiples instancias y DODAG, modo de almacenamiento y no almacenamiento, multidifusión y más. Por lo tanto, al precio de soportar una gran cantidad de funcionalidades de estándares y borradores de Internet, la implementación se ha vuelto compleja y ha logrado una gran huella de ROM.  RPL Lite: RPL Lite es la implementación de RPL predeterminada de Contiki-NG. Comenzó como una reescritura importante de la versión 2017 de Contiki RPL, con un enfoque en la funcionalidad más importante y estable, como la comunidad ha experimentado en muchas implementaciones y experimentos de investigación. RPL Lite elimina la compatibilidad con el modo de almacenamiento en favor del modo sin almacenamiento y la complejidad de manejar múltiples instancias y DODAG. A través de estos cambios, RPL Lite generalmente exhibe un mejor rendimiento y tiene una huella ROM considerablemente menor. Por otro lado, estas optimizaciones tienen un nivel de interoperabilidad más bajo con otras implementaciones, que pueden usar el modo de almacenamiento, por ejemplo. 2.1.2 Comunicaciones UDP El protocolo de datagramas de usuario, abreviado como UDP (3), es un protocolo que permite la transmisión sin conexión de datagramas en redes basadas en IP. Para obtener los servicios deseados en los hosts de destino, los puertos están listados como uno de los campos principales en la cabecera UDP. Como muchos otros protocolos de red, UDP pertenece a la familia de protocolos de Internet, por lo que debe clasificarse en el nivel de transporte y, entre la capa de red y la capa de aplicación. Mediante el protocolo de datagramas de usuario, una aplicación puede enviar información muy rápidamente, ya que no es necesario establecer una conexión con el receptor ni esperar una respuesta. Sin embargo, no hay garantía de que los paquetes vayan a llegar completos y respetando el orden en el que fueron enviados, a diferencia de TCP como se muestra en la Figura 5. Además, este protocolo no ofrece ninguna protección frente a la alteración o acceso por parte de terceros. Sin embargo, el UDP puede añadir opcionalmente una suma de verificación (que es obligatoria en IPv6) que permite detectar los paquetes defectuosos. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 14  CP2104 / PIC incorporado para flashear sobre su conector micro-USB.  botones de usuario y reinicio.  Botón de encendido / apagado y LED para mostrar el estado de encendido  LED RGB para permitir más de 7 combinaciones de colores.  Diseño 40.29 x 73.75 mm Hay conectores adicionales (no incluidos de forma predeterminada) con un espaciado de paso de 2,54 mm, exponiendo los pines CC2538. Los conectores JP4 y JP6 exponen los pines principalmente a sensores de interfaz, actuadores y buses de comunicación. Los pines pares JP6 son compatibles con los pines predeterminados I2C utilizados por otras plataformas como Firefly o RE-Mote). El bloque JP5 expone los pines del CC2538 conectado al transceptor CC1200 sub-GHz y al módulo Ethernet ENC28J60. Figura 12. Pinout del Router Orion (de (5)). 2.3 Servidor web Para poder dar acceso al usuario la red de sensores desde una interfaz cómoda e intuitiva, almacenar los datos y mensajes enviados por los sensores, es necesario el uso de un software específico que soporte estas funcionalidades. Una de las opciones es el uso de una aplicación tipo LAMP (Figura 13). Las aplicaciones LAMP combinan:  Apache: es el componente de servidor web más popular en este tipo de plataformas. Gestionan la conexión de los clientes al servidor y emite las respuestas.  MySQL: es la base de datos más popularizada. Almacena toda la información de los elementos del sistema, mensajes y códigos enviados y los datos de gestión internos de la aplicación.  Los lenguajes de programación PHP/Perl/Python (y ahora también Ruby). Desarrollan todo el proceso de gestión interna del servidor para procesar las peticiones de los clientes. 15 Despliegue de redes inalámbricas de sensores con Contiki Figura 13. Estructura de una aplicación LAMP. 2.3.1 Servidor Apache El servidor HTTP Apache (6) es un servidor web HTTP de código abierto, para plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio virtual según la normativa RFC 2616. Cuando comenzó su desarrollo en 1995 se basó inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo, y consistía solamente en un conjunto de parches a aplicar al servidor de NCSA. Es desarrollado y mantenido por una comunidad de usuarios bajo la supervisión de la Apache Software Foundation dentro del proyecto HTTP Server (httpd). Apache presenta entre otras características altamente configurables, bases de datos de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude en su configuración. Figura 14. Servidor HTTP Apache (de (6)). Apache tiene amplia aceptación en la red: desde 1996, Apache es el servidor HTTP más usado. Jugó un papel fundamental en el desarrollo de la World Wide Web y alcanzó su máxima cuota de mercado en 2005, siendo el servidor empleado en el 70% de los sitios web en el mundo. Sin embargo, ha sufrido un descenso en su cuota de mercado en los últimos años (estadísticas históricas y de uso diario proporcionadas por Netcraft). En 2009, se convirtió en el primer servidor web que alojó más de 100 millones de sitios web. Apache es usado principalmente para enviar páginas web estáticas y dinámicas en la World Wide Web. Muchas aplicaciones web están diseñadas asumiendo como ambiente de implantación a Apache, o que utilizarán características propias de este servidor web. Este servidor web es redistribuido como parte de varios paquetes propietarios de software, incluyendo la Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 16 base de datos Oracle y el IBM WebSphere application server. MacOS integra apache como parte de su propio servidor web y como soporte de su servidor de aplicaciones WebObjects. Es soportado de alguna manera por Borland en las herramientas de desarrollo Kylix y Delphi. Apache es incluido con Novell NetWare 6.5, donde es el servidor web por defecto, y en muchas distribuciones Linux Un servidor web Apache puede ser una excelente opción para ejecutar tu sitio web en una plataforma estable y versátil. Sin embargo, también presenta algunas desventajas a las que debes prestarle atención: Ventajas: 1. De código abierto y gratuito, incluso para uso comercial. 2. Software confiable y estable. 3. Parches de seguridad regulares y actualizados con frecuencia. 4. Flexible debido a su estructura basada en módulos. 5. Fácil de configurar para principiantes. 6. Multiplataforma (funciona tanto en servidores Unix como en Windows). 7. Viene listo para trabajar con sitios de WordPress. 8. Enorme comunidad y soporte fácilmente disponible en caso de cualquier problema. Desventajas: 1. Problemas de rendimiento en sitios web con demasiado tráfico. 2. Demasiadas opciones de configuración pueden generar vulnerabilidades de seguridad. 2.3.2 Bases de datos Una base de datos (7) es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En este sentido; una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta. Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto, se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos. Existen diferentes clasificaciones de las bases de datos (Figura 15), atendiendo a características puntuales: Según su variabilidad. Conforme a los procesos de recuperación y preservación de los datos, podemos hablar de:  Bases de datos estáticas. Típicas de la inteligencia empresarial y otras áreas de análisis histórico, son bases de datos de sólo lectura, de las cuales se puede extraer información, pero no modificar la ya existente.  Bases de datos dinámicas. Aparte de las operaciones básicas de consulta, estas bases de datos manejan procesos de actualización, reorganización, añadidura y borrado de información. Según su contenido. De acuerdo a la naturaleza de la información contenida, pueden ser:  Bibliográficas. Contienen diverso material de lectura (libros, revistas, etc.) ordenado a partir de información clave como son los datos del autor, del editor, del año de aparición, del área temática o del título del libro, entre otras muchas posibilidades.  De texto completo. Se manejan con textos históricos o documentales, cuya preservación debe ser a todo nivel y se consideran fuentes primarias.  Directorios. Listados enormes de datos personalizados o de direcciones de correo electrónico, números telefónicos, etc. Las empresas de servicios manejan enormes directorios clientelares, por ejemplo.  Especializadas. Bases de datos de información hiperespecializada o técnica, pensadas a partir de las necesidades puntuales de un público determinado que consume dicha información. 17 Despliegue de redes inalámbricas de sensores con Contiki Figura 15. Tipos de bases de datos. 2.3.2.1 Bases de datos relacionales Además de la clasificación por la función de las bases de datos, estas también se pueden clasificar de acuerdo a su modelo de administración de datos. Un modelo de datos es básicamente una "descripción" de algo conocido como contenedor de datos (algo en donde se guardan los datos), así como de los métodos para almacenar y recuperar datos de esos contenedores. Los modelos de datos no son cosas físicas: son abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemáticos. El modelo relacional es el modelo utilizado en la actualidad para representar problemas reales y administrar datos dinámicamente. En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos. La información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información. 2.3.3 Gestores de datos Existen programas denominados sistemas gestores de bases de datos, abreviado SGBD (del inglés Database Management System o DBMS), que permiten almacenar y posteriormente acceder a los datos de forma rápida y estructurada. Las propiedades de estos DBMS, así como su utilización y administración, se estudian dentro del ámbito de la informática. Las aplicaciones más usuales son para la gestión de empresas e instituciones públicas; También son ampliamente utilizadas en entornos científicos con el objeto de almacenar la información experimental. La base de datos y el software SGBD pueden estar distribuidos en múltiples sitios conectados por una red. Hay de dos tipos:  Distribuidos homogéneos: utilizan el mismo SGBD en múltiples sitios.  Distribuidos heterogéneos: Da lugar a los SGBD federados o sistemas multibase de datos en los que los SGBD participantes tienen cierto grado de autonomía local y tienen acceso a varias bases de datos autónomas preexistentes almacenados en los SGBD, muchos de estos emplean una arquitectura cliente-servidor. 2.3.4 MySQL MySQL es un sistema de gestión de bases de datos relacional (Figura 16) desarrollado bajo licencia Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 18 dual: Licencia pública general/Licencia comercial por Oracle Corporation y está considerada como la base datos de código abierto más popular del mundo, y una de las más populares en general junto a Oracle y Microsoft SQL Server, sobre todo para entornos de desarrollo web. Está desarrollado en su mayor parte en ANSI C y C++. Tradicionalmente se considera uno de los cuatro componentes de la pila de desarrollo LAMP y WAMP. MySQL funciona sobre múltiples plataformas, incluyendo: AIX, BSD, FreeBSD, HP-UX, Kurisu OS, GNU/Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, QNX, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, eBD, Windows (multiples versiones), OpenVMS. Figura 16. Jerarquía en aplicaciones de MySQL. Inicialmente, MySQL carecía de elementos considerados esenciales en las bases de datos relacionales, tales como integridad referencial y transacciones. A pesar de ello, atrajo a los desarrolladores de páginas web con contenido dinámico, justamente por su simplicidad. Poco a poco los elementos de los que carecía MySQL están siendo incorporados tanto por desarrollos internos, como por desarrolladores de software libre. Entre las características disponibles en las últimas versiones se puede destacar:  Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas igualmente.  Disponibilidad en gran cantidad de plataformas y sistemas.  Posibilidad de selección de mecanismos de almacenamiento que ofrecen diferentes velocidades de operación, soporte físico, capacidad, distribución geográfica, transacciones...  Transacciones y claves foráneas.  Conectividad segura.  Replicación.  Búsqueda e indexación de campos de texto. MySQL es un sistema de administración relacional de bases de datos. Una base de datos relacional archiva datos en tablas separadas en vez de colocar todos los datos en un gran archivo. Esto permite velocidad y flexibilidad. Las tablas están conectadas por relaciones definidas que hacen posible combinar datos de diferentes tablas sobre pedido. 19 Despliegue de redes inalámbricas de sensores con Contiki 2.3.5 SQL SQL (Structured Query Language) (8) es un lenguaje estándar e interactivo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en ellas, gracias a la utilización del álgebra y de cálculos relacionales, el SQL brinda la posibilidad de realizar consultas con el objetivo de recuperar información de las bases de datos de manera sencilla (Figura 17). Las consultas toman la forma de un lenguaje de comandos que permite seleccionar, insertar, actualizar, averiguar la ubicación de los datos, y más. Figura 17. Consulta de base de datos mediante sentencias. SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y potencia de los sistemas relacionales y permite así gran variedad de operaciones. Es un lenguaje declarativo de "alto nivel" o "de no procedimiento" que, gracias a su fuerte base teórica y su orientación al manejo de conjuntos de registros —y no a registros individuales— permite una alta productividad en codificación y la orientación a objetos. De esta forma, una sola sentencia puede equivaler a uno o más programas que se utilizarían en un lenguaje de bajo nivel orientado a registros. SQL también tiene las siguientes características (8):  Lenguaje de definición de datos: El LDD de SQL proporciona comandos para la definición de esquemas de relación, borrado de relaciones y modificaciones de los esquemas de relación.  Lenguaje interactivo de manipulación de datos: El LMD de SQL incluye lenguajes de consultas basado tanto en álgebra relacional como en cálculo relacional de tuplas.  Integridad: El LDD de SQL incluye comandos para especificar las restricciones de integridad que deben cumplir los datos almacenados en la base de datos.  Definición de vistas: El LDD incluye comandos para definir las vistas.  Control de transacciones: SQL tiene comandos para especificar el comienzo y el final de una transacción.  SQL incorporado y dinámico: Esto quiere decir que se pueden incorporar instrucciones de SQL en lenguajes de programación como: C++, C, Java, PHP, Cobol, Pascal y Fortran.  Autorización: El LDD incluye comandos para especificar los derechos de acceso a las relaciones y a las vistas. SQL es un lenguaje declarativo. O sea, que especifica qué es lo que se quiere y no cómo conseguirlo, por lo que una sentencia no establece explícitamente un orden de ejecución. Los sistemas de bases de datos modernos poseen un componente llamado optimizador de consultas. Este realiza un detallado análisis de los posibles planes de ejecución de una consulta SQL y elige aquel que sea más eficiente para llevar adelante la misma. Existe una ampliación de SQL conocida como FSQL (Fuzzy SQL, SQL difuso) que permite el acceso a bases de datos difusas, usando la lógica difusa. Este lenguaje ha sido implementado a nivel experimental y está evolucionando rápidamente. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 20 2.3.6 PHP PHP es un lenguaje de código abierto muy popular, adecuado para desarrollo web y que puede ser incrustado en HTML. Es popular porque un gran número de páginas y portales web están creadas con PHP. Incrustado en HTML significa que en un mismo archivo vamos a poder combinar código PHP con código HTML, siguiendo unas reglas. Esta característica permite generar páginas webs dinámicas, es decir, páginas cuyos contenidos pueden cambiar en base a los cambios que haya en una base de datos, de búsquedas o aportaciones de los usuarios, etc. Lo que distingue a PHP de JavaScript es que el código es ejecutado en el servidor, generando HTML y enviándolo al cliente como si fuera una página web estática. El cliente recibirá los resultados que el servidor devuelve después de interpretar el código PHP, sin ninguna posibilidad de determinar qué código ha producido el resultado recibido. Es decir, a través de nuestro navegador podríamos ver el código HTML, pero nunca el código PHP que dio lugar al resultado HTML. El servidor web puede ser incluso configurado para que los usuarios no puedan saber si estás o no utilizando PHP. 2.3.6.1 PhpMyAdmin PhpMyAdmin es una herramienta escrita en PHP con la intención de manejar la administración de MySQL a través de páginas web, utilizando un navegador web. Actualmente puede crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos, ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar datos en varios formatos y está disponible en 72 idiomas. 21 Despliegue de redes inalámbricas de sensores con Contiki 3 DISEÑO En este apartado se exponen las distintas etapas en las que se ha desarrollado cronológicamente el proyecto expuesto en este documento. Para reducir la complejidad y asegurar la evolución adecuada del sistema objetivo, se ha conseguido dividir el proyecto en tres fases, partiendo de los fundamentos de la red de comunicaciones hasta el tratamiento y presentación de la información recabada. La primera fase consiste en lograr establecer una comunicación entre las diferentes motas que conformarán la red final. Estas comunicaciones son del tipo UDP y el enrutado de la red es RPL. La labor de armar y organizar la red recaerá sobre una mota que actuará de servidor, a la cual enviarán el resto de motas la información del sensor de temperatura que tienen integrados. En la segunda fase, se sustituye la mota servidor por un border-router. Este border-router, además de realizar las mismas funciones que la mota servidora, incorpora la capacidad de establece una conexión TCP/IP con un ordenador. Gracias a esta conexión es posible acceder mediante consultas HTTP a la información de enrutado, y conocer la relación que el border-router ha creado entre las motas de la red. Para finalizar, se implementa el servidor LAMP en el ordenador que mantiene la conexión con el borderrouter. Este servidor gestiona la recepción y almacenamiento de los datos recibidos en el border-router, así como dotar al sistema de un método de acceso para el usuario de esos datos. 3.1 Entorno de desarrollo Para desarrollar todo el proyecto, se ha utilizado un entorno Linux. Este será ejecutado usando una imagen de la maquina virtual de Linux ejecutada en Virtual Box, no obstante, también podría utilizarse VMware. En este entorno, es posible hacer uso del programa Code Comporser Studio para la programación de los dispositivos en un entorno cómodo y la compilación se realizará desde el terminal, en el cuál también se cargarán los programas en los diferentes dispositivos. Por último, esta máquina virtual incluye diferentes simuladores, tanto de dispositivos como de redes de comunicación, para ejecutar y comprobar el funcionamiento de los códigos desarrollados antes de ser probados en los equipos físicos. El simulador a utilizar y por tanto instalar es Cooja, que permite crear y monitorizar redes de sensores y las comunicaciones entre motas. 3.1.1 Instalación de la máquina virtual La preparación del entorno Linux comienza por la instalación del software en el que se ejecutará la imagen de la máquina virtual. Desde "https://www.virtualbox.org/", es posible acceder al distribuidor de VirtualBox, desde el cual se descarga la versión 6.1 a fecha de este proyecto. Por otro lado, en "https://www.osboxes.org/lubuntu/" está disponible la descarga de una imagen de la maquina virtual de Lubuntu para ser ejecutada en VirtualBox. Lubuntu es un sistema operativo rápido y ligero, cuyo núcleo esta basado en Linux y Ubuntu, focalizado en la velocidad y la eficiencia, lo que permite ser ejecutado en sistemas con recursos limitados. Una vez instalado, en la ventana principal se debe importar la imagen de Lubuntu desde la pestaña de archivos. Antes de importarla se puede ver la información de sistema de la maquina virtual. Antes de ejecutarla y con la máquina virtual apagada, es necesario abrir la ventana de configuración y ajustar varios aspectos como se indica en la Figura 18:  Sistema: ajustar la memoria RAM, mínimo 2GB, y el número de núcleos al gusto.  Pantalla: elegir la memoria de vídeo, mínimo 32 MB.  Red: verifivar que el adaptador 1 se encuentra en modo NAT  USB: comprobar que el controlador de USB es al menos 2.0 (EHCI). Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 22 Figura 18. Ventana de configuración de VirtualBox. En esta situación, ya está preparado el entorno de desarrollo para su uso. 3.1.2 Descarga de Contiki-NG Desde el entorno de Lubuntu, el siguiente paso es descargar el toolchains (8) desde la aplicación terminal: 1. Instalar varias herramientas de desarrolo: primero se instalan varios paquetes mediante el comando "sudo apt install build-essential doxygen git curl python-serial srecord rlwrap". También es conveniente instalar "net-tools" con el comando "sudo apt-get install net-tools". 2. Instalar el compilador ARM: necesario para cargar los archivos binarios en plataformas CC2538DK o Zoul (que es el caso de este proyecto). Para instalar el compiador es necesario ejecutar el comando "sudo apt install gcc-arm-none-eabi" (Figura 19. Descarga del compilador ARM.). Figura 19. Descarga del compilador ARM. 3. Instalar el compilador MSP430: utilizado para las simulaciones. Ejecutando el comando "sudo apt install gcc-msp430" se descargará el compilador. 4. Descargar Contiki-NG desde su repositorio de Github (https://github.com/contiki-ng/contiki-ng). Además, es necesario actualizar los submodulos de la carpeta descargada de "contiki-ng" como se 23 Despliegue de redes inalámbricas de sensores con Contiki hace en la Figura 20. Figura 20. Descargar de Contiki-NG. 5. Instalar Java for Cooja: imprescindible para poder ejecutar el simulador Cooja (Figura 21. Descarga de orden ant para Cooja.). Figura 21. Descarga de orden ant para Cooja. En caso de necesitar más información, es posibe consultar la guía de Contiki-NG de los desarrolladores "https://github.com/contiki-ng/contiki-ng/wiki/Toolchain-installation-on-Linux". Con estos pasos, se habrá creado la carpeta "contiki-ng" (Figura 22), en la que están guardados los archivos de arquitecturas de plataformas soportadas, los archivos del SO, herramientas de simulación y varios ejemplos de Contiki-NG. Desde esta carpeta se desarrollará el diseño de los programas, la ejecución de simulaciones y la compilación y carga en las plataformas. Figura 22. Ubicación de carpeta "contiki-ng". 3.1.3 Preparación de archivo Cooja Para terminar, es necesario realizar una modificación en los archivos y carpeta del simulador Cooja para poder ejecutarlo. Se debe descargar el archivo de la dirección "https://search.maven.org/artifact/javax.xml.bind/jaxbapi/2.4.0-b180830.0359/jar" y guardarlo en "-/contiki-ng/tools/cooja/lib". Luego, hay que incluir el archivo .jar descargado en el archivo "-/contiki-ng/tools/cooja/build.xml", para lo cual hay que incluir en todos los apartados de <classpath> la localización del archivo descargado como se muestra en la Figura 23. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 30 la placa o un archivo fuente para ser compilado directamente en la aplicación. Figura 37. Creación de las motas para simulación. Tras crear cada mota, se pregunta cuantas se desea incluir en la simulación y su ubicación.Se colocan una mota "Z1-server" y tantas mota "Z1-client-temp" como se desee. También se podrán incluir más motas en otros momentos de la simulación si se desea ampliar la red, sin necesidad de repetir el proceso de creación. Para el caso de este documento se colocan tres motas cliente y una mota servidora (número 1). Su disposición se puede ver en la Figura 38, en la que la mota servidora tiene al alcance los nodos 2 y 3. La mota 4 no tiene alcance suficiente para tener transmisión directa con la mota servidor (número 1). El algoritmo RPL asignará como padré de la mota 4 la mota 3, quién reenviará todas las transmisiones a la mota servidor. Figura 38. Ubicación de motas. Una vez dispuesta la red, se puede ejecutar la simulación desde la ventana de control. Al iniciar, en la ventana de salida de las motas aparecerá la información del programa que se está ejecutando: versión del SO, capas de la pila de red y direcciones de enlace. En el caso del servidor, aparece el mensaje adicional del rutado DAG (Figura 39). 31 Despliegue de redes inalámbricas de sensores con Contiki Figura 39. Información de inicialización del nodo. Tras establecer el rutado, las motas clientes mandarán periódicamente un número aleatório simulando medir la temperatura. En el ejemplo de la , la mota 2 manda sus datos a la mota 1, la cual lo recibe y le responde para confirmar la recepción. En el mapa de la red se puede ver como los mensajes llegan también a las motas 4 y 3, pero dado que ninguno de los dos mensajes va dirigido a ellas (como se puede ver por las direcciones IPv6 del destino en el terminal) estas los ignoran. Figura 40. Transmisión de mensaje. Para los casos especiales como la mota 4 que no tienen alcance directo con el servidor, es interesante ver en el cronograma el momento en el que la mota 4 manda un mensaje (Figura 41, marca azul). Esta manda el mensaje, que solo llega a las motas 2 y 3 (marcas verdes), y tras procesarlo la mota 3 lo reenvía a la mota 1. De manera similar se produce la respuesta. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 32 Figura 41. Reenvío de mensajes en la red. Con esta simulación se puede afirmar el correcto funcionamiento de la red, con lo cual ya se pueden compilar los códigos fuente y cargarlos en las plataformas físicas para verificarlo. 3.2.4 Implementación de la red Tras haber comprobado en simulación que los programas funcionan correctamente, se procede a compilar los códigos en las plataformas finales. Primero hay que descomentar las lineas anteriormente modificadas del programa "udp-client-temp.c", ya que ahora se va a utilizar el sensor de temperatura de la plataforma "Zoul". Además, se deben indicar las coordenadas en las que se va a ubicar la motes, modificando el valor de las variables "x_coor" e "y_coor" (linea 68 del código) para ubicar el dispositivo en la interfaz de usuario. El segundo punto a considerar es el estado de la batería. Para asegurar la carga de estas, hay que extraer la batería del interior de la carcasa, desconectarla de la placa y medir el voltaje de sus terminales. En la Figura 42 se indica el montaje a realizar. Dado que el voltaje nominal viene especificado a 3.7V, se puede esperar un voltaje de hasta 4V a máxima carga. Por debajo del voltaje nominal, será necesario cargala, utilizando una fuente de alimentación regulable. En caso de no disponer de una, puede utilizarse un cargador de 5V estandar. Figura 42. Comprobación de batería. Tras asegurar a carga de la batería, se compila el programa correspondiente a cada mota, una con el código "udp-server.c" y tantas motas con el programa "udp-client-temp.c" como se deseen. A la hora de desplegar la red, se recomienda ubicar primero la mota servidor y posteriormente las motas 33 Despliegue de redes inalámbricas de sensores con Contiki cliente de una en una, y comprobar que cada nueva mota es capaz de comunicarse desde las ubicaciones escogidas. También deben colocarse de las más cercanas al servidor a las más lejanas, para que se pueda crear el enrutamiento adecuado con las motas intermediarias. En el caso de replicar el despliege de la Figura 38, las motas se desplegarían acorde al número que se la ha asignado a cada una. Para comprobar que una mota se ha desplegado correctamente, se debe conectar a través de un terminal serie a la mota servidor (apartado Figura 32). Con la mota servidor conectada al ordenador y la mota cliente que se desea comprobar desplegada, se reinician ambos equipos y se espera a que se reciba en el servidor un mensaje como el de la Figura 43. Mensajes recibidos en la mota servidor. Para confirmar que se trata de la baliza adecuada, se deben comprobar que las coordenadas recibidas se corresponden con las coordenadas esperadas según la ubicación, ya que a medida que se despliegue toda la red se recibirán mensajes de múltiples motas. Además se puede comprobar visualmente si una mota cliente está transmitiendo o no correctamente al servidor. Cada vez que una mota envía un mensaje, se invierte el estado de led rojo de la placa, y dado que el periodo de envío para esta prueba es de 10 segundos, es muy sencillo para un usuario realizar la comprobación. Figura 43. Mensajes recibidos en la mota servidor. Por último, cabe destacar que es recomendable, pero no imprescindible, cada vez que se despliega una nueva mota y comprobado que las anteriores tiene una comunicación estable, reiniciar las motas de la red. Esto se debe a que, si bien las nuevas motas se acabaría integrando eventualmente en el rutado de la red, este proceso es mucho más rápido si se reinicia el enrutamiento. 3.3 Comunicación con el border-router Al concluir la primera fase satisfactoriamente, se ha conseguido establecer una red de sensores centralizada y autoconfigurable. De esta manera ya es posible monitorizar la temperatura de una zona y recibir dicha información en un dispositivo terminal. La segunda fase del proyecto busca sustituir la mota servidor por otro dispositivo con mayores prestaciones y capacidades de comunicación: el border router Orion de Zolertia. Al incorporar este nuevo dispositivo, se busca dotar a la red de mayor conectividad con otros equipo. Se pretende encontrar la manera de conectar la red con un dispositivo final, con el objetivo de transmitir toda la información de la red a un almacenamiento final. 3.3.1 Programa del border-router La programación del border-router parte de las misma funciones de la mota servidora de la primera fase. A estas, se le suma la capacidad de comunicación de un ordenador con el border router Orion de Zolertia. Se usa el mismo funcionamiento de la red y de rutado de la primera fase, pero sustituyendo la mota servidor por el border-router, además de un acceso TCP/IP para acceder a una pagina web con la información del rutado de la Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 34 red. La configuración de la comunicación UDP se hace de manera similar a la primera fase. Para utilizar el servidor se debe incluir la librería "httpd-simple.h" y se puede consultar el ejemplo "rpl-border-route" como guía de utilización de la misma. En la carpeta de este ejemplo se encuentran los archivos fuente que configuran la conexión y página web. En el archivo "border-router.c" (apartado 6.2.1) se arranca un proto-hilo en el que se gestiona el servidor httpd. El objetivo de este protohilo es responder ante una solicitud HTTP que se realice desde fuera del border-router mostrando la información de rutado de la red. En la Figura 44, se recoge la jerarquía de funciones definidas para responder a una conexión TCP/IP con la información de la red. Al recibir una conexión, solo se necesita llamar a la función httpd_appcall() y definir el nombre de la función que genere las etiquetas HTML para el cliente TCP/IP. Figura 44. Jerarquía de llamadas a funciones httpd. El diseño de la página se realiza en la función especificada en el apartado "httpd_simple_get_script()". En este apartado se utilizan las macros "ADD" y "SEND" definidas en el propio archivo (Figura 45). ADD se utiliza para añadir etiquetas HTML al string que se envía al cliente al usar la macro SEND(s). Basandose en esto, se puede mostrar cualquier información contenida en el router, como es el caso del rutado en esta prueba. Figura 45. Definición de macros ADD y SEND. 3.3.2 Simulación con border-router Para simular el comportamiento de la red con el border-router, se partirá de la simulacion de la fase uno, sustituyendo la mota servidor por el router. Para simularlo, se utilizará la plataforma "sky" que viene incluida entre las plataformas de Cooja. Antes de incluirlo, es necesario la compilación previa del programa con la particularidad de incluir la sentencia SMALL=1 (Figura 46. Compilación para plataforma sky.) a la hora de compilar debido a las restrisciones de memoria de la plataforma. Figura 46. Compilación para plataforma sky. Una vez incluido el border-router de la misma manera que se realiza en la Figura 37, salvo que en este caso se 35 Despliegue de redes inalámbricas de sensores con Contiki trata de la plataforma Sky, se sustituye la mota servidor por el router. Opcionalmente se pueden redistrubir la red de acuerdo a la Figura 47 para que el rutado de la red sea más complejo. Antes de ejecutar la simulación es necesario hacer click derecho sobre el border-router en la ventana de red y acceder al menu "Mote tools > Serial Socket {SERVER}" para iniciar el puerto en la dirección 60001 y poder acceder a el. Figura 47. Comunicación y rutado de la red. Tras iniciar la simulación, hay que utilizar el comando "make TARGET=sky connect-router-cooja" y conectar con el border-router. Al hacer esto, se mostrará la información de inicio, de la cual hay que destacar la dirección IPv6 del servidor (en el caso de la Figura 48 es fd00::212:7401:1:101). Con esta dirección se puede comprobar si efectivamente el servidor es accesible, para lo cual es posible utilizar el comando "ping6" con la dirección a la que se desee pingear. En la Figura 49 se ve el tiempo que tarda cada paquete en enviarse y el tamaño de los paquetes enviados y recibidos. Figura 48. Conexión con el border-router en simulación. Figura 49. Prueba de dirección IPv6. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 36 Por último, si buscamos la dirección IPv6 del servidor en el navegador, se accede a la información de la red. Comparando la Figura 50 con la Figura 47 se puede comprobar que la información, tanto de vecinos al alcance del boreder-router como las relaciones jerárquicas entre las direcciones de las motas, se corresponde con las ubicaciones de las motas, su distancia al border-router y las motas intermedias. Figura 50. Información de rutado para el usuario. 3.3.3 Implementación del border-router Asegurado el acceso al border-router en simulación, se pasa a compilar y cargar el programa en el borderrouter con la red desplegada de la primera fase. En este caso, las palabras clave de la plataforma son "TARGET=zoul BOARD=orion". Tras la carga del programa, hay que conectarse al router. El comando para conectarse al border-router real es muy similar al empleado para el border-router de la simulación, modificando en este caso también TARGET y BOARD: "make TARGET=zoul BOARD=orion connectrouter". Figura 51. Conexión con el border-router. En la consola aparecerá de nuevo la información del border-router y, si se desea, se puede comprobar la conexión utilizando el comando "ping6" como se hace en el apartado anterior. Para corroborar finalmente que el border-router consigue correctamente enrutar y comunicar a toda la red, he accede a su dirección IPv6 desde un navegador y se visualizar el enrutado y las motas conectadas. Se podrá observa un enrutado y una jerarquía similar al de la Figura 50, dependiendo de la distribucion física de las motas. Así pues, se confirma la correcta integracion del border-router como maestro en las comunicación y gestión de la red y se procede a implementar la última fase del proyecto: la integración del servidor LAMP. 3.4 Comunicación con el servidor La última fase de este proyecto se divide en dos partes: dotar al border-router de la capacidad para comunicarse con el border-router y diseñar e implementar una aplicación que reciba, almacene, trate y muestre al usuario la información recogida por la red. La primera parte pretende ahondar en los mecanimos de 37 Despliegue de redes inalámbricas de sensores con Contiki comunicación que Contiki-NG proporciona para programar las comunicaciones del border-router, de entre los cuales se ha optado por las consultas HTTP. 3.4.1 Consulta HTTP desde el border-router Los recursos que proporciona Contiki-NG para comunicaciones HTTP se recogen en la carpeta "/os/net/applayer/http-socket" del repositorio "contiki-ng". En esta librería se definen funciones de HTTP, socket´s y servicios web. Para este proyecto solo son necesarias las funciones definicas en los archivos "http-socket", de cabecera (Figura 52) y fuente, y en concreto las que se explican a continuación:  http_socket_init(): función para inicializar un la estructura de datos utilizada para gestionar las siguientes conexiones del programa.  http_socket_get(): se envía una petición http utilizando el método get de transferencia de parámetros a la dirección url indicada. Para este proyecto, la dirección url debe comenzar por "http://[fd00::1]", indicando el tipo de petición y la direccion del servidor, seguido del directorio y el archivo al que queremos acceder. El objetivo de utilizar estas funciones, es la de reenviar los datos recibidos de los sensores al servidor. Para ello, cada vez que se recibe un mensaje UDP, se deben extraer los datos en la trama, construir una url apropiada y enviarla al archivo PHP del servidor que guardará los datos en el servidor. La extracción y construcción de la url es un tratamiento básico de cadenas de caracteres, sin embargo es importante diferenciar las dos fomas de paso de parámetros en HTTP. Figura 52. Definición de funciones para http-socket. 3.4.2 Envío de parámetros HTTP En los servicios web, internet y aplicaciones de servidores LAMP, existen dos formas básicas de envio de parámetros:  GET: la información enviada es visible para el usuario. Se realiza incluyendo al final de la url el nombre de cada dato y su valor, separando cada dato entre si mediante el caracter '&'. Es una manera muy sencilla reenviar parámetros entre peticiones, ya que es muy sencillo para cualquier programa secuencial concatenar los parámetros con la url. Es un método muy utilizado en aplicaciones que no requieran de privacidad o no sea crítico si el usuario los modifica (busquedas en Google, visualización de videos en Youtube, indicación de ubicaciones con Google Maps, etc).  POST: los datos no son accesibles para el usuario durante la transmisión. Muy adecuado para información de formularios o contraseñas, que deba ser privada y transmitida de forma segura. Es un método más complejo que el anterior debido a que conlleva un procesamiento mayor en las peticiones. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 38 Ya que la información de este proyecto son medidas de sensores e índices propios de cada mota, y a que la conexión se realiza de manera local y privada, el método get es más que suficiente para este proyecto y es más sencillo de procesar. Por esto se utiliza la función "http_socket_get()" en lugar de la función "http_socket_post()". 3.4.3 Conexión entre el border-router y el servidor Expuestas las herramientas de HTTP, ya es posible entender completamente el código "border-router.c". Pero antes de programar el router para que pueda realizar estas consultas, se necesita conocer la ubicación que el servidor tendrá para e lborderrouter cuando este se conecte. Esta ubicación es necesaria ya que todas las referencias a los archivos del servidor que guardaran los datos de los sensores parte de la dirección IP habilitada en la conexión. Para averiguar cual es esta dirección, se procede de la siguiente forma: 1. En primer lugar, hay que conectar el dispositivo Orion Ethernet Router (no es necesario que esté encendido) al ordenador en el que se este ejecutando la máquina virtual a través de un puerto USB 2.0 (es fundamental que el puerto sea 2.0 para que la máquina virtual pueda reconocer el dispositivo). Un vez conectado, hay que dirigirse a la parte inferior derecha de la interfaz y pulsar en el icono del conector USB. Se abrirá un menú desplegable como el de la Figura 53. En este menú se debe seleccionar el dispositivo "Silicon Labs Zolertia Orion Ethernet router" has que aparezca un check azul a la izquierda de este, indicando que se ha seleccionado correctamente. Figura 53. Menú de selección de dispositivos. 2. A continuación desde un terminal, se accede al directorio en el que se encuentre el programa que más adelante se cargará en el router dentro de "contiki-ng" (en el caso de este proyecto "contiking/TFM/rpl-border-router-server). Desde este directorio se ejecuta el comando "$make TARGET=zoul BOARD=orion connect-router" para abrir una conexión entre el router y el ordenador. En la Figura 54 se ve que la interfaz de conexión de este ejemplo es la "tun0". Figura 54. Conexión router-ordenador. 3. Tras identificar cual es la interfaz para el router, se necesita buscar la dirección ip que se ha abierto para el "host" de esta conexión. Abriendo una nueva consola (para mantener activa la conexión routerordenador), se ejecuta el comando "$ ifconfig", para motrar todas las interfaces que existen en el 39 Despliegue de redes inalámbricas de sensores con Contiki ordenador y es importante fijarse en el orden en el que estas aparecen. Para terminar, se ejecuta "hostname -I" para conocer todos las IP´s de las interfaces. Estas direcciones se mostrarán de manera ordenada de acuerdo al orden de las interfaces. Para este proyecto (Figura 55) la interfaz "tun0" ocupa la tercera posición, y para esta interfaz la dirección del host el "[fd00::1]". Figura 55. Interfaces habilitadas. Conociendo la dirección IP del host, ya se conoce cuál es la raíz de la URL a la que se tendrá que consultar desde el router, y por tanto ya es posible enviar mensajes desde el router al servidor. El siguiente paso es instalar la pila de software LAMP que permiter implementar el servidor en el ordenador final. 3.4.4 Instalación del servidor LAMP Como ya se ha expuesto en el apartado 2.3 de este documento, la preparación de toda la pila LAMP pasa por la instalación (10) de sus tres componentes principales: Apache2, Mysql-server y PHP. 3.4.4.1 Apache2 Para instalar el servidor Apache, se accederá al terminal de Linux y se utilizarán los comandos "$sudo apt update" y "$sudo apt install apache2". Tras la instalación, se puede utilizar el comando "$ apache2 -version " para comprobar que se ha instalado correctamente (Figura 56). Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 46 Figura 65. Pestaña de gráficas.  Pestaña de información: se explica el contexto y motivo por el que se ha desarrollado la aplicación y el proyecto. Figura 66. Pestaña de información. 3.4.6 Implementación del servidor Una vez comprendida la estructura del servidor y de la base de datos, se pasa a implementar los archivos que sostienen su funcionamiento. Junto a este documento se adjunta la carpeta "Web_TFM", donde se recogen todos los códigos HTML, PHP, JavaScript y CSS así como librerías adicionales que se han desarrollado para el funcionamiento de la aplicación web. Esta carpeta se debe ubicar en la carpeta "/var/www/html" (Figura 67), pues a esta se dirigen todas las conexiones TCP/IP que se realicen. Figura 67. Ubicación de la aplicación web. La segunda tarea para implementar el servidor es crear la base de datos y todas las tablas que la forman. Haciendo uso del terminar Linux y los comandos SQL indicados en el apartado 3.4.4.2 se debe crear una base de datos con la estructura que se especifica en el apartado 3.4.5.1. Es fundamental que todos los nombres de la base de datos, tablas y columnas se ajusten a los nombres indicados en inglés para que el resto de archivos de la aplicación puedan acceder a ellos. 47 Despliegue de redes inalámbricas de sensores con Contiki Figura 68. Manipulación de la base de datos desde el terminal Linux. La Figura 68 expone como acceder a MySQL desde un terminal con el usuario -root e introducir ejemplos de comandos SQL. Tras crear toda la base de datos completa, ya es posible comprobar el funcionamiento al completo del sistema conectando el border-router como en la segunda fase del proyecto. Una vez conectado el border-router, inmediatamente se verá un mensaje correspondiente a la primera conexión al servidor LAMP (Figura 69). Esta conexión tiene dos objetivos. El primero, realizar una comprobación del estado de la conexión (en caso de ser erróneo se verá un mensaje de "Socket Aborted" o similar, con lo cual será necesario rehacer la conexión). El segundo guardar la información de la ubicación de router en la base de datos. El router se verá como el nodo 0 en la interfaz, y desde el se irá ramificando toda la red. Figura 69. Recepción de mensajes de las motas en el router. A medida que se vayan recibiendo mensajes de las motas, estas se irán incluyendo en la interfaz, asignándoles un número y su información de enrutado (Figura 70). No es necesario apagar ni reiniciar las motas ya desplegadas con la prueba anterior, pues se irán enrutando y uniendo a la red a medida que vaya enviando las Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 48 medidas periodicamente (Figura 69). Para acceder a la aplicación web desde un navegador web, se utiliza la URL "http://localhost/ Web_TFM/". Desde ahí accederemos a la ventana principal de la aplicación tras proporcionar los credenciales de usuario. Figura 70. Visualización de la red desde la aplicación web. Desde la pestaña de mapa de la aplicación se pude comprobar el número de motas y las coordenadas en las que están ubicadas, de manera que se podrá comprobar de manera muy sencilla si alguna de las motas desplegadas no se ha conectado a la red. Figura 71. Visualización de datos. Para finalizar, en la pestaña de datos se pueden comprobar las información de los sensores que se ha recopilado hasta el momento. Se puede seleccionar la mota que queremos mostrar, el sensor (unicamente de temperatura para este proyecto) y el número de datos que queremos mostrar por gráfica. Actualizando la gráfica, aparecerán los datos empezando por los más antiguos que existen en la base de datos. Se muestran las fechas de la primera y la última medida mostrada y la hora de cada una de las que se visulizan. También es posible navegar por los datos haciendo uso de los botones "Back" y "Next", haciendo que se muestren los valores consecutivos según el número de datos por gráfica especificados. 49 4 CONCLUSIONES Este documento expone las herramientas, plataformas, métodos y fases necesarios en el diseño de una red inalámbrica de sensores basada en Contiki-NG y los dispositivos Zolertia. Se han detallado los pasos que se han seguido en el estudio desde cero para comprobar la viabilidad y consistencia de estás redes, y el máximo rendimiento que es posible alcanzar con estos sistemas. No hay duda de que las WAN serán un punto de extremo interés en el futuro próximo de las tecnologías de la información y las telecomunicaciones, concretamente en el campo cada vez más extendido del Internet of Things. Sin embargo, es importante tener en cuenta las limitaciones que estas redes y las aplicaciones que son factibles de implementarse con estos sistemas. El progreso debe ser seguro y considerando siempre cuales con los aspectos más importantes que se deben cuidar de cada proyecto. Personalmente, este proyecto me ha permitido completar mis conocimientos sobre telecomunicaciones, redes de comunicaciones, compiladores y librerías de programas, simulación de sistemas y gestión de conexiones enrutadas. 4.1 Trabajos futuros A partir de este proyecto, se abren multiples posibilidades para aumentar las capacidades y funciones de la red y la interfaz. Las ampliaciones más inmediatas del proyecto son:  Amplia el tamaño de la red, incorporando nuevos dispositivos con sensores diferentes de mayor interés.  Implementar dispositivos actuadores y emitir ordenes desde el servidor a los efectores finales de la red.  Extender las funcionalidades de interfaz de usuario y el servidor para realizar un procesamiento más intensivo de los datos de la red para extraer conclusiones de los datos.  Profundizar en la sincronización y la gestión de energías de toda la red, para extender el tiempo de trabajo de todos los dispositivos. Contiki-NG dispone de diferentes herramientas de sincronización de red y, dependiento de plataformas, diferentes herramientas de gestión de energía. Sin embargo, no ha sido posible profundizar en estos puntos en este proyecto, quedando como una de las siguientes continuaciones del mismo. Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 50 50 5 REFERENCIAS 1. Contiki-NG. [En línea] https://github.com/contiki-ng/contiki-ng/wiki. 2. Enrutado RPL. [En línea] https://github.com/contiki-ng/contiki-ng/wiki/Documentation:-RPL. 3. Comunicaciones UDP. [En línea] https://www.ionos.es/digitalguide/servidores/know-how/udp-user- datagram-protocol/. 4. Zolertia RE-Moter platform. [En línea] https://github.com/Zolertia/Resources/wiki/RE-Mote. 5. Zolertia Orion Ethernet IP64 Router. [En línea] https://github.com/Zolertia/Resources/wiki/Orion. . 6. Servidor Apache. [En línea] https://blog.infranetworking.com/que-es-apache-servidor/ , https://es.wikipedia.org/wiki/Servidor_HTTP_Apache. 7. Bases de datos. [En línea] https://concepto.de/base-de-datos/ , https://es.wikipedia.org/wiki/Base_de_datos. 8. Instalación en Linux del ToolChain. [En línea] https://github.com/contiki-ng/contiki-ng/wiki/Toolchaininstallation-on-Linux. 9. Compatibilidades Z1 - ReMote-revb. [En línea] https://github.com/Zolertia/Resources/wiki/Migrate-From- Z1-to-RE-Mote. 10. Instalación de la pila LAMP. [En línea] https://www.digitalocean.com/community/tutorials/como-instalar- en-ubuntu-18-04-la-pila-lamp-linux-apache-mysql-y-php-es. 11. Error de acceso denegado a usuario 'root'. [En línea] https://www.zeppelinux.es/corregir-error-1698- 28000-access-denied-for-user-rootlocalhost-en-mariadb-mysql/. 12. Consultas SQL. [En línea] https://www.w3schools.com/sql/default.asp. 51 Despliegue de redes inalámbricas de sensores con Contiki 6 ANEXO 6.1 Códigos de programas, comunicación entre motas 6.1.1 Udp-server.c /* INCLUDES */ #include "contiki.h" #include "net/routing/routing.h" #include "net/netstack.h" #include "net/ipv6/simple-udp.h" #include "sys/log.h" /* DEFINES */ #define LOG_MODULE "App" #define LOG_LEVEL LOG_LEVEL_INFO #define WITH_SERVER_REPLY 1 #define UDP_CLIENT_PORT 8765 #define UDP_SERVER_PORT 5678 static struct simple_udp_connection udp_conn; PROCESS(udp_server_process, "UDP server"); AUTOSTART_PROCESSES(&udp_server_process); /*------------------------------------------------------------------*/ static void udp_rx_callback(struct simple_udp_connection *c, const uip_ipaddr_t *sender_addr, uint16_t sender_port, const uip_ipaddr_t *receiver_addr, uint16_t receiver_port, const uint8_t *data, uint16_t datalen) { LOG_INFO("Received request '%.*s' from ", datalen, (char *) data); LOG_INFO_6ADDR(sender_addr); LOG_INFO_("\n"); #if WITH_SERVER_REPLY LOG_INFO("Sending response.\n"); simple_udp_sendto(&udp_conn, data, datalen, sender_addr); #endif } /*------------------------------------------------------------------*/ PROCESS_THREAD(udp_server_process, ev, data) { PROCESS_BEGIN(); /* Initialize DAG root */ NETSTACK_ROUTING.root_start(); LOG_INFO("DAG root started"); Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 52 52 /* Initialize UDP connection */ simple_udp_register(&udp_conn, UDP_SERVER_PORT, NULL, UDP_CLIENT_PORT, udp_rx_callback); PROCESS_END(); } /*------------------------------------------------------------------*/ 6.1.2 Udp-client-temp.c /* INCLUDES */ #include "contiki.h" #include "net/routing/routing.h" #include "random.h" #include "net/netstack.h" #include "net/ipv6/simple-udp.h" #include "dev/zoul-sensors.h" #include "dev/leds.h" #include "sys/log.h" /* DEFINES */ #define LOG_MODULE "App" #define LOG_LEVEL LOG_LEVEL_INFO #define WITH_SERVER_REPLY 1 #define UDP_CLIENT_PORT 8765 #define UDP_SERVER_PORT 5678 #define SEND_INTERVAL (10 * CLOCK_SECOND) #ifndef MOTE_X_COOR #define MOTE_X_COOR 100 #endif #ifndef MOTE_Y_COOR #define MOTE_Y_COOR 100 #endif static struct simple_udp_connection udp_conn; /*------------------------------------------------------------------*/ PROCESS(udp_client_process, "UDP client"); AUTOSTART_PROCESSES(&udp_client_process); /*------------------------------------------------------------------*/ static void udp_rx_callback(struct simple_udp_connection *c, const uip_ipaddr_t *sender_addr, uint16_t sender_port, const uip_ipaddr_t *receiver_addr, 53 Despliegue de redes inalámbricas de sensores con Contiki uint16_t receiver_port, const uint8_t *data, uint16_t datalen) { LOG_INFO("Received response '%.*s' from ", datalen, (char *) data); LOG_INFO_6ADDR(sender_addr); #if LLSEC802154_CONF_ENABLED LOG_INFO_(" LLSEC LV:%d", uipbuf_get_attr(UIPBUF_ATTR_LLSEC_LEVEL)); #endif LOG_INFO_("\n"); } /*------------------------------------------------------------------*/ PROCESS_THREAD(udp_client_process, ev, data) { SENSORS_ACTIVATE(cc2538_temp_sensor); static struct etimer periodic_timer; static char str[64]; uip_ipaddr_t dest_ipaddr; uint16_t x_coor = random_rand() % MOTE_X_COOR, y_coor = random_rand() % MOTE_Y_COOR; PROCESS_BEGIN(); /* Initialize UDP connection */ simple_udp_register(&udp_conn, UDP_CLIENT_PORT, NULL, UDP_SERVER_PORT, udp_rx_callback); while(1) { /* Send to DAG root */ int temp =cc2538_temp_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED); LOG_INFO("Sending Temp %d ( %d : %d ) to ", temp,x_coor,y_coor); LOG_INFO_6ADDR(&dest_ipaddr); LOG_INFO_("\n"); if(NETSTACK_ROUTING.node_is_reachable() && NETSTACK_ROUTING.get_root_ipaddr(&dest_ipaddr)) { leds_toggle(LEDS_RED); snprintf(str, sizeof(str), "php/ddbb_sv_dt.php?temp=%d&x_c=%d&y_c=%d",temp,x_coor,y_coor); simple_udp_sendto(&udp_conn, str, strlen(str), &dest_ipaddr); etimer_set(&periodic_timer,(SEND_INTERVAL)); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&periodic_timer)); } else { LOG_INFO("Not reachable yet\n"); Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 54 54 etimer_set(&periodic_timer,(CLOCK_SECOND + random_rand()%(2* CLOCK_SECOND))); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&periodic_timer)); } } PROCESS_END(); } /*------------------------------------------------------------------*/ 6.2 Códigos de programas, comunicación con router 6.2.1 Border-router.c /* INCLUDES */ #include "contiki.h" #include "net/routing/routing.h" #include "random.h" #include "net/netstack.h" #include "net/ipv6/simple-udp.h" /* Log configuration */ #include "sys/log.h" #include "net/ipv6/uip-ds6-nbr.h" #include "net/ipv6/uip-ds6-route.h" #include "net/ipv6/uip-sr.h" #include "httpd-simple.h" #include "contiki-net.h" #include "net/app-layer/http-socket/http-socket.h" #include "net/ipv6/uip-ds6.h" #include "ipv6/ip64-addr.h" #include <stdio.h> #include <string.h> /*-------------------------------------------------------------------- -------*/ static const char *TOP = "<html>\n <head>\n <title>Contiki- NG</title>\n </head>\n<body>\n"; static const char *BOTTOM = "\n</body>\n</html>\n"; const uint8_t x_router=20,y_router=30; static struct http_socket s; static int bytes_received = 0; static char buf[256]; static int blen; #define ADD(...) do { \ 55 Despliegue de redes inalámbricas de sensores con Contiki blen += snprintf(&buf[blen], sizeof(buf) - blen, __VA_ARGS__); \ } while(0) #define SEND(s) do { \ SEND_STRING(s, buf); \ blen = 0; \ } while(0); /* Use simple webserver with only one page for minimum footprint. * Multiple connections can result in interleaved tcp segments since * a single static buffer is used for all segments. */ #define LOG_MODULE "RPL BR" #define LOG_LEVEL LOG_LEVEL_INFO #define UDP_CLIENT_PORT 5678 #define UDP_SERVER_PORT 8765 #define NUM_OF_NODES 5+1 struct{ uip_ipaddr_t ip_mt; uint8_t id_pt; } motes_list[NUM_OF_NODES]; /* Declare and auto-start this file's process */ PROCESS(contiki_ng_br, "Contiki-NG Border Router"); AUTOSTART_PROCESSES(&contiki_ng_br); static struct simple_udp_connection udp_conn; /*-------------------------------------------------------------------- -------*/ int get_substring_index(const uint8_t *S,uint16_t sizeS, char subS[], uint16_t sizeSubS){ int index=-1,j=0; for(int i=0;i<sizeS;i++){ //printf("S(%c)\n",S[i]); if(S[i] == subS[0]){ for(j=0;j<sizeSubS;j++){ //printf("- S(%c) = subS(%c)\n",S[j+i],subS[j]); if(S[j+i] != subS[j]) break; } //printf("j=%d\n",j); if(j == (sizeSubS)){ index=i; //printf("ind=%d\n",index); } } } //printf("final ind=%d\n",index); return index; } Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 62 62 PSOCK_END(&s->sout); } /*-------------------------------------------------------------------- -------*/ PROCESS(webserver_nogui_process, "Web server"); PROCESS_THREAD(webserver_nogui_process, ev, data) { uip_ip4addr_t ip4addr; uip_ip6addr_t ip6addr; PROCESS_BEGIN(); uip_ipaddr(&ip4addr, 8,8,8,8); ip64_addr_4to6(&ip4addr, &ip6addr); uip_nameserver_update(&ip6addr, UIP_NAMESERVER_INFINITE_LIFETIME); httpd_init(); http_socket_init(&s); char str[128]; snprintf(str, sizeof(str), "http://[fd00::1]/Web_TFM/php/ddbb_sv_mt.php?id_mote=0&id_parent=0&x_c =%d&y_c=%d",x_router,y_router); http_socket_get(&s, str, 0, 0, http_callback, NULL); static struct etimer http_timer; etimer_set(&http_timer, 10 * CLOCK_SECOND); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&http_timer)); while(1) { PROCESS_WAIT_EVENT_UNTIL(ev == tcpip_event); httpd_appcall(data); } PROCESS_END(); } /*-------------------------------------------------------------------- -------*/ httpd_simple_script_t httpd_simple_get_script(const char *name) { return generate_routes; }