De entre la gran amalgama de protocolos de comunicación susceptibles de ser empleados en el ámbito IoT, parece que se impone con fuerza el protocolo MQTT, al menos en referencia a su amplia adopción por parte de la comunidad de desarrolladores que le lleva a estar presente en la gran mayoría de soluciones del mercado IoT actual.

MQTT (Message Que Telemetry Transport) es un protocolo de comunicación M2M (machine to machine), ligero en tanto que requiere de pocos recursos para su ejecución y con una implementación basada, como tantos otros protocolos, en un mecanismo de publicación – suscripción. Esta estrategia hace necesaria la existencia de un tercer elemento que actúe como canal de comunicación entre los actores que publican la información y los actores que reciben la notificación de dicha información. Este intermediario o “broker” tiene la misión de ordenar y racionalizar la comunicación entre los publicadores y los consumidores de los datos.

La amplia difusión de este protocolo se fundamenta, sin duda, en algunos aciertos en su diseño que lo convierten en óptimo para el despliegue de soluciones bajo el paradigma IoT en determinados escenarios.

  • La existencia de un “Broker” o elemento intermedio que ordena la comunicación, simplifica extraordinariamente el desarrollo de la misma. Más aún cuando existen soluciones de terceros ya implementadas, algunas de uso libre, y contrastada solvencia, que pueden reutilizarse sin ningún esfuerzo de desarrollo específico para su integración: RabbitMQ, Mosquitto, ZeroMQ etc.
  • La existencia de un elemento intermediario, junto con la simplicidad de su implementación, además, dota a la solución de una gran escalabilidad, puesto que, con aumentar recursos en un único elemento de la arquitectura, la solución puede crecer hasta alcanzar cifras de capacidad de proceso realmente sorprendentes.
  • La afortunada existencia de múltiples canales, también llamados etiquetas, que permite una muy eficiente segmentación de la información y el tráfico de datos.
  • Y, finalmente, un soporte directo para protocolos QoS que garantiza la fiabilidad y la integridad de la comunicación

Pero, su indudable éxito, ¿lo convierten realmente en un estándar de “facto”? ¿Se trata realmente de una solución universal llamada a normalizar el complejo universo de protocolos de comunicación en el ámbito IoT?

Responder a estas cuestiones implica replantearse, indudablemente, los diferentes escenarios en los que la tecnología IoT puede operar. Aunque es evidente que en arquitecturas basadas en el “Cloud” y totalmente orientadas a datos su eficacia y consiguiente éxito es incontestable, ¿es este el único escenario posible?, ¿Qué otras posibles arquitecturas podemos encontrar?

  • Si la solución, más que orientarse a los datos, en enfoca en el proceso, ¿resulta eficiente un esquema de publicación – suscripción en el que los datos deben pasar siempre por un intermediario? Evidentemente, si tras la captación de los datos, debe completarse un proceso que los evalúe y que tome decisiones de manera automatizada para, finalmente, interactuar con otros elementos del sistema, quizá la latencia inherente a ese modelo de publicación – suscripción no sea la solución más eficiente.
  • Sin duda, siempre que exista una cierta capacidad de proceso local, resulta preferible pre-procesar los datos antes de publicarlos. La experiencia sobre implementaciones reales de soluciones IoT, demuestra que, en algunos escenarios concretos, solo un pequeño porcentaje de la gran cantidad de datos captados, resultan significativos. Asi por ejemplo, si un sensor de temperatura capta la temperatura regularmente cada segundo durante una hora, las 3600 lecturas resultantes ¿tienen el mismo valor? En este caso, sin duda, resulta mucho más eficiente pre-seleccionar solo algunas de estas lecturas, las que muestren una variación significativa sobre lecturas anteriores, para su publicación o, incluso, publicar únicamente una métrica, como por ejemplo la media, o el valor máximo y el valor mínimo, que sintetice toda la información de esas 3600 lecturas, en un solo dato.
  • ¿Y si la información no está únicamente contenida en el propio dato, sino que, para su correcta interpretación, también es necesario la información de contexto en el que se obtuvo el dato?

Si bien es cierto que también estos escenarios son susceptibles de ser abordados con la utilización del protocolo MQTT, también lo es que, para su correcta y eficaz implementación, es necesario un desarrollo específico y una cierta reelaboración de los principios antes mencionados.

Así pues, la adopción de un protocolo concreto de comunicación no puede ser determinada sin antes analizar cuidadosamente el escenario, la arquitectura y, sobre todo, los objetivos específicos que la solución debe cumplimentar. Afortunadamente, la amplia cartera de protocolos de comunicación existentes, nos facilitará, sin duda, una posibilidad adecuada a cada escenario concreto que, en algunos casos puede consistir en una implementación rigurosa del protocolo MQTT, o cualquier otro. Pero en otras ocasiones la utilización de un protocolo que permita una comunicación horizontal o peer-peer como un API Rest distribuida, por ejemplo, tambien puede resultar útil. En definitiva, como casí siempre, la complejidad de los problemas a los que debemos enfrentarnos, nos obliga a tener una caja de herramientas bien surtida para poder afrontar con garantias cualquier solución. Y, a menudo, la mejores soluciones suelen partir de una sabia combinación de diferentes recursos.