Este documento describe varios protocolos de comunicación importantes para Internet de las Cosas (IoT), incluyendo MQTT, AMQP, CoAP y STOMP. Explica que los dispositivos IoT requieren protocolos ligeros y escalables debido a su gran número, variedad y recursos limitados. Además, describe soluciones como message queues y message services para comunicación fiable entre dispositivos a través de un broker central.

1. Protocolos de Comunicación para Internet de las Cosas
Alumno:
RICHARD STEVE COMUN GALVAN
PROFESOR:
Pedro Valencia Morales
CURSO: REDES I

2. Contenido
 INTRODUCCION
 PROTOCOLOS DE COMUNICACIÓN PARA IOT
 ¿POR QUÉ UN PROTOCOLO PARA IOT?
 CONDICIONANTES DEL M2M EN IOT
 SOLUCIONES DE COMUNICACIÓN EN EL IOT
 METODOLOGÍAS EN IOT
 PUBLISH / SUSBCRIBE (PUBSUB)
 ROUTER REMODER PROCEDURE CALLS (RRPC)
 INFRAESTRUCTURAS DE SERVICIOS EN IOT
 MESSAGE QUEUE
 MESSAGE SERVICE
 PROTOCOLOS PARA IOT
 CONCLUSIONES
 RESEÑAS

3. INTRODUCCION
El internet de las cosas (en inglés, Internet of Things, abreviado IoT; IdC, por sus siglas
en español) es un concepto que se refiere a una interconexión digital de objetos cotidianos
con internet. Es, en definitiva, la conexión de internet más con objetos que con personas. También
se suele conocer como internet de todas las cosas o internet en las cosas. Si los objetos de la vida
cotidiana tuvieran incorporadas etiquetas de radio, podrían ser identificados y gestionados por
otros equipos de la misma manera que si lo fuesen por seres humanos.
El concepto de internet de las cosas fue propuesto en 1999, por Kevin Ashton, en el Auto-ID
Center del MIT, en donde se realizaban investigaciones en el campo de la identificación por
radiofrecuencia en red (RFID) y tecnologías de sensores.

5. PROTOCOLOS DE COMUNICACIÓN PARA IOT
Vamos a comenzar a adentrarnos en el apasionante mundo del Internet de las cosas (IoT) y empezamos viendo los protocolos de
comunicación disponibles para aplicaciones de IoT.
Como sabemos el IoT es un campo en auge que, en forma muy resumida, consiste en que una gran cantidad de objetos cotidianos
están o van a estar 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 auge 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.
Anuncio:
Como hemos visto en la definición, 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.
Si pensamos en 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 la motivación de
su existencia.
En la siguiente entrada de la serie de IoT nos centraremos en el MQTT, que como hemos dicho es uno de los protocolos más
habituales y accesibles en nuestros proyectos maker.

6. ¿POR QUÉ 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?

7. CONDICIONANTES DEL M2M EN IOT
En primer lugar, en el IoT tenemos (o podemos llegar a tener) una gran cantidad de dispositivos.
Algunos de ellos serán pequeños (de 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

8. 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.
Otro requisito es que algunos de los dispositivos serán dispositivos 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 (que no es
un lugar nada seguro) 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.
CONDICIONANTES DEL M2M EN IOT

9. SOLUCIONES DE COMUNICACIÓN EN EL IOT
Entonces ¿cómo conseguimos que un número de dispositivos, distribuidos en ubicaciones y redes
desconocidas, se comuniquen entre ellos de forma fiable y escalable?
Una posible solución, que está siendo ampliamente empleada, es externalizar la comunicación un
servicio de notificaciones centralizado. De hecho, es una infraestructura cada vez más habitual en
informática, tanto en aplicaciones de IoT como las que no.

10. En definitiva, 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 parecer un poco extraño disponer de un servidor encargado únicamente de encargado de distribuir mensajes. Pero en
realidad, llevamos años usando soluciones parecidas. Sin ir más lejos, un cartero es un servicio externo encargado de distribuir
mensajes.
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.
SOLUCIONES DE COMUNICACIÓN EN EL IOT

11. METODOLOGÍAS EN IOT
Vamos a repasar un par de términos en cuanto a metodologías que podemos encontrar en IoT. En
realidad, los conceptos son parecidos, pero conviene entender las diferencias (aunque sólo sea para
hablar con propiedad).
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.

12. 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. Vamos a ver 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.

13. 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.

14. 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. Otro ejemplo
cotidiano es el buzón de correo de tu casa. Si estás fuera de vacaciones, cuando vuelves tienes
todos tus mensajes esperándote.
MESSAGE QUEUE

15. 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.

16. 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. 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.
MESSAGE SERVICE

17. PROTOCOLOS PARA 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.
Hasta aquí esta entrada sobre protocolos de comunicación M2M en IoT. Hemos visto las necesidades especiales de estos protocolos y cómo
resolverlo con una externalización en un servicio de mensajería.
También hemos visto los conceptos de PubSub y rRPC y las diferencias entre un Message Service y un Message Queue. Finalmente, hemos
repasado rápidamente algunos de los principales protocolos de IoT disponibles actualmente.

18. Conclusiones
Es posible identificar, en los años venideros, cuatro distintas macro-tendencias que darán forma al futuro de las tecnologías de Internet, junto
con la explosión de dispositivos ubicuos que constituyen el futuro de la Internet de las Cosas:
1. La primera de ellas, a veces conocida como "exaflood" o "data deluge", es la explosión de la cantidad de datos recopilados e intercambiados.
Existe la necesidad por parte de todos los actores de repensar las actuales arquitecturas de red y de almacenamiento debido a que las redes
actuales no son adecuadas para este crecimiento exponencial del tráfico. Será imprescindible encontrar nuevas formas y mecanismos que
permitan localizar, traer, y transmitir datos. Una razón importante para este diluvio de datos es la explosión en el número de dispositivos de
recogida e intercambio de información como se prevé cuando la Internet de las cosas se convierta en una realidad.
2.La energía necesaria para hacer funcionar los dispositivos inteligentes disminuirá dramáticamente. Ya hoy en día, muchos centros de datos
han alcanzado el nivel máximo de consumo de energía y la adquisición de nuevos dispositivos necesariamente tiene que continuar con la retirada
de los más viejos. Por lo tanto, la segunda tendencia que se puede identificar cubre a todos los dispositivos y sistemas desde el más pequeño al
más grande de los centros de datos: la búsqueda de un nivel cero de entropía en el que el dispositivo o sistema tendrán que generar su propia
energía.
3. La miniaturización de los dispositivos también está teniendo lugar de forma increíblemente rápida. El objetivo de un transistor
nanométrico de un solo electrón está cada vez más cerca, que parece ser el último límite, al menos hasta que se produzcan nuevos
descubrimientos de la física
4. Otra tendencia importante es avanzar hacia los recursos autonómicos. La creciente complejidad de los sistemas será inmanejable y
dificultará la creación de nuevos servicios y aplicaciones a menos que los sistemas muestren auto propiedades, como la autogestión, la
autorecuperación y la autoconfiguración.
Como tendencia general, al ser menos costoso integrar la tecnología en objetos físicos, vamos a ver más aplicaciones y la adopción de la IoT.
En consecuencia, la IoT tendrá implicaciones importantes en compañías de negocio a negocio y de negocio a consumidor en los próximos años.

19. Reseñas
https://es.wikipedia.org/wiki/Internet_de_las_cosas
https://www.luisllamas.es/protocolos-de-comunicacion-para-iot/
http://sedici.unlp.edu.ar/handle/10915/67176
https://upcommons.upc.edu/bitstream/handle/2117/100921/LM08_R_ES.pdf