MQTT: comunicación en el Internet de las Cosas

Conexiones directas vía TCP/IP

La mayoría de los dispositivos finales en el Internet de las Cosas carecen de una dirección IP pública. Como un teléfono sin un número propio, pueden hacer llamadas a otros dispositivos, pero ellos mismos no pueden recibirlas. Cuando sí pueden, con frecuenta el tráfico de datos entrante es filtrado por un cortafuegos. En la mayoría de los casos no es posible establecer una conexión directa a nivel superior de red entre dos dispositivos finales.

Cuando es posible llamar directamente a un dispositivo del IdC se producen problemas relacionados con la seguridad de los datos. No sin razón se oye cada vez más hablar de las botnet que se expanden a través de routers o cámaras IP con Firmware anticuados. No todos los diseñadores de un nuevo y atractivo gadget trabajan con la meticulosidad deseada y no todos los usuarios son conscientes de su responsabilidad como administradores.

Nubes para el IdC: un principio basado en datos

Una posible solución la ofrecen las nubes para el IdC. Estas constituyen una memoria central de datos de Internet puestas a disposición por proveedores como Google, SalesForce o IBM. Los clientes de Wiesemann & Theis también disponen gratuitamente de la nube de W&T.

Los dispositivos terminales se conectan con los servidores del proveedor de la nube para cargar o descargar desde allí sus datos. Software independientes como ThinkSpeak ofrecen la posibilidad de configurar un servidor de nube también en la propia red y guardar allí los datos.

Las nubes trabajan en base a datos. A menudo están equipadas con frontends de la web para visualizar datos de medición y estados de contadores. El acceso para M2M a datos individuales y series temporales se realiza normalmente a través de interfaces REST específicas de las plataformas. Está creciendo una oferta por parte de los proveedores de nubes de procedimientos de acceso basados en la comunicación. Así, por ejemplo, IBM BlueMix, Microsoft Azure y Xively son compatibles con el protocolo MQTT para el IdC.

MQTT: el principio basado en la comunicación

Interrupciones de la conexión en el suscriptor:

Al establecer la conexión, un suscriptor puede indicar si desea una sesión duradera (Persistent Session). En ese caso, el intermediario guarda de forma intermedia los tópicos abonados por ese usuario. Si se produce una interrupción de la conexión, guarda todos los mensajes cuya recepción tenga que ser confirmada por el suscriptor. La necesidad de una confirmación se define a través de la calidad del servicio (Quality of Service, o abreviado: QoS) de un mensaje. Un mensaje con una calidad de servicio QoS0 se entrega "máximo una vez" y, por lo tanto, es eliminado si el suscriptor no está localizable. Un mensaje con una calidad de servicio QoS1 es entregado tantas veces como sea necesario hasta que el suscriptor confirma el recibo. Una calidad de servicio QoS2 garantiza que el suscriptor reciba el mensaje exactamente una vez.

Interrupciones de la conexión en el publicador:

En su "última voluntad", al establecer la conexión un publicador (publisher) indica al intermediario (broker) qué mensajes deben ser enviados al suscriptor (subscriber) en caso de una súbita interrupción de la conexión. Cada publicador dispone exactamente de una última voluntad.

Su un publicador envía un mensaje con la etiqueta Retained, el intermediario guarda ese mensaje de forma intermedia para un tópico. Ese mensaje será enviado, por un lado, a los suscriptores que se abonen a ese tópico y, por otro lado, a los suscriptores con la calidad de servicio 1 que aún no hayan enviado confirmación de recibo. Una aplicación como ejemplo es la transmisión de una última medición de un sensor de temperatura. Para cada tópico se puede reservar exactamente un mensaje.

Comunicación segura:

MQTT utiliza la autenticación de los clientes por nombre de usuario y contraseña. De ese modo se puede asignar autorizaciones en el lado del intermediario y garantizar, por ejemplo, que solo el sensor de temperatura local pueda publicar mensajes con el tópico f2/kuehlthekte/temp. El nombre de usuario y la contraseña se transfieren al establecer la conexión y se transmiten sin codificar. Por esa razón, conviene codificar toda comunicación por MQTT desde el principio. El protocolo se encuentra en las capas superiores del modelo OSI, por lo que es muy sencillo realizar la codificación con TLS, siempre y cuando el terminal respectivo disponga de los recursos necesarios para ello.

Universal y portátil

MQTT no solo tiene una estructura básica muy sencilla, también ofrece muchas libertades para organizar los tópicos y no hace ninguna especificación respecto al contenido de Playload. Por lo tanto, MQTT es un protocolo muy genérico y con múltiples aplicaciones. Tampoco impone casi ninguna restricción al elegir el intermediario: estos están disponibles como software independiente o de proveedores comerciales establecidos, como servicio en la web o como appliance de hardware. Una aplicación que utilice MQTT para la comunicación funciona como cualquier otro intermediario de MQTT. Esto garantiza la posibilidad de cambiar de plataforma en todo momento y sin mucho esfuerzo.

Pruébelo usted mismo

¿Tiene alguna pregunta sobre Web-IO Digital o MQTT?

El Sr. Thiel le atenderá con mucho gusto.
Teléfono: +49 202/2680-110 (lu-vi de 8-17 horas)
E-mail: f.thiel@wut.de