Exploración de las redes Mesh LoRa y sus servicios con LoRaMesher

id191953 EXPLORACIÓN DE LAS REDES MESH LORA YSUS SERVICIOS CON LORAMESHERMARCEL CALLEJA ÁLVAREZ Director/a FELIX FREITAG(Departamentode Arquitecturade Computadores) Titulación Grado en Ingeniería Informática (Tecnologías de lainformación) Memoria del trabajo de fin de grado Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech Resumen El proyecto titulado Exploración de las redes mesh LoRa y sus servicios con LoRaMesher tiene como objetivo principal analizar y mejorar la funcionalidad de la librería LoRaMesher, que permite implementar redes mesh basadas en tecnología LoRa. Estas redes son relevantes por su bajo consumo de energía y largo alcance, ideales para aplicaciones IoT en entornos complejos. A través de la creación de una herramienta de Traceroute, el proyecto busca utilizar esta herramienta para evaluar las métricas de enrutamiento, ayudando a diagnosticar y monitorizar la gestión del tráfico en estas redes. Además, se abordan aspectos técnicos como el diseño de paquetes, las tablas de enrutamiento y las tareas de gestión. El resultado del trabajo es una herramienta Traceroute de código abierto, que se integra en LoRaMesher y un estudio inicial sobre su funcionamiento. 2 Resum El projecte titulat Exploració de les xarxes mesh LoRa i els seus serveis amb LoRaMesher té com a objectiu principal analitzar i millorar la funcionalitat de la llibreria LoRaMesher, que permet implementar xarxes mesh basades en tecnologia LoRa. Aquestes xarxes són rellevants pel baix consum d’energia i llarg abast, ideals per a aplicacions IoT en entorns complexos. A través de la creació d’una eina de Traceroute, el projecte cerca utilitzar aquesta eina per avaluar les mètriques d’encaminament, ajudant a diagnosticar i monitoritzar la gestió del trànsit en aquestes xarxes. A més, s’aborden aspectes tècnics com el disseny de paquets, les taules d’encaminament i les tasques de gestió. El resultat del treball és una eina Traceroute de codi obert, que s’integra a LoRaMesher i un estudi inicial sobre el seu funcionament. 3 Abstract The main objective of the project titled Exploring LoRa mesh networks and their services with LoRaMesher is to analyze and improve the functionality of the LoRaMesher library, which allows implementing mesh networks based on LoRa technology. These networks are relevant due to their low energy consumption and long range, ideal for IoT applications in complex environments. Through the creation of a Traceroute tool, the project seeks to use this tool to evaluate routing metrics, helping to diagnose and monitor traffic management in these networks. Additionally, technical aspects such as package design, routing tables, and management tasks are covered. The result of the work is an open source Traceroute tool, which is integrated into LoRaMesher and an initial study on its operation. 4 Tabla de Contenidos 1. Introducción 8 1.1. Introducción y Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.1. Contextualización............................ 8 1.2. Justificación................................... 9 1.2.1. Relevancia del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.2. Soluciones ya existentes . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3. Alcance ..................................... 10 1.3.1. Objetivos ................................ 10 1.3.2. Sub-objetivos .............................. 11 1.3.3. Requerimientos ............................. 11 1.4. MetodologíayMedios ............................. 11 1.4.1. Metodología............................... 11 1.4.2. Medios.................................. 11 2. Planificación Temporal 13 2.1. Gestióndelproyecto .............................. 13 2.2. Investigación .................................. 14 2.3. Desarrollo del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Recursos..................................... 16 3. Sostenibilidad y Presupuesto 17 3.1. Sostenibilidad.................................. 17 3.1.1. Planosocial............................... 17 3.1.2. Planoambiental............................. 18 3.1.3. Planoeconómico ............................ 18 3.2. Presupuesto................................... 18 3.2.1. Identificación y estimación de los costes . . . . . . . . . . . . . . . . 18 3.2.2. Controldegestión ........................... 20 4. Stack Tecnológico 21 4.1. Entornodepruebas............................... 21 4.2. PlacasT-BEAM ................................ 21 4.3. LoRaChatframework.............................. 22 4.4. LibreríaLoRaMesher.............................. 22 4.5. EMQXBroker.................................. 23 5. Creación de una app con LoRaChat 24 5.1. Estructura básica para crear una aplicación . . . . . . . . . . . . . . . . . 24 5.2. Configuración e integración . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Comunicación de LoRaChat con el exterior . . . . . . . . . . . . . . . . . . 25 5.3.1. Flujo de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3.2. Beneficios del enfoque . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Comunicación entre LoRaChat y LoRaMesher . . . . . . . . . . . . . . . . 28 5.4.1. Principales funciones de LoRaMeshService . . . . . . . . . . . . . . 28 5.4.2. Integración con LoRaChat . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.3. Ventajas................................. 29 5 6. Análisis de LoRaMesher 30 6.1. Tecnologias de comunicación en LoRa . . . . . . . . . . . . . . . . . . . . . 30 6.1.1. LoRaWAN................................ 30 6.1.2. LoRaMesh ............................... 31 6.2. Estructura de los paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.2.1. Tiposdepaquetes............................ 33 6.2.2. Segmentación de datos grandes . . . . . . . . . . . . . . . . . . . . 34 6.3. Colasdepaquetes................................ 35 6.3.1. Estructura general de las colas . . . . . . . . . . . . . . . . . . . . . 36 6.3.2. Tiposdecolas.............................. 36 6.4. TareasdeLoRaMesher............................. 37 6.4.1. Relación entre las tareas y las colas . . . . . . . . . . . . . . . . . . 39 7. Introducción de la herramienta Traceroute 40 7.1. DiseñodelTraceroute.............................. 41 8. Desarrollo del Traceroute 43 8.1. Aplicación de LoRaChat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1.1. Estructura de los mensajes . . . . . . . . . . . . . . . . . . . . . . . 44 8.1.2. Comandos de la aplicación . . . . . . . . . . . . . . . . . . . . . . . 45 8.2. Implementación en LoRaMesher . . . . . . . . . . . . . . . . . . . . . . . . 46 8.2.1. Paquetes Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.2.2. Llamada de Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.2.3. Procesado de paquetes Traceroute . . . . . . . . . . . . . . . . . . . 50 9. Evaluación de redes con Traceroute 53 9.1. Herramientas necesarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.2. Evaluación con la métrica First-Hop . . . . . . . . . . . . . . . . . . . . . . 55 9.2.1. Experimento con dos nodos . . . . . . . . . . . . . . . . . . . . . . 57 9.2.2. Experimento con tres nodos . . . . . . . . . . . . . . . . . . . . . . 58 9.2.3. Experimento de tres nodos . . . . . . . . . . . . . . . . . . . . . . . 59 9.3. Conclusiones de la evaluación . . . . . . . . . . . . . . . . . . . . . . . . . 62 9.3.1. Reflexión y perspectivas futuras . . . . . . . . . . . . . . . . . . . . 63 10.Conclusiones y Reflexiones 64 10.1.Logrosconseguidos ............................... 64 10.2. Dificultades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 10.2.1. Dificultades en el desarrollo de Traceroute . . . . . . . . . . . . . . 65 10.2.2. Dificultades en la evaluación . . . . . . . . . . . . . . . . . . . . . . 66 10.3.Direccionesfuturas ............................... 66 10.4.Reflexionesfinales................................ 67 11.Informe de sostenibilidad 68 11.1.Planoambiental................................. 68 11.2.Planoeconómico ................................ 68 11.3.Planosocial................................... 68 12.Términos y Conceptos 70 6 Lista de Figuras 1. DiagramadeGantt............................... 15 2. PlacasLoRaT-BEAM ............................. 22 3. Arquitectura del broker EMQX. Fuente . . . . . . . . . . . . . . . . . . . . 23 4. Mensaje de respuesta de la aplicación de temperatura . . . . . . . . . . . . 26 5. Mensaje para encender un led en el nodo 1234 . . . . . . . . . . . . . . . . 27 6. Arquitectura LoRaWAN. Fuente . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Ejemplo de red LoRa mesh. Fuente . . . . . . . . . . . . . . . . . . . . . . 31 8. Estructura del paquete LoRa y LoRaMesher. Fuente . . . . . . . . . . . . . 32 9. Estructura del paquete de datos grande. Fuente . . . . . . . . . . . . . . . 34 10. Diagrama de la tarea de envío. Fuente . . . . . . . . . . . . . . . . . . . . 38 11. Ejemplo de Traceroute en redes convencionales donde se indica la dirección de un nodo destino y se obtiene los nodos por los que pasa hasta llegar al destino. ..................................... 40 12. Método para iniciar el Traceroute desde la aplicación de LoRaChat . . . . 43 13. Estructura del mensaje JSON de envío . . . . . . . . . . . . . . . . . . . . 44 14. Estructura del mensaje JSON de respuesta . . . . . . . . . . . . . . . . . . 45 15. Método que contiene los comandos que se pueden realizar en la aplicación deTraceroute .................................. 45 16. Tipos de paquetes en LoRaMesher . . . . . . . . . . . . . . . . . . . . . . 46 17. Paquete de control en LoRaMesher . . . . . . . . . . . . . . . . . . . . . . 46 18. PaquetedeTraceroute ............................. 47 19. Método para crear un paquete de Traceroute . . . . . . . . . . . . . . . . . 47 20. Creación y envío del primer paquete . . . . . . . . . . . . . . . . . . . . . . 48 21. Gestión de paquetes de Traceroute por el nodo origen . . . . . . . . . . . . 49 22. Caso donde el paquete ha regresado al nodo origen . . . . . . . . . . . . . 51 23. Caso donde el paquete ha llegado a un nuevo nodo . . . . . . . . . . . . . 51 24. Caso donde el paquete ha llegado a un nuevo nodo . . . . . . . . . . . . . 52 25. Método para crear topologías por código . . . . . . . . . . . . . . . . . . . 54 26. Método para publicar el mensaje de Traceroute . . . . . . . . . . . . . . . 55 27. Método que recibe el resultado del Traceroute . . . . . . . . . . . . . . . . 55 28. Diagrama del experimento de dos nodos . . . . . . . . . . . . . . . . . . . 57 29. Método para crear la topología del segundo experimento . . . . . . . . . . 58 30. Diagrama del experimento de dos nodos . . . . . . . . . . . . . . . . . . . 59 31. Ejecución fallida de Traceroute . . . . . . . . . . . . . . . . . . . . . . . . 59 32. Logs del nodo A, correspondientes a los dos primeros paquetes . . . . . . . 60 33. Logs de los nodos 0x79C8 y 0x7B8C, paquete inesperado . . . . . . . . . . 61 34. Error por una excepción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Lista de Tablas 1. Salariosmedios ................................. 19 2. CostesdelProyecto............................... 19 3. Descripción de flags de paquetes . . . . . . . . . . . . . . . . . . . . . . . . 33 4. Ventajas y desventajas de cada estrategia. . . . . . . . . . . . . . . . . . . 42 7 1. Introducción 1.1. Introducción y Contexto En el ámbito de las telecomunicaciones, las redes de largo alcance y bajo consumo energético han adquirido una importancia cada vez mayor, especialmente en aplicaciones relacionadas con el Internet of Things (IoT). Dentro de este marco, LoRa (Long Range) es una tecnología de modulación inalámbrica que ha ganado popularidad por su capacidad para transmitir datos a largas distancias con un consumo de energía relativamente bajo, lo que la convierte en una opción ideal para dispositivos IoT que requieren conectividad en áreas remotas o con limitaciones energéticas. LoRa se caracteriza por su capacidad para cubrir grandes áreas geográficas con bajos costos de implementación y mantenimiento. Esto ha impulsado su adopción en múltiples sectores, como la agricultura, las ciudades inteligentes y la monitorización ambiental, donde los dispositivos deben comunicarse a largas distancias con una infraestructura mínima. Sin embargo, LoRa, en su implementación más tradicional llamada LoRaWAN (Low Power Wide Area Network), está limitado por una arquitectura basada en redes de tipo árbol, donde los dispositivos finales se comunican directamente con una estación base o gateway. Este enfoque puede generar ineficiencias cuando se trata de redes más grandes o distribuidas en áreas complejas geográficamente, ya que la comunicación depende enteramente de la disponibilidad del gateway. Para superar estas limitaciones, han surgido soluciones como LoRa Mesh, que permite la creación de redes malladas o distribuidas, donde los dispositivos pueden actuar tanto como nodos finales como intermedios, extendiendo el rango de comunicación y proporcionando redundancia. Este trabajo tiene como objetivo analizar en profundidad la solución de redes mesh LoRa implementada en la librería LoRaMesher, identificando sus características, limitaciones y posibles mejoras a través de la creación de nuevas herramientas de evaluación y simulación. Además, se explorarán y compararán diferentes métricas de enrutamiento para evaluar el rendimiento de las redes mesh LoRa. 1.1.1. Contextualización Este es el proyecto final del Grado de Ingeniería Informática de la Facultad de Informática perteneciente a la Universidad Politécnica de Cataluña. Este proyecto especializado en Tecnologías de la Información busca abordar un conjunto de competencias técnicas relacionadas con la especialidad. Entre las cuales se encuentran 8 conceptos de tecnologías de redes de computadores, evaluación de rendimiento de distintas tecnologías de comunicación y conceptos de sistemas operativos. Este proyecto se realiza fuera de los marcos de una empresa, sin embargo se realiza en el contexto de un equipo de investigación de la UPC enfocado en la implementación de una librería que implemente una red Mesh en LoRa, cuyos integrantes son el director de este proyecto, Felix Freitag, y Joan Miquel Solé, el desarrollador de LoRaMesher. 1.2. Justificación 1.2.1. Relevancia del proyecto Este proyecto tiene una relevancia significativa al abordar la mejora y evaluación de protocolos de enrutamiento en redes mesh LoRa. Las redes de baja potencia y largo alcance, como LoRa, son fundamentales en el desarrollo de soluciones IoT en áreas rurales o de difícil acceso. La optimización de LoRaMesher a través de nuevas herramientas, como la incorporación de Traceroute, permitirá realizar un análisis más detallado del rendimiento y mejorar la gestión del enrutamiento en estas redes. Estas mejoras no solo contribuirán al aumento de la eficiencia y la capacidad de la red, sino también a la aceleración del desarrollo de nuevas aplicaciones basadas en esta tecnología. 1.2.2. Soluciones ya existentes En la actualidad, no existe una comparación exhaustiva entre los protocolos de enrutamiento en redes mesh adaptadas a la tecnología LoRa. Si bien existen soluciones mesh como Zigbee, Z-Wave, Thread, Bluetooth Mesh y Wi-Fi Mesh, todas ellas están diseñadas para aplicaciones específicas con diferentes enfoques tecnológicos y limitaciones, en particular en cuanto a consumo energético, cobertura y capacidad de transmisión de datos. Por ejemplo, Zigbee y Z-Wave, aunque muy eficaces en redes de automatización del hogar, presentan limitaciones en términos de alcance en comparación con LoRa. Asimismo, tecnologías como Thread y Bluetooth Mesh, a pesar de ser eficientes energéticamente, no están optimizadas para escenarios de largo alcance y baja potencia como los que cubre LoRa. LoRaMesher, por su parte, se especializa en redes de largo alcance con un enfoque en IoT rural o industrial, donde otras tecnologías mesh no resultan viables debido a sus características. Además, no se ha encontrado hasta la fecha una solución de evaluación del rendimiento basada en una herramienta de Traceroute en redes mesh LoRa, lo que refuerza la necesidad de este proyecto. La inclusión de esta funcionalidad en LoRaMesher permitirá realizar análisis más profundos sobre la latencia y la eficiencia del enrutamiento, aspectos críticos en aplicaciones IoT que requieren un control riguroso del tráfico de datos en grandes áreas geográficas. 9 2.4. Recursos Los recursos humanos que dispone este proyecto son muy limitados y por esa razón la mayoría de roles del proyecto serán tomados por la misma persona, su autor, entre los cuales se encuentra el de jefe de proyecto, investigador y evaluador del proyecto. También se tiene en cuenta el rol de director de proyecto que lo realizará Felix Freitag. En cuanto a los recursos materiales que se usarán en el proyecto, se encuentran las herramientas para la organización y gestión: Google Meet, Google calendar, Google Drive y libretas para tomar apuntes. Admás también se incluyen las herramientas usadas para el desarrollo entre las cuales se encuentran las de programación: platformio y editor de texto, y finalmente las placas TTGO para ejecutar LoraMesher. 16 3. Sostenibilidad y Presupuesto 3.1. Sostenibilidad En relación a la encuesta del proyecto EDINSOST2-ODS se ha llegado a ciertas conclusiones sobre los conocimientos en relación con la sostenibilidad en los planos económico, ambiental y social, que afectan en el campo de la informática. Como resumen, hay que tener en cuenta ciertas consideraciones y conclusiones que nos ha dejado la encuesta. Primeramente cabe destacar que en el plano social, ya sea desde la educación de la universidad como en la educación más cultural, considero que existe cierta concienciación sobre los valores éticos y que sí se ha hecho hincapié en la importancia de los productos informáticos éticos y accesibles. A su vez en el plano ambiental, a pesar de que considero estar concienciado de la importancia del impacto ambiental, también considera que le faltan herramientas para saber cuantificarlo y evaluarlo en un proyecto real. Por otra parte, considero que cuenta con la preparación adecuada para poder medir el plano económico, tanto una estimación de los costes del proyecto como un presupuesto del mismo. En general considero, en el momento de hacer la encuesta, que se tienen conocimientos suficientes en relación a las problemáticas de sostenibilidad, pero falta el conocimiento de herramientas e indicadores, al menos en más detalle, para poder hacer un estudio en detalle sobre ciertos aspectos de la sostenibilidad como el ambiental. 3.1.1. Plano social A nivel personal creo que puedo obtener primero de todo conocimientos sobre una nueva tecnología que no he trabajado nunca como es LoRa mesh, y más en detalle sobre cómo funcionan los protocolos de enrutamiento en su forma más básica, en su implementación. Además creo que puedo obtener mucha experiencia tanto en participar en proyectos donde el nivel de abstracción es muy bajo, como en la evaluación de algoritmos o métricas. En cuanto a las soluciones que creo que aportará este proyecto, son primeramente aportar en un proyecto que es innovador, ya que no existen productos de software libre que proporcionen las mismas soluciones, y además creo que las aportaciones serán esenciales para la evaluación del rendimiento del producto. En general creo que el hecho de aportar a un proyecto de software libre una solución que ayude a mejorar su rendimiento, es el valor real que tiene este proyecto. 17 3.1.2. Plano ambiental En cuanto al impacto ambiental de este proyecto, este se centra principalmente en la parte de la evaluación de las métricas de enrutamiento, donde se necesitará hacer simulaciones del software para poder comparar los algoritmos. Por lo tanto el impacto ambiental que tendrá este proyecto será básicamente el gasto de energía eléctrica que tendrán los nodos de Lora o placas TTGO. En ese aspecto se tendrá en cuenta el gasto de energía que requieren las simulaciones y debido a ello se intentará reducir su número, asegurándose primeramente tener un producto de software pulido. Además también se tiene en cuenta el uso de productos informáticos como las placas Lora, y por ello hemos optado por utilizar placas ya compradas en años anteriores y usadas en proyectos anteriores. 3.1.3. Plano económico En términos económicos, el proyecto tiene un enfoque orientado a la optimización de recursos ya disponibles, lo que implica un bajo costo de implementación. Los gastos principales estarán asociados a el hardware necesario y la energía. Sin embargo, para mitigar costos, se recurrirá a la reutilización de componentes, como las placas Lora/TTGO, adquiridas en años anteriores para otros proyectos. Los costos de energía eléctrica generados por las simulaciones también son una parte relevante en el presupuesto. No obstante, se ha planeado minimizar el número de simulaciones mediante una fase de pruebas preliminares que permitan afinar el software y asegurarse de su funcionalidad antes de realizar simulaciones a gran escala. Finalmente el último aspecto económico a considerar es el tiempo de trabajo invertido por los miembros del equipo de desarrollo. Aunque no se prevé la contratación de personal externo, se valorará el tiempo dedicado a cada una de las fases del proyecto para una gestión eficiente. 3.2. Presupuesto 3.2.1. Identificación y estimación de los costes En esta sección se identificarán todos los elementos dentro de la estimación de un presupuesto. Entre estos elementos podremos ver distintos grupos entre los que se encuentran: costes de personal por actividad (CPA), costes generales (CG), las contingencias, y los imprevistos. Con el objetivo de poder calcular los costes de personal por actividad, debemos antes ver los precios de los salarios por hora de cada uno de los tipos de personal. Para ello 18 nos centraremos en los salarios medios de cada uno de los roles en la región de Barcelona según el sitio web Glassdoor. Rol Coste (€/h) Jefe de Proyecto 17,7 Desarrollador C junior 12,5 Cuadro 1: Salarios medios Además como ya se ha mencionado tenemos que añadir el coste de las contingencias para cubrir variaciones en las estimaciones y situaciones no imprevistas. Al ser un coste genérico se calcula como un porcentaje del coste total del proyecto. Pondremos un 15 % como valor típico de contingencia en un proyecto informático. Actividad Coste(€) Observaciones GP1 (Gestión de proyecto) 354 Jefe de proyecto 20 horas GP2 (Contextualización y alcance) 177 Jefe de proyecto 10 horas GP3 (Planificación temporal) 177 Jefe de proyecto 10 horas GP4 (Entrega final) 177 Jefe de proyecto 10 horas GP5 (Reuniones con el director) 354 Jefe de proyecto 20 horas GP6 (Redacción de la memoria) 1062 Jefe de proyecto 60 horas GP7 (Preparación de la defensa) 354 Jefe de proyecto 20 horas I1 (Investigación entrono de trabajo) 500 Desarrollador en C 40 horas I2 (Investigación evaluación) 625 Desarrollador en C 50 horas DP1 (Instalación SW y HW) 187.5 Desarrollador en C 15 horas DP2 (Desarrollo de la herramienta) 1000 Desarrollador en C 80 horas DP3 (Desarrollo de la evaluación) 1125 Desarrollador en C 90 horas Total CPA 6092.5 Placas TTGO x4 174 43.50€x 4 placas Portátil 600 Portatil personal Software para programar - Gratuito Herramientas de software de proyecto - Gratuitas Internet 150 + Estimación basada en una conexión de 300 Mbps Electricidad 49 + Estimación superficial Total CG 974 Contingencias 1059.9 Márgen de contingencia del 15 % TOTAL 8126.5 Cuadro 2: Costes del Proyecto 19 3.2.2. Control de gestión A lo largo del proyecto, se implementarán mecanismos de monitoreo y evaluación periódica que permitirán identificar cualquier desviación de las expectativas iniciales y tomar acciones correctivas de manera oportuna. El seguimiento se realizará semanalmente a través de reuniones de control, donde se evaluarán los avances del proyecto y se analizarán los indicadores clave. Cada fase del proyecto será revisada al concluir, para verificar el uso de los recursos y el cumplimiento de los plazos. Indicadores de Control: 1. Desviación de horas del proyecto: Este indicador mide la diferencia entre las fechas programadas para cada fase o tarea y las fechas reales de finalización. Permite detectar retrasos y tomar medidas correctivas. Desviación de tiempo = Fecha estimada de finalización - Fecha real de finalización 2. Desviación de costos del proyecto: Este indicador mide la comparación entre el presupuesto estimado para el proyecto y los costos reales incurridos hasta el momento. Ayuda a identificar sobrecostes o ahorros inesperados. Desviación de horas de trabajo = Horas estimadas - Horas reales trabajadas 3. Desviación en el uso de personal: Evalúa el uso real de horas de trabajo en comparación con las horas estimadas para cada tarea. Permite controlar la eficiencia del personal y ajustar los recursos si es necesario. Desviación de horas de trabajo = Horas estimadas - Horas reales trabajadas 4. Control de productividad: Relación entre el avance en la ejecución de tareas y el uso de recursos (costos y tiempo). Este indicador evalúa la eficiencia del equipo y del proceso de trabajo. Productividad = (Tareas completadas / Tareas planificadas) ∗100 20 4. Stack Tecnológico La siguiente sección se centrará en describir las tecnologías tanto software como hardware, de las cuales hará uso el proyecto. Sin embargo en vez de centrarnos en las herramientas que se utilizarán para llevar a cabo el desarrollo, de las cuales ya hemos hablado, nos centraremos en las herramientas que forman parte del proyecto y le dan forma, el stack tecnológico. Además en esta sección se justificará el uso de cada una de ellas dentro del propio stack. 4.1. Entorno de pruebas Antes de entrar a describir cada una de las tecnologías específicamente, cabe primeramente explicar el entorno donde se llevarán a cabo las simulaciones y pruebas, y donde participarán cada una de las tecnologías que describiremos en los siguientes puntos. Como elementos hardware tendremos las placas T-BEAM en este caso tres, ya que son las que tenemos disponibles, y serán los nodos que formarán nuestra red mesh. A su vez, cada una de estas placas deberá tener cargado el código de LoRaMesher (a través de la framework LoRaChat o por si solo) para poder formar parte de una red como nodo. Además, en el caso de ser el nodo gateway de la red, una de estas placas estará conectada a internet a través del broker EMQX, de esta forma, si queremos probar el Traceroute fuera de las placas, se hará a través del broker MQTT. 4.2. Placas T-BEAM Como ya hemos mencionado anteriormente en la sección 5, las placas que usaremos en el proyecto serán las Lilygo T-BEAM v1.1. Estas placas contienen varios módulos importantes en una misma unidad. Los principales componentes incluyen: Módulo LoRa de 868 MHz: Este módulo permite la comunicación inalámbrica de largo alcance entre nodos, una característica esencial para nuestra red mesh. ESP32 con WiFi y Bluetooth: El procesador ESP32 permite tanto la programación de las funcionalidades de red como la interacción mediante Bluetooth o WiFi, ofreciendo flexibilidad para pruebas y configuraciones adicionales. Pantalla OLED: La pantalla integrada facilita la visualización en tiempo real de información crítica, como el estado de las tablas de enrutamiento, los mensajes transmitidos y el estado del nodo. Estas placas han sido seleccionadas debido a su capacidad para integrar los módulos mencionados en un diseño compacto, lo que las hace ideales para proyectos de IoT y redes de malla. Además, su bajo costo y facilidad de programación aumentan su conveniencia para este tipo de aplicaciones. 21 Figura 2: Placas LoRa T-BEAM 4.3. LoRaChat framework LoRaChat es un framework utilizado para crear aplicaciones que usen LoRaMesher desde la capa de aplicación, sin tener conocimiento de las capas inferiores. Este framework hace uso de de la librería LoRaMesher para obtener información de los nodos de la red LoRa. En el contexto de nuestro proyecto este framework nos permitirá crear una aplicación de Traceroute, que nos sirva de abstracción de la funcionalidad de Traceroute y de esta manera nos permita hacer pruebas. En el contexto de nuestro proyecto, LoRaChat permitirá: Crear una aplicación de Traceroute: Esta aplicación abstraerá la funcionalidad de Traceroute, permitiendo ejecutar pruebas de conectividad entre nodos sin necesidad de interaccionar directamente con el código base de LoRaMesher. Simplificar las pruebas: Gracias a LoRaChat, el tiempo de desarrollo y depuración se reducirá, ya que nos proporciona herramientas listas para usar que interactúan con la red. En la siguiente sección, se analizará con mayor profundidad cómo LoRaChat facilita la creación de aplicaciones y sus beneficios específicos para este proyecto. 4.4. Librería LoRaMesher La librería LoRaMesher facilita la creación de redes mesh con dispositivos LoRa, gestionando automáticamente el enrutamiento entre nodos sin necesidad de infraestructura adicional. En este proyecto, LoRaMesher permitirá que los nodos T-BEAM se comuniquen eficazmente, formando una red de malla cuyos links estarán determinados por ciertas métricas, que más adelante evaluaremos su correcto funcionamiento mediante el desarrollo 22 de nuestra herramienta de Traceroute dentro de la librería. En las próximas secciones haremos una análisis más profundo sobre la librería de LoRaMesher y de cómo añadiremos la herramienta de Traceroute. En este proyecto, LoRaMesher desempeñará las siguientes funciones clave: Gestión del enrutamiento: Automatizará la comunicación entre nodos, asegurando que los datos lleguen a su destino mediante la mejor ruta disponible. Formación de la red de malla: Los nodos T-BEAM se comunicarán entre sí utilizando enlaces determinados por métricas configurables, como fuerza de la señal o latencia. Implementación de Traceroute: Se desarrollará una herramienta dentro de la librería para evaluar el correcto funcionamiento de la red, permitiendo visualizar la trayectoria de los paquetes y detectar posibles problemas. En las próximas secciones, exploraremos cómo se integrará Traceroute dentro de LoRaMesher y las mejoras que se realizarán en la librería para adaptarla a los objetivos del proyecto. 4.5. EMQX Broker EMQX es un broker MQTT altamente escalable y confiable diseñado para facilitar la transmisión de mensajes entre dispositivos en tiempo real. Es compatible con el protocolo MQTT en su totalidad, lo que lo hace ideal para aplicaciones de IoT. Dentro del contexto de este proyecto, el broker EMQX actúa como el nodo central que conecta la red con el mundo exterior, permitiendo que los mensajes generados en la red de nodos T-BEAM puedan ser enviados y recibidos desde Internet. En la Figura 3, podemos observar cómo EMQX gestiona la comunicación entre publishers (los nodos que envían datos) y subscribers (los nodos o aplicaciones que reciben datos), creando un entorno eficiente para la transmisión de información. Figura 3: Arquitectura del broker EMQX. Fuente 23 5. Creación de una app con LoRaChat Como ya hemos comentado LoRaChat es una framework que hace uso de LoRaMesher para poder crear aplicaciones que hagan uso de una red mesh LoRa de forma más fácil, abstrayendo las capas inferiores para centrarse únicamente en la capa de aplicación. 5.1. Estructura básica para crear una aplicación Para poder crear una aplicación en LoRaChat se necesita seguir una "plantilla"que marca el framework. Esta plantilla consiste en 4 archivos cada uno con un propósito: app.cpp y app.h Estos archivos contendrán por un lado la lógica de la aplicación, y por otro los métodos genéricos que llamará LoRaChat cuyos objetivos son: encender y apagar la aplicación, obtener el mensaje personalizado que generará la app (del que se hablará más adelante) y procesar un mensaje recibido. appCommandService.cpp y appCommandService.h Estos archivos serán los encargados de añadir las rutas que podremos utilizar para ejecutar nuestra aplicación, a través de un MQTT subscriber. appMessage.h Este archivo contendrá los métodos para serializar y deserializar el mensaje personalizado de nuestra app, y poder así enviarlo y recibirlo a través de MQTT. 5.2. Configuración e integración Una vez creados los archivos mencionados, los siguientes pasos son necesarios para integrar la aplicación con el sistema LoRaChat: 1. Activación en config.h:La aplicación debe ser habilitada explícitamente en el archivo config.h del proyecto. Esto asegura que el framework considere la aplicación durante el proceso de compilación y ejecución. Como en ejemplo de a continuación donde se define la activación de la aplicación de LED. 1#define LED_ENABLED 2. Instanciación en main.cpp:En el archivo principal del proyecto, es necesario instanciar la clase correspondiente a la aplicación, llamar al método genérico que la inicia y asegurarse de que se registre en los servicios de LoRaChat. A continuación se muestra un ejemplo con la aplicación de WIFI. 24 1#pragma region WiFi 2WiFiServerService&wiFiService =WiFiServerService::getInstance(); 3 4void initWiFi() { 5wiFiService.initWiFi(); 6} 7#pragma endregion 8-------------------------------------------------------------------------- 9manager.addMessageService(&wiFiService); 10 ESP_LOGV(TAG,"WiFi service added to manager"); 3. Definición de puertos en dataMessage.h:Cada aplicación en LoRaChat opera a través de un puerto específico, definido en este archivo. Esto permite identificar de manera única las aplicaciones dentro del sistema y asignarles la ruta adecuada para la comunicación de mensajes. La estructura modular y basada en plantillas de LoRaChat presenta varias ventajas a la hora de desarrollar una aplicación que haga uso de redes mesh LoRa: Abstracción: Los desarrolladores pueden centrarse únicamente en la lógica de su aplicación, sin preocuparse por los detalles complejos de la red mesh. Escalabilidad: La separación por módulos permite agregar nuevas aplicaciones o modificar las existentes sin afectar otras partes del sistema. 5.3. Comunicación de LoRaChat con el exterior La comunicación entre LoRaChat, que se ejecuta en las placas haciendo uso de LoRaMesher, y sistemas externos se realiza a través de MQTT, que actúa como un puente para conectar el mundo de los dispositivos LoRa, con servicios más convencionales en la nube o aplicaciones externas. Este mecanismo aprovecha las características robustas y eficientes de MQTT para garantizar un flujo de datos confiable entre los nodos LoRa y el exterior. A continuación se describirá el flujo de comunicación entre los nodos gateway y los servicios exteriores que demandan información sobre la red. 5.3.1. Flujo de comunicación 1. Generación y recepción de mensajes en la red LoRa LoRaChat, usando LoRaMesher, intercambia mensajes entre nodos de una red mesh. Cada nodo puede enviar y recibir datos dentro de la red, donde LoRaMesher se encarga del enrutamiento y la entrega de mensajes en un esquema mesh. 25 Las principales ventajas de este protocolo son la confiabilidad de la red, ya que los nodos pueden tener distintas formas de llegar a su destino, y por lo tanto existe más redundancia al no estar tan centralizado. Otra gran ventaja es que podemos ahorrar gateways ya que cualquier nodo puede actuar como gateway. Por otro lado al contrario que una red WAN, este tipo de redes no cubren una gran área ya que los nodos tienen que estar interconectados, para poder tener disponibilidad al nodo gateway de la red, otra desventaja podría ser que los nodos LoRa tienen más complejidad ya que cada nodo tiene que tener la información de enrutamiento, para poder redirigir los paquetes que recibe, aunque la parte buena es que se evitan servidores centralizados de enrutamiento. Tras analizar las principales tecnologías de comunicación en LoRa, es evidente que las redes mesh destacan por su capacidad de crear estructuras descentralizadas y resilientes. Estas características son esenciales en aplicaciones donde la dependencia de gateways o servidores centralizados resulta inviable, como en áreas remotas o entornos dinámicos. En este contexto, LoRaMesher surge como una herramienta clave para implementar redes mesh de forma eficiente y como hemos mencionado, para abstraer la complejidad del enrutamiento y retransmisión de paquetes, permitiendo a los desarrolladores centrarse en las aplicaciones de alto nivel sin preocuparse por los detalles del protocolo. A continuación profundizaremos en el funcionamiento interno de LoRaMesher, desglosando cómo gestiona las tablas de enrutamiento, los distintos formatos de paquetes, los algoritmos de enrutamiento, etc. 6.2. Estructura de los paquetes Con el objetivo de estructurar el protocolo sobre la capa de LoRa, el paquete principal de LoRaMesher está encapsulado en el payload del paquete de LoRa. En ese paquete es donde LoRaMesher incluye un header, en el que se describe un destino y un origen (2 Bytes cada campo), tamaño del payload y el tipo de paquete de LoRaMesher en el que a continuación profundizaremos (1 Byte cada campo), y por otro lado el payload donde cada tipo de paquete añadirá su información necesaria. Figura 8: Estructura del paquete LoRa y LoRaMesher. Fuente 32 6.2.1. Tipos de paquetes Con el objetivo de diferenciar los tipos de paquetes dentro de LoRaMesher, el protocolo hace uso de 1 byte en el header del paquete, que usa como máscara para definir las cualidades de los paquetes, este campo puede tomar los siguientes valores: Flag del paquete Uso de la flag HELLO_P Identifica un paquete de enrutamiento. DATA_P Identifica un paquete de datos estándar. XL_DATA_P Identifica a un paquete que envía un fragmento de datos grandes. ACK_P Identifica a un paquete de confirmación de un fragmento de datos grandes. LOST_P Identifica a un paquete de no confirmación conforme el destino no ha recibido el paquete. NEED_ACK_P Identifica a un paquete que enviará un paquete de ACK cuando sea recibido. SYNC_P Identifica a un paquete que notifica el comienzo de transmisión de datos grandes. Cuadro 3: Descripción de flags de paquetes LoRaMesher gestiona a través de el uso de estas flags, a grandes rasgos tres tipos de paquetes, los paquetes de enrutamiento,los paquetes de datos ylos paquetes de control. Esto es debido a que el protocolo que implementa es proactivo, eso significa que cada nodo trata de mantener información sobre el enrutamiento de toda la red. Paquetes de enrutamiento. Los paquetes de enrutamiento en LoRaMesher desempeñan un papel fundamental en la construcción y mantenimiento de las tablas de enrutamiento dentro de la red. Estos paquetes son enviados periódicamente por todos los nodos de la red, con el propósito de actualizar la información sobre las rutas disponibles en cada nodo. Para ello, los paquetes de enrutamiento utilizan una dirección de destino especial, la dirección de broadcast 0xFF, que garantiza que todos los nodos vecinos reciban estos mensajes y puedan procesarlos adecuadamente. Cada paquete de enrutamiento contiene una o varias entradas de la tabla de enrutamiento del nodo emisor. Al recibir un paquete de este tipo, el receptor realiza los siguientes pasos: 1. Identificación del tipo de paquete: El nodo determina que se trata de un paquete de enrutamiento gracias al valor en el campo de tipo del encabezado. 2. Verificación del nodo emisor: El nodo receptor comprueba si la dirección del emisor ya está registrada en su tabla de enrutamiento. Si la entrada existe, se actualizan los valores con la información más reciente. Si no, el nodo emisor es añadido a la tabla de enrutamiento del receptor. 33 3. Procesamiento de las entradas recibidas: El nodo receprot revisa todas las entradas contenidas en la tabla de enrutamiento del emisor, añadiendo nuevas entradas o actualizando las existentes en su propia tabla. Este proceso permite que la información de enrutamiento se propague eficientemente a través de la red, alcanzando incluso nodos que no están directamente conectados. Además, los paquetes de enrutamiento incluyen un campo de rol que permite identificar características especiales de los nodos, como la capacidad de actuar como gateway. Esta funcionalidad facilita la selección de rutas específicas hacia nodos con funciones especializadas, optimizando el uso de los recursos de red. Paquetes de datos. Por otro lado los paquetes de datos contienen la información de la capa de aplicación por encima de LoRaMesher. Estos paquetes pueden dividirse en dos categorias: Datos estándard: Este tipo de paquete sirve para trasmitir información común que puede ser transmitida en un solo paquete por tamaño. Datos grandes: Este tipo de paquete está diseñado para gestionar transmisiones más grandes que requieren segmentación además de mecanismos de control para garantizar que la información llegue a su destino. Este paquete además del mensaje (hasta 211 bytes), tiene que contener el número de paquetes de la secuéncia (2 bytes), el identificador dentro de la secuéncia (1 byte) y un campo que indique el siguiente salto del paquete (2 bytes). Figura 9: Estructura del paquete de datos grande. Fuente 6.2.2. Segmentación de datos grandes Cuando se transmiten datos grandes, estos se dividen en fragmentos más pequeños que caben en los paquetes de LoRa, respetando un limite máximo de 222 bytes por paquete. Con el objetivo de que el receptor reciba la información con fiabilidad, de forma ordenada y sin errores, primeramente se numera cada fragmento y se espera un paquete de confirmación por parte del receptor para confirmar su entrega. Si un fragmento no se recibe correctamente, el receptor envía un paquete de no confirmación conforme el paquete no ha sido recibido (se ha perdido), solicitando su retransmisión. Además antes de iniciar la transferencia, se establece una conexión mediante un protocolo de handshake de dos pasos. Primeramente se envia un paquete con el SYNC_P flag y el número de paquetes que contiene la transmisión, una vez recibido el destino envia un paquete de confirmación. 34 Este proceso garantiza que el receptor está preparado para recibir los datos y asegura que la transferencia puede ser gestionada correctamente. Paquetes de control. Los paquetes de control gestionan la sincronización y el estado de las conexiones durante la transmisión de datos grandes. Como ya hemos mencionado, existen paquetes de sincronización para indicar el inicio de una tranferencia de datos grande, el paquete de confirmación, que confirma la recepción exitosa de un fragmento de datos, el paquete de no confirmación (LOST_P) que notifica la pérdida de un fragmento y finalmente el paquete de solicitación de confirmación. Además con el objetivo de asegurar la integridad y fiabilidad de los datos transmitidos se añaden las siguientes características a los paquetes de control: Temporizadores dinámicos: Basados en el cálculo de RTT (Round Trip Time), ajustan los tiempos de espera para recibir ACKs. Máximo de reintentos: Configurable (por defecto, 10 reintentos) antes de considerar fallida una conexión. Timeouts adaptativos: Permiten compensar retrasos en redes congestionadas o con múltiples saltos. En el desarrollo productivo de este proyecto nos centraremos en añadir un nuevo tipo de paquete de control destinado a identificar a los paquetes que lleven a cabo nuestro Trace Route. 6.3. Colas de paquetes Como ya hemos visto, LoRaMesher tiene varios tipos de paquetes, cada uno usado para diferentes situaciones, ya sea control de la red, enrutamiento o simplemente como medio para transmitir datos, cada uno de estos paquetes una vez el nodo los recibe, estos pueden tener distintos objetivos, tal vez volver a ser enrutados, o bien han llegado a su destinación y deben comunicar alguna información de control, o tal vez deben ser entregados a la capa de aplicación. Este procesamiento de paquetes con distintas probabilidades, crea la necesidad de tener estructuras locales donde almacenar estos paquetes. LoRaMesher implementa para esta finalidad, un conjunto de colas para paquetes. Estas colas permiten que los paquetes sean almacenados temporalmente mientras esperan ser procesados o retransmitidos, asegurando que cada tarea pueda acceder a los datos de manera ordenada y eficiente. 35 6.3.1. Estructura general de las colas Cada cola en LoRaMesher está compuesta por elementos denominados Packet Queue Elements. Estos elementos contienen: Un número de prioridad, que determina el orden en el que serán procesados. La dirección de memoria del paquete, que apunta a los datos concretos almacenados. Un enlace al siguiente elemento, manteniendo una estructura de lista enlazada para agilizar el acceso. Cuando un paquete es añadido a una cola, se inserta en la primera posición si su prioridad es más alta que la de los elementos existentes. Este mecanismo garantiza que los paquetes más urgentes sean procesados primero. 6.3.2. Tipos de colas 1. Cola de paquetes recibidos (Q_RP) La cola Q_RP se encarga de almacenar los paquetes recibidos desde la interfaz de radio LoRa. Su principal objetivo es mantener los paquetes accesibles para ser procesados localmente por las tareas correspondientes. ¿Cómo funciona? Cuando un paquete llega, una tarea especializada lo recoge y lo añade a esta cola. Posteriormente, otra tarea se encarga de procesar cada paquete, ya sea para actualizar tablas de enrutamiento, reenviar el paquete o pasarlo a la capa de aplicación si es necesario. 2. Cola de paquetes a enviar (Q_SP) La cola Q_SP almacena los paquetes que están listos para ser transmitidos a través de la radio LoRa. ¿Cómo funciona? Las tareas toman los paquetes almacenados en esta cola, uno por uno, y los envían según el orden en que fueron añadidos. Esto asegura que los paquetes se transmiten siguiendo el flujo definido por la aplicación o el protocolo. 3. Cola de paquetes recibidos por el usuario (Q_URP) La cola Q_URP está diseñada específicamente para gestionar los paquetes destinados a la capa de aplicación en el nodo receptor. ¿Cómo funciona? Cuando un paquete está dirigido al propio nodo (y no a ser reenviado), se añade a esta cola. Luego, una tarea notifica a la aplicación que un nuevo paquete ha llegado y está disponible para su procesamiento. 36 4. Cola de espera para envío (Q_WSP) Esta cola administra los paquetes grandes que deben ser divididos en fragmentos más pequeños antes de su envío. ¿Cómo funciona? Cuando se establece una conexión, se crea un objeto con información sobre el estado de la transmisión, como un Identificador de secuencia para identificar la transmisión, Direcciones de origen y destino,Número total de paquetes para saber cuántos fragmentos deben enviarse, Última confirmación recibida para seguir el proceso y Temporizadores para gestionar retransmisiones en caso de fallos. 5. Cola de espera para recepción (Q_WRP) Esta cola está destinada a gestionar los fragmentos recibidos en transmisiones de datos grandes. ¿Cómo funciona? Los paquetes recibidos se almacenan temporalmente en esta cola hasta que se han recibido todos los fragmentos. Tras recibir cada fragmento, se envía un paquete de confirmación (ACK) al remitente. Si falta un fragmento, se genera una notificación (LOST) para solicitar su retransmisión. 6.4. Tareas de LoRaMesher Debido a la naturaleza asíncrona y orientada a eventos de LoRaMesher debido a los recursos limitados de los nodos LoRa, LoRaMesher utiliza tareas para el procesamientos de los paquetes y otros recursos como las tablas de enrutamientos. LoRaMesher utiliza un total de 6 tareas, donde cada una hace uso de las colas que ya hemos mencionado para operar con los paquetes, añadiendo nuevos paquetes, modificandolos y eliminando paquetes de las própias colas, que suponen una comunicación indirecta entre las tareas. 1. Tarea de recepción La tarea de recepción es la principal tarea de LoRaMesher, es por ello que tiene la prioridad más alta dentro del planificador de FreeRTOS. Su función principal es capturar los paquetes entrantes de la radio LoRa, mediante un mecanismo de interrupción, extraer el payload y transformarlo en un paquete LoRaMesher (como indica la Figura 3 vista anteriormente), crear un nuevo elemento en la cola de paquetes recibidos y finalmente notificar a la tarea de procesamiento para que gestione el paquete. 2. Tarea de envío La tarea de envío es la encargada de enviar los paquetes almacenados en la cola de envíos. Esta es la segunda tarea con más prioridad. 37 Figura 10: Diagrama de la tarea de envío. Fuente Como podemos ver en la figura esta tarea obtiene el paquete de la cola de envío verifica si la dirección de destino está en la tabla de enrtamiento y actualiza el siguiente salto del paqute. Una vez actulaizado implementa un mecanismo llamado Carrier sense multiple access with collision avoidance para evitar colisiones en el canal. Finalmente envía el paquete haciendo uso de un time on air para reducir las posibilidades de colisiones. 3. Tarea de enrutamiento La tarea del protocolo de enrutamiento tiene como objetivo actualizar periódicamente la tabla de enrutamiento de cada nodo. Esto se logra creando mensajes de enrutamiento que contienen las rutas conocidas por el nodo actual, incluyendo las direcciones de otros nodos y el número de saltos necesarios para alcanzarlos. Estos mensajes son enviados a los nodos vecinos para que puedan actualizar sus propias tablas de enrutamiento. Esta tarea tiene una prioridad menor que la tarea de envío, pero mayor que la de procesamiento. 4. Tarea de procesamiento La tarea de procesamiento actúa como intermediaria entre la recepción de paquetes y su destino final, ya sea para reenviarlos, entregarlos a la capa de aplicación, o actualizar las tablas de enrutamiento. Tras ser notificada por la tarea de recepción, esta tarea clasifica los paquetes de la cola de paquetes recibidos según si es un mensaje de enrutamiento, en cuyo caso se analiza y se actualiza la tabla de enrutamiento local, o si es un mensaje de datos, que por otro lado se verifica si el paquete está dirigido al nodo actual (se añaden a la cola de paquetes recibidos por el usuario) o necesita ser reenviado (se añaden a la cola de envíos). 5. Tarea de usuario para envío Diseñada para la capa de aplicación, esta tarea permite a los usuarios enviar mensajes de datos utilizando LoRaMesher. Esta tarea asegura que los paquetes creados por la aplicación se integren correctamente en la cola de envíos. 6. Tarea de usuario para recepción Esta tarea se ocupa de gestionar los paquetes dirigidos a la aplicación del nodo. Cada vez que un paquete es añadido a la cola de paquetes recibidos por el usuario, la tarea es notificada, permitiendo a la aplicación acceder al paquete y procesarlo según sus necesidades. Además, la aplicación debe eliminar los paquetes procesados para gestionar adecuadamente la memoria del dispositivo. 38 6.4.1. Relación entre las tareas y las colas Como ya hemos podido observar, las colas en LoRaMesher actúan como intermediarias para compartir datos entre las tareas, permitiendo una comunicación indirecta y organizada. En la siguiente figura se muestra un ejemplo de esta relación: 1. La tarea de recepción agrega paquetes a la cola Q_RP después de capturarlos de la radio LoRa. 2. La tarea de procesamiento retira los paquetes de Q_RP y, según su tipo, los coloca en Q_URP (si son para la aplicación) o Q_SP (si requieren reenvío). 3. La tarea de envío extrae paquetes de Q_SP para transmitirlos. 4. Las tareas de usuario interactúan con Q_URP para procesar paquetes recibidos o con Q_SP para enviar mensajes. 39 7. Introducción de la herramienta Traceroute Ahora que ya hemos podido analizar en profundidad la librería de LoRaMesher, como trabaja, como estructura los paquetes, como se comunican las tareas, etc. Ahora podemos adentrarnos a desarrollar una herramienta propia que constituya el propósito del proyecto. Para ello, como hemos comentado anteriormente, este proyecto se centrará en el desarollo de una herramienta de Traceroute. Pero para qué sirver un Traceroute y para qué lo queremos en LoRaMesher. Un Traceroute es una herramienta de diagnóstico utilizada en redes de comunicaciones para rastrear la ruta que sigue un paquete desde un origen hasta su destino. Su principal función es identificar los saltos intermedios por los que pasa el paquete a lo largo de la red, proporcionando información detallada, si se requiere, sobre cada uno de estos nodos. Esta herramienta resulta especialmente útil para diagnosticar problemas de conectividad, analizar el rendimiento de la red y detectar posibles fallos en las rutas. Figura 11: Ejemplo de Traceroute en redes convencionales donde se indica la dirección de un nodo destino y se obtiene los nodos por los que pasa hasta llegar al destino. En el contexto de LoRaMesher, donde los nodos forman una red en malla y la comunicación puede requerir múltiples saltos para llegar al destino, un Traceroute puede ser una herramienta muy útil para el continuo desarrollo de la librería: 1. Diagnóstico de problemas de enrutamiento En una red de malla, los paquetes pueden fallar al llegar a su destino por diversas razones, como tablas de enrutamiento desactualizadas, nodos intermedios fuera de servicio o problemas de interferencias en el canal de radio. Con un Traceroute, podemos identificar en qué punto exacto del recorrido está ocurriendo el fallo. 40 2. Verificación de las topologías formadas Aunque el protocolo proactivo de LoRaMesher intenta mantener las rutas actualizadas, los cambios en la red, como el movimiento o la desconexión de nodos, pueden afectar la información almacenada en las tablas. Además, el desarrollo de nuevas métricas como el ya mencionado BMX, provocan topologías distintas que necesitan ser verificadas. Un Traceroute puede comprobar si las rutas establecidas coinciden con las rutas esperadas. 3. Optimización de la red Al identificar rutas más largas o ineficientes, esta herramienta permitirá ajustar los parámetros del protocolo, como la periodicidad de los mensajes de enrutamiento o el tamaño de los paquetes, para optimizar el uso del canal de comunicación. 7.1. Diseño del Traceroute Aunque Traceroute es una herramienta ya utilizada en redes como las convencionales, existen distintas soluciones de trace route, cada una con distintos diseños. Por ejmplo en redes convencionales existen dos soluciones muy comunes, por un lado las que utilizan protocolos sin estado como ICMP (en el caso del que utiliza Windows) o UDP, donde existen las ventajas de usar protocolos fáciles de utilizar, muy ligeros y de diagnóstico rápido, pero por otro lado tienen muchas limitaciones por parte de los cortafuegos o tienen limitación de capacidad de información debido precisamente a la ligereza de los protocolos. Por otro lado los Traceroute basados en TCP proporcionan mayor précision para tráfico real ya que tienen en cuenta recursos TCP o parámetros de QoS que incluye TCP, pero tienen las desventaja de ser más complejos y consumir más recursos. En el caso de LoRaMesher debido a la capa sobre la que se trabaja (por encima de la capa física de LoRa), se ha decidido hacer una implementación más parecida a la de ICMP/UDP donde no se mantiene ningún estado. Sin embargo existen distintas cuestiones de diseño que hay que resolver, y en este proyecto se han planteado dos tipos de diseño de la herramienta: Estrategia de descubrimiento incremental. Este enfoque se basa en el uso de un TTL (Time-to-Live) que comienza en 1 y se incrementa progresivamente para descubrir los nodos salto por salto. Se envían múltiples paquetes, cada uno con un TTL mayor que el anterior. Cada nodo intermedio devuelve inmediatamente un paquete con su dirección al nodo origen, proporcionando la información recogida en cada salto. El proceso continúa hasta que se alcanza el nodo destino. 41 8.2.2. Llamada de Traceroute Ahora que ya tenemos los recursos necesarios para implementar el Traceroute, es decir paquetes para llevarlo a cabo y una forma de crearlos, ya podemos ver la llamada principal que iniciará el Traceroute. Este método llamado traceRoute se encuentra en el archivo principal de la librería, el LoraMesher.cpp y es el que llama el método de traceRouteOn de LoRaChat cuando se notifica con el comando mediante MQTT. Esto quiere decir que este método solamente será llamado en el nodo donde se inicia el Traceroute, por lo tanto necesitaremos saber cuándo un paquete está en este nodo que origina el Traceroute, pero eso lo veremos más adelante. De momento nos centraremos en está función que desempeñará el papel del nodo que hace la llamada. 1int8_t ttl = 1; 2 3// Crear y enviar el paquete inicial de rastreo de ruta 4ControlPacket*traceRoutePacket =PacketService::createTraceRoutePacket(dst, getLocalAddress(), ttl, 0);,→ 5ESP_LOGI(LM_TAG, "Rastreo de ruta. Primer paquete origen %X, destino %X, tamaño = %d", traceRoutePacket->src, traceRoutePacket->dst, traceRoutePacket->packetSize); ,→ ,→ 6 7auto*qp =PacketQueueService::createQueuePacket(traceRoutePacket, DEFAULT_PRIORITY, 1);,→ 8addToSendOrderedAndNotify(reinterpret_cast<QueuePacket<Packet<uint8_t>> *>(qp)); Figura 20: Creación y envío del primer paquete Para hacer un Traceroute el primer nodo deberá primeramente enviar un paquete en hacia el destino del Traceroute, y una vez envíe ese primer paquete, deberá ir esperando demás paquetes con las direcciones. En la figura anterior podemos ver cómo se hace la creación del paquete y su posterior envío, mediante la función addToSendOrderedAndNotify que añadirá el paquete a la cola de envíos y luego será la tarea de envíos la que llevará a cabo el envío. Pero cómo sabrá el nodo cuando haya llegado un nuevo paquete con una nueva dirección que añadir al Traceroute? En LoRaMesher existen otras situaciones similares donde al recibir un paquete, se necesita notificar por ejemplo al usuario, en este caso se hace uso de la tarea de usuario de envío, que permite notificar al usuario para que haga alguna acción. Sin embargo este tarea está solamente pensada para paquetes de aplicación que puedan tener datos relevantes para el usuario. Para poder notificar al nodo de la llegada de un paquete de control como los de Traceroute, requeriremos de algún método que sea interno de la funcionalidad de Traceroute. Para ello se ha decidido usar una cola para paquetes de Traceroute que solamente se usará para hacer precisamente esta notificación. La cola usada es una cola de FreeRTOS global, llamada traceRouteQueue y que solamente estará inicializada en el nodo que inicia el Traceroute. 48 Para poder realizar la espera de los paquetes se empleará un bucle para poder gestionar todos los paquetes que se reciban y una llamada bloqueante que pueda leer el contenido de la cola y desbloquee la tarea cada vez que se añada un paquete a la cola. En la siguiente figura podemos ver el bloque que contiene la lógica principal del nodo en el Traceroute. 1ControlPacket*receivedPacket =nullptr; 2while (true) { 3receivedPacket =(ControlPacket*)pvPortMalloc(sizeof(ControlPacket) + sizeof(TraceRoutePayload));,→ 4// Esperar para recibir un paquete con tiempo de espera 5if (xQueueReceive(traceRouteQueue, receivedPacket, pdMS_TO_TICKS(TRACE_ROUTE_TIMEOUT)) == pdPASS) {,→ 6noFixes = 0;// Reiniciar el contador de respuestas perdidas 7auto*tracePayload = reinterpret_cast<TraceRoutePayload*>(receivedPacket->payload);,→ 8// Añadir el nuevo salto a la lista de direcciones si no es un duplicado 9if (traceRouteAddresses.empty() || traceRouteAddresses.back() != tracePayload->newhop) {,→ 10 traceRouteAddresses.push_back(tracePayload->newhop); 11 }else { 12 // Rastreo de ruta misma dirección que el último salto 13 } 14 // Comprobar si se ha alcanzado el destino 15 if (tracePayload->newhop == dst) { 16 // Rastreo de ruta terminado. Destino alcanzado. 17 free(receivedPacket); 18 break; 19 }else { 20 // Crear y enviar el siguiente paquete con TTL incrementado 21 ttl += 1; 22 traceRoutePacket =PacketService::createTraceRoutePacket(dst, getLocalAddress(), ttl, tracePayload->id + 1);,→ 23 qp =PacketQueueService::createQueuePacket(traceRoutePacket, DEFAULT_PRIORITY, 1);,→ 24 addToSendOrderedAndNotify(reinterpret_cast<QueuePacket<Packet<uint8_t>> *>(qp)); ,→ ,→ 25 } 26 }else { 27 ++noFixes; 28 if (noFixes >= TRACE_ROUTE_NUMBER_FIXES) { // Detener después de TRACE_ROUTE_NUMBER_FIXES tiempos de espera consecutivos,→ 29 free(receivedPacket); 30 break; 31 } 32 // Reenviar el último paquete 33 addToSendOrderedAndNotify(reinterpret_cast<QueuePacket<Packet<uint8_t>> *>(qp));,→ 34 } 35 free(receivedPacket); 36 } Figura 21: Gestión de paquetes de Traceroute por el nodo origen 49 Como podemos ver, cada vez que se recibe un paquete de Traceroute (se detecta que se ha añadido en la cola) además de registrar su dirección descubierta, se comprueba si esta dirección es la dirección destino sobre la cual se ha hecho el Traceroute, en cuyo caso finaliza el Traceroute, o en el caso de que no lo sea, se crea y se envía un nuevo paquete al destino del Traceroute, pero con un TTL de una unidad más alto, para que esta vez el paquete llegue un salto más lejos y pueda descubrir un nuevo nodo. Además como podemos ver, también se han añadido dos métodos para asegurar que el Traceroute se realiza de forma correcta, la primera consiste en descartar direcciones repetidas, por si por alguna razón se recibe un paquete no deseado o se analiza mal debido a una colisión, y la segunda consiste en hacer re-intentos de seguridad (definidos por una constante) de envío de paquetes por si no se llega a recibir algún paquete que se ha perdido o ha tenido algún problema, después del timeout estipulado por otra constante. 8.2.3. Procesado de paquetes Traceroute Finalmente, una vez hemos implementado la estructura y creación de los paquetes, hemos hecho la llamada principal de Traceroute, que gestionará la lógica del nodo que origina el Traceroute, nos falta gestionar la lógica de los demás nodos para que sepan qué tienen que hacer con cada paquete de Traceroute que reciben en cada momento. En el momento de recibir un paquete, como hemos visto anteriormente en el análisis, la tarea de procesado de paquetes es la que se encarga de leer el tipo de paquete y según uno u otro se deciden hacer distintos procesos. Precisamente esta tarea se encargará de ejecutar nuestra tarea de procesado de paquetes de Traceroute llamada processTraceRoutePacket. Una vez se llame a este método, se le pasará por argumento el paquete de Traceroute a procesar. Para entender la lógica que tendrá que seguir el paquete en este método podemos diferenciar distintos casos, sin embargo antes de contemplar cualquier caso, se verifica que el payload del paquete no sea nulo, en cuyo caso se descarta el paquete, y en segundo lugar, es en este momento donde se decrementa una unidad al TTL del paquete, lo cual indica que ha llegado a un nuevo nodo. En cuanto a los casos ya mencionados, se encuentran los siguientes: 1. TTL inválido - Este caso de produce cuando el TTL una vez decrementado, se encuentra por debajo de 0. Este caso es inválido y no debería ocurrir, por lo tanto se decide descartar el paquete. 2. Nodo origen - Este caso se da cuando el TTL es igual a 0 y además tenemos en el nodo donde se está ejecutando el código, nuestra cola de Traceroute definida, en este caso se intuye que como el TTL es igual a 0, este paquete a llegado a su destino (bien un nodo nuevo que ha descubierto, o bien el nodo origen al que ha regresado), además que la cola de Traceroute esté definida nos da la información de que estamos en el nodo que inició el Traceroute. En este caso, podemos saber que el paquete de Traceroute ha terminado y por lo tanto tenemos que hacer uso de la cola que hemos explicado anteriormente y añadir el paquete para que el método principal de traceRoute pueda gestionar el paquete. 50 1// 1. El paquete ha llegado al nodo origen (notificar ruta de rastreo) 2if (tracePayload->ttl ==0&&traceRouteQueue) { 3ESP_LOGV(LM_TAG, "Paquete Trace Route terminado en el nodo %X.", getLocalAddress());,→ 4xQueueSend(traceRouteQueue, packet, 0); // Encolar el paquete para procesarlo,→ 5return; 6} Figura 22: Caso donde el paquete ha regresado al nodo origen 3. Nuevo nodo - Por otro lado, cuando no está definida la cola y además el TTL ha llegado a 0, significa que hemos llegado a un nuevo nodo (nuestro destino). En este caso se busca añadir la información del nuevo nodo al paquete, y devolver el paquete al nodo origen para registrar la información. En la siguiente figura se muestra el bloque de código que la gestiona: 1// 2. El paquete ha encontrado un nuevo nodo en el Traceroute 2if (tracePayload->ttl == 0) { 3 4// Actualizar los campos del paquete para regresar al nodo origen 5packet->dst =packet->src; 6packet->src =getLocalAddress(); 7nextHop =RoutingTableService::getNextHop(packet->dst); 8 9// Verificar si existe el siguiente salto 10 if (nextHop == 0) { 11 ESP_LOGE(LM_TAG, "Trace Route. No se encontró el siguiente salto desde %X, destino %X", packet->src, packet->dst);,→ 12 free(packet); 13 return; 14 } 15 16 packet->via =nextHop; 17 tracePayload->ttl =RoutingTableService::getNumberOfHops(packet->dst); 18 tracePayload->newhop =getLocalAddress(); 19 tracePayload->id += 1; 20 21 ESP_LOGV(LM_TAG, "Devolviendo paquete desde %X a %X vía %X con ttl %X.", packet->src, packet->dst, packet->via, tracePayload->ttl);,→ 22 addToSendOrderedAndNotify(reinterpret_cast<QueuePacket<Packet<uint8_t>>*>(qp));,→ 23 return; 24 } Figura 23: Caso donde el paquete ha llegado a un nuevo nodo 51 Como podemos ver en la figura para poder devolver el paquete al nodo origen, deberemos modificar las direcciones de destino (con la dirección del nodo origen) y origen (con el nodo actual), y obtener el siguiente salto para llegar mediante el nextHop de la tabla de encaminamiento. Además también tenemos que calcular el nuevo TTL del paquete según el número de saltos que queremos que haga hasta llegar a su destino, para ello utilizaremos un método de la tabla de encaminamiento también. Finalmente debemos añadir por supuesto, la dirección del nuevo nodo al campo de newhop. 4. Reenviar paquete - El último caso trata la situación donde el TTL del paquete todavía es mayor que 0, lo que significa que aún no ha llegado a su destino, por lo tanto lo único relevante que hay que actualizar es el vía del paquete el cual hay que actualizar con el next hop de la tabla de encaminamiento. 1// 3. Reenviar el paquete al siguiente salto 2nextHop =RoutingTableService::getNextHop(packet->dst); 3 4if (nextHop == 0) { 5ESP_LOGE(LM_TAG, "No se encontró el siguiente salto desde %X, destino %X", packet->src, packet->dst);,→ 6free(packet); 7return; 8} 9 10 packet->via =nextHop; 11 tracePayload->id += 1; 12 13 ESP_LOGV(LM_TAG, "Reenviando paquete desde %X a %X vía %X.", packet->src, packet->dst, packet->via);,→ 14 addToSendOrderedAndNotify(reinterpret_cast<QueuePacket<Packet<uint8_t>>*>(qp));,→ Figura 24: Caso donde el paquete ha llegado a un nuevo nodo Ahora que hemos visto el método de procesado de paquetes, ya podemos entender la visión general del Traceroute junto a la función de Traceroute principal y podemos empezar a hacer Traceroutes para evaluar redes de LoRaMesher. 52 9. Evaluación de redes con Traceroute En esta sección se presenta la evaluación de las redes malla creadas por LoRaMesher haciendo uso de la herramienta desarrollada, Traceroute, como parte de este proyecto. Esta herramienta ha sido diseñada para proporcionar información sobre las rutas seguidas por los paquetes en la red, facilitando así la validación de las topologías, creadas por los distintos protocolos de enrutamiento que se proponen en LoRaMesher. Por otro lado también se busca explorar el desempeñó de Traceroute como mecanismo de diagnóstico para redes de distinta forma, y con características diferentes, y poder así obtener información valiosa para la mejora de la herramienta. Esta evaluación consistirá en distintos experimentos realizados sobre distintos tipos de redes, cada una configurada de distinta forma, donde se evaluará principalmente el protocolo de enrutamiento: First-Hop (número de saltos): Este protocolo utiliza la métrica de número de saltos para determinar la ruta más corta entre el origen y el destino. Su simplicidad lo hace eficiente en redes pequeñas y de baja complejidad, pero puede mostrar limitaciones en configuraciones más grandes o dinámicas. Se diseñarán distintos escenarios para probar cómo se comporta el protocolo de First-Hop en redes pequeñas así como en redes más extensas. Con estas pruebas podremos comprobar los patrones de comportamiento del protocolo, así como sus posibles limitaciones, que nos acabarán abocando al segundo protocolo de enrutamiento, el BMX. 9.1. Herramientas necesarias Con el objetivo de poder realizar estos experimentos, necesitaremos una mezcla de herramientas tanto para poder llevar a cabo el Traceroute, como para poder simular los entornos, topologías y características que tendrán las redes donde hagamos las pruebas. Por un lado, por supuesto necesitaremos los nodos conectados a la corriente mediante un cable Micro-USB, por otro lado necesitaremos además alguna forma para crear las topologías que queramos probar, ya que debido a que la tecnología LoRa (Long range) tiene rangos de conexión muy altos, las redes de prueba como las que usamos nosotros, al estar todos los nodos localizados en el mismo sitio, a no ser que estos estén muy alejados con condiciones físicas muy concretas, todos los nodos, al ser una red malla, tienden a tener conexión entre ellos. Para ello haremos uso de una funcionalidad de testing que tiene LoRaMesher para crear topologías por código. En la siguiente figura podemos ver la función que lo hace posible: 53 1#ifdef LM_TESTING 2bool LoraMesher::canReceivePacket(uint16_t source) { 3uint16_t local_addr =getLocalAddress(); 4 5if (local_addr == 0x7AF0) { 6if (source == 0x79C8)return true; 7}else if (local_addr == 0x7B8C) { 8if (source == 0x79C8)return true; 9} 10 11 return false; 12 } 13 #endif Figura 25: Método para crear topologías por código Mediante este método podemos controlar si un nodo puede recibir un paquete que tiene como origen otro nodo, de esta forma si un nodo recibe un paquete de un nodo que esta función no permite, el paquete será descartado, provocando que la tabla de encaminamiento, mediante los paquetes que anuncian las rutas, se adapten y actualicen sus métricas según la topología buscada. La segunda herramienta que necesitaremos será simplemente para facilitar el trabajo al hacer un Traceroute. Ahora mismo para hacer un Traceroute, como ya se ha mencionado en capítulos anteriores, una vez están los nodos iniciados, necesitamos por un lado un publisher MQTT para poder ejecutar la acción del Traceroute y un subscriber MQTT para recibir el resultado del Traceroute. Para no tener que crear mensajes JSON específicos cada vez, hemos creado un programa de terminal para poder hacer Traceroutes de manera rápida y eficaz. Las siguientes figuras muestran las principales funciones del programa de python utilizado para automatizar el Traceroute. Por un lado tenemos la función publish_trace_route publica un mensaje en el tópico from-server del gateway, en función del origen y el destino del Traceroute. Por otro lado tenemos el método on_message que se ejecuta en segundo plano, una vez estamos suscritos al tópico to-server del gateway, y que recibe los mensajes resultantes del Traceroute obteniendo en el campo traceRouteAddresses las direcciones resultantes. 54 1def publish_trace_route(client, origin, destination, gateway): 2topic =f"from-server/{gateway}" 3message ={ 4"data": { 5"appPortDst":18, 6"appPortSrc":18, 7"addrDst":int(origin), 8"traceRouteCommand":0, 9"traceRouteDst":int(destination) 10 } 11 } 12 13 client.publish(topic, json.dumps(message)) Figura 26: Método para publicar el mensaje de Traceroute 1def on_message(client, userdata, msg): 2global trace_route_result, trace_route_addresses 3 4# Procesar el mensaje recibido 5payload =json.loads(msg.payload.decode()) 6data =payload.get("data", {}) 7 8if "traceRouteResult" in data: 9trace_route_result =data["traceRouteResult"] 10 trace_route_addresses =data.get("traceRouteAddresses", []) 11 print("Respuesta recibida del trace route:") 12 print(json.dumps(data, indent=2)) Figura 27: Método que recibe el resultado del Traceroute 9.2. Evaluación con la métrica First-Hop Esta sección la dedicaremos a describir los experimentos pensados para probar las redes creadas con la métrica de First-Hop. Los experimentos consistirán en probar el Traceroute primero en una red con dos nodos, donde el intercambio de paquetes es muy sencillo y a continuación añadiremos el tercer nodo que tenemos disponible para este proyecto, hecho que añadirá complejidad al Traceroute. Antes de realizar los experimentos deberemos tener cada nodo con la versión que se ha mejorado de LoRaChar, que además haga uso de la versión de LoRaMesher que incluye el Traceroute. Para poder compilar y subir el códiigo a las placas haremos uso de Platformio, concretamente el siguiente comando correspondiente a Linux: 55 1pio run --target upload --target monitor --environment ttgo-t-beam --upload-port /dev/ttyACM0 --monitor-port /dev/ttyACM0 Donde /dev/ttyACMx corresponde al puerto donde tengamos conectada la placa, y que nos servirá tanto para subir LoRaChat a las placas como para monitorizar el puerto serial de la misma. Otra cosa que tenemos que tener en cuenta, es que deberemos subir distintas versiones del código dependiendo de los nodos gateway y los nodos que no lo sean, en este caso al ser redes tan pequeñas, únicamente tenemos un gateway, por lo tanto deberemos tener en cuenta las siguientes configuraciones en el archivo config.h de LoRaChat: Para los nodos gateway deben estar configurados las credenciales de una red Wifi para poder enviar los mensajes MQTT. 1#define WIFI_SSID "*************" 2#define WIFI_PASSWORD "***************" Para los nodos gateway, además deberemos configurar con qué broker MQTT queremos que comunique nuestra red, además de los tópicos que utilizará. 1// MQTT configuration 2#define MQTT_SERVER "192.168.1.143" 3#define MQTT_PORT 1883 4#define MQTT_USERNAME "admin" 5#define MQTT_PASSWORD "public" 6#define MQTT_TOPIC_SUB "from-server/" 7#define MQTT_TOPIC_OUT "to-server/" Finalmente para los nodos que no sean gateway podemos por un lado poner valores sin sentido a las configuraciones de MQTT y WIFI que ya hemos visto, o por otro lado, también tenemos la opción de deshabilitar los servicios de MQTT y WIFI como se muestra a continuación: 1#define WIFI_ENABLED 2#define MQTT_ENABLED Una vez hemos hecho las configuraciones pertinentes ya podremos hacer la compilación y flasheo de las pertinentes versiones en las correspondientes placas. 56 9.2.1. Experimento con dos nodos El primer experimento como ya hemos dicho solamente tiene dos nodos y ambos están en una misma habitación. Por un lado tenemos un nodo gateway con la dirección: 0x7AF0 y por otro lado un nodo con la dirección 0x79C8. Ambos están conectados y su métrica es 1 según la tabla de encaminamiento, lo que a nivel práctico significa que los nodos están a un hop de distancia. El experimento empieza entonces indicando en el programa de terminal que hemos mencionado una dirección de gateway y de nodo que origina el Traceroute, con valor 0x7AF0, y un nodo destino con dirección 0x79C8. Figura 28: Diagrama del experimento de dos nodos En la figura anterior se muestra el flujo de paquetes del Traceroute en el experimento. Primeramente el nodo 0x7AF0 envía un paquete con el TTL igual a 1, para descubrir el primer nodo de la ruta, y una vez el nodo 0x79C8 recibe el paquete, este le añade su dirección y actualiza el TTL. Como podemos ver el flujo es el correcto ya que los TTLs son los correctos y el segundo nodo añade correctamente su dirección al newhop. Cabe mencionar que el paquete que envía el nodo 0x79C8, tiene un TTL de 1 ya que el paquete necesita un salto para llegar a su destino, de esta forma el paquete puede llegar sin ser descartado, de esta forma el nodo 0x79C8 ha debido volver a poner el TTL a uno, ya que una vez recibió el paquete este decrementó el TTL en uno, dando un TTL igual a 0 como resultado. 57 10. Conclusiones y Reflexiones El principal objetivo de este proyecto era explorar las redes mesh LoRa con la librería LoRaMesher, además de ser capaz de aportar a una librería de redes como esta y ser capaz de hacer una evaluación sobre sus protocolos de enrutamiento. Este capítulo tratará de describir los logros de este proyecto, los problemas con los que ha tenido que lidiar, los retos que han quedado por resolver, y en general unas conclusiones finales. A medida que se avanzó en la planificación de este proyecto, se fueron esclareciendo los objetivos generales, concentrándolos cada vez más, hasta dar con el objetivo de desarrollar una herramienta de Traceroute para LoRaMesher. Esta herramienta era una característica que se necesitaba desde hacía tiempo para la librería, y que además permitiría al proyecto usarla para la evaluación de los protocolos de enrutamiento que necesitan ser sometidos a pruebas. A continuación se detallarán los logros conseguidos en las diferentes partes de este proyecto, tanto en el análisis de la librería, como en el desarrollo de la herramienta y la posterior evaluación. 10.1. Logros conseguidos 1. Conseguir un análisis muy detallado de la librería LoRaMesher, no solo de las funcionalidades básicas que ya habían sido descritas como la tabla de enrutamiento o las tareas básicas de manejo de paquetes, si no que además se ha logrado detallar nuevas funcionalidades como los paquetes de con payloads grandes. 2. Desarrollar una herramienta de diagnóstico de redes como Traceroute que puede ser utilizada para obtener rutas o topologías de una red LoRa formada con LoRaMesher. 3. Desarrollar una capa de aplicación formada con herramientas como LoRaChat o el programa de terminal, para que un usuario sea capaz de interactuar con la herramienta de Traceroute desde una capa de aplicación. A continuación se muestra el repositorio con las versiones de LoRaChat y LoRaMesher desarrolladas en este proyecto. 1https://github.com/marcelca02/LoRaMesher_Protocol_Evaluation 4. Hacer uso de la herramienta de Traceroute para hacer una evaluación del protocolo de First-Hop usado en LoRaMesher. Estos logros que se han listado son los logros principales y más importantes que se han conseguido en este proyecto. En cada uno de estos logros ha habido una larga lista de pequeñas metas que se han descrito a lo largo de este proyecto y que también podríamos considerar como logros. 64 Descritos entonces los logros principales, podemos concluir que se han podido conseguir los principales objetivos de este proyecto, que como hemos mencionado, eran por un lado un análisis o exploración de una tecnología como LoRaMesher, y por otro el desarrollo de una herramienta de diagnóstico como Traceroute, y una evaluación de los protocolos de enrutamiento de la librería. Sin embargo a pesar de que el balance general de los objetivos de este proyecto ha sido positivo, se debe mencionar la existencia de ciertos aspectos en el proyecto que no se han podido cumplir o que no han podido ser completados. 10.2. Dificultades encontradas Aunque en el apartado del análisis, se han podido alcanzar completamente los objetivos que se tenían, ya que se ha podido documentar tanto la librería de LoRaMesher, como el framework de LoRaChat y su flujo de comunicación a través de mensajes transmitidos mediante MQTTQ, podemos encontrar ciertos aspectos que no se han podido cumplir, o al menos en su totalidad en los apartados del desarrollo del Traceroute y la posterior evaluación. Echemos un vistazo primeramente a las dificultades que nos hemos encontrado en el desarrollo del Traceroute. 10.2.1. Dificultades en el desarrollo de Traceroute El desarrollo de la herramienta de Traceroute, dentro de LoRaMesher, ha presentado numerosos desafíos que han dificultado el cumplimento de los objetivos o incluso han impedido que algunos puedan realizarse. Entre los principales problemas, destacan los siguientes: Fugas de memoria: Durante la implementación, se identificó un memory leak que, a pesar de los esfuerzos realizados, no ha podido ser solucionado completamente. Aunque su impacto es limitado en pruebas de corta duración, este problema suele comprometer la estabilidad en escenarios más complejos o prolongados como se ha podido comprobar en el apartado de evaluación donde se han realizado distintos experimentos. Complejidad de depuración: El proceso de identificar y corregir errores relacionados con la lógica del Traceroute y el enrutamiento de los paquetes de Traceroute resultó ser un reto. Esto se debe, en parte, al entorno de pruebas limitado descrito en el capítulo de evaluación, que dificulta el monitoreo detallado de los paquetes. Tiempo limitado para solucionar problemas complejos: La restricción más importante fue el tiempo limitado para abordar problemas complejos, como las fugas de memoria y la depuración de la lógica del Traceroute. Esto se debió principalmente a los imprevistos que se iban encontrando, tratando de encontrar los problemas base en la lógica del Traceroute. 65 Las dificultades mencionadas exigieron un enfoque iterativo en el desarrollo del proyecto. Aunque la resolución de numerosos problemas implicó ajustes constantes y evaluaciones que ralentizaron el avance, estos también impulsaron importantes progresos que beneficiaron significativamente al proyecto. 10.2.2. Dificultades en la evaluación Tal y como ha sucedido con las dificultades encontradas en el desarrollo del Traceroute, también se han producido dificultades en la fase de evaluación principalmente relacionadas con imprevistos: Imprevistos: Como se ha mencionado los imprevistos que suele haber cuando se trabaja con un código experimental como es LoRaMesher, redujeron el tiempo disponible para realizar evaluaciones exhaustivas de Traceroute, limitando la evaluación a una parte de los experimentos planeados. Estado del protocolo BMX: Por otra parte el objetivo de evaluar el protocolo BMX no pudo cumplirse, debido a factores externos al proyecto, ya que el desarrollo de dicho protocolo aún se encuentra en una etapa temprana. Su funcionalidad actual presenta fallos que lo hacen incompatible con las pruebas planificadas utilizando Traceroute. 10.3. Direcciones futuras A pesar de los distintos desafíos que se han enfrentado durante el desarrollo y la evaluación, el proyecto abre una puerta a diversas oportunidades para su mejora y evolución. Aunque las limitaciones actuales han condicionado los resultados obtenidos, estas mismas dificultades sirven como punto de partida para establecer nuevas metas que amplíen el alcance del proyecto. A continuación, se describen algunas lineas de trabajo que permitirán potenciar el impacto y asegurar su utilidad, además de mejorar el proceso de evaluación. Entre las distintas direcciones que puede tomar el proyecto, se destacan las siguientes: 1. Resolución de los problemas existentes: Resolver los problemas identificados durante el desarrollo sería una prioridad para garantizar el funcionamiento del sistema. Esto incluye: Corregir los memory leaks para asegurar que el sistema pueda ejecutarse sin interrupciones prolongadas o fallos inesperados. Optimizar la lógica de enrutamiento y depuración para mejorar la eficacia del Traceroute en condiciones reales. 66 2. Análisis y evaluación del protocolo BMX: Dado que el protocolo BMX está en desarrollo, una vez este avance, podríamos tener las siguientes posibilidades: Retomar su evaluación y asegurarse de que las topologías creadas son correctas mediante el Traceroute. Comparar su rendimiento con el protocolo actual basado en el hop count para identificar áreas de mejora. 3. Extensión de la herramienta de Traceroute: Se podría aprovechar la infraestructura creada tanto en LoRaMesher como en LoRaChat, para añadir más posibilidades al Traceroute: Añadir información relevante a los paquetes de Traceroute, como por ejemplo la latencia de los paquetes para llegar a cada nodo. Añadir configuraciones o parámetros al hacer un Traceroute, como por ejemplo el número de reintentos, tiempo de espera o número máximo de saltos. Desarrollar el otro diseño de Traceroute mencionado en el capítulo 7.1. 10.4. Reflexiones finales Para finalizar, cabe decir que este proyecto ha sido altamente satisfactorio al demostrar el potencial de las redes mesh LoRa y la herramienta Traceroute como una base sólida para el análisis y la optimización de este tipo de redes. Los desafíos encontrados, aunque significativos, fueron en su mayoría resueltos, y contribuyeron a tener un mayor conocimiento del tema. Mi experiencia en este proyecto ha sido muy enriquecedora. He tenido la oportunidad de adentrarme en el mundo de las redes distribuidas y trabajar directamente con tecnologías basadas en LoRa, algo que ha ampliado mis conocimientos y habilidades en este campo. El proceso de desarrollar la herramienta de Traceroute me permitió enfrentar desafíos reales tanto de implementación como diseño y por otro lado la evaluación me ha permitido entender mejor el funcionamiento de las redes mesh desde un punto de vista muy cercano. En definitiva, este trabajo pone de manifiesto la importancia de iniciativas como esta para el desarrollo de tecnologías IoT en entornos complejos. Con una continuación de este proyecto, las herramientas y conocimientos generados, pueden evolucionar y ser utilizados para muchos otros desafíos. 67 11. Informe de sostenibilidad 11.1. Plano ambiental El impacto ambiental se ha centrado en el consumo energético de simulaciones y hardware. Para reducirlo, se reutilizaron placas TTGO y se limitaron simulaciones a las necesarias tras pruebas preliminares. Aunque no se cuantificó la reducción exacta, el ahorro en materiales y energía fue relevante. De repetirse el proyecto, este podría optimizarse aún más el aspecto del consumo energético con más herramientas de simulación, en vez de hacer tanto uso de las placas. El proyecto reduce el uso de otros recursos al optimizar redes IoT en entornos remotos, disminuyendo infraestructuras más grandes. Globalmente, mejora la huella ecológica mediante un bajo consumo y la reutilización de hardware. Un posible escenario que podría aumentar la huella ecológica del proyecto sería la necesidad de reemplazar placas o dispositivos dañados, incrementando el consumo de recursos materiales. Asimismo, el uso extensivo del proyecto en grandes redes podría generar un mayor consumo energético, aunque este impacto sería menor en comparación con alternativas tecnológicas más demandantes en términos de energía. 11.2. Plano económico El coste no se cuantificó en términos humanos, pero los costos materiales no variaron respecto a lo previsto. Se reutilizaron placas TTGO, manteniendo controlados los gastos. No se han cuantificado cambios perceptibles en los gastos, respecto a la planificación. Riesgos económicos incluyen actualizaciones frecuentes de firmware, fallos de hardware o mayor consumo en redes más grandes, aunque son poco probables a corto plazo. 11.3. Plano social El proyecto permitió explorar tecnologías como LoRa mesh, fortaleciendo habilidades técnicas y reflexionando sobre la sostenibilidad. Destacó la importancia de soluciones accesibles y éticas en el software libre. 68 Los principales beneficiarios del proyecto son desarrolladores e investigadores IoT. Al ser un proyecto abierto, beneficia a aplicaciones de distintos sectores como la agricultura o el medio ambiente. Además, no se identifica ningún colectivo que pueda verse directamente perjudicado por el uso del proyecto. El proyecto aborda eficazmente el problema planteado inicialmente, ofreciendo una solución para evaluar y optimizar redes mesh basadas en LoRa. Ha permitido mejorar la gestión del enrutamiento y proporcionar herramientas de diagnóstico que eran inexistentes en la librería de LoRaMesher, cumpliendo con los objetivos planteados. Los riesgos sociales que se incluyen son usos no éticos, como monitoreo sin consentimiento, pero estos dependen del contexto y no del diseño. No genera dependencia en usuarios al usar tecnología accesible y abierta. 69 12. Términos y Conceptos LoraMesher LoraMesher es una librería de código abierto utilizada para crear redes malladas que puedan comunicar distintos nodos a través de la tecnología LoRa. El principal objetivo de este tipo de topologías de red es habilitar la comunicación multi-salto entre dispositivos, de modo que los paquetes de datos puedan viajar a través de varios nodos intermedios hasta alcanzar su destino, extendiendo significativamente el rango de cobertura sin necesidad de que todos los dispositivos estén dentro del alcance directo de un gateway o estación base. Esta librería incluye principalmente el protocolo de enrutamiento de tipo Distance-Vector llamado first-hop basado en el conteo de saltos (hop count), que ayuda a determinar el camino más corto para transmitir los datos entre nodos. Además, también incluye otro protocolo que está en proceso de implementación llamado BMX (Better Metric eXperiment), que tiene en cuenta la calidad de los links entre cada nodo para decidir el enrutado. Protocolo de enrutamiento El protocolo de enrutamiento es el conjunto de reglas y algoritmos que determinan cómo se transfieren los datos entre los nodos de una red. En el caso de LoRaMesher, el protocolo de enrutamiento se encarga de definir las rutas que los mensajes deben seguir para viajar de un nodo a otro en una red mallada. Los protocolos de enrutamiento pueden estar basados en varias métricas, como la cantidad de saltos (hop count) entre nodos, la calidad de la señal o la latencia de la red. Estos protocolos son esenciales para la eficiencia y fiabilidad de las comunicaciones en redes distribuidas, ya que optimizan el uso de los recursos de la red y evitan la congestión. Red mallada Una red mallada (mesh network) es un tipo de arquitectura de red donde los nodos están interconectados de manera descentralizada, formando una malla o red en la que cada nodo puede comunicarse con varios otros nodos directamente o a través de nodos intermediarios. En lugar de depender de un único punto central, como un router o gateway en las redes tradicionales, los nodos en una red mallada pueden actuar tanto como transmisores como repetidores de datos, lo que les permite reenviar mensajes de un nodo a otro. Gateway Un gateway o puerta de enlace es el nodo o dispositivo en una red de computadores que actúa como puente o interfaz de conexión entre nodos, y que permite comunicar y compartir recursos entre ellos. 70 Hop Count El Hop Count consiste en una métrica habitual en los protocolos de enrutamiento que cuenta el número de saltos que realiza un paquete en una topología de red, hasta llegar a su destino. Esta métrica suele ser comúnmente utilizada para determinar el camino más corto entre dos nodos, es decir, el camino con menos saltos entre nodos. Nodo Un nodo es un dispositivo o unidad dentro de una red de comunicación que tiene la capacidad de enviar, recibir y, en el caso de redes malladas como LoRaMesh, reenviar datos hacia otros nodos. Los nodos pueden actuar como puntos de inicio, intermedios o de destino en una red, y su función específica depende de la topología y el protocolo de enrutamiento implementado. ESP32 El ESP32 es un microcontrolador de bajo costo y alto rendimiento desarrollado por Espressif Systems. Es ampliamente utilizado en aplicaciones IoT gracias a su integración de módulos WiFi y Bluetooth, lo que lo convierte en una opción versátil para proyectos que requieren conectividad. Además, cuenta con una arquitectura de doble núcleo y una variedad de interfaces para sensores y dispositivos externos. T-BEAM La T-BEAM es una placa de desarrollo basada en el microcontrolador ESP32 que incluye un módulo LoRa y funcionalidades adicionales como GPS y una pantalla OLED integrada. Diseñada para proyectos de redes LoRa, esta placa permite implementar soluciones de comunicación de largo alcance y bajo consumo energético. Es ideal para pruebas y despliegues en entornos IoT. Broker MQTT Un broker MQTT es un intermediario en el modelo de comunicación publish/subscribe del protocolo MQTT. Su función principal es recibir mensajes de los publishers y distribuirlos a los subscribers que estén interesados en los tópicos correspondientes. Este componente es clave para gestionar la comunicación en tiempo real entre dispositivos conectados, garantizando eficiencia y escalabilidad. BMX (Better Metric eXperiment) El BMX es un protocolo de enrutamiento basado en métricas avanzadas que evalúan la calidad de los enlaces entre nodos en lugar de limitarse al conteo de saltos. Este enfoque permite seleccionar rutas más óptimas en términos de rendimiento general de la red, considerando factores como la intensidad de la señal, la latencia y la estabilidad de las conexiones. 71 Tabla de enrutamiento Una tabla de enrutamiento es una estructura de datos mantenida por cada nodo en una red de comunicación que almacena información sobre las rutas disponibles para alcanzar otros nodos. Incluye detalles como la dirección del nodo destino, el número de saltos necesarios y el siguiente nodo en la ruta. Estas tablas son fundamentales para el funcionamiento eficiente de protocolos de enrutamiento en redes distribuidas. Fragmentación de datos La fragmentación de datos es el proceso de dividir una unidad de datos grande en partes más pequeñas para facilitar su transmisión a través de una red. Este enfoque es especialmente importante en redes como LoRa, donde las limitaciones del tamaño de los paquetes exigen que los datos se transmitan en fragmentos secuenciales que posteriormente se reensamblan en el destino. Handshake El handshake es un proceso de negociación entre dos nodos antes de establecer una conexión o transferencia de datos. Consiste en una serie de mensajes de sincronización que confirman que ambos nodos están listos para comunicarse y que las condiciones necesarias para la transmisión de datos están aseguradas. Este procedimiento garantiza una comunicación fiable y coordinada. 72 Referencias [1] Solé, J. M., Centelles, R. P., Freitag, F., & Meseguer, R. (2022). Implementation of a LoRa Mesh Library. IEEE Access,10, 113158-113171. https://doi.org/10.1109/ACCESS.2022.3217215 [2] Red inalámbrica mallada. (s. f.). En Wikipedia, la enciclopedia libre. Recuperado el 26 de septiembre de 2024, de https://es.wikipedia.org/wiki/Redinalmbricamallada [3] Asana, T. (2024, 19 febrero). Las 12 metodologías más populares para la gestión de proyectos [2024]. Asana. https://asana.com/es/resources/project-managementmethodologies [4] Wikipedia contributors. (2024, 27 agosto). LoRa. Wikipedia. https://en.wikipedia.org/wiki/LoRa [5] Wikipedia contributors. (2024a, marzo 16). Distance-vector routing protocol. Wikipedia. https://en.wikipedia.org/wiki/Distance-vectorroutingprotocol [6] Wikipedia contributors. (2024c, octubre 14). Routing protocol. Wikipedia. https://en.wikipedia.org/wiki/Routingprotocol [7] Wigmore, I. (2019, 1 marzo). Contingency budget (cost contingency). WhatIs. https://www.techtarget.com/whatis/definition/contingency [8] TTGO T-Beam ESP32 WiFi GPS NEO-6M LORA 900 MHz BricoGeek | BricoGeek.com. (s. f.). https://tienda.bricogeek.com/lora/1502-ttgo-t-beam-esp32-wifigps-neo-6m-lora-900-mhz.html [9] Treball de fi de grau. (s. f.). Facultat D’Informàtica de Barcelona. https://www.fib.upc.edu/ca/estudis/graus/grau-en-enginyeria-informatica/treballde-fi-de-grau [10] Digi International. (2024, 18 julio). Zigbee Wireless Standard. Digi. https://es.digi.com/solutions/by-technology/zigbee-wireless-standard [11] De Luis, E. R. (2019, 5 marzo). Zigbee y Z-Wave: qué son, en qué se diferencian y qué marcas de domótica son compatibles. Xataka. https://www.xataka.com/seleccion/zigbee-z-wave-que-que-se-diferencian-quemarcas-domotica-compatibles [12] colaboradores de Wikipedia. (2024b, junio 26). LoRaWAN. Wikipedia, la Enciclopedia Libre. https://es.wikipedia.org/wiki/LoRaWAN 73