Universidad Tecnológica de Pereira Especialización en Tecnologías de la Información y las Comunicaciones Red IoT inteligente multiprotocolo con protocolos de ciberseguridad Trabajo de grado presentado como requisito para optar al título de: Especialista en Tecnologías de la Información y las Comunicaciones Andrés Gabriel Cabrera Yonatan Betancur Obando Director:
Arley Bejarano Martinez Codirectora:
Yurley Tatiana Tovar Martinez Pereira
2026
Nota de Aceptación Firma del Presidente del jurado Firma del jurado 1 - Evaluador Firma del jurado 2 - Evaluador Firma del jurado 3 - Director Pereira, de de
Índice general Agradecimientos
13
Resumen
14
Abstract
17
Introducción general
20
1. Definición del problema
22
1.1. Antecedentes del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
1.2. Enunciado del problema
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2. Justificación
24
3. Objetivos del proyecto
26
3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2. Objetivos específicos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4. Marco de referencia
27
4.1. Marco teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.1.
Fundamentos conceptuales . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.2.
Modelos matemáticos y computacionales . . . . . . . . . . . . . . . .
36
4.1.3.
Tecnologías e instrumentos . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4.
Normativas y estándares . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.1.5.
Relación entre el marco teórico y la metodología . . . . . . . . . . . .
45
4.2. Marco conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.1.
Nodo IoT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.2.
Nodo raíz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.3.
Nodo padre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.4.
Nodo hijo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.5.
Topología tipo árbol
. . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.2.6.
Interoperabilidad multiprotocolo . . . . . . . . . . . . . . . . . . . . .
48
4.2.7.
Trama de comunicación
. . . . . . . . . . . . . . . . . . . . . . . . .
48
4.2.8.
EtherType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.2.9.
Resiliencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.2.10. Ciberseguridad en IoT . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.2.11. Integridad de la información . . . . . . . . . . . . . . . . . . . . . . .
49
4.2.12. RSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.3. Marco legal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.3.1.
Ley 1273 de 2009 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.3.2.
Ley 1581 de 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.3.3.
Uso del espectro radioeléctrico y bandas de uso libre
. . . . . . . . .
50
4.3.4.
Estándares y buenas prácticas técnicas . . . . . . . . . . . . . . . . .
51
5. Estado del arte
52
5.1. Delimitación y estrategia de búsqueda
. . . . . . . . . . . . . . . . . . . . .
52
5.2. Organización de la literatura por enfoques . . . . . . . . . . . . . . . . . . .
53
5.2.1.
Arquitecturas IoT y enfoques multiprotocolo . . . . . . . . . . . . . .
53
5.2.2.
Ciberseguridad, criptografía y control de acceso en IoT . . . . . . . .
5.2.3.
Resiliencia, tolerancia a fallos y eficiencia energética . . . . . . . . . .
56
5.3. Análisis crítico y comparativo . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.4. Vacíos identificados e implicaciones para la investigación
. . . . . . . . . . .
58
6. Diseño metodológico
60
6.1. Enfoque metodológico
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.2. Diseño de la arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . .
60
6.3. Implementación multiprotocolo y gestión de comunicación
. . . . . . . . . .
61
6.4. Integración de seguridad e integridad de la información . . . . . . . . . . . .
62
6.5. Gestión de recepción y recuperación del enlace . . . . . . . . . . . . . . . . .
63
6.6. Integración en el ciclo principal del nodo . . . . . . . . . . . . . . . . . . . .
64
6.7. Evaluación experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.8. Métricas de evaluación del sistema
. . . . . . . . . . . . . . . . . . . . . . .
65
6.9. Consideraciones metodológicas . . . . . . . . . . . . . . . . . . . . . . . . . .
66
7. Desarrollo e implementación
67
7.1. Diseño del hardware
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
7.1.1.
Componentes del banco de pruebas . . . . . . . . . . . . . . . . . . .
67
7.1.2.
Nodo ESP32-WROOM-32 . . . . . . . . . . . . . . . . . . . . . . . .
68
7.1.3.
Módulo LoRa SX1278 Ra-02 . . . . . . . . . . . . . . . . . . . . . . .
69
7.1.4.
Sensor DHT22
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
7.1.5.
Alimentación y entorno de pruebas . . . . . . . . . . . . . . . . . . .
71
7.1.6.
Topología física del banco de pruebas . . . . . . . . . . . . . . . . . .
71
7.1.7.
Conexión del módulo LoRa SX1278 al ESP32-WROOM-32 . . . . . .
73
7.2. Diseño del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
7.3. Lógica de descubrimiento y enrutamiento . . . . . . . . . . . . . . . . . . . .
75
7.3.1.
Inicialización y determinación del rol . . . . . . . . . . . . . . . . . .
7.3.2.
Descubrimiento y construcción de la tabla de vecinos . . . . . . . . .
76
7.3.3.
Selección del nodo padre y vinculación . . . . . . . . . . . . . . . . .
77
7.4. Integración de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
7.4.1.
Construcción de tramas y tipos de mensaje . . . . . . . . . . . . . . .
78
7.4.2.
Flujos de envío y recepción . . . . . . . . . . . . . . . . . . . . . . . .
79
7.4.3.
Supervisión bidireccional del enlace y recuperación
. . . . . . . . . .
79
7.5. Interoperabilidad entre protocolos . . . . . . . . . . . . . . . . . . . . . . . .
81
7.5.1.
Estándar de trama multiprotocolo . . . . . . . . . . . . . . . . . . . .
81
7.5.2.
Flujo de datos de aplicación: sensor DHT22 y reenvío hasta la raíz . .
82
8. Resultados del proyecto
83
8.1. Organización del análisis experimental
. . . . . . . . . . . . . . . . . . . . .
83
8.2. Pruebas de validación de transmisión de datos . . . . . . . . . . . . . . . . .
84
8.2.1.
Prueba por ESP-NOW con publicación MQTT
. . . . . . . . . . . .
85
8.2.2.
Prueba por LoRa con publicación MQTT . . . . . . . . . . . . . . . .
88
8.3. Pruebas de comunicación para las diferentes versiones del sistema (V1, V2, V3) 90
8.3.1.
Prueba con la versión 1 del código . . . . . . . . . . . . . . . . . . . .
90
8.3.2.
Prueba con la versión 2 del código . . . . . . . . . . . . . . . . . . . .
95
8.3.3.
Prueba con la versión 3 del código . . . . . . . . . . . . . . . . . . . .
98
8.3.4.
Comparación de versiones de prueba V1, V2 y V3 . . . . . . . . . . .
101
8.3.5.
Reconexión del nodo hijo tras caída total del nodo raíz . . . . . . . .
106
8.3.6.
Reelección de padre tras caída del nodo raíz . . . . . . . . . . . . . .
108
8.4. Pruebas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
118
8.5. Pruebas del funcionamiento de la red . . . . . . . . . . . . . . . . . . . . . .
121
8.5.1.
Prueba con red de seis nodos operando con ESP-NOW . . . . . . . .
121
8.5.2.
Prueba con red de seis nodos operando con ESP-NOW y LoRa . . . .
8.6. Discusión técnica de resultados
. . . . . . . . . . . . . . . . . . . . . . . . .
130
9. Conclusiones y recomendaciones
132
9.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
132
9.2. Recomendaciones y trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . .
Índice de figuras 4.1. Arquitectura IoT por capas utilizada como base conceptual del sistema. . . .
29
4.2. Topología jerárquica tipo árbol con niveles, relaciones padre-hijo, RSSI de
enlace, ruta hacia la raíz y nodo alterno para recuperación ante fallos. . . . .
33
4.3. Flujo de intercambio de claves, protección XOR del payload, transmisión y
validación CRC-16 entre nodos. . . . . . . . . . . . . . . . . . . . . . . . . .
38
7.1. Topología física del banco de pruebas: ocho nodos ESP32-WROOM-32 orga-
nizados en tres niveles jerárquicos, dos módulos LoRa SX1278 Ra-02, sensor DHT22 en el nodo hoja H3, alimentación desde power bank USB y dos PCs para monitoreo serie y broker MQTT. . . . . . . . . . . . . . . . . . . . . . .
72
7.2. Flujo general del software implementado en el nodo ESP32. El ciclo principal
integra la inicialización, el estado del nodo, el descubrimiento, la recepción y transmisión de mensajes, la selección de padre, la seguridad del enlace, la validación de tramas y la supervisión del enlace. . . . . . . . . . . . . . . . .
75
7.3. Flujo de inicialización y determinación del rol del nodo (Sección 1 del diagrama
general). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
7.4. Flujo de descubrimiento diferenciado: lado padre, encargado del envío de anun-
cios, y lado hijo, encargado de la escucha pasiva, evaluación de candidatos y solicitud de vinculación.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
7.5. Proceso de vinculación padre-hijo, respuesta con código de motivo ante recha-
zo, y establecimiento del enlace seguro mediante Diffie-Hellman. Secciones 1 y 2 del diagrama general. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6. Flujo de construcción de tramas: cabecera, BitArray de estado, payload por
EtherType, cálculo de CRC-16 y cifrado XOR con clave DH. Sección 2 del diagrama general. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
7.7. Flujos de envío (izquierda) y recepción (derecha) dentro del bucle principal
del nodo. Secciones 3 y 4 del diagrama general.
. . . . . . . . . . . . . . . .
80
7.8. Supervisión bidireccional del enlace: lado hijo hacia el padre y lado padre
hacia cada hijo, con lógica de recuperación mediante cambio de protocolo y reelección de padre. Sección 5 del diagrama general. . . . . . . . . . . . . . .
80
7.9. Flujo de datos de aplicación del sensor DHT22: lectura en el nodo hoja, cifrado
salto a salto en nodos intermedios con preservación de autoría, y entrega final en la raíz con publicación opcional vía MQTT. Sección 6 del diagrama general. 82
8.1. Publicación MQTT de los primeros mensajes recibidos durante la prueba de
transmisión por ESP-NOW. Se observa el inicio de la secuencia con las iteraciones 1, 2 y 3 correspondientes al protocolo ESP-NOW.
. . . . . . . . . . .
86
8.2. Publicación MQTT de mensajes intermedios de la prueba por ESP-NOW. Se
evidencian iteraciones consecutivas cercanas a la mitad de la prueba, lo cual permite validar la continuidad de la transmisión. . . . . . . . . . . . . . . . .
87
8.3. Publicación MQTT de los mensajes finales de la prueba por ESP-NOW. Se
observa la llegada de las iteraciones 498, 499 y 500, confirmando la finalización del envío configurado de 500 mensajes. . . . . . . . . . . . . . . . . . . . . .
87
8.4. Publicación MQTT de mensajes iniciales de la prueba de transmisión por
LoRa. Se observan las iteraciones 29, 40 y 41 correspondientes al protocolo LoRa y publicadas por el nodo raíz ESP_001. . . . . . . . . . . . . . . . . . .
89
8.5. Publicación MQTT de mensajes intermedios de la prueba por LoRa. Se visua-
lizan iteraciones cercanas a la mitad de la prueba, lo cual permite comprobar la continuidad de la transmisión durante el envío de los 500 mensajes. . . . .
89
8.6. Publicación MQTT de los mensajes finales de la prueba por LoRa. Se observan
las iteraciones 498, 499 y 500, confirmando que el sistema completó el envío configurado de 500 mensajes. . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
8.7. Inicio de la prueba individual con ESP-NOW y publicación de datos simulados
desde ESP_003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8. Inicio de la prueba individual con LoRa y publicación de datos desde ESP_002. 93
8.9. Evidencia de prueba simultánea ESP-NOW y LoRa . . . . . . . . . . . . . .
94
8.10. Publicaciones MQTT durante la prueba simultánea con ESP-NOW y LoRa
hacia el nodo raíz ESP_001.
. . . . . . . . . . . . . . . . . . . . . . . . . . .
94
8.11. Publicaciones MQTT recibidas durante la prueba multiprotocolo con ESP-NOW
y LoRa en la versión 2. Se observa una mayor cantidad de registros provenientes del nodo ESP_002, correspondientes a lecturas reales del sensor DHT22, junto con algunas publicaciones del nodo ESP_003 asociadas a datos de temperatura simulada. En ambos casos, los mensajes son enviados hacia el nodo raíz ESP_001, evidenciando la recepción de datos desde diferentes nodos de la red multiprotocolo.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
8.12. Evidencia de saltos de iteración detectados durante la prueba de la versión 2. Estos saltos permiten estimar los mensajes no publicados en el broker MQTT para LoRa y ESP-NOW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
8.13. Publicaciones MQTT iniciales del protocolo LoRa en la versión 3, correspon-
diente al nodo ESP_002. Se observan lecturas reales del sensor DHT22 publicadas por el nodo raíz ESP_001.
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
8.14. Publicaciones MQTT iniciales del protocolo ESP-NOW en la versión 3, co-
rrespondiente al nodo ESP_003. Se observan datos de temperatura simulada publicados en el tópico RED_MULTIPROTOCOLO_ESP. . . . . . . . . . . . . . . .
100
8.15. Topología utilizada para la comparación de las versiones V1, V2 y V3.
. . . .
102
8.16. Captura generada a partir del TXT interno del nodo raíz en V3. Se observan
fallos consecutivos de KeepAlive para ESP-NOW, descarte por agotamiento y posterior aparición de reconocimientos KA ACK.
. . . . . . . . . . . . . . .
105
8.17. Topología de prueba de reconexión nodo a nodo implementada en la versión V3. Se observa el enlace ESP-NOW entre el nodo raíz ESP_001 y el nodo hijo ESP_- 006, junto con la supervisión reforzada mediante doble notificación KeepAlive. Fuente: elaboración propia con apoyo de inteligencia artificial generativa, a partir de los registros experimentales y la configuración implementada en los nodos ESP32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.18. Topología de prueba de reconexión nodo a nodo implementada en la versión V3. Se observa la asociación inicial del nodo hijo ESP_003 con el nodo raíz ESP_-
001 mediante ESP-NOW, mientras que el nodo ESP_002 permanece como raíz
alternativa con disponibilidad de conexión Wi-Fi/MQTT hacia el broker. . .
109
8.19. Topología final de la prueba complementaria de reelección de padre. Tras la
pérdida del enlace con ESP_001, el nodo hijo ESP_003 descarta el padre anterior, limpia el vínculo existente, redescubre la red y selecciona a ESP_002 como nuevo padre, restableciendo la transmisión de datos hacia el broker MQTT. .
110
8.20. Registro del nodo hijo ESP_003 durante la asociación inicial con ESP_001. Se
observa la selección del padre, la solicitud de vinculación, el intercambio DH y el primer envío de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
114
8.21. Registro del nodo hijo ESP_003 durante la detección de pérdida de ESP_001. Se evidencian los fallos de KeepAlive, la declaración de padre perdido y la limpieza de la seguridad asociada al enlace anterior. . . . . . . . . . . . . . .
115
8.22. Registro del nodo hijo ESP_003 durante la selección de ESP_002 como nuevo
padre. Se observa la nueva solicitud de vinculación, el intercambio DH y la reanudación del envío de datos hacia el nuevo padre.
. . . . . . . . . . . . .
116
8.23. Registro de ESP_001 como primera raíz. Se confirma la recepción de datos
desde ESP_003 y la publicación MQTT de las iteraciones iniciales. . . . . . .
117
8.24. Registro de ESP_002 como nueva raíz después de la pérdida de ESP_001. Se
confirma la recepción de ESP_003, el nuevo intercambio DH y la publicación MQTT de las iteraciones 9, 10 y 11. . . . . . . . . . . . . . . . . . . . . . . .
118
8.25. Evidencia del intercambio de clave Diffie-Hellman y almacenamiento de la
clave compartida en el registro de vecinos.
. . . . . . . . . . . . . . . . . . .
120
8.26. Topología de prueba con seis nodos configurados con capacidad máxima de
dos hijos por nodo mediante max_hijos = 2. Esta configuración permitió la formación de una topología jerárquica, donde el nodo ESP_001 operó como nodo raíz con conexión a Internet y publicación MQTT, mientras que los nodos intermedios permitieron el reenvío de datos generados por los nodos finales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.27. Publicaciones MQTT recibidas durante la primera prueba con seis nodos usan-
do ESP-NOW. Se observan registros provenientes de los nodos ESP_003, ESP_004 y ESP_006, enviados hacia el nodo raíz ESP_001. . . . . . . . . . . . . . . . .
123
8.28. Continuación de las publicaciones MQTT recibidas durante la primera prueba
con seis nodos usando ESP-NOW. Se evidencia la trazabilidad de los mensajes mediante campos como iteracion, saltos, id_nodo, origen_sensor y nodo_raiz.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
123
8.29. Topología identificada en la prueba con seis nodos y operación multiprotocolo
con LoRa habilitado. En esta configuración, el nodo ESP_001 actúa como nodo raíz y publica la información hacia el broker MQTT, mientras que ESP_002 y ESP_005 operan como nodos padre intermedios. Los nodos ESP_003, ESP_004 y ESP_006 se configuraron con max_hijos = 0, por lo que funcionan únicamente como nodos finales de generación de datos, favoreciendo una transmisión más estable y reduciendo la carga de reenvío en los sensores. . . . . . . . . . . . .
127
8.30. Publicaciones MQTT recibidas durante la segunda prueba con seis nodos en
operación multiprotocolo con LoRa habilitado. Se observan registros enviados hacia el nodo raíz ESP_001 desde diferentes nodos sensores de la red.
. . . .
128
8.31. Continuación de las publicaciones MQTT recibidas durante la segunda prueba
multiprotocolo. La evidencia muestra la recepción de datos de aplicación con identificación del nodo origen, iteración, saltos y nodo raíz. . . . . . . . . . .
Índice de cuadros 4.1. Comparación de protocolos de comunicación inalámbrica para IoT . . . . . .
31
4.2. Estructura de trama del sistema multiprotocolo
. . . . . . . . . . . . . . . .
31
4.3. Comparación de topologías de red para IoT
. . . . . . . . . . . . . . . . . .
32
4.4. Variables del modelo de selección de nodo padre implementado . . . . . . . .
41
4.5. Especificaciones técnicas del ESP32 relevantes para IoT . . . . . . . . . . . .
42
4.6. Correspondencia entre el marco teórico y las fases metodológicas . . . . . . .
46
7.1. Inventario de hardware del banco de pruebas . . . . . . . . . . . . . . . . . .
68
7.2. Especificaciones técnicas del ESP32-WROOM-32 relevantes para las pruebas
69
7.3. Parámetros de configuración del módulo SX1278 Ra-02 en las pruebas . . . .
70
7.4. Especificaciones del sensor DHT22 en las pruebas . . . . . . . . . . . . . . .
71
7.5. Mapeado de pines SPI entre el ESP32-WROOM-32 y el módulo SX1278 Ra-02 73
7.6. Estructura modular del sistema . . . . . . . . . . . . . . . . . . . . . . . . .
74
7.7. EtherTypes definidos en el sistema
. . . . . . . . . . . . . . . . . . . . . . .
79
7.8. Características operativas de los protocolos implementados . . . . . . . . . .
81
8.1. Criterio de tratamiento estadístico de los escenarios experimentales
. . . . .
84
8.2. Estadística descriptiva de efectividad en pruebas simultáneas por versión . .
84
8.3. Resumen cuantitativo de la primera prueba con la versión 1 del código
. . .
91
8.4. Tiempos promedio de publicación MQTT en la primera prueba V1 . . . . . .
8.5. Principales pérdidas de tramas detectadas en la primera prueba V1
. . . . .
92
8.6. Resumen cuantitativo de recepción y publicación MQTT en la versión 2 . . .
95
8.7. Resumen temporal de publicaciones MQTT en la versión 2 . . . . . . . . . .
96
8.8. Principales saltos de iteración detectados en la versión 2
. . . . . . . . . . .
96
8.9. Resumen cuantitativo de recepción y publicación MQTT en la versión 3 . . .
98
8.10. Resumen temporal de publicaciones MQTT en la versión 3 . . . . . . . . . .
99
8.11. Principales saltos de iteración identificados durante la prueba de la versión 3.
100
8.12. Principales interrupciones de publicación detectadas en V2
. . . . . . . . . .
103
8.13. Principales interrupciones de publicación detectadas en V3
. . . . . . . . . .
103
8.14. Eventos de pérdida y recuperación observados en el enlace ESP-NOW durante
V3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
104
8.15. Eventos principales de la prueba complementaria de reelección de padre . . .
111
8.16. Resumen cuantitativo de la prueba complementaria de reelección de padre
.
112
8.17. Indicadores técnicos observados durante la reelección de padre . . . . . . . .
113
8.18. Resumen de la topología observada en la primera prueba con seis nodos usando
ESP-NOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
124
8.19. Resumen cuantitativo de publicaciones MQTT en la primera prueba con seis
nodos usando ESP-NOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
124
8.20. Tiempo de publicación observado por nodo en la primera prueba usando ESP-NOW124
8.21. Principal salto de iteración detectado en la primera prueba con seis nodos
usando ESP-NOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agradecimientos Agradecemos en primer lugar a Dios por brindarnos la fortaleza, la constancia y la sabiduría necesarias para culminar esta etapa académica.
Expresamos nuestro más sincero agradecimiento a nuestras familias por su apoyo incondicional, comprensión y motivación a lo largo de este proceso, siendo un pilar fundamental en el desarrollo de este trabajo.
De manera especial, agradecemos a nuestro director de trabajo de grado, Arley Bejarano Martínez, y a nuestra codirectora, Yurley Tatiana Tovar Martínez, por su orientación, acompañamiento y valiosos aportes, los cuales fueron fundamentales para la estructuración y desarrollo de esta investigación.
Asimismo, agradecemos a la Universidad Tecnológica de Pereira y a todos los docentes de la Especialización en Tecnologías de la Información y las Comunicaciones, quienes contribuyeron con su conocimiento y experiencia a nuestra formación profesional. Finalmente, agradecemos a todas aquellas personas que, de una u otra forma, hicieron posible la realización de este trabajo.
Resumen El presente trabajo tuvo como objetivo diseñar, implementar y validar una arquitectura IoT inteligente multiprotocolo basada en nodos ESP32, orientada a mejorar la interoperabilidad, la seguridad y la resiliencia en redes desplegadas en entornos con infraestructura limitada. La problemática abordada se relaciona con las limitaciones que presentan muchas soluciones IoT al depender de conectividad permanente, gateways centralizados o protocolos únicos de comunicación, lo cual reduce la escalabilidad, aumenta la vulnerabilidad ante fallos y dificulta su aplicación en escenarios rurales, industriales o de baja cobertura. Para dar respuesta a esta necesidad, se desarrolló una arquitectura distribuida organizada mediante una topología jerárquica tipo árbol, en la cual los nodos pueden descubrir vecinos, seleccionar un nodo padre, establecer rutas de comunicación hacia un nodo raíz y mantener la supervisión del enlace mediante mensajes de control. La solución integra tecnologías de comunicación como ESP-NOW y LoRa para la transmisión de información entre nodos, Wi-Fi para la conectividad del nodo raíz y MQTT para la publicación de los datos recibidos hacia un broker externo. De esta manera, se validó una red multiprotocolo capaz de combinar comunicación local entre nodos con publicación de datos hacia servicios externos de visualización o procesamiento.
La implementación fue desarrollada en MicroPython y organizada en módulos funcionales para configuración, estado del nodo, inicialización de red, construcción de tramas, seguridad, enrutamiento, transmisión, recepción, supervisión mediante KeepAlive y operación principal. Además, se implementó una estructura de trama propia basada en EtherType, número de secuencia, bitarray de estado, identificadores de origen y destino, payload y CRC16-CCITT para la verificación de integridad de los mensajes transmitidos.
Desde el punto de vista de seguridad, se incorporó un mecanismo de intercambio de claves mediante Diffie-Hellman, protección del payload mediante XOR con clave derivada y verificación de integridad mediante CRC16-CCITT. Esta decisión se tomó considerando las restricciones de memoria, procesamiento y tiempo de ciclo del ESP32 al ejecutar simultáneamente tareas
de descubrimiento, comunicación multiprotocolo, enrutamiento, supervisión, recepción, retransmisión y publicación de datos. Como evidencia del proceso de seguridad, se verificó la generación de claves compartidas durante la vinculación entre nodos y su almacenamiento en el registro de vecinos.
La evaluación experimental se realizó mediante diferentes versiones del código y escenarios de prueba. Se analizaron transmisiones individuales por protocolo, pruebas comparativas entre ESP-NOW y LoRa, pruebas con seis nodos, pérdida del nodo raíz, reconexión del nodo hijo, reelección de padre, eventos de supervisión mediante KeepAlive y publicaciones MQTT. Para el análisis se definieron métricas como cantidad de publicaciones MQTT, iteraciones únicas recibidas, efectividad de recepción, pérdida estimada, saltos de iteración, tiempo sin publicación, trazabilidad, conectividad, interoperabilidad y recuperación ante fallos. Los resultados evidenciaron que la arquitectura logró transmitir, recibir y publicar datos mediante diferentes protocolos de comunicación. En una de las pruebas de transmisión inicial se configuraron 500 mensajes por protocolo, obteniendo 409 iteraciones únicas recibidas mediante ESP-NOW, con una efectividad aproximada del 81,80 %, y 415 iteraciones únicas recibidas mediante LoRa, con una efectividad aproximada del 83,00 %. Estos resultados permitieron validar el funcionamiento inicial de la comunicación y la publicación MQTT, aunque también evidenciaron pérdidas parciales de información durante la transmisión. La comparación entre versiones permitió identificar mejoras y diferencias importantes en el comportamiento de la red. En la versión V3, LoRa presentó el mejor desempeño global, alcanzando una efectividad aproximada del 97,80 %, mientras que ESP-NOW presentó una efectividad aproximada del 60,60 % bajo las condiciones evaluadas. El análisis de saltos de iteración mostró que LoRa presentó interrupciones menores, generalmente de una iteración, mientras que ESP-NOW registró interrupciones más amplias en algunos tramos. Esto evidenció que el desempeño de cada protocolo depende de la configuración del código, los tiempos de escucha, la carga de procesamiento y las condiciones del enlace. También se observaron eventos de pérdida temporal de enlace y posterior recuperación mediante mensajes KeepAlive y KeepAlive ACK. En los registros se identificaron fallos de comunicación con el nodo padre, incrementos en los contadores de fallo, limpieza de información asociada al enlace anterior y reconexiones posteriores. En las pruebas de reelección de padre, el nodo hijo fue capaz de detectar la pérdida del nodo raíz inicial, descartar el vínculo previo, limpiar la información de seguridad y asociarse posteriormente a un nuevo nodo raíz disponible. Este comportamiento demuestra que el sistema no detiene inmediatamente su operación ante una interrupción, sino que mantiene mecanismos de supervisión, descubrimiento y re-
cuperación.
Las pruebas con seis nodos permitieron comprobar que la capacidad máxima de hijos configurada influye directamente en la topología final de la red. Cuando los nodos tenían una capacidad máxima de dos hijos, la red pudo organizarse de forma jerárquica, distribuyendo las asociaciones entre diferentes nodos padres. En cambio, al modificar la capacidad de hijos o presentarse pérdidas de enlace, la topología cambió de acuerdo con la disponibilidad de nodos padres, las condiciones de comunicación y el protocolo utilizado. Aunque durante las pruebas se evidenció cierta pérdida de información, esta condición se relaciona principalmente con las limitaciones del microcontrolador ESP32 y del entorno MicroPython. El dispositivo debe ejecutar simultáneamente tareas de descubrimiento, recepción, transmisión, supervisión, seguridad, manejo de colas, publicación MQTT y registro de eventos. Además, el almacenamiento de archivos .txt extensos con información de prueba puede ocupar rápidamente la memoria disponible, afectando la estabilidad del sistema. Por tanto, las pérdidas observadas no invalidan la arquitectura, sino que evidencian restricciones propias del hardware utilizado.
En conclusión, el sistema desarrollado demuestra la viabilidad de implementar una red IoT multiprotocolo sobre nodos ESP32, capaz de operar de forma distribuida, segura, trazable y adaptable. La propuesta permitió integrar ESP-NOW, LoRa, Wi-Fi y MQTT bajo una misma lógica de operación, conservar la trazabilidad de los mensajes mediante campos como nodo origen, nodo raíz, protocolo, saltos e iteración, publicar información hacia servicios externos y ejecutar procesos de reconexión ante fallos. Aunque la efectividad puede variar según el protocolo, la configuración y las condiciones de conexión, la arquitectura constituye una alternativa funcional y de bajo costo para escenarios donde se requiere comunicación flexible, integración multiprotocolo y continuidad operativa sin depender completamente de infraestructura centralizada.
Palabras clave: IoT, ESP32, red multiprotocolo, ESP-NOW, LoRa, Wi-Fi, MQTT, Diffie- Hellman, XOR, CRC16-CCITT, KeepAlive, MicroPython, resiliencia.
Abstract This work aimed to design, implement, and validate an intelligent multiprotocol IoT architecture based on ESP32 nodes, focused on improving interoperability, security, and resilience in networks deployed in environments with limited infrastructure. The addressed problem is related to the limitations of many IoT solutions that depend on permanent connectivity, centralized gateways, or a single communication protocol, which reduces scalability, increases vulnerability to failures, and limits their application in rural, industrial, or low-coverage scenarios.
To address this need, a distributed architecture organized through a hierarchical tree topology was developed. In this architecture, nodes are able to discover neighbors, select a parent node, establish communication routes toward a root node, and maintain link supervision through control messages. The solution integrates ESP-NOW and LoRa as wireless communication technologies between nodes, Wi-Fi for root node connectivity, and MQTT for publishing the received data to an external broker. In this way, a multiprotocol network capable of combining local node-to-node communication with data publication to external visualization or processing services was validated.
The implementation was developed in MicroPython and organized into functional modules for configuration, node state, network initialization, frame construction, security, routing, transmission, reception, KeepAlive supervision, and main operation. In addition, a custom frame structure based on EtherType, sequence number, state bitarray, source and destination identifiers, payload, and CRC16-CCITT was implemented to verify the integrity of transmitted messages.
From the security perspective, a key exchange mechanism based on Diffie-Hellman, payload protection through XOR with a derived key, and integrity verification through CRC16- CCITT were incorporated. This decision was made considering the memory, processing, and cycle-time limitations of the ESP32 while simultaneously executing discovery, multiprotocol communication, routing, supervision, reception, retransmission, and data publication tasks.
As evidence of the security process, the generation of shared keys during node association and their storage in the neighbor registry were verified.
The experimental evaluation was carried out through different code versions and test scenarios. Individual protocol transmissions, comparative tests between ESP-NOW and LoRa, six-node tests, root node loss, child node reconnection, parent reselection, KeepAlive supervision events, and MQTT publications were analyzed. Metrics such as number of MQTT publications, unique received iterations, reception effectiveness, estimated loss, iteration jumps, time without publication, traceability, connectivity, interoperability, and failure recovery were defined.
The results showed that the architecture was able to transmit, receive, and publish data using different communication protocols. In one of the initial transmission tests, 500 messages were configured per protocol, obtaining 409 unique received iterations through ESP-NOW, with an approximate effectiveness of 81.80 %, and 415 unique received iterations through LoRa, with an approximate effectiveness of 83.00 %. These results allowed the initial operation of communication and MQTT publication to be validated, although partial information losses during transmission were also observed.
The comparison between code versions made it possible to identify relevant improvements and differences in network behavior. In version V3, LoRa showed the best overall performance, reaching an approximate effectiveness of 97.80 %, while ESP-NOW reached an approximate effectiveness of 60.60 % under the evaluated conditions. The analysis of iteration jumps showed that LoRa presented smaller interruptions, generally of one iteration, whereas ESP- NOW showed wider interruptions in some sections. This demonstrated that the performance of each protocol depends on code configuration, listening times, processing load, and link conditions.
Temporary link loss and subsequent recovery events were also observed through KeepAlive and KeepAlive ACK messages. The logs showed communication failures with the parent node, increments in failure counters, cleaning of information associated with the previous link, and later reconnections. In the parent reselection tests, the child node was able to detect the loss of the initial root node, discard the previous link, clean the security information, and subsequently associate with a new available root node. This behavior demonstrates that the system does not immediately stop its operation after an interruption, but instead maintains supervision, discovery, and recovery mechanisms.
The six-node tests made it possible to verify that the configured maximum child capacity directly influences the final network topology. When nodes had a maximum capacity of two
children, the network was able to organize itself hierarchically by distributing associations among different parent nodes. In contrast, when the child capacity was modified or link losses occurred, the topology changed according to parent node availability, communication conditions, and the protocol used.
Although partial information loss was observed during the tests, this condition is mainly related to the limitations of the ESP32 microcontroller and the MicroPython environment. The device must simultaneously execute discovery, reception, transmission, supervision, security, queue management, MQTT publication, and event logging tasks. In addition, storing extensive .txt test files can quickly consume the available memory, affecting system stability. Therefore, the observed losses do not invalidate the architecture, but rather show the hardware constraints of the implemented prototype.
In conclusion, the developed system demonstrates the feasibility of implementing a multiprotocol IoT network based on ESP32 nodes, capable of operating in a distributed, secure, traceable, and adaptable manner. The proposal made it possible to integrate ESP-NOW, LoRa, Wi-Fi, and MQTT under a common operating logic, preserve message traceability through fields such as source node, root node, protocol, hop count, and iteration number, publish information to external services, and execute reconnection processes after failures. Although effectiveness may vary depending on the protocol, configuration, and connection conditions, the architecture represents a functional and low-cost alternative for scenarios requiring flexible communication, multiprotocol integration, and operational continuity without fully depending on centralized infrastructure.
Keywords: IoT, ESP32, multiprotocol network, ESP-NOW, LoRa, Wi-Fi, MQTT, Diffie- Hellman, XOR, CRC16-CCITT, KeepAlive, MicroPython, resilience.
Introducción El Internet de las Cosas (IoT) se ha consolidado como una de las principales tecnologías habilitadoras de la transformación digital, permitiendo la interconexión de dispositivos, la automatización de procesos y la generación de información en tiempo real en sectores como la industria, la agricultura, la salud y las ciudades inteligentes [1, 8]. No obstante, en contextos como el colombiano, la implementación de soluciones IoT enfrenta importantes desafíos asociados a la infraestructura tecnológica, la conectividad y la seguridad de la información [6, 12]. En particular, la limitada cobertura de redes en zonas rurales y la dependencia de arquitecturas centralizadas dificultan el despliegue de sistemas robustos y resilientes.
Uno de los principales retos en el diseño de redes IoT radica en la interoperabilidad entre diferentes tecnologías de comunicación. Protocolos como Wi-Fi, ESP-NOW, LoRa y MQTT presentan diferencias significativas en términos de alcance, consumo energético y complejidad de implementación [13, 25]. La integración de estos protocolos suele requerir el uso de gateways centralizados, lo que introduce puntos únicos de fallo y limita la escalabilidad del sistema.
Adicionalmente, la seguridad en redes IoT representa un desafío significativo, especialmente en dispositivos con recursos limitados como el ESP32. La implementación de mecanismos de cifrado robustos puede afectar el consumo energético y el rendimiento del sistema, lo que en muchos casos conduce a configuraciones de seguridad debilitadas [1, 11]. En este contexto, surge la necesidad de diseñar arquitecturas distribuidas que permitan integrar múltiples protocolos de comunicación, reduzcan la dependencia de infraestructura centralizada y garanticen mecanismos de seguridad adecuados. Asimismo, estas arquitecturas deben ser capaces de adaptarse dinámicamente a fallos en la red mediante estrategias de autoorganización y recuperación [15, 17, 41].
El presente trabajo aborda esta problemática mediante el diseño e implementación de una
arquitectura IoT multiprotocolo basada en nodos ESP32, organizada en una topología jerárquica tipo árbol. En esta propuesta, cada nodo es capaz de descubrir vecinos, seleccionar un nodo padre, establecer rutas de comunicación y mantener la conectividad mediante mecanismos de supervisión y recuperación.
La arquitectura incorpora un modelo de comunicación basado en tramas con identificación mediante EtherType, así como mecanismos de seguridad fundamentados en el intercambio de claves mediante Diffie-Hellman y protección ligera del payload mediante XOR con clave compartida derivada. Esta decisión se adoptó porque el ESP32 ejecuta simultáneamente descubrimiento, enrutamiento, supervisión, recepción multiprotocolo, cola de transmisión y publicación hacia servicios externos; por tanto, se priorizó un mecanismo liviano y consistente con las restricciones de memoria, procesamiento y tiempo de ciclo del prototipo. De igual forma, se implementan mecanismos de validación mediante CRC16-CCITT y control de errores que contribuyen a la confiabilidad del sistema.
Finalmente, el documento se organiza de la siguiente manera: en el Capítulo 1 se presenta la definición del problema; en el Capítulo 2 la justificación; en el Capítulo 3 los objetivos del proyecto; en el Capítulo 4 el marco de referencia; en el Capítulo 5 el estado del arte; en el Capítulo 6 el diseño metodológico; en el Capítulo 7 el desarrollo e implementación; en el Capítulo 8 los resultados; y en el Capítulo 9 las conclusiones y recomendaciones. Con este trabajo se busca contribuir al desarrollo de soluciones IoT más accesibles, seguras y adaptables a entornos con limitaciones de infraestructura, aportando una arquitectura que combine interoperabilidad multiprotocolo, ciberseguridad y resiliencia en dispositivos de bajo costo.
Capítulo 1 Definición del problema
1.1.
Antecedentes del problema El Internet de las Cosas (IoT) constituye un componente fundamental en la transformación digital, al posibilitar la interconexión de dispositivos, la automatización de procesos y la generación de información en tiempo real en sectores estratégicos como la industria, la agricultura, la salud y las ciudades inteligentes. No obstante, su adopción en Colombia se ve limitada por problemas estructurales asociados a la infraestructura tecnológica, la conectividad y la seguridad de la información [6, 12]. En particular, la baja disponibilidad de redes estables en zonas rurales, la heterogeneidad de los entornos de despliegue y la falta de estandarización tecnológica dificultan la implementación de soluciones IoT robustas, escalables y adaptables a las condiciones reales del territorio.
A esta problemática se suma la fragmentación de protocolos de comunicación presentes en el ecosistema IoT. Tecnologías como Wi-Fi, ESP-NOW, LoRa y MQTT presentan diferencias significativas en alcance, consumo energético, velocidad de transmisión y complejidad de integración, lo que genera serios problemas de interoperabilidad [13, 25]. En muchos casos, esta diversidad obliga a recurrir a arquitecturas centralizadas basadas en gateways o nodos coordinadores que actúan como intermediarios entre protocolos, aumentando los costos de implementación, la dependencia de infraestructura adicional y la vulnerabilidad del sistema ante fallos, al introducir puntos únicos de fallo.
Desde la perspectiva de la seguridad, aunque plataformas como el ESP32 incorporan capacidades criptográficas avanzadas, su implementación en entornos reales continúa siendo un desafío. Las restricciones de memoria, procesamiento y consumo energético propias de este tipo de hardware hacen que, en la práctica, muchos sistemas adopten configuraciones de seguridad
reducidas o incompletas, comprometiendo la confidencialidad, integridad y disponibilidad de la información [1, 11]. Esto resulta especialmente crítico en arquitecturas distribuidas, donde la comunicación entre nodos debe mantenerse protegida sin deteriorar significativamente el rendimiento general de la red.
Por otra parte, las arquitecturas tradicionales suelen depender de conectividad continua, infraestructura estable o nodos centrales con capacidad permanente de coordinación. Esta condición resulta problemática en contextos donde la conectividad es intermitente, la cobertura es limitada o la red debe operar de manera autónoma durante intervalos prolongados. Aunque la literatura reporta avances en redes malladas, sistemas auto-recuperables y enfoques de tolerancia a fallos, estas propuestas generalmente abordan de forma parcial el problema, priorizando la conectividad, la seguridad o la resiliencia por separado, pero sin integrarlas de manera conjunta en plataformas de bajo costo y recursos restringidos como el
ESP32 [15, 17, 41].
1.2.
Enunciado del problema En este contexto, se identifica la necesidad de diseñar una arquitectura IoT distribuida capaz de integrar múltiples protocolos de comunicación, operar sobre hardware de bajo costo, incorporar mecanismos de seguridad adecuados y mantener la continuidad del servicio ante fallos o cambios en las condiciones del entorno. En consecuencia, la presente investigación se orienta a resolver la siguiente pregunta: ¿qué características debe incorporar una arquitectura multiprotocolo basada en nodos ESP32 para optimizar la interoperabilidad, la seguridad y la resiliencia en redes IoT desplegadas en contextos colombianos con infraestructura limitada?
Capítulo 2 Justificación La presente investigación se justifica por la necesidad de desarrollar soluciones IoT que respondan de manera efectiva a las condiciones técnicas, económicas y operativas de contextos con infraestructura limitada, como ocurre en diversos entornos colombianos [6, 12]. Aunque el Internet de las Cosas ha demostrado un alto potencial para transformar procesos de monitoreo, automatización y toma de decisiones en tiempo real, su implementación práctica aún enfrenta barreras importantes relacionadas con la conectividad, la interoperabilidad entre tecnologías y la seguridad de la información. Estas limitaciones reducen la viabilidad de muchas propuestas en escenarios reales, especialmente cuando se requiere operar con hardware de bajo costo y en entornos donde la cobertura de red no es continua ni homogénea. Desde el punto de vista tecnológico, el proyecto aborda una problemática actual y relevante: la necesidad de articular en una misma arquitectura múltiples protocolos de comunicación, mecanismos de seguridad y capacidades de recuperación ante fallos, sin depender de infraestructura centralizada ni de dispositivos de alto costo. En este sentido, la investigación aporta al desarrollo de arquitecturas IoT distribuidas capaces de adaptarse dinámicamente a cambios en el entorno, seleccionar rutas de comunicación adecuadas y mantener la continuidad operativa aun cuando existan restricciones de red o degradación del enlace. Este enfoque resulta especialmente pertinente en aplicaciones desplegadas en zonas rurales, instalaciones industriales dispersas, sistemas de monitoreo ambiental y escenarios donde la robustez de la red es un requisito crítico.
En el plano científico y académico, el trabajo contribuye a integrar tres dimensiones que con frecuencia son estudiadas de forma separada en la literatura: la interoperabilidad multiprotocolo, la ciberseguridad en dispositivos embebidos y la resiliencia de redes distribuidas. Mientras muchas propuestas se concentran exclusivamente en el desempeño de un protocolo, en el cifrado de la información o en la recuperación ante fallos, esta investigación plantea una
aproximación integral orientada a combinar estos elementos dentro de una misma arquitectura funcional. Por tanto, el estudio no solo tiene un valor aplicado, sino también un aporte conceptual al demostrar cómo estos componentes pueden coexistir de manera coherente en una solución basada en nodos ESP32.
Desde la perspectiva práctica, la elección del ESP32 como plataforma de desarrollo fortalece la viabilidad del proyecto, ya que se trata de un dispositivo ampliamente disponible, de bajo costo, con capacidades de procesamiento suficientes y soporte para múltiples interfaces de comunicación. Esto hace posible la construcción de un prototipo funcional replicable y escalable, lo cual incrementa la pertinencia de la investigación en contextos educativos, empresariales e incluso comunitarios. Asimismo, la implementación sobre una plataforma accesible favorece la transferencia del conocimiento generado hacia nuevos desarrollos, pruebas de laboratorio o aplicaciones reales con recursos restringidos.
La investigación también se justifica por su potencial impacto en sectores estratégicos. Una arquitectura IoT segura, interoperable y resiliente puede ser aplicada en monitoreo agrícola, automatización de procesos, supervisión de variables ambientales, gestión energética y sistemas de alerta, entre otros. En todos estos escenarios, la capacidad de los nodos para organizarse, proteger su comunicación y recuperarse ante fallos representa una ventaja significativa frente a soluciones tradicionales dependientes de conectividad permanente o de nodos centrales. De esta manera, el proyecto no solo responde a una necesidad técnica, sino que también contribuye al desarrollo de soluciones más accesibles y adaptadas a las condiciones reales del entorno.
Finalmente, esta investigación se justifica porque permite validar experimentalmente una propuesta concreta que articula teoría, diseño e implementación. Más allá del análisis conceptual, el trabajo conduce a la construcción de un prototipo funcional con el cual es posible evaluar de manera integrada la interoperabilidad, la seguridad y la resiliencia de la arquitectura propuesta. Además, la red se concibe como una arquitectura escalable: dependiendo del contexto específico de despliegue, puede optimizarse la cantidad de nodos, el número de hijos por padre, los protocolos habilitados, los intervalos de supervisión y la distribución de enlaces LoRa o ESP-NOW. Esto otorga solidez metodológica al estudio y refuerza su relevancia, al demostrar que la propuesta no se limita a un planteamiento teórico, sino que se materializa en una solución verificable, adaptable y aplicable.
Capítulo 3 Objetivos del proyecto
3.1.
Objetivo general Diseñar e implementar una arquitectura multiprotocolo para redes IoT basadas en nodos ESP32, integrando mecanismos de seguridad que permitan mejorar la interoperabilidad, la seguridad y la resiliencia en entornos con infraestructura limitada.
3.2.
Objetivos específicos Analizar las limitaciones técnicas, de conectividad y de seguridad presentes en redes IoT multiprotocolo desplegadas en contextos con infraestructura limitada. Diseñar una arquitectura multiprotocolo basada en nodos ESP32 que integre diferentes tecnologías de comunicación y mecanismos de seguridad adecuados para entornos de recursos restringidos.
Implementar un prototipo funcional que permita validar la arquitectura propuesta mediante la integración de los módulos de comunicación, enrutamiento, seguridad y recuperación ante fallos.
Evaluar el comportamiento del sistema en términos de interoperabilidad, seguridad y resiliencia, considerando su capacidad de conectividad, protección de la información y recuperación ante fallos.
Capítulo 4 Marco de referencia
4.1.
Marco teórico El presente marco teórico establece los fundamentos conceptuales, modelos matemáticos y tecnológicos que sustentan el diseño e implementación de la arquitectura IoT multiprotocolo propuesta. A diferencia del estado del arte, esta sección se centra en explicar los principios de funcionamiento de las tecnologías utilizadas, su relación con el problema de investigación y su aplicación concreta dentro del sistema desarrollado. La organización sigue una progresión lógica: primero se presentan los fundamentos conceptuales generales, luego los modelos matemáticos que gobiernan el comportamiento del sistema, y finalmente las tecnologías e instrumentos empleados en la implementación.
4.1.1.
Fundamentos conceptuales Internet de las Cosas (IoT) El Internet de las Cosas (IoT) se define como un ecosistema de dispositivos físicos interconectados capaces de capturar, procesar e intercambiar información a través de redes de comunicación [43, 44]. Este paradigma habilita la integración de sensores, actuadores y sistemas de procesamiento en entornos distribuidos, facilitando la automatización y el análisis de datos en tiempo real en dominios tan diversos como la industria, la agricultura de precisión, la salud y las ciudades inteligentes [8].
Evolución y contexto del IoT El concepto de IoT tiene sus raíces en las tecnologías de identificación por radiofrecuencia (RFID) y los sistemas de comunicación máquina a máquina
(M2M) desarrollados durante los años noventa [8, 47]. Con la masificación de los microcontroladores de bajo costo, la disponibilidad de conectividad inalámbrica y la maduración de plataformas en la nube, el paradigma evolucionó hacia ecosistemas donde miles de millones de dispositivos heterogéneos comparten información de forma autónoma [2, 43]. En el contexto colombiano, la adopción del IoT enfrenta desafíos particulares asociados a la brecha de infraestructura tecnológica entre zonas urbanas y rurales, la falta de estandarización de plataformas y las limitaciones presupuestarias para el despliegue de soluciones a escala [6, 12]. Estos factores hacen especialmente relevante el desarrollo de arquitecturas distribuidas basadas en hardware de bajo costo que minimicen la dependencia de infraestructura centralizada.
Arquitectura por capas del IoT Desde una perspectiva técnica, el IoT se estructura en capas funcionales que permiten modularizar el sistema y separar responsabilidades. El modelo más ampliamente referenciado en la literatura distingue cuatro capas principales [8, 44, 47]: Capa de percepción: comprende los dispositivos físicos que interactúan con el entorno, tales como sensores de temperatura, humedad, presión, gas y actuadores mecánicos o eléctricos. Es la capa responsable de la adquisición de datos del mundo físico. Capa de red: agrupa los protocolos y tecnologías de comunicación que permiten el intercambio de información entre dispositivos. Incluye tecnologías de corto alcance como Wi-Fi y ESP-NOW, así como tecnologías de largo alcance como LoRa y NB-IoT. Capa de procesamiento: se encarga de la gestión, análisis y transformación de los datos recolectados. Puede ejecutarse en el propio dispositivo (edge computing), en nodos intermedios (fog computing) o en servidores remotos (cloud computing). Capa de aplicación: corresponde a la interfaz final mediante la cual los usuarios o sistemas externos consumen la información o emiten comandos sobre el sistema.
Capa de Aplicación Capa de Procesamiento Capa de Red (Wi-Fi, ESP-NOW, LoRa, MQTT) Capa de Percepción (Sensores / Actuadores) Figura 4.1: Arquitectura IoT por capas utilizada como base conceptual del sistema. En este trabajo, el enfoque principal se concentra en la capa de red, donde se aborda el problema de interoperabilidad entre múltiples protocolos y la gestión distribuida de la comunicación entre nodos. No obstante, los mecanismos de seguridad implementados operan de manera transversal sobre esta capa, afectando tanto la transmisión de datos como el proceso de establecimiento de enlace.
Paradigmas de procesamiento distribuido El procesamiento en arquitecturas IoT puede ubicarse en diferentes puntos del sistema, lo que da lugar a tres paradigmas complementarios [47]:
Cloud computing: el procesamiento y almacenamiento se realizan en servidores remotos. Ofrece alta capacidad de cómputo y almacenamiento, pero introduce latencias elevadas y dependencia de conectividad continua.
Fog computing: el procesamiento se distribuye en nodos intermedios (pasarelas o gateways) ubicados entre los dispositivos y la nube. Reduce la latencia y la carga de tráfico hacia la nube, pero mantiene cierta dependencia de infraestructura centralizada. Edge computing: el procesamiento se realiza directamente en el dispositivo o en nodos muy próximos a la fuente de datos. Minimiza la latencia y la dependencia de infraestructura externa, siendo especialmente adecuado para entornos con conectividad limitada o intermitente.
La arquitectura propuesta en este trabajo adopta un enfoque de edge computing distribuido, donde cada nodo ESP32 es capaz de tomar decisiones de manera autónoma sin requerir comunicación constante con un servidor central.
Interoperabilidad en arquitecturas multiprotocolo La interoperabilidad en IoT hace referencia a la capacidad de diferentes dispositivos y protocolos para comunicarse y operar de manera conjunta dentro de un mismo sistema [25]. En arquitecturas multiprotocolo, esta interoperabilidad implica la coexistencia de tecnologías con características heterogéneas en términos de latencia, alcance, consumo energético y modelo de comunicación.
El problema del gateway centralizado El enfoque tradicional para integrar protocolos heterogéneos consiste en el uso de gateways centralizados, dispositivos que actúan como traductores entre redes con tecnologías distintas [12, 19, 37]. Si bien este esquema simplifica la integración funcional, introduce un punto único de fallo (SPOF, Single Point of Failure): si el gateway falla, toda comunicación entre las subredes queda interrumpida, comprometiendo la disponibilidad del sistema [25, 41].
Formalmente, en una red con N nodos que dependen de un gateway G para comunicarse, la disponibilidad del sistema Asistema está acotada por la disponibilidad del gateway: Asistema ≤AG
(4.1)
donde AG representa la disponibilidad del gateway. En contraste, una arquitectura distribuida donde cada nodo puede conmutar entre protocolos de forma autónoma no presenta este cuello de botella.
Comparación de protocolos de comunicación inalámbrica Los protocolos empleados en IoT presentan características muy distintas que los hacen adecuados para diferentes escenarios. La Tabla 4.1 resume los atributos principales de los protocolos considerados en este trabajo [13, 71, 25, 40, 48].
Cuadro 4.1: Comparación de protocolos de comunicación inalámbrica para IoT Protocolo Alcance Velocidad Consumo Topología Capa OSI Wi-Fi (802.11n) 50–100 m Hasta 150 Mbps Alto Estrella/Malla 1–2
ESP-NOW
200–500 m Hasta 1 Mbps Bajo Punto a punto
2
LoRa 2–15 km 0.3–50 kbps Muy bajo Estrella 1–2
MQTT
Sin límite Depende de red Bajo Pub/Sub
7
En la arquitectura propuesta, ESP-NOW se emplea como protocolo primario para la comunicación directa entre nodos vecinos debido a su baja latencia y bajo consumo. Wi-Fi se utiliza para la conexión del nodo raíz a Internet, mientras que MQTT actúa como protocolo de mensajería para la integración con servicios externos. LoRa queda disponible como alternativa para escenarios de largo alcance [18, 40].
Identificación de tramas mediante EtherType Para gestionar la coexistencia de múltiples protocolos dentro de una misma arquitectura, el sistema emplea un campo de identificación en las cabeceras de las tramas inspirado en el mecanismo EtherType del estándar Ethernet [71]. Este campo de 2 bytes permite al nodo receptor identificar el protocolo de origen y el tipo de mensaje sin necesidad de inspeccionar el payload completo. La estructura general de una trama del sistema se presenta en la Tabla 4.2.
Cuadro 4.2: Estructura de trama del sistema multiprotocolo Campo ID Origen ID Destino EtherType Payload cifrado
CRC
Tamaño
6 bytes
6 bytes
2 bytes
Variable
2 bytes
Topología jerárquica tipo árbol La topología tipo árbol organiza los nodos en niveles jerárquicos donde cada nodo establece una relación padre-hijo con otro nodo de nivel superior. Este modelo permite estructurar la red de forma escalable, facilitando la agregación de nodos y el establecimiento de rutas determinísticas hacia un nodo raíz [71, 72].
Comparación de topologías de red Existen diferentes topologías de red utilizadas en sistemas IoT, cada una con ventajas y limitaciones que condicionan su idoneidad según el escenario de despliegue. La Tabla 4.3 presenta una comparación de las topologías más relevantes [15, 71, 41].
Cuadro 4.3: Comparación de topologías de red para IoT Topología Ventajas Limitaciones Uso típico Estrella Simplicidad, baja latencia SPOF en el centro Redes domésticas Malla Alta resiliencia, múltiples rutas Complejidad de enrutamiento, alto consumo Redes industriales Árbol Balance entre simplicidad y resiliencia, rutas determinísticas Dependencia del nodo padre IoT distribuido Bus Simplicidad SPOF en el bus, baja escalabilidad Redes cableadas La topología árbol representa un equilibrio óptimo para el escenario planteado: ofrece rutas determinísticas que simplifican el enrutamiento, permite una recuperación ante fallos mediante la reelección del nodo padre, y escala de forma controlada limitando el número máximo de hijos por nodo (MAX_HIJOS = 2 en la implementación actual). Métricas de calidad de enlace Para evaluar la calidad de los enlaces en la red, el sistema emplea tres métricas fundamentales:
RSSI (Received Signal Strength Indicator): indica la potencia de la señal recibida, expresada en dBm. Valores más cercanos a cero indican mayor potencia de señal. En el ESP32, el rango típico oscila entre −100 dBm (señal muy débil) y −30 dBm (señal excelente) [18, 26].
Estabilidad del enlace: métrica derivada del historial de comunicaciones con cada vecino, que cuantifica la persistencia del enlace a lo largo del tiempo. Se calcula como la
proporción de intercambios exitosos sobre el total de intentos en una ventana temporal definida.
PER (Packet Error Rate): tasa de paquetes con errores detectados mediante CRC, que complementa la evaluación de la calidad del canal.
Raíz ID: R Nivel: 1 Internet: Sí Padre A ID: A Nivel: 2 Padre: R Padre B ID: B Nivel: 2 Padre: R Nodo 1 ID: N1 Nivel: 3 Padre: A Nodo 2 ID: N2 Nivel: 3 Padre: A Nodo 3 ID: N3 Nivel: 3 Padre: B Nodo 4 ID: N4 Nivel: 3 Padre: B Nodo alterno ID: Alt Nivel: 3 −52 dBm −57 dBm −61 dBm −58 dBm −63 dBm −60 dBm −67 dBm Ruta activa Respaldo Figura 4.2: Topología jerárquica tipo árbol con niveles, relaciones padre-hijo, RSSI de enlace, ruta hacia la raíz y nodo alterno para recuperación ante fallos. Topología implementada Como se observa en la Figura 4.2, la red propuesta organiza los nodos en tres niveles jerárquicos. El nodo raíz (nivel 1) posee conexión directa a Internet y actúa como punto de concentración del tráfico hacia servicios externos. Los nodos de nivel 2 actúan como agregadores de sus respectivos subárboles, y los nodos de nivel 3 corresponden a los dispositivos finales que recolectan o actúan sobre el entorno. Los valores de RSSI indicados en los enlaces ilustran la variabilidad de la calidad del canal en un despliegue real. El nodo alterno de respaldo (nivel 3) representa la opción de reconfiguración disponible en caso de pérdida del enlace principal, mecanismo que se describe en detalle en las secciones de selección de padre y recuperación ante fallos. Ciberseguridad en sistemas IoT La ciberseguridad en IoT se fundamenta en el modelo CIA: confidencialidad, integridad y disponibilidad de la información [45, 46]. En sistemas embebidos como los basados en ESP32, la implementación de estos principios debe considerar estrictamente las restricciones de procesamiento, memoria y consumo energético del hardware.
El modelo CIA aplicado a redes IoT El modelo CIA describe los tres objetivos fundamentales de la seguridad de la información:
Confidencialidad: garantiza que la información solo sea accesible para los nodos autorizados. En el sistema propuesto se implementa mediante protección ligera del payload con XOR usando la clave compartida derivada del intercambio Diffie-Hellman. No se utiliza AES-128 puro, debido a que el ESP32 ejecuta simultáneamente varias tareas de red y se priorizó una solución de menor costo computacional para el prototipo. Integridad: asegura que los datos no han sido alterados durante la transmisión. Se implementa mediante el cálculo y verificación de un código CRC-16 sobre cada trama [38].
Disponibilidad: garantiza que el sistema permanezca operativo ante fallos o ataques. Se implementa mediante los mecanismos de supervisión del enlace, mensajes KeepAlive y recuperación automática ante fallos descritos en la metodología. Vectores de ataque en redes IoT Los sistemas IoT son susceptibles a diferentes categorías de ataque que el diseño de seguridad debe contemplar [6, 7, 28, 45, 46]: Escucha pasiva (eavesdropping): un atacante intercepta los mensajes transmitidos en el canal inalámbrico. La protección XOR con clave compartida mitiga parcialmente este riesgo al evitar que el payload viaje en texto plano; no obstante, se reconoce que es un mecanismo ligero de prototipo y no equivalente a AES para escenarios productivos de alta seguridad.
Ataque de intermediario (man-in-the-middle, MITM): un atacante se interpone en el canal de comunicación entre dos nodos legítimos. En el contexto de la arquitectura propuesta, la proximidad física requerida para el intercambio Diffie-Hellman por ESP- NOW y la validación de identidad mediante MAC address reducen la superficie de ataque.
Ataque de repetición (replay attack): un atacante captura y reenvía mensajes legítimos para engañar al receptor. El número de secuencia de la trama, el EtherType y la validación CRC permiten identificar mensajes fuera de contexto o dañados; para una versión productiva se recomienda complementar esta lógica con contadores criptográficos o códigos de autenticación.
Clonación de nodo (node cloning): un atacante replica la identidad de un nodo legítimo para insertarse en la red. La arquitectura mitiga esto vinculando la identidad del nodo a su dirección MAC física, que es única por dispositivo [1, 38]. Protección ligera del payload mediante XOR Aunque AES-128 es una alternativa ampliamente documentada para sistemas IoT, en la implementación desarrollada no se utiliza AES-128 puro. Debido a las restricciones reales del ESP32 ejecutando MicroPython y múltiples tareas simultáneas —descubrimiento de vecinos, recepción por ESP-NOW y LoRa, supervisión KeepAlive, manejo de colas, reenvío de datos y, en el nodo raíz, publicación hacia MQTT— se optó por una protección ligera basada en XOR sobre el payload de la trama. El procedimiento implementado conserva el intercambio de claves Diffie-Hellman para obtener una clave compartida entre nodos vecinos. A partir de dicha clave, cada byte del payload se combina con la clave mediante una operación XOR repetida cíclicamente: Ci = Pi ⊕Ki m´od |K|
(4.2)
donde Pi representa el byte del payload en claro, K la clave compartida del enlace y Ci el byte protegido resultante. El descifrado utiliza la misma operación, ya que Pi = Ci ⊕Ki m´od |K|. Esta decisión reduce el tamaño del código y la carga de procesamiento en los ciclos críticos del nodo.
Es importante aclarar que este mecanismo no pretende sustituir a AES en aplicaciones productivas de alta seguridad. Su uso se justifica en el alcance experimental del prototipo, donde se busca validar la arquitectura multiprotocolo, la topología jerárquica, la selección de padres, la recuperación ante fallos y la integridad de las tramas sin sobrecargar el microcontrolador. Para despliegues reales con información sensible, la arquitectura puede evolucionar hacia AES-CTR, ASCON u otro algoritmo ligero autenticado, manteniendo el mismo esquema general de intercambio de claves, EtherType, CRC y empaquetado de tramas.
4.1.2.
Modelos matemáticos y computacionales Modelo de intercambio de claves Diffie-Hellman El protocolo Diffie-Hellman (DH) fue propuesto por Whitfield Diffie y Martin Hellman en 1976 y constituye la base de la criptografía de clave pública moderna. Su aportación fundamental consiste en permitir que dos partes establezcan una clave compartida a través de un canal inseguro sin necesidad de intercambiar la clave directamente [11, 38, 39]. Fundamento matemático El protocolo se basa en la dificultad computacional del problema del logaritmo discreto: dado un número primo p, un generador g y el valor A = ga m´od p, resulta computacionalmente inviable determinar el exponente a en tiempo polinómico para valores suficientemente grandes de p [11].
El intercambio de claves se realiza en los siguientes pasos:
1. Ambos nodos acuerdan los parámetros públicos: un primo p y un generador g (con
1 < g < p).
2. El nodo A genera un exponente secreto a y calcula su clave pública:
A = ga m´od p
(4.3)
3. El nodo B genera un exponente secreto b y calcula su clave pública:
B = gb m´od p
(4.4)
4. Ambos nodos intercambian sus claves públicas A y B a través del canal.
5. Cada nodo calcula la clave compartida K:
K = Ba m´od p = Ab m´od p = gab m´od p
(4.5)
Un atacante que intercepte A y B no puede recuperar K sin resolver el problema del logaritmo discreto, cuya dificultad crece exponencialmente con el tamaño de p.
Parámetros utilizados en la implementación En la implementación sobre MicroPython para ESP32, los parámetros se cargan desde la configuración local del nodo. Para el prototipo de laboratorio se utilizaron valores reducidos, dh_primo = 23 y dh_generador = 5, con el objetivo de validar el flujo funcional del intercambio de claves sin sobrecargar el ciclo de ejecución. Estos valores son adecuados únicamente para validación experimental; una versión productiva debe emplear parámetros criptográficos de mayor tamaño o un esquema ECDH. Consideraciones sobre ataques MITM en el contexto de la arquitectura El protocolo DH en su forma básica es vulnerable al ataque de intermediario: si un atacante puede interceptar y suplantar a ambos nodos durante el intercambio, puede establecer claves distintas con cada uno sin que ninguno lo detecte [11]. En la arquitectura propuesta, esta vulnerabilidad se mitiga mediante dos mecanismos complementarios: La comunicación DH se realiza por ESP-NOW, que requiere conocer la dirección MAC del peer de destino. Un atacante que intente suplantar a un nodo debe conocer previamente su MAC y estar físicamente dentro del rango de cobertura. El proceso de descubrimiento previo (Fase 4 de la metodología) establece una lista de vecinos conocidos antes de iniciar el intercambio de claves, lo que limita los interlocutores aceptados durante la Fase 6.
Nodo A Intercambio Diffie-Hellman Protección XOR del payload Transmisión (ESP-NOW / Wi-Fi) Recepción y descifrado Validación CRC-16 Nodo B Figura 4.3: Flujo de intercambio de claves, protección XOR del payload, transmisión y validación CRC-16 entre nodos.
Flujo de comunicación segura Como se observa en la Figura 4.3, el proceso de comunicación segura inicia con el establecimiento de la clave compartida mediante DH. Una vez obtenida la clave, el payload de cada trama se protege mediante XOR antes de su transmisión. En recepción, el nodo revierte la operación XOR y verifica la integridad mediante CRC-16 antes de procesarlo.
Modelo de integridad mediante CRC El CRC (Cyclic Redundancy Check) es un mecanismo estándar de detección de errores basado en la división polinómica en aritmética de campo finito GF(2) [38]. A diferencia de un simple checksum, el CRC tiene la capacidad de detectar ráfagas de errores de hasta r bits consecutivos, donde r es el grado del polinomio generador.
Fundamento matemático El mensaje M de k bits se trata como un polinomio M(x) de grado k −1 con coeficientes en GF(2). El polinomio generador G(x) de grado r define el tipo de CRC. El cálculo del CRC sigue el procedimiento:
1. Se desplaza el mensaje r posiciones a la izquierda: M(x) · xr.
2. Se divide entre el polinomio generador en aritmética módulo 2:
M(x) · xr = Q(x) · G(x) + R(x)
(4.6)
donde R(x) es el residuo de la división y constituye el valor CRC.
3. El mensaje transmitido es T(x) = M(x) · xr + R(x).
4. En recepción, si T(x) m´od G(x) = 0, el mensaje se considera íntegro.
Polinomio generador utilizado En la implementación del sistema se utiliza CRC-16/CCITT con polinomio generador:
G(x) = x16 + x12 + x5 + 1
(4.7)
Este polinomio, equivalente al valor hexadecimal 0x1021, es ampliamente utilizado en protocolos de comunicación industrial y ofrece las siguientes capacidades de detección [38]: Detecta todos los errores de ráfaga de hasta 16 bits. Detecta todos los errores que afectan a un número impar de bits. Probabilidad de error no detectado: aproximadamente 1/216 ≈1.5 × 10−5. Ejemplo numérico Para ilustrar el cálculo, considérese un mensaje de 8 bits 0xB2 =
10110010. Con el polinomio CRC-16/CCITT y un valor inicial de 0xFFFF, el resultado del
CRC varía según el contenido del mensaje. En la implementación en MicroPython, el cálculo se realiza byte a byte mediante una tabla de valores precalculados, lo que reduce el costo computacional frente al método de división directa.
Modelo de selección de nodo padre La selección del nodo padre constituye una de las decisiones más críticas en la arquitectura propuesta, ya que determina tanto la eficiencia de la ruta hacia la raíz como la estabilidad de la conexión del nodo. Se implementa mediante un modelo de decisión multicriterio ponderado [15, 17, 41].
Formulación del modelo implementado La versión actual del algoritmo no utiliza un modelo normalizado con múltiples pesos abstractos. La selección de padre se realiza con una lógica más directa, basada primero en criterios mínimos de aceptación y luego en un puntaje entero. Un vecino solo puede ser candidato si cumple las siguientes condiciones: Tiene conectividad hacia Internet, ya sea directa o heredada mediante su ruta hacia la raíz.
Reporta un nivel jerárquico válido.
Tiene cupo disponible según max_hijos.
Su RSSI no está por debajo del umbral mínimo configurado, cuando el RSSI está disponible.
Para cada candidato válido, el puntaje se calcula como:
Scorej = 1000 + m´ax(0, 600 −nivelj · 60) + 5 · RSSI∗ j + 50 · cupoj
(4.8)
donde RSSI∗ j corresponde al RSSI transformado por la función _puntaje_rssi(), que limita el RSSI al intervalo [−100, −20] dBm y lo desplaza al rango [0, 80]. El término cupoj corresponde a la diferencia entre max_hijos y la cantidad de hijos actualmente reportada por el candidato.
Cuadro 4.4: Variables del modelo de selección de nodo padre implementado Variable Descripción Tipo Impacto nivelj Nivel jerárquico del candidato Entero Favorece rutas más cortas hacia la raíz
RSSI∗
j RSSI limitado y desplazado al rango [0, 80] Entero Premia enlaces de mejor calidad cupoj Cupos disponibles para aceptar hijos Entero Favorece nodos con menor carga tiene_internet Condición obligatoria de conectividad hacia la raíz/Internet Booleano Filtra candidatos no válidos Scorej Puntaje total del candidato Entero Selección del padre con mayor valor Este ajuste hace que el modelo sea más coherente con el código implementado: se prioriza la conectividad hacia Internet, se favorecen niveles más cercanos a la raíz, se considera la calidad de enlace mediante RSSI y se evita saturar padres que ya alcanzaron el número máximo de hijos. Por tanto, la selección del padre es suficientemente simple para ejecutarse en el ESP32 y, al mismo tiempo, mantiene criterios relevantes para la estabilidad de la red. Justificación de los hiperparámetros del sistema Los parámetros de configuración del sistema fueron definidos considerando el balance entre capacidad de respuesta, consumo energético y estabilidad [15, 71, 18]:
MAX_HIJOS = 2: limita el número máximo de nodos hijos por nodo padre. Valores mayores reducen la profundidad del árbol pero aumentan la carga sobre los nodos intermedios y la probabilidad de congestión del canal. T_BEACON_MS = 5000 ms: intervalo entre transmisiones de beacon para descubrimiento de vecinos. Un intervalo menor acelera el descubrimiento pero aumenta el consumo energético; 5 segundos representa un equilibrio adecuado para redes no críticas.
T_COORD_CAIDO = 30000 ms: tiempo de espera antes de declarar caído al nodo padre y activar el proceso de recuperación. Este valor debe ser mayor que 6 × T_BEACON_MS para evitar falsos positivos por variaciones transitorias del canal.
4.1.3.
Tecnologías e instrumentos ESP32 como plataforma IoT El ESP32 es un sistema en chip (SoC) desarrollado por Espressif Systems, ampliamente adoptado en aplicaciones IoT por su combinación de capacidad de procesamiento, conectividad inalámbrica integrada y bajo costo [48]. A diferencia de microcontroladores de gama baja como el Arduino Uno, el ESP32 integra en un solo chip todos los componentes necesarios para implementar un nodo IoT completo.
Especificaciones técnicas Las características principales del ESP32 relevantes para este proyecto son [21, 26, 48]:
Cuadro 4.5: Especificaciones técnicas del ESP32 relevantes para IoT Característica Especificación Procesador Dual-core Xtensa LX6 a 240 MHz Memoria RAM
520 KB SRAM interna
Memoria Flash
4 MB (configurable hasta 16 MB)
Conectividad Wi-Fi
802.11 b/g/n (2.4 GHz), modos STA, AP y
STA+AP
Aceleración criptográfica Hardware AES, SHA, RSA, ECC (no usada directamente en el prototipo) Modos de bajo consumo Deep sleep (∼10 µA), Light sleep (∼800 µA)
GPIO
34 pines programables
Interfaces
SPI, I2C, UART, I2S, ADC, DAC, PWM
Aunque el ESP32 dispone de aceleración criptográfica, la implementación en MicroPython adoptó protección XOR con clave DH por simplicidad, menor uso de memoria y menor carga en el ciclo principal. Esta decisión se tomó considerando que cada nodo ejecuta simultáneamente tareas de comunicación, descubrimiento, enrutamiento, supervisión y procesamiento de datos.
MicroPython como entorno de desarrollo La implementación del sistema se realiza en MicroPython, un intérprete del lenguaje Python optimizado para microcontroladores. Las principales ventajas de MicroPython en el contexto de este proyecto incluyen [15, 21]: Facilidad de desarrollo e iteración rápida sin ciclos de compilación. Acceso directo a las interfaces de hardware del ESP32 mediante módulos como network, espnow y los controladores SPI/LoRa.
Rutinas propias de empaquetado binario, CRC16-CCITT y protección ligera XOR sobre el payload.
Entre las limitaciones, el intérprete introduce una sobrecarga de ejecución frente a C/C++ (ESP-IDF), y el recolector de basura (GC) puede introducir pausas no deterministas en la ejecución. Para mitigar esto, el sistema evita la creación excesiva de objetos temporales en los bucles críticos de tiempo real.
Protocolos de comunicación
ESP-NOW
ESP-NOW es un protocolo de comunicación propietario de Espressif que permite la transferencia de datos directa entre dispositivos ESP32 sin necesidad de infraestructura Wi-Fi externa [13, 18, 34]. Opera sobre la capa MAC del estándar 802.11 y presenta las siguientes características:
Latencia típica inferior a 5 ms, significativamente menor que Wi-Fi convencional. Payload máximo de 250 bytes por trama.
Soporte para hasta 20 peers registrados simultáneamente. No requiere que los dispositivos estén conectados a una red Wi-Fi. Canal Wi-Fi compartible con el modo STA del ESP32.
En la arquitectura propuesta, ESP-NOW es el protocolo principal para la comunicación entre nodos vecinos, incluyendo el intercambio de beacons, el protocolo Diffie-Hellman y la transmisión de tramas de datos cifradas.
MQTT
MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería basado en el modelo publicación/suscripción, diseñado específicamente para entornos con ancho de banda limitado y dispositivos con recursos restringidos [49]. Sus características principales incluyen:
Tres niveles de QoS: QoS 0 (máximo un envío), QoS 1 (al menos un envío), QoS 2 (exactamente un envío).
Mecanismo de Last Will and Testament (LWT) para notificar la desconexión inesperada de un nodo.
Soporte para mensajes retenidos (retained messages) que permiten a los nuevos suscriptores recibir el último valor publicado en un tópico.
Cabecera fija de tan solo 2 bytes, minimizando el overhead en canales con ancho de banda limitado.
En la arquitectura propuesta, MQTT actúa como protocolo de integración entre el nodo raíz y los servicios externos en la nube, permitiendo la publicación de datos recolectados por la red y la recepción de comandos remotos.
LoRa LoRa (Long Range) es una tecnología de modulación de espectro ensanchado por chirp (CSS) desarrollada por Semtech, diseñada para comunicaciones de largo alcance y muy bajo consumo energético [40, 50]. Sus parámetros configurables permiten adaptar la transmisión a diferentes escenarios:
Factor de dispersión (SF): valores entre SF7 (mayor velocidad, menor alcance) y SF12 (menor velocidad, mayor alcance).
Ancho de banda: típicamente 125, 250 o 500 kHz.
Tasa de codificación: entre 4/5 y 4/8, que controla el overhead de corrección de errores.
La combinación de estos parámetros permite alcances de hasta 15 km en zonas rurales con visión directa, con consumos en transmisión inferiores a 40 mA, lo que hace de LoRa la tecnología ideal para extender la cobertura de la red en los escenarios de despliegue rurales contemplados en este trabajo [40].
4.1.4.
Normativas y estándares El diseño de sistemas IoT debe considerar estándares internacionales que garanticen interoperabilidad, seguridad y escalabilidad. Los estándares más relevantes para el presente trabajo son:
IEEE 802.11: estándar para redes de área local inalámbricas (WLAN), sobre el cual operan Wi-Fi, ESP-NOW en el ESP32 [48].
MQTT v3.1.1 (OASIS): estándar abierto para el protocolo de mensajería IoT, garantizando interoperabilidad con brokers como Mosquitto, HiveMQ y AWS IoT Core [49].
LoRaWAN (LoRa Alliance): especificación del protocolo de red para redes LoRa, que define la estructura de trama, los procedimientos de unión a la red y los mecanismos de seguridad basados en AES-128 [50].
NIST SP 800-38A: recomendación del Instituto Nacional de Estándares y Tecnología de EE.UU. para modos de operación de cifrado por bloques, que formaliza se mantiene como referencia teórica para una posible evolución futura hacia cifrado de bloque; el prototipo actual utiliza XOR con clave DH por restricciones de implementación. OWASP IoT Top 10: lista de las diez vulnerabilidades más críticas en sistemas IoT publicada por el Open Web Application Security Project, que sirve como referencia para el diseño de los mecanismos de seguridad implementados [6, 7, 28].
4.1.5.
Relación entre el marco teórico y la metodología Los conceptos, modelos y tecnologías descritos en el presente marco teórico constituyen la base directa para el desarrollo de la metodología implementada en el sistema propuesto. La Tabla 4.6 sintetiza la correspondencia entre los elementos teóricos y las fases metodológicas donde se materializan.
Cuadro 4.6: Correspondencia entre el marco teórico y las fases metodológicas Elemento teórico Fase(s) metodológica(s) de aplicación Arquitectura IoT por capas Fases 1–3: Base del nodo, inicialización, estado inicial Topología jerárquica tipo árbol Fases 7–8: Selección de padre y asociación Tabla comparativa de protocolos Fases 4–5: Descubrimiento y tabla de vecinos Modelo DH (Diffie- Hellman) Fase 6: Seguridad de enlace XOR con clave DH Fases 10, 12, 14: Protección, transmisión y validación
CRC-16
Fases 10, 14: Integridad y validación de recepción Modelo de selección de padre Fase 7: Selección de nodo padre Estructura de trama (EtherType) Fase 9: Construcción de tramas Métricas RSSI / estabilidad Fases 5, 7, 17: Vecinos, selección y supervisión Resiliencia y recuperación Fases 17–18: Supervisión y recuperación ante fallos De esta manera, el marco teórico no solo proporciona el sustento conceptual del trabajo, sino que se integra directamente con la metodología, garantizando coherencia entre la teoría y la implementación del sistema. Cada decisión de diseño en las fases metodológicas tiene un fundamento explícito en los conceptos, modelos o tecnologías descritos en este capítulo, lo que permite trazar una línea continua entre el problema planteado, el marco conceptual y la solución implementada.
4.2.
Marco conceptual El marco conceptual define los términos clave que orientan el diseño, la implementación y la evaluación de la arquitectura propuesta. Estos conceptos permiten delimitar el significado que adquieren dentro del presente trabajo y facilitan la interpretación de los capítulos de metodología, desarrollo y resultados.
4.2.1.
Nodo IoT Un nodo IoT se entiende como un dispositivo embebido capaz de capturar, procesar y transmitir información dentro de una red distribuida. En este trabajo, cada nodo corresponde a un dispositivo ESP32 con capacidad de comunicación mediante uno o varios protocolos inalámbricos.
4.2.2.
Nodo raíz El nodo raíz corresponde al nodo que posee conectividad directa a Internet o que actúa como punto principal de referencia dentro de la topología jerárquica. En la arquitectura propuesta, el nodo raíz recibe, reenvía o concentra información proveniente de los nodos hijos y sirve como punto de salida hacia servicios externos cuando existe conectividad disponible.
4.2.3.
Nodo padre El nodo padre es aquel al cual se vincula un nodo hijo para integrarse a la red. Su selección se realiza mediante criterios como disponibilidad de Internet, nivel jerárquico, estabilidad del enlace y calidad de señal, con el propósito de mantener rutas confiables hacia la raíz.
4.2.4.
Nodo hijo Un nodo hijo es un dispositivo que no necesariamente cuenta con conectividad directa a Internet y que se asocia a un nodo padre para participar en la red. Este nodo puede transmitir datos propios, reenviar información o ejecutar procesos de descubrimiento y recuperación según las condiciones del enlace.
4.2.5.
Topología tipo árbol La topología tipo árbol corresponde a una organización jerárquica de la red en la que los nodos se conectan mediante relaciones padre-hijo. Esta estructura permite rutas más determinísticas, menor sobrecarga de enrutamiento y una administración más simple que una malla completa, aspecto relevante para dispositivos con recursos limitados.
4.2.6.
Interoperabilidad multiprotocolo La interoperabilidad multiprotocolo se refiere a la capacidad de la arquitectura para integrar y utilizar diferentes tecnologías de comunicación, como Wi-Fi, ESP-NOW y LoRa, dentro de un mismo sistema funcional. En este trabajo, dicha interoperabilidad busca permitir que los nodos seleccionen o utilicen el medio de comunicación disponible sin perder la coherencia del flujo lógico del sistema. En términos prácticos, esto significa que una trama de aplicación conserva la misma estructura lógica —EtherType, identificadores, bitarray, payload y CRC— independientemente de si viaja por ESP-NOW, Wi-Fi UDP o LoRa.
El consumo energético se entiende como el gasto de corriente asociado al funcionamiento del nodo durante sus tareas de comunicación, escucha, transmisión, procesamiento y supervisión. En este proyecto no se aborda como una medición eléctrica exhaustiva con instrumentación de laboratorio, sino como una variable de diseño que influye en la selección de protocolos, frecuencia de anuncios, intervalos de KeepAlive, uso de LoRa y carga computacional de los mecanismos de seguridad.
4.2.7.
Trama de comunicación Una trama de comunicación es la unidad estructurada de intercambio de información entre nodos. En la arquitectura propuesta, la trama incluye campos como identificador de tipo de mensaje, estado del nodo, identificadores de origen y destino, carga útil y verificación de integridad mediante CRC.
4.2.8.
EtherType El EtherType se utiliza como campo de identificación del tipo de mensaje dentro de la trama. Su función es permitir que el nodo receptor determine si el mensaje corresponde a
descubrimiento, intercambio de claves, supervisión, datos de aplicación, actualización de ruta u otro proceso interno de la red.
4.2.9.
Resiliencia La resiliencia se entiende como la capacidad de la red para mantener o recuperar su operación ante fallos de enlace, pérdida de nodos, reinicios o cambios en las condiciones de conectividad. En este proyecto, la resiliencia se materializa mediante mecanismos de supervisión, keep-alive, detección de pérdida de padre y selección de nuevas rutas.
4.2.10.
Ciberseguridad en IoT La ciberseguridad en IoT comprende los mecanismos destinados a proteger la confidencialidad, integridad y disponibilidad de la información transmitida entre nodos. En la arquitectura propuesta, esto se aborda mediante intercambio de claves, cifrado simétrico, validación de integridad y control del flujo de mensajes.
4.2.11.
Integridad de la información La integridad de la información hace referencia a la capacidad de detectar alteraciones, errores o pérdidas durante la transmisión. En este trabajo se utiliza el cálculo de CRC como mecanismo de verificación para identificar tramas corruptas o inconsistentes.
4.2.12.
RSSI
El RSSI, o indicador de intensidad de señal recibida, es una métrica utilizada para estimar la calidad relativa de un enlace inalámbrico. En la arquitectura propuesta, este valor se emplea como uno de los criterios para evaluar vecinos y seleccionar rutas dentro de la red.
4.3.
Marco legal El desarrollo de soluciones IoT en Colombia debe considerar disposiciones legales y normativas relacionadas con la protección de la información, el tratamiento de datos, el uso del
espectro radioeléctrico y la aplicación de buenas prácticas de seguridad informática. Aunque el prototipo desarrollado se orienta a un entorno académico y experimental, su diseño debe estar alineado con principios que permitan una futura aplicación responsable en escenarios reales.
4.3.1.
Ley 1273 de 2009 La Ley 1273 de 2009 modifica el Código Penal colombiano y crea el bien jurídico tutelado denominado de la protección de la información y de los datos. Esta norma incorpora conductas relacionadas con el acceso abusivo a sistemas informáticos, la interceptación de datos informáticos, el daño informático y otras afectaciones contra la confidencialidad, integridad y disponibilidad de los datos y sistemas informáticos [68]. Su relación con este proyecto se evidencia en la necesidad de proteger la comunicación entre nodos IoT mediante mecanismos de cifrado, autenticación e integridad.
4.3.2.
Ley 1581 de 2012 La Ley 1581 de 2012 establece disposiciones generales para la protección de datos personales en Colombia y desarrolla el derecho de las personas a conocer, actualizar y rectificar la información que se haya recogido sobre ellas en bases de datos o archivos [69]. Aunque el prototipo no se orienta directamente al tratamiento de datos personales, esta norma resulta relevante si la arquitectura se aplica en escenarios donde los nodos transmitan información asociada a usuarios, pacientes, habitantes, estudiantes o cualquier persona identificada o identificable.
4.3.3.
Uso del espectro radioeléctrico y bandas de uso libre El uso de tecnologías inalámbricas como Wi-Fi, ESP-NOW y LoRa debe considerar las condiciones técnicas definidas para el uso del espectro radioeléctrico en Colombia. La Resolución 105 de 2020 de la Agencia Nacional del Espectro establece bandas de frecuencia, límites de emisión y condiciones técnicas y operativas para aplicaciones permitidas bajo la modalidad de uso libre, indicando que su utilización no requiere permiso individual cuando se respetan las condiciones definidas en el anexo correspondiente [70]. En consecuencia, cualquier implementación con módulos LoRa debe configurarse de acuerdo con la banda, potencia y restricciones aplicables al territorio colombiano.
4.3.4.
Estándares y buenas prácticas técnicas Además del marco legal colombiano, el proyecto se relaciona con estándares y guías técnicas relevantes para redes IoT. Entre ellos se encuentran IEEE 802.11 para comunicaciones Wi- Fi, MQTT como protocolo de mensajería, LoRaWAN como referencia para redes de largo alcance, NIST SP 800-38A para modos de operación de cifrado y OWASP IoT Top 10 como guía de riesgos frecuentes en sistemas IoT. Estos documentos no reemplazan la legislación nacional, pero orientan decisiones de diseño seguro, interoperabilidad y validación técnica.
Capítulo 5 Estado del arte El estado del arte de una investigación tiene como propósito identificar, organizar y analizar críticamente el conocimiento existente sobre el problema de estudio, de manera que sea posible establecer qué se ha investigado, cuáles enfoques han sido aceptados, qué resultados se han obtenido y qué vacíos persisten en la literatura. En este trabajo, el análisis se orienta hacia arquitecturas IoT multiprotocolo basadas en ESP32, mecanismos de ciberseguridad aplicables a dispositivos de recursos limitados y estrategias de resiliencia en redes distribuidas.
5.1.
Delimitación y estrategia de búsqueda La revisión bibliográfica se delimitó temática y temporalmente con el fin de centrar el análisis en investigaciones relevantes para el problema planteado. En términos temáticos, se consideraron trabajos relacionados con: i) arquitecturas IoT multiprotocolo, ii) protocolos de comunicación inalámbrica aplicables a entornos IoT, iii) ciberseguridad en dispositivos embebidos y de bajo consumo, iv) resiliencia, tolerancia a fallos y recuperación de enlace, y
v) aplicaciones y evaluaciones del ESP32 como nodo principal de comunicación.
En cuanto al horizonte temporal, se priorizaron publicaciones de los últimos cinco años, complementadas con algunos trabajos de referencia ampliamente citados que permiten contextualizar el desarrollo histórico de IoT, la interoperabilidad y la seguridad de redes distribuidas. Esta decisión permite mantener actualizado el marco conceptual sin perder documentos fundamentales para comprender la evolución del área.
La búsqueda se realizó a partir de bases de datos académicas y repositorios especializados, entre ellos IEEE Xplore, ScienceDirect, SpringerLink, arXiv, Nature, repositorios universitarios y documentación técnica oficial de fabricantes como Espressif Systems y LoRa Alliance.
Para la localización de documentos se emplearon combinaciones de palabras clave como: IoT architecture, multi-protocol IoT, ESP32 wireless communication, ESP-NOW, redes malladas ESP32, LoRaWAN, IoT security, lightweight cryptography, fault tolerance in IoT, self-healing wireless sensor networks e IoT interoperability.
Estas palabras clave se combinaron mediante operadores booleanos. Algunas ecuaciones de búsqueda utilizadas fueron las siguientes:
"ESP32" AND "IoT security" "multi-protocol" AND "IoT" ("redes malladas ESP32" OR "ESP-NOW") AND "resilience" Como criterio general de calidad, se privilegiaron artículos indexados, documentos técnicos oficiales, revisiones sistemáticas y trabajos experimentales con resultados verificables. La revisión permitió identificar un conjunto de referencias representativas que fueron organizadas en tres aristas principales de análisis: arquitecturas multiprotocolo, ciberseguridad y resiliencia.
5.2.
Organización de la literatura por enfoques A partir de la revisión realizada, la literatura se agrupó en tres enfoques principales. Esta organización permite evitar una enumeración aislada de artículos y facilita el análisis crítico del conocimiento existente.
5.2.1.
Arquitecturas IoT y enfoques multiprotocolo Las arquitecturas IoT buscan integrar sensores, actuadores, redes de comunicación y servicios de procesamiento dentro de un mismo ecosistema. Los estudios generales sobre IoT describen arquitecturas por capas compuestas por percepción, red, middleware, aplicación y seguridad transversal, proporcionando una base conceptual para la interoperabilidad entre dispositivos heterogéneos [8, 43, 44, 47].
En el ámbito específico de arquitecturas multiprotocolo, diversos trabajos proponen la integración de tecnologías como Wi-Fi, ZigBee, LoRa y MQTT mediante gateways o nodos perimetrales capaces de traducir tráfico y conectar redes heterogéneas [12, 19, 25, 37]. La principal ventaja de estos enfoques radica en su capacidad de extender cobertura y facilitar la comunicación entre dispositivos con características diferentes. Sin embargo, su efectividad depende en gran medida de la estabilidad del gateway y de la infraestructura de red, lo que introduce dependencias funcionales y reduce la tolerancia a fallos en entornos con conectividad limitada.
Paralelamente, varios trabajos han estudiado el ESP32 como plataforma de bajo costo para redes inalámbricas distribuidas, destacando su doble conectividad Wi-Fi, su capacidad de procesamiento y su compatibilidad con protocolos nativos como ESP-NOW [13, 15, 71, 18, 21, 26, 30, 48]. Estos estudios demuestran que el ESP32 es adecuado para aplicaciones IoT embebidas y colaborativas; no obstante, la mayoría se concentra en escenarios de monitoreo, control puntual o pruebas de rendimiento aisladas, sin abordar una arquitectura multiprotocolo integral que combine simultáneamente interoperabilidad, seguridad y recuperación ante fallos.
5.2.2.
Ciberseguridad, criptografía y control de acceso en IoT La seguridad en IoT ha sido ampliamente estudiada debido a la gran cantidad de vulnerabilidades asociadas con dispositivos conectados. Las revisiones recientes coinciden en que problemas como contraseñas débiles, ausencia de cifrado, interfaces expuestas y falta de actualización de firmware siguen siendo causas frecuentes de incidentes de seguridad [6, 7, 28, 42, 45, 46].
En respuesta a estas limitaciones, diferentes autores han propuesto mecanismos de criptografía ligera para proteger dispositivos con restricciones de memoria, procesamiento y consumo energético. Entre los enfoques más reportados se encuentran AES para cifrado simétrico, ECC para intercambio eficiente de claves y combinaciones híbridas orientadas a equilibrar seguridad y costo computacional [1, 11, 38, 39]. La ventaja de estos esquemas consiste en ofrecer protección adecuada sin exigir la misma capacidad de procesamiento que soluciones tradicionales más pesadas. Sin embargo, muchos trabajos los validan en simulaciones o en escenarios controlados, y pocas veces analizan su impacto cuando se integran a topologías distribuidas o a múltiples protocolos en un mismo nodo.
En cuanto al control de acceso, la literatura reporta modelos como RBAC, ABAC, CapBAC
y enfoques híbridos orientados a asignar permisos dinámicos según el contexto, el rol o los atributos del dispositivo [4, 14]. Estos modelos fortalecen la gestión de identidades y privilegios, pero su implementación práctica en redes IoT distribuidas con hardware restringido continúa siendo limitada.
También se han reportado aproximaciones más avanzadas basadas en blockchain, inteligencia artificial y redes definidas por software, con el objetivo de detectar amenazas, descentralizar la confianza y automatizar la respuesta frente a incidentes [3, 11, 24]. Aunque estos enfoques son prometedores, presentan una complejidad computacional elevada y suelen depender de servicios externos o infraestructura adicional, lo cual reduce su aplicabilidad directa en nodos ESP32 operando en entornos de recursos limitados.
La literatura más reciente sobre criptografía ligera ha ampliado el análisis comparativo entre algoritmos para dispositivos restringidos. Una revisión sistemática publicada en 2025 que analiza 77 estudios entre 2006 y 2025 concluye que AES-128 sigue siendo el estándar de referencia para confidencialidad en IoT, mientras que ECDH (Elliptic Curve Diffie-Hellman) se consolida como el mecanismo preferido para intercambio eficiente de claves en entornos de recursos limitados [61]. El mismo estudio señala que la combinación de un mecanismo de derivación de clave ligero con AES para cifrado de flujo constituye actualmente la arquitectura de seguridad más equilibrada en términos de protección y costo computacional para nodos IoT de bajo consumo.
En una dirección complementaria, la comparación experimental de AES-128, SPECK y AS- CON sobre tarjetas IoT de recursos limitados, publicada en 2024 [62], demuestra que AES-128 con aceleración hardware en el ESP32 presenta un rendimiento superior al esperado teóricamente, con tiempos de cifrado de bloque inferiores a 2 ms para payloads de hasta 250 bytes. Este resultado respalda que AES-128 puede ser una alternativa viable para una versión futura de la arquitectura. Sin embargo, en el prototipo implementado se adoptó XOR con clave DH como mecanismo ligero, debido a la carga simultánea de procesos que ejecuta el ESP32 bajo MicroPython.
Respecto a las vulnerabilidades más frecuentes en implementaciones reales, una revisión sobre seguridad en el perímetro IoT publicada en 2025 documenta que una de las configuraciones deficientes más comunes consiste en desplegar brokers MQTT sin autenticación, lo que permite a cualquier dispositivo unirse a la red sin credenciales [63]. Esta observación subraya que los problemas de seguridad en IoT no siempre derivan de limitaciones del hardware, sino de decisiones de diseño y configuración que priorizan la simplicidad sobre la protección. La arquitectura propuesta en este trabajo aborda este problema estableciendo un mecanismo
de autenticación implícita basado en el intercambio Diffie-Hellman previo a cualquier transmisión de datos, de modo que solo los nodos que hayan completado el protocolo de enlace seguro pueden participar en la red.
Por otra parte, el trabajo de Chatue et al. [38] sobre la integración de algoritmos criptográficos en el protocolo ESP-NOW representa un antecedente directo de la presente investigación, ya que evalúa experimentalmente el impacto del cifrado sobre la latencia y el consumo energético de nodos ESP32 en cadenas de sensores inalámbricos. Los resultados indican que la adición de cifrado AES sobre ESP-NOW introduce una sobrecarga de latencia inferior al 15 % respecto a la comunicación no cifrada, lo que confirma la viabilidad de implementar seguridad sin comprometer significativamente el rendimiento en tiempo real del sistema.
5.2.3.
Resiliencia, tolerancia a fallos y eficiencia energética La tercera arista se relaciona con la capacidad de las redes IoT para mantener su operación ante la pérdida de nodos, la degradación del enlace o la inestabilidad de la infraestructura. En este campo, las redes en malla han mostrado ventajas importantes al permitir el reenvío dinámico de mensajes y la reorganización automática de rutas [15, 71, 72]. Particularmente, las implementaciones basadas en redes malladas ESP32 reportan mejoras en cobertura, continuidad operativa y recuperación de conectividad tras la caída de nodos intermedios. No obstante, en muchos de estos trabajos la seguridad es tratada como una capa separada o secundaria, sin una integración profunda con la lógica de recuperación. Por otra parte, las estrategias de tolerancia a fallos incluyen redundancia modular, clustering autorreparable, gemelos digitales y enrutamiento adaptativo, con resultados favorables en indicadores como disponibilidad, tasa de entrega de paquetes y detección de comportamientos anómalos [16, 17, 36, 41]. Sin embargo, buena parte de estas soluciones se ha evaluado en redes de sensores genéricas o mediante simulación, lo que limita la extrapolación directa a entornos basados en ESP32 y protocolos heterogéneos.
Finalmente, la eficiencia energética aparece como una variable transversal. El uso de protocolos de largo alcance, mecanismos de bajo consumo y políticas adaptativas de transmisión ha permitido reducir el desgaste energético y prolongar la autonomía de la red [18, 22, 26, 27, 35, 40]. A pesar de ello, la literatura todavía presenta pocas propuestas donde se estudie de manera conjunta la interacción entre consumo energético, criptografía, selección de rutas y coexistencia multiprotocolo.
El campo de la resiliencia en redes IoT ha experimentado una evolución significativa hacia en-
foques basados en inteligencia artificial para la detección y recuperación de fallos. Revisiones recientes de 2025 señalan que los métodos basados en aprendizaje profundo permiten detectar anomalías en tiempo real con mayor precisión que los umbrales estáticos tradicionales, reduciendo los tiempos de respuesta ante fallos y minimizando la intervención humana [64]. No obstante, la complejidad computacional de estos modelos los hace difícilmente implementables directamente en microcontroladores como el ESP32, lo que refuerza la pertinencia de estrategias de recuperación más ligeras basadas en métricas locales como RSSI y estabilidad del enlace, tal como se propone en el presente trabajo.
En la intersección entre resiliencia y bajo consumo, el trabajo de Gonugunta y Chen sobre arquitecturas de malla IoT con soporte 5G para mantenimiento autónomo en entornos industriales demuestra que las topologías de malla superan significativamente a las topologías estrella y árbol en términos de continuidad de servicio durante cargas de tráfico elevadas [65]. Sin embargo, los autores reconocen que la densidad de la malla, la capacidad de los nodos pasarela y la eficiencia del enrutamiento adaptativo son factores críticos que condicionan la escalabilidad del sistema. En contraste, la topología árbol propuesta en este trabajo ofrece rutas más determinísticas y menor sobrecarga de enrutamiento a expensas de una menor redundancia, lo que la hace más adecuada para entornos con recursos computacionales limitados donde la complejidad del enrutamiento en malla resultaría prohibitiva. En cuanto a la eficiencia energética, estudios recientes sobre algoritmos criptográficos ligeros en microcontroladores de batería restringida confirman que el consumo energético adicional introducido por el cifrado AES-128 en hardware con aceleración es marginal respecto al consumo total de transmisión inalámbrica, representando menos del 5 % del gasto energético por ciclo de comunicación [66]. Este resultado es relevante para la viabilidad de la arquitectura propuesta, ya que descarta el argumento frecuentemente empleado en la literatura de que la seguridad criptográfica es incompatible con la autonomía energética de los nodos IoT de bajo consumo.
5.3.
Análisis crítico y comparativo La revisión realizada permite afirmar que existe un avance significativo en cada una de las aristas consideradas; sin embargo, los trabajos revisados presentan un tratamiento fragmentado del problema. En la mayoría de casos, los estudios de interoperabilidad se concentran en conectar protocolos heterogéneos, pero mantienen una fuerte dependencia de gateways o nodos coordinadores [12, 19, 25]. Aunque esto facilita la integración funcional, también
reduce la robustez de la red frente a fallos de infraestructura.
De manera similar, los estudios sobre seguridad en IoT muestran resultados prometedores en criptografía ligera, autenticación y control de acceso [1, 4, 11, 38, 39]; no obstante, con frecuencia evalúan sus propuestas en términos de confidencialidad o integridad de manera aislada, sin relacionarlas suficientemente con el comportamiento global de la red, el consumo energético o la latencia.
En el caso de la resiliencia, los trabajos basados en redes malladas y mecanismos de autorecuperación demuestran mejoras en disponibilidad y continuidad del servicio [15, 17, 36, 41]. Sin embargo, muchas de estas propuestas no integran mecanismos de seguridad dentro del propio proceso de recuperación ni contemplan escenarios donde coexistan simultáneamente múltiples protocolos de comunicación.
En síntesis, la comparación de la literatura muestra que las soluciones actuales suelen responder de forma parcial a uno de los tres retos principales: interoperabilidad, seguridad o resiliencia. Esto dificulta contar con propuestas realmente integrales aplicables a entornos como el colombiano, donde la infraestructura es limitada, la conectividad puede ser intermitente y los recursos computacionales del hardware son reducidos.
Adicionalmente, la revisión de literatura publicada en 2024–2025 permite observar una tendencia emergente hacia la integración de inteligencia distribuida en los propios nodos, con el objetivo de que cada dispositivo sea capaz de tomar decisiones de enrutamiento, seguridad y recuperación sin depender de un nodo coordinador externo. Esta tendencia refuerza la pertinencia del enfoque distribuido adoptado en este trabajo, en el cual cada nodo ESP32 ejecuta de manera autónoma todos los módulos funcionales del sistema, desde el descubrimiento de vecinos hasta la recuperación ante fallos. Asimismo, se observa que los trabajos más recientes comienzan a validar sus propuestas sobre hardware real en lugar de exclusivamente en simulaciones, lo que incrementa la aplicabilidad práctica de los resultados y sirve como referencia directa para la evaluación experimental de la arquitectura propuesta.
5.4.
Vacíos identificados e implicaciones para la investigación A partir del análisis crítico realizado, se identifican los siguientes vacíos principales: Existe escasez de arquitecturas IoT multiprotocolo basadas en ESP32 que integren en una
misma propuesta Wi-Fi, ESP-NOW, LoRa y MQTT de manera funcional y coherente. Los mecanismos de seguridad reportados en la literatura suelen evaluarse de forma separada del comportamiento de la red, sin analizar suficientemente su efecto sobre latencia, consumo energético e interoperabilidad.
Las estrategias de resiliencia y auto-recuperación han sido estudiadas principalmente en redes malladas o simuladas, pero pocas veces en combinación con esquemas de cifrado y control de acceso adaptados a hardware restringido.
Persiste una limitada validación en escenarios reales o representativos de contextos con infraestructura limitada y conectividad intermitente, como los que se presentan en diversas regiones de Colombia.
Estos vacíos justifican el desarrollo del presente trabajo de grado. La propuesta busca reducir dicha brecha mediante el diseño e implementación de una arquitectura jerárquica tipo árbol basada en nodos ESP32, capaz de descubrir vecinos, seleccionar rutas, intercambiar información mediante distintos protocolos y proteger la comunicación con mecanismos de seguridad integrados. De esta manera, el trabajo no se limita a estudiar un componente aislado, sino que plantea una aproximación orientada a combinar interoperabilidad multiprotocolo, ciberseguridad y resiliencia dentro de un mismo sistema distribuido
Capítulo 6 Diseño metodológico
6.1.
Enfoque metodológico El desarrollo del proyecto se estructuró bajo un enfoque aplicado de ingeniería, orientado al diseño, construcción y validación experimental de una arquitectura IoT multiprotocolo basada en nodos ESP32. La metodología no se limitó a la codificación de funciones internas, sino que se organizó en macroetapas que agrupan las actividades técnicas necesarias para pasar desde la definición de la arquitectura hasta la evaluación del comportamiento del prototipo.
6.2.
Diseño de la arquitectura del sistema El propósito de esta etapa fue definir la arquitectura general de la red IoT multiprotocolo, estableciendo la organización jerárquica de los nodos, los roles funcionales, los protocolos de comunicación y la forma en que los datos debían fluir desde los nodos sensores hasta el nodo raíz y, posteriormente, hacia un broker MQTT.
En primer lugar, se definió una topología jerárquica tipo árbol, en la cual un nodo raíz con conectividad Wi-Fi actúa como punto de concentración y publicación de datos. Los nodos hijos se asocian a un padre disponible de acuerdo con criterios de conectividad, nivel jerárquico, calidad de enlace y capacidad máxima de hijos, lo que permitió organizar la red de manera controlada y evitar que todos los nodos dependieran de una única comunicación directa con el broker. Posteriormente, se establecieron los roles de operación de cada nodo: el nodo raíz se configuró con acceso a Wi-Fi e integración MQTT, mientras que los nodos intermedios o finales se configuraron para operar mediante enlaces ESP-NOW o LoRa según el escenario de prueba. También se definió la diferencia entre conectividad directa a Internet
y conectividad heredada, representada mediante los estados wifi y tiene_internet, lo que permitió que un nodo sin conexión Wi-Fi directa pudiera considerarse conectado a la red si contaba con una ruta válida hacia el nodo raíz.
Para esta etapa se utilizaron módulos ESP32-WROOM-32, entorno MicroPython, comunicación Wi-Fi, ESP-NOW, LoRa mediante módulos SX1278 y publicación MQTT hacia un broker externo, junto con diagramas de topología para representar las relaciones padre-hijo y el flujo de comunicación. Los principales parámetros considerados fueron el identificador único del nodo, el nivel jerárquico, la capacidad máxima de hijos, el estado de conectividad Wi-Fi, el estado de conectividad hacia Internet, el protocolo principal de comunicación, el RSSI cuando estuvo disponible y el identificador del nodo padre. Como resultado de esta etapa se obtuvieron la arquitectura lógica de la red, la definición de roles de nodo, la estructura inicial de configuración y los diagramas de topología utilizados como referencia para la implementación.
6.3.
Implementación multiprotocolo y gestión de comunicación El propósito de esta etapa fue implementar la comunicación entre nodos mediante diferentes protocolos inalámbricos, manteniendo una estructura común de mensajes que permitiera interpretar y enrutar la información independientemente del medio físico utilizado. La implementación inició con la construcción de los módulos de configuración, estado del nodo e inicialización de red. A partir de estos módulos se habilitaron los protocolos requeridos en cada escenario de prueba y se definió el comportamiento inicial del nodo según su disponibilidad de conexión Wi-Fi: cuando un nodo contaba con acceso directo a Internet podía actuar como raíz y, en caso contrario, entraba en modo de descubrimiento para buscar un padre disponible. El proceso de descubrimiento se implementó mediante anuncios de presencia y escucha multiprotocolo, de modo que cada nodo podía recibir información de vecinos, actualizar su tabla local y almacenar atributos como identificador, protocolo de recepción, RSSI, nivel, cantidad de hijos, disponibilidad de cupo y estado de conectividad; esta información se persistió en un archivo de vecinos para permitir trazabilidad y recuperación parcial del estado de la red. Para unificar la comunicación, se diseñó una estructura de trama propia basada en campos de origen, destino, EtherType, estado, payload y CRC, donde el campo EtherType permitió diferenciar mensajes de descubrimiento, vinculación, intercambio de claves, KeepAlive, datos de aplicación, solicitudes de reenvío y actualización de rutas, logrando
así que ESP-NOW, LoRa y Wi-Fi se integraran bajo una lógica común de procesamiento. Para el desarrollo se utilizaron MicroPython, librerías de comunicación inalámbrica para ESP32, el módulo ESP-NOW, sockets UDP sobre Wi-Fi, módulos LoRa SX1278, estructuras JSON para datos de aplicación, archivos locales para persistencia de vecinos y un cliente MQTT para la publicación de los datos recibidos por el nodo raíz. Los parámetros principales fueron los EtherType definidos para cada tipo de mensaje, el puerto UDP de comunicación, los protocolos habilitados por nodo, los identificadores de origen y destino, el tamaño del payload, el número de secuencia, el tiempo de escucha por protocolo y los intervalos de anuncio. Los entregables de esta etapa fueron los módulos de inicialización de red, descubrimiento, construcción de tramas, transmisión, recepción, tabla de vecinos y publicación de datos hacia
MQTT.
6.4.
Integración de seguridad e integridad de la información El propósito de esta etapa fue incorporar mecanismos de seguridad compatibles con las restricciones del ESP32, garantizando que la asociación entre nodos incluyera generación de clave compartida, protección ligera del payload y verificación de integridad de las tramas. La integración de seguridad se realizó después de la selección del nodo padre y antes del envío regular de datos de aplicación. Una vez que un nodo hijo identificaba un padre válido, se ejecutaba una solicitud de vinculación y, si el padre la aceptaba, ambos nodos iniciaban un intercambio de claves Diffie-Hellman para generar una clave compartida de enlace, la cual se almacenaba en la estructura de vecinos y se utilizaba posteriormente para proteger el contenido transmitido. Debido a las restricciones de memoria, procesamiento y concurrencia del ESP32 ejecutando MicroPython, no se implementó AES-128 puro en el prototipo; en su lugar, se utilizó una protección ligera del payload mediante XOR con clave derivada, manteniendo el intercambio Diffie-Hellman como mecanismo de establecimiento de clave. Adicionalmente, cada trama incorporó CRC16-CCITT para validar la integridad del mensaje recibido antes de procesarlo.
Para ello se utilizaron funciones de generación de parámetros Diffie-Hellman, rutinas de derivación de clave, operación XOR byte a byte, cálculo CRC16-CCITT y almacenamiento local de vecinos mediante archivos .json. Los parámetros considerados fueron el primo y generador usados en el intercambio Diffie-Hellman para la validación experimental, la clave
compartida generada, el estado de seguridad del vecino, el campo clave_compartida, el valor CRC calculado y el valor CRC recibido en cada trama. Como entregables se obtuvieron el módulo de seguridad, la lógica de intercambio de claves, la protección del payload, la validación de integridad y la persistencia de la clave compartida en el archivo de vecinos.
6.5.
Gestión de recepción y recuperación del enlace El propósito de esta etapa fue integrar en un mismo flujo la validación de recepción, el procesamiento de mensajes, la detección de errores, la supervisión del enlace y los mecanismos de recuperación, de manera que procesos que internamente se ejecutan como funciones separadas se presentaran como una etapa coherente de gestión de comunicación y continuidad operativa.
Cuando un nodo recibía una trama, el sistema ejecutaba primero la identificación del protocolo y del EtherType; luego se validaba la estructura de la trama, se verificaba el CRC, se descifraba el payload cuando correspondía y se despachaba el mensaje hacia la rutina asociada. Así, los mensajes de descubrimiento actualizaban la tabla de vecinos, los mensajes de vinculación activaban el proceso de asociación, los mensajes Diffie-Hellman permitían establecer claves, los mensajes de datos de aplicación eran reenviados o publicados según el rol del nodo y los mensajes KeepAlive permitían supervisar la disponibilidad del enlace. La recuperación del enlace se basó en la supervisión periódica mediante KeepAlive y KeepAlive ACK: cuando un nodo no recibía respuesta dentro de los intervalos esperados, incrementaba un contador de fallos y, si el número de fallos superaba el umbral configurado, declaraba perdido el enlace, limpiaba la información asociada al padre o hijo, eliminaba el contexto de seguridad correspondiente y regresaba al modo de descubrimiento. Este procedimiento permitió que el nodo pudiera reconectarse al mismo padre o seleccionar un nuevo padre disponible, según las condiciones de la red.
Para esta etapa se utilizaron temporizadores internos de MicroPython, contadores de fallos, registros de último contacto, mensajes KeepAlive y KeepAlive ACK, la tabla de vecinos, rutinas de limpieza de estado y lógica de retorno a descubrimiento. Los parámetros principales fueron el intervalo de KeepAlive, el tiempo máximo sin contacto, el número máximo de fallos permitidos, el identificador del vecino supervisado, el estado de asociación, el estado de seguridad y la disponibilidad de cupo para aceptar nuevas vinculaciones. Los entregables fueron la lógica de recepción validada, el manejo de mensajes por EtherType, el mecanismo de supervisión de enlaces, la limpieza de vecinos no disponibles, la recuperación ante fallos y
la reelección de padre.
6.6.
Integración en el ciclo principal del nodo El propósito de esta etapa fue integrar los módulos desarrollados en un ciclo principal capaz de operar de forma continua, atendiendo tareas de descubrimiento, recepción, transmisión, supervisión, seguridad, enrutamiento y publicación sin bloquear el funcionamiento general del nodo.
El ciclo principal se organizó de manera secuencial y no bloqueante. En cada iteración se verificaba el estado de conectividad, se escuchaban los protocolos habilitados, se procesaban los mensajes recibidos, se atendía la cola de transmisión, se ejecutaban tareas de supervisión y se actualizaba el estado de vecinos; en el nodo raíz, además, se incorporó la publicación MQTT de los datos recibidos desde la red. La integración tuvo en cuenta que el ESP32 dispone de recursos limitados, por lo que se evitó mantener procesos pesados o almacenamiento excesivo en memoria. Para las pruebas se permitió registrar información en archivos y consola, aunque se reconoció que el almacenamiento continuo de archivos extensos puede afectar el desempeño del microcontrolador.
Para ello se utilizaron módulos MicroPython, consola serial, archivos TXT de prueba, archivos JSON de vecinos, cliente MQTT, broker externo y rutinas de depuración para verificar el comportamiento del sistema durante la ejecución. Los parámetros considerados fueron los intervalos de escucha, los tiempos de publicación, los tiempos de supervisión, el tamaño de colas, la habilitación de protocolos, la bandera de cifrado, el permiso de tráfico sin cifrar para pruebas, los identificadores de nodo y el estado de memoria disponible. Los entregables fueron el archivo principal de ejecución, la integración de módulos funcionales, los registros de prueba, la publicación MQTT y el prototipo operativo de la red multiprotocolo.
6.7.
Evaluación experimental El propósito de esta etapa fue definir el procedimiento de evaluación del prototipo, estableciendo escenarios de prueba, métricas de análisis y criterios de comparación entre protocolos y versiones del código.
La evaluación se diseñó a partir de pruebas controladas en laboratorio. Se definieron escenarios de transmisión individual por protocolo, operación simultánea de ESP-NOW y LoRa,
pruebas con varias versiones del código, pruebas con seis nodos, reconexión tras pérdida del nodo raíz y reelección de padre. En cada escenario se registraron publicaciones MQTT, iteraciones recibidas, saltos de iteración, tiempos sin publicación, eventos de supervisión y evidencias de seguridad. Esta evaluación no se planteó como una prueba de escalabilidad industrial ni como una medición energética a gran escala, sino como una validación funcional y experimental del prototipo, por lo que los resultados deben interpretarse dentro del alcance del banco de pruebas utilizado y de las restricciones propias del ESP32 ejecutando MicroPython.
Para el registro y análisis se utilizaron archivos TXT, capturas de consola, cliente y broker MQTT, archivos internos de los nodos, análisis manual de iteraciones, comparación de tiempos y tablas de consolidación de resultados. Los parámetros evaluados fueron el número de mensajes esperados, las publicaciones MQTT, las iteraciones únicas recibidas, el porcentaje de efectividad, la pérdida estimada, el tiempo total de prueba, los saltos de iteración, el tiempo sin publicación, los eventos KeepAlive y KeepAlive ACK, el protocolo utilizado y la versión del código. Los entregables fueron las tablas de resultados, las capturas de evidencia, los diagramas de topología, el análisis de pérdidas, el análisis de reconexión, la comparación de versiones y las conclusiones técnicas del comportamiento de la arquitectura.
6.8.
Métricas de evaluación del sistema Para evaluar el comportamiento del prototipo se definieron métricas funcionales y cuantitativas. Estas métricas se aplicaron posteriormente en el capítulo de resultados, sin anticipar aquí los valores obtenidos.
La efectividad de recepción se calculó como la relación entre las iteraciones únicas recibidas y el número total de mensajes esperados:
Efectividad( %) = Iteraciones únicas recibidas Mensajes esperados × 100
(6.1)
La pérdida estimada se calculó como el complemento de la efectividad: Pérdida( %) = 100 −Efectividad( %)
(6.2)
La continuidad de iteraciones se evaluó mediante la identificación de saltos entre mensajes consecutivos: cuando la diferencia entre dos iteraciones recibidas era mayor que uno,
se consideró que existían mensajes intermedios no recibidos o no publicados. El tiempo sin publicación correspondió al intervalo transcurrido entre dos mensajes MQTT consecutivos cuando se detectó un salto de iteración, métrica que permitió relacionar la pérdida de continuidad con interrupciones temporales observables en el broker. La trazabilidad se evaluó verificando la presencia de campos como nodo origen, nodo raíz, protocolo, número de saltos, iteración y tipo de mensaje, los cuales permitieron reconstruir el recorrido lógico de los datos dentro de la red. La resiliencia se evaluó a partir de la detección de fallos de KeepAlive, la aparición posterior de KeepAlive ACK, la limpieza de enlaces perdidos, la reconexión del nodo hijo y la reelección de padre cuando existía otro nodo disponible. Finalmente, la interoperabilidad se evaluó verificando la coexistencia funcional de ESP-NOW, LoRa, Wi-Fi y MQTT dentro de la misma arquitectura, donde ESP-NOW y LoRa fueron considerados protocolos de comunicación entre nodos, Wi-Fi como medio de conectividad del nodo raíz y MQTT como mecanismo de publicación hacia un broker externo.
6.9.
Consideraciones metodológicas Los resultados presentados en este trabajo corresponden a un entorno controlado de laboratorio y a ejecuciones registradas mediante archivos TXT, consola serial y cliente MQTT. Por esta razón, los indicadores obtenidos permiten validar funcionalmente la arquitectura, pero no sustituyen pruebas de campo a gran escala. Para aumentar la validez estadística en trabajos futuros, se recomienda repetir cada escenario experimental bajo las mismas condiciones al menos tres veces, calcular promedio, desviación estándar, intervalos de confianza y complementar las mediciones con consumo energético, latencia por paquete y RSSI por transmisión.
Capítulo 7 Desarrollo e implementación
7.1.
Diseño del hardware El banco de pruebas del sistema fue ensamblado con componentes de bajo costo y amplia disponibilidad comercial, con el objetivo de validar la arquitectura propuesta en condiciones representativas de un despliegue real con recursos limitados. El conjunto de hardware quedó conformado por ocho nodos ESP32-WROOM-32, dos módulos de radio LoRa SX1278 Ra- 02, un sensor de temperatura y humedad DHT22, una batería portátil (power bank) como fuente de alimentación del banco de nodos, y dos computadores personales destinados a la supervisión y a la operación del broker MQTT.
7.1.1.
Componentes del banco de pruebas La Tabla 7.1 detalla la cantidad, referencia y función de cada elemento utilizado en el prototipo.
Cuadro 7.1: Inventario de hardware del banco de pruebas Cant.
Componente Referencia Función en el sistema
8
Módulo ESP32
ESP32-WROOM-32
Nodos de la red IoT: 1 raíz,
2 padres intermedios, 5 ho-
jas
2
Módulo LoRa SX1278 Ra-02 (433 MHz) Enlace de largo alcance; uno integrado al nodo raíz y otro a un nodo intermedio
1
Sensor T/H
DHT22
Adquisición de temperatura y humedad en el nodo hoja de referencia
1
Resistencia
10 kΩ
Pull-up en la línea de datos del DHT22 (montaje en protoboard)
2
Protoboard
830 puntos
Montaje sin soldadura de los módulos LoRa y del
DHT22
1
Batería portátil Power bank USB 5 V / 2 A Alimentación de los 8 nodos ESP32 mediante cables USB
2
Computador personal PC con Windows / Linux Monitoreo por terminal serie (puerto COM) y broker MQTT local (Mosquitto)
7.1.2.
Nodo ESP32-WROOM-32 El ESP32-WROOM-32 es el módulo principal de cada nodo de la red. Integra el SoC ESP32- D0WDQ6 con procesador de doble núcleo Xtensa LX6 a 240 MHz, 520 KB de SRAM, 4 MB de memoria Flash SPI, conectividad Wi-Fi 802.11 b/g/n en la banda de 2,4 GHz todo en un factor de forma de 18 × 20 mm con antena PCB integrada [48]. Sus características hacen posible ejecutar el firmware completo en MicroPython —incluyendo el ciclo de descubrimien-
to, la lógica de seguridad y la pila de protocolos— sin hardware externo adicional para las funciones Wi-Fi y ESP-NOW.
Para las pruebas, los ocho módulos fueron montados sobre tarjetas de desarrollo (DevKit) con regulador de tensión integrado y puerto Micro-USB, lo que permitió programarlos y alimentarlos directamente desde la batería portátil sin circuito de acondicionamiento adicional. La Tabla 7.2 resume las especificaciones técnicas más relevantes para el escenario de pruebas. Cuadro 7.2: Especificaciones técnicas del ESP32-WROOM-32 relevantes para las pruebas Parámetro Valor Procesador Dual-core Xtensa LX6 @ 240 MHz SRAM interna
520 KB
Flash SPI
4 MB
Wi-Fi
802.11 b/g/n (2,4 GHz), modos STA, AP y
STA+AP
Aceleración criptográfica Módulo hardware AES, SHA-2, RSA, ECC Tensión de alimentación 3,3 V (regulado) / 5 V entrada USB Corriente activa típica 80–240 mA (Wi-Fi TX) Corriente deep sleep ≈10 µA Interfaces SPI, I2C, UART, GPIO (34 pines) Dimensiones del módulo
18 × 20 × 3,2 mm
7.1.3.
Módulo LoRa SX1278 Ra-02 Los dos módulos de radio LoRa empleados corresponden a la referencia Ra-02 de AI-Thinker, basada en el transceptor Semtech SX1278 para la banda de 433 MHz. La comunicación con el ESP32-WROOM-32 se realiza mediante el bus SPI hardware del microcontrolador (pines MOSI, MISO, SCK y CS), con el pin de interrupción DIO0 conectado a un GPIO de entrada del ESP32 para señalización de recepción. El cableado se realizó con cables dupont sobre protoboard.
La Tabla 7.3 recoge los parámetros de configuración utilizados durante las pruebas, definidos en config_1.py.
Cuadro 7.3: Parámetros de configuración del módulo SX1278 Ra-02 en las pruebas Parámetro Valor configurado Descripción Frecuencia portadora
433 MHz
Banda libre ISM Factor de dispersión (SF) SF7 Mayor velocidad, menor alcance Ancho de banda
125 kHz
Configuración estándar LoRa Tasa de codificación 4/5 Mínimo overhead de FEC Potencia TX
17 dBm
Máximo permitido Ra-02 Byte de sincronización 0x12 Identificador de red privada Interfaz con ESP32 SPI hardware
MOSI, MISO, SCK, CS, DIO0
Tensión de operación 3,3 V Alimentado desde pin 3V3 del DevKit El driver del SX1278 fue implementado directamente en MicroPython dentro del módulo network_init_3.py mediante la clase SX1278. Sus métodos principales son send(bytes), start_receive(), ensure_receive() y read_payload(), siendo este último el que retorna la tupla (bytes_raw, rssi) utilizada por el sistema para actualizar la caché de RSSI de los vecinos descubiertos por LoRa.
7.1.4.
Sensor DHT22 El sensor de temperatura y humedad DHT22 fue conectado al nodo hoja de referencia mediante montaje en protoboard, con alimentación a 3,3 V y una resistencia de pull-up de 10 kΩ en la línea de datos hacia el GPIO correspondiente del ESP32. El protocolo de comunicación es monohilo (single-wire), gestionado desde MicroPython a través de la biblioteca dht nativa del firmware.
Cuadro 7.4: Especificaciones del sensor DHT22 en las pruebas Parámetro Valor Rango de temperatura −40 a +80 ◦C Resolución de temperatura 0,1 ◦C Exactitud de temperatura ±0,5 ◦C Rango de humedad relativa
0 a 100 % HR
Exactitud de humedad ±2 % HR Protocolo de comunicación Monohilo (single-wire) Tensión de alimentación 3,3 – 5,5 V Resistencia pull-up utilizada
10 kΩ
Intervalo mínimo de lectura
2 s
Intervalo configurado (dht22_intervalo_ms)
10 s
7.1.5.
Alimentación y entorno de pruebas Los ocho nodos ESP32 fueron alimentados desde una batería portátil USB de 5 V / 2 A mediante cables USB-A a Micro-USB individuales. Este esquema reprodujo condiciones de operación autónoma sin acceso a red eléctrica fija, relevante para los escenarios de despliegue rural contemplados en el proyecto.
Las dos computadoras personales cumplieron roles diferenciados: una ejecutó el broker MQTT local (Mosquitto) y registró los mensajes publicados por el nodo raíz, mientras que la segunda fue utilizada para monitoreo en tiempo real de los logs de cada nodo ESP32 mediante conexión serie (puerto COM) a través de la herramienta Thonny IDE. Esta separación permitió supervisar simultáneamente el plano de datos de aplicación (MQTT) y el plano de control interno (terminal serie) sin interferir en la operación de la red.
7.1.6.
Topología física del banco de pruebas La Figura 7.1 ilustra la disposición física de los componentes y las conexiones entre nodos en el banco de pruebas, organizada según la topología jerárquica tipo árbol definida en el diseño de la arquitectura.
Nivel 1 Nivel 2 Nivel 3 ESP32 raíz Wi-Fi + ESP-NOW Padre P1
ESP-NOW
Padre P2 ESP-NOW + LoRa H1 H2 H3
DHT22
H4 H5 SX1278 raíz SX1278 P2 Sensor DHT22 Power bank USB PC1 monitor serie PC2 broker MQTT
ESP-NOW
ESP-NOW
SPI
SPI
LoRa 433 MHz 1-Wire
USB 5 V
USB serie MQTT sobre Wi-Fi Leyenda
— ESP-NOW
—— LoRa/SPI ··· Datos, USB o MQTT Figura 7.1: Topología física del banco de pruebas: ocho nodos ESP32-WROOM-32 organizados en tres niveles jerárquicos, dos módulos LoRa SX1278 Ra-02, sensor DHT22 en el nodo hoja H3, alimentación desde power bank USB y dos PCs para monitoreo serie y broker
MQTT.
Como se observa en la Figura 7.1, la red quedó organizada en tres niveles jerárquicos con un total de ocho ESP32. El nodo raíz (nivel 1) mantuvo conectividad Wi-Fi con el router local y, a través de él, con el broker MQTT ejecutado en PC 2. Los dos padres intermedios (nivel 2) no se configuraron con Wi-Fi hacia el router; su comunicación de red se realizó mediante ESP-NOW y, específicamente, el nodo P2 contó con un módulo LoRa SX1278 para evaluar el enlace de largo alcance. Los cinco nodos hoja (nivel 3) operaron como dispositivos finales sin acceso directo a Internet, usando el protocolo disponible según la configuración de prueba. El sensor DHT22 fue conectado al nodo hoja H3 como fuente de datos reales de aplicación. Las lecturas de temperatura y humedad adquiridas cada 10 segundos fueron encapsuladas como mensajes DATOS_APLICACION_JSON (EtherType 0x9007), enrutadas salto a salto desde H3 hasta el nodo raíz y finalmente publicadas en el broker MQTT de PC 2 mediante el tópico iot/sensor/dht22.
La alimentación centralizada mediante power bank USB permitió movilizar el banco de pruebas sin dependencia de tomas eléctricas fijas, replicando las condiciones de autonomía energética características de despliegues IoT en entornos con infraestructura limitada.
7.1.7.
Conexión del módulo LoRa SX1278 al ESP32-WROOM-32 La interfaz entre el módulo Ra-02 y el ESP32-WROOM-32 se realizó por bus SPI hardware con el mapeado de pines descrito en la Tabla 7.5. La tensión de operación del Ra-02 es de 3,3 V, compatible directamente con los niveles lógicos del ESP32, por lo que no fue necesario ningún adaptador de nivel.
Cuadro 7.5: Mapeado de pines SPI entre el ESP32-WROOM-32 y el módulo SX1278 Ra-02 Pin ESP32 Pin Ra-02 Función
GPIO18 (SCK)
SCK
Reloj SPI
GPIO23 (MOSI)
MOSI
Datos maestro →esclavo
GPIO19 (MISO)
MISO
Datos esclavo →maestro
GPIO5 (CS)
NSS
Selección de chip (chip select)
GPIO26
DIO0
Interrupción de recepción / transmisión
GPIO14
RST
Reset del módulo 3V3
VCC
Alimentación 3,3 V
GND
GND
Tierra común El pin DIO0 del Ra-02 se configuró como entrada de interrupción en el ESP32 para detectar la finalización de una recepción o transmisión LoRa, permitiendo que el método ensure_receive() del driver restablezca el modo RX continuo sin perder paquetes que lleguen durante una transmisión activa.
7.2.
Diseño del software El software del sistema fue desarrollado bajo una arquitectura modular que separa responsabilidades funcionales, facilita la depuración y permite la evolución progresiva de la red IoT propuesta. La organización divide el comportamiento del nodo en componentes especializados para configuración, estado interno, inicialización de interfaces, gestión de rutas, seguridad, transmisión, recepción, supervisión del enlace e integración del ciclo principal. La modularidad adoptada permite que cada bloque pueda ser probado de forma individual y, al mismo
tiempo, integrarse dentro de una operación distribuida completa. Cuadro 7.6: Estructura modular del sistema Archivo Responsabilidad principal config_1.py Define constantes globales, EtherType, estados del nodo, protocolos soportados, temporizadores, parámetros de LoRa, configuración de WiFi, umbrales de RSSI, sensor DHT22 y parámetros generales del sistema.
state_2.py Implementa la clase NodoESP y centraliza el estado interno del nodo: identidad, rol, padre actual, tabla de vecinos, rutas, cola de mensajes, claves compartidas, contadores, temporizadores, estado de keepalive y persistencia en JSON.
network_init_- 3.py Inicializa las interfaces de comunicación y determina el estado inicial del nodo. Gestiona la preparación del nodo como raíz o como hijo en descubrimiento y soporta la configuración operativa de los protocolos habilitados.
frames_4.py Construye, interpreta y valida las tramas del sistema. Gestiona cabeceras, EtherType, serialización, cálculo y verificación de CRC, así como procesos de descifrado y decodificación de mensajes. security_5.py Implementa el establecimiento de clave compartida mediante Diffie- Hellman y la lógica asociada al cifrado y descifrado de la información entre nodos.
routing_6.py Administra la tabla de vecinos, evalúa candidatos a padre, calcula puntajes, selecciona el mejor nodo disponible, formaliza la vinculación y actualiza la ruta válida hacia la raíz.
tx_7.py Gestiona la construcción y transmisión de mensajes de control, anuncios de descubrimiento, keepalive, vinculación y datos de aplicación a través de WiFi, ESP-NOW y LoRa.
rx_8.py Implementa el flujo completo de recepción: escucha de paquetes entrantes, identificación del protocolo y remitente, lectura de cabecera, validación de integridad, descifrado y despacho según EtherType.
keepalive_9.py Supervisa el enlace con el padre y con los hijos, envía mensajes keepalive, detecta fallos reales de conectividad y activa la lógica de recuperación del enlace.
main.py Integra todos los módulos en el ciclo principal de operación. Controla el flujo global del nodo, la post-aceptación de asociación, la lectura real del sensor DHT22, el envío de datos simulados y la operación continua de la red.
La Figura 7.2 sintetiza la interacción entre módulos dentro del ciclo principal de operación. Configuración config_1.py Estado del nodo state_2.py Inicialización Wi-Fi / ESP- NOW / LoRa Bucle principal escuchar, procesar, transmitir Recepción rx_8.py Transmisión tx_7.py Rutas y padre routing_6.py KeepAlive keepalive_9.py Figura 7.2: Flujo general del software implementado en el nodo ESP32. El ciclo principal integra la inicialización, el estado del nodo, el descubrimiento, la recepción y transmisión de mensajes, la selección de padre, la seguridad del enlace, la validación de tramas y la supervisión del enlace.
7.3.
Lógica de descubrimiento y enrutamiento La lógica de descubrimiento y enrutamiento permite que los nodos sin conectividad directa a Internet detecten vecinos, evalúen su viabilidad como posibles padres, seleccionen la mejor alternativa disponible y construyan una ruta válida hacia el nodo raíz. Este proceso se ejecuta de forma distribuida, sin coordinador externo permanente, lo que incrementa la autonomía del sistema y reduce la dependencia de infraestructura centralizada.
7.3.1.
Inicialización y determinación del rol Al arrancar, cada nodo ejecuta la secuencia representada en la Figura 7.3: carga su configuración local, inicializa los módulos de comunicación (WiFi, ESP-NOW, LoRa, sensor DHT22) y verifica si dispone de acceso a Internet.
Inicio Leer configuración Inicializar interfaces ¿Wi-Fi a Internet?
Nodo raíz Descubrimiento Actualizar estado Sí No Figura 7.3: Flujo de inicialización y determinación del rol del nodo (Sección 1 del diagrama general).
Si el nodo obtiene dirección IP válida se configura como nodo raíz: fija su nivel jerárquico en 1, activa la capacidad de aceptar hijos y selecciona el protocolo principal. En caso contrario, entra en modo descubrimiento como nodo hijo, donde permanece exclusivamente en escucha de anuncios de vecinos hasta identificar un candidato a padre válido.
7.3.2.
Descubrimiento y construcción de la tabla de vecinos La Figura 7.4 muestra el flujo diferenciado entre el nodo padre y el nodo hijo durante la fase de descubrimiento.
HIJO
escucha pasiva Recibir anuncio medir RSSI ¿Criterios mínimos?
Descartar seguir escuchando Calcular score nivel + RSSI + cupo ¿Mejor padre?
Enviar solicitud 0x9010
PADRE
envía anuncios Publica estado nivel, internet, cupos ¿Hay cupo?
Acepta vinculación Rechaza sin cupo No Sí Sí Sí No Figura 7.4: Flujo de descubrimiento diferenciado: lado padre, encargado del envío de anuncios, y lado hijo, encargado de la escucha pasiva, evaluación de candidatos y solicitud de vinculación.
Todo nodo que dispone de Internet y tiene cupo (cantidad_hijos < max_hijos) transmite periódicamente un HELLO_VECINO (0x9001) en el primer ciclo y ESTADO_VE- CINO (0x9002) en los siguientes, por todos los protocolos habilitados. El payload es una estructura binaria de 4 bytes (nivel, flags, protocolo, número de hijos). El nodo hijo mantiene una escucha pasiva multiprotocolo durante la ventana discovery_escucha_ms (1 200 ms). El RSSI se captura en el primer mensaje del vecino y no se sobreescribe, garantizando mediciones representativas del enlace real. Los vecinos con marca de tiempo superior a vecino_expira_ms (120 000 ms) son eliminados automáticamente.
7.3.3.
Selección del nodo padre y vinculación Superada la fase de evaluación, el nodo ejecuta el proceso de vinculación descrito en la Figura 7.5.
El candidato seleccionado es aquel con mayor Score según la función: Scorej = 1000+m´ax(0, 600−nivelj×60)+5·RSSI_normj+50·(max_hijos−hijosj) (7.1) Los 1 000 puntos base representan el criterio dominante de acceso a Internet. La bonificación
Seleccionar mejor padre Solicitud 0x9010 ¿Acepta vinculación?
Aceptación 0x9011 Rechazo 0x9012 Intercambio Diffie-Hellman Enlace activo Limpiar estado y reintentar Sí No Figura 7.5: Proceso de vinculación padre-hijo, respuesta con código de motivo ante rechazo, y establecimiento del enlace seguro mediante Diffie-Hellman. Secciones 1 y 2 del diagrama general.
por nivel penaliza nodos alejados de la raíz; la de RSSI premia señal fuerte; la de cupo favorece padres con menor carga.
El padre evalúa la solicitud recibida (EtherType 0x9010) y responde con ACEPTACION (0x9011) o RECHAZO (0x9012) con código de motivo (sin_cupo o sin_internet). Transcurrido vinculacion_timeout_ms sin respuesta, el hijo limpia el estado y reinicia la búsqueda.
7.4.
Integración de seguridad La seguridad se integra como parte del flujo operativo del enlace, combinando tres mecanismos complementarios: establecimiento de clave compartida mediante Diffie-Hellman (DH), protección del payload mediante cifrado XOR con clave derivada, y validación de integridad mediante CRC-16.
7.4.1.
Construcción de tramas y tipos de mensaje Todos los intercambios se ajustan al formato binario de la Figura 7.6, implementado en frames_4.py.
EtherType y número de secuencia Cabecera de 9 bytes BitArray de estado ID origen e ID destino Payload según tipo de mensaje XOR con clave DH
CRC16-CCITT
trama final Figura 7.6: Flujo de construcción de tramas: cabecera, BitArray de estado, payload por EtherType, cálculo de CRC-16 y cifrado XOR con clave DH. Sección 2 del diagrama general.
La Tabla 7.7 lista los EtherTypes implementados y su función. Cuadro 7.7: EtherTypes definidos en el sistema Valor Constante Función 0x9001
HELLO_VECINO
Primer anuncio de presencia 0x9002
ESTADO_VECINO
Anuncio periódico de estado 0x9003
INTERCAMBIO_DH
Handshake Diffie-Hellman 0x9004
KEEP_ALIVE
Supervisión periódica de enlace 0x9005
KEEP_ALIVE_ACK
Confirmación de supervisión 0x9006
CONTROL_RED
Mensajes de control interno 0x9007
DATOS_APLICACION_JSON
Datos de aplicación (JSON) 0x9008
SOLICITUD_REENVIO
Retransmisión por error CRC 0x9009
ACTUALIZACION_RUTA
Notificación de cambio de ruta 0x9010
SOLICITUD_VINCULACION
Solicitud de asociación 0x9011
ACEPTACION_VINCULACION
Confirmación de asociación 0x9012
RECHAZO_VINCULACION
Rechazo de solicitud
7.4.2.
Flujos de envío y recepción La Figura 7.7 resume los flujos de envío (izquierda) y recepción (derecha) que operan dentro del bucle principal de cada nodo.
7.4.3.
Supervisión bidireccional del enlace y recuperación La Figura 7.8 muestra la lógica de supervisión implementada en keepalive_9.py, que opera simultáneamente en ambos sentidos: el hijo supervisa el enlace hacia el padre y el padre supervisa el enlace hacia cada uno de sus hijos de forma independiente. La supervisión opera con tres parámetros clave: keepalive_interval_ms (30 000 ms), keepalive_timeout_ms (10 000 ms) y max_reintentos_keepalive (3 intentos). Cuando el hijo supera el máximo de reintentos, el sistema intenta cambiar de protocolo antes de declarar la caída del enlace: prueba WiFi, luego ESP-NOW y finalmente LoRa. Solo si ninguno responde
Flujo de envío Revisar cola Construir trama Transmitir por protocolo activo Flujo de recepción Escuchar interfaces Leer cabecera y EtherType
CRC, XOR
y despacho trama enviada Figura 7.7: Flujos de envío (izquierda) y recepción (derecha) dentro del bucle principal del nodo. Secciones 3 y 4 del diagrama general.
Hijo supervisa al padre Enviar
KEEP_ALIVE
Evaluar ACK o contacto válido Sí: mantener enlace No: cambiar protocolo o redescubrir Padre supervisa a cada hijo Enviar KA por hijo Evaluar ACK o contacto válido Sí: mantener hijo No: liberar cupo del padre Figura 7.8: Supervisión bidireccional del enlace: lado hijo hacia el padre y lado padre hacia cada hijo, con lógica de recuperación mediante cambio de protocolo y reelección de padre. Sección 5 del diagrama general.
se reinicia el descubrimiento completo.
El padre mantiene un contexto independiente por hijo en keepalive_hijos[id_hijo] con los campos ultimo_ms, ultimo_ack_ms, fallos y esperando_ack. Los hijos que no responden son descartados y su cupo queda disponible para nuevos nodos.
7.5.
Interoperabilidad entre protocolos La interoperabilidad se materializa en dos planos: la estandarización del formato lógico de mensajes (independiente del medio físico) y el flujo de datos de aplicación con reenvío salto a salto hasta la raíz.
7.5.1.
Estándar de trama multiprotocolo El campo EtherType de 2 bytes al inicio de cada trama permite que el nodo receptor identifique el tipo de mensaje sin inspeccionar el payload, desacoplando la lógica de control del medio de transmisión. La misma trama puede arribar por WiFi UDP, ESP-NOW o LoRa y ser procesada por el mismo despachador (DespacharSegunEtherType()). La Tabla 7.8 sintetiza las particularidades de cada protocolo en la implementación actual. Cuadro 7.8: Características operativas de los protocolos implementados Protocolo Alcance Payload máx.
RSSI medible Uso en la arquitectura WiFi UDP ∼100 m
65 507 B
Sí (wlan_sta) Conectividad Internet (raíz), broadcast local
ESP-NOW
∼500 m
250 B
Sí (peers_table) Descubrimiento, enlace directo, DH, KA LoRa SX1278 2–15 km
255 B
Sí (read_payload) Enlace largo alcance, alternativa de recuperación
7.5.2.
Flujo de datos de aplicación: sensor DHT22 y reenvío hasta la raíz La Figura 7.9 describe el ciclo completo que sigue una lectura del sensor DHT22 desde el nodo hoja hasta su entrega en el nodo raíz, pasando por uno o más nodos intermedios con cifrado salto a salto.
Nodo hoja H3 lee DHT22 Payload con iteración y valor Trama 0x9007
CRC + XOR
Padre P2 reenvía salto a salto Nodo raíz recibe datos Publicación
MQTT
ESP-NOW/LoRa Figura 7.9: Flujo de datos de aplicación del sensor DHT22: lectura en el nodo hoja, cifrado salto a salto en nodos intermedios con preservación de autoría, y entrega final en la raíz con publicación opcional vía MQTT. Sección 6 del diagrama general. Tres reglas gobiernan el reenvío:
1. El campo id_destino de cada trama siempre apunta al siguiente salto (padre inme-
diato), no al destino final.
2. El payload JSON conserva origen_sensor para que la raíz conozca el nodo físico que
originó el dato.
3. El campo saltos se incrementa en cada reenvío para depuración de la profundidad del
árbol.
El sensor DHT22 real tiene prioridad; si no está habilitado (dht22_habilitado = False), el sistema genera lecturas simuladas como fallback (temperatura aleatoria en [20, 30] ◦C). Ambos modos respetan el intervalo dht22_intervalo_ms (10 000 ms) y solo transmiten si el enlace con el padre está activo.
En el nodo raíz, los datos recibidos se entregan al hook on_datos_aplicacion_raiz(), conectado en main.py al publicador umqtt.robust para integración con servicios externos. Esto extiende la interoperabilidad desde el plano de comunicación local hasta la capa de aplicación, completando la cadena desde la percepción física hasta la nube.
Capítulo 8 Resultados del proyecto Nota sobre las figuras generadas con apoyo de IA: las topologías, diagramas esquemáticos y representaciones visuales no provenientes directamente de capturas de terminal o registros MQTT fueron elaboradas por los autores con apoyo de herramientas de inteligencia artificial generativa, a partir de los resultados experimentales, los archivos de prueba y la configuración real de los nodos ESP32. Las capturas de terminal, registros MQTT y evidencias de ejecución corresponden directamente a los archivos obtenidos durante las pruebas.
8.1.
Organización del análisis experimental En este capítulo se presentan primero los resultados objetivos obtenidos en las pruebas y, posteriormente, su interpretación técnica. La descripción objetiva incluye publicaciones MQTT, iteraciones únicas recibidas, tiempos de prueba, saltos de iteración, eventos de KeepAlive, reconexiones y evidencias de seguridad. La discusión técnica se reserva para explicar el significado de estos datos en términos de interoperabilidad, resiliencia, continuidad operativa y limitaciones del prototipo.
Para fortalecer la interpretación cuantitativa, se incorporan indicadores estadísticos descriptivos cuando el conjunto de datos lo permite. Es importante aclarar que no todos los escenarios cuentan con varias repeticiones bajo condiciones idénticas. En los casos donde solo existe una ejecución registrada, se reporta el valor obtenido y se indica que la desviación estándar no aplica. En las comparaciones por versión, el promedio y la desviación estándar se calculan como estadística descriptiva entre versiones de prueba, no como inferencia estadística de repeticiones idénticas.
Cuadro 8.1: Criterio de tratamiento estadístico de los escenarios experimentales Tipo de escenario Número de ejecuciones registradas Tratamiento cuantitativo aplicado Alcance de interpretación Pruebas individuales por protocolo
1 por protocolo
Efectividad, pérdida, tiempo de prueba y saltos de iteración.
Validación funcional inicial del enlace y publicación
MQTT.
Pruebas simultáneas V1, V2 y V3
3 versiones comparables
Promedio, desviación estándar, mínimo y máximo entre versiones.
Comparación descriptiva del efecto de los ajustes de código.
Pruebas de reconexión y reelección
1 por escenario de falla
Línea temporal de eventos, tiempos de pérdida y recuperación.
Validación funcional de resiliencia ante pérdida de enlace.
Pruebas con seis nodos
1 por configuración de topología
Evidencia de publicaciones, nodos activos y organización jerárquica.
Validación de operación multiprotocolo y capacidad de asociación.
Cuadro 8.2: Estadística descriptiva de efectividad en pruebas simultáneas por versión Protocolo Versiones consideradas Efectividad promedio Desviación estándar Mínimo Máximo LoRa V1, V2, V3
72,07 %
39,49 %
26,60 %
97,80 %
ESP-NOW
V1, V2, V3
64,33 %
27,39 %
39,00 %
93,40 %
Global V1, V2, V3
68,20 %
9,90 %
60,00 %
79,20 %
La Tabla 8.2 permite observar la variabilidad generada por los ajustes progresivos del código. LoRa presentó el valor máximo más alto en V3, pero también la mayor dispersión entre versiones, debido a que en V1 su desempeño simultáneo fue bajo. ESP-NOW presentó un valor alto en V1, una caída en V2 y una recuperación parcial en V3. Esta variabilidad confirma que el comportamiento de los protocolos no depende únicamente del medio de comunicación, sino también de la distribución del tiempo de escucha, la carga del ciclo principal, la simultaneidad de tareas y la configuración de cada versión.
8.2.
Pruebas de validación de transmisión de datos Con base en las métricas definidas en la metodología, en esta sección se presentan las pruebas realizadas para validar la transmisión de datos dentro de la arquitectura multiprotocolo implementada. Las pruebas se enfocaron en verificar que un nodo emisor pudiera enviar mensajes simulados de temperatura hacia el nodo raíz y que este, posteriormente, publicara la información recibida en el broker MQTT.
Para facilitar el seguimiento de los mensajes, cada paquete incluyó campos de trazabilidad como el identificador del nodo origen, el número de iteración, el total de mensajes configurados, el protocolo utilizado, el número de saltos y el nodo raíz encargado de la publicación. De esta forma, fue posible observar el avance de la transmisión y validar la llegada de mensajes iniciales, intermedios y finales.
Es importante tener en cuenta que los resultados presentados corresponden a la configuración ajustada para la etapa experimental. En dicha configuración se aumentaron los tiempos de escucha, se redujo el intervalo de descubrimiento y se optimizó el procesamiento de LoRa para mejorar la recepción de mensajes. Por tanto, los porcentajes de efectividad reflejan el comportamiento del sistema después de aplicar estos ajustes de prueba.
8.2.1.
Prueba por ESP-NOW con publicación MQTT Con el fin de realizar una validación inicial del funcionamiento del protocolo ESP-NOW dentro de la red multiprotocolo, se ejecutó una prueba básica de transmisión de datos hacia el nodo raíz ESP_001. Esta prueba no tuvo como objetivo evaluar el desempeño definitivo del sistema bajo condiciones críticas, sino comprobar que el enlace ESP-NOW se encontraba operativo, que los nodos podían transmitir información hacia la raíz y que los datos recibidos podían ser publicados posteriormente en el broker MQTT.
Durante esta validación, el protocolo ESP-NOW fue utilizado como enlace de comunicación entre los nodos sensores y el nodo raíz ESP_001, encargado de recibir la información y reenviarla hacia el tópico MQTT correspondiente. De esta manera, se verificó el flujo básico de comunicación desde la generación del dato en el nodo origen, su transmisión mediante ESP-NOW y su publicación final en el broker.
La prueba consistió en el envío de un total de 500 mensajes simulados de temperatura. Cada mensaje incluyó un identificador de iteración, el número total de iteraciones configuradas, el identificador del nodo origen, el protocolo utilizado y el nodo raíz que recibió la información. Esto permitió validar el orden de transmisión, la continuidad de los mensajes y la correcta publicación de los datos recibidos.
En las capturas obtenidas desde el cliente MQTT se observa la publicación de los mensajes en el tópico RED_MULTIPROTOCOLO_ESP. Los datos publicados contienen campos como origen_sensor, iteracion, total_iteraciones, nodo_raiz, tp y el valor de temperatura simulado. La presencia de mensajes iniciales, intermedios y finales permite evidenciar que la prueba se
ejecutó hasta alcanzar la iteración 500, confirmando así que el protocolo ESP-NOW operaba correctamente como enlace de transmisión dentro de esta etapa inicial de validación. Figura 8.1: Publicación MQTT de los primeros mensajes recibidos durante la prueba de transmisión por ESP-NOW. Se observa el inicio de la secuencia con las iteraciones 1, 2 y 3 correspondientes al protocolo ESP-NOW.
Figura 8.2: Publicación MQTT de mensajes intermedios de la prueba por ESP-NOW. Se evidencian iteraciones consecutivas cercanas a la mitad de la prueba, lo cual permite validar la continuidad de la transmisión.
Figura 8.3: Publicación MQTT de los mensajes finales de la prueba por ESP-NOW. Se observa la llegada de las iteraciones 498, 499 y 500, confirmando la finalización del envío configurado de 500 mensajes.
A partir de esta prueba se puede concluir que el nodo raíz recibió los mensajes enviados mediante ESP-NOW y logró publicarlos en MQTT sin interrumpir el flujo principal del sistema. Además, el uso del campo iteracion permitió comprobar el avance de la prueba y confirmar que se alcanzó el total de 500 transmisiones configuradas.
8.2.2.
Prueba por LoRa con publicación MQTT Con el propósito de evaluar el comportamiento de la red multiprotocolo bajo una tecnología de mayor alcance, se realizó una prueba de transmisión utilizando el protocolo LoRa. En esta prueba, LoRa fue evaluado como enlace de envío hacia el nodo raíz ESP_001, encargado de recibir los datos y publicarlos posteriormente en el broker MQTT. Durante las pruebas, ESP_002 correspondió al enlace LoRa.
La prueba consistió en el envío de 500 mensajes simulados de temperatura. Cada mensaje incluyó campos de control como el identificador del nodo origen, el número de iteración, el total de iteraciones configuradas, el número de saltos, el protocolo utilizado, el valor simulado de temperatura y el nodo raíz que recibió la información.
En las capturas obtenidas desde el cliente MQTT se observa que los mensajes fueron publicados en el tópico RED_MULTIPROTOCOLO_ESP. El campo pc presenta el valor 3, correspondiente al protocolo LoRa dentro de la codificación definida en el sistema. Asimismo, se evidencian mensajes en diferentes puntos de la prueba, incluyendo iteraciones iniciales, intermedias y finales, lo cual permite validar la continuidad del envío hasta alcanzar la iteración 500.
Figura 8.4: Publicación MQTT de mensajes iniciales de la prueba de transmisión por LoRa. Se observan las iteraciones 29, 40 y 41 correspondientes al protocolo LoRa y publicadas por el nodo raíz ESP_001.
Figura 8.5: Publicación MQTT de mensajes intermedios de la prueba por LoRa. Se visualizan iteraciones cercanas a la mitad de la prueba, lo cual permite comprobar la continuidad de la transmisión durante el envío de los 500 mensajes.
Figura 8.6: Publicación MQTT de los mensajes finales de la prueba por LoRa. Se observan las iteraciones 498, 499 y 500, confirmando que el sistema completó el envío configurado de 500 mensajes.
A partir de esta prueba se evidencia que el sistema logró transmitir datos mediante LoRa y publicar la información recibida en MQTT. Aunque LoRa presenta una velocidad de transmisión menor en comparación con ESP-NOW, su integración dentro de la red permite ampliar el alcance de comunicación del sistema, lo cual resulta útil en escenarios donde los nodos se encuentran más alejados o donde se requiere comunicación de baja tasa de datos.
8.3.
Pruebas de comunicación para las diferentes versiones del sistema (V1, V2, V3)
8.3.1.
Prueba con la versión 1 del código Con el fin de realizar una validación inicial del comportamiento de transmisión de datos en la primera versión del código, se ejecutaron pruebas de publicación MQTT empleando los protocolos ESP-NOW y LoRa. Esta prueba tuvo como propósito verificar que los nodos hijos pudieran generar datos, transmitirlos hacia el nodo raíz ESP_001 y que este último publicara correctamente la información en el tópico MQTT RED_MULTIPROTOCOLO_ESP.
La evaluación se realizó en tres escenarios: una prueba individual con ESP-NOW, una prueba individual con LoRa y una prueba simultánea en la que ambos protocolos transmitieron datos hacia el nodo raíz. Para el análisis cuantitativo se tomó como referencia un total de 500 mensajes esperados por protocolo, considerando el campo iteracion como identificador de continuidad de la secuencia recibida.
Cuadro 8.3: Resumen cuantitativo de la primera prueba con la versión 1 del código Escenario Protocolo Nodo origen Publicaciones MQTT Iteraciones únicas Tiempo de prueba Efectividad Pérdida Prueba individual
ESP-NOW
ESP_003
409
409/500
1 h 43 min 13 s
81.80 %
18.20 %
Prueba individual LoRa
ESP_002
422
415/500
2 h 01 min 23 s
83.00 %
17.00 %
Prueba simultánea
ESP-NOW
ESP_003
468
467/500
1 h 49 min 34 s
93.40 %
6.60 %
Prueba simultánea LoRa
ESP_002
164
133/500
1 h 51 min 01 s
26.60 %
73.40 %
En la Tabla 8.3 se observa que, durante las pruebas individuales, ambos protocolos lograron publicar información en MQTT; sin embargo, no se alcanzó el 100 % de los mensajes esperados. ESP-NOW registró 409 publicaciones MQTT, equivalentes a una efectividad de
81.80 %, mientras que LoRa registró 415 iteraciones únicas dentro del rango esperado de
500 mensajes, alcanzando una efectividad de 83.00 %. Aunque LoRa presentó un porcentaje
ligeramente superior en la prueba individual, también se identificaron publicaciones duplicadas y una interrupción parcial de la secuencia, lo que indica que el comportamiento no fue completamente continuo.
En la prueba simultánea, ESP-NOW presentó el mejor desempeño de la versión 1, con 467 iteraciones únicas recibidas de 500 esperadas, lo que representa una efectividad de 93.40 % y una pérdida de 6.60 %. En contraste, LoRa presentó una reducción significativa en la recepción, con 133 iteraciones únicas dentro del rango esperado, equivalente a una efectividad de 26.60 % y una pérdida de 73.40 %. Este comportamiento evidencia que, bajo transmisión simultánea y condiciones degradadas de conexión, LoRa fue el protocolo más afectado en términos de continuidad y estabilidad de publicación.
Cuadro 8.4: Tiempos promedio de publicación MQTT en la primera prueba V1 Escenario Protocolo Hora inicial Hora final Promedio entre publicaciones Prueba individual
ESP-NOW
15:35:47 17:19:00
15.18 s/publicación
Prueba individual LoRa 17:40:20 19:41:43
17.30 s/publicación
Prueba simultánea
ESP-NOW
15:23:54 17:13:28
14.08 s/publicación
Prueba simultánea LoRa 15:23:50 17:14:51
40.86 s/publicación
La Tabla 8.4 permite comparar el ritmo de publicación de cada protocolo. En las pruebas individuales, ESP-NOW presentó un promedio aproximado de 15.18 segundos por publicación, mientras que LoRa presentó un promedio de 17.30 segundos por publicación. No obstante, en la prueba simultánea se evidenció una diferencia considerable: ESP-NOW mantuvo un promedio de 14.08 segundos por publicación, mientras que LoRa aumentó hasta 40.86 segundos por publicación. Esto indica que LoRa tuvo mayores pausas entre mensajes publicados, lo cual coincide con la pérdida de continuidad observada en la secuencia de iteraciones. Cuadro 8.5: Principales pérdidas de tramas detectadas en la primera prueba V1 Escenario Protocolo Tramas perdidas Iteración en la que se recuperó Hora de recuperación Prueba individual
ESP-NOW
33–48
49
15:45:47 Prueba individual
ESP-NOW
272–274
275
16:34:44 Prueba individual
ESP-NOW
149–150
151
16:07:48 Prueba individual LoRa 15–41
42
17:47:25 Prueba individual LoRa 9–11
12
17:41:50 Prueba individual LoRa 121–122
123
18:27:43 Prueba simultánea
ESP-NOW
246–259
260
16:20:45 Prueba simultánea
ESP-NOW
204–215
216
16:10:59 Prueba simultánea LoRa 261–273
274
16:14:51 Prueba simultánea LoRa 101–111
112
15:44:00 Prueba simultánea LoRa 248–257
258
16:11:48 La Tabla 8.5 muestra que las pérdidas no ocurrieron únicamente al inicio o al final de las pruebas, sino también durante la operación continua. En la prueba individual ESP-NOW, el salto más representativo se presentó entre las iteraciones 32 y 49, donde no se recibieron las tramas 33 a 48, para una pérdida puntual de 16 mensajes. A pesar de esto, el protocolo logró recuperar la secuencia posteriormente y continuar publicando datos. En la prueba individual LoRa, se observó una pérdida más marcada entre las iteraciones
14 y 42, donde no se recibieron las tramas 15 a 41. Además, el archivo evidencia una in-
terrupción parcial de la prueba, seguida de un reinicio de la secuencia de iteraciones. Por esta razón, aunque LoRa alcanzó una efectividad global de 83.00 % en iteraciones únicas, su comportamiento presentó mayor inestabilidad temporal que ESP-NOW. En la prueba simultánea, ESP-NOW mantuvo una mejor continuidad general, aunque presentó pérdidas puntuales de 12 y 14 mensajes en algunos tramos. Por otro lado, LoRa registró pérdidas recurrentes y de mayor impacto, lo cual explica su baja efectividad de 26.60 % en este escenario. Esto sugiere que, en la versión 1 del código, LoRa fue más sensible a las con-
diciones de enlace, tiempos de espera, colisiones o limitaciones de recepción cuando operó junto con otro protocolo.
Figura 8.7: Inicio de la prueba individual con ESP-NOW y publicación de datos simulados desde ESP_003.
Figura 8.8: Inicio de la prueba individual con LoRa y publicación de datos desde ESP_002.
Figura 8.9: Evidencia de prueba simultánea ESP-NOW y LoRa Figura 8.10: Publicaciones MQTT durante la prueba simultánea con ESP-NOW y LoRa hacia el nodo raíz ESP_001.
A partir de los resultados obtenidos, se concluye que la primera versión del código permitió validar correctamente el flujo principal de transmisión: generación del dato en el nodo hijo, envío hacia el nodo raíz y publicación final en MQTT. Sin embargo, también se evidenciaron pérdidas de continuidad en las iteraciones, especialmente en LoRa y en el escenario simultáneo. ESP-NOW mostró un comportamiento más estable, principalmente en la prueba simultánea, donde alcanzó una efectividad de 93.40 %. LoRa, aunque funcionó en la prueba individual, presentó mayor variabilidad y una disminución considerable de desempeño cuando compartió el escenario de operación con ESP-NOW.
Estos resultados permiten establecer una línea base para la versión 1 del sistema. La prueba
confirma que la arquitectura general funciona, pero también evidencia la necesidad de mejorar los mecanismos de control de pérdidas, reintentos, confirmación de recepción y manejo de colas para aumentar la confiabilidad de la red multiprotocolo en versiones posteriores.
8.3.2.
Prueba con la versión 2 del código La segunda versión del código fue evaluada mediante una prueba de transmisión simultánea hacia el nodo raíz ESP_001, utilizando publicaciones MQTT en el tópico RED_MULTIPROTO- COLO_ESP. En esta versión se buscó mejorar el comportamiento de recepción y continuidad de la red cuando operan enlaces asociados a LoRa y ESP-NOW, manteniendo la publicación final de los datos recibidos en el broker MQTT.
A diferencia de la primera versión, esta prueba no corresponde únicamente a una validación inicial de funcionamiento, sino a una evaluación más prolongada del comportamiento de la red bajo operación continua. En esta prueba, el nodo ESP_002 correspondió al enlace LoRa y estuvo asociado a lecturas reales del sensor DHT22; mientras que el nodo ESP_003 correspondió al enlace ESP-NOW y estuvo asociado a datos de temperatura simulada. Para el análisis cuantitativo se tomó como referencia un total esperado de 500 iteraciones por protocolo, utilizando el campo iteracion como identificador de continuidad. Cuadro 8.6: Resumen cuantitativo de recepción y publicación MQTT en la versión 2 Protocolo Nodo asociado Publicaciones MQTT Mensajes esperados Iteraciones únicas recibidas Tiempo de prueba Efectividad Pérdida LoRa
ESP_002
459
500
459
1 h 22 min 56.88 s
91.80 %
8.20 %
ESP-NOW
ESP_003
195
500
195
1 h 22 min 15.65 s
39.00 %
61.00 %
Total –
654
1000
654
–
65.40 %
34.60 %
La Tabla 8.6 muestra que el protocolo LoRa presentó el mejor comportamiento durante la prueba, con 459 publicaciones MQTT correspondientes a 459 iteraciones únicas. Esto representa una efectividad del 91.80 % respecto a las 500 iteraciones esperadas, con una pérdida estimada del 8.20 %. Este resultado evidencia una mejora importante en la continuidad del flujo de datos para el enlace LoRa, ya que la mayoría de las lecturas reales del sensor DHT22 fueron recibidas y publicadas correctamente por el nodo raíz.
Por otra parte, el protocolo ESP-NOW registró 195 publicaciones MQTT, equivalentes a 195 iteraciones únicas sobre las 500 esperadas. Esto representa una efectividad del 39.00 % y una pérdida estimada del 61.00 %. Aunque el enlace logró publicar datos durante un periodo prolongado, la continuidad fue menor, evidenciando saltos frecuentes en la secuencia de iteraciones. Esto indica que la versión 2 permitió mantener la operación general de la red, pero
todavía presentó diferencias importantes de desempeño entre los protocolos evaluados. Cuadro 8.7: Resumen temporal de publicaciones MQTT en la versión 2 Protocolo Primera publicación Última publicación Intervalo promedio entre publicaciones Mayor intervalo sin publicación LoRa 20:03:16.063 21:26:12.943
10.87 s
30.85 s
ESP-NOW
20:03:41.357 21:25:57.002
25.44 s
265.83 s
En la Tabla 8.7 se observa que ambos protocolos permanecieron activos durante un tiempo similar, superior a una hora y veinte minutos. Sin embargo, el comportamiento temporal fue diferente. LoRa mantuvo un intervalo promedio cercano a 10.87 segundos entre publicaciones, lo cual evidencia una transmisión periódica más estable. En cambio, ESP-NOW presentó un intervalo promedio de 25.44 segundos y un intervalo máximo sin publicación de 265.83 segundos, lo cual evidencia interrupciones más prolongadas durante la prueba. Cuadro 8.8: Principales saltos de iteración detectados en la versión 2 Protocolo Última iteración antes de la pérdida Hora de pérdida Iteración donde se recupera Hora de recuperación Pérdida estimada LoRa
371
21:06:16.938
374
21:06:47.791
2 mensajes
LoRa
387
21:09:00.361
389
21:09:21.457
1 mensaje
LoRa
129
20:25:03.423
131
20:25:24.210
1 mensaje
ESP-NOW
158
20:33:58.368
170
20:36:06.256
11 mensajes
ESP-NOW
57
20:13:14.600
66
20:17:40.434
8 mensajes
ESP-NOW
264
20:52:46.674
272
20:54:12.302
7 mensajes
ESP-NOW
187
20:39:08.542
195
20:40:32.206
7 mensajes
ESP-NOW
149
20:32:24.568
156
20:33:38.400
6 mensajes
La Tabla 8.8 permite identificar que las pérdidas del protocolo LoRa fueron menores y más aisladas. El salto más relevante ocurrió entre las iteraciones 371 y 374, con dos mensajes intermedios no publicados. En los demás casos, la pérdida fue de un solo mensaje, lo que indica que, aunque existieron interrupciones, la recuperación del flujo fue rápida. En contraste, ESP-NOW presentó saltos más marcados. El evento más significativo ocurrió entre las iteraciones 158 y 170, con una pérdida estimada de 11 mensajes. También se observaron saltos de 8, 7 y 6 mensajes en diferentes puntos de la prueba. Estos resultados evidencian que el enlace ESP-NOW presentó una menor continuidad y periodos más largos sin publicación en el broker MQTT durante esta prueba.
Figura 8.11: Publicaciones MQTT recibidas durante la prueba multiprotocolo con ESP-NOW y LoRa en la versión 2. Se observa una mayor cantidad de registros provenientes del nodo ESP_002, correspondientes a lecturas reales del sensor DHT22, junto con algunas publicaciones del nodo ESP_003 asociadas a datos de temperatura simulada. En ambos casos, los mensajes son enviados hacia el nodo raíz ESP_001, evidenciando la recepción de datos desde diferentes nodos de la red multiprotocolo.
Figura 8.12: Evidencia de saltos de iteración detectados durante la prueba de la versión 2. Estos saltos permiten estimar los mensajes no publicados en el broker MQTT para LoRa y
ESP-NOW.
En términos generales, la versión 2 evidencia una mejora importante para el protocolo Lo-
Ra, el cual alcanzó una efectividad superior al 90 %. Esto permite concluir que los ajustes realizados en esta versión favorecieron la estabilidad de este enlace durante la transmisión de datos hacia el nodo raíz. Sin embargo, el comportamiento de ESP-NOW muestra que todavía existían limitaciones en la operación simultánea, especialmente por los intervalos prolongados sin publicación y por la cantidad de saltos de iteración observados.
8.3.3.
Prueba con la versión 3 del código La tercera versión del código fue evaluada mediante una prueba de transmisión simultánea hacia el nodo raíz ESP_001, utilizando publicaciones MQTT en el tópico RED_MULTIPRO- TOCOLO_ESP. En esta prueba se mantuvo la operación conjunta de los protocolos LoRa y ESP-NOW, con el propósito de validar el comportamiento de la red bajo una condición de funcionamiento más cercana a una operación continua.
Para esta versión, el nodo ESP_002 correspondió al enlace LoRa y estuvo asociado a lecturas reales del sensor DHT22. Por otra parte, el nodo ESP_003 correspondió al enlace ESP-NOW y transmitió datos de temperatura simulada. El análisis cuantitativo se realizó tomando como referencia 500 iteraciones esperadas por protocolo, utilizando el campo iteracion como indicador de continuidad de la transmisión.
Cuadro 8.9: Resumen cuantitativo de recepción y publicación MQTT en la versión 3 Protocolo Nodo asociado Publicaciones MQTT Mensajes esperados Iteraciones únicas 1–500 Tiempo de prueba Efectividad Pérdida LoRa
ESP_002
489
500
489
1 h 40 min 00.52 s
97.80 %
2.20 %
ESP-NOW
ESP_003
313
500
303
1 h 29 min 53.80 s
60.60 %
39.40 %
Total –
802
1000
792
–
79.20 %
20.80 %
La Tabla 8.9 muestra que la versión 3 presentó una mejora importante en el comportamiento global de la red. El protocolo LoRa, asociado al nodo ESP_002, alcanzó 489 iteraciones válidas de 500 esperadas, lo que representa una efectividad del 97.80 %. Este resultado evidencia una transmisión mucho más estable para las lecturas reales del sensor DHT22, con una pérdida estimada de solo 2.20 %.
En el caso de ESP-NOW, asociado al nodo ESP_003, se registraron 313 publicaciones MQTT. Sin embargo, para el cálculo de efectividad se consideraron únicamente las iteraciones dentro del rango esperado de 1 a 500, obteniendo 303 iteraciones válidas. Esto representa una efectividad del 60.60 % y una pérdida del 39.40 %. Aunque este resultado continúa mostrando pérdidas relevantes, representa una mejora frente a la versión 2, donde ESP-NOW había presentado una efectividad menor. Por lo tanto, la versión 3 puede considerarse una configu-
ración más equilibrada para operación simultánea, especialmente por la recuperación parcial del enlace ESP-NOW y la alta estabilidad alcanzada por LoRa.
Cuadro 8.10: Resumen temporal de publicaciones MQTT en la versión 3 Protocolo Primera publicación Última publicación considerada Intervalo promedio Mayor intervalo sin publicación LoRa 11:34:31.213 13:14:31.730
12.30 s
26.35 s
ESP-NOW
11:34:04.487 13:03:58.283
17.86 s
223.17 s
En la Tabla 8.10 se observa que LoRa mantuvo un comportamiento más constante durante toda la prueba. Su intervalo promedio entre publicaciones fue de aproximadamente 12.30 segundos, con un intervalo máximo sin publicación de 26.35 segundos. Esto indica que, aunque se presentaron pérdidas puntuales, el flujo de datos se recuperó rápidamente. Por el contrario, ESP-NOW presentó un intervalo promedio mayor, de aproximadamente
17.86 segundos, y un intervalo máximo sin publicación de 223.17 segundos. Este comporta-
miento evidencia que las pérdidas de ESP-NOW no fueron solamente eventos aislados de una iteración, sino interrupciones más prolongadas en algunos puntos de la prueba. Figura 8.13: Publicaciones MQTT iniciales del protocolo LoRa en la versión 3, correspondiente al nodo ESP_002. Se observan lecturas reales del sensor DHT22 publicadas por el nodo raíz ESP_001.
Figura 8.14: Publicaciones MQTT iniciales del protocolo ESP-NOW en la versión 3, correspondiente al nodo ESP_003. Se observan datos de temperatura simulada publicados en el tópico RED_MULTIPROTOCOLO_ESP.
Cuadro 8.11: Principales saltos de iteración identificados durante la prueba de la versión 3. Protocolo Última iter. antes Hora de pérdida Iter. recuperación Hora recuperación Pérdida estimada LoRa
2
11:34:44.218
4
11:35:07.362
1 mensaje
LoRa
20
11:38:20.886
22
11:38:46.922
1 mensaje
LoRa
344
12:43:33.515
346
12:43:59.863
1 mensaje
LoRa
454
13:05:40.256
456
13:06:06.131
1 mensaje
ESP-NOW
468
12:57:55.523
487
13:01:38.692
18 mensajes
ESP-NOW
124
11:55:52.149
141
11:59:09.272
16 mensajes
ESP-NOW
237
12:16:14.818
254
12:19:45.867
16 mensajes
ESP-NOW
90
11:49:46.372
95
11:50:40.852
4 mensajes
A partir de los saltos de iteración identificados en la Tabla 8.11, se evidencia que las pérdidas de LoRa fueron puntuales y de baja magnitud, ya que en los eventos más representativos solo se presentó la ausencia de una iteración entre el último dato recibido y la recuperación del flujo. Esto indica que, aunque existieron interrupciones breves, el protocolo logró restablecer la transmisión rápidamente y mantener una continuidad adecuada durante la prueba. Por el contrario, ESP-NOW presentó saltos de iteración más amplios, con pérdidas estimadas
de 4, 16 y hasta 18 mensajes en los eventos analizados. Estos saltos reflejan periodos de interrupción más prolongados en la recepción de datos, lo cual afecta directamente su efectividad global. Sin embargo, a pesar de estas pérdidas, el protocolo logró recuperar el envío de publicaciones MQTT y continuar operando dentro de la red multiprotocolo, lo que demuestra que la versión 3 permitió una recuperación funcional del enlace, aunque no completamente estable.
En términos generales, la versión 3 presentó el mejor comportamiento global de las pruebas simultáneas. La efectividad total fue del 79.20 %, calculada sobre 792 iteraciones válidas recibidas de 1000 esperadas. El resultado más destacado fue el desempeño de LoRa, que alcanzó una efectividad del 97.80 %, con pérdidas mínimas y rápida recuperación. ESP-NOW continuó presentando pérdidas importantes, pero logró una mejora frente a la versión anterior, alcanzando una efectividad del 60.60 %. Esto permite concluir que la versión 3 mejora la operación simultánea de la red multiprotocolo, aunque todavía se requiere optimizar la estabilidad del enlace ESP-NOW para reducir los saltos prolongados de iteración. De esta manera, la evidencia confirma que la versión 3 representa un avance frente a las pruebas anteriores, especialmente por la alta estabilidad observada en LoRa y por la capacidad de ESP-NOW de recuperar la comunicación después de interrupciones. No obstante, los saltos registrados en ESP-NOW muestran que la coexistencia de protocolos aún genera afectaciones en la continuidad del flujo de datos, por lo que futuras mejoras deben orientarse a la gestión de tiempos de transmisión, reintentos y priorización de mensajes.
8.3.4.
Comparación de versiones de prueba V1, V2 y V3 Además de las pruebas individuales y de mala conexión, se analizaron tres versiones sucesivas del código, denominadas V1, V2 y V3. Cada versión corresponde a modificaciones controladas realizadas sobre la lógica de escucha, transmisión, prioridad de protocolos y distribución de roles dentro de la red, con el propósito de mejorar la recepción de mensajes y comparar el comportamiento de ESP-NOW y LoRa cuando operan de manera individual o simultánea. Para la comparación de las tres versiones se tomó como referencia una topología jerárquica tipo árbol. En esta topología, el nodo ESP_001 actúa como nodo raíz, debido a que dispone de conexión a Internet y se encarga de recibir la información proveniente de los demás nodos para publicarla posteriormente en el broker MQTT. A partir de este nodo raíz se organizan nodos intermedios y nodos finales, los cuales se comunican mediante enlaces ESP-NOW o LoRa, según la configuración definida en cada versión de prueba.
La topología empleada permitió evaluar no solo la cantidad de mensajes recibidos por protocolo, sino también el efecto que tienen la distribución de roles, la asignación de hijos y la prioridad de escucha sobre el desempeño global de la red. En este sentido, las versiones V1, V2 y V3 no se compararon únicamente por la efectividad individual de LoRa o ESP-NOW, sino también por su capacidad de mantener una recepción equilibrada cuando ambos enlaces participan dentro de una misma arquitectura de comunicación.
Topología de comparación de versiones V1, V2 y V3 Nodo raíz
ESP_001
Publicación MQTT Nodo de prueba
ESP_002
Protocolo LoRa Nodo de prueba
ESP_003
Protocolo ESP-NOW Esquema general de validación para comparar las tres versiones del código Figura 8.15: Topología utilizada para la comparación de las versiones V1, V2 y V3. La Figura 8.15 muestra la estructura general considerada para las pruebas. En ella se observa que el nodo raíz recibe información desde diferentes ramas de la red. Algunas ramas están conformadas por enlaces ESP-NOW y otras por enlaces LoRa, permitiendo validar el comportamiento de la arquitectura multiprotocolo bajo diferentes configuraciones. Esta distribución fue importante para identificar si las pérdidas de mensajes estaban asociadas al protocolo utilizado, a la prioridad de escucha o a la forma en que los nodos fueron organizados dentro de la topología.
En todos los casos, la validación se realizó a partir de los archivos TXT de publicación MQTT y, para V3, también se revisaron los registros internos del nodo raíz y del enlace ESP-NOW. Adicionalmente, se corrigió la interpretación de V3 a partir del archivo definitivo suministrado para esta versión: dicho código corresponde a la configuración de LoRa, preparada para trabajar con lectura real del sensor DHT22.
Saltos de iteración en las versiones V2 y V3
Para complementar el análisis porcentual, se revisaron los principales saltos de iteración en las versiones V2 y V3. Estos saltos permiten identificar tramos en los que el broker MQTT dejó de recibir publicaciones consecutivas de un protocolo. Por esta razón, el análisis no se presenta en función de las líneas del archivo TXT, sino a partir de la iteración previa a la interrupción, el tiempo estimado sin publicación y la iteración en la que se recuperó nuevamente la recepción.
Cuadro 8.12: Principales interrupciones de publicación detectadas en V2 Protocolo Última iteración recibida Iteración de recuperación Mensajes perdidos Tiempo sin publicación LoRa
371
374
2
30.853 s
ESP-NOW
158
170
11
127.888 s
ESP-NOW
57
66
8
265.834 s
ESP-NOW
187
195
7
83.664 s
ESP-NOW
264
272
7
85.628 s
Cuadro 8.13: Principales interrupciones de publicación detectadas en V3 Protocolo Última iteración recibida Iteración de recuperación Mensajes perdidos Tiempo sin publicación LoRa
2
4
1
23.144 s
LoRa
18
20
1
23.026 s
ESP-NOW
468
487
18
223.169 s
ESP-NOW
124
141
16
197.123 s
ESP-NOW
237
254
16
211.049 s
En la Tabla 8.12 se observa que, para la versión V2, la interrupción más representativa en LoRa fue de solo 2 mensajes, con un tiempo sin publicación de 30.853 s. En cambio, ESP- NOW presentó interrupciones más prolongadas, destacándose un evento entre las iteraciones
57 y 66, donde se perdieron 8 mensajes y el tiempo sin publicación fue de 265.834 s. Esto
evidencia que, aunque ESP-NOW continuó funcionando, su recepción MQTT presentó pausas más extensas durante la prueba.
En la Tabla 8.13 se evidencia una mejora importante para LoRa, ya que los principales saltos fueron únicamente de una iteración, con tiempos sin publicación cercanos a 23 s. Esto indica que la versión V3 permitió una recuperación más rápida y estable para el enlace LoRa. Por el contrario, ESP-NOW continuó presentando interrupciones más amplias, con pérdidas de 16 a 18 mensajes y tiempos sin publicación superiores a 190 s. Esta diferencia explica por qué, dentro de V3, LoRa alcanzó una efectividad de 97.80 %, mientras que ESP-NOW quedó en 60.60 %.
Eventos de supervisión en la versión V3 El archivo interno del nodo raíz en V3 permitió revisar eventos de supervisión asociados al protocolo ESP-NOW. En el registro se observaron fallos consecutivos de KeepAlive para dicho enlace, seguido de descarte por agotamiento de reintentos y posterior aparición de nuevos KA ACK. Esto indica que el sistema detectó la pérdida de contacto, ejecutó su lógica de supervisión y volvió a observar respuestas del nodo cuando el enlace estuvo disponible nuevamente.
Cuadro 8.14: Eventos de pérdida y recuperación observados en el enlace ESP-NOW durante V3 Tiempo sin contacto / evento Evento registrado Interpretación
51.432 s
Fallo KA enlace ESP-NOW #1, sin contacto de 51432 ms Inicio de pérdida temporal del enlace ESP-NOW.
82.168 s
Fallo KA enlace ESP-NOW #2, sin contacto de 82168 ms Persistencia de la falta de respuesta del enlace.
112.984 s
Fallo KA enlace ESP-NOW #3, sin contacto de 112984 ms Aumento del contador de fallos de supervisión.
143.655 s
Fallo KA enlace ESP-NOW #4, sin contacto de 143655 ms El enlace continúa sin confirmar contacto.
Evento de descarte por reintentos agotados Fallo KA enlace ESP-NOW #5 y descarte por KA agotado El nodo raíz descarta temporalmente el enlace no responsivo después de alcanzar el número máximo de fallos permitidos.
Recuperación posterior del enlace KA ACK enlace ESP-NOW OK Se evidencia nuevamente respuesta asociada a ESP-NOW.
Reconocimiento restablecido
KA ACK -> ESP-NOW
El nodo raíz vuelve a intercambiar reconocimiento con el hijo mediante ESP-NOW.
Figura 8.16: Captura generada a partir del TXT interno del nodo raíz en V3. Se observan fallos consecutivos de KeepAlive para ESP-NOW, descarte por agotamiento y posterior aparición de reconocimientos KA ACK.
En la Tabla 8.14 se observa que el enlace ESP-NOW no se pierde de forma abrupta sin supervisión, sino que el sistema registra progresivamente el aumento del tiempo sin contacto. El primer fallo aparece después de 51.432 s sin respuesta, mientras que los eventos posteriores se registran a los 82.168 s, 112.984 s y 143.655 s. Esta secuencia evidencia que la lógica de KeepAlive permite identificar una degradación progresiva del enlace antes de ejecutar el descarte por agotamiento de reintentos.
Después del descarte temporal del enlace, el registro muestra nuevamente eventos de reconocimiento mediante KA ACK. Esto indica que el sistema no se bloquea después de detectar la pérdida, sino que continúa escuchando y puede volver a procesar respuestas cuando el enlace ESP-NOW vuelve a estar disponible. Sin embargo, este comportamiento también confirma que ESP-NOW presentó inestabilidad durante V3, lo cual se relaciona con los saltos de iteración observados en la publicación MQTT, especialmente en los tramos donde se reportaron pérdidas de 16 a 18 mensajes.
En conjunto, el análisis de V1, V2 y V3 muestra que los cambios realizados sí tuvieron impacto medible sobre la recepción de mensajes. La versión V2 favoreció claramente a LoRa, mientras que V3 logró el mejor resultado global con una configuración corregida en la cual LoRa operó como enlace dedicado con sensor DHT22 real. Sin embargo, los registros también evidencian que ESP-NOW puede seguir presentando pérdidas cuando la red se encuentra ejecutando tareas simultáneas de anuncio, recepción, supervisión y publicación MQTT.
8.3.5.
Reconexión del nodo hijo tras caída total del nodo raíz Adicionalmente, se realizó una prueba específica de resiliencia empleando la última versión del código implementado, correspondiente a la versión V3. En esta prueba se evaluó el comportamiento de reconexión en una topología nodo a nodo, conformada por el nodo raíz ESP_001 y el nodo hijo ESP_006, ambos comunicados mediante el protocolo ESP-NOW. El objetivo principal de esta validación fue comprobar si, ante la desconexión total del nodo raíz, el nodo hijo era capaz de detectar la pérdida del enlace, limpiar la información asociada al padre anterior, retornar al estado de descubrimiento, identificar nuevamente al nodo raíz cuando este regresara a operación y completar otra vez el proceso de vinculación segura. Esta prueba permite validar no solo la reconexión física del enlace, sino también la recuperación lógica de la red y la continuidad del flujo de datos después de una falla crítica. En la versión V3 se incorporó una mejora en la lógica de supervisión del enlace, basada en la notificación doble de mensajes KeepAlive. A diferencia de una supervisión simple, en esta versión el enlace nodo a nodo cuenta con dos eventos de verificación antes de confirmar la pérdida o recuperación de comunicación. Esta estrategia permite acelerar la detección de fallos y mejorar la reacción del sistema ante desconexiones, evitando que el nodo hijo permanezca demasiado tiempo asociado a un padre que ya no se encuentra disponible. La topología utilizada en esta prueba se muestra en la Figura 8.17. En esta configuración, el nodo raíz ESP_001 mantiene la conexión hacia el broker MQTT mediante Wi-Fi, mientras que el nodo hijo ESP_006 envía datos de aplicación a través de ESP-NOW. La comunicación entre ambos nodos se supervisa mediante mensajes KeepAlive y respuestas KA ACK, aplicados en ambos sentidos del enlace.
Figura 8.17: Topología de prueba de reconexión nodo a nodo implementada en la versión V3. Se observa el enlace ESP-NOW entre el nodo raíz ESP_001 y el nodo hijo ESP_006, junto con la supervisión reforzada mediante doble notificación KeepAlive. Fuente: elaboración propia con apoyo de inteligencia artificial generativa, a partir de los registros experimentales y la configuración implementada en los nodos ESP32.
Durante la prueba, el nodo raíz ESP_001 fue desconectado totalmente mientras la red se encontraba en operación. En el nodo hijo se observó inicialmente la comunicación normal con el padre, seguida por la ausencia de respuestas KA ACK. Posteriormente, el sistema registró fallos de KeepAlive, declaró la pérdida del padre, eliminó la información anterior del enlace y retornó al proceso de descubrimiento. Una vez el nodo raíz volvió a estar disponible, el hijo detectó nuevamente sus anuncios, solicitó vinculación, repitió el intercambio de claves Diffie-Hellman y reanudó el envío de datos de aplicación.
La prueba se analizó a partir de dos archivos de registro: uno correspondiente al nodo raíz ESP_001 y otro correspondiente al nodo hijo ESP_006. En el nodo hijo se observaron las etapas de asociación inicial, envío de datos, pérdida del padre por ausencia de KeepAlive, limpieza del enlace anterior, retorno a descubrimiento, nueva solicitud de vinculación, nuevo intercambio Diffie-Hellman y reanudación del envío de datos. En el nodo raíz se observó el reinicio del sistema, la recuperación de conectividad Wi-Fi, la aceptación del hijo, la respuesta al intercambio de claves y la recepción de nuevos datos de aplicación después de la reconexión.
8.3.6.
Reelección de padre tras caída del nodo raíz Como complemento a la prueba anterior, se incorporó una segunda validación de resiliencia en la cual el nodo hijo ESP_003 inició su operación asociado al nodo raíz ESP_001. Posteriormente, al presentarse la pérdida del padre, el nodo hijo descartó el enlace anterior, limpió la información de seguridad asociada y regresó al modo de descubrimiento. A diferencia de la prueba anterior, en este escenario la recuperación no terminó regresando al mismo padre, sino mediante la selección de un nuevo nodo raíz disponible, correspondiente a ESP_002. Esta prueba permite evaluar no solo la reconexión, sino también la capacidad de reelección de padre y continuidad operativa cuando existe otro nodo con conectividad a Internet disponible en la red.
La evidencia se obtuvo a partir de tres archivos de registro: el archivo del primer nodo raíz ESP_001, el archivo del segundo nodo raíz ESP_002 y el archivo del nodo hijo ESP_003. En el primer tramo, ESP_003 seleccionó a ESP_001 como mejor candidato, realizó solicitud de vinculación, recibió aceptación, ejecutó el intercambio Diffie-Hellman y completó la asociación segura. En el registro de ESP_001 se confirmó la recepción y publicación MQTT de las iteraciones iniciales. En el segundo tramo, tras dos fallos de KeepAlive, el hijo declaró perdido a ESP_001, eliminó el vínculo anterior y volvió al barrido de descubrimiento. Finalmente, detectó a ESP_002, lo seleccionó como nuevo padre, repitió la vinculación segura y continuó transmitiendo datos de aplicación hacia la nueva raíz.
La Figura 8.18 representa la condición inicial de la prueba. En esta etapa, el nodo ESP_-
001 actuaba como nodo raíz con salida hacia Internet y publicación MQTT, mientras que el
nodo ESP_003 operaba como nodo hijo asociado mediante ESP-NOW. El nodo ESP_002 se encontraba disponible como un segundo nodo con capacidad de asumir el rol de padre o raíz en caso de pérdida del enlace principal.
Figura 8.18: Topología de prueba de reconexión nodo a nodo implementada en la versión V3. Se observa la asociación inicial del nodo hijo ESP_003 con el nodo raíz ESP_001 mediante ESP- NOW, mientras que el nodo ESP_002 permanece como raíz alternativa con disponibilidad de conexión Wi-Fi/MQTT hacia el broker.
Después de la caída o pérdida de comunicación con ESP_001, el nodo hijo ESP_003 detectó la ausencia de respuesta mediante los mensajes de supervisión KeepAlive. Al superarse los fallos configurados, el sistema limpió la información del padre anterior, eliminó la clave compartida asociada a ese enlace y retornó al estado de descubrimiento. En ese nuevo barrido, ESP_003 identificó a ESP_002 como nuevo candidato válido, repitió el proceso de vinculación segura y continuó enviando información hacia la red, como se muestra en la Figura 8.19.
Figura 8.19: Topología final de la prueba complementaria de reelección de padre. Tras la pérdida del enlace con ESP_001, el nodo hijo ESP_003 descarta el padre anterior, limpia el vínculo existente, redescubre la red y selecciona a ESP_002 como nuevo padre, restableciendo la transmisión de datos hacia el broker MQTT.
Cuadro 8.15: Eventos principales de la prueba complementaria de reelección de padre Instante de la prueba Archivo / equipo Evento observado Inicio de la prueba Hijo ESP_003 Selección de ESP_001 como mejor padre, solicitud de vinculación, aceptación, intercambio DH y asociación completada.
Asociación inicial Raíz ESP_001 Registro del hijo ESP_003, generación de clave compartida y publicación MQTT de la iteración
1.
Antes de la caída del padre Raíz ESP_001 Recepción y publicación MQTT de la iteración 2 antes de la pérdida del padre.
Primer evento de supervisión Hijo ESP_003 Detección del primer fallo de KeepAlive hacia ESP_001. El nodo aún mantiene el enlace, pero incrementa el contador de fallos.
Segundo evento de supervisión Hijo ESP_003 Detección del segundo fallo consecutivo de KeepAlive. Este evento confirma que el padre anterior dejó de responder dentro del tiempo esperado. Después del segundo fallo KA Hijo ESP_003 Declaración de padre perdido, descarte de ESP_- 001, limpieza completa del vecino, limpieza de seguridad y retorno al estado de descubrimiento. Nuevo proceso de descubrimiento Hijo ESP_003 Selección de ESP_002 como nuevo padre, solicitud de vinculación, aceptación, nuevo intercambio DH y asociación completada.
Reasociación con nueva raíz Raíz ESP_002 Registro del hijo ESP_003, establecimiento de clave compartida y publicación MQTT de la iteración 9. Operación posterior a la reelección Raíz ESP_002 Recepción y publicación MQTT de las iteraciones 10 y 11 después de la reelección del padre. A partir de los eventos registrados se evidencia que la versión más reciente del código implementa una lógica de supervisión más rápida, debido a que el nodo hijo no espera una cantidad elevada de reintentos para declarar la pérdida del padre. En esta prueba, dos fallos consecutivos de KeepAlive fueron suficientes para considerar que ESP_001 ya no estaba disponible, limpiar el enlace anterior y regresar al proceso de descubrimiento. Esta decisión reduce el tiempo de recuperación frente a una caída total del nodo raíz, ya que evita mantener durante demasiado tiempo una asociación no funcional.
El comportamiento observado también confirma que la recuperación no depende únicamente de que el mismo padre vuelva a estar disponible. En este caso, el nodo hijo fue capaz de identificar otro nodo con capacidad de conexión a Internet, correspondiente a ESP_002, y establecer con él una nueva asociación segura. Esto demuestra que la red puede reorganizarse dinámicamente ante la pérdida de un nodo raíz, manteniendo la continuidad de transmisión mediante la reelección de padre.
Desde el punto de vista de resiliencia, esta prueba es más completa que una reconexión simple, debido a que valida tres condiciones importantes: la detección de pérdida del padre anterior, la eliminación de la información de seguridad y enrutamiento asociada a ese enlace, y la selección de un nuevo padre disponible. Además, la publicación posterior de las iteraciones 9, 10 y 11 evidencia que la comunicación no quedó bloqueada después de la caída de ESP_001, sino que fue restablecida a través de ESP_002.
Análisis cuantitativo de la reelección de padre Para cuantificar esta prueba se tomó nuevamente como referencia el campo iteracion. En el registro del nodo hijo ESP_003 se observaron las iteraciones 1 a 11. En el primer nodo raíz ESP_001 se confirmaron las iteraciones 1 y 2, mientras que en el segundo nodo raíz ESP_002 se confirmaron las iteraciones 9, 10 y 11. Las iteraciones 3 a 8 corresponden al intervalo de pérdida y transición, durante el cual el nodo hijo continuó generando mensajes, pero el enlace anterior ya no permitía confirmar su entrega hacia la raíz.
Cuadro 8.16: Resumen cuantitativo de la prueba complementaria de reelección de padre Tramo de la prueba Iteraciones generadas Iteraciones confirmadas Efectividad Pérdida Interpretación Operación inicial con
ESP_001
1–2 1–2
100.00 %
0.00 %
El enlace inicial con el primer padre funcionó correctamente.
Periodo de caída y transición 3–8
0
0.00 %
100.00 %
La pérdida corresponde al intervalo en el que el padre anterior dejó de estar disponible y el hijo aún no había completado una nueva asociación.
Operación posterior con ESP_002 9–11 9–11
100.00 %
0.00 %
Después de la reelección, la nueva raíz recibió y publicó correctamente los datos.
Total del archivo analizado 1–11
1, 2, 9, 10, 11
45.45 %
54.55 %
La efectividad global incluye el periodo de desconexión y búsqueda de nuevo padre.
El resultado global de 45.45 % no debe interpretarse como una pérdida permanente de la arquitectura, sino como el efecto de incluir dentro del cálculo el tiempo en que el padre inicial
estuvo caído y el nodo hijo se encontraba en proceso de recuperación. Si el análisis se separa por tramos funcionales, la red tuvo 100.00 % de recepción antes de la caída y 100.00 % de recepción después de completar la reelección del nuevo padre. Por tanto, la prueba evidencia que la arquitectura puede recuperar la comunicación no solamente cuando reaparece el mismo nodo raíz, sino también cuando existe otro nodo raíz o padre con conectividad disponible para asumir la recepción.
Cuadro 8.17: Indicadores técnicos observados durante la reelección de padre Indicador Valor observado Interpretación Primer padre seleccionado
ESP_001
Nodo raíz inicial con Internet y nivel 1. Puntaje del primer candidato
1920
La selección consideró nivel, RSSI y cupo disponible.
RSSI del primer candidato al descubrimiento -44 dBm Señal adecuada para establecer el enlace inicial por ESP-NOW.
Fallos de KeepAlive antes de declarar pérdida
2 de 2
El sistema esperó el máximo de reintentos antes de descartar al padre.
Tiempo sin contacto en el segundo fallo
65844 ms
La pérdida se declaró después de aproximadamente 65.84 s sin contacto válido. Nuevo padre seleccionado
ESP_002
Nodo raíz disponible seleccionado después del retorno a descubrimiento.
Puntaje del nuevo candidato
1940
El nuevo padre presentó mejor puntaje que el candidato anterior en el momento de recuperación.
RSSI del nuevo candidato -40 dBm La señal permitió completar nuevamente la vinculación por ESP-NOW.
Reestablecimiento de seguridad Exitoso Se generó una nueva clave compartida DH con
ESP_002.
Figura 8.20: Registro del nodo hijo ESP_003 durante la asociación inicial con ESP_001. Se observa la selección del padre, la solicitud de vinculación, el intercambio DH y el primer envío de datos.
Figura 8.21: Registro del nodo hijo ESP_003 durante la detección de pérdida de ESP_001. Se evidencian los fallos de KeepAlive, la declaración de padre perdido y la limpieza de la seguridad asociada al enlace anterior.
Figura 8.22: Registro del nodo hijo ESP_003 durante la selección de ESP_002 como nuevo padre. Se observa la nueva solicitud de vinculación, el intercambio DH y la reanudación del envío de datos hacia el nuevo padre.
Figura 8.23: Registro de ESP_001 como primera raíz. Se confirma la recepción de datos desde ESP_003 y la publicación MQTT de las iteraciones iniciales.
Figura 8.24: Registro de ESP_002 como nueva raíz después de la pérdida de ESP_001. Se confirma la recepción de ESP_003, el nuevo intercambio DH y la publicación MQTT de las iteraciones 9, 10 y 11.
8.4.
Pruebas de seguridad Desde el punto de vista de seguridad, la implementación integra tres componentes principales: el intercambio de claves mediante Diffie-Hellman, la protección del contenido mediante XOR con clave derivada y la verificación de integridad mediante CRC16-CCITT. Esta combinación
permite que los nodos establezcan una clave compartida, protejan el contenido del payload y descarten tramas que no superen la validación de integridad.
Es importante aclarar que el mecanismo usado en el prototipo no corresponde a una implementación de AES-128 puro. Debido a las restricciones de memoria, procesamiento y concurrencia propias del ESP32 ejecutando simultáneamente tareas de descubrimiento, enrutamiento, recepción, transmisión, supervisión y publicación, se optó por una protección basada en XOR con clave derivada. Esta decisión permitió mantener un mecanismo de protección ligero y compatible con las limitaciones del prototipo, sin afectar de forma significativa el flujo operativo de la red.
La evidencia experimental del intercambio de claves se presenta mediante capturas del proceso ejecutado entre los nodos (véase figura 8.17). En lugar de registrar únicamente el archivo final en una tabla, se documenta visualmente la secuencia completa: solicitud de intercambio Diffie- Hellman, respuesta del nodo asociado y persistencia de la clave compartida en el archivo vecinos.json. Esto permite comprobar que la clave no fue asignada manualmente, sino generada durante el proceso de vinculación segura entre nodos.
(a) Solicitud de intercambio de clave desde el nodo hijo.
(b) Respuesta del nodo raíz durante el intercambio DH.
(c) Registro de la clave compartida generada en vecinos.json.
Figura 8.25: Evidencia del intercambio de clave Diffie-Hellman y almacenamiento de la clave compartida en el registro de vecinos.
En la Figura 8.25 se observa que el proceso de seguridad cumple las tres etapas esperadas: el nodo hijo inicia la negociación, el nodo raíz responde al intercambio y posteriormente queda registrada una clave_compartida asociada al vecino. Con esto se valida el flujo de seguridad implementado para la vinculación, ya que el enlace queda asociado a una clave derivada antes de transportar datos de aplicación protegidos mediante XOR y verificados con CRC16-CCITT.
8.5.
Pruebas del funcionamiento de la red
8.5.1.
Prueba con red de seis nodos operando con ESP-NOW Con el fin de validar el comportamiento de la red en una condición más cercana a una operación distribuida, se realizó una primera prueba con seis nodos ESP32 configurados con una capacidad máxima de dos hijos por nodo, mediante el parámetro max_hijos = 2. Esta configuración permitió que los nodos no solo actuaran como emisores de datos, sino también como posibles padres intermedios dentro de la red. De esta manera, fue posible evaluar la formación automática de una topología jerárquica, la asociación entre nodos, el reenvío de datos a través de rutas de varios saltos y la publicación final de la información en el broker
MQTT.
En esta prueba, la comunicación entre los nodos se realizó mediante el protocolo ESP-NOW. Aunque el sistema desarrollado permite operar con diferentes protocolos de comunicación, el objetivo de esta validación fue analizar el comportamiento específico de la red cuando todos los enlaces principales se establecen por ESP-NOW. El nodo ESP_001 actuó como nodo raíz, debido a que tenía conectividad a Internet y era el encargado de publicar los datos recibidos en el tópico MQTT RED_MULTIPROTOCOLO_ESP.
La configuración max_hijos = 2 permitió que algunos equipos aceptaran nodos hijos y actuaran como padres intermedios. De esta manera, la red no quedó limitada a una comunicación directa entre cada nodo y la raíz, sino que se formaron rutas de varios saltos. Esta condición fue importante para comprobar el comportamiento del sistema en una topología distribuida, donde los datos generados por los nodos finales podían ser reenviados por otros nodos antes de llegar al nodo raíz ESP_001. En la evidencia obtenida, los nodos ESP_003, ESP_004 y ESP_- 006 generaron datos de aplicación, mientras que los nodos intermedios permitieron reenviar la información hasta el nodo raíz ESP_001. En particular, ESP_003 transmitió datos reales del sensor DHT22, mientras que ESP_004 y ESP_006 transmitieron valores de temperatura simulada.
Figura 8.26: Topología de prueba con seis nodos configurados con capacidad máxima de dos hijos por nodo mediante max_hijos = 2. Esta configuración permitió la formación de una topología jerárquica, donde el nodo ESP_001 operó como nodo raíz con conexión a Internet y publicación MQTT, mientras que los nodos intermedios permitieron el reenvío de datos generados por los nodos finales.
Figura 8.27: Publicaciones MQTT recibidas durante la primera prueba con seis nodos usando ESP-NOW. Se observan registros provenientes de los nodos ESP_003, ESP_004 y ESP_006, enviados hacia el nodo raíz ESP_001.
Figura 8.28: Continuación de las publicaciones MQTT recibidas durante la primera prueba con seis nodos usando ESP-NOW. Se evidencia la trazabilidad de los mensajes mediante campos como iteracion, saltos, id_nodo, origen_sensor y nodo_raiz.
Cuadro 8.18: Resumen de la topología observada en la primera prueba con seis nodos usando
ESP-NOW
Nodo Rol observado Padre identificado Nivel estimado Función principal
ESP_001
Raíz No aplica
1
Concentración de datos y publicación MQTT
ESP_002
Padre intermedio
ESP_001
2
Asociación con la raíz y reenvío de datos
ESP_005
Padre intermedio
ESP_001
2
Asociación con la raíz y reenvío de datos
ESP_003
Nodo sensor / hijo Nodo intermedio
3
Transmisión de datos reales del sensor DHT22
ESP_006
Nodo sensor / hijo Nodo intermedio
3
Transmisión de temperatura simulada
ESP_004
Nodo sensor / hijo profundo Nodo intermedio
4
Transmisión de temperatura simulada mediante ruta de tres saltos Cuadro 8.19: Resumen cuantitativo de publicaciones MQTT en la primera prueba con seis nodos usando ESP-NOW Nodo origen Sensor / dato Saltos Iteraciones esperadas Iteraciones recibidas Efectividad Pérdida
ESP_003
DHT22
2
26
26
100.00 %
0.00 %
ESP_006
Temperatura simulada
2
16
16
100.00 %
0.00 %
ESP_004
Temperatura simulada
3
23
20
86.96 %
13.04 %
Total – –
65
62
95.38 %
4.62 %
La Tabla 8.19 muestra que la red logró publicar 62 mensajes MQTT de un total esperado de 65 dentro del tramo registrado, lo que corresponde a una efectividad global de 95.38 %. Los nodos ESP_003 y ESP_006 alcanzaron una continuidad del 100.00 %, ya que todas las iteraciones esperadas dentro de sus respectivos rangos fueron recibidas y publicadas correctamente. Por otra parte, el nodo ESP_004 presentó una efectividad de 86.96 %, debido a la pérdida de tres mensajes dentro del tramo analizado.
Cuadro 8.20: Tiempo de publicación observado por nodo en la primera prueba usando ESP-
NOW
Nodo origen Primera publicación Última publicación Duración del tramo Intervalo promedio
ESP_003
17:23:38.934 17:28:17.261
278.327 s
11.133 s
ESP_004
17:24:13.752 17:28:09.068
235.316 s
12.385 s
ESP_006
17:25:28.436 17:28:11.526
162.510 s
10.834 s
A partir de los tiempos registrados en la Tabla 8.20, se observa que el nodo ESP_003 mantuvo el tramo de publicación más amplio, con una duración aproximada de 278.327 s. Este nodo presentó un intervalo promedio de 11.133 s entre publicaciones, valor coherente con una transmisión periódica cercana a 10 s considerando los retardos propios del procesamiento,
reenvío y publicación MQTT. El nodo ESP_006 presentó un intervalo promedio de 10.834 s, mientras que ESP_004 obtuvo un promedio de 12.385 s, afectado principalmente por un salto de publicación identificado durante la prueba.
Cuadro 8.21: Principal salto de iteración detectado en la primera prueba con seis nodos usando ESP-NOW Nodo origen Tiempo antes de la pérdida Iteración antes Tiempo de recuperación Iteración recuperada Mensajes perdidos
ESP_004
17:24:35.332
3
17:25:16.011
7
3
El salto mostrado en la Tabla 8.21 evidencia que el nodo ESP_004 dejó de publicar después de la iteración 3 y recuperó la publicación en la iteración 7. Esto representa una pérdida estimada de tres mensajes y un tiempo sin publicación de aproximadamente 40.679 s. Este comportamiento puede estar asociado a que ESP_004 fue el nodo con mayor profundidad dentro de la topología observada, ya que sus mensajes llegaron al nodo raíz con saltos = 3. Por lo tanto, su información dependía de una ruta con más enlaces intermedios, aumentando la probabilidad de interrupciones temporales frente a los nodos que solo requerían dos saltos. En términos generales, la prueba demuestra que la red pudo operar con seis nodos bajo una configuración de dos hijos máximos por nodo, manteniendo la publicación MQTT desde diferentes ramas de la topología. La presencia del campo saltos permitió verificar que los mensajes no provenían únicamente de enlaces directos, sino de rutas jerárquicas con reenvío entre nodos. Los resultados también evidencian que la profundidad de la ruta influye en la continuidad de la recepción: los nodos ubicados a dos saltos alcanzaron una efectividad del 100.00 %, mientras que el nodo ubicado a tres saltos presentó una pérdida parcial. En conclusión, esta primera prueba valida el funcionamiento de la red jerárquica usando ESP- NOW con seis nodos ESP32 configurados con max_hijos = 2. La arquitectura logró formar una topología distribuida, asociar nodos intermedios, reenviar datos de aplicación y publicar la información en MQTT a través del nodo raíz. La efectividad global de 95.38 % muestra un comportamiento funcional para la prueba realizada, aunque también evidencia que los nodos ubicados en niveles más profundos pueden requerir mecanismos adicionales de retransmisión, confirmación o ajuste de tiempos para mejorar la continuidad de recepción.
8.5.2.
Prueba con red de seis nodos operando con ESP-NOW y LoRa En esta prueba se evaluó el comportamiento de la red utilizando seis nodos ESP, manteniendo una topología jerárquica compuesta por un nodo raíz, dos nodos intermedios y tres nodos finales encargados de generar datos de aplicación. A diferencia de configuraciones anteriores, los nodos finales fueron configurados con una capacidad máxima de cero hijos, mediante el parámetro max_hijos = 0, con el propósito de evitar que asumieran funciones de reenvío y concentrar su operación únicamente en la generación y transmisión de datos. Esta decisión buscó mejorar la efectividad de la transmisión, reducir la carga de procesamiento en los nodos sensores y disminuir la probabilidad de pérdidas asociadas a rutas más profundas. El objetivo de esta validación fue comprobar la operación de la red cuando se habilita LoRa dentro del esquema multiprotocolo, conservando el soporte de ESP-NOW para las etapas de descubrimiento, asociación, supervisión y, en algunos casos, transmisión de mensajes. A partir de los archivos de vecinos generados por los nodos, se identificó la participación de los seis dispositivos de la red: ESP_001, ESP_002, ESP_003, ESP_004, ESP_005 y ESP_006. El nodo ESP_001 actuó como nodo raíz con conectividad Wi-Fi y publicación MQTT. Los nodos ESP_002 y ESP_005 operaron como padres intermedios, mientras que los nodos ESP_003, ESP_004 y ESP_006 funcionaron como nodos finales de generación de datos. En estos últimos se configuró max_hijos = 0, de manera que no aceptaran nuevos hijos y no participaran como nodos de retransmisión. Esta estructura confirma que la prueba corresponde a una validación de red distribuida con roles definidos, donde la capacidad de reenvío se concentró en los nodos intermedios para mejorar la estabilidad general de la transmisión.
Figura 8.29: Topología identificada en la prueba con seis nodos y operación multiprotocolo con LoRa habilitado. En esta configuración, el nodo ESP_001 actúa como nodo raíz y publica la información hacia el broker MQTT, mientras que ESP_002 y ESP_005 operan como nodos padre intermedios. Los nodos ESP_003, ESP_004 y ESP_006 se configuraron con max_hijos = 0, por lo que funcionan únicamente como nodos finales de generación de datos, favoreciendo una transmisión más estable y reduciendo la carga de reenvío en los sensores.
Figura 8.30: Publicaciones MQTT recibidas durante la segunda prueba con seis nodos en operación multiprotocolo con LoRa habilitado. Se observan registros enviados hacia el nodo raíz ESP_001 desde diferentes nodos sensores de la red.
Figura 8.31: Continuación de las publicaciones MQTT recibidas durante la segunda prueba multiprotocolo. La evidencia muestra la recepción de datos de aplicación con identificación del nodo origen, iteración, saltos y nodo raíz.
El análisis de resultados muestra que la red logró mantener una estructura funcional de seis nodos, donde los nodos finales enviaron información hacia el nodo raíz mediante la intermediación de otros nodos. La presencia de publicaciones MQTT provenientes de diferentes orígenes confirma que el sistema no dependió únicamente de un enlace punto a punto, sino que permitió la operación de una topología jerárquica con múltiples rutas lógicas hacia la raíz.
Sin embargo, es importante aclarar que esta prueba no debe interpretarse como una prueba exclusivamente LoRa. En los registros se observa que algunos nodos tenían habilitados tanto ESP-NOW como LoRa, y que el protocolo principal de operación continuó asociado a ESP-NOW en varios eventos de descubrimiento, asociación y supervisión. Por tanto, esta validación se clasifica como una prueba de seis nodos en operación multiprotocolo con LoRa habilitado. Desde el punto de vista funcional, el resultado es positivo porque se comprobó que la red pudo organizarse en tres niveles: raíz, padres intermedios y nodos finales. Además, se verificó que la restricción de cero hijos en los nodos finales permitió delimitar claramente su función dentro de la topología, evitando que estos dispositivos asumieran tareas de retransmisión. De esta manera, los nodos finales se concentraron en la generación y envío de datos, mientras que los nodos intermedios asumieron la responsabilidad de extender la cobertura lógica de la red. Esta separación de roles contribuyó a mejorar la efectividad de la transmisión y a reducir la complejidad operativa en los nodos sensores.
En conclusión, la prueba evidencia que la red multiprotocolo puede operar con seis nodos, mantener una topología jerárquica y publicar datos de aplicación en MQTT desde diferentes nodos sensores. La habilitación de LoRa aporta una alternativa adicional de comunicación dentro del sistema; no obstante, los resultados también muestran que la operación real de la red depende de la coordinación entre los protocolos disponibles, especialmente ESP-NOW y LoRa. Adicionalmente, la configuración de los nodos finales con max_hijos = 0 permitió mejorar la organización funcional de la red, ya que los sensores no asumieron tareas de reenvío y se limitaron a generar datos. Por tanto, futuras pruebas deberán separar con mayor precisión los escenarios de transmisión exclusivamente ESP-NOW, exclusivamente LoRa y operación mixta, así como evaluar diferentes valores de capacidad de hijos para determinar su impacto en la efectividad de transmisión.
8.6.
Discusión técnica de resultados La evidencia experimental presentada en las secciones anteriores muestra que la arquitectura propuesta logró integrar comunicación entre nodos y publicación externa de datos mediante el uso combinado de ESP-NOW, LoRa, Wi-Fi y MQTT. Desde el punto de vista funcional, ESP-NOW y LoRa permitieron validar la transmisión local entre nodos, mientras que Wi-Fi y MQTT permitieron comprobar la salida de la información hacia un broker externo. Esta integración confirma que la propuesta no se limita a un único enlace inalámbrico, sino que articula varios protocolos dentro de una misma lógica de operación. Los porcentajes de efectividad muestran que el desempeño varía de forma importante según la versión del código y la distribución de tareas internas. En las pruebas individuales iniciales se obtuvieron efectividades superiores al 80 % para ambos protocolos, lo que permitió validar el funcionamiento básico de transmisión y publicación. Sin embargo, en las pruebas simultáneas se observaron diferencias más marcadas, especialmente cuando el ciclo principal debía atender escucha, transmisión, supervisión, seguridad, publicación MQTT y registro de datos. Esto indica que la arquitectura es funcional, pero sensible a la carga de procesamiento y a los tiempos asignados a cada protocolo.
La comparación entre V1, V2 y V3 evidencia que los ajustes de software impactaron directamente la estabilidad de cada enlace. La versión V2 favoreció la recepción LoRa, pero redujo la continuidad de ESP-NOW. La versión V3 alcanzó el mejor desempeño global y el mejor resultado para LoRa, lo que sugiere que una asignación más clara de roles y una menor competencia interna por el ciclo de procesamiento mejora la recepción. No obstante, la desviación estándar calculada entre versiones muestra que el sistema todavía presenta variabilidad y que se requieren repeticiones adicionales bajo condiciones idénticas para fortalecer la validez estadística.
Los eventos de reconexión, supervisión y reelección de padre demuestran que la resiliencia no depende únicamente de recibir todos los mensajes, sino de la capacidad del sistema para detectar una pérdida de enlace, limpiar el estado anterior, volver a descubrir vecinos y restablecer una ruta de comunicación. En este sentido, los mensajes KeepAlive y KeepAlive ACK cumplieron una función central, ya que permitieron identificar fallos y activar la recuperación automática. La reelección de padre permitió comprobar que un nodo hijo puede abandonar un padre no disponible y asociarse a otro nodo con conectividad.
Las pérdidas de información observadas no invalidan la arquitectura, pero sí evidencian limitaciones del prototipo. El ESP32 ejecutando MicroPython debe atender múltiples tareas
concurrentes y, además, durante las pruebas se generaron registros extensos en archivos TXT y salidas de consola. Este registro detallado fue útil para la trazabilidad experimental, pero puede ocupar memoria y afectar la estabilidad del microcontrolador. Por tanto, en una versión productiva se recomienda reducir el registro local, usar almacenamiento externo o enviar los eventos de diagnóstico hacia un sistema de monitoreo externo.
Finalmente, desde el punto de vista de seguridad, el intercambio Diffie-Hellman, la protección XOR con clave derivada y la validación CRC16-CCITT permitieron demostrar un flujo de asociación segura e integridad de trama dentro del alcance del prototipo. Sin embargo, este mecanismo debe interpretarse como una protección ligera y experimental. Para aplicaciones reales con información sensible, la arquitectura debe evolucionar hacia cifrado autenticado, como AES en modo adecuado para IoT o algoritmos ligeros modernos, manteniendo la lógica de intercambio de claves, trazabilidad y validación de integridad.
Capítulo 9 Conclusiones y recomendaciones
9.1.
Conclusiones A partir del diseño, implementación y evaluación experimental desarrollada, se concluye que el objetivo general del proyecto fue cumplido, ya que se diseñó e implementó una arquitectura IoT multiprotocolo basada en nodos ESP32, capaz de integrar comunicación local entre nodos, publicación externa de datos, mecanismos de seguridad ligera y estrategias de recuperación ante fallos. La arquitectura permitió articular ESP-NOW y LoRa como enlaces de comunicación entre nodos, Wi-Fi como medio de conectividad del nodo raíz y MQTT como protocolo de publicación hacia un broker externo.
En relación con el primer objetivo específico, orientado a analizar las limitaciones técnicas, de conectividad y de seguridad en redes IoT con infraestructura limitada, el proyecto permitió evidenciar que el desempeño de una red multiprotocolo no depende únicamente del protocolo utilizado, sino también de la capacidad del microcontrolador para atender múltiples tareas simultáneas. Las pérdidas de información, los saltos de iteración y los tiempos sin publicación observados durante las pruebas se relacionaron con la carga del ciclo principal, los tiempos de escucha, la publicación MQTT, la supervisión KeepAlive, la seguridad, el manejo de colas y el registro de archivos TXT. Esta conclusión confirma que las restricciones de memoria y procesamiento del ESP32 deben considerarse como un factor crítico de diseño. Respecto al segundo objetivo específico, relacionado con el diseño de una arquitectura multiprotocolo, se concluye que la topología jerárquica tipo árbol permitió organizar la red de forma estructurada mediante relaciones padre-hijo, niveles jerárquicos y selección de rutas hacia un nodo raíz. Las pruebas con seis nodos demostraron que la capacidad máxima de hijos influye directamente en la topología final, permitiendo distribuir asociaciones cuando
los nodos tienen cupo disponible y evitando nuevas vinculaciones cuando no existe capacidad. Esta organización contribuye a la interoperabilidad y facilita la gestión de rutas en comparación con una red sin estructura jerárquica.
En relación con el tercer objetivo específico, correspondiente a la implementación del prototipo funcional, se concluye que los módulos desarrollados permitieron ejecutar descubrimiento, selección de padre, vinculación segura, transmisión, recepción, supervisión, reconexión y publicación MQTT. Las pruebas individuales iniciales con 500 mensajes permitieron validar el funcionamiento base de los enlaces, obteniendo una efectividad aproximada del 81,80 % para ESP-NOW y del 83,00 % para LoRa. Estos valores no representan el límite definitivo de la arquitectura, pero sí comprobaron que ambos protocolos podían transportar datos hacia el nodo raíz y que este podía publicarlos en MQTT.
En relación con el cuarto objetivo específico, orientado a evaluar interoperabilidad, seguridad y resiliencia, se concluye que la arquitectura fue capaz de mantener comunicación multiprotocolo y ejecutar mecanismos de recuperación ante fallos. En las pruebas por versiones, la comparación entre V1, V2 y V3 mostró que el desempeño global mejoró desde 60,00 % en V1, hasta 65,40 % en V2 y 79,20 % en V3. En esta última versión, LoRa alcanzó una efectividad aproximada del 97,80 %, mientras que ESP-NOW alcanzó aproximadamente 60,60 % bajo las condiciones evaluadas. Estos resultados indican que los ajustes de temporización, escucha y distribución de carga tienen un impacto directo sobre la continuidad de recepción. La resiliencia de la arquitectura se validó mediante eventos de pérdida de enlace, supervisión con KeepAlive, recepción de KeepAlive ACK, reconexión del nodo hijo y reelección de padre. En las pruebas realizadas, el sistema no se limitó a detener la operación ante una falla, sino que detectó la pérdida de contacto, limpió información del enlace anterior, eliminó el contexto de seguridad asociado y regresó a descubrimiento para restablecer la comunicación. Esto demuestra una contribución técnica importante del proyecto: la red puede reorganizarse después de la pérdida de un nodo raíz o de un padre, siempre que exista otro nodo disponible con conectividad.
Desde el punto de vista de seguridad, se concluye que el sistema implementó una validación funcional de asociación segura mediante intercambio Diffie-Hellman, protección del payload mediante XOR con clave derivada y verificación de integridad mediante CRC16-CCITT. Este mecanismo permitió comprobar que la clave compartida se generó durante el proceso de vinculación y no fue asignada manualmente. Sin embargo, se reconoce como una limitación que XOR no ofrece el mismo nivel de protección que un cifrado autenticado robusto, por lo cual debe entenderse como una solución ligera de prototipo y no como una implementación
criptográfica final para escenarios productivos de alta seguridad. La comparación estadística descriptiva entre versiones mostró una variabilidad relevante en el comportamiento de los protocolos. En las pruebas simultáneas, LoRa presentó una efectividad promedio de 72,07 % con desviación estándar de 39,49 %, mientras que ESP-NOW presentó una efectividad promedio de 64,33 % con desviación estándar de 27,39 %. Esta dispersión indica que los protocolos fueron sensibles a la configuración del código y a la distribución del tiempo de procesamiento, por lo que futuras validaciones deben incluir más repeticiones por escenario para obtener conclusiones estadísticamente más robustas. Como limitación general, se concluye que las pruebas fueron realizadas en un entorno controlado y con un número limitado de ejecuciones por escenario. Aunque los registros TXT, capturas MQTT y evidencias de consola permitieron validar funcionalmente la arquitectura, aún no se cuenta con una evaluación a gran escala en campo, mediciones detalladas de consumo energético, análisis de latencia por paquete ni pruebas de escalabilidad con un número mayor de nodos. Estas limitaciones no reducen el aporte del proyecto, pero delimitan el alcance experimental de los resultados obtenidos.
En síntesis, el proyecto aporta una arquitectura funcional, modular y de bajo costo para redes IoT multiprotocolo, demostrando que es posible combinar interoperabilidad, trazabilidad, seguridad ligera y resiliencia sobre nodos ESP32. La propuesta constituye una base experimental para futuros desarrollos orientados a despliegues IoT en entornos con infraestructura limitada, donde la continuidad operativa y la capacidad de recuperación resultan tan importantes como la transmisión de datos.
9.2.
Recomendaciones y trabajo futuro Se recomienda ampliar la evaluación experimental incorporando múltiples repeticiones por cada escenario de prueba. Para fortalecer la validez estadística, cada configuración debería ejecutarse al menos tres veces bajo condiciones equivalentes, calculando promedio, desviación estándar, valores mínimos, máximos e intervalos de confianza. Esto permitiría diferenciar mejor entre pérdidas ocasionales y comportamientos sistemáticos de cada protocolo. Se recomienda implementar un mecanismo de cifrado más robusto para una versión productiva del sistema. La protección XOR utilizada en el prototipo permitió validar el flujo de seguridad con baja carga computacional, pero debe evolucionar hacia AES en un modo adecuado para dispositivos IoT, ECDH para intercambio de claves o algoritmos ligeros
autenticados, manteniendo la estructura de tramas, EtherType, CRC y control de vecinos. Se recomienda ampliar el número de nodos y realizar pruebas de escalabilidad. Aunque se realizaron validaciones con varios nodos, es necesario evaluar el comportamiento de la arquitectura con una red más grande, diferentes niveles jerárquicos, mayor cantidad de hijos por padre y tráfico simultáneo desde múltiples sensores. Esto permitiría identificar límites reales de crecimiento, congestión y estabilidad.
Se recomienda medir el consumo energético de los nodos durante las tareas de descubrimiento, transmisión, recepción, supervisión y publicación. Esta medición es importante porque una red IoT desplegada en campo puede depender de baterías o fuentes de energía limitadas. Comparar el consumo de ESP-NOW, LoRa, Wi-Fi y MQTT permitiría optimizar los intervalos de envío y las estrategias de suspensión.
Se recomienda optimizar el manejo de memoria y el registro de eventos en el ESP32. Durante las pruebas se observó que los archivos TXT extensos y las salidas detalladas de depuración pueden ocupar memoria y afectar la estabilidad. Para trabajos futuros se sugiere registrar solo eventos críticos, emplear almacenamiento externo o enviar logs resumidos hacia un servidor de monitoreo.
Se recomienda incorporar mecanismos de acuse de recibo y retransmisión para los datos de aplicación. Aunque los mensajes KeepAlive permiten supervisar el enlace, las pérdidas de iteraciones muestran que la capa de aplicación puede beneficiarse de confirmaciones, reintentos controlados y ventanas de transmisión para mejorar la continuidad de datos. Se recomienda validar la arquitectura en escenarios reales de despliegue IoT, especialmente en ambientes rurales, industriales o con obstáculos físicos. Estas pruebas permitirían medir el impacto de distancia, interferencia, ubicación del nodo, RSSI, orientación de antenas y condiciones ambientales sobre la efectividad de ESP-NOW y LoRa.
Se recomienda complementar el análisis con métricas de latencia, RSSI por paquete, tasa de retransmisión, tiempo de reconexión, tiempo de reelección de padre y estabilidad de rutas. Estas métricas permitirían caracterizar de forma más completa el desempeño de la red y comparar su comportamiento frente a otras arquitecturas IoT.
Finalmente, se recomienda mantener la modularidad del código y documentar cada versión con sus parámetros exactos de configuración. Esto facilitará la reproducibilidad de las pruebas, la comparación entre versiones y la incorporación de nuevas tecnologías o algoritmos sin alterar la lógica general de la arquitectura.
Bibliografía [1] M. Al-Mashhadani and M. Shujaa, “Seguridad de IoT mediante tecnología de cifrado AES basada en la plataforma ESP32,” 2022. [Online]. Available: https://www.iajit. org/paper294IoT-Security-Using-AES-Encryption-Technology-based-ESP32-P latform. [Accessed: Nov. 03, 2025].
[2] M. S. Sharbaf, “El IoT: crecimiento y diversidad y desafíos,” 2022. [Online]. Available: https://ieeexplore.proxyutp.elogim.com/stamp/stamp.jsp?arnumber=10152044. [Accessed: Nov. 03, 2025].
[3] W. Villegas-Ch, J. Govea, R. Gutierrez and A. Mera-Navarrete, “Optimización de la seguridad en ecosistemas de IoT mediante modelos híbridos de inteligencia artificial y blockchain: un enfoque escalable y eficiente para la detección de amenazas,” 2025. [Online]. Available: https://ieeexplore.proxyutp.elogim.com/stamp/stamp.jsp?t p=&arnumber=10849557. [Accessed: Nov. 03, 2025].
[4] S. Pal and Z. Jadidi, “Control de acceso híbrido para ambientes IoT,” 2021. [Online]. Available: https://pmc.ncbi.nlm.nih.gov/articles/PMC8539538/pdf/sensors-2 1-06832.pdf. [Accessed: Nov. 03, 2025].
[5] M. Gayathri and V. S. Veera, “Algoritmos de clustering y gemelos digitales en IoT,”
2025. [Online]. Available: https://www.frontiersin.org/articles/10.3389/frcmn
.2025.1602928/full. [Accessed: Nov. 03, 2025].
[6] Check Point Software, “Los mayores retos de la seguridad IoT,” 2023. [Online]. Available: https://www.checkpoint.com/es/cyber-hub/network-security/what-is-iot-sec urity/biggest-iot-security-challenges/. [Accessed: Nov. 03, 2025]. [7] Splashtop, “Seguridad IoT: Amenazas y estrategias,” 2025. [Online]. Available: https: //www.splashtop.com/es/blog/iot-security. [Accessed: Nov. 03, 2025].
[8] Centro de Investigación COITaoc, “Estado del arte y tendencias del IoT e IoE,” 2021. [Online]. Available: https://coitaoc.org/wp-content/uploads/2021/06/Estado-d el-Arte-IoT.pdf. [Accessed: Nov. 03, 2025].
[9] Dialnet, “Estado del arte de un sistema IoT para interacción con objetos,” 2023. [Online]. Available: https://dialnet.unirioja.es/descarga/articulo/8590689.pdf. [Accessed: Nov. 03, 2025].
[10] Intel Corporation, “Arquitectura de referencia para IoT con transferencia de datos,”
2015. [Online]. Available: https://repository.unad.edu.co/bitstream/10596/276
48/4/avelezpe.pdf. [Accessed: Nov. 03, 2025].
[11] Escuela Colombiana de Ingeniería, “Blockchain & IoT para arquitectura segura y transparente,” n.d. [Online]. Available: https://repositorio.escuelaing.edu.co/bitstr eams/c1ccd9bf-d935-4579-9a16-9bce2063f507/download. [Accessed: Nov. 03, 2025]. [12] Infotec, “Nodo multiplataforma de conectividad para IoT,” 2025. [Online]. Available: ht tps://infotec.repositorioinstitucional.mx/jspui/bitstream/1027/491/1/Tes is%20Nodo%20Multiplataforma%20de%20Conectividad%20para%20IoT%200v15.pdf. [Accessed: Nov. 03, 2025].
[13] Random Nerd Tutorials, “Protocolos de comunicación inalámbrica ESP32,” 2022. [Online]. Available: https://randomnerdtutorials.com/esp32-wireless-communicati on-protocols/. [Accessed: Nov. 03, 2025].
[14] A. Vélez Pérez, “Arquitecturas de referencia para IoT con transferencia segura de información,” 2020. [Online]. Available: https://repository.unad.edu.co/bitstream/1 0596/27648/4/avelezpe.pdf. [Accessed: Nov. 03, 2025].
[15] S. Ramadhan, I. Syafalni, N. Sutisna and T. Adiono, “Implementación de redes en malla multisalto utilizando ESP32 para la comunicación IoT,” 2024. [Online]. Available: http s://ieeexplore.proxyutp.elogim.com/stamp/stamp.jsp?tp=&arnumber=10912962. [Accessed: Nov. 03, 2025].
[16] T. Baranwal, S. Varada, S. Das and M. R. Haider, “Sistema IoT tolerante a fallos que utiliza Digital Twin basado en software,” 2025. [Online]. Available: https://arxiv.or g/abs/2505.24047. [Accessed: Nov. 03, 2025].
[17] M. Gayathri and V. V. Snigdha, “Enrutamiento basado en clústeres con autorreparación y eficiencia energética para redes de sensores inalámbricos sostenibles,” 2025. [Online].
Available: https://www.frontiersin.org/journals/communications-and-network s/articles/10.3389/frcmn.2025.1602928/full. [Accessed: Nov. 03, 2025]. [18] S. Gancarčík, J. Šumský and M. Kubaščík, “Exploración de protocolos de comunicación inalámbrica en la plataforma ESP32 para aplicaciones en exteriores,” 2024. [Online]. Available: https://developer.espressif.com/blog/esp-now-for-outdoor-appli cations/. [Accessed: Nov. 03, 2025].
[19] H. B. Jadhav et al., “Protección de arquitecturas de IoT basadas en la nube: un enfoque multiprotocolo,” 2024.
[20] H. Zhang and X. Huang, “Diseño de terminal de control remoto multifuncional para IoT,” 2025. [Online]. Available: https://www.clausiuspress.com/assets/default/a rticle/2025/03/08/article_1741488142.pdf. [Accessed: Nov. 03, 2025]. [21] S. Feyerabend, “Una evaluación real de la idoneidad del ESP32 para su uso en redes inalámbricas ad hoc,” 2025. [Online]. Available: https://www.db-thueringen.de/ser vlets/MCRFileNodeServlet/dbt_derivate_00068872/ilm1-202520021_009-012.p df. [Accessed: Nov. 03, 2025].
[22] A. K. Kowsalyadevi and G. Umamaheswari, “Una investigación exhaustiva de ESP32 para mejorar el alcance de Wi-Fi y el control del tráfico en redes de defensa,” 2025. [23] Y. Zhang et al., “Un modelo de despliegue hexagonal adaptativo para redes de sensores inalámbricos resilientes en agricultura de precisión,” 2024. [Online]. Available: https: //www.nature.com/articles/s41598-024-75571-2. [Accessed: Nov. 03, 2025]. [24] A. Aljumah et al., “Un marco de seguridad de red descentralizada basado en blockchain y SDN para el Internet de las Cosas,” 2025. [Online]. Available: https://www.nature .com/articles/s41598-025-93690-2. [Accessed: Nov. 03, 2025]. [25] T. Azad, M. A. H. Newton, J. Trevathan and A. Sattar, “Interoperabilidad de la red perimetral del IoT: un enfoque multiprotocolo para una comunicación fluida entre dispositivos perimetrales,” 2025. [Online]. Available: https://www.sciencedirect.com/ science/article/pii/S0140366425000829. [Accessed: Nov. 03, 2025]. [26] M. J. Espinosa et al., “Caracterización y evaluación del rendimiento del ESP32 para redes de sensores sincronizados en tiempo real,” 2024. [Online]. Available: https://ro din.uca.es/bitstream/10498/33480/OA_2024_0839.pdf. [Accessed: Nov. 03, 2025].
[27] A. Antony and D. M. Kelambath, “LPMQTT: un protocolo de mensajería IoT de bajo consumo basado en el estándar MQTT,” 2024.
[28] K. A. Babativa Santos, “Pruebas de Seguridad Aplicadas a Infraestructura IoT,” 2023. [Online]. Available: https://repositorio.uniandes.edu.co/server/api/core/bi tstreams/348a8317-b588-43a4-80d1-4cf93a4dd21c/content. [Accessed: Nov. 03, 2025].
[29] D. A. Espinoza Quizhpe and J. A. Bonilla Morán, “Diseño y simulación de una red IPv6 para sucursales enfocado al Internet de las Cosas (IoT),” 2024. [Online]. Available: https://dspace.ups.edu.ec/bitstream/123456789/27923/1/UPS-GT005405.pdf. [Accessed: Nov. 03, 2025].
[30] D. A. Fonseca, “Diseño y prototipado de un sistema de bajo costo basado en ESP32 para el monitoreo en tiempo real de CO2 y ruido,” 2025. [Online]. Available: https: //repository.unad.edu.co/bitstream/10596/70234/dafonseca1.pdf. [Accessed: Nov. 03, 2025].
[31] E. L. Morán Álvarez and A. P. Sánchez Montiel, “Diseño e implementación de un sistema de tele-asistencia para la atención de emergencias a personas con movilidad reducida,”
2025. [Online]. Available: https://dspace.ups.edu.ec/bitstream/123456789/2991
5/1/UPS-GT006099.pdf. [Accessed: Nov. 03, 2025].
[32] J. A. Forero Rodríguez, “Diseño e Implementación de una red de comunicación con los equipos de automatización y control compatibles con GridTeractions,” 2020. [Online]. Available: https://repositorio.uniandes.edu.co/server/api/core/bitstreams /4d1dcf6c-5d3b-4f71-90c0-608a484615ae/content. [Accessed: Nov. 03, 2025]. [33] M. I. Álvarez Bautista and G. Sesea Pascasio, “Creación de biblioteca WiFi ESP para microcontroladores PIC,” 2020. [Online]. Available: https://ru.dgb.unam.mx/bitst ream/20.500.14330/TES01000804235/3/0804235.pdf. [Accessed: Nov. 03, 2025]. [34] V. R. Zurita Navarrete, “Implementación de un sistema de direccionales inalámbrico para chalecos de ciclistas mediante el protocolo ESP-NOW,” 2024. [Online]. Available: https://bibdigital.epn.edu.ec/bitstream/15000/25792/1/CD%2014534.pdf. [Accessed: Nov. 03, 2025].
[35] M. I. Labib, M. ElGazzar, A. Ghalwash and S. N. AbdulKader, “An efficient networking solution for extending and controlling wireless sensor networks using low energy technologies,” 2021. [Online]. Available: https://pmc.ncbi.nlm.nih.gov/articles/PMC862 7223/pdf/peerj-cs-07-780.pdf. [Accessed: Nov. 03, 2025].
[36] T. Baranwal, S. Varada, S. Das and M. R. Haider, “Fault-Tolerant IoT System Using Software-Based Digital Twin,” 2025. [Online]. Available: https://arxiv.org/pdf/25 05.24047v1. [Accessed: Nov. 03, 2025].
[37] J. Macas, H. Pinilla, W. Castellanos, J. D. Alvarado and A. Sánchez, “Diseño e implementación de un Gateway IoT multiprotocolo,” 2025. [Online]. Available: https: //arxiv.org/pdf/2001.08171. [Accessed: Nov. 03, 2025].
[38] L. M. Chatue et al., “Cryptographic Algorithm Grafted onto the ESP-NOW Protocol for Security Optimization in Wireless Sensor Network Chains,” 2025. [Online]. Available: https://www.scirp.org/pdf/jis2025162_57801107.pdf. [Accessed: Nov. 03, 2025]. [39] S. Aqeel, A. S. Khan, I. A. Abbasi, F. Algarni and D. Grzonka, “Enhancing IoT security with a DNA-based lightweight cryptography system,” 2025. [Online]. Available: https: //www.nature.com/articles/s41598-025-96292-0. [Accessed: Nov. 03, 2025]. [40] H. Suomi, “Wireless Connection Technologies for IoT Devices in Long Range, Low-Power Networks,” 2024. [Online]. Available: https://www.theseus.fi/bitstream/10024/8 55114/Suomi_Heli.pdf. [Accessed: Nov. 03, 2025].
[41] Z. Lan, “A Comprehensive Review of Fault-Tolerant Routing Mechanisms for the Internet of Things,” 2023. [Online]. Available: https://thesai.org/Publications/ViewPa per?Volume=14&Issue=7&Code=IJACSA&SerialNo=116. [Accessed: Nov. 03, 2025]. [42] Autor desconocido, “El estado del arte sobre el internet de las cosas: amenazas y buenas prácticas,” 2024. [Online]. Available: https://repository.unad.edu.co/bitstream /handle/10596/28446/Monografia.pdf. [Accessed: Nov. 03, 2025]. [43] L. Da Xu, W. He and S. Li, “Internet of Things in Industries: A Survey,” IEEE Transactions on Industrial Informatics, vol. 10, no. 4, pp. 2233–2243, 2014. [44] A. Zanella, N. Bui, A. Castellani, L. Vangelista and M. Zorzi, “Internet of Things for Smart Cities,” IEEE Internet of Things Journal, vol. 1, no. 1, pp. 22–32, 2014. [45] M. Ammar, G. Russello and B. Crispo, “Internet of Things: A survey on the security of IoT frameworks,” Journal of Information Security and Applications, vol. 38, pp. 8–27,
2018.
[46] S. Sicari, A. Rizzardi, L. Grieco and A. Coen-Porisini, “Security, privacy and trust in Internet of Things: The road ahead,” Computer Networks, vol. 76, pp. 146–164, 2015.
[47] A. Rayes and S. Salam, Internet of Things From Hype to Reality, Springer, 2017. [48] Espressif Systems, “ESP32 Technical Reference Manual,” [Online]. Available: https: //www.espressif.com/.
[49] OASIS, “MQTT Version 3.1.1,” [Online]. Available: http://docs.oasis-open.org/mq tt.
[50] LoRa Alliance, “LoRaWAN Specification,” [Online]. Available: https://lora-allianc e.org.
[51] Autor desconocido, “Estado del arte y tendencias del IoT e IoE,” 2024. [Online]. Available: https://coitaoc.org/wp-content/uploads/2021/06/Estado-del-Arte-IoT .pdf. [Accessed: Nov. 03, 2025].
[52] Autor desconocido, “Análisis integral de seguridad en dispositivos IoT,” 2023. [Online]. Available: https://openaccess.uoc.edu/bitstream/10609/150709/4/oliveiraTF G0624memoria.pdf. [Accessed: Nov. 03, 2025].
[53] Autor desconocido, “Seguridad en el Internet de las Cosas (IoT),” 2024. [Online]. Available: https://openaccess.uoc.edu/bitstream/10609/149592/1/ffernandezapTF G0124memoria.pdf. [Accessed: Nov. 03, 2025].
[54] Autor desconocido, “Arquitecturas IoT – ¿Cuáles son las más comunes?”, 2024. [Online]. Available: https://iotprojects.io/arquitecturas-iot/. [Accessed: Nov. 03, 2025]. [55] Autor desconocido, “Estado del arte de las arquitecturas de internet de las cosas (IoT),”
2014. [Online]. Available: https://www.academia.edu/7197061/Estado_del_Arte_d
e_las_Arquitecturas_de_Internet_de_las_Cosas_IoT_. [Accessed: Nov. 03, 2025]. [56] D. Hercog, T. Lerher, M. Truntič and O. Težak, “Design and Implementation of ESP32- Based IoT Devices,” Sensors, vol. 23, no. 15, p. 6739, 2023. [Online]. Available: https: //www.mdpi.com/1424-8220/23/15/6739 [57] Anonymous, “Design and Implementation of ESP32-Based Edge Computing for Object Detection,” Sensors, vol. 25, no. 6, p. 1656, 2025. [Online]. Available: https://www.md pi.com/1424-8220/25/6/1656 [58] S. Feyerabend, “A Real-World Assessment of the Suitability of the ESP32 for Use in Wireless Ad Hoc Networks,” 2025. [Online]. Available: https://www.db-thueringen. de/servlets/MCRFileNodeServlet/dbt_derivate_00068872/ilm1-202520021_009 -012.pdf. [Accessed: Nov. 03, 2025].
[59] F. Serepas, I. Papias, N. Bellos and V. Marinakis, “Lightweight Embedded IoT Gateway for Smart Homes Based on an ESP32 Microcontroller,” Computers, vol. 14, no. 9, p. 391,
2025. [Online]. Available: https://www.mdpi.com/2073-431X/14/9/391
[60] Anonymous, “Gateway-Free LoRa Mesh on ESP32: Design, Self-Healing Mechanisms, and Empirical Performance,” Sensors, vol. 25, no. 19, p. 6036, 2025. [Online]. Available: https://www.mdpi.com/1424-8220/25/19/6036 [61] Anonymous, “A systematic review of lightweight cryptographic schemes for security and privacy in IoT,” Discover Computing, Springer Nature, 2025. [Online]. Available: https://link.springer.com/article/10.1007/s10791-025-09755-3 [62] Anonymous, “Efficiency and Security Evaluation of Lightweight Cryptographic Algorithms for Resource-Constrained IoT Devices,” Sensors, vol. 24, no. 12, p. 4008, 2024. [Online]. Available: https://www.mdpi.com/1424-8220/24/12/4008 [63] Anonymous, “Securing IoT Edge: A Survey on Lightweight Cryptography, Anonymous Routing and Communication Protocol Enhancements,” International Journal of Information Security, Springer, 2025. [Online]. Available: https://link.springer.com/ar ticle/10.1007/s10207-025-01071-7 [64] Manju and V.K. Srivastav, “Review of Self-Healing IoT Networks Based on AI-Driven Fault Detection and Recovery,” International Journal of Applied and Behavioral Sciences, vol. 2, no. 1, pp. 230–244, 2025.
[65] K. C. Gonugunta and M. Chen, “Self-Healing IoT Mesh Architectures with 5G Support for Autonomous Maintenance,” 2024. [Online]. Available: https://www.researchgate .net/publication/394436348 [66] Anonymous, “Comprehensive Analysis of Lightweight Cryptographic Algorithms for Battery-Limited Internet of Things Devices,” International Journal of Distributed Sensor Networks, Wiley, 2025. [Online]. Available: https://onlinelibrary.wiley.com/ doi/10.1155/dsn/9639728 [67] Anonymous, “A Survey of Efficient Lightweight Cryptography for Power-Constrained Microcontrollers,” Technologies, vol. 13, no. 1, p. 3, 2024. [Online]. Available: https: //www.mdpi.com/2227-7080/13/1/3 [68] Congreso de Colombia, “Ley 1273 de 2009: por medio de la cual se modifica el Código Penal, se crea un nuevo bien jurídico tutelado denominado de la protección de
la información y de los datos,” Diario Oficial No. 47.223, 2009. [Online]. Available: https://www.suin-juriscol.gov.co/viewDocument.asp?id=1676699 [69] Congreso de Colombia, “Ley Estatutaria 1581 de 2012: por la cual se dictan disposiciones generales para la protección de datos personales,” Diario Oficial No. 48.587, 2012. [Online]. Available: https://www.funcionpublica.gov.co/eva/gestornormativo/no rma.php?i=49981 [70] Agencia Nacional del Espectro, “Resolución 105 de 2020: por la cual se actualiza el Cuadro Nacional de Atribución de Bandas de Frecuencias y se establecen condiciones para uso libre del espectro,” 2020. [Online]. Available: https://normograma.crcom.g ov.co/crc/compilacion/docs/resolucion_ane_0105_2020.htm [71] IEEE, IEEE Standard for Ethernet, IEEE Std 802.3-2018. Institute of Electrical and Electronics Engineers, 2018. Disponible en: https://standards.ieee.org/standard/ 802_3-2018.html [72] W. Stallings, Data and Computer Communications, 10th ed. Pearson, 2013.
Cita: Betancur-Obando, Yonatan, Cabrera-Tenganan, Andrés Gabriel (2026), Red IoT inteligente multiprotocolo con protocolos de ciberseguridad, Universidad Tecnológica de Pereira, p. N. https://hdl.handle.net/11059/16903