Prototipo de red LoRaWAN para solución IoT

# Prototipo de red LoRaWAN para solución IoT * **Estudiante**: Bibiana Mollinedo Rivadeneira * **Tutores**: * **Por empresa**: Jonathan Hernán Sánchez * **Por Universidad**: Damián Héctor Primo * **Lugar de realización**: Fonexa S.A. * **Período de realización**: 29/08/2019 - 06/12/2019 * **Fecha de presentación**: 06/12/2019 ## Resumen Se desarrolla un prototipo de solución [IoT](#IoT-gIoT) *(Internet of Things)* con tecnología de base **[LoRaWAN](#LoRaWAN-dLoRaWAN)**, conformado por un **módulo de adquisición de datos, uno de comunicación/transmisión inalámbrica de los mismos, así como un módulo de procesamiento y visualización** para el usuario final. Previo proceso de investigación a nivel de hardware así como de software, respecto a los requerimientos, opciones disponibles en el mercado local, haciendo hincapié en los protocolos de comunicación implicados, recopilando información necesaria para la toma de desiciones de usos e implementación de tecnologías. Se realiza la puesta en marcha y prueba de concepto, se establecen conclusiones y proyecciones según soluciones comerciales potenciales, relacionadas a *sensado de nivel de llenado en contenedores de residuo para optimización de rutas de recolección* y *monitoreo de sistemas de riego rurales*. ### Palabras clave LoRa, LoRaWAN, IoT, ESP32, arduino, thethingnetworks, mqtt, python, flask, dash. ## Sobre este documento **“Desarrollo de Prototipo de solución IoT basado en tecnología LoRaWAN”** se produce en el contexto de una práctica profesional supervisada para culminar la carrera de Ing. en Telecomunicaciones, en la Universidad Nacional de Río Cuarto por Bibiana Rivadeneira, bajo la tutoría de Jonathan Sanchez y convenio entre UNRC y Fonexa S.A. Este documento es de libre acceso, permite modificación y redistribución, apostando al cumplimiento de la [Ley 26899: Repositorios digitales institucionales de acceso abierto.](https://www.argentina.gob.ar/normativa/nacional/ley-26899-223459) <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Licencia Creative Commons" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br />Esta obra está bajo una <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional</a>. Este es un resumen legible por humanos (y no un sustituto) de la licencia. Advertencia. Usted es libre de: * **Compartir** — copiar y redistribuir el material en cualquier medio o formato * **Adaptar** — remezclar, transformar y construir a partir del material para cualquier propósito, incluso comercialmente. * La licenciante no puede revocar estas libertades en tanto usted siga los términos de la licencia Bajo los siguientes términos: * **Atribución** — Usted debe dar crédito de manera adecuada, brindar un enlace a la licencia, e indicar si se han realizado cambios. Puede hacerlo en cualquier forma razonable, pero no de forma tal que sugiera que usted o su uso tienen el apoyo de la licenciante. * No hay restricciones adicionales — No puede aplicar términos legales ni medidas tecnológicas que restrinjan legalmente a otras a hacer cualquier uso permitido por la licencia. *** ## Índice de contenidos [TOC] ## Introducción Los elementos de la cotidianidad se transformaron al cabo de muy poco tiempo y de manera exponencial, en dispositivos a conectar a la red, enviando y recibiendo dimensiones gigantezcas de datos. Sin embargo existen aún áreas sin acceso a internet, pero con no menos importantes, ni en menor cantidad, datos a aportar. Las redes LoRaWAN, en su arquitectura híbrida de comunicación, ofrece alcances significativos, bajos requerimientos de potencia, versatilidad en la implementación con bajos costos. Ante la tarea de diseñar una red de este tipo, y más específicamente prepararse para la toma de decisiones desde una perspectiva técnica, ingenieril y lo más agnóstica posible ante diferentes escenarios y por ende variables a contemplar, se opta por experiencias empíricas de recopilación de datos, análisis y conclusiones en base a una prueba de concepto y prototipo funcional con vista a escalar a un producto comercial. ## Motivación El proyecto conformado por el conjunto de tareas y procesos de **investigación y desarrollo** de las tecnologías en auge de Internet de las cosas y la construcción de un prototipo surge en la empresa FONEXA, impulsado por Jonathan, del área de desarrollo de software. ## Objetivos ### Generales Cumplimentar requerimiento de práctica profesional para culminar carrera de grado transfiriendo conocimientos y destrezas adquiridas en la currícula a una aplicación del mundo real relacionada con *Internet de las cosas*, a través de procesos de investigación y desarrollo para llevar a cabo una *prueba de concepto* y prototipo de solución. ### Específicos - [x] Investigar los fundamentos, especificaciones técnicas, económicas y sociales de las tecnologías en cuestión. - [x] Investigar opciones disponibles en el mercado local, así como factibles. - [x] Tomar decisiones sobre la elección de las tecnologías, modos de configuración, dispositivos en función a lo anterior. - [x] Simular y/o adquirir los recursos necesarios para el desarrollo del prototipo. - [x] Implementación y puesta en marcha del prototipo. - [x] Análisis de los resultados. - [x] Confección de conclusiones. ## Descripción de la Empresa: FONEXA S.A. ### Resumen Empresa joven fundada por ingenieros en telecomunicaciones con espíritu emprendedor. Experiencia en la industria tras haber formado parte de las principales compañías de telecomunicaciones del País, enfocada principalmente en comprender las necesidades de los clientes y de esta forma ofrecerles la solución, servicio o producto que mejor se adapte a cada situación. ![](https://i.imgur.com/Jqg38oJ.png) ### Datos institucionales * **Domicilio**: Estados Unidos N° 770, Banda Norte, Río Cuarto, Córdoba. <iframe width="425" height="350" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="https://www.openstreetmap.org/export/embed.html?bbox=-64.33069109916688%2C-33.11485042197422%2C-64.32658195495607%2C-33.112235390739556&layer=mapnik" style="border: 1px solid black"></iframe><br/><small><a href="https://www.openstreetmap.org/#map=18/-33.11354/-64.32864">Ver mapa más grande</a></small> * **Teléfono**: (0358)4621093 * **Rubro**: Telecomunicaciones ### Contexto * **Área de desarrollo de práctica profesional supervisada**: I+D, bajo tutoría de encargado de desarrollo de software de la empresa. * **Días y horas de trabajo**: | Día | Desde | Hasta | Cant de hs | | --- | ----- | ----- | ---------- | | LUN |8.30hs |13.00hs| 4,5 | | MAR |8.30hs |13.00hs| 4,5 | | JUE |8.30hs |13.00hs| 4,5 | | VIE |14.00hs|17.30hs| 3,5 | > NOTA: Durante la realización de la práctica profesional se flexibilizaron días, horarios y modalidades de trabajo en función de las tareas, al rededor de los pactados inicialmente. *Ver anexo: Planilal de horas y Diagrama de Gantt* • **Descripción de actividades**: Se implementan soluciones de telecomunicaciones de todo tipo, tanto de infraestructura de redes de diferentes tecnologías, como desarrollo de software. En particular, la práctica profesional se realiza como continuación de la iniciativa de impulsar nuevos proyectos y soluciones de Internet de las cosas. • **Organigrama**: ![](https://i.imgur.com/sT3Wy9I.png) ### Descripción de las tareas Se llevan a cabo tareas de investigación y desarrollo de un prototipo de solución de Internet de las cosas con tecnología LoRaWAN acorde a plan de trabajo, con dedicación diaria de cuatro horas reloj, y según el siguiente diagrama de procesos y tareas: ![](https://i.imgur.com/1BCOhF7.png) ### Descripción del proyecto El proyecto puede ser descripto desde un enfoque general/global. Para su planificación y abordaje, se definen *"módulos"* según las funcionalidades requeridas como sigue: [![](https://i.imgur.com/1FVP0T7.png)](https://commons.wikimedia.org/wiki/File:Tecnologias-LoRaWAN.png) *Diagrama global del proyecto con tecnologías tentativas* de brivadeneira, jonathan sanchez / [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en) * **Módulo de adquisición de datos**: Hardware y software necesario para sensar magnitudes físicas de interés, modificar variables de entorno, se conecta con el módulo adyacente, el de transmisión según tecnología [LoRaWAN](#LoRaWAN-dLoRaWAN). *Inicialmente se simula la adquisición con software.* * **Módulo de comunicación/transmisión**: Hardware necesario para comunicar o transmitir los datos provenientes del módulo de adquisición a través de la red de forma inalámbrica, hasta el servidor. * **Módulo de red**: *(Servidor de red)*. Encargado de administrar la red [LoRaWAN](#LoRaWAN-dLoRaWAN), gestionar y administrar los dispositivos activos, y servir los datos al módulo de procesamiento y visualización. * **Módulo de procesamiento y visualización de datos**: Código de procesamiento de los datos adquiridos, servicio web de visualización dinámica para el usuario final. ## Metodología Para cada uno de los módulos descriptos anteriormente, se lleva a cabo el proceso de **investigación** de los fundamentos, especificaciones técnicas, haciendo hincapié en los protocolos de comunicación, así como características económicas y sociales de las tecnologías en cuestión. Se realiza la **toma de decisiones** sobre la elección de las tecnologías, modos de configuración, dispositivos en función a lo anterior, en primera instancia para el proceso de prototipado y para llevar a cabo la prueba de concepto, para luego proyectar las opciones adecuadas a soluciones comerciales. Se simulan o adquieren los recursos necesarios para el desarrollo y la **puesta en marcha** del prototipo. Se obtienen y analizan los resultados para establecer así conclusiones sobre el prototipo y su proyección como potencial producto o solución tecnológica. ## Fundamentos teóricos A continuación se exponen a modo de síntesis, los datos más relevantes que surgen del proceso de investigación, como base para la toma de decisiones. ### Sobre LoRa/LoRaWAN #### LoRa {#dLoRa} *(**Lo**ng **Ra**nge)* es una técnica de *modulación* basada en *chirp spread spectrum* ([SSC](#SSC-gSSC)), *espectro ensanchado con [chirp](#Chirp-gChirp)*. #### LoRaWAN {#dLoRaWAN} *(Low Power Wide Area Network - Redes de baja potencia y área amplia)* es un protocolo de comunicación y arquitectura de sistema, orientado a **[IoT](#IoT-gIoT)** *(Internet of Things - Internet de las cosas)* que implementa **[LoRa](#LoRa-dLoRa)**. Dichas especificaciones adquirieron gran *"popularidad"* en el campo de **[IoT](#IoT-gIoT)**, algunos de los factores de lo anterior son: * **Largo alcance**, un [gateway](#Gateway-dGateway) puede dar cobertura a dispositivos de toda una ciudad, esto es, alcance a distancias en kilómetros. > El 13 de Julio de 2019, se logró un nuevo récord mundial de alcance con [LoRaWAN](#LoRaWAN-dLoRaWAN, con **766 km** de distancia y `25mW` de potencia de transmisión. > [Más información.](https://www.thethingsnetwork.org/article/lorawan-distance-world-record) * **Bajo consumo**, el protocolo de acceso al medio es tal, que los nodos no se sincronizan con los gateways, se energizan e inician la transmisión sólo cuando tienen datos a enviar, esto reporta tiempo de vida de baterías muy superiores a otras tecnologías. > Por ejemplo, para un sensor tomando datos del suelo en un sistema de control de irrigación, se considera que la humedad del suelo no va a cambiar demasiado rápido, se toma una medición por hora, lo que permite cambiar la batería **cada dos años**, comparado con sensar datos cada *cinco minutos*, lo que requeriría cambio de batería *cada dos meses*. [Ver más](https://www.alliot.uk/achieving-long-battery-life-with-lora-sensors/) * **Alta capacidad de la red**, la técnica de modulación empleada permite la comunicación entre un [gateway](#Gateway-dGateway) y múltiples nodos a diferentes distancias y tasas de transferencia. * **Adaptabilidad**, la red soporta diferentes clases de nodos según los requerimientos, permitiendo adaptar la red a diferentes aplicaciones. * **Bajo costo**, una red funcional puede ser implementada con dispositivos de bajo costo. * **Seguridad**, implementa algoritmos robustos de encriptación. Implementando encriptación a nivel de red como así tambien a nivel de aplicación. * **Gran comunidad activa alrededor del mundo**. * **Compatible con componentes open source**. ##### Arquitectura La arquitectura general de una red [LoRaWAN](#LoRaWAN-dLoRaWAN) es como sigue: [![](https://upload.wikimedia.org/wikipedia/commons/c/cc/ArquitecturaLoRa.png)](https://commons.wikimedia.org/wiki/File:ArquitecturaLoRa.png) *Arquitectura general de una red [LoRaWAN](#LoRaWAN-dLoRaWAN)* de brivadeneira / [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en) * **End-points**: Se comunican con uno o más gateways según el protocolo LoRa. * **Sensor**: *(→)* Registra medición de una magnitud física y la transmite a los gateways. *Ej: sensor de temperatura, de presión, de nivel.* * **Actuador**: *(↔)* Según dato recibido desde la red *modifica* uno o más parámetros del entorno. *Ej: LED, relé.* * **Gateways**: *(↔)* Se comunican con end-points según protocolo LoRa, así como con *-uno o más-* servidores de red por *Ethernet, WiFi o 3G/4G*. * **Servidor de red**: *(↔)* Se comunica con gateways y servidor de aplicación a través de red de datos. * **Servidor de aplicación**: *(↔)* Se comunica con dispositivos del usuario, así como servidor de red. Provee servicios al usuario, autentica dispositivos, etc. ##### Especificaciones técnicas A continuación se exponen las especificaciones técnicas de interés de [LoRaWAN](#LoRaWAN-dLoRaWAN). ##### Cifrado [LoRaWAN](#LoRaWAN-dLoRaWAN) implementa **[AES](#AES-gAES)-CTR** en el payload del tráfico de la red, así como **[AES](#AES-gAES)-CMAC** en el campo de *MIC, Código de Integridad del Mensaje* ##### Frecuencia de trabajo En Argentina, la banda de frecuencias de trabajo para una red LoRaWAN es **`902 - 928 MHz`**, (915-928 MHz usable). *Ver pag. 8, "Table 1: Channel Plan per Country" en Anexo 1: LoRaWAN Regional Parameters (v1.1)*. ##### Normativa Argentina El rango de frecuencias de trabajo corresponde a la lista de [Bandas no licenciadas](https://www.enacom.gob.ar/bandas-no-licenciadas_p680): > Conviene destacar que el Reglamento de Radiocomunicaciones de UIT ha destinado a nivel mundial (y en algún caso, regional) bandas para uso primario para las aplicaciones Industriales, Científicas y Médicas (ICM). La Nota de Pie 5.150 dice: > "Las bandas *(...)* **`902-928MHz` en la Región 2 (frecuencia central 915MHz)**, *(...)*, están designadas para aplicaciones industriales, científicas y médicas (ICM). Los servicios de radiocomunicación que funcionan en estas bandas deben aceptar la interferencia perjudicial resultante de estas aplicaciones." Según la [Cuadro de atribución de bandas de frecuencias de la República Argentina](https://www.enacom.gob.ar/multimedia/noticias/archivos/201904/archivo_20190416044315_5617.pdf), la banda comprendida entre los **`915 MHz y 928 MHz`** *(ver pag 188, nótese que no comienza en `902 MHz`)*, corresponde a * **"Servicio TIC para banda de frecuencia de uso compartido"**. * Tipo de servicio FIJO/MOVIL de *Uso Privado – Prestador*. * Bajo **[resolución 581MM18](https://www.enacom.gob.ar/multimedia/normativas/2018/res581MM.pdf)**, la que establece los siguientes niveles de trabajo: * Potencia Máxima del Transmisor (Conducida) `30dBm`. * Potencia Máxima del Transmisor (P.I.R.E.) `36dBm`. ##### Ocupación espectral La distribución espectral es según la norma **AU915-928 US902-928**, como sigue: [![](https://upload.wikimedia.org/wikipedia/commons/thumb/2/27/EspectroAU915-928LoRa.png/800px-EspectroAU915-928LoRa.png)](https://commons.wikimedia.org/wiki/File:EspectroAU915-928LoRa.png) *"AU915-928 LoRa v1.1"* de brivadeneira / [CC-BY-SA 4.0](http://creativecommons.org/licenses/by-sa/4.0/) * **Upstream** * 64 canales numerados de 0 a 63 de **`125kHz`** de ancho de banda, y **`200kHz`** entre ellos. El primero en **`915.2MHz`** y el último en **`927.1MHz`**. *(Verde)*. * 8 canales numerados de 64 a 71 de **`500kHz`** de ancho de banda, y **`1.6MHz`** entre ellos. El primero en **`915.9MHz`** y el último en **`927.1MHz`**. *(Azul)*. * **Downstream** * 8 canales numerados de 0 a 7 de **`500kHz`** de ancho de banda, y **`600kHz`** entre ellos. El primero en **`923.3MHz`** y el último en **`927.5MHz`**. *(Amarillo)*. > NOTA: En Argentina existe un consenso de usar los canales 8 a 15 de la especificación AU915 p **AU915 sub-band 2**, Para implementación de la red de código abierto TTN. ##### Formato de las tramas Las tramas *(frames)* del protocolo LoRa posee una estructura formada por las capas **física**, **MAC** y superiores *(aplicación)*: [![](https://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/LoRaFrameFormat.png/800px-LoRaFrameFormat.png)](https://commons.wikimedia.org/wiki/File:LoRaFrameFormat.png) *"LoRa Frame Format"* de brivadeneira / [CC-BY-SA 4.0](http://creativecommons.org/licenses/by-sa/4.0/) * **Capa física** *-azul-* (*Physical Layer Frame*): La trama LoRa comienza con un * **Preámbulo**: Además de cumplir la función de *sincronismo*, define el *esquema de modulación de paquetes*. Duración típica del preámbulo: `12.25 Ts.` * **Encabezado + CRC** *(Header)*: Contiene información sobre el *tamaño* del [payload](#Payload-gPayload), si el *[CRC](#CRC-gCRC)* del [payload](#Payload-gPayload) de `16-bit` está o no presente en la trama. *Sólo los frames del enlace de subida contienen el campo [CRC](#CRC-gCRC)*. Tamaño de `20 bits`. * **Payload**: *-anaranjado-* *(PHY Payload)* - `0-96 bits` * **Capa MAC**. * **MAC Header**: Define la versión del protocolo así como el tipo de mensaje. * **MAC Payload**: *-verde-* Contiene *join-request* o *join-access*, empleados en el proceso de activación de un end-point. El MAC Payload es gestionado por la *capa de aplicación*, está conformado por: * **Frame Header**: *-violeta-* * **Dirección de dispositivo**: los primeros`8 bits` identifican la red, los demás se asignan deforma dinámica durante el inicio de sesión e identifican al dispositivo en la red. * **Frame Control**: `1 byte`, contiene información de control de la red como ser implementar o no velocidad de *subida* especificada por el [gateway](#Gateway-dGateway), [ACK](#ACK-gACK) del mensaje anterior, si el [gateway](#Gateway-dGateway) tiene más datos para transmitir. * **Frame counter** para el número de secuencia. * **Frame options**: datos para cambiar configuración como velocidad de transmisión, potencia de transmisión y validación de conexión. * **Frame Port**: Valor determinado según el tipo de aplicación. * **Frame Payload**: Datos a enviar a la red. Se cifra con la AppSKey mediante el algoritmo [AES](#AES-gAES) 128. * **MIC** *(Message Integrity Code)*: Resultado de computar el header y payload MAC con una NwkSKey. *Ver Anexo: "Formatos de payload"* ##### Endpoints {#Endpoints} El módulo de adquisición de datos tiene como funcionalidad el sensado de magnitudes físicas de interés, *(según aplicación, temperatura, presión, humedad, nivel, etc)*. Se conecta directamente con el de transmisión según tecnología [LoRaWAN](#LoRaWAN-dLoRaWAN). En el diagrama general de la arquitectura de la red [LoRa](#LoRa-dLoRa) se denominan *[end-point](#Endpoints-Endpoints)s*. ##### Factor de ensanchado vs tasa de bits El factor de ensanchado de las señales enviadas en una red [LoRa](#LoRa-dLoRa), defindo como: $SF = \frac{chip\_rate}{symbol\_rate}$, el cociente entre la cantidad de pulsos por segundo y la cantidad de símbolos por segundo, varía entre 7 y 12 según normativa regional e impacta directamente en la tasa de bits como sigue: $bit rate = SF·\frac{Bw}{2^{SF}}$ A continuación se muestran las tasas de bits, según configuración física correspondiente a normativa `AU915-928` | DataRate | Configuration | Bit rate [bit/sec] | |----------|----------------------|--------------------| | 0 | LoRa: SF12 / 125 kHz | 250 | | 1 | LoRa: SF11 / 125 kHz | 440 | | 2 | LoRa: SF10 / 125 kHz | 980 | | 3 | LoRa: SF9 / 125 kHz | 1760 | | 4 | LoRa: SF8 / 125 kHz | 3125 | | 5 | LoRa: SF7 / 125 kHz | 5470 | | 6 | LoRa: SF8 / 500 kHz | 12500 | | 7 | RFU | | | 8 | LoRa: SF12 / 500 kHz | 980 | | 9 | LoRa: SF11 / 500 kHz | 1760 | | 10 | LoRa: SF10 / 500 kHz | 3900 | | 11 | LoRa: SF9 / 500 kHz | 7000 | | 12 | LoRa: SF8 / 500 kHz | 12500 | | 13 | LoRa: SF7 / 500 kHz | 21900 | | 14 | RFU | | | 15 | Defined in LoRaWAN | | *Ver tabla 35, pag. 38 de Anexo 1: LoRaWAN Regional Parameters (v1.1)* ##### Clases de end-points (A, B y C) Según los requerimientos para el diseño del sistema y en función del "intercambio" *(trade off)* entre optimizar la **energía necesaria** (y por ende la vida útil de la batería) vs optimizar la **latencia** en el enlace de descarga, existen tres tipos bien definidos de [end-point](#Endpoints-Endpoints)s, caracterizados por los tiempos de transmisión y recepción con el [gateway](#Gateway-dGateway), la energía necesaria para ello versus la latencia en la transmisión. Todos los tipos de [end-point](#Endpoints-Endpoints)s permiten comunicaciones bi-direccionales, implementan el método de acceso [**ALOHA**](#ALOHA-gAloha) con *tiempo de uplink* random. ![](https://i.imgur.com/thibGDY.png) *Pag. 10 ["What is LoRaWAN?"](https://lora-alliance.org/sites/default/files/2018-04/what-is-lorawan.pdf)* de [LoRa Alliance](lora-alliance.org) ###### Clase A Los [end-point](#Endpoints-Endpoints)s de clase A abren una ventana de *dowlink* *("escuchan")* por cada ventana de uplink, la que se habilita al cabo de un tiempo azaroso. No permiten comunicación [Full-Duplex](#FullDuplex-gFullDuplex), sino [Half-Duplex](#HalfDuplex-gHalfDuplex), mientras el [end-point](#Endpoints-Endpoints) transmita información al [gateway](#Gateway-dGateway), éste no puede "responder". El **requerimiento de energía es mínimo** *(y por ende la vida útil de batería máxima)*, pero es el tipo de [end-point](#Endpoints-Endpoints) que **más latencia** presenta en la transmisión. ###### Clase B A diferencia de los [end-point](#Endpoints-Endpoints) clase A, por cada ventana de uplink se abren dos pequeñas ventanas de downlink, el requerimiento de energía es mayor al de los [end-point](#Endpoints-Endpoints)s de clase A, pero presenta menor latencia. ###### Clase C A diferencia de las clases A y B, la ventana de tiempo para el enlace de downlink está disponible siempre, es decir, permiten comunicación [Full-Duplex](#FullDuplex-gFullDuplex). El requerimiento de energía es el máximo, mientras que los tiempos de latencia mínimos. Lo anterior es relevante para aplicaciones críticas, donde se requieren tiempos de respuesta mínimos, como ser alarmas, sistemas de reacción ante emergencias, etc. ###### Diagrama comparativo [![](https://i.imgur.com/mSgqMMP.png)](https://commons.wikimedia.org/wiki/File:LoRa_End_Device_Classifications.png) *"LoRa End Device Classifications"* de brivadeneira / [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en) ###### Ejemplos de uso según clase de end-point | Clase | Uso | Energía | Latencia | | ----- | --- | ------- | -------- | | A | Monitoreo de sistema de riego para estadísticas de consumo, caudal, etc. | Mínima | Máxima | | A | Monitoreo de nivel de llenado de contenedores de residuos para optimizar rutas de recolección. | Mínima | Máxima | | B | Monitoreo de contenido de gas en sistemas zeppelin para optimizar recorrido de proveedor. | Media | Media | | C | Monitoreo crítico y sistema de alarmas ante fallas. | Máxima | Mínima | ##### Modos de activación Cuando un [end-point](#Endpoints-Endpoints) desea conectarse a la red [LoRaWAN](#LoRaWAN-dLoRaWAN), envía al [gateway](#Gateway-dGateway) un *"join-request"* o solicitud de inicio de sesión en la red mediante un mensaje con datos de configuración y abre una ventana de recepción. El [gateway](#Gateway-dGateway) reenvía el mensaje al servidor, éste devuelve un mensaje para confirmar el inicio de sesión del [end-point](#Endpoints-Endpoints) si los datos fueran correctos, así como las claves, o un mensaje de rechazo de lo contrario. [![](https://upload.wikimedia.org/wikipedia/commons/9/9b/LoRa_end-devices_activation.png)](https://commons.wikimedia.org/wiki/File:LoRa_end-devices_activation.png) *"LoRa end-devices activation"* de brivadeneira / [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en) *Ver Anexo: "Modos de activación"* ###### Cuadro comparativo | OTAA | ABP | | ------------ | ----------- | | El [end-point](#Endpoints-Endpoints) puede cambiar de red e iniciar una nueva sesión sin necesidad de re-programar parámetros. | Si el [end-point](#Endpoints-Endpoints) cambia de red, se deben re-configurar los parámetros | | Requiere capacidad de trabajar con mensajes de *join*. | No requiere capacidad de trabajar con mensajes de *join*. | | Los parámetros RxDelay y CFList pueden ser configurados en el momento del inicio de sesión | | | La generación de las claves NwkSKey y AppSKey se realiza automáticamente garantizando que éstas son únicas | Se deben generar las claves NwkSKey y AppSKey previo al inicio de sesión y garantizar que sean únicas. | | Proceso de inicio de sesión adecuado para redes [LoRaWAN](#LoRaWAN-dLoRaWAN) con numerosos [end-point](#Endpoints-Endpoints)s y con proyección a escalar. | Proceso de inicio de sesión adecuado para prototipar y pruebas de concepto. | ##### Gateway {dGateway} En la arquitectura de una red [LoRa](#LoRa-dLoRa), los [gateways](#Gateway-dGateway) conectan los nodos con la red de datos. Su función principal es **recibir los mensajes de uno o más [end-point](#Endpoints-Endpoints)s** a través del enlace de *uplink*, agregar *metadata*, opcionalmente agregar mensajes de estado y ***reenviarlos* al servidor**, este proceso se lleva a cabo por un *"forwarder"*. Y viceversa. Un [gateway](#Gateway-dGateway) consta de dos *"componentes"*: ###### LoRa gateway {#Lgateway} Se comunica con los [end-point](#Endpoints-Endpoints)s por [RF](#RF-gRF) a través redes de baja potencia [LoRa](#LoRa-dLoRa). Las señales que llegan al [gateway](#Gateway-dGateway) son analógicas, una vez en este punto de la arquitectura, se digitalizan a través de un dispositivo electrónico cuyo diagrama de bloques simplificado es como sigue: ![](https://i.imgur.com/COLgX70.png) "Simplified Block Diagram", *Figure 1, pag. 9*, [Data Sheet RMF95](https://cdn.sparkfun.com/assets/learn_tutorials/8/0/4/RFM95_96_97_98W.pdf). Los datos digitalizados se envían al Microcontrolador/Microprocesador para que este pueda contar con dichos datos para ejecutar sus tareas principales. En el caso del chip RFM95 utiliza la interfaz **[SPI](#SPI-gSPI)** mientras que algunos chips utilizan [I²C](#I²C-gI²C). ###### LoRa gateway Bridge Este componente del [gateway](#Gateway-dGateway) usa redes de banda ancha como **WiFi, Ethernet o radio celular** para comunicarse con la red WAN, donde se encuentra el servidor. Envía los mensajes provenientes de los [end-point](#Endpoints-Endpoints)s a través de la red de datos. El [gateway](#Gateway-dGateway) recibe además mensajes a través del enlace de *download* provenientes del servidor con metadata añadida por el mismo, y datos de configuración del [gateway](#Gateway-dGateway) o mensajes de configuración destinados a los [end-point](#Endpoints-Endpoints)s. *Ver Anexo: "Protocolos Gateway LoRa"* ##### LoRa Nerwork Server El servidor de red en la arquitectura [LoRa](#LoRa-dLoRa) es el responsable de **enrutar** los datos de la red [IoT](#IoT-gIoT) entre dispositivos y aplicaciones. *Ver Anexo Servidores de red LoRaWAN* ##### Integración #### MQTT *(**M**essage **Q**ueuing **T**elemetry **T**ransport)* Transporte de mensajes de telemetría por colas. ##### Breve introducción al protocolo MQTT se diseña para intercambiar grandes cantidades de datos entre dispositivos de una red IoT -*(M2M, embebidos o aplicaciones móviles)*- bajo la pila de protocolos TCP/IP, de manera agnóstica a sus tecnologías y rendimientos, pensado para generar mensajes **ligeros**, en redes **inestables**, de **ancho de banda limitado** y con nodos de **baja potencia**, con rendimiento que roza el **tiempo real**. El mecanismo de intercambio *bidireccional* de mensajes de tipo suscripción-publicación se basa en un **broker** *(intermediario o negociador)*, bajo un paradigma de orientado a **eventos** y de **baja latencia.** Provee seguridad y escalabilidad. *Ver Anexo: "Protocolos de integración, Fundamentos MQTT"* #### Websocket Protocolo que permite comunicación bidireccional y full-duplex a través de un socket establecido mediante HTTP. Responde a una comunicación tipo *cliente-servidor*. Se muestra a continuación un diagrama descriptivo de una comunicación websocket. [![](https://upload.wikimedia.org/wikipedia/commons/1/10/Websocket_connection.png)](https://commons.wikimedia.org/wiki/File:Websocket_connection.png) "Web socket" de brivadeneira / [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en) ##### Socket TCP Comunicación de datos en el que dos aplicaciones intercambian cualquier tipo flujo, para ello se requiere: * Dos **direcciones IP** que identifican a la computadora *origen* y a la *remota* correspondientemente. * Dos **puertos** que identifican a los programas en cada host. *Ver Anexo: "Fundamentos Websocket"* #### HTTP REST API ##### REST **RE**presentational **S**tate **T**ransfer *(transferencia de estado representacional)* es un estilo de arquitectura de software para sistemas distribuidos como la Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP, ante la crisis de escalabilidad. ##### REST API Los servicios web *"sirven"* a un sitio u aplicación. Los clientes usan **I**nterfaces de **P**rogramación de **A**plicaciones para comunicarse con servicios web. Una API ofrece un conjunto de datos y de funciones para facilitar la interacción entre programas y les permite intercambiar infrormación. Una API web puede ser descripta como *la cara* de un servicio web, escuchando y respondiendo directamente a los pedidos de los clientes. Una API en la que se aplica el estilo de arquitectura REST, es una REST API. [![](https://upload.wikimedia.org/wikipedia/commons/3/36/Web_API.png)](https://commons.wikimedia.org/wiki/File:Web_API.png) "Web API" de brivadeneira / [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en) *Ver Anexo: "Protocolos de integración, Fundamentos REST API"* ## Análisis de componentes y tecnologías Se realiza el análisis comparativo de componentes y tecnologías de cada sección de la red [LoRa](#LoRa-dLoRa), con enfoque en la toma de decisiones con vista a **prototipar** una solución, esto es, alcanzar los requerimientos mínimos para la *prueba de concepto* del potencial producto. Se analizan opciones ideales, recomendadas y disponibles. Se toman decisiones en función de dicho análisis, pero con base en hardware disponible. ### Requerimientos mínimos * **[End-point](#Endpoints-Endpoints)s** - [ ] **Sensor/es y Actuador/es**: Es posible simular datos adquiridos por sensores de manera sencilla con un código en Python. Así mismo se podrá simular o conectar actuadores del tipo relé u otro que permitan la modificación del entorno donde se encuentra cada [end-point](#Endpoints-Endpoints). - [x] **Módulo RF LoRa**: Necesario para la comunicación entre [end-point](#Endpoints-Endpoints)s y [gateway](#Gateway-dGateway) LoRaWAN. *Debe trabajar en el rango de frecuencias 915-928MHz, ver modelo RFM95.* - [ ] **Antena RF**: Se requiere para comunicaciones de larga distancia, debe trabajar en el rango de frecuencias mencionado y de radiación omnidireccional. Para el caso del prototipo basta con un conductor a modo de dipolo. - [x] **Fuente de corriente**: Necesaria para energizar el módulo RF. Según el caso: * Cable USB (se monta circuito de prueba en protoboard). * Shield/microcontrolador. * Arduino. * RaspberryPi. * Otros. * Baterias: Para pruebas de campo que tengan que ver con mediciónes de alcance, se analizará la implementación simple de un sistema autónomo de alimentación. - [ ] **Módulo WiFi**: Dispositivo adicional que permite comunicar varios sensores a un [end-point](#Endpoints-Endpoints), únicamente posible en casos de que se tenga conexión a la red eléctrica. No necesaria para el prototipo. * **[Gateway](#Gateway-dGateway)** - [x] **Módulo RF LoRa**: Necesario para la comunicación entre [end-point](#Endpoints-Endpoints)s y [gateway](#Gateway-dGateway) LoRaWAN. *Debe trabajar en el rango de frecuencias 915-928MHz, ver modelo RFM95.* - [ ] **Antena RF**: Se requiere para comunicaciones de larga distancia, debe trabajar en el rango de frecuencias mencionado y de radiación omnidireccional. Para el caso del prototipo basta con un conductor a modo de dipolo. - [x] **Fuente de corriente**: Necesaria para energizar el módulo RF. Según el caso: * Cable USB (se monta circuito de prueba en protoboard). * Shield/microcontrolador. * Arduino. * RaspberryPi. * Otros. - [ ] **Enlace Backhole**: Dependiendo del dispositivo a utilizar como [gateway](#Gateway-dGateway), la conexión de este hacia internet podrá hacerse via WiFi, Ethernet, 4G u otro. * **Server**: - [x] Red. - [x] Aplicación. A fin de prototipar, es posible implementar ambos en un mismo host y separando los mismos mediante procesos de virtualización. ### Hardware disponible {#hwDisponible} En este caso, como recurso disponible *a priori* se cuenta con el siguiente hardware * Microcontrolador **ESP32** *(dos unidades disponibles)*. * Microcontrolador **ESP8266** *(una unidad disponible)*. * Microcontrolador Arduino UNO *(una unidad disponible)* * Módulo WiFi para Arduino. *(una unidad disponible)* #### Endpoints Los [end-point](#Endpoints-Endpoints)s deben operar bajo la norma **AU915-928** para la comunicación inalámbrica de datos con los [gateway](#Gateway-dGateway). Se determina qué *módulo RF* emplear, como interface entre la sección de adquisición de datos y [gateway](#Gateway-dGateway), en función de sensores compatibles y disponibles con el módulo RF y viceversa. ##### Ideal La elección **ideal** de hardware para [end-point](#Endpoints-Endpoints)s o nodos corresponde a productos certificados por [LoRa Alliance](https://lora-alliance.org/lorawan-certified-products). ##### Recomendado Acotando el conjunto de posibilidades, se recomienda trabajar con hardware compatible con norma **AU915-928**, y especificación sub-band2 *(frecuencia de trabajo Argentina, y consenso para usar la red TTN si fuera el caso)*. ##### Para prototipado A fin de alcanzar el objetivo de **prototipar** una solución, se acota el conjunto de hardware según el que puede proveer el equipo de trabajo, minimizando los tiempos de adquisición, costos, pero también como **demostración de simpleza y versatilidad de implementaciones de redes [IoT](#IoT-gIoT) con [LoRaWAN](#LoRaWAN-dLoRaWAN)**. #### End-points y Gateways Entre los requerimientos indispensables para montar una red [LoRaWAN](#LoRaWAN-dLoRaWAN) se encuentran el de transmisión de señales de [RF](#RF-gRF) hacia el/los [gateways](#Gateway-dGateway), **implementando el estándar** [LoRa](#LoRa-dLoRa), para lo que se necesita un módulo con dichas características que opere en el rango de frecuencias correspondiente a la *normativa argentina* y disponible en el mercado local. El mismo corresponde al [Módulo FM95/96/97/98](https://cdn.sparkfun.com/assets/learn_tutorials/8/0/4/RFM95_96_97_98W.pdf). #### Network/Application Server *Ver Anexo: "Servidores de red y aplicación LoRaWAN"* Se realiza un análisis comparativo de las opciones disponibles para servidores de red y de aplicación a través del siguiente cuadro: | Solución | Licencia | Se integra / compatible con | Requerimientos | Características | |--------------------------------------------------------------------------------------------|---------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | [LoRaServer](loraserver.io) | [MIT](https://es.wikipedia.org/wiki/Licencia_MIT) | [End-point](#Endpoints-Endpoints)s clase A/B/C. [ABP](#ABP-dABP) y [OTAA](#OTAA-dOTAA). [LoRaWAN](#LoRaWAN-dLoRaWAN) 1.0 y 1.1. Semtech. Basic Station. ADR. gRPC y REST API. MQTT y HTTP. Docker. PostgreSQL. Redis. | Ubuntu 16.04 (LTS). Ubuntu 18.04 (LTS). Debian 9 (Stretch). | Es parte del proyecto LoRaServer con soluciones listas para usar (incluyendo App Server). Por defecto usa el protocolo MQTT. Soporta configuración de canales de [LoRaWAN](#LoRaWAN-dLoRaWAN). Incluye interfáz web. Documentación disponible. | | [The Things Network](https://www.thethingsnetwork.org) | [MIT](https://es.wikipedia.org/wiki/Licencia_MIT) | [End-point](#Endpoints-Endpoints)s clase A/C. [ABP](#ABP-dABP) y [OTAA](#OTAA-dOTAA). [LoRaWAN](#LoRaWAN-dLoRaWAN) 1.0 y 1.1. Semtech. Basic Station. ADR. gRPC y REST API. MQTT y HTTP. RabbitMQ. OAuth2. Docker. Amazon. Google Cloud. Azure. | Distro GNU/Linux. Go. | Es parte del stack TTN con soluciones listas para usar (incluyendo App Server). Arquitectura distrubuída que requiere Routers, Brokers y Handlers además del servidor de red. Soporta redes privadas, pero requiere conexión con TTN Account Server. Soporta redes privadas intercambiando información con la red pública.* Soporta velocidad de datos adaptativa. Incluye interfáz web. Provee productos y servicios para industrias. Comunidad alrededor del mundo (existe comunidad en Río Cuarto). Documentación disponible. | | [Compact server for private LoRaWAN](https://github.com/gotthardp/lorawan-server) | [MIT](https://es.wikipedia.org/wiki/Licencia_MIT) | [End-point](#Endpoints-Endpoints)s clase A y C. [ABP](#ABP-dABP) y [OTAA](#OTAA-dOTAA). [LoRaWAN](#LoRaWAN-dLoRaWAN) 1.0 y 1.1. Semtech. Basic Station. ADR. gRPC y REST API. MQTT y HTTP. AMQP. RabbitMQ. MongoDB. OAuth2. Docker. Amazon AWS IoT. Google Cloud. Microsoft Azure IoT Hub. IBM Watson IoT Platform. MathWorks ThingSpeak. ThingsBoard Open-source IoT Platform Adafruit IO. Orange Live Objects. | Sistema Operativo (Windows, GNU/Linux, Os X, Raspbian, etc) Erlang/OTP 20.3+- | Incluye funcionalidades de servidor de red y de aplicación. Pensado para prototipos. Pensado para redes privadas. Incluye interfaz web. Documentación disponible. Brinda asistencia vía lista de e-mails. | | [FloraNet](https://github.com/Fluent-networks/floranet) | [MIT](https://es.wikipedia.org/wiki/Licencia_MIT) | [End-point](#Endpoints-Endpoints)s clase A y C. [ABP](#ABP-dABP) y [OTAA](#OTAA-dOTAA). MQTT y HTTP. Microsoft Azure IoT Hub. | Distribución GNU/Linux. Python. | Pensado para integrar con Microsoft Azure. Documentación disponible. Guía paso a paso disponible. | ## Tecnologías definitivas Dada la naturaleza del proyecto, orientada a la investigación y desarrollo, y concibiendo al par *practicante-tutor* como un equipo que lleva adelante el mismo, se seleccionan e implementan herramientas de: * **Gestión de proyectos**, hojas de cálculo en [Google Drive](https://www.google.com/intl/es_ALL/drive/). * **Registro de horas y tareas**, hojas de cálculo en [Google Drive](https://www.google.com/intl/es_ALL/drive/), diagrama de Gannt. * **Sistema de control de versiones**, [git](https://git-scm.com/). * **Servicio de repositorios digitales y abiertos**, [Github](https://github.com/). * **Documentación**, markdown, hackmd.io. * **Confección de diagramas**, draw.io. El entorno de desarrollo y puesta en marcha se define según los problemas abordados durante los procesos, sin descuidar las buenas prácticas y herramientas conocidas y amenas para el equipo de trabajo: * **Simulador de sistemas embebidos**, [mbed simulator.](https://labs.mbed.com/simulator/) * **IDE de desarrollo para microcontroladores**, [VS Code](https://go.microsoft.com/fwlink/?LinkID=760868). * **IDE para gestión de proyectos y librerías de sistemas embebidos**, [PlatformIO IDE](https://platformio.org/install/ide?install=vscode). * **Entorno de desarrollo para pyton scripting**, [Jupyterlab](https://jupyterlab.readthedocs.io/en/stable/). ### Para prototipado Se opta por montar la red en infraestructura de servicios gratuitos *(y por ende limitados)* en la nube, así como los métodos y formatos más simples. ### Para potencial solución comercial Se seleccionan las soluciones acordes a redes privadas, *"sin sacrificar simplicidad"*. Se muestra acontinuación el diagrama simbólico indicando las tecnologías elegidas para cada caso: [![](https://i.imgur.com/RaFKbDm.png)](https://commons.wikimedia.org/wiki/File:Diagrama-toma-decisiones.png) *Diagrama global del proyecto con tecnologías tentativas y resultado de toma de decisiones* de brivadeneira, jonathan sanchez / [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en) A continuación se describen las opciones definitvas por sección de arquitectura de red LoRaWAN: * **Gateway**: esp32-oled * **Nodos**: * esp32-oled * arduino-uno ![](https://i.imgur.com/ai9t8Wv.png) *Red LoRa: ESP32-oled, arduino-uno.* ### End-points Se seleccionan microcontroladores disponibles y adquiridos de diferentes tecnologías para testear una red agnóstica a las mismas: * ESP32, oled. * Arduino uno. #### Clase de end-point Se elige la clase de end-point tipo **A**, dado que las aplicaciones que se proyectan como evolución del prototipo no presenta exigencias de tiempo de transmisión, así como se buscan minimizar costos y acotar las opciones de hardware disponibles, lo que impacta en los requerimientos de energía. #### Modo de activación Dado que la cantidad de dispositivos de la red a prototipar es controlable, se selecciona el modo de activación **ABP** (*Activation by personalization*) por su simpleza y posibilidad de pre-programar los dispositivos. ### Gateways Se selecciona el microcontrolador con mayor capacidad de performance para cumplir el rol de **gateway** de la red, esto es esp32-oled. #### Forwarder Se elige **Semtech** como software forwarder debido al tiempo y respaldo en el desarrollo del software, apostando a la compatibilidad con mayor cantidad de tecnologías en una potencial red LoRaWAn como evolución del prototipo. ### Servidores de red y aplicación A fin de realizar el prototipado así como la prueba de concepto, se opta por usar la infraestructura de los servicios en la nube dados por [thethingnetworks](https://www.thethingsnetwork.org/), suprimiendo así tiempo de desarrollo e implementación. > Se deben contemplar las [limitaciones]((https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy-guidelines/1300)) de dichos servicios respecto al flujo de datos en la red pública, para enviar datos desde los nodos durante todo el día, se establecen intervalos de mensaje de aproximadamente **5 minutos**, tiempo estimado para dos nodos. Proyectando una potencial solución comercial, se elige **Compact server for private LoRaWAN networks** como servidor de red así como servidor de aplicación, con documentación disponible y contacto directo con desarrollador. Además, *a priori* se define montar ambos servidores en la misma computadora, de manera que esta solución se adapta mejor a los recursos disponibles. Se agrega procesamiento de datos con Python y visualización Flask y Dash, dada la experiencia en dichas tecnologías en el equipo de trabajo, como extensión del prototipo así como muestra de la posibilidad de funciones específicas y personalización a futuras soluciones comerciales. Como protocolo de comunicación entre los módulos de red y aplicación se elige **MQTT**, por ser estándar para aplicaciones de IoT y como oportunidad para explorar el mismo. ### Formato Frame Manteniendo el criterio de elección a fin de prototipado, procurando simpleza, versatilidad de implementación así como compatibilidad con mayor cantidad de tecnologías y escalabilidad, se selecciona **CBOR** como formato de frame. ## Procedimiento Habiendo seleccionado tecnologías definitivas, se describen los procedimientos para implementar los módulos del proyecto desde end-points hasta servidor de aplicación, testeando conectividad y desempeño. La siguiente lista de tareas describe el proceso de testeo, implementación y puesta en marcha del prototipo luego de la toma de decisiones y adquisición de recursos necesarios: ### Conectividad punto a punto LoRa Se realiza para corroborar buenas condiciones de hardware, se buscan ejemplos de código abierto, se realizan las modificaciones correspondientes para adaptar al hardware, entorno de desarrollo así como a la frecuencia de transmisión. ### Implementación gateway LoRa Se busca registrar por primera vez un gateway LoRa en una red pública, se buscan ejemplos de código abierto, se realizan las modificaciones correspondientes para adaptar al hardware, entorno de desarrollo así como a la frecuencia de transmisión, se emplea el microcontrolador ESP32 por su capacidad de procesamiento superior a arduino-uno. ### Implementación nodos LoRa Se crea una aplicación a la que se añaden dispositivos LoRa en una red pública, se buscan ejemplos de código abierto, se realizan las modificaciones correspondientes para adaptar al hardware, entorno de desarrollo así como a la frecuencia de transmisión, se emplean los microcontroladores ESP32 y arduino-uno. ### Implementación servidores de red y aplicación Se usa el servicio en la nube de thethingsnetwork.org, servicio gratuito y en una red pública, pero con limitaciones de uso. ### Simulación de paquetes LoRa A fin de avanzar con los módulos de aplicación bajo un escenario controlado de simulación se realiza la búsqueda de herramientas de código abierto, se simulan nodos y gateways LoRa para trabajar sobre los datos que reportan a la salida los servidores de red y de aplicación. ### Desarrollo e implementación de API MQTT Se emplea el broker público de thethingsnetworks.org, se inciia un cliente MQTT y se desarrollan algoritmos en `Python` para servir los payload LoRa en una API. ### Desarrollo e implementación de dashboard Se desarrolla además una aplicación web para graficar los datos en tiempo real, la que es alimentada por los datos de la API. ## Desarrollo A continuación se describe el desarrollo de las tareas según lo planificado y el resultado de la toma de decisiones. > El desarrollo de software para el prototipo de red LoRaWAN se encuentra hosteado y documentado con las correspondientes instrucciones que **garantizan su reproducibilidad**, en el siguiente repositorio: [LoRaWANprototype](https://github.com/brivadeneira/LoRaWANprototype). ### Conectividad punto a punto LoRa con ESP32 Se comprueba conectividad LoRa entre microcontroladores ESP32, con módulo LoRa integrado, antena de RF y display: ![](https://i.imgur.com/tXObZ6c.jpg) *ESP32 + RFM95 + Display.* Se toman ejemplos de código abierto y sus correspondientes instrucciones para adaptarlo al entorno de desarrollo del equipo de trabajo, realizar modificaciones mínimas en los algoritmos y testear así de manera sencilla que el módulo LoRa y las antenas de RF funcionen correctamente. > Se usan ejemplos de Aaron.Lee from HelTec AutoMation, ChengDu, China 成都惠利特自动化科技有限公司 www.heltec.cn. Se complementa la puesta en marcha de este ejemplo con observaciones respecto a la frecuencia de transmisión y canal, analizando la evolución de la red con la normativa argentina en mente. Se siguen las instrucciones principales del proyecto [LoRaWANprototype](https://github.com/brivadeneira/LoRaWANprototype), para acontinuación implementar [oled lora receiver](https://github.com/brivadeneira/LoRaWANprototype/tree/master/1.oled_lora_reciever) y [oled lora sender](https://github.com/brivadeneira/LoRaWANprototype/tree/master/0.oled_lora_sender) en cada uno de los esp32. ### Implementación nodos LoRa #### Implementación gateway LoRa ESP32 Se toman ejemplos de código abierto y sus correspondientes instrucciones para adaptarlo al entorno de desarrollo del equipo de trabajo, así como la documentación oficial de thethingnetworks.org, para registrar por primera vez un gateway LoRa en la red pública. > Se usan ejemplos de Maarten Westenberg (mw12554@hotmail.com), based on work done by Thomas Telkamp for Raspberry PI 1-ch gateway and many others. Se siguen las instrucciones principales del proyecto [LoRaWANprototype](https://github.com/brivadeneira/LoRaWANprototype), para acontinuación implementar [esp32 single channel lora gateway](https://github.com/brivadeneira/LoRaWANprototype/tree/master/2.esp32_single_channel_lora_gateway). #### Implementación nodo LoRa ESP32 Se toman ejemplos de código abierto y sus correspondientes instrucciones para adaptarlo a la frecuencia de trabajo de la normativa Argentina, entorno de desarrollo del equipo de trabajo, así como la documentación oficial de thethingnetworks.org, para registrar por primera vez una aplicación y un dispositivo nuevo. > Se usan ejemplos de Thomas Telkamp and Matthijs Kooijman. Se siguen las instrucciones principales del proyecto [LoRaWANprototype](https://github.com/brivadeneira/LoRaWANprototype), para acontinuación implementar [esp32 single channel lora node](https://github.com/brivadeneira/LoRaWANprototype/tree/master/3.esp32_single_channel_lora_node). ### Implementación nodo arduino uno Se siguen las instrucciones principales del proyecto [LoRaWANprototype](https://github.com/brivadeneira/LoRaWANprototype), para acontinuación implementar [arduino uno lora node](https://github.com/brivadeneira/LoRaWANprototype/tree/master/4.arduino_uno_lora_node). ### Implementación servidores de red y aplicación El prototipo de red LoRaWAN se monta sobre la infrastructura de [thethingsnetworks](https://www.thethingsnetwork.org/), tanto en lo que a servidor de red como de aplicación respecta. Se registra el gateway esp32, se crea una nueva aplicación y se registran los nodos esp32 y arduino uno. ### Simulación paquetes LoRa A fin de construir integraciones de aplicación en un escenario controlado, se emplea el simulador online [Mbed OS Simulator](https://labs.mbed.com/simulator) de paquetes LoRa, escrito en js y con ejemplos LoRa disponibles. **5.** Elegir el ejemplo **LoRaWAN**: ![](https://i.imgur.com/XzoKLyr.png) **5.1** Copiar y pegar las claves desde la aplicación *(paso 4.2)* y reemplazar en el código: ```javascript // Device credentials, register device as OTAA in The Things Network and copy credentials here static uint8_t DEV_EUI[] = { 0x00, 0x37, 0xD5, 0x78, 0x63, 0x16, 0xE6, 0x64 }; static uint8_t APP_EUI[] = { 0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x02, 0x38, 0x0C }; static uint8_t APP_KEY[] = { 0xB3, 0x9B, 0x30, 0x5F, 0xF1, 0xDF, 0xB4, 0x5B, 0xFA, 0xB5, 0x61, 0x3E, 0x4B, 0x30, 0xF7, 0x75 }; ``` **5.2** Modificar el puerto a 1 ```javascript // The port we're sending and receiving on #define MBED_CONF_LORA_APP_PORT 1 ``` **6.** Click en `run` **6.1** En `devices` -> `sim-1` -> `data` se pueden observar los paquetes generados: ![](https://i.imgur.com/z7A5vIJ.png) **7.** Repetir los pasos 4 a 6 tantas veces como dispositivos se deseen simular. ### Desarrollo e implementación de API MQTT Se llevan adelante tareas de *desarrollo* y puesta en marcha de una API en `Python` que reciba los mensajes de los nodos LoRa a través del protocolo MQTT y los *sirva* en formato `json`. Se usan las librerías `flask` para crear crear una aplicación web - cliente de MQTT con un socket que permite procesamiento de varios hilos, uno para recibir los datos del cliente y otro para publicar los datos en la API. ### Desarrollo e implementación de dashboard Se desarrolla además un *dashboard* dinámico y en tiempo real que grafica los datos de los nodos, este servicio *"consume"* la API. Se procesan y formatean los datos y se crea una aplicación web con la librería `dash`. > Cabe destacar que lo anterior es de código abierto y se encuentra publicado en un rapositorio digital abierto: [LoRaWAN prototype](https://github.com/brivadeneira/LoRaWANprototype). ## Resultados Se muestran a continuación los resultados de la investigación, desarrollo, configuración y puesta en marcha de la red LoRa punto a punto y posterior red LoRaWAN integrada a API y dashboard en tiempo real de los datos sensados. ### Red LoRa punto a punto Se descargan e implementan códigos de ejemplo de un transmisor y un receptor LoRa, se corrobora el funcionamiento del módulo y antena para dicha transmisión: ![](https://i.imgur.com/fKgGXnj.png) *Red LoRa punto a punto.* El hardware elegido, con display, permite testear rápidamente el funcionamiento. ### Red LoRaWAN Se descargan e implementan códigos en los microcontroladores, se registra el gateway en thethingsnetworks.org, así como los nodos en una aplicación: ![](https://i.imgur.com/IPScPYl.png) Los nodos envían mensajes LoRa al gateway, recepción que se puede apreciar en el display, el gateway se conecta con los servidores de red y aplicación, se pueden apreciar además los datos en la aplicación: ![](https://i.imgur.com/z7A5vIJ.png) ### API y dashboard Para el desarrollo de la API y dashboard se emplea una herramienta de **[simulación](https://labs.mbed.com/simulator/)** de sistemas embebidos con conectividad LoRa, reemplazando los nodos y gateway, en un entorno más controlado y simple: ![](https://i.imgur.com/XzoKLyr.png) #### API Se agrega a los servidores de red y aplicación **integración** de un **broker MQTT** disponibles en thethingsnetwork.org. Se desarrolla e implementa un script en Python que inicia un **cliente MQTT** y sirve los datos en formato json en una API, en tiempor real: ![](https://i.imgur.com/xF0oOmQ.png) *API LoRaWAN* Se pueden observar payloads LoRa servidos en tiempo real. #### Dashboard Se desarrolla una aplicación interativa que grafica en tiempo real los datos *de humedad y temperatura*. ![](https://i.imgur.com/NpaIw8q.png) *Gráfico de datos con filtro por dispositivo esp32*. ![](https://i.imgur.com/iVHgiSN.png) *Gráfico de datos con filtro por dispositivo arduino-uno*. ![](https://i.imgur.com/Q9Z0wwJ.png) *Gráfico de datos con filtro por dispositivo "todos"*. ## Análisis de los resultados El desarrollo, implementación y puesta en marcha del prototipo LoRaWAN se obtiene producto de la búsqueda bibliográfica, confirmar y profundizar conceptos de telecomunicaciones, analizar entre las numerosas opciones, tecnologías, códigos, dispositivos, soluciones, etc, desde una perspectiva ingenieril y con vistas a una evolución que inicia en una prueba de concepto, pero se proyecta a una potencial solución comercial. ## Conclusiones ### Sobre el proyecto Se alcanzaron los objetivos de investigación y desarrollo así como de implementación y puesta en marcha de la prueba de concepto y prototipo esencial para mostrar solución de internet de las cosas, con respaldo de tecnologías y decisiones para potencial solucion comercial y para escalar el mismo. Respetando las tareas asignadas y el plan de trabajo, con algunas modificaciones en las tecnologías elegidas y entorno de desarrollo. ### Aspectos laborales En el equipo practicante-tutor se supieron establecer planificaciones, tareas a realizar y cumplirlas de manera seria y profesional y con el uso de herramientas de gestión de proyectos sin inconveniente alguno. El tutor optó por la flexibilidad horaria, lo que benefició la correcta adaptación a actividades laborales y académicas en el día a día. Medió correspondientemente en la solicitud de adquisición de equipamientos, con la menor demora posible conforme al plan de trabajo. La modalidad presencial resulta en muchas ocasiones innecesaria, sin embargo la adaptación al lugar de trabajo y personal de la empresa fue natural. ### Aspectos profesionales Las actividades en el marco de la práctica profesional se llevaron a cabo en un escenario lo más cercano posible a una experiencia laboral real, la relación interpersonal practicante-tutor se desenvolvió naturalmente y como un verdadero equipo de trabajo, mientras que el vínculo con el resto del personal ameno, relaciones interpersonales, en algunas ocasiones la comunicación fuera del equipo practicante-tutor podría haber sido más fluída y en un contexto más organizado. Las responsabilidades asumidas respetaron el plan de trabajo pactado sin eventualidad ni inconveniente alguno. ## Proyección ### Sobre el proyecto Se proyectan mejoras y evoluciones en el prototipo, como agregar nodos y gateways de diferentes tecnologías a la red, redes privadas LoRaWAN, sensores y actuadores según potenciales soluciones, aplicaciones al usuario final orientadas a cada cliente. ### Sobre la empresa Se realiza el paso inicial a fin de impulsar proyectos de internet de las cosas con potencial de evolucionar a productos y servicios, tanto en lo que a la investigación como adquisición de equipamiento y puesta en marcha de un prototipo, con su correspondiente documentación. Se proyectan actividades sobre lo trabajado para la correcta toma de decisiones hacia soluciones de internet de las cosas. ## Bibliografía ### Documentos técnicos Technical Marketing Workgroup 1.0, [**"LoRaWAN. What is it?"**](https://lora-alliance.org/resource-hub/what-lorawanr), [*LoRa Alliance*](https://lora-alliance.org/), Noviembre 2015. [*LoRa Alliance*](https://lora-alliance.org/), [**"LoRaWAN Regional Parameters v1.0.3revA"**](https://lora-alliance.org/resource-hub/lorawanr-regional-parameters-v11rb), [LoRa Alliance](https://lora-alliance.org/resource-hub/lorawanr-regional-parameters-v103reva), Inc., 2017. [Cuadro de Atribución de Bandas de Frecuencias de la República Argentina](https://www.enacom.gob.ar/cuadro-de-atribucion-de-bandas-de-frecuencias-de-la-republica-argentina-cabfra-_p1588), CABFRA, Julio 2019. [Resolución 581MM18](https://www.enacom.gob.ar/multimedia/normativas/2018/res581MM.pdf), Poder Ejecutivo Nacional, Septiembre 2018. [Carsten Bormann](mailto:cabo@tzi.org?subject=cbor.io), [RFC 7049 - Concise Binary Object Representation (CBOR)](https://cbor.io/), Octubre de 2013. [Documentación oficial Semtech UDP](https://github.com/LoRa-net/packet_forwarder/blob/master/PROTOCOL.TXT), Semtech-Cycleo. [Documentación oficial Basic Station Forwarder](https://doc.sm.tc/station/), Semtech Corp. Fette & Melnikov, [RFC N° 6455 - WebSocket protocol](https://tools.ietf.org/rfc/rfc6455.txt), Diciembre de 2011. ### Libros G. C. Hillar, [*MQTT Essentials - ALightweight IoT Protocol*](http://ebooks.blt4spd.com/ebooks/titles/2596/file/MQTT%20Essentials%20-%20a%20Lightweight%20-%20Gaston%20C.%20Hillar.pdf), Birmingham, UK: Packt Publishing Ltd, 2017. V. Wang, F. Salim and P. Moskov [The definitive guide to HTML5 WebSocket](http://cdn.lxqnsys.com/HTML5%20WebSocket权威指南.pdf), friendsoft Apress. ### Artículos académicos ["LoRaWAN - OTA or ABP?"](https://static1.squarespace.com/static/560cc2c2e4b01e842d9fac18/t/5a938d38ec212d9451fbecf8/1519619387035/OTAA_or_ABPv3.pdf), Newie Ventures. ["Análisis para Despliegue de una Red de Sensores Heterogénea"](http://sedici.unlp.edu.ar/bitstream/handle/10915/73360/Documento_completo.pdf-PDFA.pdf?sequence=1&isAllowed=y), Medina Santiago, Romero Fernando, De Giusti Armando, Tinetti Fernando G. ["A Study of LoRa: Long Range & Low Power Networks for the Internet of Things"](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5038744/), Aloÿs Augustin, Jiazi Yi Thomas Clausen and William Mark Townsley. ### Repositorios digitales ["Single Channel LoRaWAN Gateway"](https://github.com/platenspeler/ESP-1ch-Gateway-ver-2.0), Maarten Westenberg. ["Heltec ESP32 & ESP8266 Series Arduino Develop Environment"](https://github.com/Heltec-Aaron-Lee/WiFi_Kit_series), Aaron.Lee from HelTec AutoMation, ChengDu, China 成都惠利特自动化科技有限公司 www.heltec.cn. ["Arduino-LMIC library"](https://github.com/tftelkamp/arduino-lmic), Thomas Telkamp and Matthijs Kooijman. ["ESP32 Single Channel Gateway"](https://github.com/vpcola/ESP32SingleChannelGateway), Vergil Cola. ### Guías, tutoriales y artículos en blogs Admin (10 de Octubre de 2018). ["LoRa- (Long Range) Network and Protocol Architecture with Its Frame Structure"](http://www.techplayon.com/lora-long-range-network-architecture-protocol-architecture-and-frame-formats) [*Entrada en un blog*]. Recuperado de [Techplayon](http://www.techplayon.com). akirasan (13 de Mayo de 2018). ["Nodo LoRaWAN con ESP32"](http://akirasan.net/nodo-lorawan-con-esp32/) [*Entrada en un blog*]. Recuperado de [Techplayon](http://akirasan.net/). akirasan (12 de Mayo de 2018). ["MiniGateway LoRa monocanal con ESP32"](http://akirasan.net/minigateway-lora-monocanal-con-esp32/) [*Entrada en un blog*]. Recuperado de [Techplayon](http://akirasan.net/). > Título del post \[Mensaje en un blog\]. Nombre del blog. Recuperado de htpp://xxxx > * Libros: Iniciales y Apellido del autor, Título del libro en cursiva. Edición. Lugar de publicación: Editorial, Año de publicación. > * Informes técnicos: Iniciales y Apellido del autor, "Título del informe", Nombre de la empresa, Sede la empresa, Tipo de informe abreviado, Número de informe, Fecha de publicación > * Leyes:- > 1. Los elementos que se deben tener para referenciar al final del documento son: > 2. Número de la ley y denominación oficial si la tiene. > 3. Título de la publicación en que aparece oficialmente. > 4. Lugar de publicación > 5. Fecha (indicar día, mes y año) > - Ley N° 18525. Diario Oficial de la República de Chile, Santiago, Chile, 30 de junio de 1986. > Blogs > Apellido, A. (Fecha). Título del post \[Mensaje en un blog\]. Nombre del blog. Recuperado de htpp://xxxx > RFC: Autor, RFC N° - Titulo, Fecha. > Bormann C., Editor, RFC 3095 - Robust Header Compression (ROHC), July 2001 > ## ANEXO [Anexos](https://hackmd.io/qpch67KMRlSA-u0h56eLRg#Anexos-LoRa) ### Glosario #### ACK {#gACK} *(**ACK**nowledgement)*, "acuse de recibo", mensaje que el destino de la comunicación envía al origen de esta para confirmar la recepción de un mensaje. [Más información: Artículo Wikipedia](https://es.wikipedia.org/wiki/ACK) #### ADR {#gADR} *(**A**daptative **D**ata **R**ate)*, velocidad de datos adaptable. Es un mecanismo que optimiza las velocidades de datos, los tiempos de transmisión y el consumo de energía de la red. El mismo debe estar disponible en cuanto un dispositivo posea condiciones de RF estables. [Más información: Documentación TheThingsNetwork](https://www.thethingsnetwork.org/docs/lorawan/adr.html) #### AES {#gAES} *(Advanced Encryption Standard - Estándar avanzado de cifrado)*, algoritmo de cifrado simétrico. [Más información: Artículo de Wikipedia](https://es.wikipedia.org/wiki/Advanced_Encryption_Standard) #### ALOHA {#gAloha} Protocolo del nivel de enlace de datos para redes de área local con topología de difusión. [Más información: Artículo de Wikipedia](https://es.wikipedia.org/wiki/ALOHAnet#El_protocolo_ALOHA) #### API {#gAPI} *(**A**pplication **P**rogramming **I**nterface)*, interfáz de programación de aplicaciones, conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones) #### Coseno alzado {#gCosenoAlzado} Tipo de filtro electrónicoa fin de reducir al mínimo la interferencia entre símbolos (ISI). ![](https://upload.wikimedia.org/wikipedia/commons/f/fd/Raised-cosine-filter.png) *Raised Cosine Filter Response* de [Wdwd](https://commons.wikimedia.org/wiki/User:Wdwd) / [CCby-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/) [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Filtro_de_coseno_alzado) #### Chirp {#gChirp} Señal cuya frecuencia varía *(aumenta y disminuye)* con el tiempo. [![](https://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Linear-chirp.svg/800px-Linear-chirp.svg.png)](https://en.wikipedia.org/wiki/Chirp#/media/File:Linear-chirp.svg) *"A linear chirp waveform; a sinusoidal wave that increases in frequency linearly over time" de [Georg-Johann](https://commons.wikimedia.org/wiki/User:Georg-Johann)* / [CC BY-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/) [Más información: Artículo de Wikipedia.](https://en.wikipedia.org/wiki/Chirp) #### CRC {#gCRC} *(**C**yclic **R**edundancy **C**heck)*, verificación por redundancia cíclica, es un código de detección de errores usado frecuentemente en redes digitales y en dispositivos de almacenamiento para detectar cambios accidentales en los datos. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Verificaci%C3%B3n_de_redundancia_c%C3%ADclica) #### CUPS {gCUPS} *(En el contexto de una red LoRaAN)*. Protocolo que implementa requests HTTP/REST a las estaciones para proveer información de estado y "actualizaciones". [Más información: Documentación Semtech.](https://lora-developers.semtech.com/resources/tools/basic-station/the-cups-protocol/) #### FullDuplex {#gFullDuplex} Sistema de comunicación que admite envío y recepción de información de manera *simultánea*. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/D%C3%BAplex_(telecomunicaciones)#D%C3%BAplex_(d%C3%BAplex_completo_o_full_duplex)) #### gPRC {#gPRC} Framework [RPC](https://es.wikipedia.org/wiki/Llamada_a_procedimiento_remoto) *(Remote Procedure Call, ejecuta código de manera remota.)* open-source. #### HalfDuplex {#gHalfDuplex} Sistema de comunicación en el que la información se transmite en un sólo sentido, se envía o se recibe, y no de manera simultánea. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/D%C3%BAplex_(telecomunicaciones)#Semid%C3%BAplex_(half_duplex)) #### Hash {#gHash} Resultado de aplicar una función de cifrado a un dato. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Función_hash_criptográfica#targetText=Las%20funciones%20hash%20criptográficas%20son,y%20son%20fáciles%20de%20calcular.) #### HTTP {#gHTTP} *(**H**ypertext **T**ransfer **P**rotocol)*, protocolo de transferencia de hipertexto para transferencia de información en la web. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Protocolo_de_transferencia_de_hipertexto#targetText=El%20Protocolo%20de%20transferencia%20de,en%20la%20World%20Wide%20Web.) #### IoT {#gIoT} *(**I**nternet **o**f **T**hings - Internet de las cosas).* Paradigma referido a la interconexión de objetos a la red (internet), que, previo a su definición, no lo estaban. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Internet_de_las_cosas) #### I²C {#gI²C} *(**I**nter-**I**ntegrated **C**ircuit)* **Circuito inter-integrado** es un bus serie de datos desarrollado en 1982 por [Philips](https://es.wikipedia.org/wiki/Philips "Philips") Semiconductors (hoy [NXP Semiconductors](https://es.wikipedia.org/wiki/NXP_Semiconductors "NXP Semiconductors"), parte de [Qualcomm](https://es.wikipedia.org/wiki/Qualcomm "Qualcomm")[1](https://es.wikipedia.org/wiki/I%C2%B2C#cite_note-1)). Se utiliza principalmente internamente para la comunicación entre diferentes partes de un circuito, por ejemplo, entre un controlador y circuitos periféricos integrados. [Más Información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/I%C2%B2C) #### JSON {gJSON} *(**J**avaScript **O**bject **N**otation)*, notación de objeto de JavaScript, formato de texto sencillo para el intercambio de datos. Ejemplo: ```json {"usuario":"user","password":"123456"}; ``` #### LNS {gLNS} *(En el contexto de una red LoRaWAN)*. Protocolo que permite comunicación entre dispositivos mediante websocket, para transmortar e intercambiar texto en formato JSON. [Más información: Documentación Semtech.](https://lora-developers.semtech.com/resources/tools/basic-station/the-lns-protocol/) #### Open Source {gOpenSource} Código Abierto, es un modelo de desarrollo de software basado en la colaboración abierta. Si un software es de código abierto, entonces el código se encuentra disponible, garantizando ciertas libertades. [Más información: Artículo de Wikipedia](https://es.wikipedia.org/wiki/C%C3%B3digo_abierto) #### RF {gRF} **R**adio **F**recuencia, rango de frecuencias entre 3 `Hz` y 300 `GHz` del espectro electromagnético. [Más información: Artículo de Wikipedia](https://es.wikipedia.org/wiki/Radiofrecuencia) #### Payload {#gPayload} *Carga útil*, datos enviados en un canal de comunicación excluyendo cabecera o metadatos. [Más información: Artículo de Wikipedia](https://es.wikipedia.org/wiki/Carga_%C3%BAtil_(inform%C3%A1tica)) #### SPI {#gSPI} *(**S**erial **P**eripheral **I**nterface)*. Interfaz de periféricos en serie, estándar de comunicaciones sincrónicas para la transferencia de información entre circuitos integrados en equipos electrónicos en serie. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Serial_Peripheral_Interface) #### CSSC {#gCSS} *(**C**hirp **S**pread **S**pectrum)*, espectro ensanchado con chirp, técnica de modulación de gran ocupación espectral y cuyas señales varían en frecuencia con el tiempo. [Más información: Artículo de Wikipedia.](https://en.wikipedia.org/wiki/Chirp_spread_spectrum) #### TLS {gTLS} *(**T**ransport **L**ayer **S**ecurity)*, seguridad en capa de transporte, conjunto de protocolos de cifrado para seguridad en comunicaciones de redes de datos. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Transport_Layer_Security) #### UDP {gUDP} *(**U**ser **D**atagram **P**rotocol)*, protocolo de datagramas de usuario, protocolo del nivel de transporte basado en el intercambio de datagramas, correspondiente a capa 4 del modelo OSI. No implementa corrección de errores. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/Protocolo_de_datagramas_de_usuario) #### Web socket {gWebsocket} Tecnología que proporciona un canal de comunicación bidireccional y full-duplex sobre un único socket TCP. Está diseñada para ser implementada en navegadores y servidores web, pero puede utilizarse por cualquier aplicación cliente/servidor. [Más información: Artículo de Wikipedia.](https://es.wikipedia.org/wiki/WebSocket) ### [Anexo 1: LoRaWAN Regional Parameters (v1.1)](https://drive.google.com/drive/folders/1CF-PDrGQx2sutzC-O6sgg4gP6YRGbppg) > Nota del Tutor Empresa referirse a: • Cumplimiento de objetivos. • Análisis de resultado. > Planilla de Evaluación de la Práctica completada por el Tutor de la Empresa > Nota del Tutor Docente: referirse a: • Cumplimiento de objetivos. • Análisis de resultado. > Adosar 13 - CD con el Informe de la Práctica Profesional > Especificaciones El informe final deberá ser presentado impreso según los siguientes criterios: • Hoja tamaño A4 • Letra New Times Roman 12 • Interlineado 1 ½ alineamiento justificado. • Páginas numeradas en forma correlativa. • Extensión máxima del resumen: 200 palabras. • Extensión máxima del informe: 25 páginas (sin incluir anexos)