SISTEMA DE MONITOREO PARA UN ESQUEMA DE BASURAS CON …
92
SISTEMA DE MONITOREO PARA UN ESQUEMA DE BASURAS CON BASE EN UNA TECNOLOGÍA IoT Jonathan Puentes Rivero Carlos Andrés Rodríguez Osorio Universidad Distrital “Francisco José de Caldas” Facultad tecnológica Bogotá, Colombia 2019
Transcript of SISTEMA DE MONITOREO PARA UN ESQUEMA DE BASURAS CON …
SISTEMA DE MONITOREO PARA UN ESQUEMA DE BASURAS CON BASE
EN UNA TECNOLOGÍA IoT
Jonathan Puentes Rivero Carlos Andrés Rodríguez Osorio
Universidad Distrital “Francisco José de Caldas”
Facultad tecnológica
Bogotá, Colombia
2019
SISTEMA DE MONITOREO PARA UN
ESQUEMA DE BASURAS CON BASE
EN UNA TECNOLOGÍA IoT
Jonathan Puentes Rivero Carlos Andrés Rodríguez Osorio
Trabajo de grado para optar al título de:
Ingeniero en telecomunicaciones
Director:
PhD. Luis Fernando Pedraza Martínez
Universidad Distrital “Francisco José de Caldas”
Facultad tecnológica
Bogotá, Colombia
2019
Resumen
En esta monografía se plantea la solución para un mejor control en esquema de
recolección de basuras en la ciudad de Bogotá por medio de un prototipo con tecnología
IoT “LoRa”, con el objetivo de monitorear algunas de las variables que alteran el buen
funcionamiento de este sistema, haciendo uso de diferentes nodos LoRa (dos nodos)
encargados de adquirir los datos de temperatura, humedad y volumen de los contenedores
de basura y posteriormente transmitirlos por medio del protocolo LoRa al Gateway
encargado de subir la información a la nube y de esta forma facilitar el proceso de
monitoreo y control de alarmas por parte de los operarios.
Se plasman los resultados obtenidos en la evaluación de parámetros de calidad de servicio
(perdida de paquetes, jitter y RRSI) de la tecnología LoRa en diferentes escenarios.
Palabras clave: Internet de las cosas, LoRa, LoraWAN, Redes de sensores,
Comunicaciones móviles, parámetros QoS.
Abstract
In this paper, the solution for a better control in the garbage collection scheme in the city of
Bogotá is proposed through a prototype with IoT technology "LoRa", with the objective of
monitoring some of the variables that alter the proper functioning of this system, making
use of different LoRa nodes (two nodes) responsible for acquiring the temperature, humidity
and volume data of the garbage containers and subsequently transmitting them through
the LoRa protocol to the Gateway responsible for uploading the information to the cloud
and in this way facilitates the process of monitoring and control of alarms by operators.
The results found in the evaluation of service quality parameters (packet loss, jitter and
RRSI) of LoRa technology in different scenarios are reflected.
Keywords: Internet of Things, LoRa, LoRaWAN, Sensor networks, QoS parameters,
mobile communications.
Contenido
1. Introducción ............................................................................................................. 1 1.1 Planteamiento del problema y justificación ......................................................... 1 1.2 Objetivos ............................................................................................................ 2
Objetivo general ......................................................................................................... 2 Objetivos específicos ................................................................................................. 2
1.3 Marco de referencias .......................................................................................... 2 Estado del Arte ........................................................................................................... 2
1.4 Marco Teórico .................................................................................................... 4 1.4.1 Espectro electromagnético ................................................................................ 4 1.4.2 Comunicaciones inalámbricas ........................................................................... 5 1.4.2.1 Clasificación ................................................................................................... 5 1.4.3 Protocolo LoRaWAN ......................................................................................... 6 1.4.3.1 Nodos finales y clases de dispositivos ............................................................ 7 1.4.3.2 Conexión ABP y OTAA ................................................................................... 9 1.4.4 Gateway LoRa ................................................................................................. 12 1.4.4.1 Tipos de Gateway ......................................................................................... 13 1.4.4.2 Características del Gateway ......................................................................... 13 1.4.5 Modulación 𝐋𝐨𝐑𝐚𝐓𝐌 ....................................................................................... 13 1.4.5.1 Espectro de dispersión LoRa ........................................................................ 14 1.4.5.2 Propiedades de la modulación LoRa ............................................................ 15 1.4.6 Arduino ............................................................................................................ 16 1.4.6.1 Arduino nano ................................................................................................ 16 1.4.7 Sensor DHT22 ................................................................................................. 17 1.4.8 Sensor HC-SR04 ............................................................................................. 17 1.4.9 Módulo Transceptor RFM95W ......................................................................... 18 1.4.10 Gateway Dragino LG01 ................................................................................. 19 1.4.11 ThingSpeak ................................................................................................... 20 1.4.12 IFTTT ............................................................................................................ 20 1.4.13 Estructura del internet de las cosas (IoT) ...................................................... 21 1.4.13.1 La plataforma cloud .................................................................................... 21 1.4.13.2 La plataforma de Internet de las Cosas ...................................................... 21 1.4.13.3 La solución IoT ........................................................................................... 22 1.4.13.4 Las aplicaciones IoT ................................................................................... 22 1.4.14 Parámetros de configuración en LoRa ........................................................... 22 1.4.14.1 Ancho de banda (BW) ................................................................................ 22 1.4.14.2 Tasa de codificación (CR) .......................................................................... 22 1.4.14.3 Factor de dispersión (SF) ........................................................................... 23 1.4.14.4 Estructura del paquete de datos ................................................................. 23
2. Metodología ............................................................................................................ 24 2.1 Ventajas de la tecnología seleccionada ............................................................ 24 2.2 Selección tecnológica de los nodos LoRa ........................................................ 25 2.3 Selección tecnológica LPWANS ....................................................................... 26 2.4 Implementación de la infraestructura de Internet de las cosas con tecnología LoRa ................................................................................................................................... 28
2.4.1 Construcción de los Nodos LoRaWAN ............................................................ 29 2.4.1.1 Adquisición de datos sensor de DTH22 ........................................................ 29
2.4.1.2 Adquisición de datos sensor HC-SR04 ........................................................ 31 2.4.1.3 Transmisión de datos con LoRa RFM95W ................................................... 33 2.4.2 Implementación del Gateway LoRaWAN ........................................................ 35 2.4.2.1 Estructura interna del Gateway LG-01P ....................................................... 35 2.4.2.2 Configuración de parámetros de red ............................................................ 35 2.4.2.3 Conexión con los nodos LoRa ...................................................................... 36 2.4.3 Configuración del servidor en la nube ThingSpeak ......................................... 37 2.4.4 Creación de la interfaz WEB ........................................................................... 40 2.4.5 Creación del aplicativo móvil ........................................................................... 43 2.4.6 Configuración de alarmas en los nodos .......................................................... 47 2.4.6.1 Configuración del portal IFTTT ..................................................................... 47 2.4.7 Medición de parámetros de calidad del servicio .............................................. 48 2.4.7.1 Medición de parámetros desde TX (RFM95W) ............................................ 48 2.4.7.2 Medición de parámetros desde RX (Gateway) ............................................. 49
3. Resultados y análisis ............................................................................................. 51 3.1 Nodos LoRa implementados .................................................................................. 51 3.2 Servidor en la nube ThingSpeak ............................................................................ 52 3.3 Pagina Web ........................................................................................................... 53
3.3.1 Rendimiento del aplicativo web en ordenadores ............................................. 55 3.3.2 Rendimiento del aplicativo web en dispositivos móviles .................................. 56
3.4 Aplicativo para dispositivos móviles ....................................................................... 57 3.5 Evaluación de Parámetros de calidad del servicio ............................................ 58
3.5.1 Medición de potencia recibida en línea de vista .............................................. 58 3.5.2 Medición de potencia recibida con obstáculos en radiación vertical ................ 60 3.5.3 Medición de potencia con obstáculos en radiación horizontal ......................... 61 3.5.4 Análisis de parámetros de calidad del servicio de transferencia de datos sin línea de vista escenario 1. ................................................................................................ 62 3.5.4.1 Análisis cancha de microfútbol ............................................................... 63 3.5.4.2 Análisis parqueadero .............................................................................. 64 3.5.5 Análisis de parámetros de calidad del servicio de transferencia de datos sin línea de vista escenario 2. ................................................................................................ 65 3.5.5.1 Análisis piso 1. ............................................................................................. 65 3.5.5.2 Análisis parque. ...................................................................................... 67 3.5.5.3 Análisis distancia máxima. ..................................................................... 68 3.5.6 Análisis de parámetros de calidad del servicio en línea de vista. ................... 69
3.6 Desempeño de la comunicación LoRa .............................................................. 71 3.6.1 Factor de Dispersión (SF) ............................................................................... 71 3.6.2 Ancho de banda (BW) ..................................................................................... 71 3.6.3 Ratio de codificación (CR) ............................................................................... 72 3.6.4 Estructura del paquete LoRa ........................................................................... 74 3.6.5 Tiempo en el aire ............................................................................................ 75
4. Conclusiones y trabajos futuros........................................................................... 78
Lista de figuras
Fig 1. Espectro electromagnético [4]. ............................................................................... 4
Fig 2. Clasificación de las redes inalámbricas [5]. ............................................................ 6
Fig 3. Composición de una red común, tomado de LoRaWAN Specification 2019 [6]. ..... 7
Fig 4. Clases de nodos soportados en el protocolo LoRaWAN, tomado de LoRaWAN
Specification 2019 [7]. ...................................................................................................... 9
Fig 5. Activación sobre el aire, tomado de Haciendo IoT con LoRa [9]. .......................... 10
Fig 6. Activación por personalización, tomado de Haciendo IoT con LoRa [9]. .............. 11
Fig 7. Comunicación usando activación sobre el aire en LoRaWAN, tomado de Jaguar
Network [2]. .................................................................................................................... 12
Fig 8. Composición de una red básica entre nodos y gateway LoRa, tomado de Internet of
Things [8]. ...................................................................................................................... 12
Fig 9. Arduino Nano [28]. ............................................................................................... 16
Fig 10. Sensor de humedad y temperatura DHT22 [29]. ................................................ 17
Fig 11. Sensor de ultrasonido HC-SR04 [30]. ................................................................ 18
Fig 12. Modulo transceptor RFM96W [31]. ..................................................................... 19
Fig 13. Gateway Dragino LG01 [32]. .............................................................................. 20
Fig 14. Plataforma en la nube para IoT ThingSpeak [33]. .............................................. 20
Fig 15. Plataforma de integración de aplicaciones en la nube para IoT IFTTT [34]. ....... 21
Fig 16. Estructura de una plataforma de IoT [35]. .......................................................... 21
Fig 17. Estructura del paquete de radio LoRa [23]. ........................................................ 23
Fig 18. Comparativa de tecnologías de comunicación Wireless en función de la cantidad
de datos transmitidos y el consumo energético [37]. ...................................................... 27
Fig 19. Comparativa entre tecnologías LPWAN, celulares y ZigBee en diversos aspectos
[37]. ................................................................................................................................ 27
Fig 20. Arquitectura del sistema de comunicaciones LoRa implementado. .................... 28
Fig 21. Arquitectura implementada en la construcción de los nodos LoRa. .................... 29
Fig 22. Conexiones DTH22 y Arduino nano, cable amarillo (Out), cable rojo (+5V), cable
negro (GND). .................................................................................................................. 30
Fig 23. Diagrama de flujo implementado para la lectura del sensor de humedad y
temperatura. ................................................................................................................... 31
Fig 24. Conexiones HC-SR04, cable rojo (+5V), cable azul (Trig), cable amarillo (Echo),
cable negro (GND). ........................................................................................................ 32
Fig 25. Diagrama de flujo implementado para la lectura del sensor de ultrasonido. ....... 32
Fig 26. Lora Modulo controlador SPI. ............................................................................. 33
Fig 27. Diagrama de conexiones empleado para conectar el módulo RFM95 y el
microcontrolador Arduino. ............................................................................................... 33
Fig 28. Diagrama de flujo empleado en los nodos LoRa. ................................................ 34
Fig 29. Estructura interna del Gateway LG-01P. ............................................................. 35
Fig 30. Configuración de red Gateway LG-01P. .............................................................. 36
Fig 31. Acceso a internet en el Gateway a través de la red LAN inalámbrica. ................ 36
Fig 32. Diagrama de flujo empleado en la configuración y programación del Gateway. .. 37
Fig 33. Creación y configuración de canales en ThingSpeak. ......................................... 38
Fig 34. Canales creados en ThingSpeak para la lectura de datos. ................................. 38
Fig 35. APIkey de lectura en los diferentes canales creados en ThingSpeak. ................ 39
Fig 36. Visualización de los datos para el campo de temperatura en el servidor en la nube
ThingSpeak. .................................................................................................................... 40
Fig 37. Diagrama de casos de uso del aplicativo WEB. .................................................. 41
Fig 38. Interfaz de inicio del aplicativo WEB. .................................................................. 41
Fig 39. Pestaña de monitoreo de variables en los contenedores. ................................... 42
Fig 40. Pestaña de información de contacto de los autores en el aplicativo Web. .......... 43
Fig 41. Interfaz de login aplicativo móvil para monitoreo de sensores de los nodos. ...... 44
Fig 42. Interfaz de monitoreo de variables en la aplicación móvil. .................................. 44
Fig 43. Interfaz de monitoreo por cada sensor al pulsar gráficas. ................................... 45
Fig 44. Diagrama UML de secuencia en el aplicativo móvil. ........................................... 46
Fig 45. Applets del portal IFTTT ..................................................................................... 47
Fig 46. Configuración de asunto y cuerpo de correo ....................................................... 48
Fig 47. Monitor Serial IO Ninja ........................................................................................ 49
Fig 48. Trafico de paquetes en Wireshark. ..................................................................... 50
Fig 49. Montaje final de los Nodos LoRa fuera del recipiente a monitorear. .................... 51
Fig 50. Datos de los dos contenedores publicados en ThingSpeak ................................ 52
Fig 51. Forma de exportar los datos registrados desde ThingSpeak. ............................. 52
Fig 52. Interfaz de acceso a las variables monitoreadas por contenedor. ....................... 53
Fig 53. Apis para visualizar los datos en el aplicativo Web con opción de descargar los
registros. ......................................................................................................................... 54
Fig 54. Interacción con la gráfica de Humedad del nodo 2 en la página WEB. ............... 54
Fig 55. Resultados del test de rendimiento de la página web para PC’s. ........................ 55
Fig 56. Parámetros evaluados para estimar el rendimiento de la página web en
ordenadores. .................................................................................................................. 55
Fig 57. Resultados del test de rendimiento de la página web para dispositivos móviles. 56
Fig 58. Parámetros evaluados para estimar el rendimiento de la página web en dispositivos
móviles. .......................................................................................................................... 56
Fig 59. Interfaces de monitoreo de las variables medidas en el aplicativo móvil. ........... 57
Fig 60. Rendimiento del aplicativo móvil de monitoreo. .................................................. 58
Fig 61. Distancia pruebas líneas de vista primer piso..................................................... 59
Fig 62. Potencia vs distancia en línea de vista. .............................................................. 60
Fig 63. Potencia vs distancia con obstáculos en radiación vertical. ................................ 61
Fig 64. Distancia máxima entre emisor y receptor .......................................................... 61
Fig 65. Potencia vs distancia con obstáculos en radiación horizontal ............................. 62
Fig 66. Distancias recorridas con el emisor .................................................................... 62
Fig 67. Numero de paquetes perdidos en cancha microfútbol ........................................ 63
Fig 68. Numero de paquetes perdidos en parqueadero. ................................................ 64
Fig 69. Ubicación de transmisor LoRa ........................................................................... 65
Fig 70. Numero de paquetes perdidos en piso 1. ........................................................... 66
Fig 71. Numero de paquetes perdidos en la prueba del parque. .................................... 67
Fig 72. Perdida de paquetes distancia máxima. ............................................................. 68
Fig 73. Escenario en línea de vista. ............................................................................... 69
Fig 74. Perdida de paquetes en línea de vista. .............................................................. 70
Fig 75. Estructura del paquete LoRa. ............................................................................. 74
Fig 76. Estructura del paquete transmitido por los nodos LoRa al Gateway. .................. 74
Fig 77. Información obtenida del paquete recibido en el Gateway por medio de Wireshark.
....................................................................................................................................... 75
Fig 78. Información del paquete luego de ser enviado por el Gateway al servidor en la nube
Thingspeak. .................................................................................................................... 75
Lista de tablas
Tabla 1. Velocidades en la comunicación usando modulación LoRa a diferentes anchos
debanda y factores de propagación. [22] ........................................................................ 16
Tabla 2. Comparación de la sensibilidad en el receptor en función del factor de dispersión
en modulación FSK de espectro ensanchado [23]. ......................................................... 23
Tabla 3.Comparativa de características para diferentes versiones de microcontroladores
[36]. ................................................................................................................................. 25
Tabla 4. Comparativa de características para diferentes versiones de microcontroladores
Arduino [36]. ................................................................................................................... 26
Tabla 5. Consumo energético de los dispositivos empleados. ........................................ 51
Tabla 6. Potencia vs distancia en línea de vista. ............................................................. 59
Tabla 7. Potencia vs distancia con obstáculos en radiación vertical. .............................. 60
Tabla 8. Nivel de potencia recibida VS distancia con obstáculos en radiación horizontal 61
Tabla 9. Jitter en cancha de microfútbol ......................................................................... 63
Tabla 10. Jitter en parqueadero ...................................................................................... 64
Tabla 11. Jitter piso 1. .................................................................................................... 66
Tabla 12. Jitter medido en la prueba del parque. ............................................................ 67
Tabla 13.Jitter distancia máxima..................................................................................... 68
Tabla 14. Jitter en línea de vista. .................................................................................... 70
Tabla 15. Relación entre el factor de dispersión (SF), Chips/Symbol y sensibilidad. ...... 71
Tabla 16. Valores de Bitrate nominal obtenidos para un ancho de banda de 125 kHz con
diferentes SF y CR configurados. ................................................................................... 72
Tabla 17. Valores de Bitrate nominal obtenidos para un ancho de banda de 250 kHz con
diferentes valores de SF y CR. ....................................................................................... 73
Tabla 18. Valores obtenidos para tiempo en el aire con una configuración de ancho de
banda de 125kHz, Code Rate variable y factor de dispersión variable. ........................... 76
Tabla 19. Valores obtenidos para tiempo en el aire con una configuración de ancho de
banda de 250kHz, longitud del preámbulo de 2500 symbols, Code Rate variable y factor
de dispersión variable. .................................................................................................... 77
1
1. Introducción
Desde hace unos meses en los diferentes barrios de Bogotá se han venido instalando
contenedores para que los ciudadanos puedan depositar la basura, con lo que se busca
evitar el problema de los residuos arrojados en la calle, sin embargo la implementación de
este sistema de recolección de basura se ha enfrentado a diferentes problemas como la
distribución de los contenedores, así como la frecuencia de recolección de la basura, en
algunos países que este sistema ya ha sido implementado, ha presentado grandes
problemáticas como lo son los incendios de estos mismos generando como consecuencia
el reemplazo de estos contenedores, los cuales tienen un costo bastante elevado, es por
esta razón que se pretende diseñar un sistema para monitorear en tiempo real vía web
variables que puedan determinar el estado del contenedor con el fin de optimizar los
tiempos de recolección de basura y algunas alarmas como incendios o inundaciones,
evaluando parámetros de calidad de servicio en la comunicación de los dispositivos.
El crecimiento de las tecnologías LPWAN plantea la necesidad de estudiar las
características que estás nos presentan y de esta forma poder escoger la tecnología y los
dispositivos óptimos para aplicaciones futuras.
1.1 Planteamiento del problema y justificación
Actualmente el mal uso de los contenedores dispuestos para la disposición de basuras ha
ocasionado problemas de acumulación de residuos, esto debido a los tiempos establecidos
para la recolección de basura en cada uno de los contenedores, puesto que en algunos
casos los contenedores se llenan en tiempos inferiores al esperado, por lo que este
permanece rebosado hasta que llega el día de recolección, caso contrario sucede cuando
el contenedor ha sido usado muy poco por lo que un desplazamiento del camión
compactador implicaría un gasto innecesario.
Es por ello por lo que se desea implementar un sistema de monitoreo evaluando
parámetros de calidad de servicio que permita visualizar en tiempo real algunos
parámetros físicos que permitan determinar el estado de llenado de los contenedores, de
esta forma se podría establecer el mejor momento de recolección sin generar gastos
adicionales en el desplazamiento de los vehículos compactadores.
2
1.2 Objetivos
Objetivo general
Desarrollar un sistema de comunicación IoT con nodos LoRa para monitorear las variables
de temperatura, humedad y porcentaje de llenado para contenedores de basura de la
ciudad de Bogotá.
Objetivos específicos
1. Implementar la infraestructura de Internet de las Cosas para realizar las mediciones
de los sensores del esquema de basuras, como lo son: la temperatura, la humedad
y el porcentaje de llenado de los contenedores de basura.
2. Visualizar la información de los sensores del esquema de basuras a través de la
nube en una plataforma Web.
3. Evaluar parámetros de calidad de servicio (QoS) de la infraestructura IoT
desarrollada.
1.3 Marco de referencias
Estado del Arte
Dada la creciente demanda de nuevas tecnologías como IoT, la cual busca una amplia
conectividad de una gran gama de nuevos elementos, dada la creciente popularidad de
esta y otras tecnologías emergentes las redes también buscan una evolución para suplir
nuevos retos, tecnologías en redes LPWAN como Longe range (Lora), sigfox, estas
tecnologías de bajas frecuencias que permiten gran potencia a largas distancias [1]. Con
estos dispositivos también encontramos el nacimiento de todo tipo de aplicaciones que
además generan una nueva gama de retos para el uso de estas tecnologías, y es
importante registrar análisis de ellas, tales como los parámetros de calidad de estos
servicios.
Se resaltan los múltiples trabajos que se centran en un análisis de las características de
estas tecnologías, trabajos que analizan cual es la mejor manera de configurar estas
tecnologías, teniendo en cuenta la diversa gama de parámetros de configuración, que
permite su configuración al interior de estos elementos [1].
En [2] se realizan mediciones experimentales para determinar la precisión del sensor, Las
redes de sensores inalámbricos y la tecnología de comunicación de red que se utilizan
para respaldar la recolección inteligente de datos agrícolas y el control de equipos en
tecnología IoT.
En [3] se desarrolla una plataforma LoRa en la cual el nodo de riego envía datos a la nube
a través de las pasarelas LoRa por medio de la transmisión inalámbrica. El sistema puede
ser controlado remotamente por aplicaciones móviles.
En el desarrollo de [4] se evalúa empíricamente el rendimiento de propagación en interiores
de LoRa. Las medidas prácticas se analizaron críticamente frente a cuatro modelos de
propagación; Sitio de la UIT genérico, log-distance, multi-wall y trazado de rayos 3D.
En [5] se realizan pruebas de rendimiento en una red LoRa en topología estrella, Con el
fin de verificar la calidad del servicio (QoS) que esta red puede proporcionar, esto permite
extraer métricas de rendimiento básicas, como la tasa de error de paquete (PER), pero
también métricas relacionadas específicamente con la capa física de LoRa.
Se realiza en [6] un sistema de red de malla LoRa para el monitoreo de áreas grandes de
aplicaciones de IoT. Se desplegaron 19 dispositivos de red LoRa mesh en un área de 600m
a 800m y se instaló un gateway que recolectó datos en intervalos de 1 minuto.
En [7,8] se presenta un análisis exhaustivo del impacto de la selección de parámetros de
transmisión LoRa en el rendimiento de la comunicación. En el cual estudiaron el impacto
de la configuración de parámetros en el consumo de energía y la confiabilidad de la
comunicación.
En [10] se realizan pruebas a dos dispositivos LoRa SX1272 y SX1278, a partir de
diferentes configuraciones de firmware en espacios cerrados y abiertos, se le realizan sus
respectivas mediciones de corriente y tiempo para evaluar el consumo de potencia.
Se presenta en [11] una tesis donde se hace uso de dos transceptores LoRa uno que se
usa como Gateway por medio de una Raspberry pi y otro como emisor de paquetes en
4
conjunto de un Arduino, con el objetivo de que el emisor envié sus datos al Gateway y este
los suba a un aplicativo para que el usuario los pueda visualizar, evaluando parámetros de
calidad de servicio en la comunicación.
En [12] y [13] se presentan proyectos enfocados al sector agrícola donde se realizan
pruebas a diferentes dispositivos LoRaWAN y BLE, adicionalmente midieron algunos
parámetros de calidad del servicio como la perdida de paquetes, potencia y distancia
máxima del enlace sin línea de vista.
1.4 Marco Teórico
1.4.1 Espectro electromagnético
El espectro electromagnético es el rango de frecuencias de todas las ondas
electromagnéticas que se pueden propagar a través del espacio libre, ordenadas según su
longitud de onda y su frecuencia (Figura 1).
Como el propio nombre indica, estas ondas tienen un componente magnético y otro
eléctrico. La forma más familiar de radiación electromagnética es la luz visible.
Fig 1. Espectro electromagnético [4].
Los rangos de frecuencias más utilizados en las comunicaciones inalámbricas son los
siguientes:
• Infrarrojos (IR): Se utilizan en comunicaciones punto a punto de corto alcance, son
muy direccionales y no pueden atravesar obstáculos. Este medio se utiliza
habitualmente en el mando a distancia de la televisión y hasta hace unos años era
también un sistema de comunicación que se utilizaba a menudo para conectar
dispositivos situados el uno al lado del otro (un PDA4 con el ordenador o con un
móvil y el teclado con el ordenador). Es el rango de frecuencia más alto para
comunicaciones inalámbricas. [1][2][4]
• Microondas (MW). Este rango de frecuencias es adecuado para transmisiones de
largo recorrido (comunicaciones por satélite, comunicaciones terrestres punto a
punto como alternativa al cable coaxial o la fibra óptica, y también la mayoría de las
tecnologías inalámbricas más habituales que existen actualmente y que
explicaremos brevemente en esta asignatura, como UMTS, Bluetooth o WLAN).
Las microondas suelen ser direccionales y utilizan una parte del espectro con
frecuencias más pequeñas que los infrarrojos. [1]
• Radiofrecuencias (RF): Es el rango que utilizan las transmisiones de radio (FM,
AM) y televisión digital terrestre (TDT). Las radiofrecuencias son omnidireccionales
y pueden atravesar obstáculos sin ningún problema. [1]
1.4.2 Comunicaciones inalámbricas
En un sentido amplio y general, se entiende por comunicaciones inalámbricas aquellas
comunicaciones entre dispositivos (móviles o no) o entre personas que intercambian
información utilizando el espectro electromagnético en medios no guiados.
1.4.2.1 Clasificación
La clasificación de las redes inalámbricas se da atendiendo a diferentes criterios, a
continuación, se presentará una clasificación atendiendo al alcance y a la manera de
controlar el acceso a las redes (Figura 2). [3]
• Redes de área personal inalámbrica (WPAN: wireless personal área networks.
• Redes de área local inalámbrica (WLAN: wireless local area networks).
• Redes de área extendida inalámbrica (WWAN: wireless wide área networks).
Podemos diferenciar dos tipos de WWAN, según quién controle su acceso:
o Comunicación fija (FWWAN: fixed wireless wide area networks).
o Comunicación móvil (MWWAN: mobile wireless wide area networks).
6
Fig 2. Clasificación de las redes inalámbricas [5].
La gran difusión de las WLAN se debe a las importantes ventajas que presentan respecto
a las LAN:
• Movilidad: los usuarios de una WLAN pueden acceder a información en tiempo
real desde cualquier lugar de la organización.
• Instalación simple: no hay que preocuparse por la instalación de cables dentro del
radio de cobertura.
• Flexibilidad: permite acceder a lugares que una LAN cableada no alcanzaría
nunca.
• Bajo coste: aunque el coste inicial de instalación de las WLAN puede ser superior
a las LAN con cable, a largo plazo puede suponer un ahorro, sobre todo en entornos
con cambios frecuentes de ubicación de los dispositivos.
• Escalabilidad: las WLAN se pueden configurar con diferentes topologías de una
manera sencilla según la necesidad del entorno. Podemos tener las WLAN ad hoc
(donde los dispositivos se van añadiendo a la red) y las WLAN con puntos de
acceso conectados a la red principal.
1.4.3 Protocolo LoRaWAN
LoRaWAN es un protocolo de comunicación radio de baja potencia para el internet de las
cosas (IoT). Su propósito es conseguir establecer conexiones de largo alcance. Estas
comunicaciones están enfocadas para pequeños dispositivos IoT o M2M que desean
transmitir poca información y por tanto sin necesidad de grandes velocidades, pero con la
intención de emplear el menor consumo de energía para así poder tener un mayor tiempo
de vida con pequeñas baterías.
Su intención es establecer una red de dispositivos conectados que se les denominará
nodos. Los cuales establecerán un enlace inalámbrico con un elemento más potente capaz
de comunicarse con todos estos elementos de manera gestionada. Este elemento tomará
el nombre de Gateway. A su vez, este gateway será capaz de comunicarse por otro método
de red, con mayor ancho de banda y transmitir toda la información de estos dispositivos a
aquellos elementos que la soliciten. [4]
La especificación LoRaWAN es un protocolo de red de baja potencia y área amplia (LPWA,
por sus siglas en inglés) diseñado para conectar "cosas" operadas por batería a Internet
en redes regionales, nacionales o globales, y se enfoca en requisitos clave de Internet de
las cosas (IoT), como el bidireccional. Servicios de comunicación, seguridad de extremo a
extremo, movilidad y localización.
En una red LoRaWAN clásica (Figura 3), los dispositivos finales denominados nodos se
conectan a Gateways y estos envían todo a un servidor, que por medio de una API entrega
los datos a una aplicación final para el usuario. [5]
Fig 3. Composición de una red común, tomado de LoRaWAN Specification 2019
[6].
1.4.3.1 Nodos finales y clases de dispositivos
Los nodos finales son dispositivos de hardware físico que contienen capacidades de
detección, algo de potencia de cálculo y un módulo de radio para traducir los datos en una
señal de radio.
8
Típicamente los nodos se construyen a partir de los módulos de radio cómo los que
ofrecemos en nuestra tienda online y algún tipo de microcontrolador como Arduino u otros
de mayor potencia de cálculo a los que asociamos diferentes sensores y/o actuadores. [5]
✓ Modo LoRa: comunicación punto a punto
En este modo los nodos pueden trabajar mediante una conexión punto a punto
(P2P), la principal característica de este modo es que no se requiere un dispositivo
intermediario que administre la comunicación, es decir, los dispositivos pueden
enviar entre ellos información directamente, y esto es perfecto para
comunicaciones sencillas. [6]
✓ Mesh
Otra manera es con un tipo de Mesh donde se encuentra un nodo que se encarga
de coordinar la red y su desventaja es que se encuentra limitada a 255 redes de
255 nodos ya que el nodo coordinador solo puede escuchar un nodo a la vez.
✓ LoRaWAN
En modo LoRaWAN los nodos deben conectarse a un gateway que soporta hasta
62,500 y puede escuchar 8 nodos a la vez, para poder unirse a la red y aprovechar
las características del protocolo el nodo debe enviar una serie de llaves de
identificación y seguridad, todos los nodos trabajan en una conexión tipo estrella, y
los mismos nodos aun estando en movimiento se conectan al gateway más cercano
y con mejor calidad de comunicación, muy similar a como funciona una red celular.
[6]
Clases
En el protocolo LoRaWAN existen tres tipos de clases de nodos (Figura 4):
Clase A: Los dispositivos esta clase son los que tienen el menor consumo de
energía. Sin embargo, estos sólo pueden recibir un enlace descendente después
de enviar un mensaje de enlace ascendente.
Los dispositivos de Clase A pueden utilizarse de dos formas:
• Enviar datos en un intervalo de tiempo (por ejemplo, cada 15 minutos)
• Enviar datos con eventos (p. ej. cuando la temperatura supera los 21º o por debajo
de 19º).
Clase B: Los nodos finales que usan de tipo B permiten más espacios de mensajes
de enlace descendente que para los de clase A. Esto reduce la latencia de los
mensajes, pero al mismo tiempo hace que sea menos eficiente en el uso de la
energía.
Clase C: Por último, la clase C tiene ventanas de recepción continua que solo se cierran
cuando el dispositivo está enviando un mensaje de enlace ascendente.
Debido a esto, es el menos eficiente de energía y en la mayoría de los casos necesita una
fuente de energía constante para operar. [5]
Fig 4. Clases de nodos soportados en el protocolo LoRaWAN, tomado de
LoRaWAN Specification 2019 [7].
1.4.3.2 Conexión ABP y OTAA
Existen dos maneras de conectarse a una red LoRaWAN, se requieren una serie de claves
y número de identificación por parte del nodo para lograr el correcto funcionamiento de la
red y mantener su seguridad. [7]
➢ Modo OTAA
En OTAA (Over The Air Activation) es la manera más segura de conectarse a la
red (Figura 5), y los parámetros de configuración son:
• DevEUI: Este es un identificador de fábrica, hace a cada dispositivo único. Esta
configuración en algunos dispositivos se puede modificar.
• AppEUI: Identificador de aplicación único utilizado para agrupar objetos. Esta
dirección de 64 bits se, utiliza para clasificar los dispositivos por aplicación. Esta
Configuración se puede ajustar
• AppKey: Es una clave secreta AES de 128bits compartida entre el dispositivo
periférico y la red. Se utiliza para determinar las claves de sesión. Esta
configuración se puede ajustar.
10
Fig 5. Activación sobre el aire, tomado de Haciendo IoT con LoRa [9].
Con estos datos de manera simple la conexión se realiza de la siguiente manera:
1. El nodo solicita un join (o inicio de sesión) a la red con los datos de configuración y
abre la ventana de recepción.
2. El Gateway recibe la solicitud y la envía al servidor.
3. El servidor verifica que el nodo este dado de alta y la llave de encriptación sea
correcta.
4. Si es correcta asigna una sesión temporal y la envía por medio del gateway al nodo,
si los datos son incorrectos rechaza el join.
5. El nodo recibe la sesión temporal y puede enviar datos a la red.
La principal ventaja de la conexión tipo OTAA es la seguridad ya que la sesión se dice:
“se crea en el aire” y se renueva cada vez que el dispositivo pierde la conexión, es
apagado o reiniciado, esto dificulta que alguien pueda robar la sesión y clonar el
dispositivo. [7]
➢ Modo ABP
El modo ABP (Activation By Personalization, ver Figura 6) es el modo más sencillo de
conexión, los parámetros de conexión son:
• DevAddress: Dirección lógica (equivalente a una dirección IP) que se utilizará para
toda comunicación posterior con la red.
• NetworkSessionKey: Clave de cifrado entre el dispositivo y el operador utilizado
para las transmisiones y para validar la integridad de los mensajes.
• ApplicationSessionKey: Clave de cifrado entre el dispositivo y el operador (a
través de la aplicación) utilizada para transmisiones y para validar la integridad de
los mensajes.
Fig 6. Activación por personalización, tomado de Haciendo IoT con LoRa [9].
Con estos parámetros la conexión se realiza de la siguiente manera:
1. El dispositivo envía datos hacia al Gateway
2. El Gateway válida que los datos corresponda a la sesión
3. Si es correcta la sesión se procesan los datos, sino se rechazan.
La principal ventaja de este tipo de conexión (Figura 7) es que no se requiere hacer un
join a la red para poder enviar datos, la confirmación del lado del servidor no es
necesaria ya que la sesión ya está manualmente asignada, para dispositivos que están
en movimiento o no tienen excelente recepción este tipo de conexión es idónea. La
desventaja es que al encontrarse la llave de encriptación en el dispositivo pudiera ser
extraída y clonada por una atacante.
12
Fig 7. Comunicación usando activación sobre el aire en LoRaWAN, tomado de Jaguar
Network [2].
1.4.4 Gateway LoRa
Las puertas de enlace forman el puente entre los dispositivos y The Things Network (Figura
8). Los dispositivos usan redes de baja potencia como LoRaWAN para conectarse a la
Puerta de enlace, mientras que la Puerta de enlace usa redes de alto ancho de banda
como WiFi, Ethernet o Celular para conectarse a la Red de Cosas. [8]
Fig 8. Composición de una red básica entre nodos y gateway LoRa,
tomado de Internet of Things [8].
Todas las puertas de enlace al alcance de un dispositivo recibirán los mensajes del
dispositivo y los reenviarán a The Things Network. La red duplicará los mensajes y
seleccionará la mejor puerta de enlace para reenviar los mensajes en cola para el enlace
descendente. Una única puerta de enlace puede servir a miles de dispositivos.
1.4.4.1 Tipos de Gateway
Algunos nodos a los cuales se les determina como gateway en una red son los siguientes:
• Firewall de aplicaciones Web: filtra el tráfico hacia y desde un servidor web y
examina los datos de la capa de aplicación.
• API, SOA o XML: gestiona el tráfico que fluye hacia dentro y fuera de un servicio,
una arquitectura orientada a microservicios o un servicio web basado en XML.
• IoT gateway: agrega datos, traduce entre protocolos y procesa datos de sensores
antes de enviarlos hacia adelante y entre otras características.
• Cloud gateway de almacenamiento: traduce solicitudes de almacenamiento con
varias llamadas de API de servicio de almacenamiento en la nube.
• Media gateway: convierte datos del formato requerido para un tipo de red al
formato requerido para otro.
1.4.4.2 Características del Gateway
El Gateway es encargado de comunicarse de forma bidireccional vía LoRa con los nodos
finales. Existe una gran variedad de Gateways en el mercado y a su vez ello una gran
variedad de características diferentes entre ellos, en América y Europa: SX301 (para 915
y 868 MHZ) 8 canales de recepción simultánea, 1 canal de transmisión SO basado en una
distribución de Linux.
Existe un tipo de gateway denominado single channel caracterizado por poseer solo un
canal de recepción comparado con los demás que tienen 8. Un gateway común comercial
puede soportar hasta 62,500 nodos enviando información una vez al día o 1,000 nodos
enviando información cada 30 segundos, aproximadamente.
1.4.5 Modulación 𝐋𝐨𝐑𝐚𝐓𝐌
LoRa es un esquema patentado de modulación de espectro ensanchado que es derivado
de la modulación CSS (Chirp Spread Spectrum) y que intercambia la velocidad de datos
por sensibilidad dentro de un ancho de banda de canal fijo, implementa una velocidad de
datos variable, utilizando factores de propagación ortogonales, lo que le permite al
diseñador del sistema intercambiar velocidad de datos para rango o potencia, para
optimizar el rendimiento de la red en un ancho de banda constante [22].
14
1.4.5.1 Espectro de dispersión LoRa
En la modulación LoRa, la difusión del espectro se consigue generando una señal de
barrido que varía continuamente en frecuencia. Una ventaja de este método es que los
desplazamientos de tiempo y frecuencia entre el transmisor y el receptor son equivalentes,
reduciendo en gran medida la complejidad del diseño del receptor. El ancho de banda de
frecuencia de este barrido es equivalente al ancho de banda espectral de la señal.
La modulación LoRa se Semtech aborda todos los problemas asociados con los sistemas
DSSS para proporcionar una alternativa de bajo costo, bajo consumo de energía y, sobre
todo, robusta a las técnicas tradicionales de comunicaciones de amplio espectro [23].
Podemos definir la tasa de bits de modulación, Rb, como:
𝑅𝑏 = 𝑆𝐹 ∗1
[2𝑆𝐹
𝐵𝑊] 𝑏𝑖𝑡𝑠/𝑠𝑒𝑔 (1)
Donde:
𝑆𝐹 = 𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑝𝑟𝑜𝑝𝑎𝑔𝑎𝑐𝑖ó𝑛
𝐵𝑊 = 𝐴𝑛𝑐ℎ𝑜 𝑑𝑒 𝑏𝑎𝑛𝑑𝑎 𝑑𝑒 𝑚𝑜𝑑𝑢𝑙𝑎𝑐𝑖ó𝑛 (𝐻𝑧)
Ahora se define el periodo de símbolo, 𝑇𝑠, como:
𝑇𝑠 =2𝑆𝐹
𝐵𝑊 𝑠𝑒𝑔 (2)
Así la tasa de símbolos, 𝑅𝑠, es el reciproco de 𝑇𝑠.
𝑅𝑠 =1
𝑇𝑠=
𝐵𝑤
2𝑆𝐹 𝑠𝑖𝑚𝑏𝑜𝑙𝑜𝑠/𝑠𝑒𝑔 (3)
Finalmente se puede definir la tasa de chip, 𝑅𝑐, como:
𝑐 = 𝑅𝑠 ∗ 2𝑆𝐹 𝑐ℎ𝑖𝑝𝑠/𝑠𝑒𝑔 (4)
La hoja de datos que proporciona Semtech establece la siguiente relación: “un chip se
envía por segundo por cada Hertz de ancho de banda”, lo cual se puede interpretar como:
𝑅𝑐 =𝐵𝑤
2𝑆𝐹∗ 2𝑆𝐹 = 𝐵𝑊 𝑐ℎ𝑖𝑝𝑠/𝑠𝑒𝑔 (5)
Adicionalmente la modulación LoRa incluye un esquema de corrección de errores variable
que mejora la robustez de la señal trasmitida a expensas de la redundancia. De esta forma
se puede definir la velocidad binaria nominal de la señal de datos como:
𝑅𝑏 = 𝑆𝐹 ∗[
4
4+𝐶𝑅]
[2𝑆𝐹
𝐵𝑊] (6)
Donde:
𝑆𝐹 = 𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑝𝑟𝑜𝑝𝑎𝑔𝑎𝑐𝑖ó𝑛
𝐶𝑅 = 𝑇𝑎𝑠𝑎 𝑑𝑒 𝑐ó𝑑𝑖𝑔𝑜
𝐵𝑊 = 𝐴𝑛𝑐ℎ𝑜 𝑑𝑒 𝑏𝑎𝑛𝑑𝑎 𝑑𝑒 𝑚𝑜𝑑𝑢𝑙𝑎𝑐𝑖ó𝑛 (𝐻𝑧)
Cada tiempo de símbolo (𝑇𝑠) la frecuencia brinca a un valor fijo y comienza a crecer desde
ahí, el valor al que brinca representa el símbolo del mensaje enviado. La cantidad de bits
que se pueden codificar por símbolo viene dada por un parámetro ajustable llamado
Spreading Factor (𝑆𝐹), por lo cual, si este tiene un valor de N, el símbolo representa N bits
y puede tener 2 elevado a la N posibles valores de frecuencia a lo que puede brincar [9].
1.4.5.2 Propiedades de la modulación LoRa
Algunas propiedades destacadas de la modulación LoRa se nombran a continuación:
➢ Ancho de banda escalable: Lora es capaz de ajustar su ancho de banda y su
frecuencia de operación lo que le permite operar en diferentes modos.
➢ Envolvente Constante: Al igual que FSK, Lora clasifica como una modulación de
envolvente constante, lo que significa que para su demodulación es sencilla y
puede reutilizar amplificadores con ganancia programable de bajo costo sin
hacerles ninguna modificación.
➢ Robustez: Esta modulación es altamente resistente a mecanismos de interferencia
dentro como fuera del canal. Típicamente el recibidor tiene una selectividad fuera
de canal de 90 dB y una repulsión de co-canal de 20 dB. Lo que se compara con
la modulación FSK que tiene una selectividad de 50 dB de rechazo por fuera del
canal y -6dB de rechazo por co-canal.
➢ Inmunidad contra el efecto Doppler: El offset generado por el efecto doppler
insignificante en cierta medida al hecho por la modulación Lora, por lo cual esta
modulación tiene bastante inmunidad a este efecto.
➢ Capacidad de Red: Por medio de la ortogonalidad de SF LoRa es capaz de enviar
múltiples señales por un mismo canal con diferentes SF sin una degradación en la
recepción
➢ Localización: Lora es una modulación inherentemente ideal para radares lo que la
hace buena para aplicaciones de localización y ubicación
Aumentar el bandwith hace la comunicación más rápida, ya que disminuye el tiempo de bit
(Aumenta la capacidad de canal Sharon-Hartley). El aumento del factor de SF vuelve más
16
lenta la comunicación ya que aumenta el tiempo de bit, esto a pesar de que el símbolo
transporta más bits. En la tabla 1 se observan diferentes tasas de transferencia en función
de 𝑆𝐹 y 𝐵𝑊.
SF BW = 125 kHz BW = 250 kHz BW = 500 kHz
6 9.4 kb/s 18.8 kb/s 37.5 kb/s
12 0.293 kb/s 0.588 kb/s 1.17 kb/s
Tabla 1. Velocidades en la comunicación usando modulación LoRa a diferentes
anchos debanda y factores de propagación. [22]
1.4.6 Arduino
Es una plataforma de código abierto para la programación de microcontroladores,
permitiendo que estos dispositivos ejecuten una serie de instrucciones ya programadas y
almacenadas en la placa, esta industria además de proveer la plataforma de programación
también comercializa sus propias placas, las cuales en su totalidad son compatibles con
código abierto, permitiendo que los usuarios las puedan adaptar a sus necesidades [27].
1.4.6.1 Arduino nano
Es una placa pequeña (Figura 9) compuesta por un chip microcontrolador ATmega 328,
con las mismas funcionalidades del Arduino Mega, solo que con una limitación de pines y
memoria, indispensable para proyectos que requieran de una placa pequeña, pues cuenta
con las siguientes características: 14 puertos digitales de entrada/salida, 8 puertos
análogos, una memoria de 16 KB, 1 KB de SRAM y 512 bytes de EPROM [28].
Fig 9. Arduino Nano [28].
1.4.7 Sensor DHT22
Es un sensor de humedad y temperatura compuesto internamente por un sensor capacitivo
(Figura 10) encargado de medir la humedad del aire circundante y un sensor resistivo para
medir la temperatura, los datos son transmitidos por medio del pin de datos con una señal
digital, este sensor solo es capaz de sensar cada 2 segundos y es compatible con el
protocolo Dallas One-Wire Para conectar varios sensores, a continuación, se mencionan
sus características [29]:
❖ Alimentación: 3.3Vdc ≤ Vcc ≤ 5.5Vdc
❖ Rango de medición de temperatura: -40°C a 125 °C
❖ Exactitud de medición de temperatura: <± 0.2 °C
❖ Resolución Temperatura: 0.1°C
❖ Rango de medición de humedad: De 0 a 100% RH
❖ Exactitud de medición de humedad: ± 2% RH (Max ± 2% RH)
❖ Resolución Humedad: 0.1%RH
❖ Tiempo de sensado: 2s
Fig 10. Sensor de humedad y temperatura DHT22 [29].
1.4.8 Sensor HC-SR04
Es un sensor de ultrasonido (Figura 11) capaz de medir distancias y detectar obstáculos
en un rango de 2 a 400 cm, su funcionamiento consiste en enviar un pulso de arranque y
medir la anchura del pulso de retorno, de esta forma poder calcular la distancia en la que
se encuentra el obstáculo, se caracteriza por presentar un bajo consumo, una alta precisión
y un bajo precio, otras de sus características son [30]:
❖ Dimensiones del circuito: 43 x 20 x 15 mm
❖ Tensión de alimentación: 5 Vcc
❖ Frecuencia de trabajo: 40 KHz
18
❖ Rango máximo: 4 m
❖ Rango mínimo: 1.7 cm
❖ Ángulo de medición: 15°
❖ Duración mínima del pulso de disparo (nivel TTL): 10 μS.
❖ Duración del pulso eco de salida (nivel TTL): 100-25000 μS.
❖ Tiempo mínimo de espera entre una medida y el inicio de otro 20 mS.
Fig 11. Sensor de ultrasonido HC-SR04 [30].
1.4.9 Módulo Transceptor RFM95W
Es un módulo de radiofrecuencia de bajo consumo energético (Figura 12) adaptable a
diferentes modulaciones para la comunicación con otros dispositivos, cuenta con un
modem de largo alcance de propagación (Ultra Long Range) y una alta resistencia a las
interferencias, además presenta las siguientes características [31]:
❖ Modem LoRaTM.
❖ 168 dB de presupuesto de enlace máximo.
❖ +20 dBm: salida de RF constante de 100 mW vs. suministro de V.
❖ +14 dBm de alta eficiencia PA.
❖ Velocidad de bits programable hasta 300 kbps.
❖ Alta Sensibilidad: DL hasta -148 dBm.
❖ Parte delantera a prueba de balas: IIP3 = -12.5 dBm.
❖ Excelente inmunidad de bloqueo.
❖ Baja corriente de RX de 10,3 mA, 200 nA.
❖ Sintetizador totalmente integrado con una resolución de 61 Hz.
❖ Modulación FSK, GFSK, MSK, GMSK, LoRaTM y OOK.
❖ Sincronizador de bits incorporado para recuperación de reloj.
❖ 127 dB de rango dinámico RSSI.
❖ Detección automática de RF y CAD con AFC ultrarrápido.
❖ Motor de paquetes de hasta 256 bytes con CRC.
❖ Tamaño de módulo: 16 * 16 mm
Fig 12. Modulo transceptor RFM96W [31].
1.4.10 Gateway Dragino LG01
Es un Gateway de tecnología LoRa de un solo canal (Figura 13), es un dispositivo de
código abierto, es compatible con redes Wifi, Ethernet, celular 3G o 4G, es un dispositivo
inmune a altas interferencia y presenta las siguientes características [32]:
❖ Sistema de código abierto OpenWrt
❖ Bajo consumo de energía
❖ Actualización de firmware vía web
❖ Software actualizable a través de la red
❖ Aprovisionamiento automático
❖ Servidor web incorporado
❖ Administrado por Web GUI, SSH a través de LAN o WiFi
❖ Admite WiFi AP, cliente o modo Ad-Hoc (malla)
❖ Conexión a Internet a través de LAN, WiFi, 3G o 4G
❖ El diseño a prueba de fallos proporciona un sistema robusto
❖ Arduino IDE compatible. Fácil de programar
❖ Banda LoRa disponible a 433/868/915/920 Mhz
❖ Alcance máximo en LoRa: 5 ~ 10 km
❖ Para Linux: Procesador: 400MHz, 24K MIPS Flash: 16 MB; RAM: 64 MB
❖ LoRa Side: MCU: ATMega328P Flash: 32 KB, RAM: 2 KB Chip LoRa:
SX2176 / 78.
20
Fig 13. Gateway Dragino LG01 [32].
1.4.11 ThingSpeak
Es una plataforma libre que permite el análisis de IoT así como la creación de canales para
subir, observar y analizar en vivo los datos en la nube, es compatible con diferentes
dispositivos, es una plataforma muy estable y eficiente, su estructura se muestra en la
Figura 14 [33].
Fig 14. Plataforma en la nube para IoT ThingSpeak [33].
1.4.12 IFTTT
De sus siglas Every thing works better together (todo funciona mejor juntos, Figura 15) es
un portal que permite sincronizar todas las aplicaciones para que trabajen juntas, permite
crear tareas e interacciones entre aplicaciones, haciendo que cuando se presente un
evento automáticamente el portal interactúe con las demás aplicaciones y ejecute una
acción ya programada, es compatible con dispositivos IoT y es sencilla de usar [34].
Fig 15. Plataforma de integración de aplicaciones en la nube para IoT IFTTT [34].
1.4.13 Estructura del internet de las cosas (IoT)
El mercado IoT ofrece cada vez más opciones de plataformas, soluciones y aplicaciones
en la nube. Algunas son más o menos cerradas y otras permiten la construcción de la
plataforma desde la base, a continuación, se describen los componentes o piezas clave
que conforman una plataforma de internet de las cosas en la nube (Figura 16).
Fig 16. Estructura de una plataforma de IoT [35].
1.4.13.1 La plataforma cloud
La conforman una serie de servicios PaaS o platform-as-a-service que son utilizados como
base para montar o desarrollar las soluciones IoT basadas en la nube [35].
1.4.13.2 La plataforma de Internet de las Cosas
Es el siguiente nivel y, como hemos visto, es la base para que los dispositivos conectados
se comuniquen y se construya el ecosistema IoT. Consiste en un conjunto de herramientas
y servicios PaaS y SaaS (software-as-a-service) pensados para el desarrollo de soluciones
22
IoT. Esta se encarga de la seguridad, la escalabilidad y la fiabilidad de la plataforma
IoT.[35]
1.4.13.3 La solución IoT
Se trata de un sistema software end-to-end que es capaz de integrar desde la conexión
física de los dispositivos hasta la interfaz de usuario, pasando por tareas como la gestión
y el análisis de datos.
1.4.13.4 Las aplicaciones IoT
Son las piezas de software mediante las cuales los usuarios interactúan con la plataforma
de Internet de las Cosas. Por decirlo de otra manera, son la cara más visible de la
plataforma. Permiten desarrollar multitud de funciones como gestión de datos o extracción
de información relevante, ejecutar acciones o tomar decisiones basadas en datos sin
necesidad de conocer los entresijos de la plataforma.
1.4.14 Parámetros de configuración en LoRa
En una red de área amplia de baja potencia, se emplea la capa física LoRa la define el
protocolo de comunicación y la arquitectura del sistema, que son los parámetros
determinantes para el ahorro de energía en la batería de un nodo, así como también de la
capacidad de la red, calidad del servicio y seguridad. LoRaWAN define el propio protocolo
MAC y la arquitectura del sistema de la red y a nivel físico, en cambio es LoRa quien
permite el enlace de comunicación de largo alcance.
1.4.14.1 Ancho de banda (BW)
El valor del ancho de banda muestra cómo va a ser la señal de transmisión. Para el caso
de los nodos implementados se pueden escoger entre 3 opciones: 125KHz, 250KHz o
500KHz. Para una transmisión rápida la mejor opción es configurarlos a 500KHz, sin
embargo, se configuran los nodos a 125KHz ya que permite un mayor alcance y mejora la
sensibilidad, por lo que la comunicación tiene un mejor balance en el enlace.
1.4.14.2 Tasa de codificación (CR)
El valor de la tasa de codificación es posible elegirlo entre 4 opciones: 4/5, 4/6, 4/7 y 4/8.
Esto determina que para cada 4 bits útiles en la trama van a ser codificados por 5, 6, 7 u 8
bits de transmisión en función de su valor. El tipo de codificación más pequeña en 8.4,
mayor tiempo en el aire de la transmisión, por lo que toma más tiempo transmitir un
paquete.
1.4.14.3 Factor de dispersión (SF)
El factor de dispersión es el número de bits por símbolo que se utiliza en el procesamiento
de los datos antes de que la señal sea transmitida. Su valor está comprendido entre 6 y
12. Este parámetro es relevante en el tipo de técnica de espectro utilizado. Es decir que
cuanto mayor es el factor de dispersión configurado más capacidad tiene el receptor para
alejarse de la señal de ruido.
Al emplearse una modulación de espectro ensanchado (Chirp) y variación del factor de
propagación LoRaWWAN dispone de diferentes velocidades de transmisión en función de
la señal, estas están comprendidas en el rango de los 0.3kbps y 22kbps. En la Tabla 2 se
muestra la sensibilidad del receptor y la tasa de bits equivalente en función del factor de
dispersión.
Tabla 2. Comparación de la sensibilidad en el receptor en función del factor de dispersión
en modulación FSK de espectro ensanchado [23].
1.4.14.4 Estructura del paquete de datos
En LoRaWAN se encuentran dos tipos de mensaje downlink y uplink. Los mensajes de
uplink so transmitidos por los dispositivos finales (nodos) al servidor de red, utilizando el
gateway como intermediario, estos mensajes utilizan el modo explícito de
empaquetamiento de radio LoRa, el cual está compuesto por la estructura que se ve en la
Figura 17.
Fig 17. Estructura del paquete de radio LoRa [23].
24
2. Metodología
Para el diseño metodológico se pretende identificar de manera sistemática la calidad de
desempeño de un sistema de monitoreo y comunicación basado en tecnología LoRa. En
el ámbito del desarrollo, los sensores se utilizan de acuerdo al contexto, por ejemplo, para
medir temperatura y humedad, así mismos sensores de potencia con el fin de medir la
intensidad con la que está irradiando el transmisor. Se identifican estrategias para
transmitir la información de los sensores de los nodos LoRa al punto de almacenamiento
(Gateway LG01P), recolección de datos o sistemas de monitorización en la nube,
evaluando sus parámetros de calidad de servicio (QoS) en la comunicación.
El prototipo implementado cumple con las especificaciones de la estructura de una
plataforma de IoT, haciendo uso específico de la plataforma cloud hasta aplicación IoT.
Esta arquitectura usa protocolos de red específicos para IoT con su propia red de
comunicación, sin usar el protocolo IP hasta las tecnologías de red.
2.1 Ventajas de la tecnología seleccionada
LoRa está pensado para aplicaciones de baja potencia, de red de área amplia (LPWAN).
Tiene un rango de más de 15 kilómetros y una capacidad de hasta 1 millones de nodos.
La combinación de baja potencia y largo alcance con velocidades de datos máxima a 50
kilobits por segundo (Kbps).
Actualmente LPWAN es la única que cumple con todos los requisitos que exige cualquier
proyecto IoT:
• Conectividad a larga distancia.
• Conectividad segura, mediante triple encriptación.
• Envío bidireccional de pequeños paquetes de datos.
• Consumo eléctrico ultra mínimo, evitando así el problema recurrente del consumo
de batería.
• Geolocalización outdoor/indoor. Actualmente LoRa es la única tecnología de bajo
consumo capaz de geolocalizar con precisión en outdoor e indoor.
• Al no utilizar frecuencias de licencia, los costes de conectividad son
considerablemente inferiores.
2.2 Selección tecnológica de los nodos LoRa
A la hora de determinar que microcontrolador implementar para la unidad de control del
nodo se tienen en cuenta una serie de parámetros a nivel de hardware que nos permitan
desarrollar la solución de manera eficiente y que este se adapte a las necesidades del
proyecto, en la Tabla 3 se muestra una comparativa de dichas características.
Tabla 3.Comparativa de características para diferentes versiones de microcontroladores
[36].
En la Tabla 4 se muestra una comparativa de las diferentes características que se pueden
conseguir en un microcontrolador en diferentes fabricantes. Lo principal que debemos
saber es los requerimientos del proyecto que vamos a implementar. Con esto nos da una
idea de la cantidad de pines analógicos y digitales (normales y de tipo PWM o modulados
por ancho de pulso para simular una salida analógica) que necesitamos para nuestro
trabajo. Este primer escrutinio nos permite descartar algunas placas más simples que no
tengan suficientes pines o, al contrario, descartar las de mayor número de ellos para
reducir los costes puesto que con menos pines es posible implementar el proyecto. En la
Tabla 4 se observa una comparativa entre las diferentes placas de Arduino con el fin de
seleccionar la placa más conveniente para el proyecto.
26
Tabla 4. Comparativa de características para diferentes versiones de microcontroladores
Arduino [36].
2.3 Selección tecnológica LPWANS
En la Figura 18 se observa una comparativa a nivel general de las tecnologías de IoT
para comunicación de datos de bajo consumo energético y largo alcance. Entre ellas
también existen casos en los que se mantiene un equilibrio de prestaciones sin
arriesgar en ningún punto de ellos (LoRa). El tercer factor a considerar es la tasa de
bits, que varía desde los 100 bps hasta los 350 Mbps.
También se puede apreciar en la Figura 18 en el lado izquierdo de la imagen las
tecnologías de menor cantidad de datos transmiten a lo largo del día y por ende tienen
la posibilidad de ser alimentadas por pequeñas fuentes de energía, a la derecha se
encuentran las tecnologías con una mayor transmisión de datos y que tienen un mayor
consumo energético. [37]
Fig 18. Comparativa de tecnologías de comunicación Wireless en función de la cantidad
de datos transmitidos y el consumo energético [37].
Por último, en la Figura 19, se puede observar una representación de la comparativa entre
las diversas tecnologías LPWAN, las tecnologías celulares y la tecnología ZigBee en
aspectos como el rango, consumo energético, ancho de banda, costes de suscripción y de
despliegue de infraestructura.
Fig 19. Comparativa entre tecnologías LPWAN, celulares y ZigBee en diversos aspectos
[37].
28
2.4 Implementación de la infraestructura de Internet de las
cosas con tecnología LoRa
La tecnología que se implementa para llevar a cabo la solución, luego de comparar las
deferentes tecnologías de comunicación inalámbricas que se muestran en la Figura 17, es
LoRa; ya que esta tecnología permite enviar información en distancias superiores a un
kilómetro en entornos urbanos, con un consumo de potencia en la transmisión inferior a
los 27dBm (0.5 W) con un tamaño de trama de datos programado para la transferencia de
datos, la arquitectura de comunicaciones LoRa para el proyecto se muestra en la Figura
20, esta permite establecer una comunicación entre el objeto conectado hasta la aplicación
a utilizar.
Fig 20. Arquitectura del sistema de comunicaciones LoRa implementado.
La arquitectura de red implementa una topología de estrella en la que cada dispositivo final
se comunica con el gateway, el cual actúa de intermediario para comunicarse con el
servidor de red.
En una red de área amplia de baja potencia, se emplea la capa física LoRa la define el
protocolo de comunicación y la arquitectura del sistema, que son los parámetros
determinantes para el ahorro de energía en la batería de un nodo, así como también de la
capacidad de la red, calidad del servicio y seguridad. LoRaWAN define el propio protocolo
MAC y la arquitectura del sistema de la red y a nivel físico, en cambio es LoRa quien
permite el enlace de comunicación de largo alcance.
2.4.1 Construcción de los Nodos LoRaWAN
En este caso se emplean una serie de sensores con características de funcionamiento
específicas, dentro de los sensores implementados se encuentran:
• Sensor de temperatura ambiente y humedad relativa DTH22, el cual utiliza un
sensor capacitivo de humedad y un termistor para medir el aire circundante.
• Sensor de ultrasonido HC-SR04, con el cual es posible calcular distancias por
medio de las señales acústicas generadas por el sensor en un rango de 2 a 450
cm.
Adicionalmente se hace uso del módulo RF95W, el cual se encarga de transmitir los datos
capturados por los sensores, y enviarlos encapsulados al gateway por medio del protocolo
LoRaWAN, en la Figura 21 se muestra el esquema implementado para los nodos.
Fig 21. Arquitectura implementada en la construcción de los nodos LoRa.
2.4.1.1 Adquisición de datos sensor de DTH22
El sensor DHT22 es un sensor digital de Temperatura y Humedad, el cual es posible
implementar con cualquier microcontrolador. Utiliza un sensor capacitivo de humedad y un
termistor para medir el aire circundante y solo un pin para la lectura de los datos. El rango
de medición de temperatura es de -40°C a 80 °C con precisión de ±0.5 °C y rango de
humedad de 0 a 100% RH con precisión de 2% RH, el tiempo entre lecturas debe ser de
2 segundos.
30
En la Figura 22 se aprecia el diagrama de conexiones entre el sensor DTH22 y el
microcontrolador, dichas conexiones aplican para ambos nodos identificados con el Id NX1
para el nodo 1 y NX2 para el nodo 2.
Fig 22. Conexiones DTH22 y Arduino nano, cable amarillo (Out), cable rojo (+5V), cable
negro (GND).
La adquisición de los datos provenientes del sensor implementado se configura a través
de un código en Arduino el cual permite realizar la verificación del estado del sensor,
posteriormente se realizar la lectura de datos, en caso que no detecté sensor conectado
se emite una alarma informando que no se está reconociendo el sensor, en la Figura 23
se muestra el diagrama de flujo del funcionamiento del sensor.
Fig 23. Diagrama de flujo implementado para la lectura del sensor de humedad y
temperatura.
2.4.1.2 Adquisición de datos sensor HC-SR04
El sensor HC-SR04 posee dos transductores: un emisor y un receptor piezoeléctricos,
además de la electrónica necesaria para su operación. El funcionamiento del sensor es el
siguiente: el emisor piezoeléctrico emite 8 pulsos de ultrasonido(40KHz) luego de recibir la
orden en el pin TRIG, las ondas de sonido viajan en el aire y rebotan al encontrar un objeto,
el sonido de rebote es detectado por el receptor piezoeléctrico, luego el pin ECHO cambia
a Alto (5V) por un tiempo igual al que demoró la onda desde que fue emitida hasta que fue
detectada, el tiempo del pulso ECO es medido por el microcontrolador y así se puede
calcular la distancia al objeto. El funcionamiento del sensor no se ve afectado por la luz
solar o material de color negro. En la Figura 24 se puede observar el diagrama de
conexiones empleado.
32
Fig 24. Conexiones HC-SR04, cable rojo (+5V), cable azul (Trig), cable amarillo (Echo),
cable negro (GND).
Sabiendo que la velocidad del sonido es de aproximadamente 340m/s (343,2m/s a 20º de
temperatura ambiente), podremos calcular la distancia recorrida por la onda para ir y
volver. Lógicamente esa distancia la acabaremos dividiendo por dos para establecer la
distancia aproximada a la que se encuentra el objeto. Con base a esta variación de
distancia y conociendo las dimensiones del tanque es posible calcular el volumen que está
siendo ocupado empleando la ecuación de volumen para un rectángulo, la cual consta de
multiplicar lado por ancho y la variación en altura que obtenemos con el sensor, en la
Figura 25 se muestra el diagrama de flujo empleado.
Fig 25. Diagrama de flujo implementado para la lectura del sensor de ultrasonido.
2.4.1.3 Transmisión de datos con LoRa RFM95W
Para realizar la comunicación del módulo RFM95W con el Arduino se debe configurar el
sistema con el protocolo de comunicaciones “SPI” (Figura 26) entre el módulo RFM95W y
el Arduino nano, esto se hace incluyendo la librería “RadioHead95” en el Arduino la cual
permite realizar la comunicación entre los dispositivos, así mismo se incluyen las librerías
necesarias para realizar la respectiva comunicación LoRa del nodo con el gateway, y el
funcionamiento del dispositivo.
Fig 26. Lora Modulo controlador SPI.
Al realizar la adquisición de los datos provenientes de los sensores implementados se
configuran a través de un código en Arduino el cual permite realizar la verificación de la
lectura de cada uno de estos, el módulo RFM95W (Figura 27) permite realizar la lectura y
escritura del Arduino sin que se vea afectado su funcionamiento y comunicarse con el
gateway a través de la librería RadioHead.
Fig 27. Diagrama de conexiones empleado para conectar el módulo RFM95 y el
microcontrolador Arduino.
34
El diagrama de flujo empleado para la transmisión de datos se muestra en la Figura 28,
inicialmente se valida que existan datos almacenados correspondientes a la lectura de los
sensores, posterior a esto se verifica que exista conexión con el gateway enviando una
petición de conexión, el Gateway responde con una confirmación indicando que está listo
para recibir datos, una vez que se establece la conexión entre el modulo y el Gateway se
envían los datos de los sensores empaquetados, si hay algún problema en la transmisión
de datos se envía una petición por parte del Gateway para que se restablezca la conexión.
Fig 28. Diagrama de flujo empleado en los nodos LoRa.
2.4.2 Implementación del Gateway LoRaWAN
La implementación del Gateway LoRa consta de tres fases, la primera es el realizar las
conexiones físicas de los diferentes periféricos que interactúan en el Gateway, la segunda
consiste en la configuración de los parámetros de red del Gateway para darle salida a
internet, y la tercera consiste en programar el microcontrolador que incorpora el Gateway,
para comunicarse con los nodos y establecer una conexión con el servidor en la nube a
través del protocolo MQTT.
2.4.2.1 Estructura interna del Gateway LG-01P
En la Figura 29 se muestra la estructura interna del Gateway implementada, en la que
interactúa el microcontrolador con los diferentes módulos de comunicación requeridos
(WiFi, LoRaWAN).
Fig 29. Estructura interna del Gateway LG-01P.
2.4.2.2 Configuración de parámetros de red
Para realizar la respectiva conexión del servidor en la nube y el Gateway es necesario
configurar los parámetros básicos de red del dispositivo, el Gateway es posible configurarlo
en diferentes redes, ya sea WiFi, 4G LTE, Celular 3G y UMTS/HSPA+, en este caso se
configura a través de una red inalámbrica (Figura 30).
36
Fig 30. Configuración de red Gateway LG-01P.
Al ingresar al sistema se configura como WiFi client (Figura 31), esto con el fin de darle
salida a internet al Gateway y poder conectarlo con el servidor de aplicación ThingSpeak.
Fig 31. Acceso a internet en el Gateway a través de la red LAN inalámbrica.
2.4.2.3 Conexión con los nodos LoRa
En esta sección se describe el diagrama de flujo (Figura 32) empleado en el Gateway para
la conexión con los nodos LoRa, inicialmente se configuran los parámetros de transmisión
para que el Gateway se pueda comunicar con los nodos, una vez que el Gateway se
comunica con los nodos se desempaquetan los datos recibidos, en este caso los datos se
separan y almacenan en variables diferentes, en base al número de identificación de cada
nodo.
Los datos recibidos son almacenados para posteriormente ser enviados al servidor
ThingSpeak en la nube una vez que se establece la conexión del servidor con el Gateway,
lo anterior se logra empleando el protocolo de comunicación MQTT.
Fig 32. Diagrama de flujo empleado en la configuración y programación del Gateway.
2.4.3 Configuración del servidor en la nube ThingSpeak
Para que ThingSpeak se sincronice con el Gateway se debieron crear canales para cada
uno de los nodos en los contenedores (Figura 33), en la configuración de canales se
establecen los campos correspondientes a las variables medidas, así mismo se determinan
las claves de lectura (Read API) que se deben configurar en el Gateway para que pueda
interactuar con el servidor.
38
Fig 33. Creación y configuración de canales en ThingSpeak.
Es necesario la creación y configuración de múltiples canales públicos (Figura 34) en
ThingSpeak para enlazar con el gateway, con el fin de poder almacenar los datos
recolectados por los nodos y visualizarlos en la página web.
Fig 34. Canales creados en ThingSpeak para la lectura de datos.
LoRaWAN incluye dos niveles de seguridad uno para la red y otro para la aplicación. La
seguridad de la red garantiza la autenticidad del nodo en la red, mientras que la capa de
seguridad de la aplicación garantiza que el operador de red no tenga acceso a los datos
de la aplicación del usuario final, esto se logra haciendo uso del algoritmo de cifrado
AES128:
• Network Session Key: Clave de 128 bits que garantiza la seguridad a nivel de red.
• Application Session Key: Clave de 128 bits que garantiza la seguridad extremo a
extremo a nivel de aplicación.
• Application Key: Clave de 128 bits que garantiza la seguridad extremo a extremo a
nivel de aplicación
ThingSpeak otorga un API de escritura y lectura que se generan automáticamente al
momento de crear los canales, cada uno de estos es identificado por el ID del canal y por
una clave única generada (APIkey).
Para el proceso de obtener los datos alojados en el servidor se recurre a la APIkey de
lectura. En Figura 35 se identifican las APIkey implementadas.
Fig 35. APIkey de lectura en los diferentes canales creados en ThingSpeak.
En la Figura 36 se muestra como se visualizan los datos en Thingspeak para cada uno de
los campos leídos.
40
Fig 36. Visualización de los datos para el campo de temperatura en el servidor en la
nube ThingSpeak.
2.4.4 Creación de la interfaz WEB
El desarrollo del aplicativo web se realiza en el gestor de contenido Webnode, ya que es
una alternativa fiable para la creación e implementación de aplicativos en los que se
incluyen interfaces de usuario. El aplicativo posee una interface agradable al usuario
permitiendo visualizar la información de los sensores de cada nodo, Historiales y la opción
de descargar los registros de los sensores en diferentes formatos, cuando las gráficas
están saturadas o no están dentro de los parámetros se pueden reiniciar mediante el
mismo aplicativo. En la Figura 37 se muestra el diagrama de casos de uso del aplicativo
web.
Fig 37. Diagrama de casos de uso del aplicativo WEB.
El aplicativo cuenta con 3 pestañas (Figura 38); Inicio, Contenedores y Nuestro equipo, en
la pantalla de inicio se encuentra la presentación del proyecto.
Fig 38. Interfaz de inicio del aplicativo WEB.
42
La pestaña contenedores cuenta con un menú de opciones donde se resaltan los dos
contenedores monitoreados, al seleccionar una de las opciones se despliega una nueva
ventana (Figura 39) donde se visualizan gráficamente los datos de los sensores, la fecha
y hora local, existe la opción de exportar el registro de datos en tres formatos: JSON, XML,
CSV.
Fig 39. Pestaña de monitoreo de variables en los contenedores.
En la pestaña Nuestro Equipo (Figura 40) se muestra la información de contacto de los
autores del proyecto, así mismo el planteamiento del problema y la justificación del
proyecto.
Fig 40. Pestaña de información de contacto de los autores en el aplicativo Web.
2.4.5 Creación del aplicativo móvil
Se realiza la creación e implementación de un aplicativo en la herramienta App Inventor
para dispositivos móviles con sistema operativo Android, en la cual podemos visualizar el
registro de datos transmitidos al Gateway por los nodos. El aplicativo consta de una interfaz
de usuario sencilla con validación de ingreso, es decir que solo se puede acceder a la
información si se cuenta con el usuario y clave respectiva, en la Figura 41 se muestra la
interfaz de login del aplicativo móvil.
44
Fig 41. Interfaz de login aplicativo móvil para monitoreo de sensores de los nodos.
Al autenticarse el usuario en el aplicativo móvil se ingresa al menú de monitoreo (Figura
42), en este apartado el usuario puede visualizar las variables de los sensores para cada
contenedor, así mismo tiene la opción de desplegar en una nueva ventana las gráficas e
historial por cada sensor.
Fig 42. Interfaz de monitoreo de variables en la aplicación móvil.
Una vez se ingresa a la pantalla de usuario se visualiza la información de los sensores
capturada y enviada del gateway, los datos están separados en la aplicación por zonas,
donde cada zona corresponde a un nodo, en cada zona está configurado la visualización
de las tres variables medidas, también es posible observar el estado de recepción de datos,
es decir si los datos si están siendo transmitidos por el gateway hacia la aplicación, al
oprimir el botón graficas se despliega una nueva ventana (Figura 43) con graficas
interactivas de cada sensor.
Fig 43. Interfaz de monitoreo por cada sensor al pulsar gráficas.
A continuación, se describe el diagrama de interacciones y procesos del aplicativo móvil
en la interfaz de login (Figura 44), en este se muestra como está estructurada la interfaz y
como esta interactúa con el usuario final.
46
Fig 44. Diagrama UML de secuencia en el aplicativo móvil.
El usuario ingresa a la aplicación, en la interfaz de login valida su usuario y contraseña, si
los datos son correctos ingresa a la interfaz de monitoreo, de lo contrario se mantendrá en
la pestaña de login, estando en la ventana de monitoreo la aplicación despliega los datos
de los sensores leídos, así mismo muestra mensajes del estado de la conexión con el
servidor ThingSpeak, de esta forma se determina si el servidor le está enviando datos a la
aplicación, en esta ventana el usuario puede presionar el botón de gráficas, al hacerlo se
despliega una nueva ventana con el registro grafico de los valores de los sensores leídos,
esto se puede hacer por cada variable leída, si el usuario decide regresar, la aplicación lo
devuelve a la ventana de monitoreo, de esta forma el usuario puede consultar otro sensor
o salir de la aplicación.
2.4.6 Configuración de alarmas en los nodos
Para generar las alarmas de cada uno de los eventos críticos que se presentan se realizó
por medio del portal web IFTTT, para ello se le acciono un evento de webhooks, cuando
se publique un evento en el link the webhooks se accionaran varias tareas previamente
programadas en el portal web, pues este enviara un correo electrónico y un mensaje de
texto de alarma indicando que alguna de las variables medidas se ha salido de su límite y
el usuario debe tomar acciones para solucionar este evento, por ejemplo si se acciona el
applet Contenedor1 se genera una alarma al correo electrónico asociado en IFTTT
indicando que el contenedor 1 presenta la variable que suministra ThingSpeak en un punto
crítico
2.4.6.1 Configuración del portal IFTTT
En el portal IFTTT podemos crear varios servicios o applets que realicen una acción
diferente cada uno de ellos, por lo cual se crearon dos applets uno para generar alarmas
del contenedor 1 y otro para el contenedor 2 como se observa en la Figura 45.
Fig 45. Applets del portal IFTTT
Para poder generar las alarmas al correo electrónico se debe configurar el asunto y cuerpo
del correo como se observa en la Figura 46.
48
Fig 46. Configuración de asunto y cuerpo de correo
El valor correspondiente a la variable Value1 lo suministra ThingSpeak cada vez que
publique una alarma en webhooks.
2.4.7 Medición de parámetros de calidad del servicio
Se debe tener en cuenta que en la obtención y análisis de datos se lleva a cabo por medio
del software IO Ninja y Wireshark, los cuales tienen como objetivo corroborar los tiempos
de emisión, recepción y entrega del paquete.
2.4.7.1 Medición de parámetros desde TX (RFM95W)
Para poder analizar los datos emitidos por el transceptor se debe configurar el
microcontrolador para que envié simultáneamente los datos por el puerto serial y de esta
forma poder acceder a ellos con mayor facilidad.
Se instaló el programa IO Ninja (Figura 47), por medio del cual se monitoreo la información
transmitida y se destacaron los datos de interés para proceder a analizar cada uno de los
parámetros QoS.
Fig 47. Monitor Serial IO Ninja
La información de los paquetes enviados por el transmisor (tiempo, estado de enlace,
datos, secuencia) serán de gran ayuda para analizar los parámetros Qos cuando se
comparen respecto de los del receptor (Gateway).
2.4.7.2 Medición de parámetros desde RX (Gateway)
Por medio del software Wireshark se pudo obtener la información necesaria para medir los
parámetros de calidad de servicio del Gateway, pues se enlazo con la computadora con
una dirección IP estática y se inició la consola de Arduino en donde se puede observar
toda la información recibida por el transceptor rfm95w en el Gateway, como ya existe un
tráfico de datos entre la computadora y el Gateway, Wireshark puede ver esta información
y almacenarla con los tiempos de recepción para posteriormente poder exportarla y realizar
un análisis más detallado, para obtener únicamente la información del Gateway se aplicó
un filtro en Wireshark en donde solo se pudiera ver la dirección IP de destino la asignada
al Gateway como se observa en la Figura 48.
50
Fig 48. Trafico de paquetes en Wireshark.
3. Resultados y análisis
3.1 Nodos LoRa implementados
En el diseño de los nodos se implementó un circuito de unas dimensiones pequeñas y de
una forma que si alguno de los componentes se avería pueda ser reemplazado con
facilidad, pues se realizó un base para el Modulo RFM95W con su respectivo conector
SMA para la antena y una base en la que se puede encajar tanto el Arduino como el módulo
del transceptor LoRa.
Obteniendo finalmente un solo montaje en donde se integran todos los módulos y sensores
del sistema como se observa en la Figura 49.
Fig 49. Montaje final de los Nodos LoRa fuera del recipiente a monitorear.
La fuente de alimentación (el consumo se muestra en la Tabla 5) para todo el montaje en
cada nodo se realiza a través de bancos de baterías recargables (Powerbank), estas
baterías permiten que cada nodo tenga una carga aproximada de 7 días las 24 horas,
debido a que en el código fuente de cada nodo se establece que debe ser activado solo
cuando vaya a enviar información, de lo contrario se encuentre en un estado de
hibernación, esto se realiza con tiempos configurables.
Dispositivo Consumo corriente (mA) Estado de transmisión (mA)
Microcontrolador Arduino 6.8 10.5
Nodo LoRa 1.2 13.5
Tabla 5. Consumo energético de los dispositivos empleados.
52
3.2 Servidor en la nube ThingSpeak
La publicación de los datos en ThingSpeak (Figura 50) tuvo un resultado satisfactorio por
medio de la consola interna de Linux del Gateway con el comando "mosquitto_pub", ya
que haciendo uso de la librería de ThingSpeak en el Gateway el dispositivo presenta un
retardo de un minuto y medio en realizar la publicación de cada dato, por medio de la
consola los datos son publicados al instante que son recibidos en el Gateway, por tal
motivo se optó por emplear el protocolo de comunicación MQTT para la publicación de los
datos en la nube.
Fig 50. Datos de los dos contenedores publicados en ThingSpeak
Desde el servidor en la nube ThingSpeak es posible exportar los datos registrados (Figura
51) de los sensores en diversas zonas horarios, dichos datos se descargar en formato CSV
con lo cual puede ser manipulados desde Excel.
Fig 51. Forma de exportar los datos registrados desde ThingSpeak.
3.3 Pagina Web
Como solo se puedo hacer uso de un canal para la publicación de los datos por medio del
comando de Linux y la interfaz de usuario de la plataforma de ThingSpeak no permite
interactuar y visualizar la información de una forma organizada, por lo tanto se optó por
crear una página web en Webnode (Figura 52), la cual se encuentra sincronizada con los
datos publicados en ThingSpeak y proyecta la información de una forma más ordenada e
interactiva para el usuario, separando cada una de las variables por contenedores.
Fig 52. Interfaz de acceso a las variables monitoreadas por contenedor.
En la Figura 53 se muestra cómo se puede descargar los datos registrados por cada
variable medida (Apis en la WEB), Temperatura, humedad y volumen en diferentes
formatos.
54
Fig 53. Apis para visualizar los datos en el aplicativo Web con opción de descargar los
registros.
Para mayor comodidad del usuario es posible interactuar con la gráfica, de esta manera
podemos ubicarnos en un punto específico de la gráfica (Figura 54) y consultar información
útil, por ejemplo, el valor medido en ese punto, la fecha en la que fue tomado y la hora a
la que se registró ese valor.
Fig 54. Interacción con la gráfica de Humedad del nodo 2 en la página WEB.
En este caso se evalúa el rendimiento de la página web en versión de PC y dispositivos
móviles, de esta forma se determina el comportamiento del aplicativo web en diversos
dispositivos y como responde a estos.
3.3.1 Rendimiento del aplicativo web en ordenadores
Para evaluar el desempeño de la página web en ordenadores se hace uso de la
herramienta de testing de google PageSpeed Insights, arrojando los resultados que se
muestran en la Figura 55.
Fig 55. Resultados del test de rendimiento de la página web para PC’s.
El resultado para ordenadores fue del 97, lo que significa que los parámetros evaluados
(Figura 56) tienen un tiempo rápido de respuesta, superando todos el 90.
Fig 56. Parámetros evaluados para estimar el rendimiento de la página web en
ordenadores.
56
3.3.2 Rendimiento del aplicativo web en dispositivos móviles
Para evaluar el desempeño de la página web en dispositivos móviles se hace uso de la
misma herramienta de testing, arrojando los resultados que se muestran en la Figura 57.
Fig 57. Resultados del test de rendimiento de la página web para dispositivos móviles.
El resultado para dispositivos móviles fue del 84, lo que significa que los parámetros
evaluados (Figura 58) tienen un tiempo moderado de respuesta, por tal razón puede
presentar problemas de rendimiento en teléfonos antiguos.
Fig 58. Parámetros evaluados para estimar el rendimiento de la página web en
dispositivos móviles.
3.4 Aplicativo para dispositivos móviles
En la Figura 59 se muestra la interfaz de monitoreo de las variables una vez se loguea el
usuario, en esta se muestran los datos de los sensores para los dos contenedores, con la
opción de ver las gráficas por separado para cada uno.
Fig 59. Interfaces de monitoreo de las variables medidas en el aplicativo móvil.
Se evalúa el rendimiento de la aplicación móvil haciendo uso de la herramienta Android
Profiler (Figura 60), en cuanto al consumo de recursos de red, CPU, RAM y batería del
dispositivo móvil, los resultados se muestran en la Figura 60, en trabajos futuros la
aplicación se podría optimizar reduciendo bloques en la programación de la misma.
58
Fig 60. Rendimiento del aplicativo móvil de monitoreo.
3.5 Evaluación de Parámetros de calidad del servicio
Se realizaron mediciones de parámetros de calidad de servicio como lo son los niveles de
potencia (RSSI), Jitter y perdida de paquetes, esto se realizó en diferentes escenarios, en
línea de vista y sin línea de vista, una parte de las mediciones se realizó en las
instalaciones de la universidad distrital Francisco José de Caldas sede tecnológica.
3.5.1 Medición de potencia recibida en línea de vista
Esta prueba se realizó en el primer piso de los bloques 1, 2, 3,4 de la universidad distrital
Francisco José de Caldas en línea recta como se evidencia en la Figura 61, en esta se
describe el escenario de pruebas para medir los niveles de potencia marcados en el
gateway.
Fig 61. Distancia pruebas líneas de vista primer piso.
El objetivo principal de esta prueba es obtener una relación distancia con potencia RSSI
(indicador de fuerza de la señal recibida, Tabla 6) por el transceptor, en la cual se
obtuvieron los siguientes resultados.
EN LÍNEA DE VISTA
Distancia (m) RSSI (dBm)
9,255 -60
14,4 -64
18,366 -77
24,452 -63
30,687 -79
35,575 -77
40 -74
Tabla 6. Potencia vs distancia en línea de vista.
En la Figura 62 se observan los niveles de potencia medidos para diferentes distancias
según el escenario de pruebas de la Figura 61.
60
Fig 62. Potencia vs distancia en línea de vista.
Se pueden observar unos niveles de potencia muy similares sin variaciones drásticas, esto
debido a que siempre estuvo en línea de vista y las distancias no fueron lo suficientemente
largas.
3.5.2 Medición de potencia recibida con obstáculos en radiación
vertical
En esta prueba se dejó fijo el Gateway en el piso número 1 del bloque 1,2,3,4 de la
universidad y el emisor se fue desplazando durante cada uno de los pisos superiores,
teniendo en cuenta que cada uno de los pisos tiene una altura de 2.548 metros y las
planchas intermedias un grosor aproximado de 20 cm, en la Tabla 7 se muestran los
resultados obtenidos mientras que en la Figura 63 se muestra el comportamiento del nivel
de potencia en este escenario.
CON OBSTÁCULOS
PISO distancia(m) RSSI (dBm)
2 2,548 -55
3 5,096 -61
4 7,644 -92
5 10,192 -92
Tabla 7. Potencia vs distancia con obstáculos en radiación vertical.
-100
-80
-60
-40
-20
0
20
5 10 15 20 25 30 35 40 45R
SSI (
dB
m)
Distancia (m)
POTENCIA VS DISTANCIA
Fig 63. Potencia vs distancia con obstáculos en radiación vertical.
Durante estas pruebas se observó una variación más significativa en la potencia, pues
a medida que se fueron subiendo más pisos la potencia percibida en el emisor fue cada
vez menor como se observa en la Figura 65.
3.5.3 Medición de potencia con obstáculos en radiación horizontal
Para la ejecución de esta prueba se realizó un desplazamiento por medio de un
vehículo en el cual se transportaba el dispositivo transmisor, obteniendo una distancia
máxima de comunicación de 1000 m sin línea de vista (Figura 64), en la Tabla 8 se
muestran los resultados obtenidos para esta prueba.
Fig 64. Distancia máxima entre emisor y receptor
DISTANCIA (m) RSSI (dBm)
600 -78
900 -96
1000 -98
Tabla 8. Nivel de potencia recibida VS distancia con obstáculos en radiación horizontal
-130
-80
-30
20
0 2 4 6 8 10 12
RSS
I (d
Bm
)
Distancia (m)
POTENCIA VS DISTANCIA
62
Fig 65. Potencia vs distancia con obstáculos en radiación horizontal
En la Figura 65 se evidencio un gran cambio en la potencia percibida por el emisor, debido
a la gran distancia recorrida; en las distancias mayores a 1 kilómetro se perdió
completamente la comunicación.
3.5.4 Análisis de parámetros de calidad del servicio de
transferencia de datos sin línea de vista escenario 1.
En esta prueba se dejó fijo el Gateway en el piso numero 5 Bloque 1 y el emisor se
desplazó por dos puntos estratégicos de la universidad, el Gateway siguió recibiendo
constantemente la información (Figura 66).
Fig 66. Distancias recorridas con el emisor
• Gateway: Piso 5 bloque 1
• Punto A: Parqueadero.
• Punto B: Cancha de microfútbol
-150
-100
-50
0
550 650 750 850 950 1050
RSS
I (d
Bm
)
Distancia (m)
RSSI VS DISTANCIA
3.5.4.1 Análisis cancha de microfútbol
En la Tabla 9 y Figura 67, se relacionan los datos obtenidos en la prueba realizada
desde el bloque 1 piso 5 con el receptor (Gateway) y en la cancha de microfútbol el
nodo LoRa transmitiendo datos durante 3 minutos.
Tabla 9. Jitter en cancha de microfútbol
Fig 67. Numero de paquetes perdidos en cancha microfútbol
En la Tabla 9 se observa que el Jitter tiene un valor promedio de 8,37 segundos, lo cual es
normal debido a que el tiempo de transmisión desde el nodo LoRa está configurado a 8
segundos, es decir cada 8 segundos el transmisor enviara datos al Gateway, se puede
observar la pérdida de un paquete en la Figura 67 equivalente al 7% de la totalidad de los
paquetes.
1,3133 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
9,6956 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
18,0766 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
26,4554 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
34,8408 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
43,2199 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
51,6005 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
59,9828 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
68,3634 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
76,7501 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
85,1359 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
93,5078 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
110,2768 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
118,6518 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
Jitter (s)
8,37913
8,38666
Time Source Destination Info
8,37505
8,38228
8,37880
8,38234
8,37191
64
3.5.4.2 Análisis parqueadero
En la Tabla 10 y Figura 68, se observan los valores de jitter obtenidos en las pruebas
realizadas con el transmisor ubicado en el parqueadero.
Tabla 10. Jitter en parqueadero
Fig 68. Numero de paquetes perdidos en parqueadero.
En este escenario se observa un mejor comportamiento que en la cancha de microfútbol
ya que no se perdió ninguno de los datos transmitidos, todos fueron recibidos
satisfactoriamente en el Gateway, con un Jitter similar al tiempo de trasmisión configurado
en el nodo LoRa.
3,4829670 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
11,8620200 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
12,0376090 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
20,2440110 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
28,6228330 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
37,0142190 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
45,3847380 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
53,7649910 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
62,1453360 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
70,5426500 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
78,9071330 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
87,2881340 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
95,6693050 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
104,0510580 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
112,4309310 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
120,8108160 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
129,1909420 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
137,5701220 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48)
145,9525770 10.130.1.1 10.130.1.2 Server: Encrypted packet (len=48) 8,3824550
Info
8,2064020
8,3790530
Jitter (s)
8,3913860
8,3802530
8,3798850
8,3810010
8,3817530
8,3973140
8,3791800
Time RX Source Destination
3.5.5 Análisis de parámetros de calidad del servicio de
transferencia de datos sin línea de vista escenario 2.
Las pruebas de este escenario se realizaron en la localidad de Engativá Bogotá Colombia
en un ambiente con mayor cantidad de obstáculos (Figura 69), pues el Gateway se ubicó
en el tercer piso de una casa y se movió por 3 puntos estratégicos para medir sus
parámetros de calidad del servicio (Jitter y pérdida de paquetes), se realizó una transmisión
de 10 minutos en cada uno de los escenarios con el objetivo de obtener más datos y por
consiguiente un nivel de confianza mayor.
Fig 69. Ubicación de transmisor LoRa
3.5.5.1 Análisis piso 1.
En este escenario de prueba se fijó el Gateway en el piso número 3 de la casa y el nodo
LoRa en el piso 1 con la finalidad de obtener resultados del comportamiento de la
comunicación en radiación vertical con múltiples obstáculos, para esta prueba el tiempo de
transmisión del nodo se modificó a 10 segundos, obteniendo los resultados que se
muestran en la Figura 70 y Tabla 11 respectivamente.
66
Fig 70. Numero de paquetes perdidos en piso 1.
Tabla 11. Jitter piso 1.
A una altura de 4,5 metros con obstáculos de concreto, interferencias de red celular, wifi,
radio, entre otros se obtuvo un resultado satisfactorio ya que no hubo pérdida de paquetes
y el jitter se comportó de acuerdo a la trasmisión de paquetes del nodo.
61 61
0
PAQUETES TX PAQUETES RX PAQUETES PERDIDOS
PERDIDA DE PAQUETES
PAQUETES TX PAQUETES RX PAQUETES PERDIDOS
0,2906 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
10,4297 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
20,5276 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
30,6269 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
40,7383 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
50,8591 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
60,9637 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
71,0859 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
81,1854 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
91,3152 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
101,4077 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
111,5189 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
121,6303 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
131,7594 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
141,8809 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=112)
151,9756 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
162,0969 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
172,1887 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
182,2999 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
192,4216 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
202,5277 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
212,6427 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
222,7479 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
232,8579 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
242,9692 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
253,0800 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
263,1910 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
273,3221 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
283,4215 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
293,5523 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
303,6814 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
313,7497 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
323,8779 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
333,9817 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
344,0930 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
354,1991 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
364,3109 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
374,4189 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
384,5330 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
394,6922 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
404,7525 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
414,8803 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
424,9956 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
435,1065 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
445,2000 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=112)
455,3106 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
465,4215 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
475,5434 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
485,6495 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
495,7575 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
505,8865 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
515,9794 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
526,1008 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
536,2023 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
546,3133 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
556,4303 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
566,5449 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
576,6538 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
586,7587 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
596,8884 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
606,9819 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48) 10,09354
10,10884
10,11069
10,12194
10,10799
10,09289
10,10149
10,11705
10,12973
10,12786
10,11089
10,06825
10,10377
10,10613
10,10795
10,15920
10,13078
10,11125
10,12909
10,09477
10,09178
10,12168
10,11506
10,11004
10,11081
10,13110
10,12980
Time Source Destination Info Jitter (s)
10,13910
10,09923
10,12081
10,12214
3.5.5.2 Análisis parque.
Para ejecutar esta prueba el Gateway se dejó fijo en la casa y se procedió a mover el
transmisor al parque como se observa en la Figura 71, obteniendo los siguientes resultados
para perdida de paquetes (Figura 71) y jitter (Tabla 12).
Fig 71. Numero de paquetes perdidos en la prueba del parque.
Tabla 12. Jitter medido en la prueba del parque.
58 58
0
PAQUETES TX PAQUETES RX PAQUETES PERDIDOS
PERDIDA DE PAQUETES
PAQUETES TX PAQUETES RX PAQUETES PERDIDOS
8,6138 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
18,8785 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
29,1425 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
39,4093 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
49,6563 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
59,9409 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
70,1858 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
80,4567 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
90,7161 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
100,9998 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
111,2466 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
121,5365 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
131,7763 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
142,0602 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
152,3085 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
162,5909 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
172,8365 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
183,1123 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
193,3668 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
203,6575 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
213,8972 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
224,1815 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
234,4356 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
244,7082 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=112)
254,9635 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
265,2788 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
275,5000 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
285,7478 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
296,0278 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
306,2873 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
316,5553 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
326,8289 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
337,0959 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
347,3597 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
357,4718 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
367,5666 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
377,6766 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
387,7988 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
397,9277 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
408,0182 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
418,3333 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
428,3979 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
438,5044 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
448,7735 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
459,0373 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
469,3231 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
479,5689 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
489,8603 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
500,1150 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
510,3911 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
520,6397 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
530,9142 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
541,1649 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
551,4270 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=112)
561,7038 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
571,9793 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
582,2689 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
592,5070 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
10,28368
Time Source Destination Info Jitter (s)
10,26477
10,26677
10,28458
10,27086
10,25947
10,28986
10,28397
10,28238
10,27580
10,29075
10,28428
10,27264
10,31532
10,24780
10,06457
10,26905
10,27358
10,26377
10,09480
10,12216
10,09058
10,23802
10,28576
10,29140
10,27603
10,27452
10,26208
10,27543
68
En este escenario no se presenció ninguna pérdida de paquetes y el jitter promedio es
similar al tiempo de transmisión del nodo a una distancia de 100 metros sin línea de vista.
3.5.5.3 Análisis distancia máxima.
En este escenario se recorrió en un vehículo diferentes puntos para verificar hasta que
distancia máxima era capaz de recibir la señal el Gateway, obteniendo como resultado 200
metros sin línea de vista como se observa en la Figura 72 (Distancia máxima), en este
escenario de pruebas se obtuvieron los siguientes resultados que se muestran en la Figura
72 y Tabla 13 respectivamente.
Fig 72. Perdida de paquetes distancia máxima.
Tabla 13.Jitter distancia máxima.
55
40
15
PAQUETES TX PAQUETES RX PAQUETES PERDIDOS
PERDIDA DE PAQUETES
PAQUETES TX PAQUETES RX PAQUETES PERDIDOS
0,0101 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
10,7924 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
21,5940 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
32,3963 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
43,2060 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
54,0029 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
64,8173 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
75,6245 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
86,4046 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
118,8125 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
129,6298 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
140,4208 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
151,2141 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
162,0161 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
172,8569 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
183,6279 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
194,4318 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
205,2417 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
216,0243 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
226,8258 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
237,6370 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
302,4475 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=112)
313,2486 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
324,0462 10.130.1.1 10.130.1.201 Server: Encrypted packet (len=48)
10,79102
10,80191
10,77102
10,80988
10,80157
64,81051
10,79767
32,40793
Time Source Destination Info Jitter (s)
10,78230
10,80232
10,79682
10,80714
En este escenario se evidencio una gran pérdida de paquetes ya que se perdió el 27% de
la información, aproximadamente una cuarta parte de los paquetes transmitidos y por ende
se presenció un Jitter mucho más elevado ya que la información no fue recibida en ningún
instante por el Gateway.
3.5.6 Análisis de parámetros de calidad del servicio en línea de
vista.
En este escenario se fijó el Gateway en bloque 1 piso 5 de la Universidad distrital Francisco
José de caldas y el nodo transmisor se dejó estático en el centro comercial el ensueño
diagonal a la universidad (Figura 73), en el cual existe una amplia línea de vista entre el
nodo y el Gateway, distanciados a 300 metros, para esta prueba el nodo transmisor se
configuro para que transmitiera cada 8 segundos.
Fig 73. Escenario en línea de vista.
Obteniendo los resultados de jitter y perdida de paquetes que se muestran en la Tabla 14
y Figura 74 respectivamente.
70
Tabla 14. Jitter en línea de vista.
Fig 74. Perdida de paquetes en línea de vista.
Como se observó en los anteriores resultados no se presentó ninguna pérdida de paquetes
durante la comunicación y el Jitter se encuentra de acuerdo al tiempo de transmisión del
nodo 8 segundos.
15,8300 192.168.240.2 192.168.240.1
24,2470 192.168.240.2 192.168.240.1
32,6640 192.168.240.2 192.168.240.1
41,0830 192.168.240.2 192.168.240.1
49,5050 192.168.240.2 192.168.240.1
57,9240 192.168.240.2 192.168.240.1
66,3400 192.168.240.2 192.168.240.1
74,7600 192.168.240.2 192.168.240.1
83,1810 192.168.240.2 192.168.240.1
91,5990 192.168.240.2 192.168.240.1
100,0150 192.168.240.2 192.168.240.1
108,4340 192.168.240.2 192.168.240.1
116,8520 192.168.240.2 192.168.240.1
125,2740 192.168.240.2 192.168.240.1
133,6930 192.168.240.2 192.168.240.1
142,1100 192.168.240.2 192.168.240.1
150,5290 192.168.240.2 192.168.240.1
158,9480 192.168.240.2 192.168.240.18,41900
8,41700
8,41900
8,41900
8,42000
8,41800
8,41900
8,42200
8,41700
Time Source Destination Jitter (s)
55 55
0
PAQUETES TX PAQUETES RX PAQUETES PERDIDOS
PERDIDA DE PAQUETES
PAQUETES TX PAQUETES RX PAQUETES PERDIDOS
3.6 Desempeño de la comunicación LoRa
Hay tres parámetros principales que pueden ser modificados en la modulación LoRa:
ancho de banda (BW, bandwidth), factor de dispersión (SF, Spreading factor) y ratio de
codificación (CR, Code rate), estos parámetros determinan el Bitrate, inmunidad a la
interferencia y el tiempo de ocupación del canal en la transmisión.
3.6.1 Factor de Dispersión (SF)
Uno de los parámetros más importantes que afectan el rendimiento a nivel físico, es el
factor de dispersión (SF), es decir, la relación entre el ancho de banda de la señal y la
velocidad de símbolos. Manteniendo el ancho de banda constante, es posible mejorar la
sensibilidad del receptor aumentando el tiempo en aire. Cada incremento del SF,
corresponde a una duplicación del tiempo en aire y una disminución de la sensibilidad de
aproximadamente 3 dB, Tabla 15.
SF Tasa de bits equivalente (kb/s) Chips/Symbol Sensibilidad (dBm)
12 0.293 4096 -137
11 0.537 2048 -134
10 0.976 1024 -132
9 1.757 512 -129
8 3.125 256 -126
7 5.466 128 -123
Tabla 15. Relación entre el factor de dispersión (SF), Chips/Symbol y sensibilidad.
3.6.2 Ancho de banda (BW)
Se emplean configuraciones con los siguientes anchos de banda 125, 250 y 500 KHz. Un
aumento de uno en el factor de dispersión divide la frecuencia del chirp en 2. Dado que
hay 2𝑆𝐹 𝑐ℎ𝑖𝑟𝑝𝑠 en un símbolo, un símbolo puede codificar SF bits de información.
Por lo tanto, el symbol rate y el Bitrate son dados por el SF, los cuales son proporcionales
al BW, a continuación, se describe la ecuación que expresa la duración de un símbolo para
un determinado SF y BW:
𝑇𝑠 =2𝑆𝐹
𝐵𝑊
72
3.6.3 Ratio de codificación (CR)
LoRa incluye un FEC (Forward Error Correction), denominado CR (Code Rate) el cual
puede tomar los siguientes valores: 4/5, 4/6, 4/7 y 4/8. El primer valor indica cuantos bits
son de información (Payload) y el segundo bits enviados. En la Tabla 16 se muestran los
valores de Bitrate nominal obtenidos para diferentes configuraciones de SF y CR para un
ancho de banda de 125 kHz.
Ancho de Banda (BW) Factor de dispersión (SF) Code Rate (CR) Bitrate nominal
125 kHz 12
4/5
4/6
4/7
4/8
293 bps
244 bps
209 bps
183 bps
125 kHz 11
4/5
4/6
4/7
4/8
537 bps
448 bps
384 bps
336 bps
125 kHz 10
4/5
4/6
4/7
4/8
977 bps
814 bps
698 bps
610 bps
125 kHz 9
4/5
4/6
4/7
4/8
1758 bps
1465 bps
1256 bps
1099 bps
125 kHz 8
4/5
4/6
4/7
4/8
3125 bps
2604 bps
2232 bps
1953 bps
125 kHz 7
4/5
4/6
4/7
4/8
5469 bps
4557 bps
3906 bps
3418 bps
Tabla 16. Valores de Bitrate nominal obtenidos para un ancho de banda de 125 kHz con diferentes SF y CR configurados.
En la Tabla 17 se muestran los resultados de Bitrate nominal obtenidos para un ancho de
banda de 250 kHz configurando diferentes valores de SF y CR.
Ancho de Banda (BW) Factor de dispersión (SF) Code Rate (CR) Bitrate nominal
250 kHz 12
4/5
4/6
4/7
4/8
586 bps
488 bps
419 bps
366 bps
250 kHz 11
4/5
4/6
4/7
4/8
1074 bps
895 bps
767 bps
671 bps
250 kHz 10
4/5
4/6
4/7
4/8
1953 bps
1628 bps
1395 bps
1221 bps
250 kHz 9
4/5
4/6
4/7
4/8
3516 bps
2930 bps
2511 bps
2197 bps
250 kHz 8
4/5
4/6
4/7
4/8
6250 bps
5208 bps
4464 bps
3906 bps
250 kHz 7
4/5
4/6
4/7
4/8
10938 bps
9115 bps
7812 bps
6836 bps
Tabla 17. Valores de Bitrate nominal obtenidos para un ancho de banda de 250 kHz con diferentes valores de SF y CR.
74
3.6.4 Estructura del paquete LoRa
La estructura del paquete LoRa es la que se ve en la Figura 75.
Fig 75. Estructura del paquete LoRa.
Preámbulo
El preámbulo es una serie de bits que se envían con la finalidad de sincronizar al receptor
con el transmisor. Este valor puede ser parametrizado con valores desde 6 a 65535,
quedando un preámbulo de 10 a 65539 respectivamente (debido a que hay 4 símbolos de
preámbulo que son fijos). Tanto el emisor como el receptor se configuran con el mismo
preámbulo para sincronizarse. Como excepción, si el receptor utiliza 65535 como
preámbulo puede recibir paquetes con preámbulos menores.
Encabezado
Hay dos tipos de encabezados que pueden ser configurados, según el modo que se utilice:
• Implícito (no hay encabezado): el receptor debe conocer de antemano el tamaño
del Payload y del CR utilizado.
• Explícito: este es el modo que se configura por defecto, en el campo Header del
paquete se envía información sobre el tamaño de la carga, CR y CRC.
En la Figura 76 se puede apreciar el mensaje transmitido por los nodos capturado por un
sniffer en el puerto serial, en este se observa la información transmitida y el tamaño del
Payload del paquete (En este caso corresponde a 37 Bytes de carga útil).
Fig 76. Estructura del paquete transmitido por los nodos LoRa al Gateway.
Es posible obtener información sobre la estructura del paquete LoRa recibido en el
Gateway a través de la herramienta Wireshark, por medio de esta podemos capturar
paquetes que envía el Gateway a la nube, en la Figura 77 se aprecia cómo está
conformado el paquete y el tamaño del mismo (En este caso 40 Bytes de carga útil), en
este se identifica también información referente a la cabecera del paquete.
Fig 77. Información obtenida del paquete recibido en el Gateway por medio de
Wireshark.
El Gateway para enviar el paquete al servidor en la nube (ThingSpeak) adiciona
información adicional de la estructura del mensaje en la cabecera del paquete y lo envía
por medio del protocolo TCP/IP, en este proceso se cifra la información y se transmite
estableciendo una conexión con el servidor en la nube por medio de un canal cifrado entre
el cliente y servidor (Esto gracias al protocolo TLS - Transport Layer Security Figura 78).
Así el intercambio de información se realiza en un entorno seguro y libre de ataques.
Fig 78. Información del paquete luego de ser enviado por el Gateway al servidor en la nube Thingspeak.
3.6.5 Tiempo en el aire
Luego de seleccionados todos los parámetros de configuración en la modulación (SF, BW
y CR) y del paquete, es posible obtener el tiempo en el aire. Es el tiempo que se demora
en enviar el paquete, durante el que se ocupa el canal de radio.
76
El fabricante brinda una herramienta con la que es posible obtener diversos parámetros en
la comunicación, denominada LoRa Modem Calculator Tool [39], la cual se encuentra
disponible de manera gratuita en el sitio web del fabricante. Esta herramienta permite
ingresar los parámetros de la transmisión y en base a estos calcular el tiempo en el aire
de cada paquete, así como el tiempo que se requiere entre envió de mensajes.
En nuestro sistema el mensaje del nodo hacia el gateway es de 40 bytes, y el de respuesta
del gateway hacia el nodo de 10 bytes. Utilizando esta herramienta se obtuvo la
información contenida en la Tabla 18 variando el factor de dispersión (SF) y Code Rate
(CR) para una carga útil de 40 bytes.
Tabla 18. Valores obtenidos para tiempo en el aire con una configuración de ancho de banda de 125kHz, Code Rate variable y factor de dispersión variable.
En la Tabla 19 se muestran los resultados obtenidos para tiempo en el aire variando el
ancho de banda a 250 kHz y modificando el tamaño del preámbulo del mensaje de 8
symbols que están por defecto a 2500 symbols.
Tabla 19. Valores obtenidos para tiempo en el aire con una configuración de ancho de banda de 250kHz, longitud del preámbulo de 2500 symbols, Code Rate variable y factor
de dispersión variable.
Debido a la cantidad y características de la información que se requiere transmitir
(temperatura, humedad, nivel de llenado y otra información), no se requiere una solución
de alta velocidad ni baja latencia (Se resalta en amarillo en la Tabla 18 la configuración
implementada en los dispositivos). Además, la información del estado del contenedor no
78
requiere ser enviada constantemente, sino cada un determinado lapso, entre otros
motivos, porque las variables no evolucionan rápidamente, sino que son procesos físicos
que se dan en el tiempo (por ejemplo, un contenedor no se desplaza ni se llena
instantáneamente).
4. Conclusiones y trabajos futuros
• Se evidenció un mejor comportamiento en la comunicación entre el nodo LoRa y el
gateway en línea de vista, ya que se alcanzó una distancia mayor sin presenciar
perdida de paquetes.
• Para proyectos en los que se necesita una velocidad de transmisión en tiempo real
se recomienda hacer uso de la consola de Linux que trae por defecto el gateway
Dragino, ya que por medio de librerías el tiempo de recepción y publicación de los
datos es mucho más demorado.
• La tecnología LoRa permite enviar información en un rango de 1 a 2 km en
condiciones ideales, sin embargo, se determinó que para condiciones ambientales
reales la distancia máxima es de 1000m, pero con una gran pérdida de información.
Es posible obtener variación en los resultados si se configura un factor de
ensanchamiento diferente, puesto que esta configuración determina que tanto
tiempo dura la comunicación en el aire.
• Se determinó que a mayor distancia entre los nodos y el gateway el factor de
dispersión aumenta, lo que conlleva a una disminución en la velocidad de
transmisión, así como también la sensibilidad en el receptor.
• Hacer uso de la herramienta IFTTT, optimiza el proceso de monitoreo de
contenedores, ya que al encontrarse sincronizado con la nube informa al usuario
en tiempo real cualquier tipo de alarma.
• Se observó que todo el tráfico entre dispositivos finales (nodos) y el servidor de red
se cifra y se encapsula mediante dos llaves derivadas del Appkey que hacen uso
del algoritmo de cifrado AES128, por este motivo no es posible observar el
contenido en el Payload del mensaje al capturarlos y analizarlos en el sniffer
Wireshark.
• El gateway es solo de un canal y solo puede escuchar a un nodo a la vez, se debe
configurar cada uno de los nodos para que transmita la información en tiempos
diferentes y de esta forma evitar conflictos entre ellos.
• Con base en los resultados obtenidos en las múltiples pruebas realizadas, se
denota una clara degradación en las prestaciones de la comunicación con el
aumento de la distancia, esta tendencia se ve reflejada en los niveles de potencia
(RSSI), ya que este indica la potencia con la que llega la señal al receptor, se
determinó el límite de una comunicación fiable y estable cerca de los -90 dBm.
• La información obtenida de Jitter en los escenarios que no presentaron perdida de
información se puede evidenciar que este tiempo es muy similar al tiempo de
transmisión de los nodos, por lo cual se puede concluir que la eficiencia en la
transmisión y recepción de paquetes es estable y se realiza en tiempo real.
• A la hora de realizar la instalación de los nodos y configurar una red de
comunicaciones inalámbrica, se deben tener en cuenta varios aspectos; entre ellos
está la cobertura que puede ofrecer dicha red, ya que en este caso solo se están
monitoreando dos contenedores no es muy relevante, sin embargo si se desea
expandir el proyecto es necesario determinar el número de nodos adicionales y
Gateways necesarios para garantizar una cobertura adecuada, así mismo hay que
tener en cuenta el consumo energético de los diversos dispositivos que forman
parte de la red, ya que en aplicaciones enfocadas al sector IoT es esencial que los
dispositivos operen a bajos niveles de potencia, garantizando una vida útil
extendida.
Bibliografía
[1] M. F. Barcell, “Medios de transmision,” Univ. Cadiz, pp. 1–39, 2019.
[2] ESPECTROMETRIA.COM, “Espectro electromagnético,” 2015. [Online]. Available:
http://www.espectrometria.com/espectro_electromagntico.
[3] I. Bernal and D. Ph, “Comunicaciones Inalámbricas Introducción Comunicaciones
Inal,” pp. 1–53, 2005.
[4] LoRaWAN, “LoRaWAN Long Wide Area Network,” 2012. [Online]. Available:
https://blogs.deusto.es/aplicaciones-tic/lorawan-long-range-wide-area-network/.
[Accessed: 05-Apr-2019].
[5] alfaiot, “El protocolo LoRaWAN,” 2016. [Online]. Available:
https://www.alfaiot.com/blog/ultimas-noticias-1/post/el-protocolo-lorawan-6.
[Accessed: 05-Apr-2019].
[6] U. Distrital, F. Jose, and P. Lora, “´ DE UN IMPLEMENTACI ON GATEWAY LOW-
80
COST PARA EL IMPLEMENTACI ON GATEWAY LOW-COST PARA EL
PROTOCOLO LoRa.”
[7] Medium, “Haciendo IoT con LoRa,” 2017. [Online]. Available:
https://medium.com/beelan/haciendo-iot-con-lora-capitulo-2-tipos-y-clases-de-
nodos-3856aba0e5be. [Accessed: 06-Apr-2019].
[8] THE THINGS NETWORK, “Extend The Things Network by installing a Gateway,”
2019. [Online]. Available: https://www.thethingsnetwork.org/docs/gateways/.
[Accessed: 06-Apr-2019].
[9] E. Solera, “Modulacion LoRa:Long Range Modulation,” 2018. [Online]. Available:
https://medium.com/pruebas-de-laboratorio-de-la-modulación-lora/modulación-lora-
4ad74cabd59e. [Accessed: 06-Apr-2019].
[10] “Arduino - Introduction.” .
[11] U. Manual, “Arduino Nano V2.3 User Manual,” Arduino, pp. 1–5, 2008.
[12] Aosong Electronics, “Dht22,” pp. 1–7.
[13] www.Elecfreaks.com, “Ultrasonic Ranging Module HC - SR04,” Datasheet, pp. 1–4,
2013.
[14] Hope Microelectronics Co., “RFM95/96/97/98 Datasheet,” vol. 98, p. 121, 2014.
[15] “LG01-S IoT Gateway con tecnología LoRa®.” .
[16] “IoT Analytics - ThingSpeak Internet of Things.” .
[17] “Todo funciona mejor juntos - IFTTT.” .
[18] Á. Casanova, “Así se estructura una plataforma de Internet de las Cosas en la nube,”
2019. [Online]. Available: https://ausum.cloud/es/blog/iot/2019/asi-se-estructura-
una-plataforma-de-internet-de-las-cosas-en-la-nube. [Accessed: 21-Sep-2019].
[19] VB-MUNDO, “Comparación de diferentes AVR de Arduino,” 2019. [Online].
Available: http://www.vb-mundo.com/comparacion-de-diferentes-avr-de-arduino/.
[Accessed: 26-Sep-2019].
[20] E. Diaz Marín, “APLICACIÓN DE COMUNICACIONES INALÁMBRICAS LPWAN
PARA DETECCIÓN DE INCENDIOS FORESTALES BASADOS EN SISTEMAS
IoT,” p. 87, 2017.
[12] B. L. E. Lorawan and C. Garrido-hidalgo, “despliegue.”
[13] U. Distrital, F. Jose, and P. Lora, “´ DE UN IMPLEMENTACI ON GATEWAY LOW-
COST PARA EL IMPLEMENTACI ON GATEWAY LOW-COST PARA EL
PROTOCOLO LoRa.”
[14] M. F. Barcell, “Medios de transmision,” Univ. Cadiz, pp. 1–39, 2019.
[15] ESPECTROMETRIA.COM, “Espectro electromagnético,” 2015. [Online]. Available:
http://www.espectrometria.com/espectro_electromagntico.
[16] I. Bernal and D. Ph, “Comunicaciones Inalámbricas Introducción Comunicaciones
Inal,” pp. 1–53, 2005.
[17] LoRaWAN, “LoRaWAN Long Wide Area Network,” 2012. [Online]. Available:
https://blogs.deusto.es/aplicaciones-tic/lorawan-long-range-wide-area-network/.
[Accessed: 05-Apr-2019].
[18] alfaiot, “El protocolo LoRaWAN,” 2016. [Online]. Available:
https://www.alfaiot.com/blog/ultimas-noticias-1/post/el-protocolo-lorawan-6.
[Accessed: 05-Apr-2019].
[19] Medium, “Haciendo IoT con LoRa,” 2017. [Online]. Available:
https://medium.com/beelan/haciendo-iot-con-lora-capitulo-2-tipos-y-clases-de-
nodos-3856aba0e5be. [Accessed: 06-Apr-2019].
[20] Jaguar Netwoek, “COLLECTE IoT,” 2018. [Online]. Available: https://www.jaguar-
network.com/produit/stellar. [Accessed: 06-Apr-2019].
[21] THE THINGS NETWORK, “Extend The Things Network by installing a Gateway,”
2019. [Online]. Available: https://www.thethingsnetwork.org/docs/gateways/.
[Accessed: 06-Apr-2019].
[22] SEMTECH, “LoRa TM Modulation Basics,” no. May, pp. 1–26, 2015.
[23] E. Solera, “Modulacion LoRa:Long Range Modulation,” 2018. [Online]. Available:
https://medium.com/pruebas-de-laboratorio-de-la-modulación-lora/modulación-lora-
4ad74cabd59e. [Accessed: 06-Apr-2019].
[24] “Normograma del Ministerio de Tecnologías de la Información y las Comunicaciones
[RESOLUCION_ANE_0711_2016].” .
[25] “Introducción a Wi-Fi (802.11 o WiFi),” 2015. [Online]. Available:
http://es.ccm.net/contents/789-introduccion-a-wi-fi-802-11-o-wifi.
[26] Instituto Colombiano de Normas Técnicas y Certificacion. (ICONTEC), “Ntc-
Iso10012,” p. 22, 2003.
[27] “Arduino - Introduction.” .
[28] U. Manual, “Arduino Nano V2.3 User Manual,” Arduino, pp. 1–5, 2008.
[29] Aosong Electronics, “Dht22,” pp. 1–7.
[30] www.Elecfreaks.com, “Ultrasonic Ranging Module HC - SR04,” Datasheet, pp. 1–4,
2013.
[31] Hope Microelectronics Co., “RFM95/96/97/98 Datasheet,” vol. 98, p. 121, 2014.
82
[32] “LG01-S IoT Gateway con tecnología LoRa®.” .
[33] “IoT Analytics - ThingSpeak Internet of Things.” .
[34] “Todo funciona mejor juntos - IFTTT.” .
[35] Á. Casanova, “Así se estructura una plataforma de Internet de las Cosas en la nube,”
2019. [Online]. Available: https://ausum.cloud/es/blog/iot/2019/asi-se-estructura-
una-plataforma-de-internet-de-las-cosas-en-la-nube. [Accessed: 21-Sep-2019].
[36] VB-MUNDO, “Comparación de diferentes AVR de Arduino,” 2019. [Online].
Available: http://www.vb-mundo.com/comparacion-de-diferentes-avr-de-arduino/.
[Accessed: 26-Sep-2019].
[37] E. Diaz Marín, “APLICACIÓN DE COMUNICACIONES INALÁMBRICAS LPWAN
PARA DETECCIÓN DE INCENDIOS FORESTALES BASADOS EN SISTEMAS
IoT,” p. 87, 2017.
[38] E. Diaz Marín, “APLICACIÓN DE COMUNICACIONES INALÁMBRICAS LPWAN
PARA DETECCIÓN DE INCENDIOS FORESTALES BASADOS EN SISTEMAS
IoT,” p. 87, 2017.
[39] Semtech LoRa, “LoRaTools,” 2019. [Online]. Available:
https://www.loratools.nl/#/airtime. [Accessed: 08-Nov-2019].
