Diseño e implementación de actualizaciones Over The Air (OTA) para redes de sensores inalámbricas

Diseño e implementación de actualizaciones Over The Air (OTA) para redes de sensores inalámbricas David García Fernández GRADO EN INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID Trabajo Fin de Grado en Ingeniería Informática Curso 2018-2019 Director: Joaquín Recas Resumen en castellano El objeto de este trabajo es el estudio de la viabilidad de las actualizaciones de firmware Over The Air (OTA) utilizando una red LPWAN, en concreto LoRaWAN. Dar soporte para actualizaciones de firmware OTA a día de hoy resulta fundamental y más todavía cuando estos nodos se encuentran en lugares remotos o sitios donde el acceso es muy limitado o peligroso. Tener implementada la funcionalidad para actualizaciones vía OTA permite corregir errores o añadir nuevas funcionalidades a distancia. Uno de los objetivos prioritarios consiste en que la misma actualización pueda llegar a un conjunto de nodos a la vez evitando tener que actualizar los nodos uno por uno, ya que esto supondría el envío de gran cantidad de información duplicada. Para llevar a cabo esta tarea, se ha realizado un estudio en profundidad sobre las características y el funcionamiento de la red LoRaWAN teniendo en cuenta que las redes LPWAN en general dificultan llevar a cabo este tipo de actualizaciones debido a sus conocidas limitaciones en cuanto a tamaño de payload y elevada latencia. Finalmente, este trabajo demuestra la viabilidad de las OTA mediante la aplicación de parches de actualización de firmware a conjuntos de nodos. Palabras clave OTA Over The Air Pycom Lopy STM32L475 LoRa LoRaWAN Bajo consumo Firmware OTA LoRa Server Red de sensores Abstract The aim of this work is the study of the feasibility of firmware updates Over The Air (OTA) using an LPWAN network, specifically LoRaWAN. Supporting OTA firmware updates today is essential and especially when these nodes are located in remote places or places where access is very limited or dangerous. Having the functionality implemented for updates via OTA allows correcting errors or adding new functionalities remotely. One of the priority objectives is that the same update can reach a set of nodes at the same time, avoiding having to update the nodes one by one, since this would mean sending a large amount of duplicate information. To carry out this task, an in-depth study has been carried out on the characteristics and operation of the LoRaWAN network, considering that LPWAN networks in general are not the most suitable networks to carry out this kind of updates due to their known limitations in terms of payload size and high latency. Finally, this work demonstrates the viability of the OTA by applying firmware update patches to node sets. Keywords OTA Over The Air Pycom Lopy STM32L475 LoRa LoRaWAN Low Power Firmware OTA LoRa Server Sensor Network Índice general Índice i Agradecimientos iii 1. Introducción 1 2. Introduction 3 3. Estado del arte 5 4. LoRa y LoRaWAN 10 4.1. LoRa........................................ 10 4.2. LoRaWAN..................................... 11 4.2.1. Autenticación con LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Clases y ventanas de recepción . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. Formato tramas de datos LoRaWAN . . . . . . . . . . . . . . . . . . 18 4.2.4. Limitaciones Duty-cycle LoRaWAN . . . . . . . . . . . . . . . . . . . 20 4.3. Recapitulación .................................. 22 5. Gateway 23 5.1. Modosdefuncionamiento ............................ 23 5.2. Pruebasrealizadas ................................ 24 6. LoRa Server 33 6.1. Dependencias ................................... 35 7. Actualización de nodos vía OTA con LoRaWAN 37 7.1. MulticastconLoRaWAN............................. 38 7.2. Actualizando un nodo vía OTA . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.2.1. Sincronización del reloj . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.2.2. Configuración del grupo multicast . . . . . . . . . . . . . . . . . . . . 45 7.2.3. Fragmentación de paquetes . . . . . . . . . . . . . . . . . . . . . . . . 45 7.2.4. Ventanaderecepción........................... 46 7.2.5. Recepción del nuevo firmware . . . . . . . . . . . . . . . . . . . . . . 47 7.3. Redundancia ................................... 51 7.4. Seguridad en las actualizaciones . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.5. Consumo...................................... 54 7.6. Actualizando múltiples nodos . . . . . . . . . . . . . . . . . . . . . . . . . . 55 i 7.7. Actualizacionesdelta............................... 56 7.8. Almacenamiento ................................. 61 7.9. Pruebas fuera del laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . 62 8. Conclusiones 65 9. Conclusions 67 Bibliografía 70 A. Mensajes para la creación de un grupo Multicast 71 A.1. Sincronización del reloj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 A.2. Configuración del grupo multicast . . . . . . . . . . . . . . . . . . . . . . . . 72 A.3. Fragmentación de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.4.Ventanaderecepción............................... 75 ii Agradecimientos Al Departamento de Arquitectura de Computadores y Automática y en especial a mi tutor, Joaquín Recas, por ofrecerme la posibilidad de investigar en un campo tan interesante como son las redes LPWAN. iii Capítulo 1 Introducción En los últimos años hemos visto un crecimiento muy importante en cuanto al número de dispositivos IOT, la gran mayoría de las estadísticas1coinciden en que en un futuro no muy lejano llegaremos hasta los 75 mil millones de dispositivos conectados. Con este ritmo de crecimiento las redes tradicionales se han quedado obsoletas, por lo que estos dispositivos están demandando redes de bajo consumo y largo alcance. Este tipo de tecnologías se denominan LPWAN o Low Power Wide Area Network. Las redes LPWAN son redes utilizadas para cubrir un área muy extensa con un bajo consumo de energía; esto permite que los nodos puedan estar situados en lugares remotos alimentándose con una batería durante largos periodos de tiempo. A diferencia de las redes tradicionales que cuentan con un gran ancho de banda y bajas latencias, las redes LPWAN tienen un ancho de banda muy limitado y una alta latencia, es por esto que estas tecnologías no están orientadas a la transmisión de datos en tiempo real. Las tecnologías LPWAN utilizan una banda denominada ISM (Industrial, Scientific and Medical); esta banda puede utilizarse de forma libre siempre y cuando se cumplan unos requisitos mínimos, estos requisitos consisten en respetar la potencia máxima de transmisión y el tiempo máximo que se puede ocupar el medio. En Europa esta banda corresponde con los rangos de frecuencia 861-870 MHz y los tiempos máximos que se puede ocupar el medio que van desde el 0,1 %, 1 % y el 10% en función de la frecuencia concreta que se esté utilizando. 1https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/ 1 Con este proyecto se pretende estudiar las distintas opciones y su viabilidad para que una red de sensores inalámbricos pueda recibir actualizaciones de firmware utilizando una red LoRaWAN. Una red de sensores inalámbricos es un conjunto de nodos que tienen instalados una serie de sensores para medir diferentes variables. También cuentan con al menos un módulo de radio que puede encontrarse ya instalado en la placa o acoplarse externamente; este módulo es el responsable de la comunicación por radio con un servidor de aplicación. Habitualmente en los nodos IOT se pueden configurar parámetros que afectan al funcionamiento (periodos de muestreo, tipo de filtrado, etc.). Este tipo de nodos IOT además de soportar todo lo anterior pueden utilizar la radio para recibir actualizaciones de software. Esto nos ofrece la posibilidad de actualizar el firmware de uno o más nodos que podrían estar fácilmente a más de 20 kilómetros de distancia de la antena receptora más cercana. Estos dispositivos IOT llevan dentro de su microcontrolador un programa informático llamado firmware, este programa, que es el encargado de la gestión completa del nodo, es el que pretendemos actualizar; habitualmente estos programas no tienen un gran tamaño y se programan en lenguajes como C y C++. El firmware habitualmente se encuentra en la memoria flash del propio microcontrolador y permanece en ejecución mientras el nodo se encuentra alimentado lo que dificulta enormemente su actualización. 2 Capítulo 2 Introduction In recent years we have seen a very important growth in the number of IOT devices, the vast majority of statistics agree that in the not too distant future we will reach up to 75 billion connected devices. With this growth rate, traditional networks have become obsolete, so these devices are demanding networks with low power consumption and long range. These types of technologies are called LPWAN or Low Power Wide Area Network. LPWAN networks are used to cover a very large area with low energy consumption, allowing the nodes to be located in remote places feeding on a battery for long periods of time. Unlike traditional networks, that have high bandwidth and low latencies, LPWAN networks have a very limited bandwidth and high latency, which is why these technologies are not ideal for real-time data transmission. LPWAN technologies use a band called ISM (Industrial, Scientific and Medical).This band can be used freely as long as minimum requirements are met. These requirements consist of respecting the maximum transmission power and the maximum time that the medium can be occupied. In Europe, this band corresponds to the frequency ranges 861-870 MHz and the maximum times that can be occupied by the medium, range from 0.1 %, 1% and 10 % depending on the specific frequency that is being used. This project aims to study the different options and their feasibility so that a wireless sensor network can receive firmware updates using a LoRaWAN network. A network of wireless sensors is a set of nodes that have installed a series of sensors to measure different 3 Capítulo 4 LoRa y LoRaWAN Es importante tener claras las diferencias existentes entre LoRa y LoRaWAN, a continuación se explica de forma detallada que es cada una. 4.1. LoRa LoRa es el nombre de la modulación utilizada para transmitir datos a bajo nivel y que permite alcanzar grandes distancias con un bajo consumo de energía, su equivalente en el modelo OSI sería el modelo físico, o dicho de otra forma, es la forma en la que se codifica la información que se transmite de forma inalámbrica. Algunas de las características más importantes que nos ofrece LoRa son las siguientes: Muy bajo consumo, ideal para dispositivos con baterías. Largo alcance. Tamaño de payload limitado (hasta 255 Bytes). No se requiere licencia para utilizarlo en las bandas asignadas. Soporte para comunicación bidireccional. Las frecuencias sobre las que trabaja LoRa varían en función de la zona del mundo en la que nos encontremos, a continuación una breve tabla que muestra las principales frecuencias LoRa1y la zona en la que se utilizan: 10 Zona Frecuencia Europa 863-870 MHz Estados Unidos 902-928 MHz Australia 915-928 MHz China 470-510 & 779-787 MHZ Cuadro 4.1:Tabla de frecuencias LoRa1 4.2. LoRaWAN LoRaWAN5es una capa que trabaja sobre LoRa y que añade nuevas funcionalidades muy interesantes, algunas características son: Comunicaciones cifradas con AES-128. Diferentes clases para los nodos. El tamaño del payload se reduce debido a la información extra que añade LoRaWAN a la trama como porcentaje de batería, MIC (Message Integrity Code), etc... Posibilidad de tener redes públicas y privadas. Topología en estrella. 11 Figura 4.1:Esquema LoRaWAN Fuente: https://lora-alliance.org En la figura [4.1] podemos ver la estructura que sigue LoRaWAN, en la parte izquierda se encuentran los nodos o dispositivos finales, a continuación los gateways que son los responsables de recibir y transmitir mensajes desde/hacia los nodos, a su vez los gateways se comunican con el servidor responsable de la aplicación mediante un protocolo conocido por ambos, habitualmente MQTT [6.1] o UDP en ambos casos usando JSON pero con una estructura de mensaje diferente. UDP es un protocolo de la capa de transporte muy rápido, no orientado a conexión y utilizado en aplicaciones donde la latencia es muy importante. En UDP no hay retransmisión de tramas perdidas. JSON o JavaScript Object Notation, es un formato de texto utilizado para el intercambio de información entre procesos. JSON es ampliamente utilizado por lo que encontramos librerías para extraer la información en la mayoría de lenguajes de programación. 4.2.1. Autenticación con LoRaWAN Con LoRaWAN es imprescindible que cada dispositivo esté dado de alta en una base de datos antes de comenzar a transmitir, si el dispositivo transmitiera antes de ser dado de alta 12 la aplicación automáticamente descartaría estos paquetes. Existen dos formas de realizar este proceso, a continuación se detallan las ventajas e inconvenientes de cada una de ellas. Activation by Personalization (ABP) La podríamos definir como una activación estática, cada nodo ya lleva configuradas las claves ’Network session key’ y ’Application session key’ de forma estática, por ejemplo, como constantes en el código fuente. Estas claves van a ser siempre las mismas y en caso de que otra persona se hiciera con ellas podría acceder a toda la información transmitida con destino/origen el nodo afectado. Algunas de sus características son: Menor uso de la red, no se transmite el paquete JOIN REQUEST hacia el gateway ni la posible respuesta desde el gateway JOIN ACCEPT. Menor seguridad por usar claves estáticas. Parámetros de red que se pueden establecer de forma dinámica mediante el paquete de respuesta a un JOIN REQUEST quedan establecidos de forma estática. Para que el nodo pueda funcionar en modo ABP debe disponer de al menos las claves ’Network session key’, ’Application session key’ y un ’Dev EUI’[4.2.1]. Además es necesario que el nodo esté dado de alta en la aplicación con las mismas claves. 13 Figura 4.2:Configuración de las claves de sesión de forma manual para el método de autenticación ABP. La figura [4.2] es una captura de pantalla de la aplicación Lora-App-Server instalada en nuestro servidor donde podemos ver los datos necesarios para dar de alta un nuevo nodo con autenticación ABP. Over-the-Air Activation (OTAA) Con este método de activación los nodos generan las claves de sesión ’Network session key’ y ’Application session key’ en el momento en el que quieren unirse a la red, en primer lugar envían un paquete JOIN_REQUEST el cual es verificado por la aplicación donde dichos nodos están registrados, si todos los datos son correctos la aplicación autoriza el acceso mediante el envío de un paquete JOIN_ACCEPT; el nodo utilizará los datos contenidos en este paquete para generar las claves de sesión. Algunas de sus características son: Configuración de parámetros de red como ’RxDelay’ de forma dinámica mediante la respuesta JOIN_ ACCEPT. Mayor seguridad por usar claves dinámicas, las claves se generan de forma dinámica mediante los datos contenidos en el paquete JOIN_ACCEPT. 14 Hay que tener en cuenta que no todos los dispositivos soportan la activación OTAA. Para utilizar este método de autenticación es necesario configurar ’App EUI’, ’App Key’, ’Dev EUI’: App EUI: Identifica la aplicación a la que van dirigidos los datos, es decir, que aplicación debe tratar los mensajes de los nodos. App Key: Es una clave ’maestra’, se utiliza para establecer la conexión con la aplicación y generar las claves de sesión (NwkSKey y AppSKey). Dev EUI: Es un identificador único habitualmente establecido por el fabricante, es equivalente a por ejemplo una dirección MAC y sirve para identificar a un dispositivo de forma única. Figura 4.3:Paquetes ’JOIN REQUEST’ Y ’JOIN ACCEPT’ en LoRa App Server (autenticación OTAA). En la siguiente figura [4.4] podemos observar como las claves han sido generadas de forma dinámica y por tanto no se nos permite modificarlas. 15 Figura 4.4:Claves generadas de forma dinámica al unirse el nodo a la red utilizando OTAA como método para la autenticación. Es importante añadir que no debemos enviar el mensaje JOIN REQUEST por cualquier frecuencia, la documentación de LoRaWAN nos indica que tres canales podemos utilizar para enviar nuestro mensaje JOIN REQUEST. Ver figura [4.5]. Es obligatorio que estos tres canales estén soportados por todos los nodos, el resto de canales son de libre elección dentro de la banda asignada. Figura 4.5:Frecuencias en las que podemos enviar un mensaje JOIN REQUEST. Fuente: https://lora-alliance.org LoRaWAN Regional Parameters 4.2.2. Clases y ventanas de recepción En LoRaWAN existen tres modos de funcionamiento diferentes denominados clases, en función de cuál de ellas estemos utilizando podremos recibir datos desde un gateway en cualquier momento, en momentos programados o únicamente después de que el nodo transmita. Clase A: por lo general la más utilizada debido a su bajo consumo, el nodo únicamente 16 puede recibir datos durante un breve periodo de tiempo después de una transmisión. Después de realizar una transmisión el nodo abre la ventana de recepción RX1 en la misma frecuencia sobre la que ha realizado la transmisión. La ventana de recepción RX2 se abre en función de la configuración previa establecida mediante el comando RXParamSetupReq. Figura 4.6:Ventanas de recepción LoRaWAN para dispositivos de la clase A. Fuente: https://lora-alliance.org Clase B: el nodo puede recibir datos sin necesidad de tener que transmitir antes, el gateway está programado para emitir balizas de sincronización de forma periódica1 y los nodos reciben estas balizas. Gracias a esto el gateway puede calcular en que momento el nodo estará a la escucha y realizar la transmisión en dicho momento. Clase C: el nodo está siempre a la escucha, mayor consumo y no recomendable para dispositivos que funcionen con baterías, puede recibir datos transmitidos por el gateway en cualquier momento excepto si en dicho momento el nodo estuviera transmitiendo. 1Habitualmente 128 segundos. 17 Figura 4.7:Ventanas de recepción LoRaWAN para dispositivos de la clase C. Fuente: https://lora-alliance.org 4.2.3. Formato tramas de datos LoRaWAN En la figura [4.8] podemos observar el formato que tiene una trama downlink, es decir, datos enviados por el servidor hacia los nodos, los campos PHDR y PHDR_CRC son campos que se rellenan por el transmisor, PHYPayload corresponde con los datos que añade nuestra aplicación y Preamble que se utiliza para sincronizar el receptor. Figura 4.8:Formato mensaje LoRaWAN enviado desde el servidor hacia los nodos. Fuente: https://lora-alliance.org Por el contrario, la figura [4.9] muestra el formato que tiene una trama uplink, es decir, datos enviados por los nodos hacia el servidor, los campos PHDR, PHDR_CRC y CRC son campos que se rellenan por el transmisor, PHYPayload corresponde con los datos que añade nuestro nodo y Preamble al igual que en el caso anterior que se utiliza para sincronizar el receptor. Figura 4.9:Formato mensaje LoRaWAN enviado por los nodos hacia el servidor. Fuente: https://lora-alliance.org 18 Los tipos de mensajes que nos podemos encontrar en LoRaWAN son los siguientes [4.10] Figura 4.10:Tipos de mensajes soportados por LoRaWAN. Fuente: https://lora-alliance.org Los mensajes Join-request y Join-accept corresponden a los mensajes intercambiados entre el nodo y la aplicación cuando un nodo solicita unirse mediante OTAA. Ver más en el apartado [4.2.1]. Mensajes Unconfirmed Data Up y Unconfirmed Data Down corresponden a mensajes de datos enviados por los nodos y la aplicación respectivamente y que no tienen que ser confirmados, es decir, no hay que enviar un ACK como acuse de recibo. Mensajes Confirmed Data Up y Confirmed Data Down igual que los anteriores, corresponden a mensajes de datos enviados por los nodos y la aplicación respectivamente y que tienen que ser confirmados mediante el envío de un ACK. El mensaje de confirmación ACK se puede combinar con otros datos en el mismo mensaje. Rejoin-request este mensaje solo puede ser enviado por los nodos que se han unido utilizando como método de autenticación OTAA, sirve para re-inicializar una sesión, esto es útil si queremos cambiar algún parámetro que fue establecido en la antigua sesión o si por algún motivo perdemos el contexto de la sesión. El mensaje Proprietary nos permite definir dentro del protocolo nuestro propio formato de mensaje. Dado que este formato lo desarrollaríamos nosotros, sería responsabilidad 19 porque este software también funciona sobre otras placas. La prueba realizada ha consistido en el envío de paquetes de 1 byte desde una placa PyCom con autenticación ABP, factor de propagación 7 y un ancho de banda 125 KHz. Durante la prueba se ha podido comprobar que pese a las limitaciones que tiene la tasa de paquetes perdidos ha sido realmente baja. Este gateway se podría considerar una buena alternativa para los casos en los que no es necesaria la comunicación con los nodos. Para nuestro proyecto no es una opción a considerar porque la actualización de nodos requiere del envío de datos hacia los nodos. Otro inconveniente que surge es que al no contar con transmisión de paquetes no se puede utilizar el mecanismo de autenticación OTAA, estando limitado únicamente a ABP. Este gateway no soporta el protocolo MQTT por lo tanto para utilizarlo con LoRa Server debemos hacer uso de la herramienta LoRa Gateway Bridge. Figura 5.3:Arranque del programa single_chan_pkt_fwd Módulo Precio Raspberry PI 3 B+ 40 e RFM95W 7 e Cables para conexión 2 e Total: 49 e Cuadro 5.2:Coste de los componentes para montar este proyecto. 26 Para este gateway no se han medido los consumos porque al no permitir la transmisión de paquetes no resulta relevante. 2. En segundo lugar se pone a prueba el proyecto https://github.com/JaapBraam/ LoRaWanGateway, este proyecto a diferencia del anterior si cuenta con la funcionalidad para transmitir datos hacia los nodos. Para poner en marcha este proyecto es necesario disponer de un módulo ESP826611 y un módulo RFM95W [3.3]. ESP PIN RFM95W PIN D1 (GPIO5) DIO0 D2 (GPIO4) DIO1 D5 (GPIO14) SCK D6 (GPIO12) MISO D7 (GPIO13) MOSI D0 (GPIO16) NSS GND GND 3.3V VCC Cuadro 5.3:Tabla de conexiones del módulo RFM95W con ESP8266. Figura 5.4:Montaje de un gateway con un módulo ESP8266 y RFM95W Las pruebas realizadas consistieron en el envío de un determinado número de paquetes desde una placa STM32L4 [3.2]. Se enviaron un total de 50 paquetes con un payload de un byte, autenticación OTAA, un factor de propagación de 7 y un ancho de banda 27 de 125 KHz, el tiempo entre los envíos fue de 3 segundos. Como el gateway solo puede estar a la escucha en un único canal se optó por configurar en ambos dispositivos la frecuencia 868.100 MHz; es importante recordar que este gateway no soporta MQTT y en el caso utilizar LoRa Server debemos usar LoRa Gateway Bridge para realizar la conversión de UDP a MQTT. Figura 5.5:Consola del gateway ESP8266 La siguiente figura [5.6] es un recorte de la aplicación LoRa App Server donde podemos observar parte de los paquetes recibidos durante la prueba. Figura 5.6:Extracto donde podemos observar parte de los paquetes recibidos durante la prueba. 28 Desplegando cualquiera de los paquetes de la figura anterior podemos observar la configuración de la modulación LoRa: Figura 5.7:Extracto de uno de los paquetes recibidos donde se ve la configuración utilizada para la transmisión. Después de realizar las pruebas anteriores junto con las pruebas de OTA se determina que este gateway no es válido para este proyecto por los siguientes motivos: Solo puede recibir datos de un único canal. El gateway se reinicia con errores PANIC aleatorios. El gateway no puede enviar datos en la frecuencia asignada al downlink del firmware. A pesar de que con paquetes de tamaño 1 byte el resultado ha sido muy bueno, durante las pruebas de OTA se observa que con paquetes de un tamaño más grande la sincronización no es buena y se pierden muchos paquetes. Consumos ESP8266 + RFM95W Arranque Máximo tras varios encendidos: 94 mA Escuchando Entre 40-50 mA Transmitiendo Entre 90-100 mA Cuadro 5.4:Tabla de consumo gateway módulo ESP8266 29 Figura 5.8:Gráfico de consumo gateway módulo ESP8266 Los consumos se han medido con un multímetro conectado en serie. En la siguiente tabla [5.5] se encuentra detallado el coste para montar este gateway. Módulo Precio ESP8266 3 e RFM95W 7 e Cables para conexión 2 e Total: 12 e Cuadro 5.5:Coste de los componentes para montar este proyecto. 3. Finalmente se optó por probar un gateway comercial, modelo ’Sentrius RG1xx’2. Este gateway comercial soporta tanto LoRa como LoRaWAN, dispone de conexión Ethernet, Wifi y Bluetooth, soporta y detecta todos los factores de propagación y puede tanto recibir como transmitir por cualquiera de los canales que componen la banda LoRa 868 MHz en Europa. A diferencia del fabricado por Multitech que viene con una 2https://www.lairdconnect.com/wireless-modules/lorawan-solutions/sentrius-rg1xx-lora-enabledgateway-wi-fi-bluetooth-ethernet 30 versión de Node-Red instalada, este no permite la instalación de ningún paquete. Figura 5.9:Gateway Sentrius RG1xx Figura 5.10:Pantalla inicial del gateway Sentrius RG1xx 31 Se realizaron las mismas pruebas que las realizadas a los gateways anteriores, se utilizó la placa STM32L4 con un factor de propagación de 7, un ancho de banda de 125 KHz, autenticación OTAA y sin ninguna restricción en cuanto al canal a utilizar. El porcentaje de paquetes recibidos fue del 100 %. Como la actualización de firmware es un proceso delicado y pretendemos tener la mayor eficiencia posible, utilizaremos este gateway para realizar todas las pruebas de OTA. Este gateway soporta el protocolo MQTT por lo que no necesitaremos ningún software adicional para que funcione con LoRa Server. El precio de este gateway es de 219,00e3 3https://es.farnell.com/laird-technologies/rg186/gateway-868mhz-wifi-blu-eth/dp/2802548 32 Capítulo 6 LoRa Server LoRa Server1es un proyecto libre compuesto por múltiples aplicaciones para gestionar de forma sencilla la comunicación entre una aplicación en un servidor y los nodos. LoRa Server soporta la comunicación bidireccional, es decir, podemos tanto enviar mensajes hacia los nodos como recibirlos. A continuación se detallan las tres aplicaciones del proyecto que vamos a utilizar en este trabajo: LoRa Server es el corazón del proyecto, es el encargado de gestionar todas las tramas recibidas/enviadas desde/hacia los nodos, comprueba la integridad de los mensajes, gestiona las conexiones OTAA [4.2.1], envía las balizas en caso de que estemos trabajando con la clase B, en general gestiona toda la conexión inalámbrica. LoRa Server no tiene ningún tipo de interfaz gráfica, la única forma de comunicarse con el servidor es mediante los comandos gRPC. gRPC, Remote Procedure Call, es un framework desarrollado por la empresa Google que funciona sobre el nuevo protocolo HTTP/2.0; gRPC se utiliza para la conexión entre servicios. La ventaja que ofrece es que estos servicios pueden estar desarrollados en diferentes lenguajes de programación e incluso ejecutándose sobre plataformas diferentes. LoRa App Server es una interfaz gráfica para LoRa Server, se comunica con este 1https://www.loraserver.io 33 mediante el protocolo gRPC. LoRa App Server ofrece una API muy completa para comunicarnos con LoRa Server y poder tratar los datos que recibimos de nuestros nodos directamente con una aplicación creada por nosotros para su gestión. La API de LoRa App Server soporta los protocolos gRPC y REST. LoRa Gateway Bridge es un software que convierte los datos de los paquetes del protocolo UDP en paquetes del protocolo MQTT y viceversa, esto es necesario con algunos gateways que no soportan el protocolo MQTT y se vuelve necesario realizar la conversión para que sea compatible con LoRa Server. Figura 6.1:Arquitectura del proyecto LoRa Server con sus múltiples aplicaciones. Fuente: https://www.loraserver.io/overview/architecture/ 34 En la figura [6.1] podemos observar cómo se comunican las diferentes aplicaciones que componen LoRa Server, en el centro nos encontramos con el broker MQTT, tanto los gateway como LoRa Server están subscritos a una serie de canales para recibir los mensajes, por ejemplo, para los gateway estos canales tienen el formato gateway/IDENTIFICADOR_GATEWAY/. Continuando por la parte superior vemos que el siguiente salto sería o bien el propio gateway en el caso de soportar el protocolo MQTT o bien el software encargado de realizar la conversión de MQTT a UDP. De la mitad de la figura hacia abajo se encuentran todos los servicios que funcionan con LoRa Server y nuestra aplicación. 6.1. Dependencias Para que LoRa Server funcione correctamente debemos instalar antes las siguientes dependencias: Servidor con soporte MQTT 3.1.1 o superior, por ejemplo, el servidor Mosquitto.2 MQTT3es un protocolo de comunicación máquina a máquina muy ligero y útil en entornos donde contamos con ancho de banda muy limitado. Su funcionamiento se basa en una jerarquía de ’topics’ a los que nos podemos subscribir para recibir mensajes. Por ejemplo, vamos a suponer que tenemos colocados nodos a ambos lados de una calle, los nodos del lado izquierdo enviarán sus mensajes al topic /nodos/calle/izquierda, mientras que los del lado derecho lo harían a /nodos/calle/derecha, por otro lado, una aplicación que tuviera que recibir los mensajes de todos los nodos, independientemente del lado de la calle en el que se encuentren estaría subscrita a /nodos/calle/#. El comodín #sustituye todos los niveles que queramos hacia abajo. El comodín +únicamente lo utilizamos para un único nivel, por ejemplo, /nodos/+/temperatura, que nos daría la temperatura de /nodos/1/temperatura,/nodos/2/temperatura, etc... 2Mosquitto es un servidor de código libre que implementa los protocolos MQTT 3.1, 3.1.1 y 5.0, es un servidor muy ligero y de código libre que se encuentra disponible para la mayoría de las plataformas actuales. 3Message Queue Telemetry Transport 35 Figura 7.4:Alta de un nuevo dispositivo ABP. Una vez hemos configurado nuestra aplicación en LoRa-App-Server es momento de trabajar con el nodo. En este ejemplo se pretende actualizar el firmware mediante una actualización de tipo delta (ver apartado [7.7]). Este tipo de actualización se limita a enviar los cambios entre el firmware guardado en los nodos y el nuevo firmware. En la siguiente figura se puede observar el fragmento de código que ha sido insertado. Figura 7.5:Nuevo código insertado en el firmware. 42 Antes de compilar el nuevo firmware debemos hacer una copia del firmware actual, esto nos va a permitir crear la actualización delta comparando ambos firmware. Una vez tenemos una copia del firmware podemos compilar el nuevo código: $ mbed compile -m DISCO_L475VG_IOT01A -t GCC_ARM --profile=./profiles/tiny.json El siguiente paso es generar y firmar el parche, para esto se utiliza el siguiente comando: $ lorawan-fota-signing-tool sign-delta --old old.bin --new new.bin --output-format bin -o signed-diff.bin Por último dividimos el parche en fragmentos de hasta 204 bytes, en este punto debemos decidir cuantos paquetes de redundancia queremos añadir. Para la placa que estamos utilizando y debido a las limitaciones de memoria, el máximo es de 39 paquetes de redundancia. $ lorawan-fota-signing-tool create-frag-packets -i signed-diff.bin --output-format plain --frag-size 204 --redundancy-packets 32 -o fragmentos Con esto daríamos por concluida la parte de preparación de la actualización. Es momento de, sabiendo que nodos son los que vamos a actualizar, darlos de alta en el script encargado de tal gestión. Para ello modificamos el fichero loraserver.js dentro de la carpeta fuotaserver. En la siguiente figura podemos observar algunos nodos de pruebas comentados y un único nodo para actualizar (el que no está comentado). En la parte inferior aparece el identificador del dispositivo encargado del broadcast, este id corresponde con el generado al dar de alta el dispositivo ABP [7.2]. 43 Figura 7.6:Identificadores de los nodos que se van a actualizar. Llegados a este punto no queda más que lanzar el software encargado de las actualizaciones en el servidor e ir viendo como es este proceso. Para ello ejecutamos el siguiente comando: $ node loraserver.js fragmentos Subscribed to all application events A partir de este momento comienzan a intercambiarse entre el servidor y los nodos una serie de mensajes para preparar la descarga multicast, a continuación se muestra por diferentes secciones cada uno de los pasos. Recordar también que en el Apéndice [A] se encuentra un listado con todo detalle de cada uno de los mensajes intercambiados y sus campos. 7.2.1. Sincronización del reloj El primer paso para crear un grupo multicast es sincronizar el reloj de todos los nodos, es muy importante tener la hora correctamente sincronizada en los nodos para que estos puedan abrir la ventana de recepción en el momento justo y no pierdan ningún paquete, esto se puede realizar de dos maneras, el nodo puede enviar un mensaje AppTimeReq como en este caso o el servidor puede forzar la actualización mediante un mensaje ForceDeviceResyncReq. Lo 44 normal es que sea el nodo, que al entrar en la rutina de actualización sincronice la hora de forma automática. En la siguiente figura podemos observar la respuesta del servidor en el nodo. Figura 7.7:Sincronización de hora en un nodo. 7.2.2. Configuración del grupo multicast Una vez que todos los nodos han sincronizado su reloj se procede a enviar un mensaje McGroupStatusReq para crear un grupo multicast. En este momento los nodos utilizando la clave APP_KEY más una clave enviada desde el servidor pueden calcular las claves de la sesión. En la siguiente figura puede observarse la consola del nodo y las claves de la sesión multicast. Figura 7.8:Configuración del grupo multicast en un nodo. 7.2.3. Fragmentación de paquetes Dadas las limitaciones en el tamaño del payload que tenemos, debemos dividir el firmware en pequeños fragmentos de hasta 204 bytes por paquete. Esto lo hacemos enviando desde el servidor el mensaje FragSessionSetupReq. En la figura se observa entre otras cosas el tamaño de la actualización (32 fragmentos), el tamaño de cada fragmento (204 bytes) y el padding (cuando el último fragmento no está completo, cuanta información hay que 45 descartar contando por la derecha). Figura 7.9:Configuración de la sesión de fragmentación. 7.2.4. Ventana de recepción Por último, nos queda indicar al nodo si queremos que el nodo abra una ventana de recepción de la clase B (sincronización de ventanas de recepción mediante balizas) o de la clase C (ventana de recepción siempre abierta). En nuestro caso nos interesa que el firmware se descargue en los nodos lo antes posible para que estos puedan seguir funcionando con normalidad. Para abrir una ventana de recepción de la clase C el servidor envía el mensaje McClassCSessionReq. Figura 7.10:Configuración de la ventana de recepción. En la figura podemos ver el tiempo restante para que el nodo abra la ventana de recepción (10 segundos), el timeout (128 segundos), la frecuencia de descarga del firmware, que 46 pertenece al rango de frecuencias con un duty cycle del 10 % y el data rate [4.12]. 7.2.5. Recepción del nuevo firmware Pasados los 10 segundos indicados en el campo timeToStart [7.10], el servidor comienza a enviar los fragmentos del firmware. En la siguiente figura se ve como el nodo cambia a la clase C y comienza a recibir los fragmentos: Figura 7.11:Recepción de los paquetes fragmentados. En este caso concreto la actualización está fragmentada en 32 paquetes. Cuando el nodo reciba todos los paquetes comenzará a parchear el firmware. Esto puede verse en la siguiente figura: 47 Figura 7.12:Parcheo del firmware. Una vez el nodo termina de parchear el firmware, tiene que verificar utilizando la clave pública que tiene guardada si la firma es correcta, en caso de que la firma sea correcta se escribe en la cabecera del slot 1 (ver apartado [7.8]) la información de versión y la firma. Todo esto puede verse en la siguiente figura: Figura 7.13:Verificación de la firma. Por último, escrita la información de la cabecera del nuevo firmware se da por concluida la sesión de fragmentación. Ahora el nodo tiene que reiniciarse, esto fuerza la ejecución del 48 bootloader que se encargará de ir comprobando si hay alguna versión más reciente en alguno de los slot, en caso de encontrarla la copiará donde corresponda. En la siguiente figura vemos precisamente como ocurre esto, la placa se reinicia automáticamente y el bootloader detecta una versión más reciente en el slot 1[7.8] (el firmware actualizado mediante una actualización delta), entonces el bootloader copia esta versión a la flash del microcontrolador, a continuación detecta que el backup (slot 2) no coincide con el firmware más reciente por lo que copia a la memoria externa, en concreto al slot 2 que sirve como backup del firmware más reciente, el firmware que se encuentra en la memoria flash del microcontrolador. Finalmente se ejecuta el nuevo firmware, podemos ver al final de la figura el texto ’AGREGAMOS TEXTO PARA ...’ que fue la modificación realizada en el código fuente. 49 Figura 7.14:Fin la sesión de fragmentación y reinicio del nodo. Con el objetivo de mostrar toda la información disponible, a continuación se muestra el proceso anterior visto desde la aplicación de consola que se ejecuta en el lado del servidor. En la figura pueden verse cada una de las etapas descritas anteriormente. 50 Figura 7.15:Proceso de actualización visto desde el servidor. 7.3. Redundancia La pérdida de fragmentos por parte de los nodos es algo real, una breve interferencia externa en la frecuencia de descarga de datos puede fácilmente provocar la pérdida de algunos fragmentos. No puede ser aceptable que un nodo que ha perdido un pequeño porcentaje de paquetes no pueda actualizarse correctamente y tenga que esperar a que se envíe la actualización completa de nuevo. Durante la sesión de broadcast (en la actualización) los nodos no envían ACK, esto quiere decir que el servidor desconoce que paquetes no han recibido para poder reenviarlos. La redundancia se consigue con la aplicación de los algoritmos denominados LDPC o Low Density Parity Check, estos algoritmos fueron propuestos en el año 1960 por Robert G. Gallager8aunque no se empezaron a utilizar hasta los años 90. Para este proceso se crea una matriz de NxM, donde N corresponde al parámetro de 51 Figura 7.17:Dos nuevos ficheros binarios en el editor HxD. $ node jdiff -js -v file1 file2 parche ... Prescanning: . Equal bytes = 6 Data bytes written = 18 Overhead bytes written = 7 $ xxd parche 00000000: a7a3 05a7 a653 2032 2044 4946 4552 454e .....S 2 DIFEREN 00000010: 4349 4153 20a7 a532 0a CIAS ..2. a7a3 ->05 situarse en la posición 05 (para escribir en la siguiente posición). a7a6 ->escribir en el fichero 53 2032 2044 4952 454e 4349 4153 20 que corresponde con ’S 2 DIFERENCIAS ’ a7a5 ->situarse al final del fichero y escribir 32 0a que corresponde con ’2.’ Tamaño del nuevo posible firmware: $ stat file2 58 File: file2 Size: 24 Blocks: 8 IO Block: 4096 regular file Tamaño del parche: $ stat parche File: parche Size: 25 Blocks: 8 IO Block: 4096 regular file Tal y como podemos ver en el último ejemplo, no siempre es mejor opción una actualización delta frente a una actualización completa. Habitualmente sí lo será debido a que el firmware no se genera de forma aleatoria, si no que se compone de diferentes secciones que se ubican en las mismas zonas del binario. En cualquier caso se debe valorar cada actualización de forma individual. Veamos ahora que ocurre con un ejemplo real, el tamaño del firmware cargado en el nodo es de 160 KiB, dado que el bootloader ya se encuentra cargado en el nodo no es necesario adjuntarlo en la actualización, esto quiere decir que el fichero de actualización tiene 32KiB menos. La actualización va a consistir en añadir un for con un printf, este printf va a contener un string de 33 bytes. Tamaño firmware cargado en el nodo (sin bootloader): $ stat old.bin File: old.bin Size: 138120 Blocks: 272 IO Block: 4096 regular file Nuevo código: for(int i=0;i<20;i++) 59 { printf("AGREGAR NUEVOS BYTES AL CODIGO"); } Tamaño nuevo firmware (sin bootloader): $ stat new.bin File: new.bin Size: 138168 Blocks: 272 IO Block: 4096 regular file Generar la actualización delta y firmarla: $ lorawan -fota -signing -tool sign - delta --old old. bin --new new.bin --output - format bin -o signed - diff . bin $ stat signed - diff .bin File: signed - diff .bin Size: 6493 Blocks : 16 IO Block : 4096 regular file Figura 7.18:Comparativa entre el tamaño de los dos tipos de actualización. 60 En la figura [7.18] podemos observar una diferencia de tamaños muy importante, una reducción en el tamaño de la actualización de un 95,3% utilizando una actualización delta frente a una completa. Al reducir el tamaño de la actualización se consigue un mejor resultado. Los nodos necesitan menos espacio para almacenar la información, el porcentaje de paquetes perdidos se reduce y el tiempo necesario para la descarga es muy inferior. 7.8. Almacenamiento En esta implementación de OTA se utilizan las dos memorias disponibles en la placa, la primera es una memoria SPI de 8MB y la segunda es la memoria flash del microcontrolador de 1 MB. El mapa de la memoria flash del microcontrolador es el siguiente: Figura 7.19:Organización de la memoria flash. En la dirección de memoria 0x08000000 se encuentra el bootloader, conviene recordar que el bootloader se va a ejecutar en primer lugar y entre otras cosas gestiona las actualizaciones de firmware del chip. En la dirección 0x08008800 se encuentra la cabecera del firmware, esta cabecera contiene la versión del firmware y la firma del mismo, esta información será de utilidad más adelante. Por último, en la dirección 0x08009000 se encuentra el firmware, la dirección final dependerá del tamaño del mismo. Por otro lado tenemos la memoria SPI, esta memoria se estructura de la siguiente forma: 61 Figura 7.20:Organización de la memoria SPI. Slot 0: el slot 0 se utiliza para almacenar el firmware en el caso de estar recibiendo una actualización de tipo completa. Slot 2: en este slot hay un backup del firmware más reciente cargado en el microcontrolador. Utilizando esta copia podemos recuperar el chip en caso de corrupción en el firmware. Slot 1: en el caso de las actualizaciones de tipo delta este slot se utiliza para combinar el firmware actual guardado en el slot 2 con el parche recibido. Durante el encendido de la placa el bootloader comprueba utilizando la versión almacenada en la cabecera de los slots cuál de los firmwares es el más reciente, en base a esto decide cual debe estar cargado en el microcontrolador y copiado en el slot 2 como respaldo. Para ejecutar el bootloader, nada más terminar una actualización del tipo que sea la placa se reinicia de forma automática, de esta forma se ejecuta el bootloader y realiza todas las actualizaciones en las memorias que correspondan. 7.9. Pruebas fuera del laboratorio Todas las pruebas anteriores se han hecho en un entorno controlado, el laboratorio, las pruebas que se muestran a continuación han sido realizadas fuera de este, en concreto, en 62 el campus de Ciudad Universitaria. En la primera prueba se ha querido comprobar la actualización OTA de dos nodos de forma simultánea, para ello se ha colocado un gateway en el laboratorio y dos nodos en diferentes ubicaciones dentro del campus, la situación de los nodos y el gateway se muestra en la siguiente figura: Figura 7.21:Situación de los nodos y gateway durante la prueba fuera del laboratorio. La distancia entre el gateway y el nodo más alejado ha sido de 215 metros, la conexión entre el gateway y ambos nodos se ha realizado con un date rate de 5, recibiendo ambos nodos el nuevo firmware de forma correcta. De los 32 paquetes que formaban la actualización delta, ambos nodos recibieron el 100 % de los mismos, no haciendo necesario recurrir a los 63 paquetes de redundancia. En la segunda prueba se quiere poner a prueba la tecnología LoRa en un entorno de interferencias debido a los múltiples equipos informáticos y de radio utilizados en las distintas facultades. Para esta prueba se coloca el gateway en la Facultad de Informática y uno de los nodos en la azotea de la Facultad de Ciencias Físicas, a continuación se muestra una figura con la situación exacta: Figura 7.22:Situación del gateway y nodo durante la segunda prueba fuera del laboratorio. En esta ocasión la distancia entre el nodo y el gateway es de 542 metros, la conexión al igual que en la anterior prueba se ha realizado de forma correcta con un data rate de 5. Para actualizar este nodo se ha utilizado de nuevo la actualización delta frente a la completa; dicha actualización estaba compuesta por 30 fragmentos. El nodo ha sido capaz de recibir todos los fragmentos de forma correcta. No han sido necesarios los paquetes de redundancia. Como conclusión de las pruebas, la valoración general es muy positiva, todas las actualizaciones fuera del laboratorio, en un entorno que podemos considerar que se asemeja más al de la futura ubicación de los nodos han sido un éxito. 64 Capítulo 8 Conclusiones El objetivo marcado para este proyecto de fin de grado había sido conseguir actualizar el firmware de los nodos de una red de sensores mediante una tecnología LPWAN denominada LoRaWAN. Este objetivo no solo se ha logrado sino que además toda la información recopilada y todas las pruebas realizadas tanto en el laboratorio como en un entorno real van a ser de especial interés para el proyecto Solar Node, en el cual además de recopilar información acerca de la radiación solar van a poder tener soporte para actualizaciones OTA. Se ha podido concluir que en la mayoría de los casos es mucho más conveniente realizar actualizaciones OTA parciales frente a actualizaciones completas. Sin embargo en algunas ocasiones nos podría ocurrir que el tamaño de la actualización parcial sea superior a la actualización completa, en este caso es mejor idea dividir una actualización grande en actualizaciones más pequeñas para evitar fallos de comunicación. La placa B-L475E-IOT01A[3.2] con procesador STM32L475VGT6, elegida finalmente como placa de pruebas para las actualizaciones OTA, ha sido todo un acierto; la memoria SPI que lleva integrada en placa se ha vuelto indispensable para poder tener siempre una copia de respaldo del firmware, en caso de que se corrompiera alguna parte del firmware, el bootloader podría fácilmente reemplazar el firmware corrupto. También dicha memoria es utilizada para generar el nuevo firmware cuando se ejecuta una actualización delta. Gracias a la memoria integrada evitamos tener que añadir algún tipo de soporte adicional donde guardar esta información, este soporte podría ser un lector de tarjetas SD, un pen-drive 65 conectado a un puerto OTG mediante un adaptador, etc... El conjunto de aplicaciones que forman LoRa Server han demostrado durante el desarrollo de este proyecto ser muy robustas y fiables, además son aplicaciones de código libre y con una gran comunidad y documentación detrás. Como conclusión final de este proyecto, a pesar de que el protocolo elaborado por la asociación LoRa-Alliance para el envío de datos multicast es relativamente nuevo, se ha podido comprobar en multitud de ocasiones durante las pruebas realizadas que este protocolo es muy estable y fiable. 66 Capítulo 9 Conclusions The objective set for this end-of-degree project was to update the firmware of the nodes of a sensor network using an LPWAN technology called LoRaWAN. This objective has not only been achieved but also all the information collected and all the tests carried out, both in the laboratory and in a real environment, are going to be of special interest for the Solar Node project, which in addition to gathering information about solar radiation, will be able to have support for OTA updates. It has been concluded that it is much more convenient to perform partial OTA updates against complete updates. However, in some cases it could happen that the size of the partial update is larger than the complete update, in this case it is better to divide a large update into smaller updates to avoid communication problems. The board B-L475EIOT01A [3.2] with processor STM32L475VGT6, was finally chosen as a test board for OTA updates, has been a success. The SPI memory that is integrated in the board has become indispensable to always have a backup copy of the firmware, in case any part of the firmware is corrupted, the bootloader could easily replace the corrupted firmware. This memory is also used to generate the new firmware when a delta update is performed. Thanks to the integrated memory we avoid having to add some additional support to store this information, this support could be an SD card reader, a pen-drive connected to an OTG port through an adapter, etc ... The set of applications that form LoRa Server have shown during the development of 67 Figura A.7:Formato mensaje FragSessionSetupReq. FragSession, que se descompone en: •FragIndex identificador de la sesión, hasta 4 sesiones. •McGroupBitMask utilizado para asociar sesiones de fragmentación a grupos multicast, indica que grupos de multicast pueden recibir datos de esta sesión de fragmentación, un valor 0000 indica solo datos unicast, un valor 0001 indica sesión de multicast 0 y un valor 1111 indica que pueden recibir datos de esta sesión en los 4 grupos multicast más unicast. Figura A.8:Formato parámetro FragSession. NbFrag, número de fragmentos que vamos a enviar. FragSize, tamaño de los fragmentos. Control es una estructura de control que tiene los siguientes campos: •FragAlgo, indica el algoritmo utilizado para la fragmentación de los paquetes. •BlockAckDelay, máximo de tiempo para que los nodos confirmen un mensaje que requiera confirmación recibido por un grupo multicast. El nodo generará un valor aleatorio utilizando nuestro máximo tiempo para evitar las colisiones que tendríamos si todos los nodos confirmaran el mensaje al mismo tiempo. 74 Figura A.9:Formato parámetro Control. Padding, número de bytes que se descartan del último fragmento recibido. Por ejemplo, para un tamaño de payload de 204 bytes, si una actualización solo requiere de 128 bytes tendríamos un padding de 76, 204 - 76 = 128 bytes de datos. Descriptor indica el tipo de datos que está recibiendo el nodo, por ejemplo, una actualización OTA. Este mensaje requiere una confirmación por parte de los nodos, el mensaje de confirmación contiene los siguientes campos: Figura A.10:Formato mensaje FragSessionSetupAns. Si alguno de los bits [0:3] está a uno entonces el nodo ha rechazado la sesión de fragmentación. A.4. Ventana de recepción Mensaje McClassCSessionReq para abrir una ventana de recepción de la clase C. Contiene los siguientes campos: Figura A.11:Formato mensaje McClassCSessionReq. 75 McGroupIDHeader que contiene una estructura con los siguientes parámetros: Figura A.12:Formato parámetro McGroupIDHeader. McGroupID que corresponde con el identificador del grupo multicast. SessionTime es el tiempo en segundos para abrir la ventana de recepción. SessionTimeOut que contiene una estructura con los siguientes parámetros: Figura A.13:Formato parámetro SessionTimeOut. Donde TimeOut es el máximo tiempo que va a estar la ventana de recepción abierta antes de volver a la clase A para ahorrar batería. DLFrequ Frecuencia en la que van a estar escuchando los nodos, se utiliza 869.525 MHz por tener un duty cycle del 10 %. DR indica el factor de propagación y el ancho de banda. Este mensaje también requiere que los nodos confirmen su correcta recepción mediante el envío de un mensaje McClassCSessionAns que contiene los siguientes campos: Figura A.14:Formato mensaje McClassCSessionAns. La estructura Status&McGroupID contiene los siguientes parametros: 76 McGroupUndefined, a uno si el grupo multicast del campo McGroupID no existe. FreqEerror, a uno si el nodo no soporta la frecuencia. DRError, a uno si el nodo no soporta dicho data rate. McGroupID Identificador del grupo multicast. Figura A.15:Formato parámetro Status&McGroupID. El campo (cond)TimeToStart se utiliza para comprobar que el reloj del nodo sigue correctamente sincronizado. El nodo indica en este campo los segundos restantes para abrir la ventana de recepción y de esta forma el servidor puede comprobar que está correctamente sincronizado. 77