Experimento avanzado: sobre la base del experimento básico, conectar una entrada digital para mandar órdenes remotas (pulsador) y dos salidas digitales (leds rojo y Amarillo) para recibir órdenes remotas en base a unas alarmas, mediante una plataforma IoT propia diseñada y programada con Node-RED.
De forma más avanzada usando una plataforma IoT desarrollada con Node-RED, permite más acciones y personalización, así como publicar los datos en una web pública accesible.
Se capturarán los datos de los sensores de temperatura, humedad e iluminación y se almacenarán en una Base de Datos InfluxDB: https://aprendiendonodered.com:8086
El stream de datos se analizará en tiempo real y se generarán unas alertas cuando se superen los siguientes umbrales:
Temperatura > 22 ºC
Iluminación < 500
Se programará la lógica, de forma que cuando la iluminación sea baja, se encenderá el led amarillo y cuando la temperatura sea alta se encenderá el led rojo, según los umbrales definidos anteriormente.
Además se mostrarán en el dashboard de la plataforma IoT desarrollada por los alumnos los siguientes datos:
Gauge y gráfica últimos 30 minutos temperatura
Gauge y gráfica últimos 30 minutos humedad
Gauge y gráfica últimos 30 minutos iluminación
Estado de los leds
Contador con el número de veces que se pulsa el pulsador y un reset de contador.
Estado del dispositivo
Un switch para encender y apagar el led integrado
Ejemplo de ejercicio IoT con redes 5G, usando Arduino MKR1500 que tiene conectividad LTE-M.
Para el curso, usaremos esta tarjeta IoT https://1nce.com/en-us/1nce-connect que tiene activado para España tanto LTE-M como NB-IoT. Es imprescindible que cada alumno que asista al curso tenga una tarjeta de este tipo. Es posible comprar esta tarjeta en https://shop.1nce.com/portal/shop/ y tarda aprox. 5 días en llegar.
Experimento básico 5G: Conexión a red LTE-M mediante un Arduino MKR NB 1500 y envío de al menos dos parámetros ambientales de sensores conectados, mediante API REST y MQTT a la plataforma https://thingspeak.com/, configuración de un dashboard y almacenado de datos históricos.
Ejemplo de ejercicio IoT con redes 5G, usando Arduino MKR1500 que tiene conectividad LTE-M.
Para el curso, usaremos esta tarjeta IoT https://1nce.com/en-us/1nce-connect que tiene activado para España tanto LTE-M como NB-IoT. Es imprescindible que cada alumno que asista al curso tenga una tarjeta de este tipo. Es posible comprar esta tarjeta en https://shop.1nce.com/portal/shop/ y tarda aprox. 5 días en llegar.
Usaremos Arduino MKR NB 1500 que tiene conectividad LTE-M. La práctica tiene como objetivo que los alumnos puedan observar una experiencia con conectividad, «subir» datos y observarlos en un dashboard y luego con esos datos activar por ejemplo una alarma (que representaría encendiendo un led).
En configuración en la sección “Broker Server”, poner los datos del broker MQTT que estamos usando y comprobar que conecta correctamente.
Crear un dashboard con los siguientes elementos asociados a los topics:
Un value con nombre “temperatura” y suscrito al topic cursomqtt/<ID_DISPOSITIVO>/temperatura – para visualizar la temperatura del sensor DHT22
Un value con nombre “humedad” y suscrito al topic cursomqtt/<ID_DISPOSITIVO>/humedad – para visualizar la humedad del sensor DHT22
Un graph con nombre “iluminacion” y suscrito al topic cursomqtt/<ID_DISPOSITIVO>/iluminacion – para seguir la ilumincación del sensor LDR
Un switch con nombre “led rojo” que publique ON y OFF y esté suscrito al topic cursomqtt/<ID_DISPOSITIVO>/ledrojo – para controlar el estado del led rojo
Un switch con nombre “led amarillo” que publique ON y OFF y esté suscrito al topic cursomqtt/<ID_DISPOSITIVO>/ledamarillo – para controlar el estado del led amarillo
Un led con nombre “estado” que esté suscrito al topic cursomqtt/<ID_DISPOSITIVO>/status y muestre en rojo si recibe un OFF y verde si recibe un ON
Un texto con nombre “pulsador” que esté suscrito al topic cursomqtt/<ID_DISPOSITIVO>/status y muestre por texto cada vez que se pulse el pulsador.
El Dashboard quedará como:
Finalmente comprobar que puedes interactuar con la maqueta desde el móvil.
5G está causando un gran impacto en IoT, lo que permite una amplia gama de nuevos dispositivos y arquitecturas de plataforma. Esperamos que esto pueda significar innovaciones como la gestión automatizada del ciclo de vida, la división de redes, las redes definidas por software y las aplicaciones de redes distribuidas optimizadas para la nube.
Los teléfonos móviles ya están en transición a 5G, pero el futuro de IoT está en el horizonte. Todo eso es muy emocionante para la industria, pero descifrar el lío de acrónimos técnicos que rodean la tecnología 5G puede limitar nuestra capacidad de comprender cómo 5G cambiará el panorama de IoT.
La popularidad y la ubicuidad de los dispositivos IoT han llevado al surgimiento de opciones de redes de área amplia (LP-WAN) de bajo consumo como SigFox y LoRa.
Las opciones celulares tradicionales, como las redes 3G, 4G y LTE, consumen demasiada energía. Además, no se adaptan bien a las aplicaciones en las que solo se transmite una pequeña cantidad de datos con poca frecuencia, por ejemplo, medidores para leer los niveles de agua, el consumo de gas o el uso de electricidad.
Cellular IoT intenta responder a la búsqueda incesante de mejores aplicaciones de bajo consumo y largo alcance.
IoT celular significa: pocos datos a lo largo de muchos kilómetros. Uno de los factores detrás de la popularidad de la tecnología IoT celular es que permite aprovechar la infraestructura GSM densa y confiable existente, lo que significa un mejor rendimiento y economía al mismo tiempo. Sin embargo, debe quedar claro que las opciones celulares estándar y bien establecidas, como 2G, 3G o LTE consumen mucha energía y, por lo tanto, no van bien con las aplicaciones habituales de IoT, donde solo se envían pequeñas cantidades de datos de forma intermitente, como medidores inteligentes, sensores y actuadores agrícolas, dispositivos de seguimiento de activos, equipo inteligente para el cuidado de la salud y muchos más.
CAT-1
Cat-1 representa un impulso inicial hacia la conexión de dispositivos IoT mediante redes LTE existentes. Si bien el rendimiento es inferior a las redes 3G, es una excelente opción para aplicaciones IoT que requieren una interfaz de navegador o voz. La principal atracción es que ya está estandarizado y, lo que es más importante, la transición a la red Cat-1 es sencilla. Los expertos predicen que a medida que las tecnologías 3G, y eventualmente 4G, desaparezcan, las redes Cat-1 (y Cat-M1) ocuparán su lugar.
CAT-0
Para que las redes IoT basadas en LTE tengan éxito, deben tener las siguientes características: 1) batería de larga duración, 2) bajo costo, 3) compatibilidad con un gran volumen de dispositivos, 4) cobertura mejorada (mejor penetración de la señal a través de las paredes, por ejemplo). ), y 5) de largo alcance/amplio espectro.
Cat-0 optimiza el costo ya que eliminó funciones que admitían requisitos de alta velocidad de datos para Cat-1 (cadena de receptor doble, filtro dúplex). Si bien Cat-1 está reemplazando a 3G, Cat-0 es el protocolo que sienta las bases para que Cat-M reemplace a 2G como la opción más económica.
Cat-M1/Cat-M/LTE-M
Cat-M (oficialmente conocido como LTE Cat-M1) a menudo se considera la segunda generación de chips LTE creados para aplicaciones de IoT. Completa la reducción de costos y consumo de energía para la cual Cat-0 preparó el escenario originalmente. Al limitar el ancho de banda máximo del sistema a 1,4 MHz (a diferencia de los 20 MHz de Cat-0), Cat-M tiene aplicaciones específicas para aplicaciones LPWAN como la medición inteligente, en las que solo se requiere una pequeña cantidad de transferencia de datos.
Pero la verdadera ventaja de Cat-M sobre otras opciones radica en esto: Cat-M es compatible con la red LTE existente. Para operadores como Verizon y AT&T, esta es una gran noticia, ya que no tienen que gastar dinero para construir nuevas antenas, aunque la integración de Cat-M en redes LTE requiere un parche de software. Las bases de clientes existentes de Verizon y AT&T probablemente concluirán que Cat-M es, con mucho, la mejor opción. Por último, es casi seguro que las tecnologías 5G y LTE coexistirán hasta bien entrada la década de 2020, por lo que la retrocompatibilidad de Cat-M es una ventaja.
NB-IoT (también llamado Cat-M2) tiene un objetivo similar al de Cat-M; sin embargo, utiliza modulación DSSS en lugar de radios LTE. Por lo tanto, NB-IoT no opera en la banda LTE, lo que significa que los proveedores tienen un costo inicial más alto para implementar NB-IoT.
No obstante, NB-IoT se promociona como la opción potencialmente menos costosa, porque elimina la necesidad de una puerta de enlace. Otras infraestructuras suelen tener puertas de enlace que agregan datos de sensores, que luego se comunican con el servidor principal. Sin embargo, con NB-IoT, los datos del sensor se envían directamente al servidor principal. Por ese motivo, Huawei, Ericsson, Qualcomm y Vodafone están invirtiendo activamente en aplicaciones comerciales de NB-IoT.
Estándares de IoT celular creados en torno al concepto de LPWAN que se desarrolló para extender la vida útil de la batería de los dispositivos con recursos limitados y puede funcionar de manera efectiva a distancias de alrededor de 20 a 150 kilómetros.
Preparados para el futuro: son parte de 3GPP y 5G, el futuro líder de la tecnología de conectividad
Estandarizado, seguro y administrado por el operador dentro del espectro licenciado.
Diseñado para aplicaciones IoT que son de bajo costo, funcionan con velocidades de datos bajas, necesitan una batería de larga duración y se usan con frecuencia en lugares de difícil acceso.
Una opción obvia para implementaciones M2M que buscan reemplazos 2G y 3G para dispositivos heredados con largos ciclos de vida que requieren una buena cobertura y una mayor duración de la batería.
Muy bajo consumo de energía, lo que permite una duración de la batería del dispositivo de hasta 10 años. Es por eso que estas redes a veces también se denominan redes de área amplia de baja potencia (LPWAN).
Largo alcance y cobertura muy amplia, varias veces mejor que LTE.
Hardware de bajo costo, debido a la complejidad reducida y economías de escala.
Hasta 100000 o incluso más dispositivos por estación base, porque cada dispositivo tiene requisitos de rendimiento de datos muy bajos y porque las técnicas de software optimizadas permiten que las estaciones base se comuniquen con una gran cantidad de dispositivos IoT.
A juzgar por la lista anterior, parece que las características que comparten LTE-M y Narrowband IoT prevalecen y que las dos tecnologías son casi sinónimos. Pero no es del todo así; la diferencia entre ellos radica en algunos parámetros clave y, nuevamente, esos son, de hecho, los factores decisivos en el proceso de decisión de elegir la opción de conectividad IoT celular adecuada para su implementación.
NB‑IoT y LTE‑M son los sucesores naturales de los estándares celulares más antiguos para las aplicaciones existentes y también impulsarán el desarrollo de aplicaciones completamente nuevas.
La siguiente figura muestra algunos de los casos de uso de IoT habilitados por MTC masivo y aplicaciones críticas de MTC. El MTC masivo se basa en tecnologías LPWAN, incluidas NB-IoT y LTE-M, mientras que el MTC crítico requerirá comunicaciones en tiempo real con muy baja latencia y alta confiabilidad.
La siguiente tabla compara las características de LTE‑M y NB‑IoT. Las mayores diferencias son el ancho de banda y el soporte de voz, pero a efectos prácticos, es probable que las diferencias para los desarrolladores de dispositivos IoT sean pequeñas. NB-IoT puede usar un poco menos de energía y el hardware requerido puede ser un poco menos complejo.
La principal diferencia entre LTE-M y NB-IoT es el ancho de banda de frecuencia. Como sugiere el nombre NarrowBand, el ancho de banda de frecuencia para NB-IoT es considerablemente más bajo que para LTE-M. La tasa de rendimiento de datos también es mayor con LTE-M, con hasta 1 Mbit/s. Para NB-IoT, la velocidad de datos es mucho más baja, hasta 128 Kbit/s.
En términos de penetración en edificios, NB-IoT funciona mejor que LTE-M y, por lo tanto, está predestinado para aplicaciones estacionarias, especialmente en edificios y sótanos. LTE-M tiene una puntuación particularmente buena en las aplicaciones móviles de IoT porque la tecnología admite lo que se conoce como «traspaso», es decir, conmutación de celdas de radio sin interrupción.
EC-GSM (anteriormente EC-EGPRS)
EC significa Cobertura Extendida. EC-GSM es la red GSM optimizada para IoT, el protocolo inalámbrico que utiliza el 80 % de los teléfonos inteligentes del mundo. Como sugiere el nombre, EC-GSM se puede implementar en redes GSM existentes, una gran ventaja en términos de practicidad y modularidad, ya que una simple pieza de software permite la conectividad EC-GSM dentro de redes 2G, 3G y 4G. EC-GSM también tiene aplicaciones específicas en regiones no occidentales como Malasia y países de África y Medio Oriente, donde 2G sigue siendo un estándar popular. Se dice que Ericsson, Intel y Orange completaron las pruebas en vivo de EC-GSM a principios de este año. EC-GSM, sin embargo, no está generando tanta expectación como Cat-M o NB-IoT.
IoT celular 5G
A diferencia de las opciones de IoT celular anteriores, 5G aún no se ha definido oficialmente. Next Generation Mobile Networks Alliance (NGMN) está presionando para que las especificaciones sean 40 veces más rápidas que 4G y admiten hasta 1 millón de conexiones por kilómetro cuadrado. 5G ya está habilitando aplicaciones de gran ancho de banda y alta velocidad para transmisión Ultra-HD (4k), conectividad de automóviles autónomos o aplicaciones VR/AR.
Si es un proveedor de telefonía celular, se verá obligado a elegir una tecnología para implementar para cumplir con las aplicaciones de IoT de banda estrecha. Para los usuarios, es importante entender que estas diferentes opciones no necesariamente tienen que ser mutuamente excluyentes. Esto se extiende a otras redes LPWAN como SigFox o LoRa.
IoT cubre un amplio espectro de aplicaciones. A veces, necesita un gran ancho de banda, como con la vigilancia en tiempo real. Los medidores inteligentes y muchos casos de uso de ciudades inteligentes requieren una pequeña transferencia de datos una o dos veces al día. Esto significa que ninguna tecnología (incluso 5G) puede satisfacer las necesidades específicas de una solución/dispositivo IoT.
El 5G se está desarrollando principalmente en tres vías:
Banda ancha móvil mejorada o eMBB
IoT para servicios de misión crítica
IoT masivo
Banda Ancha Móvil Mejorada o eMBB (enhaced Mobile BroadBand)
5G ofrecerá velocidades de Gigabit y enormes cantidades de datos. Eso significa conectividad siempre activa en cualquier lugar y velocidades constantes similares a las de la fibra, sin importar el número de conexiones. Además de los servicios de banda ancha móvil de ultra-alta velocidad para teléfonos inteligentes, también se ofrecerán otros servicios como banda ancha fija para residencias y empresas, Realidad Virtual (VR) y Realidad Aumentada (AR), etc. Es importante recalcar que durante la transición a las nuevas redes y servicios 5G que se están implementando gradualmente, la red Gigabit 4G-LTE subyacente se mantendrá como alternativa (fallback) cuando los usuarios entren en áreas sin cobertura 5G.
IoT en Servicios de Misión Crítica
El sello distintivo del 5G es su capacidad para proporcionar una latencia ultra-baja y una fiabilidad extremadamente alta. Estas capacidades habilitarán aplicaciones, servicios y usos que no eran posibles con 4G. Por ejemplo, en la automatización industrial podrá reemplazar la conexión Ethernet por cable. Otras aplicaciones posibles son la cirugía remota, el control a distancia de operaciones peligrosas, etc.
IoT Masivo
IoT LTE hizo el trabajo de adaptar la tecnología pensada para smartphones a los dispositivos IoT con sus características específicas, como la baja velocidad, el bajo coste y el bajo consumo de energía. Ahora, esta tecnología IoT LTE está evolucionando hacia el IoT 5G Masivo. Uno de los avances específicos de 5G aplicado a IoT será la capacidad de admitir una densidad muy alta de dispositivos IoT en un área pequeña, llegando al millón de dispositivos por kilómetro cuadrado. El objetivo es conectar de manera eficiente cualquier dispositivo que pueda conectarse a Internet, sin saturar la red.
Evolución de IoT LTE a IoT 5G
IoT LTE es una de las tecnologías actuales que utilizan los dispositivos IoT para conectarse a la red. Esta tecnología junto con algunas otras, se engloban dentro del estándar 3GPP para redes LPWA (Low Power Wide Area).
Los dispositivos IoT tienen necesidades diversas. Hay aplicaciones como cámaras de vídeo que requieren velocidades y capacidades muy altas mientras que otras aplicaciones requieren velocidades bajas pero una duración de batería extremadamente larga. En función de sus necesidades se aplica la tecnología IoT adecuada. IoT LTE ha construido unos sólidos cimientos y aprovechando esta base, IoT 5G podrá llevar su rendimiento al siguiente nivel, permitiendo una densidad muy alta de dispositivos, así como una latencia muy baja y extrema fiabilidad. La asociación 3GPP, que desarrolla los estándares de comunicación móvil, publicó en la release 15 su adaptación para IoT 5G, una nueva interfaz de radio llamada 5G-NR (New Radio). 5G-NR tendrá soporte en banda para LTE y será totalmente compatible con versiones anteriores. Esto significa que los dispositivos IoT LTE de hoy funcionarán sin problemas cuando las redes se actualicen a 5G-NR.
5G-NR permitirá muchos nuevos usos que ahora no pueden realizarse con 4G. Los servicios de misión crítica 5G incluyen características como eURLLC (comunicación ultra-confiable de baja latencia) que ofrece una latencia próxima al milisegundo y CoMP (multipunto coordinado) que ofrece una fiabilidad muy alta. Los primeros módulos en darse a conocer en el mercado IoT 5G han sido los módulos 5G sub-6 y mmWave de Telit. Estos módulos con formato Data Card tipo M.2 y soporte para PCIe Gen3 y USB 3.1 son compatibles con la última generación 4G/5G release 15. Soportan SA y NSA así como una amplia gama de frecuencias en 5G FR1, 5G FR2 y LTE. También cuentan con un receptor GNSS de doble frecuencia GPS para una mayor precisión y soporte de voz LTE.
A medida que el 5G comienza su implantación generalizada nos podemos preguntar si vale la pena seguir invirtiendo en IoT LTE o hemos de esperar a IoT 5G. O si somos una empresa que aún no han adoptado IoT LTE nos podríamos plantear si pasar directamente a IoT 5G. Invertir en IoT LTE hoy no solo satisface las necesidades del mercado actual, sino que también establece una base sólida para abordar las oportunidades del futuro de manera efectiva. La confrontación entre IoT LTE y IoT 5G no existe, no son conceptos contrarios sino complementarios. IoT LTE es la clave para el éxito en IoT 5G. La industria que quiera ser líder en IoT deberá tener una base sólida en IoT LTE o de lo contrario correrá el riesgo de ser adelantada por la competencia.
Usaremos esta tarjeta IoT https://1nce.com/en-us/1nce-connect que tiene activado para España tanto LTE-M como NB-IoT. Es imprescindible que cada alumno que asista al curso tenga una tarjeta de este tipo. Podéis comprar esta tarjeta en https://shop.1nce.com/portal/shop/ y tarda aprox. 5 días en llegar.
MQTT son las siglas de Message Queue Telemetry Transport y tras ellas se encuentra un protocolo ideado por IBM y liberado para que cualquiera podamos usarlo enfocado a la conectividad Machine-to-Machine (M2M).
MQTT fue creado por el Dr. Andy Stanford-Clark de IBM y Arlen Nipper de Arcom — ahora Eurotech — en 1999 como una forma rentable y confiable de conectar los dispositivos de monitoreo utilizados en las industrias del petróleo y el gas a servidores empresariales remotos. Cuando se les planteó el reto de encontrar la manera de enviar los datos de los sensores de los oleoductos en el desierto a sistemas SCADA externos (control de supervisión y adquisición de datos), decidieron utilizar una topología de publicación/suscripción basada en TCP/IP que se basaría en los eventos para mantener bajos los costos de transmisión de los enlaces satelitales.
Aunque MQTTT todavía está estrechamente asociado con IBM, ahora es un protocolo abierto que es supervisado por la Organización para el Avance de los Estándares de Información Estructurada (OASIS).
Está enfocado al envío de datos en aplicaciones donde se requiere muy poco ancho de banda. Además, sus características le permiten presumir de tener un consumo realmente bajo así como precisar de muy pocos recursos para su funcionamiento.
Estas características han hecho que rápidamente se convierta en un protocolo muy empleado en la comunicación de sensores y, consecuentemente, dentro del Internet de las Cosas.
MQTT es un protocolo pensado para IoT que está al mismo nivel que HTTP o CoAP:
Comparativa MQTT y CoAP:
Un aspecto importante a tener en cuenta de los dispositivos IoT no es solamente el poder enviar datos al Cloud/Servidor, sino también el poder comunicarse con el dispositivo, en definitiva la bidireccionalidad. Este es uno de los beneficios de MQTT: es un modelo brokered, el cliente abre una conexión de salida al bróker, aunque el dispositivo esté actuando como Publisher o subscriber. Esto normalmente evita los problemas con los firewalls porque funciona detrás de ellos o vía NAT.
Cómo funciona MQTT
En el caso de que la comunicación principal se base en HTTP, la solución tradicional para enviar información al dispositivo sería HTTP Polling. Esto es ineficiente y tiene un coste elevado en aspectos de tráfico y/o energía. Una manera más novedosa de hacerlo sería con el protocolo WebSocket, que permite crear una conexión HTTP completa bidireccional. Esto actúa de canal socket (parecido al canal típico TCP) entre el servidor y el cliente. Una vez establecido, ya es trabajo del sistema escoger un protocolo para hacer un túnel sobre la conexión.
El Transporte de telemetría de cola de mensajes (MQTT) es un protocolo de código abierto que se desarrolló y optimizó para dispositivos restringidos y redes de bajo ancho de banda, alta latencia o poco confiables. Es un transporte de mensajería de publicación/suscripción que es extremadamente ligero e ideal para conectar dispositivos pequeños a redes con ancho de banda mínimo. El MQTT es eficiente en términos de ancho de banda, independiente de los datos y tiene reconocimiento de sesión continua, porque usa TCP. Tiene la finalidad de minimizar los requerimientos de recursos del dispositivo y, a la vez, tratar de asegurar la confiabilidad y cierto grado de seguridad de entrega con calidad del servicio.
El MQTT se orienta a grandes redes de dispositivos pequeños que necesitan la supervisión o el control de un servidor de back-end en Internet. No está diseñado para la transferencia de dispositivo a dispositivo. Tampoco está diseñado para realizar «multidifusión» de datos a muchos receptores. El MQTT es simple y ofrece pocas opciones de control. Las aplicaciones que usan MQTT, por lo general, son lentas en el sentido de que la definición de «tiempo real» en este caso se mide habitualmente en segundos.
Para filtrar los mensajes que son enviados a cada cliente los mensajes se disponen en topics organizados jerárquicamente. Un cliente puede publicar un mensaje en un determinado topic. Otros clientes pueden suscribirse a este topic, y el broker le hará llegar los mensajes suscritos.
Los clientes inician una conexión TCP/IP con el broker, el cual mantiene un registro de los clientes conectados. Esta conexión se mantiene abierta hasta que el cliente la finaliza. Por defecto, MQTT emplea el puerto 1883 y el 8883 cuando funciona sobre TLS.
Para ello el cliente envía un mensaje CONNECT que contiene información necesaria (nombre de usuario, contraseña, client-id…). El broker responde con un mensaje CONNACK, que contiene el resultado de la conexión (aceptada, rechazada, etc).
Para enviar los mensajes el cliente emplea mensajes PUBLISH, que contienen el topic y el payload.
Para suscribirse o desuscribirse se emplean mensajes SUBSCRIBE y UNSUSCRIBE, que el servidor responde con SUBACK y UNSUBACK.
Por otro lado, para asegurar que la conexión está activa los clientes mandan periódicamente un mensaje PINGREQ que es respondido por el servidor con un PINGRESP. Finalmente, el cliente se desconecta enviando un mensaje de DISCONNECT.
MQTT es un protocolo que está cobrando mucha importancia en la industria (IIoT). MQTT (Message Queuing Telemetry Transport, ‘Cola de mensajes telemetría y transporte’) es un protocolo publicar/suscribir diseñado para SCADA. Se centra en un mínimo encabezado (dos bytes) y comunicaciones confiables. También es muy simple. Tal como HTTP, la carga MQTT es específica para la aplicación, y la mayoría de las implementaciones usan un formato JSON personalizado o binario.
MQTT es interesante usarlo cuando el ancho de banda bajo y no conozca su infraestructura. Asegúrese de que su proveedor tenga un broker MQTT a quien le pueda publicar información, y siempre asegure la comunicación con TLS (Transport Layer Security, ‘seguridad en la capa de transporte’).
Por ejemplo, MQTT sería una buena opción para monitorizar y controlar los paneles solares. MQTT es un protocolo de publicación/suscripción con brokers de mensajes centrales. Cada panel solar puede contener un nodo IoT que publique mensajes de tensión, corriente y temperatura.
MQTT está diseñado para minimizar el ancho de banda, lo que lo convierte en una buena opción para el monitoreo satelital de la línea de transmisión, pero hay una trampa. La ausencia de metadatos en las cabeceras de los mensajes significa que la interpretación de los mensajes depende completamente del diseñador del sistema.
Para compensar las redes poco fiables, MQTT soporta tres niveles de Calidad de Servicio (QoS):
Disparar y olvidar (0) – Fire and Forget – At most once
Al menos una vez (1) – At least once
Exactamente una vez (2) – Exactly once
Si se solicita el nivel de calidad de servicio 1 ó 2, el protocolo gestiona la retransmisión de mensajes para garantizar la entrega. La calidad de servicio puede ser especificada por los clientes de publicación (cubre la transmisión del publicador al broker) y por los clientes suscriptores (cubre la transmisión de un broker a un suscriptor).
MQTT QoS 2 aumentará la latencia porque cada mensaje requiere dos handshake completos de ida y vuelta del remitente al receptor (cuatro en total del publicador al suscriptor).
En un patrón de publicación/suscripción es difícil saber la diferencia entre «Ha pasado mucho tiempo desde que supe de mi publicador» y «Mi publicador murió». Ahí es donde entra en juego la Última Voluntad y el Testamento (LWT) de MQTT. Los clientes pueden publicar mensajes sobre temas específicos (por ejemplo, aisle15/rack20/panel5/FalloSensor) para que se entreguen si se desconectan sin enviar un mensaje de «desconexión». Los mensajes se almacenan en el broker y se envían a cualquier persona que se haya suscrito al tema.
MQTT de un vistazo
Ancho de banda muy bajo
TCP/IP
Publicar/suscribir transferencia de mensajes
Topología de muchos a muchos a través de un broker central
Sin metadatos
Tres niveles de QoS
Última Voluntad y Testamento revela nodos desconectados
Las ventajas de usar el protocolo MQTT son:
Es asíncrono con diferentes niveles múltiples de calidad del servicio, lo que resulta ser importante en los casos donde las conexiones de Internet son poco confiables.
Envía mensajes cortos que se vuelven adecuados para las situaciones de un bajo ancho de banda.
No se requiere de mucho software para implementar a un cliente, lo cual lo vuelve fantástico para los dispositivos como Arduino con una memoria limitada.
Podemos cifrar los datos enviados y usar usuario y password para proteger nuestros envíos.
Si quisiera grabar en una BBDD con MQTT, un suscriptor a una serie de topics se encarga de grabar los datos cada vez que cambia un valor o cada cierto tiempo, por ejemplo con un script de python o ejecutando Node-RED en una máquina virtual o en el propio servidor (o Raspberry Pi) donde corre el broker (Mosquitto):
NodeRed no es más que un software que se instala en un nodo aunque se instale en el mismo servidor que el broker.
MQTT (Message Queue Telemetry Transport), un protocolo usado para la comunicación machine-to-machine (M2M) en el «Internet of Things». Este protocolo está orientado a la comunicación de sensores, debido a que consume muy poco ancho de banda y puede ser utilizado en la mayoría de los dispositivos empotrados con pocos recursos (CPU, RAM, …).
Un ejemplo de uso de este protocolo es la aplicación de Facebook Messenger tanto para android y Iphone. La arquitectura de MQTT sigue una topología de estrella, con un nodo central que hace de servidor o «broker». El broker es el encargado de gestionar la red y de transmitir los mensajes, para mantener activo el canal, los clientes mandan periódicamente un paquete (PINGREQ) y esperan la respuesta del broker (PINGRESP). La comunicación puede ser cifrada entre otras muchas opciones.
En esta forma de comunicación se desacoplan los clientes que publican (Publisher) de los que consumen los datos (Suscribers). Eso significa que los clientes no se conocen entre ellos unos publican la información y otros simplemente la consumen, simplemente todos tienen que conocer al message broker.
El desacoplamiento se produce en tres dimensiones:
En el espacio: El publicador y el suscriptor no tienen porqué conocerse. No hace falta saber la dirección IP del contrario, ubicación, ni nada, el publicador manda el dato y lo entrega el broker. Muy interesante si cambio el equipo suscriptor de IP o de ubicación.
En el tiempo: El publicador y el suscriptor no tienen porqué estar conectados en el mismo momento. Como el email, que lee el dato publicado cuando el suscriptor está disponible, pero necesita el retained u otro método con persistencia de los admitidos por MQTT.
En la sincronización: las operaciones en cualquiera de los dos componentes no quedan interrumpidas mientras se publican o se reciben mensajes.
Es precisamente el broker el elemento encargado de gestionar la red y transmitir los mensajes.
Una característica interesante es la capacidad de MQTT para establecer comunicaciones cifradas lo que aporta a nuestra red una capa extra de seguridad.
La comunicación se basa en unos «topics» (temas), que el cliente que publica el mensaje crea y los nodos que deseen recibirlo deben suscribirse a él. La comunicación puede ser de uno a uno, o de uno a muchos.
Dentro de la arquitectura de MQTT, es muy importante el concepto «topic» o «tema» en español ya que a través de estos «topics» se articula la comunicación puesto que emisores y receptores deben estar suscritos a un «topic» común para poder entablar la comunicación. Este concepto es prácticamente el mismo que se emplea en colas, donde existen un publicadores (que publican o emiten información) y unos suscriptores (que reciben dicha información) siempre que ambas partes estén suscritas a la misma cola.
Los Broker MQTT aplican un filtrado a los mensajes que son recibidos desde los publicadores, para discriminar a qué clientes suscritos es entregado. En MQTT este filtro se denomina Topic, y simplemente consiste en una cadena de texto UTF-8, y una longitud máxima de 65536 caracteres (aunque lo normal es que sea mucho menor). Se distingue entre mayúsculas y minúsculas.
Este tipo de arquitecturas, lleva asociada otra interesante característica: la comunicación puede ser de uno a uno o de uno a muchos.
Un «topic» se representa mediante una cadena y tiene una estructura jerárquica. Cada jerarquía se separa con ‘/’.
Por ejemplo, «edificio1/planta5/sala1/raspberry2/temperatura» o «/edificio3/planta0/sala3/arduino4/ruido«. De esta forma se pueden crear jerarquías de clientes que publican y reciben datos, como podemos ver en la imagen:
De esta forma un nodo puede subscribirse a un «topic» concreto («edificio1/planta2/sala0/arduino0/temperatura») o a varios («edificio1/planta2/#»).
El funcionamiento de los Topcis en MQTT es sencillo y transparente. Por un lado el Broker acepta todos los Topics. No es necesario crearlo explícitamente antes de publicar o suscribirse al Broker. Los clientes pueden suscribirse a uno o varios Topic. Para ello, el cliente puede establecer varias suscripciones y/o emplear Wildcards.
Finalmente, los clientes publican mensajes indicando un único Topic. El Broker recibe el mensaje y, si encuentra alguna suscripción que cumpla con el filtro del Topic, transmite el mensaje a los clientes suscritos.
Un broker no necesita mantener una lista de los temas a los que se han publicado los mensajes, sólo comprueba la lista de temas a los que está suscrito cada cliente cuando llega un mensaje.
Un topics especiales son los topics de sistema, que son aquello que publica el propio broker para mandar información de su estado. Estos están bajo la jerarquía de $SYS: https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics
Existen dos comodines en MQTT para suscribirse a varios topics (no se pueden usar para publicar):
Multi-level Wildcard: # (se suscribe a todos los hijos bajo esa cola)
Single Level Wildcard: + (se suscribe solo a ese nivel)
Un carácter de tema especial, el carácter dólar ($), excluye un tema de cualquier suscripción de root wild card. Normalmente, el $ se utiliza para transportar mensajes específicos del servidor o del sistema.
El éxito de un sistema de IoT depende enormemente de la arquitectura que diseñemos para la mensajería. En el caso de MQTT es esencial planear y organizar los Topic que vamos a emplear en el proyecto.
Es importante diseñar el sistema de Topics para que sea ampliable y mantenible. Queremos poder añadir más dispositivos a nuestra red o nuevas funcionalidades, y evitar darnos cuenta en el futuro de que el sistema que elegimos es insuficiente.
Mantener los Topic lo más pequeños y claros posible. Un topic debe dar la información clara del dato que publica. Es recomendable usar Topics lo más específicos posibles, evitando enviar mensajes a varios dispositivos y discriminar por el contenido del mensaje.
Emplear únicamente caracteres ASCII estándar en los topics, evitando caracteres especiales e incluso espacios. Esto hará más sencillo la interpretación de Topics desde los dispositivos, y la interoperabilidad entre lenguajes de programación y dispositivos.
En el caso de grandes estructuras de dispositivos o conectividad entre aplicaciones, el siguiente esquema de división de Topics funciona muy bien en múltiples aplicaciones:
protocol_prefix se usa para diferenciar entre diferentes protocolos/aplicaciones que se pueden usar al mismo tiempo
src_id es el ID del cliente mqtt que publica el mensaje. Se espera que sea el mismo que el «ID de cliente» que se usa para conectarse al broker MQTT. Permite un control rápido de ACL para verificar si el cliente puede publicar un tema específico.
dest_id es el ID de cliente de la unidad de «destino», es decir, a quién está destinado el mensaje. También permite un control rápido de ACL en el broker para determinar si el cliente puede suscribirse a un tema en particular. Puede haber topics de «destino» reservados para especificar que el mensaje se transmite a cualquier interesado. Por ejemplo el topic “todos”.
message_id es el ID real del mensaje dentro del protocolo utilizado. Por lo general, usa un valor numérico (como una cadena, por supuesto), porque el dispositivo IoT u otro sistema embebido que está conectado al broker MQTT puede tener otros enlaces de E/S y usar el mismo protocolo (pero con un marco de transporte diferente) para controlar el dispositivo utilizando estos otros enlaces de E/S. Usualmente usar ID de mensajes numéricos en tales enlaces de comunicación.
extra_properties es un subtema opcional que se puede utilizar para comunicar otra información adicional específica de MQTT (por ejemplo, pares clave=valor separados por comas). Un buen ejemplo sería informar la marca de tiempo del mensaje cuando realmente fue enviado por el cliente. En el caso de mensajes «retenidos», puede ayudar a identificar la relevancia del mensaje recibido. Con el protocolo MQTTv5, la necesidad de este subtema puede desaparecer porque habrá otra forma de comunicar propiedades adicionales.
En otros casos para dispositivos IoT que queramos controlar, el dispositivo (dev) podría suscribirse (sub) al tema de control y publicar (pub) al tema de estado.:
pub: clients/dev/dev_id/status
sub: clients/dev/dev_id/control
De esta manera, la lógica sub, pub es muy simple tanto para clientes como para dispositivos.
MQTT me permite gran escalabilidad. Añadir un nuevo Arduino o un suscriptor es muy sencillo dentro de la jerarquía vista
Con escalable me refiero a la capacidad que tiene un sistema para ser ampliado. Los sistemas de sensores en general, particularmente en nuestro caso hablamos del mundillo del Internet de las Cosas, se caracterizan por enviar muchos datos de pequeño tamaño en tiempo real ya que hay muchos sensores transmitiendo simultáneamente y cada breves periodos de tiempo, cuya información necesita ser consumida por otros elementos en tiempo real.
En una Arquitectura basada en Broker es fundamental evitar el SPOF (punto único de fallo).
En el contexto MQTT hay 2 estrategias principales:
Bridging: hace forward de mensajes a otro bróker MQTT. Es la solución de HiveMQ, Mosquitto, IBM MQ
Clustering: soportando el añadido dinámico de nodos al cluster. Lo usa ActiveMQ, HiveMQ o RabbitMQ.
Cuando un sistema de estas características se empieza a saturar se bloquean las comunicaciones y se pierde la característica de «tiempo real».
Hasta ahora, todos los sistemas que habíamos visto se basaban en un cliente que se comunicaba con un servidor. Si cualquier cliente se intenta comunicar con un servidor que está procesando tanta información que, en ese momento, no es capaz de trabajar con más contenido, el sistema entero fallará, o bien porque se satura y bloquea a nivel global o porque empieza a descartar aquella información que no puede procesar (lo que es inadmisible en muchos caso, imagina una alarma de Riesgo de Explosión en tu cocina porque se ha detectado una fuga de gas…).
Existen varias formas de abordar esta problemática pero, a día de hoy, una de las más empleadas es usar sistemas de colas donde se deja toda la información y el encargado de procesarla va «sacando» de esta cola la información. De esta manera, si ponemos más «encargados de procesamiento» son capaces de vaciar más rápido la cola si viésemos que está se está empezando a llenar y, de cara a los sensores, no sería necesario hacer ningún cambio, ya que ellos siempre envían al mismo sitio.
MQTT no hace exactamente lo mismo ya que, para empezar, no hay colas sino «topics» pero la filosofía es muy parecida, permitiendo a grandes sistemas operar con total fluidez y, junto con sus optimizaciones que buscan entre otras cosas reducir consumos y tamaños de trama para poder operar en elementos embebidos, es el motivo por el que es un protocolo tan empleado en comunicaciones M2M.
Además, nos permite una gestión de la seguridad razonablemente sencilla que facilita que nuestros sistemas se comporten de una forma más robusta.
MQTT será el nexo entre hardware (sensor) y todos los elementos típicos del mundo software (servidores, bases de datos, Big Data). En esta capa nos preocupamos de que la información llegue a un sistema que posteriormente se ocupa de distribuirlo entre las demás partes y nos da igual lo que haya a partir de ese momento y su tamaño. Puede que no tengamos nada más que una web de visualización o puede que tengamos un complejo sistema de Machine Learning y Big Data. Puede que seamos un particular enviando un dato de temperatura a un panel de visualización en su Raspberry o puede que seamos una multinacional que controla en tiempo real su producción de amoniaco a nivel global bajando y subiendo la carga de producción en sus diferentes fábricas según los costes de transporte y el consumo de sus diferentes centros de distribución. Nos es lo mismo a este nivel porque nosotros hacemos sólo una cosa y la hacemos bien: enviar datos de un dispositivo hardware a un sistema mucho mayor. Es lo que se llama microservicios que ha popularizado netflix (http://enmilocalfunciona.io/arquitectura-microservicios-1/)
Las cargas de la plataforma basada en MQTT aumentan en n al cuadrado. Por ejemplo, supongamos un escenario extremo en el que hay dos clientes en los que cada uno se suscribe a todos los temas posibles. Cuando un cliente publica un mensaje, el broker necesita recibir un mensaje y otro cliente también necesita recibir el mensaje. Esto significa que un mensaje enviado podría resultar en dos transmisiones. Lo mismo ocurre con el otro cliente, por lo que son cuatro mensajes en total para un sistema de dos clientes.
Para un sistema de tres clientes, este número se convierte en nueve mensajes en total (es decir, tres mensajes por cliente). El simple hecho de tener 10 dispositivos conectados significa que el intermediario de mensajes debe ser capaz de manejar 10*10 (es decir, 100 mensajes, etc.).
Cuando la cantidad de clientes MQTT comience a crecer, la carga en el broker de mensajes, el sistema general y la plataforma crecerán casi exponencialmente.
Siempre tener esto en cuenta cuando escale cualquier plataforma IoT que se base en MQTT en las etapas posteriores o agregue más dispositivos.
Protocolo MQTT
MQTT está diseñado para requerir una sobrecarga mínima del protocolo para cada paquete con el fin de preservar el ancho de banda para los dispositivos embebidos con recursos limitados. Es un marco de trabajo realmente sencillo para la gestión de redes mesh de dispositivos habilitados para TCP.
Los mensajes MQTT se entregan asincrónicamente («push») a través de la arquitectura publish subscribe. El protocolo MQTTT funciona intercambiando una serie de paquetes de control MQTT de una manera definida. Cada paquete de control tiene un propósito específico y cada bit del paquete se crea cuidadosamente para reducir los datos transmitidos a través de la red.
Una sesión MQTT se divide en cuatro etapas: conexión, autenticación, comunicación y terminación. Un cliente comienza creando una conexión TCP/IP con el broker utilizando un puerto estándar o un puerto personalizado definido por los operadores del broker. Al crear la conexión, es importante reconocer que el servidor puede continuar una sesión antigua si se le proporciona una identidad de cliente reutilizada.
Los puertos estándar son el 1883 para la comunicación no cifrada y el 8883 para la comunicación cifrada mediante SSL/TLS. Durante el handshake SSL/TLS, el cliente valida el certificado del servidor para autenticar el servidor.
MQTT es llamado un protocolo ligero porque todos sus mensajes tienen una pequeña huella de código. Cada mensaje consta de una cabecera fija, una cabecera variable opcional, una carga útil de mensaje limitada a 256 MB de información y un nivel de calidad de servicio (QoS).
MQTTT soporta BLOBS (Binary Large Object) de mensajes de hasta 256 MB de tamaño. El formato del contenido es específico de la aplicación. Las suscripciones de temas se realizan utilizando un par de paquetes SUBSCRIBE/SUBACK. La anulación de la suscripción se realiza de forma similar utilizando un par de paquetes UNSUBSCRIBE/UNSUBACK.
Durante la fase de comunicación, el cliente puede realizar operaciones de publicación, suscripción, cancelación (unsuscribe) y ping. La operación de publicación envía un bloque binario de datos, el contenido, a un topic definido por el publisher.
La operación de ping al servidor del broker usando una secuencia de paquetes PINGREQ/PINGRESP, que se usa para saber si está viva la conexión. Esta operación no tiene otra función que la de mantener una conexión en vivo y asegurar que la conexión TCP no ha sido apagada por una pasarela o un router.
Cuando un publicador o suscriptor desea finalizar una sesión MQTT, envía un mensaje DISCONNECT al broker y, a continuación, cierra la conexión. Esto se denomina “graceful shutdown” porque le da al cliente la posibilidad de volver a conectarse fácilmente al proporcionarle su identidad de cliente y reanudar el proceso donde lo dejó.
Si la desconexión ocurre repentinamente sin tiempo para que un publisher envíe un mensaje DISCONNECT, el broker puede enviar a los suscriptores un mensaje del publisher que el broker ha almacenado previamente en caché. El mensaje, que se llama testamento, proporciona a los suscriptores instrucciones sobre qué hacer si el editor muere inesperadamente.
MQTT tiene 14 tipos de mensajes, normalmente un usuario sólo usa los mensajes de CONNECT, PUBLISH, SUBSCRIBE Y UNSUBSCRIBE. Si queréis conocer los tipos de mensajes podéis consultarlos en: https://dzone.com/refcardz/getting-started-with-mqtt
El identificador de cliente (ClientId) identifica a cada cliente MQTT que se conecta a un broker MQTT. El broker usa el ClientID para identificar al cliente y el estado actual del cliente. Por lo tanto, este ID debe ser único por cliente y broker. En MQTT 3.1.1, puede enviar un ClientId vacío, si no necesita que el broker mantenga un estado. El ClientId vacío da como resultado una conexión sin ningún estado. En este caso, el indicador “clean session” debe establecerse en verdadero o el broke rechazará la conexión.
El parámetro de ClientId es muy importante cuando queremos tener persistencia en datos y que el cliente pueda recuperar datos no obtenidos mientras estaba desconectado, usado junto la QoS2.
Recordar que cada cliente que se conecte a un broker debe tener un ClientId diferente.
MQTT se ha convertido en un protocolo popular para conectar dispositivos de Internet de las cosas (IoT) a la nube. MQTT se desarrolló originalmente en 1999 para monitorear oleoductos y oleoductos a través de redes satelitales. En ese momento, la necesidad era un protocolo que fuera eficiente para dispositivos remotos con fuentes de energía limitadas, que tuviera un uso eficiente del ancho de banda y que pudiera operar a través de conexiones de red poco confiables. Cuando se desarrolló MQTT, el término IoT no se había acuñado, la computación en la nube no existía y el conjunto diverso de aplicaciones para IoT no había surgido.
Por estos motivos, era necesario actualizar el protocolo MQTT para abordar algunas de las características faltantes necesarias para alojar MQTT en plataformas en la nube a gran escala y para manejar aplicaciones IoT adicionales. En 2015/2016, se comenzó a trabajar dentro de OASIS en una nueva versión de la especificación, denominada MQTT 5. En marzo de 2019, MQTT 5 fue ratificado como estándar oficial de OASIS.
Mosquitto soporta MQTT V5
Hay 5 características clave que mejoran el manejo de errores, la escalabilidad y la flexibilidad del despliegue de los sistemas MQTT:
Sesión y caducidad del mensaje: MQTT 5 permite ahora que cada sesión y mensaje especifique un límite de tiempo. Si un mensaje no se entrega en un período de tiempo determinado, se borrará. Esto puede ser muy importante para los casos de uso crítico de seguridad si un mensaje necesita llegar dentro de un cierto período de tiempo.
Suscripciones compartidas: Las suscripciones compartidas permiten que varias instancias del cliente MQTT compartan las suscripciones del mismo tema de un broker MQTT. Esta característica es muy útil si un cliente MQTT ha sido configurado para transmitir datos MQTT en un sistema empresarial back-end, como una base de datos. Diferentes clientes MQTT que comparten las mismas suscripciones pueden ser desplegados a través de diferentes nodos del clúster para ayudar con la escalabilidad y la alta disponibilidad.
Reconocimientos negativos: Un broker MQTT que soporta MQTT 5 puede ahora enviar lo que se llama un acuse de recibo negativo para rechazar ciertos tipos de mensajes, tales como la máxima calidad de servicio, el tamaño máximo de los mensajes y las características no soportadas en el broker. El rechazo de un mensaje que excede el tamaño máximo del mensaje es útil para identificar a los clientes MQTT que podrían haberse convertido en maliciosos.
Indicadores de formato de carga útil (Payload): MQTT siempre ha sido agnóstico en cuanto a la carga útil, pero MQTT 5 ahora permite la adición de indicadores de formato de carga útil, valores binarios o texto. Esto facilitará el procesamiento del mensaje MQTT.
Propiedades del usuario: Además de los indicadores de formato de carga útil, los mensajes MQTT 5 pueden ahora incluir propiedades de usuario que añaden una propiedad clave-valor al encabezamiento del mensaje. Estas propiedades permiten que se añada información específica de la aplicación a cada cabecera de mensaje.
Non Local Publishing, si se usa esta opción el broker no mandará los mensajes del topic al que mandas si también estás suscrito. Es una opción de suscripción.
Suscripciones compartidas, se usar el topic reservado $SHARE y se usa para balanceo de carga, de forma que los clientes suscritos a ese topic compartido no lo reciben todos sino de forma alternativa: http://www.steves-internet-guide.com/mqttv5-shared-subscriptions/
Reason Codes en todos los mensajes de ACK excepto PINGRESP
Al enviar mensajes MQTT existe la posibilidad de que los mensajes no lleguen al destinatario.
El envío de mensajes sin saber con seguridad que fueron recibidos se llama «QoS 0» (cero).
Es posible que también desee QoS 1, que le permite saber que el mensaje fue recibido. Básicamente, después de cada publicación, el suscriptor dice «OK». En el lenguaje MQTT se llama «PUBACK» (Reconocimiento de publicación).
También está QoS 2, que no sólo garantiza que su mensaje fue recibido, sino que sólo fue recibido una vez. Esto es un poco más complejo porque necesitas empezar a rastrear los IDs de los paquetes, así que lo dejaremos para más adelante.
Usar un nivel u otro depende de las características y necesidades de fiabilidad de nuestro sistema. Lógicamente, un nivel de QoS superior requiere un mayor intercambio mayor de mensajes de verificación con el cliente y, por tanto, mayor carga al sistema.
Los niveles de calidad de servicio (QoS) determinan cómo se entrega cada mensaje MQTT y deben especificarse para cada mensaje enviado a través de MQTT. Es importante elegir el valor de QoS adecuado para cada mensaje, ya que este valor determina la forma en que el cliente y el servidor se comunican para entregar el mensaje. Con el uso de MQTT se podrían lograr tres niveles de calidad de servicio para la entrega de mensajes:
QoS 0 (A lo sumo una vez – at most once) – donde los mensajes se entregan de acuerdo con los mejores esfuerzos del entorno operativo. Puede haber pérdida de mensajes. Confía en la fiabilidad del TCP. No se hacen retransmisiones.
QoS 1 (Al menos una vez – at least once) – donde se asegura que los mensajes lleguen, pero se pueden producir duplicados. El Receiver recibe el mensaje por lo menos una vez. Si el receiver no confirma la recepción del mensaje o se pierde en el camino el sender reenvía el mensaje hasta que recibe por lo menos una confirmación. Pueden duplicarse mensajes.
QoS 2 (Exactamente una vez – exactly once) – donde se asegura que el mensaje llegue exactamente una vez. Eso incrementa la sobrecarga en la comunicación pero es la mejor opción cuando la duplicación de un mensaje no es aceptable.
Existe una regla simple cuando se considera el impacto del rendimiento de la QoS. Es «Cuanto mayor sea la QoS, menor será el rendimiento«. MQTT proporciona flexibilidad a los dispositivos de IoT para elegir la calidad de servicio apropiada que necesitarían para sus requisitos funcionales y ambientales.
Para que el broker mantenga/retenga los mensajes publicados para el cliente, si este está momentáneamente desconectado, ocurre cuando un mensaje es publicado con QoS 1 o 2 y el cliente que recibe comple estas condiciones:
Conectado con clean session a falso
Suscrito con QoS 1 o 2
Desde la V5 de MQTT se puede establecer un expiry interval para que no se retengan los mensajes de forma indefinida en el broker.
Cuando habla de QoS en MQTT, deben considerar los dos lados de la entrega de mensajes:
Envío de mensajes desde el cliente de publicación al broker.
Entrega de mensajes del broker al cliente suscriptor.
Examinaremos los dos lados de la entrega del mensaje por separado porque existen diferencias sutiles entre los dos. El cliente que publica el mensaje para el broker define el nivel de QoS del mensaje cuando envía el mensaje al broker. El broker transmite este mensaje a los clientes suscriptores utilizando el nivel de calidad del servicio que cada cliente suscriptor define durante el proceso de suscripción. Si el cliente suscriptor define una QoS más baja que el cliente de publicación, el broker transmite el mensaje con la calidad de servicio más baja.
Todos los mensajes enviados con QoS 1 y 2 se ponen en cola para clientes sin conexión hasta que el cliente vuelve a estar disponible. Sin embargo, esta cola solo es posible si el cliente tiene una sesión persistente. Solo el cliente puede solicitar una sesión persistente cuando se conecta al broker (clean session es false)
Las sesiones persistentes guardan toda la información relevante para el cliente en el broker. El ID de cliente que proporciona el cliente cuando establece la conexión con el broker identifica la sesión.
En una sesión persistente, el broker almacena la siguiente información (incluso si el cliente está fuera de línea). Cuando el cliente se vuelve a conectar, la información está disponible de inmediato.
Existencia de una sesión (incluso si no hay suscripciones).
Todas las suscripciones del cliente.
Todos los mensajes en un flujo de calidad de servicio (QoS) 1 o 2 que el cliente aún no ha confirmado.
Todos los mensajes nuevos de QoS 1 o 2 que el cliente perdió mientras estaba desconectado.
Todos los mensajes de QoS 2 recibidos del cliente que aún no se han reconocido por completo.
Cuando el cliente se conecta al broker, puede solicitar una sesión persistente. El cliente usa un indicador cleanSession para decirle al intermediario qué tipo de sesión necesita.
Cuando el indicador de cleanSession se establece en falso, el broker crea una sesión persistente para el cliente. Toda la información y los mensajes se conservan hasta la próxima vez que el cliente solicite una sesión limpia. Si el indicador de sesión limpia se establece en falso y el broker ya tiene una sesión disponible para el cliente, utiliza la sesión existente y entrega los mensajes previamente en cola al cliente.
Al igual que el broker, cada cliente MQTT también debe almacenar una sesión persistente. Cuando un cliente solicita al servidor que contenga datos de sesión, el cliente es responsable de almacenar la siguiente información:
Todos los mensajes en un flujo de QoS 1 o 2, que aún no han sido confirmados por el broker.
Todos los mensajes de QoS 2 recibidos del intermediario que aún no se han reconocido por completo.
Por lo tanto para que haya una persistencia lo debe solicitar el suscriptor y el publicador debe mandar con una QoS 1 o 2.
Un cliente puede establecer un mensaje Last Will and Testament (LWT) en el momento en el que se conecta con el Broker MQTT. Si el cliente no desconecta correctamente el Broker envía el mensaje LWT.
Cuando un cliente MQTT se conecta al servidor MQTT puede definir un tema y un mensaje que necesita ser publicado automáticamente sobre ese tema cuando se desconecta inesperadamente. Esto también se llama «Ultima voluntad y testamento» (LWT). Cuando el cliente se desconecta inesperadamente, el temporizador keep alive del lado del servidor detecta que el cliente no ha enviado ningún mensaje o el PINGREQ keep alive. Por lo tanto, el servidor publica inmediatamente el mensaje Will en el tema Will especificado por el cliente.
La función LWT puede ser útil en algunos escenarios. Por ejemplo, para un cliente MQTT remoto, esta función se puede utilizar para detectar cuando los dispositivos IoT salen de la red. La función LWT se puede utilizar para crear notificaciones para una aplicación que esté supervisando la actividad del cliente.
Cada mensaje MQTT puede ser enviado como un mensaje con retención (retained), en este caso cada nuevo cliente que conecta a un topic recibirá el último mensaje retenido de ese tópico.
Normalmente, si se envía un mensaje sobre un topic y nadie está suscrito a ese tema, el mensaje es simplemente descartado por el broker. Sin embargo, el publisher puede decirle al broker que mantenga el último mensaje en ese tema fijando el indicador de mensaje retenido.
Esto puede ser muy útil, como por ejemplo, si tiene un sensor que publica su estado sólo cuando se cambia, por ejemplo, el sensor de puerta. ¿Qué sucede si un nuevo suscriptor se suscribe a este estado?. Sin los mensajes retenidos, el suscriptor tendría que esperar a que el estado cambie antes de recibir un mensaje, sin embargo, con el mensaje retenido, el suscriptor vería el estado actual del sensor.
Lo que es importante entender es que sólo se retiene un mensaje por topic, el siguiente mensaje publicado sobre ese tema reemplaza al último mensaje retenido para ese tema.
NOTA: Si no usas clean sessions, entonces podrías ver mensajes que han sido almacenados pero no retenidos.
Cada mensaje MQTT puede ser enviado como un mensaje con retención (retained), en este caso cada nuevo cliente que conecta a un topic recibirá el último mensaje retenido de ese tópico.
Cuando un cliente conecta con el Broker puede solicitar que la sesión sea persistente (clean session = false), en ese caso el Broker almacena todas las suscripciones del cliente, todos los mensajes QoS 1 y 2 no procesados o perdidos por el cliente
Un mensaje MQTT CONNECT contiene un valor keepAlive en segundos donde el cliente establece el máximo tiempo de espera entre intercambio de mensajes
Seguridad MQTT
Ya sabemos lo importante que es la seguridad, y más en escenarios IoT en el que comunican objetos entre sí. MQTT confía en tecnologías estándares para esto:
Autenticación usuario/Password
Seguridad SSL/TLS
ACLs
Los puertos estándar son el 1883 para la comunicación no cifrada y el 8883 para la comunicación cifrada mediante SSL/TLS. Durante el handshake SSL/TLS, el cliente valida el certificado del servidor para autenticar el servidor. El cliente también puede proporcionar un certificado de cliente al broker durante el handshake, que el broker puede utilizar para autenticar al cliente. Aunque no forma parte específica de la especificación MQTT, se ha convertido en habitual que los broker admitan la autenticación de clientes con certificados SSL/TLS del lado del cliente.
Dado que el protocolo MQTTT pretende ser un protocolo para dispositivos con recursos limitados y de IoT, el SSL/TLS puede no ser siempre una opción y, en algunos casos, puede no ser deseable. En estos casos, la autenticación se presenta como un nombre de usuario y contraseña de texto claro que el cliente envía al servidor como parte de la secuencia de paquetes CONNECT/CONNNACK. Algunos brokers, especialmente los brokers abiertos publicados en Internet, aceptan clientes anónimos. En tales casos, el nombre de usuario y la contraseña simplemente se dejan en blanco.
Reto MQTT: Seguridad, Interoperabilidad y Autenticación
Debido a que el protocolo MQTT no fue diseñado con la seguridad en mente, el protocolo ha sido tradicionalmente utilizado en redes back-end seguras para propósitos específicos de la aplicación. La estructura temática de MQTT puede fácilmente formar un árbol enorme, y no hay una manera clara de dividir un árbol en dominios lógicos más pequeños que puedan ser federados. Esto dificulta la creación de una red MQTT globalmente escalable porque, a medida que crece el tamaño del árbol temático, aumenta la complejidad.
Otro aspecto negativo de MQTT es su falta de interoperabilidad. Debido a que las cargas útiles de mensajes son binarias, sin información sobre cómo están codificadas (sin metadatos), pueden surgir problemas, especialmente en arquitecturas abiertas en las que se supone que las diferentes aplicaciones de los diferentes fabricantes funcionan a la perfección entre sí.
MQTT tiene características de autenticación mínimas incorporadas en el protocolo. El nombre de usuario y las contraseñas se envían en texto claro y cualquier forma de uso seguro de MQTT debe emplear SSL/TLS, que, lamentablemente, no es un protocolo ligero.
Autenticar clientes con certificados del lado del cliente no es un proceso simple, y no hay manera en MQTT, excepto el uso de medios propietarios fuera de banda, para controlar quién posee un topic y quién puede publicar información sobre él. Esto hace que sea muy fácil inyectar mensajes dañinos, ya sea intencionadamente o por error, en la red.
Además, no hay forma de que el receptor del mensaje sepa quién envió el mensaje original a menos que esa información esté contenida en el mensaje real. Las características de seguridad que tienen que ser implementadas sobre MQTT de forma propietaria aumentan la huella de código (footprint) y hacen que las implementaciones sean más difíciles.
Ventajas MQTT
Son varias las ventajas del protocolo MQTT como sistema de comunicación IoT. Por un lado, tenemos todas las ventajas del patrón pub/sub como son escalabilidad, asincronismo y desacoplamiento entre clientes.
Además, MQTT aporta una serie de características que le han hecho sobresalir sobre otros competidores.:
Sencillez y ligereza. Esto lo hace adecuado para aplicaciones IoT, donde frecuentemente se emplean dispositivos de escasa potencia.
Menor necesidad de recursos se traduce en un menor consumo de energía, lo cual es interesante en dispositivos que funcionan 24/7 y muy especialmente en dispositivos alimentados por batería.
Requiere un ancho de banda mínimo, lo cual es importante en redes inalámbricas, o conexiones con posibles problemas de calidad.
Medidas adicionales importantes, como la seguridad y calidad del servicio (QoS).
Es una solución largamente testada y consolidada, que aporta robustez y fiabilidad.
Clientes MQTT
Existen muchos clientes y librerías para MQTT, puesto que se trata de un protocolo libre sencillo de implementar.
Una aplicación de cliente MQTT se encarga de recopilar información del dispositivo de telemetría, conectar con el servidor y publicar la información en el servidor. También puede suscribirse a temas, recibir publicaciones y controlar el dispositivo de telemetría.
MQTT Explorer es un cliente MQTT integral que proporciona una descripción general estructurada de sus topics MQTT y hace que trabajar con dispositivos/servicios en su broker sea muy simple.
MQTT-spy es una utilidad de código abierto destinada a ayudarle a monitorear la actividad sobre temas de MQTTT. Ha sido diseñado para tratar con grandes volúmenes de mensajes, así como con publicaciones ocasionales.
mqtt-spy es probablemente una de las utilidades de código abierto más avanzadas para publicar y monitorear actividades sobre temas de MQTT. Está dirigido a dos grupos de usuarios:
Innovadores que necesitan una herramienta para crear prototipos de IO o proyectos de integración
Usuarios avanzados que necesitan una utilidad avanzada para sus entornos de trabajo
Cliente MQTT python que está disponible en python. El proyecto Eclipse Paho proporciona implementaciones de cliente de código abierto de los protocolos de mensajería MQTT y MQTT-SN destinados a aplicaciones nuevas, existentes y emergentes para Internet de las cosas (IoT).
El cliente python de paho es asíncrono, lo que significa que si lanzo un script y finaliza antes de publicar o recibir fallará. Para ello se debe usar los loops y las funciones de callback
MQTT ha surgido como un protocolo de mensajería estándar para la IoT. Se puede utilizar en redes TCP/IP y es muy ligero. La norma sigue un modelo de publicación-suscripción («pub/sub»).
Como habrás imaginado, para conseguir una comunicación MQTT, emplearemos una librería. Existen muchas disponibles gracias a la gran (tanto en tamaño como en calidad) comunidad que existe alrededor de Arduino.
Una de las librerías más conocidas y la más estable y flexible es Arduino Client for MQTT http://pubsubclient.knolleary.net/ que nos provee de un sencillo cliente que nos permite tanto subscribirnos como publicar contenido usando MQTT. Internamente, usa la API de Arduino Ethernet Client lo que lo hace compatible con un gran número de shields y placas.
Un Gateway IoT es un dispositivo físico o un programa de software que sirve como punto de conexión entre la nube y los controladores, sensores y dispositivos inteligentes. Todos los datos que se mueven a la nube, o viceversa, pasan por el gateway, que puede ser un dispositivo de hardware dedicado o un programa de software. Un gateway IoT también puede denominarse pasarela inteligente o nivel de control.
Algunos sensores generan decenas de miles de puntos de datos por segundo. Una pasarela proporciona un lugar para preprocesar esos datos localmente en el borde antes de enviarlos a la nube. Cuando los datos se agregan, se resumen y se analizan tácticamente en el borde, se minimiza el volumen de datos que deben ser enviados a la nube, lo que puede tener un gran impacto en los tiempos de respuesta y en los costes de transmisión de la red.
En contraposición con la infraestructura cloud tradicional, basada en grandes centros de datos que centralizan el poder computacional, otros paradigmas como Fog Computing proponen la distribución de esta capacidad de cómputo hacia los extremos de la red. Este paradigma busca solventar los problemas de comunicación de datos entre los dispositivos generadores y consumidores de los mismos al acercar los centros de procesado y análisis de datos hacia ellos, reduciendo de esta forma la latencia y el uso de la infraestructura de red.
Se habla de Edge Computing en referencia a una infraestructura, que se puede entender como un caso específico de Fog Computing. Un escenario típico puede ser el caso de uso de Internet of Things (IoT) en el que los nodos de computación se necesitan estar físicamente cerca de las fuentes de datos, como un robot industrial o un sensor de presión de un tanque de combustible o un indicador de consumo de la red eléctrica. En general se puede definir un nodo de computación Edge como un hardware con capacidad de cómputo situado físicamente cerca de los dispositivos o equipos que hacen uso de sus recursos, bien sea en la propia maquinaria, en una planta de producción o en un almacén.
Otra ventaja de una pasarela de IoT es que puede proporcionar seguridad adicional para la red de IoT y los datos que transporta. Dado que el gateway gestiona información que se mueve en ambas direcciones, puede proteger los datos que se mueven hacia la nube de fugas y dispositivos de IoT de ser comprometidos por ataques externos maliciosos con características tales como detección de manipulaciones, cifrado, generadores de números aleatorios de hardware y motores de cifrado.
La pasarela IoT desempeña un papel importante en la gestión de los dispositivos. Cada dispositivo (sensor/actuador) tiene un caso de uso diferente y emite mensajes a través de diferentes canales como Wifi, BLE, Zigbee, Ethernet, RF, LPWAN, LTE, etc. y el gateway realiza varias funciones como conectividad de dispositivos, traducción de protocolos, agregación, filtrado, correlación, seguridad, actualizaciones, administración y más. Se sitúa entre los dispositivos y la plataforma de nube.
Además un Gateway puede hacer conexión VPN segura entre localizaciones diferentes, permitiendo unir de forma segura diferentes puntos a través de Internet.
Hace no tantos años la conexión remota era por módem o por GSM con conexiones pto a pto. En la actualidad usamos internet para el telecontrol, pero es un problema el tema de la seguridad. Ya existen dispositivos como el router industrial eWON Flexy https://ewon.biz/es/productos/flexy modular que es servidor OPC UA y cliente openvpn, es muy potente para conectar y dar funcionalidades adicionales a unos autómatas.
eWON monta la VPN y al ser servidor modbus TCP y OPC UA, es posible acceder remotamente y de forma segura a los datos del autómata e integrarlo con datos de otras localizaciones.
Los gateways industriales permite la traducción de protocolos típicamente industriales como Modbus RTU/ASCII/TCP a PROFINET o PROFIBUS a protocolos de Internet como HTTP o MQTT, permitiendo actualizar los dispositivos industriales a los nuevos protocolos de comunicación en Internet.
Los gateways de IIoT o «nube» se distinguen por su énfasis en servir datos de dispositivos hasta una nube u otros componentes de la Internet industrial. Los factores diferenciadores incluyen el uso de un microprocesador y un sistema operativo estándar, como la plataforma Intel IoT, así como el soporte de APIs de Transferencia de Estado Representacional (REST), Transporte de Telemetría de Colas de Mensajes (MQTT), y otros protocolos de integración y transporte de datos de la IoT. También se puede utilizar para este fin la OPC UA (Arquitectura Unificada).
Estos gateways también pueden añadir una capa adicional de seguridad con el uso de VPNs u otras comunicaciones seguras.
Un Edge Gateway se encuentra en la intersección de los sistemas de borde (edge), entre la Internet externa y la intranet local que está siendo utilizada por los otros dispositivos de su ecosistema. Por lo tanto, es el punto de acceso clave para la conectividad de red, tanto dentro como fuera del ecosistema de dispositivos.
Existen tres principios fundamentales de la seguridad: confidencialidad, integridad y disponibilidad. Deberá asegurarse de que todas las comunicaciones entre el gateway y los dispositivos cumplen cada uno de los tres principios mientras se produce la comunicación en las redes internas y externas.
También vale la pena señalar que la puerta de enlace es a menudo la primera en ser atacada por dos razones:
Tiene una mayor potencia de procesamiento, que puede utilizar para ejecutar aplicaciones más intensivas. Más potencia significa mejor software, pero mejor software significa más vulnerabilidades para que un hacker las explote.
Debido a su ubicación como dispositivo Edge entre Internet e Intranet, el gateway es el punto de entrada de cualquier vector de amenaza (así como la primera línea de defensa del sistema).
Las recomendaciones sobre la seguridad de un dispositivo de pasarela de la IoT constan de tres pasos.
Identidad para el dispositivo Gateway. Dar al gateway una identidad (utilizando un certificado digital X.509).
Habilitar la identidad «sólida» para el dispositivo Gateway
Utilizar el Gateway para proporcionar identidad a su ecosistema
Aprendiendo Arduino 