Research design

MQTT es un protocolo ligero, asincrono y esta basado en la publicación/suscripción de mensajes a un broker (intermediario), figura 34, sigue el modelo de los subject-based systems. Está diseñado para ser: abierto, simple, ligero y fácil de implementar. Sus características lo hacen ideal para: redes de poco ancho de banda y poco fiables y para dispositivos empotrados con recursos de memoria y procesamiento limitados (Requena, 2014), para paradigmas emergenes como M2M, el IoT, las aplicaciones móviles y las redes de sensores. MQTT opera sobre redes TCP/IP. Consecuentemente, este protocolo no puede ser ejecutado directamente sobre una red de sensores ya que estas no tienen porque estar adaptadas a las redes TCP/IP y generalmente tienen su propia pila de protocolos. Para resolver este problema IBM desarrolló MQTT-SN (AS Stanford & Linh, 2013) como una extensión de MQTT adaptada a las peculiaridades de una red de sensores.

Figura  34.  Arquitectura  de  MQTT.  Fuente:  (Al-Fuqaha, Mohsen Guizani, & Mehdi Mohammadi, 2015)  

MQTT fue originado en la década de los 90, dentro del sector industrial. Las compañías buscaban una tecnología ligera y con un alto grado de adaptabilidad a la hora de ejecutarse sobre sistemas y dispositivos con recursos limitados, que permitiera monitorizar los sistemas industrials y mecánicos que tenían en sus fábricas. Para dar solución al sector industrial, IBM con Andy Stanford-Clark y otros colaboradores, uno de ellos Arcom (ahora Eurotech) con Arlen Nipper en 1999 introdujeron el Protocolo MQTT y este fue estandarizado en 2013 por OASIS (Locke, 2010).

Este protocolo ha sido seleccionado recientemente por OASIS - Open Standards for the Information Society (es un consorcio de empresas cuyo cometido es guiar el desarrollo, la convergencia y la adopción de estádares abiertos con el objetivo

de globalizar la sociedad de la información), como uno de los protocolos destinados a soportar el paradigma del IoT y por ende, las Smart Cities. Además de esto, desde que IBM libera la especificación de este protocolo, su uso a crecido paulatinamente, llegando a estar en auge en la actualidad. En este aspecto cabe destacar la contribución del Eclipse Paho Project, un proyecto que está en continuo desarrollo por la fundación Eclipse, cuyo objetico es implementar clientes MQTT en varios lenguajes de programación, como Java, C o JavaScript, y que publico su primera versión de las librerías MQTT en Junio de 2014 (Requena, 2014). MQTT tiene como objetivo conectar dispositivos y redes integrados con aplicaciones y middleware. La operación de conexión utiliza un mecanismo de enrutamiento (uno-a-uno, uno-a-muchos, muchos-a-muchos) y habilita a MQTT como un protocolo de conexión óptima para el IoT y M2M.

Como ya se mencionó es un protocolo ligero usado para la comunicación máquina a máquina (M2M) en el IoT (Internet of Things) ya que los clientes son pequeños y utiliza el ancho de banda de red de forma eficiente, facilitando ser utilizado en la mayoría de los dispositivos empotrados con pocos recursos. La cabecera de longitud fija tiene sólo 2 bytes de longitud y se minimizan los intercambios de protocolo para reducir el tráfico en la red. Se ejecuta sobre TCP/IP, que proporciona conectividad de red básica. No depende en modo alguno del contenido del mensaje. Da soporte a la entrega asegurada y a transferencias 'dispara y olvida', como es un protocolo de publicación/suscripción la entrega de mensajes es independiente de la aplicación. La entrega es desacoplada liberando a la aplicación de tener que estar conectada a un servidor y esperando mensajes. El modelo de interacción es como en el correo electrónico, pero optimizado para la programación de aplicaciones.

La entrega de mensajes puede ser de tres tipos: como máximo una vez (fire-and- forget), los mensajes se entregan en base a la carga de la red, se puede producir pérdida de mensajes. Ejemplo, mensaje emitido por un sensor ambiente en el que no importa si una lectura individual se pierde ya que instantes después se publicará un nuevo valor; al menos una vez (no confinable), se asegura que los mensajes llegan, pero se pueden producir duplicados; exactamente una vez (at least once), se asegura que los mensajes llegan exactamente una sola vez. Este nivel de utilización es necesario en sistemas de facturación de billetes, contaje, etc. Además, dispone de una función que notifica a los suscriptores si se produce una desconexión de un cliente de un servidor MQTT (Locke, 2010).

hace de servidor o “broker” con una capacidad de hasta 10.000 clientes. El broker es el encargado de gestionar la red y de transmitir los mensajes, para mantener activo el canal, los clientes envian periódicamente un paquete (PINGREQ) y esperan la respuesta del broker (PINGRESP). La comunicación puede ser cifrada entre otras muchas opciones.

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. Un “topic” se representa mediante una cadena y tiene una estructura jerárquica. Cada jerarquía se separa con ‘/’. De esta forma un nodo puede suscribirse a un “topic” concreto o a varios, figura 35.

Figura  35.  Proceso  de  publicación  /  suscripción  utilizado  por  MQTT.  Fuente:  (Locke, 2010)  

A continuación en la tabla 5 (se presenta en dos partes), se muestra una comparación entre los protocolos de aplicación presentados en presente capítulo.

HTTP UPnP CoAP SOAP

Estándar

Estandarizado por la IETF en los RFCs 1945, 2616, 2774 y 7540. El más importante 2616. Libre de derechos de autor

Conjunto de estandares abiertos y tecnologías. UPnP Forum. World Wide Web Consortium.

Modelo Petición o Solicitud/Respuesta Plug and play

Petición o Solicitud/Respuesta. Arquitectura Cliente/Servidor, similar al de HTTP. Seguridad

Media. Segura con SSL. Muy vulnerable si no usa certificados de seguridad, son costosos Ninguna. No implementa ningún tipo de autenticación o de seguridad. Opcional en la capa de transporte, Seguridad DTLS. Permite Autenticacion.

Flexibilidad Flexible. nuevos métodos, que añaden Permite añadir nuevas funcionalidades.

Flexible. Se adapta a cualquier red y

protocolo. Flexible.

HTTP UPnP CoAP SOAP Sobrecarga

Alta. Cabeceras muy largas y de texto plano, sin comprensión. En la versión 2, añade compresión. Baja. Encabezados pequeños, simplifica la cabecera HTTP. Media. Websockets

Soporta IoT Si. HTTP RESET si.

Si. Diseñado para trabajar en dispositivos electrónicos muy simples y con recursos limitados.

S. Protocolo lento.

Escalabilidad Alta Alta. independencia Por del la medio y dispositivos. Alta. Puede ser utilizado para formar protocolos más complejos. XMPP AMQP MQTT Estándar

Estandarizado por la IETF en los RFCs 6120 y 6121. Libre de derechos de autor, Estándar abierto.

Estándar abierto

En proceso de estandarización por el OASIS (MQTT) Technical Committee. Libre de derechos de autor desde que IBM liberó su especificación

Modelo Petición o Solicitud/Respuesta y Publicación/Suscripción. Arquitectura Cliente/Servidor

Publicación/Suscripci

ón Publicación/Suscripción Seguridad Fuerte. Incorporada SASL y TLS.

Alta. Autenticación y/o cifrado basado en SASL y TLS.

Media. Autenticación de cliente y conexión segura con SSL. La conexión puede ser cifrada usando SSL/TLS.

Flexibilidad

Flexible. Admite Extensiones para añadir nuevas funcionalidades o para adaptar el protocolo a nuevas tecnologías. Las desarrolla XSF (XMPP Standards Foundation), o cualquier organización o proyeto individual de Software, p.e. Google+.

No Flexible. Se requiere una nueva versión del protocolo para añadir una funcionalidad.

QoS No soportada. Soportada. Tres (3) _tipos. Soportada. Tres (3) tipos. Sobrecarga

Alta. XMPP está basado en procesamiento de texto y esto produce una sobrecarga en la red y un gasto alto en recursos de cómputo.

Media.

Muy baja. La cabecera corta de los mensajes tan solo ocupa 2 bytes. En general es un protocolo muy ligero que introduce una sobre carga mínima en la red.

Websockets Si Si

Soporta IoT

Si. En principio sería un protocolo demasiado pesado debido a que está basado en XML y no se adaptaría bién a los dispositivos empotrados. Pero la capacidad de permitir extensiones hacen que se pueda adaptar.

Si.

Si. Debido a sus características, MQTT es un protocolo ideal para los requisitos que impone el IoT.

Escalabilidad Alta. P.e. La aplicación Whatsapp

Alta. Por lo general, depende de la calidad de los nodos servidores y de la topología que usen. P.e. El chat de Facebook

Tabla  5.  Comparación  entre  los  protocolos  de  aplicación  presentados.  Fuente:  Autora.  

La tabla 5, permite ver las características de los protocolos de aplicación presentados y que son utilizados en aplicaciones IoT, cada protocolo tiene unas

características propias y depende de la aplicación y el desarrollo su utilización, no se puede definir cual es el protocolo más adecuado para cualquier desarrollo IoT. Por ejemplo para un desarrollo que requiera una seguridad fuerte, alta escabilidad y flexibilidad, seguramente el protocolo más adecuado será XMPP.

Para esta tesis de investigación y el prototipo propuesto, el protocolo que cumple en mayor grado las características necesarias es MQTT. Sus características lo hacen ideal para entornos IoT, una sobrecarga muy baja (la cabecera tiene tan solo dos bytes), es muy liviano, es un estandar abierto, ha sido probado en la industria y el control y automatización de hogares (domótica), etc, según algunos autores es el protocolo más utilizado para aplicaciones IoT, después de HTTP- RESET y a partir de que IBM liberó su especificación, se ha vuelto muy popular.

7.7.1 Broker para MQTT

El broker es la pieza clave de los sistemas basados en la publicación/suscripción de eventos y por ende, en los sistemas que utilizan MQTT, en la tabla 6, se muestra una comparción entre los brokers MQTT más utilizados actualmente.

Broker QoS

0 QoS 1 QoS 2 Auth Puente SSL Dinámicos Topics Websockets

Mosquitto SI SI SI SI SI SI SI NO RSMB SI SI SI SI SI NO SI NO WebSphere MQ SI SI SI SI SI SI SI ? HiveMQ SI SI SI SI NO SI SI SI Apache Apollo SI SI SI SI NO SI SI SI Apache ActiveMQ SI SI SI ? ? ? ? SI RabbitMQ SI SI NO SI NO SI SI ? MQTT.js SI NO NO % NO SI SI ? Moquette SI SI NO ? ? ? ? NO Mosca SI SI NO SI ? ? ? SI

Tabla  6.  Comparación  entre  brokers  MQTT.  Fuente:  (Requena, 2014)  

Convención: SI (soportado), NO (no soportado), ? (desconocido) y % limitación:

MQTT.js acepta conexiones con usuario y contraseña, pero actualmente no realiza el procedimiento de autenticar la conexión.

De acuerdo a las características y compatibilidad que presenta el broker mosquitto con MQTT, fue el broker escogido para esta investigación e implementación.