Optimización de una red IoT LoRa mediante ajustes realizados en los parámetros avanzados de la red

Curso: 2023-2024 Director: Vélez Elordi, Manuel María Estudiante: Sedano Isasi, Iker OPTIMIZACIÓN DE UNA RED IOT LORA MEDIANTE AJUSTES REALIZADOS EN LOS PARÁMETROS AVANZADOS DE LA RED MÁSTER UNIVERSITARIO EN INGENIERÍA DE TELECOMUNICACIÓN TRABAJO FIN DE MASTER Fecha: Bilbao, 6, junio, 2024 I Resumen En los últimos años, el IoT ha crecido significativamente, con la tecnología LoRa destacando por su amplio alcance y bajo consumo energético. Itelazpi, una empresa pública vasca, ha desplegado una extensa red LoRa en la CAV, conectando más de 100.000 dispositivos IoT, la gran mayoría siendo dispositivos metering de agua. Esta red ha sido clave para la monitorización y gestión eficiente del agua, permitiendo la recopilación de datos en tiempo real y optimizando la administración de recursos hídricos. Este trabajo de fin de master se enmarca en unas prácticas de cooperación educativa en Itelazpi, desarrolladas durante más de dos años y medio. Este trabajo se propone optimizar la red existente mediante ajustes en los parámetros de calidad de servicio (QoS) del protocolo LoRaWAN, sin necesidad de añadir más hardware. La localidad de Galdakao, con una cobertura adecuada y una alta densidad de dispositivos, ha sido seleccionada como zona de estudio piloto para implementar y validar estas mejoras. Para ello, primero se definirán los parámetros que se van a utilizar para poder medir la calidad de la red, al igual que los métodos de extracción de estos y la forma en la que se presentarán en forma de gráficos para poder analizarlos. Una vez definido esto, se desarrollará una aplicación de escritorio capaz de obtener los gráficos resultantes con la mínima interacción del usuario posible, para así poder automatizar la mayoría del proceso del análisis y ser capaz de realizar estos análisis en cualquier zona de la red. Para poder determinar el impacto de la modificación de ciertos parámetros QoS del protocolo LoRaWAN, primero se realizará un análisis previo a cualquier cambio, para poder observar el estado actual de la red en la zona estudiada. Una vez hecho esto, se modificarán ciertos parámetros QoS en función de los resultados que se quieran obtener, y se volverá a realizar otro análisis, para observar el estado de la red después de haberle aplicado los cambios. Finalmente, tras estudiar el impacto de los cambios realizados, se realizarán otros cambios finales con el fin de maximizar las mejoras obtenidas y paliar el impacto negativo que pueda suponer el cambio de ciertos parámetros. Esto servirá para volver a analizar el estado de la red y obtener conclusiones sobre el impacto del cambio de diferentes parámetros, los cuales serán aplicables al resto de la red. Palabras clave: IoT, metering, LoRa, LoRaWAN, parámetros QoS II Laburpena Azken urteotan, IoT nabarmen hazi da, LoRa teknologia bere irismen zabalagatik eta energiakontsumo txikiagatik nabarmentzen delarik. Itelazpi euskal enpresa publikoak LoRa sare zabala zabaldu du EAEn, 100.000 IoT gailu baino gehiago konektatuz, gehienak ur-metering gailuak izanik. Sare hori funtsezkoa izan da ura modu eraginkorrean monitorizatzeko eta kudeatzeko, datuak denbora errealean biltzea ahalbidetuz eta baliabide hidrikoen administrazioa optimizatuz. Master amaierako lan hau Itelazpin bi urte eta erdiz baino gehiagoz garatutako hezkuntzalankidetzako praktika batzuen barruan kokatzen da. Lan honek egungo sarea optimizatzea proposatzen du, LoRaWAN protokoloko zerbitzuaren kalitate-parametroetan (QoS) doikuntzak eginez, hardware gehiago gehitu beharrik gabe. Galdakaoko herria, estaldura egokiarekin eta gailu-dentsitate handiarekin, azterketa-eremu pilotu gisa hautatu da hobekuntza horiek inplementatzeko eta baliozkotzeko. Horretarako, lehenik eta behin, sarearen kalitatea neurtzeko erabiliko diren parametroak definituko dira, bai eta horiek erauzteko metodoak eta analizatu ahal izateko grafiko moduan aurkezteko modua ere. Behin hori definituta, mahaigaineko aplikazio bat garatuko da, lortutako grafikoak erabiltzailearen ahalik eta elkarrekintza txikienarekin lortzeko gai izango dena, horrela analisiaren prozesu gehiena automatizatu ahal izateko eta analisi horiek sareko edozein gunetan egiteko gai izateko. LoRaWAN protokoloko QoS parametro jakin batzuen aldaketaren eragina zehaztu ahal izateko, lehenik eta behin, edozein aldaketaren aurreko analisi bat egingo da, aztertutako eremuan sarearen egungo egoera behatu ahal izateko. Hori egin ondoren, QoS parametro batzuk aldatuko dira lortu nahi diren emaitzen arabera, eta beste analisi bat egingo da, aldaketak aplikatu ondoren sarearen egoera behatzeko. Azkenik, egindako aldaketen eragina aztertu ondoren, beste azken aldaketa batzuk egingo dira, lortutako hobekuntzak maximizatzeko eta parametro jakin batzuk aldatzeak ekar dezakeen inpaktu negatiboa arintzeko. Horrek balio izango du sarearen egoera berriro aztertzeko eta hainbat parametroren aldaketaren inpaktuari buruzko ondorioak ateratzeko. Parametro horiek sarearen gainerako ataletan aplikatu ahal izango dira. Gako-hitzak: IoT, metering, LoRa, LoRaWAN, QoS parametroak III Abstract In recent years, IoT has grown significantly, with LoRa technology standing out for its wide range and low power consumption. Itelazpi, a Basque public company, has deployed an extensive LoRa network in the BAC, connecting more than 100,000 IoT devices, the vast majority being water metering devices. This network has been key to efficient water monitoring and management, enabling real-time data collection and optimising water resource management. This master's thesis is part of an educational cooperation internship at Itelazpi, carried out over more than two and a half years. This work aims to optimise the existing network by adjusting the quality of service (QoS) parameters of the LoRaWAN protocol, without the need to add more hardware. The town of Galdakao, with adequate coverage and a high density of devices, has been selected as a pilot study area to implement and validate these improvements. To do this, we will first define the parameters that will be used to measure the quality of the network, as well as the methods for extracting them and the way in which they will be presented in the form of graphs for analysis. Once this has been defined, a desktop application will be developed capable of obtaining the resulting graphs with as little user interaction as possible, in order to automate most of the analysis process and be able to perform these analyses in any area of the network. In order to determine the impact of modifying certain QoS parameters of the LoRaWAN protocol, an analysis will first be performed prior to any changes, in order to observe the current state of the network in the area under study. Once this has been done, certain QoS parameters will be modified according to the results to be obtained, and another analysis will be carried out again, to observe the state of the network after the changes have been applied. Finally, after studying the impact of the changes made, other final changes will be made in order to maximise the improvements obtained and mitigate the negative impact of changing certain parameters. This will serve to re-analyse the state of the network and obtain conclusions on the impact of the change of different parameters, which will be applicable to the rest of the network. Keywords: IoT, metering, LoRa, LoRaWAN, QoS parameters IV Índice 1. Introducción ...................................................................................................................... 1 2. Contexto ........................................................................................................................... 3 2.1. Zona de estudio ......................................................................................................... 4 3. Objetivos y alcance del trabajo .......................................................................................... 6 4. Beneficios que aporta el trabajo ........................................................................................ 7 4.1. Beneficios sociales ..................................................................................................... 7 4.2. Beneficios económicos .............................................................................................. 7 4.3. Beneficios técnicos .................................................................................................... 7 5. Descripción de la solución propuesta ................................................................................ 8 5.1. Metodología de captura de datos y resultados .......................................................... 8 5.2. Creación de interfaz de usuario ............................................................................... 22 5.3. Estudio inicial .......................................................................................................... 57 5.4. Iteraciones de mejora .............................................................................................. 70 5.5. Configuración final ................................................................................................... 82 6. Planificación del proyecto ............................................................................................... 94 6.1. Paquetes de trabajo................................................................................................. 94 6.2. Diagrama de GANTT .............................................................................................. 101 7. Presupuesto .................................................................................................................. 103 8. Conclusiones ................................................................................................................. 105 9. Bibliografía .................................................................................................................... 106 V Lista de ilustraciones Ilustración 1: Arquitectura de red LoRa [1] ................................................................................ 1 Ilustración 2: Diagrama de la red LoRa de Itelazpi ..................................................................... 2 Ilustración 3: Esquema de problemas de densificación de la red LoRa de Itelazpi ...................... 3 Ilustración 4: Ubicación de los Gateways en Galdakao............................................................... 5 Ilustración 5: Esquema de planificación del proyecto ................................................................ 8 Ilustración 6: Información básica de un device en Orbiwise ....................................................... 9 Ilustración 7: Información detallada de un device en Orbiwise l .............................................. 10 Ilustración 8: Información detallada de un device en Orbiwise ll ............................................. 10 Ilustración 9: Mensaje MAC enviado por un dispositivo........................................................... 10 Ilustración 10: Información básica de un Gateway en Orbiwise l ............................................. 11 Ilustración 11: Información básica de un Gateway en Orbiwise ll............................................. 12 Ilustración 12: Información detallada de un Gateway en Orbiwise .......................................... 12 Ilustración 13: Endpoint de la API de Orbiwise para obtener todos los devices de un grupo .... 14 Ilustración 14: Endpoint de la API de Orbiwise para obtener los payloads de un device ........... 15 Ilustración 15: Extracto de las opciones disponibles del endpoint de obtención de payloads ... 15 Ilustración 16: Respuesta obtenida de una llamada el endpoint de obtención de payloads ..... 16 Ilustración 17: Endpoint para obtener todos los Gateways asociados a un usuario .................. 17 Ilustración 18: Respuesta obtenida de una llamada el endpoint de listado de Gateways ......... 17 Ilustración 19: Endpoint de la API NST para obtener parámetros avanzados de un Gateway ... 18 Ilustración 20: Formato de respuesta de una llamada al endpoint de obtención de parámetros avanzados de un Gateway ....................................................................................................... 18 Ilustración 21: Diagrama de bloques de la obtención de parámetros de los devices ................ 23 Ilustración 22: Diagrama de bloques de la obtención de parámetros de los Gateways ............. 25 Ilustración 23: Explicación gráfica de la fórmula de Haversine [6] ............................................ 28 Ilustración 24: Diagrama de bloques de la GUI funcional ......................................................... 33 Ilustración 25: Pantalla principal (GUI funcional) ..................................................................... 34 Ilustración 26: Pantalla de selección de grupo (GUI funcional) ................................................. 34 Ilustración 27: Pantalla de selección de tiempo (GUI funcional) ............................................... 35 Ilustración 28: Pantalla de obtención de payloads (GUI funcional)........................................... 35 Ilustración 29: Pantalla de guardado (GUI funcional) ............................................................... 36 Ilustración 30: Pantalla de datos guardados (GUI funcional) .................................................... 37 Ilustración 31: Pantalla de ingresar credenciales para los Gateways (GUI funcional) ................ 37 Ilustración 32: Pantalla con la lista de todos los Gateways (GUI funcional) .............................. 38 Ilustración 33: Pantalla con Gateways seleccionados (GUI funcional) ...................................... 38 Ilustración 34: Pantalla de obtención de parámetros de Gateways (GUI funcional) ................. 39 Ilustración 35: Pantalla de creación de gráficos (GUI funcional) ............................................... 39 Ilustración 36: Pantalla de finalización (GUI funcional) ............................................................ 39 Ilustración 37: Pantalla de selección de carpetas (GUI funcional) ............................................ 40 Ilustración 38: Pantalla de creación de gráficos combinados (GUI funcional) ........................... 40 Ilustración 39: Diagrama de bloques de la GUI final ................................................................. 41 Ilustración 40: Diagrama de funcionamiento de "Tkinter-Designer" ........................................ 42 Ilustración 41: Pantalla principal (GUI final) ............................................................................. 43 Ilustración 42: Pantalla de selección de grupo (GUI final) ........................................................ 44 Ilustración 43: Pantalla de selección de tiempo (GUI final) ...................................................... 44 Ilustración 44: Pantalla de obtención de payloads (GUI final) .................................................. 45 VI Ilustración 45: Pantalla de guardado (GUI final)....................................................................... 46 Ilustración 46: Pantalla de datos guardados (GUI final)............................................................ 47 Ilustración 47: Pantalla de ingresar credenciales para los Gateways (GUI final) ....................... 47 Ilustración 48: Pantalla con la lista de todos los Gateways (GUI final) ...................................... 48 Ilustración 49: Pantalla con Gateways seleccionados (GUI final) .............................................. 48 Ilustración 50: Pantalla de obtención de parámetros de Gateways (GUI final) ......................... 49 Ilustración 51: Pantalla de creación de gráficos (GUI final) ...................................................... 49 Ilustración 52: Pantalla de finalización (GUI final) .................................................................... 50 Ilustración 53: Pantalla de elección de numero de análisis (GUI final) ...................................... 50 Ilustración 54: Pantalla de selección de carpetas (GUI final) .................................................... 51 Ilustración 55: Pantalla de creación de gráficos combinados (GUI final) ................................... 52 Ilustración 56: Resultado de crear el ejecutable ...................................................................... 53 Ilustración 57: Ejecutable de la aplicación ............................................................................... 54 Ilustración 58: Ventana emergente al introducir credenciales erróneas................................... 55 Ilustración 59: Información estática de un Gateway ................................................................ 57 Ilustración 60: Archivos JSON de los parámetros de cada Gateway .......................................... 58 Ilustración 61: Ejemplo de datos de calidad de señal obtenidos de un Gateway ...................... 58 Ilustración 62: Información estática de un device .................................................................... 59 Ilustración 63: Información de cada mensaje transmitido de un device ................................... 60 Ilustración 64: Ejemplo de datos unificados de un Gateway .................................................... 61 Ilustración 65: Ejemplo de datos unificados de un device ........................................................ 61 Ilustración 66: Mapa de Gateways y devices de Galdakao ....................................................... 62 Ilustración 67: Zoom del mapa de Gateways y devices de Galdakao ........................................ 62 Ilustración 68: Gráfico de número de frames de uplink por Gateway (estudio inicial) .............. 63 Ilustración 69: Grafico de la distribución de la media de RSSI (estudio inicial) .......................... 64 Ilustración 70: Distribución de "Average Gateways reached" (estudio inicial) .......................... 64 Ilustración 71: Distribución de "Last SF used" (estudio inicial) ................................................. 65 Ilustración 72: Distribución de "Lost frames" (estudio inicial) .................................................. 66 Ilustración 73: Distribución de "Received frames" (estudio inicial)........................................... 66 Ilustración 74: Márgenes de potencia de los mensajes (estudio inicial) ................................... 67 Ilustración 75: Distribución de "Average SNR" (estudio inicial) ................................................ 67 Ilustración 76: Media de RSSI por cada SF (estudio inicial) ....................................................... 68 Ilustración 77: Media de SNR por cada SF (estudio inicial) ....................................................... 68 Ilustración 78: Media de mensajes perdidos por distancia al Main gateway (estudio inicial) .... 69 Ilustración 79: Media de mensajes perdidos por SF (estudio inicial) ........................................ 69 Ilustración 80: Mensaje de configuración del Network Server a un device ............................... 73 Ilustración 81: Comando MAC enviado en el mensaje de configuración .................................. 73 Ilustración 82: Comparativa de la media de RSSI de los mensajes recibidos en cada Gateway . 75 Ilustración 83: Comparación del número de mensajes recibidos por cada Gateway................. 75 Ilustración 84: Comparación del número de Gateways al que llegan los mensajes ................... 76 Ilustración 85: Comparación del último SF utilizado por los devices......................................... 76 Ilustración 86: Comparación del ToA relativo a la distancia al Main Gateway .......................... 77 Ilustración 87: Comparación de RSSI en función de SF ............................................................. 77 Ilustración 88: Comparación de SNR en función de SF ............................................................. 78 Ilustración 89: Comparación de la distribución de RSSI ............................................................ 78 Ilustración 90: Comparación de la distribución de SNR ............................................................ 79 Ilustración 91: Comparación del número de mensajes recibidos.............................................. 79 VII Ilustración 92: Comparación de porcentaje de mensajes perdidos en relación a la distancia al Main Gateway ........................................................................................................................ 80 Ilustración 93: Comparación de porcentaje de perdidas en relación al SF ................................ 80 Ilustración 94: Relación entre el SF y ToA ................................................................................ 81 Ilustración 95: SNR mínimo para demodular dependiendo el SF [19] ....................................... 81 Ilustración 96: Comparativa de la media de RSSI recibida por cada Gateway ........................... 85 Ilustración 97: Comparación del número de mensajes recibidos por cada Gateway................. 86 Ilustración 98: Comparación del número de Gateways al que llegan los mensajes ................... 86 Ilustración 99: Comparación del último SF utilizado por los devices......................................... 87 Ilustración 100: Comparación del ToA relativo a la distancia al Main Gateway ........................ 87 Ilustración 101: Comparación de RSSI en función de SF ........................................................... 88 Ilustración 102: Comparación de SNR en función de SF ........................................................... 88 Ilustración 103: Comparación de la distribución de RSSI .......................................................... 89 Ilustración 104: Comparación de la distribución de SNR .......................................................... 89 Ilustración 105: Comparación de número de mensajes recibidos ............................................ 90 Ilustración 106: Comparación de porcentaje de mensajes perdidos en relación a la distancia al Main Gateway ........................................................................................................................ 90 Ilustración 107: Comparación del porcentaje de la media cumulada de mensajes perdidos en relación a la distancia con el Main Gateway ............................................................................ 91 Ilustración 108: Comparación de porcentaje de perdidas en función del SF ............................. 91 Ilustración 109: Diagrama de Gantt ....................................................................................... 102 VIII Lista de tablas Tabla 1: Resumen de parámetros a obtener de los devices ..................................................... 11 Tabla 2: Resumen de parámetros a obtener de los Gateways .................................................. 13 Tabla 3: Resumen de parámetros que se van a utilizar para analizar la red .............................. 14 Tabla 4: Parámetros obtenidos listando los devices ................................................................. 15 Tabla 5: Parámetros obtenidos utilizando el endpoint de obtención de payloads .................... 16 Tabla 6: Parámetros obtenidos listando los Gateways ............................................................. 17 Tabla 7: Parámetros avanzados obtenidos de la API del NST ................................................... 18 Tabla 8: Resumen de métodos de obtención de parámetros ................................................... 19 Tabla 9: Parámetros QoS configurables en el Nework Server ................................................... 71 Tabla 10: Nuevos valores de los parámetros QoS modificados (iteración)................................ 72 Tabla 11: Nuevos valores de los parámetros QoS modificados (final)....................................... 83 Tabla 12: Sueldos y nóminas ................................................................................................. 103 Tabla 13: Amortizaciones ...................................................................................................... 103 Tabla 14: Resumen de presupuesto....................................................................................... 104 6 3. Objetivos y alcance del trabajo El objetivo principal de este trabajo es consiste en la optimización de la red IoT LoRa desplegada por Itelazpi mediante ajustes realizados en los parámetros avanzados de la red. Esta optimización será aplicada en un área focalizada de la red (Galdakao) y con los resultados obtenidos y mediante la aplicación de escritorio desarrollada, se podrá expandir al resto de la red IoT. Para poder llevar a cabo este objetivo, se plantean cinco objetivos secundarios, los cuales ayudaran a llevar a cabo una mejor realización del trabajo final. • Definición de parámetros importantes y de resultados a obtener para el análisis: para realizar un análisis lo más completo posible de la red LoRa de Itelazpi, es indispensable definir los parámetros que serán necesarios para realizar dicho análisis. Además, también es necesario definir cuáles serán los resultados que se van a querer obtener, al igual que el formato en el que se presentarán. • Creación de la aplicación de escritorio: con el fin de poder replicar este análisis en las diferentes zonas de la red de Itelazpi, se creará una aplicación de escritorio con interfaz de usuario para facilitar y simplificar los futuros análisis de la red. • Estudio previo a realizar cambios en la red: antes de realizar ningún cambio en la red, será necesario analizar el estado actual de esta, con el fin de identificar cuáles pueden ser los puntos más débiles y respecto a estos programar una serie de cambios en los parámetros avanzados de la red. • Realización de cambios para mejorar el estado de la red: para poder encontrar un punto óptimo de los parámetros avanzados de la red que se quieren cambiar, será necesario ir cambiándolos y algunos de estos serán prueba y error. Dependerá de cuan rápido se llegue al resultado esperado para saber el número de iteraciones que se realizarán. • Obtención de los parámetros óptimos para los resultados deseados: una vez realizadas las iteraciones de prueba y error para encontrar los parámetros QoS adecuados, se asignarán estos parámetros y se hará un análisis final con el fin de ver si realmente se obtienen los resultados esperados. 7 4. Beneficios que aporta el trabajo En este apartado se va a hacer mención a los beneficios económicos, técnicos y sociales que suponen este trabajo de fin de master. 4.1. Beneficios sociales Este trabajo ayudara a optimizar la red LoRa de Itelazpi. Esta optimización no solo impulsará la eficiencia en la gestión de recursos críticos como puede ser el agua, sino que también redundará en beneficios significativos para las autoridades locales, como los ayuntamientos. Esto se traducirá directamente en una mejora palpable en la gestión del agua en la Comunidad Autónoma Vasca. Este progreso se reflejará en una mayor disponibilidad de agua, en una reducción sustancial del desperdicio y, en última instancia, en el fortalecimiento de la sostenibilidad de este recurso crítico en la región. 4.2. Beneficios económicos En cuanto a los beneficios económicos, estos se podrían dividir en dos partes, los beneficios de la empresa gestora de la red LoRa, Itelazpi, y los beneficios económicos que las empresas que gestionan los contadores de agua. Por parte de Itelazpi, la optimización de la red LoRa supondrá un ahorro de gastos más que un mayor ingreso de capital. Esto se debe a que, optimizando la red, se pretende dar más cobertura y de mejor calidad utilizando los mismos Gateways, por lo que Itelazpi no tendrá que instalar nuevos Gateways, ahorrándose así los costes de compra, instalación, supervisión y mantenimiento de estos. En el caso de los usuarios de la red, estos también podrán reducir costes con la optimización de la red, ya que los datos de los dispositivos tendrán una tasa de error mucho menor y la cobertura ofrecida será mayor, por lo que el gasto de personal en ir físicamente a los lugares donde están instalados estos dispositivos se puede recortar drásticamente. 4.3. Beneficios técnicos El principal beneficio técnico de este trabajo es la resolución de los aspectos específicos que causan un peor desempeño de la red, impactando positivamente en la eficiencia local. Esto se debe a que el trabajo se ha realizado para la zona focalizada de Galdakao, por lo que los resultados obtenidos podrán ser visibles en esa zona. Esto implica que, gracias a haber realizado el análisis en una zona en concreto, se ha obtenido una instantánea precisa y actualizada de la red en Galdakao. Pero, los resultados pueden servir para establecer bases sólidas para la toma de decisiones en futuras expansiones y ajustes de la red LoRa. En términos generales, este trabajo ayudara a la futura planificación de la red LoRa al igual que a la optimización de la ya desplegada en otros lugares que no sean Galdakao, ya que el trabajo se ha realizado de la manera generalizada posible. 8 5. Descripción de la solución propuesta En este apartado del trabajo se van a detallar los pasos seguidos durante el transcurso para la elaboración de este. Estos pasos se explicarán de una forma ordenada tal y como se organizó el TFM desde un principio. Siguiendo el esquema de planificación (Ilustración 5), este apartado se va a dividir para describir el trabajo, relacionado con los cinco objetivos secundarios. Primero se explicarán las diferentes definiciones que se han hecho, tanto de los parámetros que se van a utilizar como de los resultados que se pretende obtener. Ilustración 5: Esquema de planificación del proyecto A continuación, se explicará todo lo relacionado con la aplicación de escritorio que se ha creado, empezando desde los scripts independientes más básicos hasta llegar a la aplicación final la cual aúna todo lo previamente creado. Después se explicará el estudio inicial que se ha hecho, antes de realizar ningún cambio a la red, para así poder observar el estado de esta y obtener conclusiones respecto a que parámetros podría ser necesario cambiar. Posteriormente, se explicará la iteración de mejora que se ha realizado con el fin de encontrar los valores óptimos de los parámetros avanzados de la red que se han decidido cambiar. Esta parte es totalmente escalable en cuanto a número de iteraciones y se podría repetir las veces necesarias hasta obtener los resultados esperados. Pero, debido al limitado tiempo del TFM, se ha hecho una única iteración. Por último, en la configuración final se realizará un análisis con los valores finales de los parámetros avanzados de la red que se han modificado, para asegurar así el correcto funcionamiento de la red y las mejoras respecto al estado inicial de esta. 5.1. Metodología de captura de datos y resultados Este primer apartado del trabajo es fundamental, ya que en él se definen los aspectos significativos del TFM. Al establecer las bases y los objetivos, se orienta el desarrollo del resto del trabajo. Primero se han definido los parámetros que pueden resultar importantes para este trabajo, los cuales ayudaran a entender mejor la red y visualizar como esta cambia a través de estos parámetros. Una vez teniendo definidos que parámetros se necesitan para hacer un buen análisis de la red, se definen los métodos de extracción de estos de los diferentes lugares donde están guardados. Por último, sabiendo cuales van a ser los parámetros que se van a utilizar para analizar la red, se definen diversos gráficos para poder visualizar estos parámetros de una forma sencilla y clara. 9 Esto también incluye mezclar diferentes parámetros con el fin de visualizar los datos de una manera más compacta. En resumen, en este bloque se explicarán en profundidad los siguientes subapartados: • Definición de parámetros • Definición de métodos de captura de datos • Definición de gráficos a obtener 5.1.1. Definición de parámetros Como primer punto de este trabajo es importante definir cuáles son los parámetros que se van a utilizar para definir la calidad de la red LoRa de Itelazpi. Estos parámetros se pueden obtener del Network Server con el cual se gestiona toda la red IoT. El Network Server utilizado por Itelazpi es Orbiwise [3], una plataforma pensada para proyectos a gran escala y con muchas funcionalidades útiles para llevar a cabo diferentes tareas. Orbiwise está dividido en dos partes, una para la gestión de los devices y otra para la gestión de los Gateways, DASS (Data Access Sub-System) y NST (Network Supervision Tool) respectivamente. Como para el completo análisis de la red es necesario obtener datos tanto de los devices como de los Gateways, se hará uso de ambas instancias con el fin de obtener el mayor número de parámetros útiles. Parámetros de los devices Haciendo uso de la interfaz gráfica de Orbiwise, se pueden analizar los parámetros disponibles de los dispositivos. Para empezar, en la información básica de los dispositivos se pueden encontrar como parámetros útiles el DevEUI (identificador único de cada dispositivo) y la posición de este (latitud y longitud). Esta información se puede ver en la Ilustración 6, señalados únicamente los parámetros mencionados. Ilustración 6: Información básica de un device en Orbiwise Por otro lado, accediendo a información más detallada de los devices, se pueden encontrar parámetros relacionados con la calidad de la red, como pueden ser el RSSI, SNR, etc. De estos parámetros que se pueden observar en la Ilustración 7, se hará uso del RSSI (Received Signal Strength Indicator), del SNR (Signal-to-Noise Ratio), el SF (Spreading Factor), el Main Gateway (Gateway principal) y el número de Gateways al que llegan los mensajes del dispositivo. 10 Ilustración 7: Información detallada de un device en Orbiwise l De estos parámetros, el RSSI y el SNR se utilizarán para averiguar con que potencia de señal llegan los mensajes que los devices envían. El SF se utilizará para ver el modo en el que se transmiten los datos. El Main Gateway será útil para ver que Gateways tienen más carga de trabajo, y finalmente, el número de Gateways al que llega cada mensaje será un indicativo de la redundancia de la red. Continuando con la información detalla de los devices, también es posible seleccionar rangos de tiempo y obtener información única y exclusivamente de ese rango definido, además de medias y porcentajes. En la Ilustración 8 se pueden observar diferentes parámetros los cuales también son realmente útiles para realizar un análisis de la calidad de la red. Ilustración 8: Información detallada de un device en Orbiwise ll Entre ellos se encuentran el número de mensajes recibidos en el Network Server del dispositivo (UL Frame CnT) y las medias en el rango de tiempo seleccionado de los parámetros RSSI y SNR (Avr RSSI[dBm] y Avr SNR[dB]). Además, partiendo del dato del número de mensajes que han llegado a Orbiwise y analizando cual es el número máximo de mensajes que deberían de haber llegado, se puede obtener el número de mensajes perdidos (Lost Frames). Finalmente, existe un parámetro que en la interfaz web de Orbiwise no se muestra, pero es igual de importante para medir la calidad de la red como el resto. Este parámetro es el tiempo en el aire (Time on Air, ToA) de cada mensaje, ya que la tecnología LoRa al utilizar una banda no licenciada [4], el tiempo que se puede ocupar la banda el limitado, por lo que es interesante controlar este parámetro. En la Ilustración 9, se puede observar que el parámetro ToA aparece en los mensajes de la capa MAC (Medium Access Control) que envían los dispositivos. Ilustración 9: Mensaje MAC enviado por un dispositivo En resumen, los parámetros que es necesario obtener de cada device quedan listados en la Tabla 1, con su nombre para su uso y su definición breve. 11 Nombre Definición deveui Identificador único del device latitude Latitud para su ubicación longitude Longitud para su ubicación average_rssi Media de RSSI en el tiempo analizado average_snr Media de SNR en el tiempo analizado average_time_on_air_ms Media de ToA en el tiempo analizado average_gws_reached Media de Gateways alcanzados en el tiempo analizado main_gw Gateway principal del device lost_frames Numero de mensajes no recibidos en Orbiwise received_frames Numero de mensajes recibidos en Orbiwise last_SF_used SF usado en el último mensaje recibido Tabla 1: Resumen de parámetros a obtener de los devices Parámetros de los Gateways Al igual que con los devices, los parámetros que se pueden ser útiles para hacer un análisis de la red pueden encontrarse en la interfaz web de Orbiwise. Primero de todo, observando la información básica de un Gateway, se pueden encontrar los parámetros de Gateway ID (identificador único de cada Gateway) y Name (Nombre asignado al Gateway para reconocerlo fácilmente), tal y como se puede observar en la Ilustración 10. Ilustración 10: Información básica de un Gateway en Orbiwise l 12 Además de esta información básica, también se pueden encontrar las coordenadas (latitud y longitud) de donde está instalado el Gateway (Ilustración 11), al igual que pasaba con los devices. Ilustración 11: Información básica de un Gateway en Orbiwise ll Accediendo a información más detallada de cada Gateway, se pueden encontrar parámetros directamente relacionados con el intercambio de mensajes. Entre ellos destacan UL Frame Cnt (Uplink Frame Count), Lost Frame Cnt (Lost Frame Count), Avr RSSI [dBm] (Average RSSI [dBm]) y Avr SNR [dB] (Average SNR [dB]). Estos se pueden encontrar en la Ilustración 12. Ilustración 12: Información detallada de un Gateway en Orbiwise De los parámetros mencionados, UL Frame Cnt será útil para saber cuántos mensajes recibe un Gateway y ver si este está saturado respecto a los demás. Lost Frame Cnt se utilizará para averiguar si el Gateway tiene perdida de paquetes, esto es, que haya recibido el mensaje de un device pero que por alguna razón no lo haya podido retransmitir al Network Server. Por otro lado, Avr RSSI y Avr SNR servirán para ver la potencia media de los mensajes recibidos en el Gateway en el rango de tiempo previamente establecido. Resumiendo, los parámetros que es necesario obtener de cada Gateway quedan listados en la Tabla 2, con su nombre para su uso y su definición breve. 13 Nombre Definición Gateway_ID Identificador único del Gateway name Nombre asignado al Gateway para su fácil reconocimiento latitude Latitud para su ubicación longitude Longitud para su ubicación UL_Frame_Cnt Numero de mensajes recibidos en el tiempo analizado Lost_Frame_Cnt Numero de mensajes perdidos en el tiempo analizado Avr_RSSI_[dBm] Media de RSSI en el tiempo analizado Avr_SNR_[dBm] Media de SNR en el tiempo analizado Tabla 2: Resumen de parámetros a obtener de los Gateways Resumen de parámetros Con el fin de visualizar mejor los parámetros que se van a utilizar para hacer el análisis de la red, se han resumido en la Tabla 3, donde aparece el nombre, la definición y la asociación del parámetro a un device o un Gateway. Además, se han añadido nuevos parámetros que únicamente se pueden obtener utilizando tanto información de los devices como de los Gateways. Estos parámetros son el Gateway más cercano a cada device y las distancias respectivas entre el device y el Main Gateway y el Gateway más cercano. Nombre Definición Asociado deveui Identificador único del device device latitude Latitud para la ubicación del device device longitude Longitud para la ubicación del device device average_rssi Media de RSSI de mensajes del device en el tiempo analizado device average_snr Media de SNR de mensajes del device en el tiempo analizado device average_time_on_air_ms Media de ToA de mensajes del device en el tiempo analizado device average_gws_reached Media de Gateways alcanzados por device en el tiempo analizado device lost_frames Numero de mensajes no recibidos en Orbiwise por device device received_frames Numero de mensajes recibidos en Orbiwise por device device last_SF_used SF usado en el último mensaje enviado por el device device main_gw Gateway principal del device device distance_to_main_gw Distancia entre el device y el Main Gateway device 14 nearest_gw Gateway más cercano al device device distance_to_nearest_gw Distancia entre el device y el Gateway más cercano device Gateway_ID Identificador único del Gateway Gateway name Nombre asignado al Gateway para su fácil reconocimiento Gateway latitude Latitud para la ubicación del Gateway Gateway longitude Longitud para la ubicación del Gateway Gateway UL_Frame_Cnt Numero de mensajes recibidos en el tiempo analizado por Gateway Gateway Lost_Frame_Cnt Numero de mensajes perdidos en el tiempo analizado por Gateway Gateway Avr_RSSI_[dBm] Media de RSSI de mensajes recibidos por Gateway en el tiempo analizado Gateway Avr_SNR_[dBm] Media de SNR de mensajes recibidos por Gateway en el tiempo analizado Gateway Tabla 3: Resumen de parámetros que se van a utilizar para analizar la red 5.1.2. Definición de los métodos de captura de parámetros Con el fin de poder hacer uso de los parámetros ya definidos para realizar el análisis de la red LoRa, será necesario establecer los métodos con los que se van a obtener esos datos, para así poder tener acceso a estos de una manera en la que se pueda automatizar. Para ello, Orbiwise cuenta con una API (Application Programming Interface) y una extensa documentación la cual será posible consultar con el fin de averiguar cómo obtener los parámetros solicitados. Al igual que el apartado anterior, en este también se diferenciará la obtención de los parámetros de los devices y de los Gateways. Parámetros de los devices Analizando la documentación de la API de Orbiwise, se encuentra un método para obtener una lista de todos los devices pertenecientes a un grupo (Ilustración 13). Itelazpi organiza los dispositivos por grupos, y una de las directrices para asignar grupos es el municipio en el que está instalado el sensor. Por lo que, para el caso de este trabajo, el grupo que se va a utilizar el “galdakao”. Ilustración 13: Endpoint de la API de Orbiwise para obtener todos los devices de un grupo Con este endpoint se obtienen diversos parámetros de cada dispositivo, pero de los definidos previamente, únicamente 3, los cuales se pueden ver en la Tabla 4. En la tabla, {host} hace 15 referencia a la dirección de Orbiwise y puede ser tanto la dirección privada como la pública, y {groupid} hace referencia al nombre del grupo que se va a utilizar, en este caso “galdakao". Parámetro Endpoint deveui https://{host}/rest/nodes?group={groupid} latitude https://host/rest/nodes?group=groupid longitude https://host/rest/nodes?group=groupid Tabla 4: Parámetros obtenidos listando los devices Una vez habiendo obtenido una lista de todos los devices de los que se va a hacer el análisis, usando el siguiente endpoint (Ilustración 14) se pueden obtener los mensajes (payloads) que ha enviado cada dispositivo. Ilustración 14: Endpoint de la API de Orbiwise para obtener los payloads de un device Además, este endpoint permite añadir diferentes opciones para filtrar los payloads. Entre ellas, las más interesantes son las de filtrar por fecha, ya que el análisis se hará en un rango de tiempo determinado. En la Ilustración 15 se pueden observar algunas de las opciones disponibles, y marcadas en rojo, las que se van a utilizar. Ilustración 15: Extracto de las opciones disponibles del endpoint de obtención de payloads Utilizando este endpoint, se obtendrá como resultado la información de la Ilustración 16 para cada device. De esta información obtenida, se harán cálculos para obtener ciertos parámetros que no se consiguen directamente, sino que es necesario realizar algunas operaciones, como puede ser el caso de obtener las medias de RSSI, SNR, ToA, etc. 22 o Media de SNR por último SF utilizado: en este último, se mostrará lo mismo que en anterior, pero utilizando los valores de SNR en vez de RSSI. Estos gráficos servirán para analizar los datos obtenidos de cada análisis del estado de la red después de aplicar los cambios. Además, estos también servirán para comparar los resultados de los diferentes estudios, visualizando en un único grafico el antes y el después. 5.2. Creación de interfaz de usuario En este segundo apartado, el objetivo es crear una interfaz gráfica para poder realizar tantos análisis de la red LoRa de Itelazpi como se quiera, de cualquier zona seleccionada y englobando todo lo posible. Para ello, como primer paso se han generado diversos scripts utilizando el lenguaje de programación Python. Estos scripts se pueden dividir en dos secciones, los que sirven para la obtención de los parámetros y los que sirven para tratar los datos obtenidos para generar los gráficos. Después de haber generado los scripts, se creará una interfaz de usuario funcional para unificar todos estos. Y finalmente, se retocará la interfaz de usuario funcional con el fin de hacerla más amigable para el usuario final, además de crear un instalador para poder instalar la aplicación en cualquier máquina. En resumen, en este bloque se explicarán en profundidad los siguientes subapartados: • Generación de scripts para la obtención de datos • Generación de scripts para la visualización de gráficos • Creación de interfaz de usuario funcional • Creación de interfaz de usuario final • Corrección de errores y casos límites NOTA: a lo largo de este apartado se hará referencia a diferentes carpetas y/o archivos del proyecto completo subido en GitHub, con el fin de poder seguir mejor la explicación. El proyecto completo se encuentra en este enlace: https://github.com/isedano005/LoRa-NetworkAnalyzer. 5.2.1. Generación de scripts para la obtención de datos Para la obtención de datos de la API de Orbiwise, es necesario distinguir entre los devices y los Gateways, ya que la información de los parámetros de estos no se extrae del mismo sitio. Por ende, este apartado se dividirá en dos, la que concierne a la obtención de los parámetros de los devices y la que concierne a los Gateways. NOTA: el código descrito en este subapartado (con algunas modificaciones ya que después se ha adaptado a la interfaz de usuario) se puede encontrar en el módulo de la API (api_module) del trabajo final. Parámetros de los devices Para obtener los parámetros previamente definidos de los devices, es necesario seguir una serie de pasos hasta llegar a los parámetros requeridos. En la Ilustración 21 se puede observar el diagrama de bloques de lo que concierne a la obtención de estos parámetros de una forma sencilla. 23 Ilustración 21: Diagrama de bloques de la obtención de parámetros de los devices El diagrama se podría resumir en los siguientes puntos: • Pedir las credenciales del usuario con el que se quiere realizar el análisis. • Obtener un token para la API asociado al usuario para mayor seguridad. • Obtener los grupos asociados al usuario. • Seleccionar un grupo y obtener todos los devices asociados a este. • Seleccionar el rango de fechas en las que se quiere realizar el análisis. • Obtener todos los payloads de todos los devices en ese rango de tiempo. Toda esta información obtenida se va almacenando en diferentes archivos JSON para poder tratar estos datos más adelante. Entrando más en detalle en cada uno de estos puntos, lo primero de todo es autenticarse contra el servidor mediante unas credenciales. Estas credenciales son el usuario y contraseña que se utilizan para la interfaz web de Orbiwise. Tal y como Itelazpi tiene organizado los diferentes usuarios, las credenciales utilizadas para el caso de estudio de Galdakao solo sirven para un único cliente (CABB) y una única marca de contadores en concreto (iTron). Como la parte de seguridad es importante ya que se está trabajando sobre una red en producción, se ha decidido utilizar un token para aumentar la seguridad de las llamadas a la API, en vez de estar transmitiendo una y otra vez las credenciales mismas. 24 Para ello, la API de Orbiwise cuenta con un endpoint que permite obtener un token para un cierto tiempo con el que las llamadas a la API quedaran autenticadas con el usuario y contraseña que previamente se han introducido. El endpoint en cuestión es el siguiente: https://itelorbiwise.itelazpi.eus/rest/oauth2/token Y hace falta pasarle los siguientes datos para obtener el token: • “grant_type”: “password” • “username”: {usuario} • “password”: {contraseña} Una vez obtenido el token, el siguiente paso es obtener todos los grupos dentro del usuario. Como ya se ha mencionado anteriormente, los grupos son una forma de organizar los dispositivos, y entre las formas de organizarlos se encuentra la geográfica, definiendo un grupo por cada municipio y asignado estos grupos a cada device correspondiente. El endpoint para obtener los grupos es el siguiente: https://itelorbiwise.itelazpi.eus/rest/groups Y se le pasa el siguiente parámetro: • “Authorization”: “Bearer {token}” Con esto se obtiene una lista de todos los grupos existentes en ese usuario. De estos grupos se selecciona uno de ellos, en este caso “galdakao", y se vuelve a hacer una llamada a la API para obtener todos los devices asociados al grupo. Para ello se llama al siguiente endpoint: https://itelorbiwise.itelazpi.eus/rest/groups Como el número de devices puede ser elevado (en el caso de Galdakao unos 13.000), la API para evitar sobrecargas devuelve un máximo de 2.000 devices por llamada, pero es posible obtenerlos todos si se le añaden los siguientes parámetros para obtener una lista paginada: • “Authorization”: “Bearer {token}” • “group”: “galdakao" • “limit”: 2000 • “get_pages”: “true” Con esta llamada, la API devuelve varias referencias a las diferentes páginas para poder realizar varias consultas una detrás de otra para ir obteniendo los devices asociados al grupo en grupos de 2.000 devices por llamada. Estas referencias vienen en el parámetro “page_state”, y añadiendo este nuevo parámetro a la llamada al endpoint en vez de “get_pages”, se van obteniendo todos los devices asociados al grupo seleccionado. Finalmente, una vez habiendo obtenido la lista de todos los devices de los que se va a realizar el análisis, se obtendrán todos los payloads de estos, esto es, todos los datos que los devices han enviado. 25 Para ello, primero será necesario seleccionar un rango de tiempo en el que se va a realizar el análisis. En el caso de Galdakao, los análisis recogen datos de 7 días, tiempo suficiente para tener una cantidad de datos considerable. Se podría escoger un rango más amplio, pero esto supone más cantidad de datos, o lo que es lo mismo, más carga de trabajo para la API y para la aplicación a desarrollar en sí. Para obtener los payloads de cada device, es necesaria una llamada a la API por cada device. https://itelorbiwise.itelazpi.eus/rest/nodes/{deveui}/payloads/ul Además, a cada llamada es necesario añadirle los siguientes parámetros: • “Authorization”: “Bearer {token}” • “data_format”: “hex" • “from_date”: {fecha de inicio del análisis} • “to_date”: {fecha de fin del análisis} Una vez realizadas todas las llamadas a la API necesarias y habiendo obtenido todas las respuestas, todos estos datos se almacenan en archivos JSON para trabajar con ellos más adelante. Con esto habría concluido la extracción de datos de los devices de la API, por lo que ahora es el turno de los Gateways. Parámetros de los Gateways Para la obtención de los parámetros de los Gateways, se seguirá la lógica explicada en el diagrama de bloques de la Ilustración 22. Ilustración 22: Diagrama de bloques de la obtención de parámetros de los Gateways 26 El diagrama de la imagen es parecido al de los devices, teniendo un inicio prácticamente idéntico. Entrando en más en detalle en el diagrama, los pasos a seguir para obtener los parámetros predefinidos de los Gateways serían los siguientes: • Pedir las credenciales del usuario administrador de Gateways. • Obtener un token para la API asociado al usuario para mayor seguridad. • Obtener la lista de todos los Gateways de la red. • Seleccionar los Gateways a analizar y obtener los parámetros de cada uno de ellos. Al igual que se ha hecho con los devices, estos datos se almacenarán en archivos JSON para poder trabajar con ellos más adelante. Entrando en detalle en cada bloque, se puede observar que hasta la obtención del token el proceso es idéntico al conseguido con los devices. La única diferencia serían las credenciales usadas para obtener el token, ya que, para el caso de los Gateways, existe un usuario que se encarga de almacenar la información de todos los Gateways. Por eso mismo, el endpoint para obtener el token es el mismo, pero los parámetros utilizados son diferentes: https://itelorbiwise.itelazpi.eus/rest/oauth2/token Los parámetros en cuestión serían los siguientes: • “grant_type”: “password” • “username”: {usuario_gateways} • “password”: {contraseña_gateways} Una vez obtenido el token, el siguiente paso es obtener la lista de todos los Gateways que forman la red LoRa. Para ello, se llama al siguiente endpoint: https://itelorbiwise.itelazpi.eus/rest/gateways Y se le pasa el siguiente parámetro: • “Authorization”: “Bearer {token}” Una vez habiendo obtenido el listado de todos los Gateways, será necesario seleccionar cuales se van a analizar. Esto se puede hacer de una forma relativamente sencilla, ya que los Gateways se nombran teniendo en cuenta la ubicación en donde se han instalado, por lo que, para este caso de estudio de Galdakao, todos los Gateways que se encuentran instalados en el municipio, tienen en el nombre “Galdakao”. Teniendo ya los Gateways que se quieren analizar definidos, se pasa a utilizar la API del NST para obtener los parámetros de los Gateways. Como ya se ha mencionado anteriormente, esta API no funciona tan bien como la de Orbiwise, y para este caso de la obtención de los parámetros de los Gateways, el endpoint utilizados no devuelve un objeto al hacer la llamada, si no que, la única forma de obtener datos del endpoint es haciendo la llamada a través de un navegador, como si fuese una URL. Esto implica que la automatización del proceso se complica un poco, ya que es necesario el uso de un navegador en vez de llamadas a la API a través de código Python. Para solventar este problema, se utilizará web scraping [5], una técnica para obtener datos de páginas web de una forma automatizada. 27 La utilización del web scraping conlleva el uso de un navegador en segundo plano (totalmente transparente para el usuario), con lo que, ralentiza el proceso de la obtención de datos comparando a la utilización de únicamente llamadas simples a la API. Dicho esto, las URLs que se van a utilizar tendrán este formato: https://itelorbiwise.itelazpi.eus/tfw1/rest?getGWStatsAggregated=1&from={from_date} &to={to_date}&gw={gw_id}&tz=-60 Donde {from_date} y {to_date} serían las mismas fechas seleccionadas en la parte de obtención de los devices y {gw_id} sería el identificador único de cada Gateway, por lo que habría que utilizar una URL por cada Gateway que se quiera analizar. Todos los datos se irán almacenando en archivos de una forma ordenada para poder utilizarlos posteriormente en el tratamiento de estos datos y la creación de gráficos utilizando estos mismos. 5.2.2. Generación de scripts para la visualización de gráficos Después de haber generado los scripts para la obtención de los parámetros tanto de los devices como de los Gateways, el siguiente paso consiste en crear otros nuevos scripts para la creación de los gráficos que previamente se habían definido. Para ello, se seguirá utilizando el lenguaje de programación Python. Antes de empezar a crear los gráficos, es necesario adaptar los datos previamente obtenidos que se han ido guardando en diferentes archivos JSON. Con esto se pretende homogeneizar los datos y obtener un único archivo con los parámetros que se van a graficar para los devices y otro para los Gateways. NOTA: el código descrito en este subapartado (con algunas modificaciones ya que después se ha adaptado a la interfaz de usuario) se puede encontrar en el módulo de los datos (data_module) del trabajo final. Tratamiento de datos Para empezar, se han cogido todos los payloads, previamente obtenidos, de todos los devices y se han calculado los valores medios de diferentes parámetros, con los datos obtenidos de la franja de tiempo elegida. Esto se ha hecho ya que la API no devuelve los valores medios, sino que devuelve un valor asociado a cada uno de los payloads. Los parámetros de los cuales se ha calculado el valor medio son los siguientes: • RSSI • SNR • ToA • Número de Gateways alcanzados Por otro lado, se ha calculado también cual ha sido el Main Gateway más común para cada device de todos los payloads. Además, se han contado el número de mensajes (payloads) recibidos (received frames) y se ha calculado, en base al número máximo de mensajes recibidos, el número de mensajes perdidos (lost frames). Finalmente, del último payload recibido se extrae el SF en el cual está emitiendo el device. 28 Una vez hecho eso, se crea un nuevo archivo JSON con estos datos y también con varios parámetros que se han obtenido directamente de la API al listar los devices. El archivo en cuestión contara con los siguientes parámetros para cada device: • Deveui • Latitud • Longitud • Media de RSSI • Media de SNR • Media de ToA • Media de número de Gateways alcanzados • Main Gateway • Mensajes perdidos • Mensajes recibidos • Ultimo SF utilizado Teniendo todos estos datos, los únicos parámetros restantes para cada device son las distancias al Main Gateway y al Gateway más cercano. Para poder calcular estos parámetros, se utilizarán las coordenadas (latitud y longitud) de los devices y de los Gateways. Entonces, para cada device se calculará la distancia a su Main Gateway utilizando la fórmula de Haversine (Ilustración 23). Además, con el mismo método, se calculará la distancia al resto de Gateways del análisis y se obtendrá el más cercano al device y la distancia a la que se encuentra. Ilustración 23: Explicación gráfica de la fórmula de Haversine [6] Una vez habiendo realizado estos cálculos, se añaden los siguientes tres campos a los ya existentes para cada device, obteniendo así toda la información necesaria para cada uno de los dispositivos. • Distancia al Main Gateway (m) • Gateway más cercano • Distancia al Gateway más cercano (m) Teniendo ya un único archivo JSON con todos los parámetros de los devices, el siguiente paso es realizar algo similar con todos los Gateways. 29 Para ello, lo primero de todo sería unir los parámetros obtenidos individualmente de cada Gateway en un único archivo. En el caso de los Gateways, la API sí que facilita los valores medios de los parámetros, por lo que no sería necesario realizar cálculos como con los devices. De todos los parámetros que se obtienen de cada Gateway haciendo web scraping, se guardaran los siguientes: • Identificador de Gateway • Numero de mensajes de uplink recibidos • Numero de paquetes perdidos • Media de RSSI (de los paquetes recibidos) • Media de SNR (de los paquetes recibidos) Y una vez unificados todos eso datos, se combinarán con los obtenidos al haber listado los Gateways, los cuales son los siguientes: • Nombre del Gateway • Latitud • Longitud Con todo esto, el tratamiento de datos se puede dar por finalizado ya que se ha conseguido unificar los parámetros de los devices en un único archivo JSON, al igual que los parámetros de los Gateways, que se guardan en otro archivo JSON diferente. Creación de gráficos Teniendo ya todos los parámetros tanto de los devices como de los Gateways en archivos JSON de un formato conocido, el siguiente paso es generar los scripts para obtener los gráficos previamente definidos a partir de estos datos. Los gráficos que se van a crear van a ser interactivos, esto es, no una simple imagen sino unos gráficos en los que se van a poder añadir y quitar ciertos parámetros, hacer clic en las barras de los datos y obtener información adicional, etc. Para ello, los gráficos generados tendrán la extensión HTML, en vez de las típicas PNG o JPEG de las imágenes. El primer gráfico que se va a generar será el mapa que contendrá la localización de los Gateways, con información adicional de cada uno de estos, y la ubicación de cada device. Estos últimos serán representado como puntos, ya que al poder ser tantos (en este caso unos 13.000), el mapa tarda demasiado tiempo en cargar y no es cómodo visualizarlo. Para crear el mapa se han utilizado 2 librerías de Python: • Geopy [7]: Para obtener las coordenadas centrales del municipio del que se realiza el análisis y así centrar el mapa. • Folium [8]: Para dibujar un mapa y añadir marcadores de los Gateways y los devices de una forma sencilla. Con la ayuda de estas librerías, se ha generado un script capaz de crear un mapa interactivo que muestre todos los Gateways y devices seleccionados para el análisis y guardar este mapa en un archivo HTML (mapGWsAndDevices.html). 30 Los gráficos restantes son gráficos de barras, por lo que no necesitaran las librerías geopy y folium, pero si esta otra: • Plotly [9] Esta librería facilita la creación de gráficos interactivos, entre ellos los de barras, que ha sido el método elegido para visualizar los datos. Los primeros gráficos de barras que se van a crear son los relacionados con los Gateways, los cuales tienen en el eje X cada uno de los Gateways que se ha seleccionado para el análisis. Todos los datos necesarios para crear estos gráficos se encuentran en el JSON de información de los Gateways. Una vez teniendo esos datos, para la creación de los gráficos se utilizará como eje X el identificador del Gateway, y para el eje Y, los siguientes parámetros, uno para cada gráfico. • Numero de mensajes de uplink recibidos • Numero de paquetes perdidos • Media de RSSI (de los paquetes recibidos) • Media de SNR (de los paquetes recibidos) Y con estos datos se generan los siguientes gráficos interactivos. • uplinkFrameCounter_x_gateways.html • lostFrameCounter_x_gateways.html • averageRSSI_x_gateways.html • averageSNR_x_gateways.html Con estos gráficos generados, el siguiente paso sería el crear otros scripts para los gráficos de los devices. Primero, se crearán los gráficos de distribuciones, después los que ordenan los devices por distancias al Main Gateway, y finalmente, los que los ordenan por el ultimo SF utilizado. Empezando con las distribuciones, lo primero que se ha hecho es organizar y agrupar los datos en bloques para poder mostrar de una forma sencilla, pero a la vez significativa, los datos obtenidos. Los valores se han agrupado de la siguiente manera: • Media de RSSI: se ha redondeado el valor de cada device al entero más cercano, haciendo que en el eje X se muestren solo los valores enteros en saltos de 1 dBm. El eje Y muestra el número de devices que, después de redondear, tienen esa media de RSSI. • Media de SNR: exactamente igual que la media de RSSI, pero con los valores de SNR. El eje X muestra valores enteros de SNR en saltos de 1 dB y el eje Y el número de devices que tienen esa media de SNR, después de haber redondeado el valor. • Media de ToA: el valor de ToA se redondea al entero múltiplo de diez más cercano, dejando así en el eje X saltos de 10 ms. • Mensajes perdidos: el número de mensajes perdidos siempre va a ser un número entero, por lo que se agrupan dependiendo ese número. • Mensajes recibidos: al igual que el número de mensajes perdidos, estos también serán un número entero. Además, este gráfico y el de mensaje perdidos será inversamente proporcional. • Media de número de Gateways alcanzados: el número de media de Gateways alcanzados se redondea al décimo más cercano, dando más precisión al grafico que si 31 se redondease al entero más cercano. Por lo que, el eje X muestra saltos de 0.1 Gateways alcanzados. • Main Gateways: en este caso, el eje X serán los identificadores de los Gateways (como con los gráficos de los Gateways) y como cada device cuenta con un Main Gateway, se cuentan el número de ocurrencias de cada uno de estos y se muestran en el gráfico, siendo el eje Y el número de devices que tienen a dicho Gateway asociado como el Main Gateway. • Último SF utilizado: parecido al gráfico de Main Gateways, pero en este caso se utilizado el parámetro del último SF utilizado por cada device como eje X. Como eje Y, el número de devices que han utilizado ese SF. Siguiendo el mismo orden que la lista anterior, los gráficos que se obtienen se guardan con los siguientes nombres: • RSSI_distribution.html • SNR_distribution.html • timeOnAir_distribution.html • lostFrames_distribution.html • receivedFrames_distribution.html • averageGatewaysReached_distribution.html • mainGateways_distribution.html • lastSFUsed_distribution.html Una vez generado los gráficos de distribuciones, los siguientes gráficos son los relacionados con las distancias de los devices al Main Gateway. Para ello, se agrupan los devices a partir de la distancia al Main Gateway y redondeando al centenar más cercano, dejando así en el eje X la distancia al Main Gateway en saltos de 100 metros. Una vez teniendo los devices agrupados de esta manera, se calcularán las medias de diferentes parámetros dentro de cada rango de distancia, para así poder graficar los valores de los devices de una forma relativamente precisa sin sobrecargar mucho el grafico de datos. Las medias calculadas por cada agrupación de distancia han sido de los siguientes parámetros: • Media de RSSI: se calcula la media de todas las medias de RSSI de los devices que estén dentro del rango de distancia. Además de graficar las barras, una para distancia, también se grafica una línea continua para poder observar la media acumulada de todos los valores de RSSI de los devices que se encuentran a menos de X distancia del Main Gateway, donde X es 100, 200, 300, etc. • Media de SNR: exactamente igual que con los valores de RSSI, pero con los valores de SNR para este gráfico. Además de la media acumulada. • Media de ToA: igual que con RSSI y SNR, pero esta vez con los valores de Time on Air en milisegundos. También se grafica la media acumulada para este caso. • Media de mensajes perdidos: para este grafico se calcula la media de mensajes perdidos por device en el rango de distancia al Main Gateway. Además, se calcula también la media acumulada de mensajes perdidos a lo largo de las distancias. • Media de mensajes perdidos en porcentaje: se utilizan los mismos datos que para el anterior gráfico, pero en vez de utilizar el valor absoluto de mensajes perdidos, se 38 Ilustración 32: Pantalla con la lista de todos los Gateways (GUI funcional) En esta pantalla, se podrán filtrar por nombre y seleccionar los Gateways que se deseen incluir en el análisis. En la Ilustración 33 se puede observar que para este caso práctico se han seleccionado los Gateways de la zona de Galdakao, los cuales todos ellos tienen en el nombre la palabra “Galdakao”. Ilustración 33: Pantalla con Gateways seleccionados (GUI funcional) 39 Una vez seleccionados los Gateways deseados, se pasará a la siguiente pantalla (Ilustración 34), donde de nuevo se podrá ver una barra de carga mientras se van obteniendo los parámetros de los Gateways seleccionados. Ilustración 34: Pantalla de obtención de parámetros de Gateways (GUI funcional) Al finalizar esta obtención de datos, se pasará a la siguiente pantalla (Ilustración 35) donde se iniciará la creación de los gráficos a partir de los parámetros que se han ido obteniendo hasta el momento. Ilustración 35: Pantalla de creación de gráficos (GUI funcional) Al finalizar, se mostrará una nueva pantalla simple (Ilustración 36) con la cual se informa al usuario de que el proceso ha finalizado. Ilustración 36: Pantalla de finalización (GUI funcional) Con esto, la parte de realizar un análisis de la red estaría cubierta. Pero, en la pantalla de inicio (Ilustración 25) existe la posibilidad de realizar una comparativa entre dos análisis previamente realizados, para poder obtener los gráficos de ambos análisis unificados y poder analizar mejor la información obtenida. Una vez en esta pantalla (Ilustración 37), se le dará al usuario la opción de elegir dos carpetas (FromXXXXXX_ToYYYYYY) que contienen los análisis previos. 40 Ilustración 37: Pantalla de selección de carpetas (GUI funcional) Habiendo seleccionado las carpetas, se generarán los gráficos correspondientes en un nuevo directorio que sigue la siguiente jerarquía: • Grupo o FromXXXXXX_ToYYYYYY o FromAAAAAA_ToBBBBBB o Compare_XXXXYYYY_to_AAAABBBB ▪ distancesToMainGateway ▪ distributions ▪ gateways ▪ lastSFused Donde se creará la carpeta “Compare_XXXXYYYY_to_AAAABBBB” y ahí se guardarán los gráficos creados a partir de los análisis que se habían realizado en las carpetas “FromXXXXXX_ToYYYYYY” y “FromAAAAAA_ToBBBBBB”. Mientras se generan los gráficos, se volverá a visualizar una barra de progreso (Ilustración 38) para indicar al usuario el porcentaje de completado del proceso. Ilustración 38: Pantalla de creación de gráficos combinados (GUI funcional) Finalmente, cuando termina el proceso se puede ver la pantalla de finalización (Ilustración 36) al igual que se podía ver cuando se terminaba un análisis. Con esto, se puede dar por finalizada la interfaz gráfica funcional, ya que cubre la mayoría de aspectos necesarios para realizar un análisis y poder realizar comparativas entre los diferentes análisis realizados. 5.2.4. Creación de interfaz de usuario final Con el fin de crear una aplicación más profesional y amigable para el usuario final, se decide mejorar la interfaz gráfica añadiéndole algo de diseño y alguna nueva funcionalidad entre otras cosas. Además, la interfaz de usuario funcional es únicamente código Python, ejecutado desde la línea de comandos, pero para crear una aplicación funcional en cualquier ordenador de 41 Itelazpi, será necesario crear un instalador, ya que no todos los ordenadores, ni usuarios, tienen por qué poder o saber ejecutar Python. Por ello, en este apartado primero se describirán los cambios de diseño realizados a la aplicación funcional y finalmente se explicará cómo se ha pasado de tener código Python únicamente ejecutable desde la línea de comandos a un instalador capaz de instalar el programa, y todas las dependencias, en cualquier ordenador. Nuevo diseño En el nuevo diseño, la funcionalidad de la aplicación es prácticamente idéntica, pero con alguna diferencia en la parte de comparación de análisis y en la finalización de obtención de datos. En la Ilustración 39 se puede observar el diagrama de bloques de esta nueva interfaz, la cual varia ligeramente con el mostrado en la interfaz funcional. Ilustración 39: Diagrama de bloques de la GUI final Además de estos cambios, esta nueva interfaz se ha diseñado con la intención de ser más amigable para el usuario, además de más atractiva visualmente. Para esto último, se ha utilizado la web “Figma” [12], la cual ofrece una herramienta de diseño de aplicaciones a través de un editor de arrastrar y soltar (Drag & Drop). 42 Por otro lado, para exportar los diseños creados con el editor e importarlos en la aplicación diseñada en forma de código Python, se ha hecho uso de la herramienta “Tkinter-Designer” [13], la cual permite transformar los diseños creados con el editor en código Python. Para ello, a la herramienta el usuario únicamente tiene que pasarle 3 parámetros. • Token ID: Token generado dentro de la propia cuenta de Figma para identificar al usuario. • File URL: URL del diseño creado por el usuario. • Output Path: Carpeta de destino en el ordenador para guardar el código y los demás recursos. En la Ilustración 40 se puede observar el diagrama de funcionamiento de esta herramienta, de una forma clara. Ilustración 40: Diagrama de funcionamiento de "Tkinter-Designer" 43 Haciendo uso de estas herramientas, se ha mejorado la interfaz gráfica con el fin de hacerla más agradable y atractiva para el usuario final, añadiéndole colores, una mejor organización, diseño, etc. NOTA: el código descrito en este subapartado se puede encontrar en el módulo de la interfaz de usuario (gui_module) del trabajo final. Dejando esto claro, al ejecutarse la aplicación final se podrá ver una nueva pantalla de inicio (Ilustración 41), con las mismas funcionalidades que tenía la interfaz funcional, pero con un diseño renovado. Ilustración 41: Pantalla principal (GUI final) Comparando con la interfaz funcional, en esta pantalla se ha añadido el nombre de la aplicación en modo de portada, texto explicativo para cada acción y diseño en los botones y entradas de texto. Además, a la ventana como tal, se le ha añadido el logo de Itelazpi (arriba a la izquierda) y se le ha puesto un nombre significativo a la ventana. En cuanto a la funcionalidad, esta no ha cambiado. Se pueden introducir las credenciales del usuario donde se encuentran los dispositivos para realizar el análisis o pulsar el botón “Iniciar comparativa” para comparar diferentes análisis ya realizados. Si se introducen las credenciales (unas correctas), se mostrará la siguiente pantalla (Ilustración 42), donde se podrán ver los grupos que existen en este usuario. 44 Ilustración 42: Pantalla de selección de grupo (GUI final) En esta pantalla se ha ajustado un poco el tamaño de los elementos y se ha añadido texto explicativo, además de cambiar el diseño del botón. Aquí se podrá filtrar y buscar el grupo deseado y una vez seleccionado se pasará a la siguiente pantalla (Ilustración 43), donde se seleccionarán las fechas de inicio y final del análisis. Ilustración 43: Pantalla de selección de tiempo (GUI final) 45 En esta nueva pantalla se han centrado los elementos para dar una mejor imagen a esta, además de exponer la información obtenida (número de devices) de una forma clara y concisa. Una vez se seleccionan las fechas para el análisis, en la siguiente pantalla (Ilustración 44) se podrá ver el progreso de obtención de los payloads de esas fechas de los devices del grupo elegido. Ilustración 44: Pantalla de obtención de payloads (GUI final) En esta pantalla se muestra ahora el tiempo seleccionado para el análisis, en días, y el número de dispositivos de los cuales se va a extraer información. Además, también se añade texto explicativo. Una vez finalizada la obtención de los datos, se pasará a la siguiente pantalla (Ilustración 45), donde se le indicará al usuario que debe elegir un directorio para guardar los datos. 46 Ilustración 45: Pantalla de guardado (GUI final) En esta nueva pantalla se ha añadido bastante información sobre cómo se van a generar los subdirectorios de los datos, ya que en la interfaz funcional esta información no se explicaba por ningún lado. Por la parte de funcionalidad, es exactamente igual que lo que era en la interfaz funcional, por lo que, seleccionando un directorio raíz, se crearan los diferentes subdirectorios, separando, grupos, rangos de tiempo, datos y gráficos. Una vez elegido el directorio raíz, se mostrará la siguiente pantalla (Ilustración 46) con la información del directorio seleccionado. 47 Ilustración 46: Pantalla de datos guardados (GUI final) Al presionar el botón “Siguiente”, se pasará a la siguiente pantalla (Ilustración 47), donde se pedirán las credenciales del usuario administrador de los Gateways. Ilustración 47: Pantalla de ingresar credenciales para los Gateways (GUI final) Una vez introducidas las credenciales, y si son correctas, se mostrará una lista (Ilustración 48) con todos los Gateways administrados por ese usuario. De esa lista, se tendrán que elegir los Gateways deseados para realizar el análisis. 54 Una vez la ejecución del comando se ha completado, se habrá creado un ejecutable (LoRa Network Analyzer.exe, Ilustración 57), con el icono que se había predefinido. Ilustración 57: Ejecutable de la aplicación Este archivo ejecutable únicamente funciona bien en la maquina en la que se ha creado, ya que, para su funcionamiento, está obteniendo recursos de otros directorios. Para que el ejecutable funcione en cualquier otro ordenador, habría que mover a esos ordenadores tanto el ejecutable como el directorio de recursos. Esto, por mucho que sea funcional, no es demasiado profesional, ya que, cualquier programa que se instala en el ordenador se suele hacer a través de un archivo “setup”, con el cual se instalan todos los elementos necesarios. Con el fin de imitar esta práctica y crear una aplicación más profesional, se utiliza el programa “Inno Setup” [17], el cual permite crear un único archivo de setup para poder instalar la aplicación y todos los recursos necesarios. Para poder crear el archivo setup, son necesarios los siguientes elementos: • Nombre de la aplicación: el nombre con el que se instalará. • Archivo ejecutable: el de la aplicación que se ha desarrollado. • Recursos extra: recursos necesarios para el correcto funcionamiento de la aplicación. • Licencia de la aplicación creada: documento legal del uso que se le puede dar a la aplicación. • Nombre del setup: el nombre del archivo setup. • Icono del archivo setup: icono con el que se creara el archivo de setup. Con estos elementos y siguiendo los pasos, se obtendrá el archivo setup que se podrá mover a cualquier ordenador y al ejecutarlo y seguir los pasos indicados, se instala la aplicación que ha sido desarrollada para realizar análisis de la red LoRa de Itelazpi. 5.2.5. Corrección de errores y casos límites A lo largo del tiempo que se iba creando la interfaz funcional y la aplicación final, se han ido encontrando varios errores o mejoras posibles para que el funcionamiento de la aplicación sea el óptimo. Las correcciones más significativas se pueden agrupar en 4 grupos: • Obtención del endpoint correcto dependiendo la red en la que se encuentre el usuario. • Manejo de excepciones de fallos de autenticación. • Aplicación multihilo. • Manejo de casos límites con falta de datos. 55 En los siguientes subapartados se explicará más detalladamente cada una de estas correcciones. Obtención de endpoint En un principio, la aplicación ha sido desarrollada en un ordenador, pero esta aplicación tiene que ser ejecutable en cualquier ordenador de Itelazpi, se encuentre donde se encuentre. Teniendo esto en cuenta, se han detectado diferentes posibilidades en donde el ordenador puede encontrarse en diferentes redes, por lo que es necesario garantizar la conectividad desde esas redes a los endpoints de las APIs utilizadas. Las diferentes redes donde podría encontrarse el ordenador son las siguientes: • Red cableada de Itelazpi (salida a internet por EJIE) • Red WiFi de Itelazpi (salida por la IP pública de Itelazpi) • VPN de Itelazpi • Resto de casos Estos 4 casos se pueden agrupar en dos grupos. Por una parte, las redes conocidas de Itelazpi (red de EJIE, WiFi de Itelazpi y VPN de Itelazpi), y por otra, las redes desconocidas. En el primer grupo, al ser estas redes conocidas, se puede configurar la aplicación para detectar el prefija de las direcciones IP de esas redes y utilizar un endpoint para este caso. El enpoint en cuestión será el accesible únicamente desde la IP privada, ya que estas redes tienen acceso al direccionamiento privado de los servidores donde está instalado el Network Server de Orbiwise. En el segundo grupo, como en este se engloban el resto de opciones, se opta por asignarle el direccionamiento público, ya que este será accesible desde la gran mayoría de redes. Excepciones de fallo de autenticación Al estar desarrollando la aplicación en un entorno controlado y cerrado, el fallo de autenticación por la introducción errónea de credenciales por parte del usuario no se tuvo en cuenta. Esto hizo que la aplicación no supiese manejar esas excepciones y que al introducir unas credenciales incorrectas la aplicación se quedase congelada, teniendo que cerrarla y volver a abrir para poder volver a trabajar con ella. Esto sumado a que no se guarda el estado del análisis que se está llevando a cabo, hacia que, si se erraba en la inserción de credenciales del usuario administrador de los Gateways, se perdía todo el progreso realizado hasta el momento. Para evitar que esto pase, se ha tenido en cuenta que puede ser que las credenciales pueden no ser correctas, y para indicarle al usuario que debe volver a introducir de nuevo las credenciales, de forma correcta esta vez, la aplicación lanza una ventana emergente (Ilustración 58) con esta información. Ilustración 58: Ventana emergente al introducir credenciales erróneas 56 Programación multihilo La aplicación desarrollada tiene como objetivo realizar diferentes análisis de la red LoRa de Itelazpi, y para ello, necesita una gran cantidad de datos para obtener resultados. La obtención de estos datos es manejada por la API de Orbiwise, pero al ser tal la cantidad (para el análisis de Galdakao, 7 días de datos de 13.000 dispositivos), el tiempo de obtención de estos es muy significativo (entre 30 y 40 minutos para Galdakao). Por ello, en la aplicación se implementan las barras de carga, para que el usuario pueda observar el progreso realizado hasta el momento. Pero, al implementar esto, la aplicación tiene que ser capaz de manejar la interfaz gráfica y las llamadas a la API de forma simultánea, ya que, si no, la aplicación entraría en modo “No responde” (ya que la interfaz gráfica se queda congelada) por mucho que las llamadas a la API se sigan ejecutando. Para el usuario final, si no sabe el funcionamiento de la aplicación, le da la sensación de que la aplicación se ha colgado, por mucho que no sea así. Es por eso que, para evitar esta situación, en los casos que la aplicación debe hacer llamadas a la API, se hacen desde un hilo diferente, para que la interfaz gráfica siga funcionando y el usuario pueda observar que la aplicación está trabajando y mostrando el progreso. Casos límite de falta de datos Al igual que se ha explicado con las excepciones de autenticación, esta aplicación se ha desarrollado en un entorno cerrado y siempre utilizando los mismos datos, los necesarios para un análisis en Galdakao. Pero, función de la aplicación debe ser aplicable a todos los escenarios posibles, es decir a los diferentes municipios en los que Itelazpi cuenta con cobertura LoRa y sensores. Por ello, es posible que, en los diferentes casos, falten ciertos datos que hacen que la aplicación deje de funcionar correctamente y que no se generen los resultados deseados, o ningún resultado en el peor de los casos. Tras realizar diferentes análisis y pruebas a la aplicación, los casos donde pueden faltar datos que han sido corregidos son los siguientes: • Sin grupos en el usuario con el que se ha hecho login. • Grupo no seleccionado para realizar el análisis. • Sin datos de los devices en las fechas seleccionadas. • Sin Gateways con el usuario administrador de Gateways (login con otro usuario). • Gateways no seleccionados para realizar el análisis. • Sin datos de los Gateways en las fechas seleccionadas. • Parámetros faltantes para realizar algún gráfico. • Archivos JSON no encontrados para realizar comparativas. Al realizar estas correcciones, se pretende maximizar la eficacia de la aplicación y hacer que el usuario pueda utilizarla de una manera sencilla, sin miedo a equivocarse y tener que volver a empezar desde el principio. 57 5.3. Estudio inicial En este tercer apartado se analizará la red tal y como se configura por defecto, con el fin de ver el estado base de la red y poder determinar los cambios que podrían ser beneficiosos para aumentar la calidad de esta. Para el análisis, se obtendrán los parámetros tanto de los Gateways como de los devices, haciendo uso de los scripts que se han preparado con anterioridad. Una vez obtenidos esos datos, se les aplicará un procesado y se generarán los gráficos predefinidos, estos también, con los scripts que se habían preparado. Finalmente, se hará una interpretación de estado actual de la red analizando los gráficos, y se valorarán cuáles han sido los resultados obtenidos y cuál es la calidad de la red tras este primer análisis. En resumen, en este bloque se explicarán en profundidad los siguientes subapartados: • Obtención de los datos de los Gateways • Obtención de los datos de los devices • Procesado de datos • Generación de gráficos • Interpretación del estado de la red • Valoración de los resultados iniciales 5.3.1. Obtención de los datos de los Gateways Con el fin de realizar un análisis completo de la red, se obtendrán los parámetros de los Gateways seleccionados, es decir, los que se encuentran en Galdakao, ya que el análisis y las optimizaciones se harán en ese municipio. En la red LoRa de Itelazpi, existen 16 Gateways que se encuentran en Galdakao, pero solo 15 de ellos se encontraban activos en el rango de fechas seleccionadas para la obtención de parámetros, por lo que, el análisis contará únicamente con 15 Gateways, ya que el decimosexto devolverá datos vacíos. Habiendo definido los Gateways de los que se quiere obtener la información, haciendo uso de los scripts, se creará un archivo JSON con la información estática de todos los Gateways seleccionados, la que se puede ver en la Ilustración 59. Ilustración 59: Información estática de un Gateway 58 El rango de tiempo seleccionado para el análisis ha sido de 7 días, ya que se ha considerado tiempo suficiente para realizar medias y cálculos estadísticos de los parámetros obtenidos, sin llegar a sobrecargar a la aplicación de datos, ya que esto la ralentizaría. Para la obtención de los datos, se utilizarán los scripts previamente creados, y con ellos se obtendrá un archivo JSON con la información de cada Gateway (Ilustración 60). Ilustración 60: Archivos JSON de los parámetros de cada Gateway Dentro de cada uno de estos archivos, se puede encontrar la información necesaria para el posterior análisis de la red, como se puede observar en la Ilustración 61. Ilustración 61: Ejemplo de datos de calidad de señal obtenidos de un Gateway Con estos datos, se puede dar por concluida la obtención de los parámetros de los Gateways en la fase inicial. 59 5.3.2. Obtención de los datos de los devices A la vez que se realiza la obtención de los datos de los Gateways, también se obtienen los parámetros de los devices, ya que se pretende usar la misma franja de tiempo (los mismos 7 días) para analizar los parámetros y hacer los cálculos estadísticos pertinentes. Para obtener los datos necesarios para el análisis, se utilizarán los scripts previamente creados, con los cuales se obtendrán 2 archivos JSON. El primero de ellos contará con la información estática de los devices, la que se puede observar en la Ilustración 62. Ilustración 62: Información estática de un device El segundo archivo contiene los parámetros de calidad de los mensajes transmitidos durante los 7 días seleccionados (Ilustración 63). 60 Ilustración 63: Información de cada mensaje transmitido de un device Con todos estos datos conseguidos de los devices, se puede dar por finalizada la obtención de los parámetros, ya que, con estos dos archivos JSON creados, es posible realizar un análisis muy completo de la calidad de la red. 5.3.3. Procesado de datos Una vez obtenidos los archivos con los datos “en crudo” tanto de los Gateways como de los devices, es necesario hacerles un tratamiento para seleccionar los datos realmente importantes para el análisis, así como obtener ciertos parámetros derivados de los originales, como pueden ser medias, máximos, etc. Por la parte de los Gateways, se unifican los datos estáticos con la información de la calidad de señal que han recibido durante los 7 días y se genera un único archivo con toda la información necesaria para la generación de gráficos relacionados a los Gateways (Ilustración 64). 61 Ilustración 64: Ejemplo de datos unificados de un Gateway Por la parte de los devices, el procedimiento seguido es similar, creando un único archivo JSON (Ilustración 65) que contiene tanto la información estática de cada device como las estadísticas obtenidas a través de los datos de calidad de señal durante los datos de los 7 días obtenidos. Ilustración 65: Ejemplo de datos unificados de un device Con estos dos archivos JSON creados, es posible generar los gráficos que se había definido al inicio del proyecto, para así poder analizar la calidad de la red durante los 7 días en los que se ha realizado el análisis. 5.3.4. Generación de gráficos Habiendo tratado ya los datos y generado los archivos JSON con la información necesaria tanto de los Gateways como de los devices, haciendo uso de los scripts ya preparados, se empiezan a generar los gráficos predefinidos. Empezando por el mapa, en la Ilustración 66 se puede observar como este ha sido creado añadiendo los Gateways como etiquetas y los devices como simples figuras circulares (con el fin de no sobrecargar el propio mapa y que la experiencia de usuario sea buena). Además, el mapa se ha centrado automáticamente en la zona de Galdakao, como se había predefinido. 62 Ilustración 66: Mapa de Gateways y devices de Galdakao Si se hace zoom en la imagen, se puede observar cómo están repartidos los devices a lo largo de los edificios. Además, haciendo clic en las etiquetas de los Gateways, se puede obtener información extra (nombre del Gateway) con el fin de dar facilidades a la hora de identificarlos. Todo esto se puede ver en la Ilustración 67. Ilustración 67: Zoom del mapa de Gateways y devices de Galdakao 63 Este mapa puede servir para hacer una inspección visual de donde están situados los devices y Gateways, y así hacer una aproximación de por dónde puede faltar cobertura LoRa o donde puede ser necesario añadir otro Gateway para darle más capacidad a la red. En cuanto a los gráficos asociados a los Gateways, se han generado como se esperaba utilizando los scripts previamente creados. Como ejemplo, en la Ilustración 68 se puede observar cuantos mensajes de uplink ha recibido cada Gateway durante el transcurso de los 7 días, para así poder identificar cuáles son los Gateways con más tráfico. Ilustración 68: Gráfico de número de frames de uplink por Gateway (estudio inicial) Además, para facilitar la comprensión del gráfico, se ha añadido información extra a cada barra, a la cual se puede acceder fácilmente pasando el ratón por encima de la barra deseada. En esta información adicional se ha añadido el nombre del Gateway (para identificarlo más fácilmente que con el identificador único de Gateway) y el número exacto de frames de uplink. El resto de gráficos se han obtenido de la misma manera, ejecutando los scripts que se habían creado anteriormente y alimentándolos con los datos ya tratados tanto de los Gateways como de los devices. Los subgrupos de gráficos que también se han generado son las distribuciones de los parámetros de los devices (Ilustración 69), los que ordenan los datos dependiendo la distancia al Main Gateway y los que los ordenan dependiendo cual ha sido el último SF que han utilizado. 70 Por otro lado, en cuanto a la perdida de paquetes, lo ideal es que sea cero, pero eso es prácticamente inalcanzable por diferentes motivos ajenos a la propia red o de escalabilidad de esta. Para tener un objetivo realista, lo ideal es que no haya más de un 10% de perdida de paquetes en los devices analizados. Finalmente, los niveles de potencia de señal, aun estando dentro de lo normal para el protocolo LoRaWAN, se podría intentar aumentar estos valores con el fin de que los mensajes de los dispositivos más lejanos también acaben llegando a los Gateways, llegando a su vez al Network Server. En resumen, el porcentaje de mensajes perdidos supera el esperado, por lo que será necesario realizar acciones para reducir este número. Además, el número de devices que solo llegan a un único Gateway es algo alarmante, ya que esto puede suponer en ciertos escenarios un aumento significativo del porcentaje de paquetes perdidos. Por último, la potencia de señal recibida, aun estando dentro de las franjas que marca el propio protocolo LoRaWAN, no son del todo buenas, por lo que se intentara mejorar estos niveles. 5.4. Iteraciones de mejora A lo largo de este cuarto apartado, se partirá de las conclusiones obtenidas en el estudio inicial sobre el estado de la red LoRa y que cambios pueden ser aplicables para mejorar la calidad de servicio de esta. Primero se plantearán los parámetros avanzados de la red que se deben modificar con el fin de obtener las modificaciones en la red que se habían propuesto. Tras plantear estos parámetros, se aplicarán a la red, en este caso, a Galdakao únicamente, y se esperará un tiempo prudencial para que los cambios surtan efecto. El resto del análisis será similar al estudio inicial, ya que se obtendrán los parámetros tanto de los Gateways como de los devices, se procesarán los datos obtenidos y se crearán los gráficos de este nuevo análisis. Como diferencia con el anterior estudio, en este se utilizará la interfaz gráfica funcional para llevar a cabo el proceso de la obtención de los datos, el tratado y la generación de los gráficos. Además, no solo se generarán los gráficos de este análisis, sino que también se crearán gráficos comparativos entre este y el anterior. Finalmente, se hará una interpretación del estado de la red a través de los gráficos generado y se valorará el nuevo estado tras haber aplicado los cambios pertinentes. En resumen, en este bloque se explicarán en profundidad los siguientes subapartados: • Replanteamiento de nuevos parámetros QoS • Obtención de los datos de los Gateways • Obtención de los datos de los devices • Procesado de datos • Generación de gráficos • Interpretación del estado de la red • Valoración de los resultados tras los cambios 5.4.1. Replanteamiento de nuevos parámetros QoS Con el fin de cambiar la calidad de la red LoRa, se ha planteado cambiar diferentes parámetros QoS. El Network Server de Orbiwise permite al administrador de la red establecer perfiles de 71 calidad de servicio, pudiendo estos asignarse a usuarios enteros, grupos o incluso devices individuales. Los parámetros que se pueden modificar aparecen en la siguiente tabla (Tabla 9), además de una pequeña descripción de lo que significa cada parámetro y el valor que asigna Orbiwise en el perfil de QoS que viene por defecto en el propio Network Server. Nombre Descripción Valor LoRaWAN region Región de trabajo de LoRaWAN EU868 Min data-rate Data rate mínimo posible para uplink 0 Max data-rate Data rate máximo posible para uplink 5 Min TX power Potencia de transmisión mínima posible [dBm] en uplink 2 Max TX power Potencia de transmisión máxima posible [dBm] en uplink 16 SNR margin in dB Margen sobre el SNR promedio requerido para la demodulación 12 RSSI margin in dB Margen sobre el RSSI promedio requerido para la demodulación 12 Target redundancy Número de retransmisiones uplink, espaciales + temporales 0 Min unconfirmed UL repetitions Mínimo de veces que un mensaje de uplink tiene que ser recibido en el Network Server 1 Max unconfirmed UL repetitions Máximo de veces que un mensaje de uplink tiene que ser recibido en el Network Server 5 Averaging window length Longitud de la ventana de promediado 15 Additional SNR margin on join Margen adicional en el join cuando las estadísticas SNR no son buenas 10 Max SF steps for ADR on join Número máximo de cambios de SF en el join 5 Max SF steps for ADR Número máximo de cambios de SF en modo regular 2 Min number of gateways to receive device Número mínimo de Gateways que tiene que recibir las tramas 1 Delay between two TxPower control steps Retraso (mensajes) entre dos mensajes de control de potencia de transmisión 6 Gateway aggregation time [ms] Tiempo que el Network Server esperará para recopilar los mensajes de uplink 0 Tabla 9: Parámetros QoS configurables en el Nework Server Con las valoraciones del estudio inicial y viendo que parámetros QoS son modificables en el Network Server, se pueden seleccionar varios parámetros de estos para intentar modificar la calidad de la red LoRa e intentar obtener los resultados esperados. De todos los parámetros, se han seleccionado 4 de ellos para modificarlos, y así ver los cambios que estos producen en la red. 72 • Min Tx power: aumentando este parámetro se pretende obligar a los devices a transmitir a mayor potencia, dando mejor señal a los Gateways a cambio de mayor consumo de batería. • RSSI margin in dB: aumentando este parámetro, se obliga a los devices a transmitir con mayor potencia también, pero esta vez porque el Gateway necesita un margen de RSSI más alto para recibir y demodular el mensaje. • Target redundancy: aumentando este otro parámetro, se obliga al device a tener que transmitir el mensaje a un mínimo de dos Gateways, pero en el caso de que no llegue a dos Gateways diferentes, tendrá que retransmitir el mensaje de nuevo para el mismo Gateway. • Min number of gateways to receive device: aumentando este parámetro, se obliga al device a llegar a dos Gateways o más, únicamente siendo válida esta opción y no la de retransmisión de mensaje al mismo Gateway. Habiendo definido los parámetros QoS que se van a modificar y su porque, en la Tabla 10 se puede observar el valor inicial de este parámetro y su valor después de haberle aplicado el cambio. Parámetro Valor original Nuevo valor Min TX power 2 16 RSSI margin in dB 12 18 Target redundancy 0 1 Min number of gateways to receive device 1 2 Tabla 10: Nuevos valores de los parámetros QoS modificados (iteración) Con estos nuevos valores se pretende obligar a los devices a transmitir a una mayor potencia y a un número mayor de Gateways, con el fin de perder el mínimo número de mensajes. 5.4.2. Obtención de los datos de los Gateways Para la obtención de los datos de los Gateways, es necesario esperar cierto tiempo para que los nuevos parámetros QoS se apliquen correctamente. Estos parámetros son exclusivos de los devices, pero, los parámetros que se obtienen de los Gateways son información sobre los mensajes que han recibido de los devices, por lo que es necesario esperar hasta que los devices transmitan con normalidad con los nuevos parámetros cambiados. El tiempo que se debe esperar para obtener los datos es algo relativo, ya que depende cuanto tiempo tarden los devices en aplicar los cambios. Como para el análisis se están utilizando datos de 7 días, lo mínimo que se debe esperar es ese tiempo. Pero, los cambios aplicados a los devices no son instantáneos, ya que, para que el Network Server le comunique a un device cierta información, este debe hacerlo durante las ventanas de recepción de datos de los devices, tal y como indica el protocolo LoRaWAN. Los devices cuentan con dos ventanas de recepción que se abren después de enviar un mensaje, normalmente tras 1 y 5 segundos cada una, en los devices de clase A [18]. Los contadores de agua utilizados para este análisis únicamente envían entre 4 y 5 mensajes al día, por lo que la comunicación entre device y Network Server puede llegar a ser algo lenta. 73 Para evitar que parte de los contadores que se van a analizar no hayan aplicado los cambios, se ha optado por dejar 2 semanas de margen para que los devices puedan hacer los cambios que necesiten. Por ello, sumando las 2 semanas para aplicar los cambios y los 7 días de recolección de datos, se deben esperar, al menos, 3 semanas para realizar el nuevo análisis. La obtención de los datos de los Gateways en si es similar a la realizada en el estudio inicial, pero esta vez se utilizará la interfaz gráfica funcional para realizar estas tareas. Resumiendo, estos son los pasos que se seguirán para la obtención de los datos de los Gateways: • Seleccionar un rango de tiempo para el análisis. • Seleccionar los Gateways que se quieren analizar. • Obtención de información estática de cada Gateway (API Orbiwise). • Obtención de parámetros relacionados con la calidad de los mensajes de cada Gateway (web scraping). Una vez realizado estos pasos, se habrán conseguido los archivos JSON necesarios para su posterior tratamiento. 5.4.3. Obtención de los datos de los devices Para la obtención de los datos de los Gateways, también es necesario esperar las 3 semanas que se habían definido, por las mismas razones que para la obtención de los parámetros de los Gateways, explicadas en el apartado anterior. En la ilustración 80 se puede observar un mensaje de configuración que envía el Nework Server a un device, con el fin de que este cambie el SF que está utilizando. Ilustración 80: Mensaje de configuración del Network Server a un device En este caso, el device estaba emitiendo el SF10, y el mensaje de configuración le obliga a cambiar a SF12, tal y como se observa en el comando MAC que ha sido enviado (ilustración 81). Ilustración 81: Comando MAC enviado en el mensaje de configuración Una vez esperado el tiempo predefinido, se utiliza la interfaz de usuario funcional para realizar el nuevo análisis, en vez de tener que estar ejecutando diferentes scripts uno a uno en un orden concreto. Utilizando la GUI funcional, se deberán seguir los mismos pasos que con los scripts, pero de una forma mucho más guiada y con probabilidades mucho menores de que ocurra algún error durante el proceso. Los pasos a seguir en cuestión serían los siguientes: • Seleccionar usuario para el análisis. • Elegir un grupo (municipio) dentro de ese usuario. • Obtención de la información estática de todos los devices de ese grupo. 74 • Seleccionar un rango de fechas para el análisis. • Obtención de los parámetros relacionados con la calidad de los mensajes enviados por los devices durante el rango de tiempo seleccionado, para cada uno de los devices. Siguiendo estos pasos se habrán conseguido los archivos JSON necesarios para continuar con el análisis. 5.4.4. Procesado de datos Al igual que en el estudio inicial, tanto los datos obtenidos de los Gateways como de los devices tienen que ser procesados al formato JSON predefinido, para posteriormente poder generar los gráficos que se desean. Con la interfaz gráfica funcional, este proceso se realiza automáticamente una vez finalizada la obtención de los parámetros de los Gateways y de los devices, pero antes de que se generen los gráficos, como es lógico. El proceso de la generación de los archivos JSON procesados queda relegado a un segundo plano, dejando al usuario una pantalla de carga mientras se ejecuta este proceso. El formato de los datos procesados es exactamente igual a los que se han obtenido en el estudio inicial, tanto para los devices como para los Gateways. 5.4.5. Generación de gráficos La generación de gráficos durante este análisis también se realiza automáticamente, y en segundo plano, gracias a la interfaz de usuario funcional desarrollada. Los gráficos generados son los mismos que en el estudio inicial, pero con los datos de entrada de este nuevo análisis. Al igual que los gráficos generados para el estudio inicial, estos también se pueden separar en 5 categorías diferentes: • Mapas • Ordenado por Gateway • Distribuciones • Ordenado por distancias al Main Gateway • Ordenado por el ultimo SF utilizado Pero, además de todos estos gráficos, como este análisis trata de comparar los resultados con el estudio inicial, también se han creado gráficos comparativos entre los datos del primer análisis y los de este. Para realizar esto, también se ha utilizado la interfaz gráfica funcional, teniendo únicamente que seleccionar los datos obtenidos del primer análisis y los de este, relegando a un segundo plano la creación de estos gráficos. Los gráficos comparativos creados son exactamente los mismos que los generados para un análisis individual, a excepción del mapa, ya que no es necesario compara las posiciones de los Gateways y de los devices, ya que todos son elementos estáticos de la red. Entre estos gráficos comparativos, se puede encontrar el de la Ilustración 82, donde se muestra la media de RSSI (en dBm) de todos los paquetes recibidos por cada Gateway, diferenciando el primer análisis (en azul) con el segundo (en rojo). 75 Ilustración 82: Comparativa de la media de RSSI de los mensajes recibidos en cada Gateway Al igual que este gráfico, el resto de ellos que comparan el estudio inicial con este análisis realizado, tendrán el mismo formato, donde los datos del primer análisis se mostrarán en azul y los de la iteración de mejora en rojo. 5.4.6. Interpretación del estado de la red Analizando más en profundidad los gráficos que se han obtenido, se pueden obtener varias conclusiones de cómo ha cambiado el estado de la red en Galdakao. Para ver mejor los resultados, a lo largo de este apartado únicamente se utilizarán los gráficos comparativos entre el estudio inicial y el análisis realizado como iteración de mejora, y se mostrarán los que contengan información más significativa para analizar el cambio realizado en la red. Empezando por el grafico que muestra el número de mensajes recibidos por cada Gateway (Ilustración 83), se puede observar un aumento considerable en el número de mensajes en esta iteración comparado con el estado inicial de la red. Ilustración 83: Comparación del número de mensajes recibidos por cada Gateway 76 Por otro lado, si se observa el gráfico que muestra a cuantos Gateways llegan de media los mensajes de los devices (Ilustración 84), se puede observar un desplazamiento hacia la derecha de las barras, esto es, que ha aumentado la media de a cuantos Gateways llegan los mensajes enviados por los devices. Ilustración 84: Comparación del número de Gateways al que llegan los mensajes Si se observa el grafico de la distribución de los devices dependiendo del SF que están utilizando (Ilustración 85), se observa claramente que una gran cantidad de devices (unos 2.500) han pasado de utilizar SF7 a trabajar con SF12. Ilustración 85: Comparación del último SF utilizado por los devices Teniendo esto en cuenta, como el tiempo en el aire (ToA) de los mensajes aumenta a medida que aumenta el SF, en el grafico que muestra la media de ToA dependiendo a la distancia a la que se encuentren del Main Gateway (Ilustración 86), se puede observar claramente que la distancia ya no es un factor determinante en el tiempo que tarda el mensaje en llegar al Gateway, como pasaba en el estudio inicial, sino que ahora es mucho más constante independientemente de la distancia. 77 Ilustración 86: Comparación del ToA relativo a la distancia al Main Gateway Si se analiza las calidades de las señales recibidas, RSSI y SNR, se puede ver que ha habido un aumento considerable en estos dos parámetros. Mirando el grafico de la media de RSSI por cada SF diferente (Ilustración 87), se puede observar un aumento de entre 7 y 10 dBm para cada SF. Y si se observa el grafico de SNR en función del SF (Ilustración 88), se puede ver que ahora el único SF que tiene un SNR negativo es el SF12, en el resto se recibe más señal que ruido. Ilustración 87: Comparación de RSSI en función de SF 78 Ilustración 88: Comparación de SNR en función de SF Observando las distribuciones de estos dos parámetros, se puede ver que, en las medidas que había un mayor número de devices, una parte de esos se han desplazado hacia la derecha, aumentando el nivel de RSSI y de SNR. Esto se puede ver en la Ilustración 89 e Ilustración 90 respectivamente. Ilustración 89: Comparación de la distribución de RSSI 79 Ilustración 90: Comparación de la distribución de SNR Finalmente, analizando los gráficos que muestran las tasas de mensajes recibidos y perdidos, se puede observar que el número de devices que han recibido una mayor cantidad de mensajes a aumentado, como se puede ver en la Ilustración 91. Además, se puede ver que, en este análisis, algunos devices (424) han llegado a transmitir 33 mensajes, en vez de los 32 como máximo que se habían transmitido en los 7 días del estudio inicial. Ilustración 91: Comparación del número de mensajes recibidos Por otro lado, si se analizan los mensajes perdidos dependiendo de la distancia (Ilustración 92), se puede ver que la distancia al Main Gateway ya no es un factor tan determinante, y que el porcentaje de pérdidas se mantiene más o menos constante independientemente de la distancia a la que se encuentre el device del Gateway. Además, la media acumulada de los mensajes perdidos no supera el 10%, al contrario de lo que pasaba en el estudio inicial. 86 Ilustración 97: Comparación del número de mensajes recibidos por cada Gateway Por otro lado, si se observa el número de Gateways, de media, al que llegan los mensajes de los devices en esta configuración final (Ilustración 98), se puede apreciar que, respecto a la iteración de mejora, los mensajes no llegan a tantos Gateways, pero, respecto a la configuración inicial, el número medio de Gateways al que llegan los mensajes ha aumentado considerablemente, estando la mayoría de devices en el rango de entre 1,5 y 3,5 Gateways por mensaje. Ilustración 98: Comparación del número de Gateways al que llegan los mensajes Observando el grafico de la distribución del SF de los devices (Ilustración 99), se puede observar que los devices han vuelto a utilizar el SF que estaban utilizando antes de realizar ningún cambio en la red, trabajando la mitad de los devices aproximadamente con SF7, y siendo SF12 el segundo Spreading Factor más utilizado. 87 Ilustración 99: Comparación del último SF utilizado por los devices Habiendo visto el cambio que han sufrido los devices en cuanto al SF que están utilizando, se puede observar un cambio acorde a esto en el ToA de los mensajes, ya que, cuanto menor es el SF, menor es el ToA de este. En la Ilustración 100 se puede observar que el ToA se ha visto reducido a aproximadamente la mitad respecto al estudio anterior. Por otro lado, también se puede observar que el ToA deja de ser tan dependiente de la distancia a la que se encuentra el device del Main Gateway, como pasaba con la configuración inicial. Esto hace que los devices más cercanos tengan un ToA más alto que el que tenían al inicio del estudio, pero cuanto mayor es la distancia entre el device y el Gateway, en este estudio final el ToA se mantiene más o menos constante, al contrario que lo que pasaba al inicio, que iba aumentando. Aun así, teniendo en cuenta esta gran diferencia, la media total del parámetro ToA acaba convergiendo en aproximadamente el mismo valor (740 ms) en el estudio inicial y en este final, dejando la media total de ToA de la iteración de mejora en un valor muy superior (1385 ms). Ilustración 100: Comparación del ToA relativo a la distancia al Main Gateway 88 Analizando los valores de RSSI y SNR en función del SF que están utilizando los devices, se puede observar que los valores han vuelto a los que eran durante el estudio inicial, antes de realizar algún tipo de cambio en los parámetros avanzados de la red. La mayor diferencia entre esta configuración final y la inicial se ve en SF7, donde el RSSI ha aumentado casi 3 dB (Ilustración 101) y el valor de SNR también ha aumentado, en aproximadamente 0.5 dBm (Ilustración 102). Ilustración 101: Comparación de RSSI en función de SF Ilustración 102: Comparación de SNR en función de SF Observando las distribuciones de estos parámetros en vez de analizar la media por cada SF, se puede ver que tanto la distribución de RSSI (Ilustración 103) como la de SNR (Ilustración 104) se encuentran en un punto intermedio entre las distribuciones del estado inicial y las obtenidas en la iteración de mejora, acercándose más a esta última más que a la primera, pero sin llegar a ser tan parecida, sobre todo el SNR. 89 Ilustración 103: Comparación de la distribución de RSSI Ilustración 104: Comparación de la distribución de SNR Finalmente, analizando los gráficos que muestran las tasas de recepción y perdida de paquetes, se puede observar que, el número de mensajes recibidos ha aumentado respecto a la iteración de mejora, que a su vez había aumentado en comparación al estudio inicial. Observando la distribución de mensajes recibidos (Ilustración 105), se puede ver que el mayor cambio ha sido en los devices de los cuales en la iteración de mejora se recibían 29-30 mensajes, ahora se reciben 31-32, aumentando el número total de mensajes recibidos. Además, es de mencionar que, en este análisis final, el número máximo de mensajes es de 32 y no 33 como pasaba en la iteración d mejora. 90 Ilustración 105: Comparación de número de mensajes recibidos Por otro lado, analizando los mensajes perdidos en función de la distancia a la que se encuentran los devices del Main Gateway, se puede observar que el cambio de la iteración de mejora al estudio final no es muy significativo, al contrario que con el estudio inicial, que la mejora es muy notable. En la Ilustración 106 se puede observar que, comparando la iteración de mejora con este último estudio, dependiendo la distancia el porcentaje de perdidas es similar en los casos. Pero, viendo la media total acumulada, se puede observar que en general, la perdida de paquetes es menor con esta configuración final, donde anteriormente la media era de 9,6% de paquetes perdidos y con esta configuración es de 9,39%. Ilustración 106: Comparación de porcentaje de mensajes perdidos en relación a la distancia al Main Gateway En la Ilustración 107 se puede observar únicamente la media acumulada de los 3 estudios, viéndose claramente como en el estudio inicial la distancia era un factor muy determinante, al contrario que en los otros 2 estudios. 91 Ilustración 107: Comparación del porcentaje de la media cumulada de mensajes perdidos en relación a la distancia con el Main Gateway Si se observa también el porcentaje de pérdidas de paquetes en función del SF que están utilizando los devices (Ilustración 108), se puede ver que, con los SF7, SF10 y SF11, el porcentaje de pérdidas de paquetes ha disminuido entre un 2% y un 3% en comparación a la iteración de mejora. Por otro lado, con los SF8 y SF9, las pérdidas se han mantenido constantes, pero, en lo que al SF12 respecta, las perdidas han aumentado un 4%. Ilustración 108: Comparación de porcentaje de perdidas en función del SF 5.5.7. Valoración de los resultados y conclusiones finales Una vez analizados los gráficos con información relevante para el nuevo estado de la red, se pueden obtener varias conclusiones respecto al nuevo estado de esta, además de cómo ha variado con los diferentes cambios aplicados y cuáles han sido las mejoras que ha sufrido. Empezando por el número total de mensajes recibidos por cada Gateway, se puede observar una gran disminución respecto a la iteración de mejora. Esto podría haber supuesto una mayor pérdida de paquetes, pero ha sido justo al revés, el porcentaje de paquetes perdidos ha 92 disminuido, por lo que, se deduce que la mayoría de los mensajes extra que se recibían en los Gateways eran redundantes y no aportaban información nueva. Es de mencionar que, respecto al estado inicial, el número de paquetes totales ha aumentado ligeramente por Gateway. Esto es bastante probable que haya propiciado aumento de mensajes recibidos por cada devices, reduciendo el porcentaje de pérdidas. En relación a esto último, también se ha podido apreciar una mejora en cuanto al número medio de Gateways que llegan los mensajes de los devices respecto a la configuración inicial, únicamente habiendo indicado a los devices que aumentasen su potencia mínima de transmisión. Pero, respecto a la iteración de mejora, el número de Gateways alcanzados por mensaje ha disminuido, ya que en la iteración se forzaba explícitamente a una redundancia espacial (o temporal). Aun así, vistos los resultados del porcentaje de mensajes perdidos, se deduce que no es necesaria esa redundancia forzada para garantizar la correcta recepción de los paquetes. Dado que los parámetros QoS de redundancia forzada se han restablecido a por defecto en esta configuración final, la distribución de los Spreading Factor utilizados por los devices es casi idéntica a la del estudio inicial, dejando la gran mayoría de devices trabajando en SF7. Esto afecta en gran parte al uso de la batería, ya que cuanto menor es el SF, menor es el uso de la radio, por lo que la batería se agota más despacio. El uso de la batería es un parámetro difícil de medir en este proyecto, ya que las baterías tienen una vida útil de 15 años sin tener que cargarlas, y el proyecto dura únicamente algo más de 5 meses en su totalidad. Pero, la disminución de SF no solo afecta a la batería, sino que también al ToA de los mensajes, ya que, al igual que el uso de la radio, cuando menor es el SF, menor es el ToA de los mensajes que se envían. Esto afecta a las colisiones entre los mensajes, siendo más probable que ocurran estas colisiones cuanto mayor sea el ToA. Analizando los valores de RSSI y SNR, se puede ver que estos son prácticamente idénticos a los obtenidos del estudio inicial, excepto los de los devices que trabajan con SF7. Esto se debe al aumento de mínimo de potencia, ya que estos devices han sido obligados a transmitir con una mayor potencia de la necesaria, por lo que han aumentado la calidad de la señal recibida. En comparación con la iteración de mejora, los valores sí que son relativamente peores, pero esto no afecta a la calidad de la señal, ya que tanto los valores del estudio inicial como los del final están dentro de los rangos del propio protocolo, por márgenes bastante amplios, siendo el SNR unos 12 dB mayor del mínimo necesario para la demodulación. Finalmente, analizando los resultados obtenidos en cuanto a la perdida de mensajes, se ha podido ver una continua mejora de este parámetro, dejándolo por debajo del 10% de mensajes perdidos totales. En este estudio final, al haber aumentado la potencia mínima de los devices, se ha podido ver que los devices que usan SF7 han sido los más afectados, siendo notable la mejora en cuanto a RSSI y SNR. Teniendo en cuenta esto, se entiende por qué los devices utilizando un SF7 han tenido el menor porcentaje de perdidas, un 5% aproximadamente. En el resto de Spreading Factors, se ha visto una mejora respecto a la iteración de mejora, excepto en los que utilizan SF12, en los cuales las perdidas han aumentado un 4%. Esto se debe a que en la iteración de mejora un gran número de devices trabajaban con SF12, y estos trasmitían los mensajes con redundancia espacial o temporal, por lo que se entiende que el 93 número de mensajes recibidos fuese mayor. Aun así, respecto al estudio inicial, los porcentajes de pérdidas de paquetes han disminuido en cada uno de los diferentes Spreading Factors. Analizando también el número de mensajes recibidos de cada device, se puede observar que los devices que en los otros estudios se estaban recibiendo 29 o 30 mensajes, de un total de 32, con esta configuración final se están recibiendo 31 o 32. Esto tiene sentido si se mira con la mejora del porcentaje de pérdidas de SF7, ya que los devices que utilizan SF7 suelen ser los más cercanos a los Gateways por lo que suelen tener una menor tasa de perdidas. Por lo que, se puede deducir que aumentando la potencia mínima de transmisión de los devices se ha conseguido que los devices que estaban teniendo pérdidas de 2 o 3 mensajes (en 7 días de duración del análisis), ahora tengan 0 o un único mensaje perdido. En relación a la perdida de paquetes, es de mencionar también que, durante el estudio inicial, estas pérdidas estaban bastante relacionadas con la distancia a la que se encontraban los devices de su Main Gateway, aumentando las dos proporcionalmente. Sin embargo, en la iteración de mejora y en este estudio final, este no es el caso, y la perdida de paquetes se mantiene más o menos constante, indiferente a la distancia a la que se encuentra el device del Main Gateway. En conclusión, en la iteración de mejora se han conseguido disminuir el porcentaje de mensajes perdidos, pero, además de ello, por consecuencia de los parámetros QoS cambiados, también se ha hecho que una cantidad importante de devices trabajen en SF12 en vez de SF7, aumentando el consumo de batería y el ToA de los mensajes. Hay que añadir que, también se ha conseguido mejorar la calidad de la señal recibida, como se puede ver tras analizar los parámetros RSSI y SNR. Pero, con la configuración final aplicada, es decir, con únicamente el aumento de la potencia de transmisión mínima hasta igualarla con la máxima, se ha conseguido reducir el porcentaje de mensajes perdidos, incluso más que en la iteración de mejora. Además, los devices han vuelto a trabajar en SF7, aumentando su vida útil de batería y reduciendo el ToA de los mensajes considerablemente. En contrapartida, los niveles de señal recibidos apenas han variado respecto a los del estudio inicial, únicamente mejorando los de SF7, pero esto no supone ningún problema, ya que desde un principio los niveles entraban dentro de los márgenes para poder demodular la señal por un amplio margen. 94 6. Planificación del proyecto Este trabajo de fin de master se ha dividido en diferentes paquetes de trabajo, los cuales se han dividido en varias tareas. En este apartado se explicará lo realizado en cada una de estas tareas y se añadirá la duración de cada tarea al igual que la fecha en la que inició. En los paquetes de trabajo centrales del trabajo (PT3, PT4 y PT5), las tareas realizadas son prácticamente idénticas, pero la finalidad global de cada paquete de trabajo es diferente. 6.1. Paquetes de trabajo PT1: Metodología de captura de datos y resultados Fecha de inicio: Semana 1. Duración: 1 semana. En este primer paquete de trabajo el objetivo es definir los parámetros importantes para hacer un buen análisis de la red IoT de Itelazpi además de su método de obtención de las bases de datos del Network Server. Por otro lado, también se definirán los gráficos que se generarán para hacer una buena interpretación de los resultados obtenidos. El trabajo de fin de master (TFM) tendrá inicio el 1 de enero, el cual será considerado “semana 1” para el resto de este apartado. T101: Definición de parámetros Fecha de inicio: Semana 1. Duración: 1 semana. En esta primera tarea se definirán los parámetros necesarios para hacer un buen y completo análisis de la red IoT de Itelazpi. Para ello, se listarán todos los parámetros que el Network Server ofrece, tanto para los Gateways como para los dispositivos LoRa, y se hará un cribado para seleccionar los realmente útiles para el futuro análisis de la red. T102: Definición de los métodos de captura de parámetros Fecha de inicio: Semana 1. Duración: 1 semana. Mientras se definen los parámetros necesarios, se analizará cómo se pueden capturar estos de una forma automatizada, analizando los diferentes métodos de extracción de los datos y eligiendo el que mejor se adapte al proyecto. T103: Definición de gráficos a obtener Fecha de inicio: Semana 1. Duración: 1 semana. Teniendo en cuenta los parámetros que se pueden llegar a obtener, se definirán varios gráficos que servirán de ayuda para interpretar los datos previamente obtenidos y así poder analizar los resultados. 95 PT2: Creación de interfaz de usuario Fecha de inicio: Semana 2. Duración: 16 semanas. Este segundo paquete de trabajo consistirá en la creación de una interfaz de usuario para poder replicar el análisis de la red en diferentes zonas de una manera sencilla y guiada. Para ello primero se generarán scripts básicos para la obtención de datos y generación de gráficos, los cuales más tarde se unirán en un único programa con una interfaz de usuario “user friendly”. Este paquete de trabajo está dividido en el tiempo, ya que se utiliza el tiempo necesario para obtención de los datos de los diferentes paquetes de trabajo para llevarlo a cabo. T201: Generación de scripts para la obtención de datos Fecha de inicio: Semana 2. Duración: 2 semanas. En esta primera tarea se generarán los scripts para la obtención de los parámetros previamente definidos. Para ello, se utilizarán los métodos definidos en la tarea T102. Estos scripts se crearán para poder trabajar con ellos de la forma más automatizada posible, al igual que con la mayor flexibilidad a la hora de cambiar parámetros, para su futura reutilización en nuevos análisis. T202: Generación de scripts para la visualización de gráficos Fecha de inicio: Semana 3. Duración: 2 semanas. En esta tarea se generarán los scripts necesarios para visualizar los gráficos previamente definidos. Al igual que los scripts de la tarea T201, estos también se crearán para trabajar con ellos de la manera más automatizada y con la mayor flexibilidad posible. T203: Creación de interfaz de usuario funcional Fecha de inicio: Semana 9. Duración: 3 semanas. Esta tarea comienza después de la T401, mientras se lleva a cabo la obtención de los datos de la iteración de mejora (T402 y T403), ya que este proceso lleva su tiempo y es totalmente pasivo. En esta tarea se creará una interfaz de usuario funcional unificando los scripts previamente generados, tanto de obtención de datos como de generación de gráficos. T204: Creación de interfaz de usuario final Fecha de inicio: Semana 15. Duración: 3 semanas. Al igual que pasaba con la anterior tarea, esta comienza después de la T501, mientras se lleva a cabo la obtención de los datos de la configuración final (T502 y T503). En esta tarea se modificará la interfaz de usuario funcional para crear una más amigable para el usuario, haciendo más fácil su uso por diferentes personas, tanto participantes del proyecto, 102 Ilustración 109: Diagrama de Gantt 103 7. Presupuesto En este apartado se muestra el presupuesto del trabajo de fin de master. En este se calcula la cantidad de dinero necesaria para llevar a cabo el TFM, para poder gestionar los costes y para poder cumplir los objetivos de este. Para ello se definen tres apartados: gasto de personal, amortizaciones y gastos. A continuación, se hace un análisis en profundidad de cada uno de estos apartados, y se concluye con un breve resumen. 7.1. Gasto de personal El equipo está formado por dos ingenieros Senior y un ingeniero Junior, por lo cual, es necesario diferenciarlos a la hora de realizar los cálculos de los sueldos y nóminas (Tabla 12). Código Nombre Coste (€/h) Horas Total (€) I1 Ingeniero Senior 60 100 6.000 I2 Ingeniero Senior 60 100 6.000 I3 Ingeniero Junior 35 600 21.000 Total (€) 33.000 Tabla 12: Sueldos y nóminas 7.2. Amortizaciones Con las amortizaciones se pretende distribuir el gasto de algunos elementos a lo largo de su vida útil. Ya que estos elementos tienen una vida útil más allá del trabajo, no se incluye su valor en totalidad, sino que se incluye un porcentaje (Tabla 13). Hay que tener en cuenta que, aunque la licencia de Orbiwise tengan solo un año de duración, al tener un coste tan elevado se ha decido amortizarla. El coste de la licencia es proporcional al número de Gateways dados de alta en ese Network Server, 400€/Gateway al año. Es por eso que, en la columna “cantidad” el valor es mayor que uno, ya que se han tenido en cuenta el número de Gateways dados de alta. Código Concepto Unidades Coste unitario Vida útil (años) Duración (meses) Total amortizado (€) PC Ordenador portátil 1 1.500 4 5 156,25 CN Contadores 13.000 100 15 5 36.111,11 GW Gateways 16 2.200 6 5 2.444,44 OW Licencia anual Orbiwise 16 400 1 5 2.666,66 Total (€) 41.378,47 Tabla 13: Amortizaciones 104 7.3. Resumen Para finalizar, se combinan todas las anteriores partes para obtener la cantidad total (Tabla 14). Aunque para ello, hay que tener en cuenta que hay que sumar los costes indirectos, los cuales pueden ser la electricidad consumida por los servidores de Orbiwise y Gateways entre otros. Todos esos costes se incluirán como un 10% de los costes directos. Finalmente, hay que añadir otro 10% de imprevistos, ya que cabe la posibilidad de que algún Gateway falle o por cualquier otra razón haya que hacer algún tipo de gasto no planeado. Concepto Total (€) Gasto de personal 33.000 Amortizaciones 41.378,47 Subtotal l 74.378,47 Costes indirectos (10%) 7.437,85 Subtotal ll 81.816,32 Imprevistos (10%) 8.181,63 Total (€) 89.997,95 Tabla 14: Resumen de presupuesto 105 8. Conclusiones Concluyendo el trabajo de fin de master, se puede decir que los objetivos han sido cumplidos, tanto el principal como los secundarios. Se ha logrado optimizar la red IoT LoRa desplegada por Itelazpi mediante ajustes realizados en los parámetros avanzados de la red. Además, se ha desarrollado una aplicación de escritorio para poder realizar nuevos análisis en diferentes zonas de estudio de una forma sencilla. Para ello, se han realizado varios estudios sobre la red, observando así, como afectaban a la calidad de servicio los cambios de ciertos parámetros QoS. Estos análisis se han podido automatizar en la medida de lo posible gracias a la creación de la aplicación de escritorio, la cual no es únicamente útil en el marco de este TFM, sino que puede utilizarse para cualquier otro estudio similar en la red LoRa de Itelazpi. Analizando los resultados obtenidos tras los diferentes análisis realizados, se ha concluido que únicamente forzando a los devices a transmitir a máxima potencia, sea cual sea su SF, se ha conseguido minimizar la perdida de mensajes de estos devices por debajo del 10%, sin alterar en gran medida el resto de variables, como podían ser el SF, ToA, RSSI, SNR, etc. Por otro lado, gracias al trabajo realizado a lo largo de 3 años en las prácticas de cooperación educativa, se ha podido trabajar a fondo con una red LoRa real, pudiendo ver el proceso que supone desplegar una red. Desde el despliegue de los Gateways hasta la transmisión de datos a los diferentes clientes finales, pasando por un tratamiento y almacenaje de datos exhaustivo. En lo personal, el trabajo ha sido todo un reto, ya que ni Itelazpi ni Orbiwise contaban con una manera de poder visualizar el estado de la red de grupos (municipios) específicos, por lo que, haciendo uso de las herramientas disponibles, se ha conseguido desarrollar una manera de realizar esto, lo que lo convierte en algo muy satisfactorio. Además, con las conclusiones obtenidas, a partir de ahora el estado de la red mejorará poco a poco, ya que se ha descubierto una manera de poder reducir la perdida de paquetes sin grandes efectos secundarios. Resumiendo, gracias al desarrollo de la aplicación de escritorio y las conclusiones obtenidas a través de los estudios realizados, el análisis y la optimización de la red LoRa es mucho más sencilla, por lo que, en caso de ser necesario, se tendrán todas las facilidades para poder hacerlo. 106 9. Bibliografía [1] “LoRaWAN architecture”, The Things Network. [En línea]. Disponible en: https://www.thethingsnetwork.org/docs/lorawan/architecture/. [Consultado: 27may-2024]. [2] “Smart metering with LoRaWAN”, TEKTELIC, 30-oct-2023. [En línea]. Disponible en: https://tektelic.com/expertise/lorawan-smart-metering/. [Consultado: 27-may2024]. [3] “Home - OrbiWise - LoRaWAN Network Server, Internet of things technologies”, OrbiWise - LoRaWAN Network Server, Internet of things technologies, 12-abr-2021. [En línea]. Disponible en: https://orbiwise.com/. [Consultado: 27-may-2024]. [4] “LoRa y el duty cycle”, Lpwan.es, 09-mar-2022. [En línea]. Disponible en: https://lpwan.es/lora/lora-y-el-duty-cycle/. [Consultado: 27-may-2024]. [5] “¿Qué Es el Web Scraping? Cómo Extraer Legalmente el Contenido de la Web”, Kinsta®, 28-jul-2022. [En línea]. Disponible en: https://kinsta.com/es/basede-conocimiento/que-es-web-scraping/. [Consultado: 27-may-2024]. [6] “Distance on a sphere: The haversine formula”, Esri Community, 05-oct-2017. [En línea]. Disponible en: https://community.esri.com/t5/coordinate-referencesystems-blog/distance-on-a-sphere-the-haversine-formula/ba-p/902128. [Consultado: 27-may-2024]. [7] “Welcome to GeoPy’s documentation! — GeoPy 2.4.1 documentation”, Readthedocs.io. [En línea]. Disponible en: https://geopy.readthedocs.io/en/stable/. [Consultado: 27-may-2024]. [8] “Folium — folium 0.16.1.dev67+gb80e7e92 documentation”, Github.io. [En línea]. Disponible en: https://python-visualization.github.io/folium/latest/index.html. [Consultado: 27-may-2024]. [9] “Plotly”, Plotly.com. [En línea]. Disponible en: https://plotly.com/python/. [Consultado: 27-may-2024]. [10] “tkinter — Python interface to Tcl/Tk”, Python documentation. [En línea]. Disponible en: https://docs.python.org/es/3/library/tkinter.html. [Consultado: 27may-2024]. [11] “Tkcalendar — tkcalendar 1.5.0 documentation”, Readthedocs.io. [En línea]. Disponible en: https://tkcalendar.readthedocs.io/en/stable/. [Consultado: 27-may2024]. [12] “Figma: The Collaborative Interface Design Tool”, Figma. [En línea]. Disponible en: https://www.figma.com/. [Consultado: 27-may-2024]. 107 [13] “Tkinter-Designer: An easy and fast way to create a Python GUI ”, GitHub. [En línea]. Disponible en: https://github.com/ParthJadhav/Tkinter-Designer. [Consultado: 27-may-2024]. [14] “Git - git con bash”, Git-scm.com. [En línea]. Disponible en: https://gitscm.com/book/es/v2/Ap%C3%A9ndice-A%3A-Git-en-otros-entornos-Git-con-Bash. [Consultado: 27-may-2024]. [15] “Fast and reliable end-to-end testing for modern web apps”, Playwright.dev. [En línea]. Disponible en: https://playwright.dev/python/. [Consultado: 27-may-2024]. [16] “PyInstaller manual — PyInstaller 6.7.0 documentation”, Pyinstaller.org. [En línea]. Disponible en: https://pyinstaller.org/en/stable/. [Consultado: 27-may-2024]. [17] “Inno setup”, Jrsoftware.org. [En línea]. Disponible en: https://jrsoftware.org/isinfo.php. [Consultado: 27-may-2024]. [18] “Device classes”, The Things Network. [En línea]. Disponible en: https://www.thethingsnetwork.org/docs/lorawan/classes/. [Consultado: 27-may2024]. [19] “RSSI and SNR”, The Things Network. [En línea]. Disponible en: https://www.thethingsnetwork.org/docs/lorawan/rssi-and-snr/. [Consultado: 27may-2024]. [20] “LoRa alliance - homepage - LoRa alliance®”, LoRa Alliance®, 03-nov-2023. [En línea]. Disponible en: https://lora-alliance.org/. [Consultado: 27-may-2024]. [21] “Itelazpi – Digitalizaziorako funtsezkoak”, Itelazpi.eus. [En línea]. Disponible en: https://www.itelazpi.eus/es/. [Consultado: 27-may-2024]. [22] IoT Consulting, “LoRa vs LoRaWAN - ¿Cuál es la diferencia?”, Tu fuente experta en IoT, 15-mar-2021. [En línea]. Disponible en: https://iotconsulting.tech/lora-vslorawan/. [Consultado: 27-may-2024].