Introducción
El intercambio de datos entre dispositivos IoT es el la piedra fundamental de este tipo de proyecto. Armamos una lista de los protocolos de comunicación existentes en el ámbito del IoT.
¿Por qué se necesita un protocolo de comunicacion especifico para IoT?
Un protocolo de comunicación es un conjunto de normas definidas como un standard para que dos o más dispositivos puedan comunicarse y entenderse.
Con el avance de las telecomunicaciones y el impulso que ha supuesto Internet, contamos con protocolos robustos como el WiFi ó el 3G la comunicación entre dispositivos no resulta ningún problema.
Sin embargo, en los proyectos de IoT tenemos ciertos requisitos especiales que hacen que los protocolos populares de comunicación no sean eficientes. ¿Cuáles son estos condicionantes?
Te puede interesar
Condicionantes de los proyectos IoT
Por su filosofía los proyectos IoT cuentan con una gran cantidad de dispositivos. Algunos de ellos de pequeños recursos (energía, potencia de RF, etc), como sensores o actuadores. Mientras que otros cuentan con mucho más recursos, como los servidores que recoge información, almacena datos, procesa estadísticas y/o aplican reglas de negocio.
Dispositivos de bajos recursos
Se debe contemplar que algunos de los dispositivos serán dispositivos embebidos, de bajo costo y escasa capacidad de cálculo. Por tanto, el protocolo deberá requerir poca capacidad de procesamiento.
Escalabilidad
Queremos que se puedan añadir o quitar dispositivos dinámicamente, sin que el comportamiento del sistema se modifique. 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.
Relacionado con la variedad y número de dispositivos, vamos a querer interoperabilidad. Nuestra solución debera ser capaz de soportar la mayor variedad de dispositivos, sistemas operativos y lenguajes de programación.
Concurrencia
Se debe contemplar que un gran numero de sensores, actuadores y servidores, conlleva 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.
Seguridad
No importa de qué proyecto se trate la seguridad debe ser un elemento importante a tener en cuenta. En un proyecto IoT los dispositivos suelen estar expuestos a Internet y transmitir información privada e incluso controlan sistemas físicos.
Accesibilidad
Debemos poder acceder a los dispositivos fácilmente, por lo que tendremos que lidiar con direcciones de IP dinámicas y DHCP, posibles conexiones con mucha latencia o poco ancho de banda, dependencia con la infraestructura de la red, firewalls, etc.
Soluciones de comunicación en aplicaciones IoT
¿Cómo conseguir que un número alto de dispositivos, distribuidos geograficamente usando redes desconocidas, se comuniquen entre sí?
Una solución posible, es externalizar la comunicación con un servicio de notificaciones centralizado. Esta solución consiste en disponer un servidor central o Broker, que se encarga de recibir los mensajes de todos los dispositivos emisores, y distribuirlos a los receptores.
El Broker tiene una dirección fija y es accesible por todos los dispositivos, con lo que se elimina el problema de visibilidad entre dispositivos. 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 entre si, por lo que NO DEPENDEN del resto. Por tanto, esta infraestructura nos proporciona la escalabilidad.
Arquitectura de aplicación IoT
Definiciones
Publish/Susbcribe (pubsub)
La metodología Publicador/Suscriptor o PubSub es un arquitectura de mensajería donde un agente, el "Suscriptor", informa al "Broker" que quiere recibir mensajes de determinado tipo.
Otro miembro del sistema, el "Publicador" publica mensajes en la cola que le corresponde para que se distribuido por el "Broker" a los "Suscriptores" correspondientes.
Router Remoder Procedure Calls (RRPC)
El rRPC es un patrón de ejecución remota de procedimientos. Donde un miembro del sistema, llamado "Callee", comunica al "Broker" que proporciona un cierto procedimiento. Otro miembro, llamado "Caller", puede llamar a este procedimiento.
El Broker 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 topologias para realizar un patrón PubSub o rRPC. Describiremos dos de las principales. A efectos prácticos, podemos conseguir funcionalidades similares en ambos planteamientos, pero igual que en el caso anterior conviene ser consciente de la diferencia.
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 "Broker" genera una cola de mensajes única para cada uno de los clientes que inician la subscripción.
El Broker discrimina los mensajes empleando el identificador del cliente, existen mecanismos para distribuir a múltiples clientes el mismo mensaje.
Las 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 Broker y son entregados cuando se conecta.
Ejemplo
Una aplicación de mensajería tipo Whastapp, donde el usuario recibe los mensajes que ha recibido mientras no estaba conectado.
Message Service
Servicio de mensajería puro o Message Service. En este escenario, el Broker 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.
Ejemplo
Un chat, donde no podemos recuperar los mensajes emitidos cuando no estábamos en la sala. Otro ejemplo cotidiano es 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 para IoT
| MQTT MQ Telemetry Transport |
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) |
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 |
Protocolo abierto que se ejecuta sobre WebSockets, y provee tanto aplicaciones de PubSub como rRPC. |
| CoAP Constrained Application Protocol |
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 |
Protocolo sencillo que emplea HTTP y mensajes de texto para buscar el máximo de interoperabilidad. |
| XMPP Extensible Messaging and Presence Protocol |
Protocolo abierto basado en XML diseñado para aplicaciones de mensajería instantánea. |
| WMQ WebSphere MQ |
Protocolo de Message Queue desarrolado por IMB. |
