PROTOCOLOS DE COMUNICACIÓN IOT

Compártelo en tus redes sociales...
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter

Para comenzar en el mundo del internet de las cosas (IoT) tenemos que tener claro los diferentes protocolos de comunicación disponibles para IoT

Bien IoT es un campo en pleno apogeo que, en forma muy resumida, consiste en mantener una gran cantidad de objetos conectados entre sí. El IoT está de moda, de esto no cabe duda. Aunque hay mucho “humo” en torno al IoT, como siempre pasa en todos los temas de moda, lo cierto es que previsiblemente ha llegado para quedarse.

Parte del apogeo del IoT es la popularidad de Internet y los Smartphone, la mejora de los sistemas de comunicación, y la aparición de dispositivos con conectividad pequeños, baratos y de bajo consumo como el ESP8266 o el ESP32.

Básicamente la comunicación entre dispositivos es la piedra central del IoT. Por tanto, empezaremos viendo algunos protocolos de comunicación existentes en el ámbito del IoT.

Tenemos en cuenta estos protocolos de IoT seguramente nos vendrá a la cabeza rápidamente el popular MQTT. Sin embargo, no sólo existe todo es MQTT en el campo del IoT. En esta entrada veremos distintos protocolos, algunas de sus características, y el motivo de su existencia de su existencia.

¿Por Qué Necesitamos Un Protocolo Para IoT?

Un protocolo de comunicación es una serie de normas que definimos para que dos o más dispositivos puedan comunicarse y entenderse.

Como sabremos, tenemos muchas formas de comunicar realizar la comunicación M2M (machine-to-machine). Actualmente, con el desarrollo que han tenido las telecomunicaciones y el impulso que ha supuesto Internet, esto no resulta ningún problema.

Sin embargo, en el campo del IoT tenemos ciertos requisitos especiales que hacen que las habituales formas de comunicación entre dispositivos no sean totalmente adecuadas ¿Cuáles son estos condicionantes?

Condicionantes Del M2M En IoT

En primer lugar, en el IoT se puede llegar a tener una gran cantidad de dispositivos. Algunos de ellos serán pequeños recursos, como sensores o actuadores. Mientras que otros serán más grandes, como un servidor que recoge información, almacena datos, y procesa estadísticas.

Otro requisito es que queremos que sea escalable, es decir, que puedan añadirse o retirarse dinámicamente dispositivos sin que el comportamiento global del sistema se modifique.

También es importante mantener débil el acoplamiento entre dispositivos. Es decir, queremos que la dependencia entre los dispositivos sea la menor posible, y deseablemente nula.

Es necesario que algunos de los dispositivos sean embebidos, con bajo coste y escasa capacidad de cálculo. Por tanto, tiene que ser un protocolo que requiera poca capacidad de procesado.

Relacionado con la variedad y número de dispositivos, vamos a querer interoperabilidad. Es decir, que nuestra solución funcione la mayor variedad de dispositivos, sistemas operativos, y lenguajes de programación.

Además, es posible que haya un gran número de comunicaciones simultáneas y, en general, se requiere una respuesta rápida. Esto requiere que los mensajes transmitidos sean pequeños y, nuevamente, no requieran un gran procesamiento.

Por supuesto, tenemos siempre presente el condicionante de la seguridad, ya que estos dispositivos están expuestos a Internet  y transmiten información privada e incluso controlan sistemas físicos.

Finalmente, tenemos que poder acceder a los dispositivos fácilmente, por lo que tendremos que lidiar con direcciones dinámicas y DHCP, posibles conexiones con mala latencia o ancho de banda, dependencia con la infraestructura de la red, firewalls, etc.

Soluciones De Comunicación En El IoT

¿Cómo conseguimos que un número de dispositivos, distribuidos en ubicaciones y redes desconocidas, se comuniquen entre ellos de forma fiable y escalable?

Bien, la solución consiste en disponer un servidor central que se encarga de recibir los mensajes de todos los dispositivos emisores, y distribuirlos a los receptores. De forma genérica llamaremos a este servidor ‘Router’ o ‘Broker’.

Puede que sea poco ortodoxo disponer de un servidor encargado de distribuir mensajes. Pero en realidad, ya varios años se ha venido usando soluciones parecidas.

Este servidor, tiene una dirección fija (o equivalentemente un dominio), de forma que es accesible por todos los dispositivos, con lo que resolvemos el problema de tener que encontrar al otro dispositivo.

El servidor mantiene un registro de los dispositivos conectados, recibe los mensajes, y los distribuye al resto dispositivos, filtrando los destinatarios según algún criterio.

Los dispositivos en ningún momento ‘ven’ o dependen del resto de dispositivos. Por tanto, esta infraestructura nos proporciona la escalabilidad.

Metodologías En IoT

Publish / Susbcribe (Pubsub)

La metodología Pub/Sub es un patrón de mensajería donde un agente, el ‘Subscriber’, informa al Router que quiere recibir un tipo de mensajes. Otro agente, el ‘Publisher’ puede publicar mensajes. El Router distribuye los mensajes a los Subscribers.

Router Remoder Procedure Calls (RRPC)

El RRPC es un patrón de ejecución remota de procedimientos donde un agente, llamado ‘Callee’, comunica al Router que proporciona un cierto procedimiento. Otro agente, llamado ‘Caller’, puede llamar a este procedimiento. El Router invoca el procedimiento en el Callee, recoge el resultado del proceso, y lo comunica al Caller que lo ha invocado.

Infraestructuras De Servicios En IoT

Existen varias aproximaciones para realizar un patrón PubSub o RRPC. Veamos dos de las principales.

No obstante, también hay que destacar que existen soluciones que adoptan un comportamiento intermedio o híbrido entre ambos planteamientos.

Message Queue.

En un servicio de mensajería de tipo Message Queue el Router genera una cola de mensajes única para cada uno de los clientes que inician la subscripción. El Router discrimina los mensajes empleando el identificador del cliente, aunque por supuesto existen mecanismos para distribuir a múltiples clientes.

Estas colas de mensajes de cliente mantienen los mensajes recibidos hasta que son entregados al cliente. De forma que si se recibe un mensaje cuando el cliente no está conectado, se mantienen en el Router y son entregados cuando se conecta.

Un ejemplo de Message Queue es una aplicación de mensajería tipo Whastapp o Telegram, donde el usuario recibe los mensajes que ha recibido mientras no estaba conectado.

Message Service.

Otro planteamiento es servicio de mensajería puro o Message Service. En este caso, el router distribuye inmediatamente los mensajes a los clientes conectados. Los mensajes se filtran por algún criterio, como el tema o el contenido del mensaje.

A diferencia de un Message Queue, los mensajes entregados mientras el cliente está desconectado se pierden. No obstante, eso no significa que un servicio Message Service no pueda implementar algún tipo de persistencia de datos, por ejemplo, para analítica, históricos, o calidad del servicio.

Un ejemplo de Message Services es un chat, donde no podemos recuperar los mensajes emitidos cuando no estábamos en la sala. Un ejemplo podria ser una conversación a viva voz. Si alguien dice algo mientras estamos en otra habitación, aunque entremos nos hemos perdido lo que se dijo antes.

Protocolos IoT

Ahora que hemos visto la necesidad y planteamiento de los protocolos destinados a aplicaciones de IoT, vamos a ver algunos de los muchos protocolos M2M disponibles.

  • MQTT (MQ Telemetry Transport) es un protocolo PubSub de Message Service que actúa sobre TCP. Destaca por ser ligero, sencillo de implementar. Resulta apropiado para dispositivos de baja potencia como los que frecuentemente tenemos en IoT. Está optimizado para el routing activo de un gran número de clientes conectados de forma simultánea.
  • AMQP (Advanced Message Queuing Protocol) es un protocolo PubSub de Message Queue. AMQP está diseñado para asegurar la confiabilidad e interoperabilidad. Está pensado para aplicaciones corporativas, con mayor rendimiento y redes de baja latencia. No resulta tan adecuado para aplicaciones de IoT con dispositivos de bajos recursos.
  • WAMP (Web Application Messaging Protocol) es un protocolo abierto que se ejecuta sobre WebSockets, y provee tanto aplicaciones de PubSub como rRPC.
  • CoAP (Constrained Application Protocol) es un protocolo pensado para emplearse en dispositivos de IoT de baja capacidad. Emplea el modelo REST de HTTP con cabeceras reducidas, añadiendo soporte UDP, multicast, y mecanismos de seguridad adicionales.
  • STOMP (Streaming Text Oriented Messaging Protocol, es un protocolo sencillo que emplea HTTP y mensajes de texto para buscar el máximo de interoperabilidad.
  • XMPP (Extensible Messaging and Presence Protocol) es un protocolo abierto basado en XML diseñado para aplicaciones de mensajería instantánea.
  • WMQ (WebSphere MQ) es un protocolo de Message Queue desarrolado por IMB.
Compártelo en tus redes sociales...
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.