Protocolos de capa de aplicación para IoT: IoT Parte 11

Esta capa es responsable de formatear y presentar datos. La capa de aplicación en Internet suele basarse en el protocolo HTTP. Sin embargo, HTTP no es adecuado en entornos con recursos limitados porque es extremadamente pesado y, por lo tanto, genera una gran sobrecarga de análisis. Por ello, existen muchos protocolos alternativos que se han desarrollado para entornos IOT. Algunos de los protocolos de capa de aplicación de IoT más populares son los siguientes:

•MQTT

•SMQTT

• CoAP

• DDS

•XMPP

• AMQP

• HTTP RESTful

• MQTT-SN

• PISIÓN

•SMCP

• LLAP

• ISS

• LWM2M

•M3DA

• XMPP-IOT

•ONS 2.0

• JABÓN

• WebSocket

• Flujos reactivos

•HTTP/2

• JavaScript de IoT

MQTT: Message Queuing Telemetry Transport es un protocolo de mensajería ligero. Utiliza la forma de comunicación publicación-suscripción y es por eso que se utiliza para la comunicación M2M (máquina a máquina). Se basa en el protocolo TCP-IP y está diseñado para funcionar con un ancho de banda limitado. En la terminología de protocolo, el ancho de banda de red limitado se denomina "área de cobertura de código pequeña". Sin embargo, el significado exacto de ancho de banda de red limitado no queda claro en la especificación.

Este protocolo está especialmente diseñado para redes de sensores y redes de sensores inalámbricos. MQTT permite que los dispositivos envíen o publiquen información sobre un tema determinado a un servidor. Existe un broker MQTT (Broker-Mosquitto) entre el editor y el suscriptor. Luego, el corredor transfiere la información a clientes previamente registrados.

Los sensores interactúan con un intermediario, que es un dispositivo o servidor IOT que lee y publica datos de sensores. Los otros dispositivos que se suscriben y solicitan datos del sensor se denominan clientes. Los propios sensores se denominan editores en la red. El cliente puede ser una computadora portátil, un teléfono inteligente, una tableta u otro dispositivo móvil. Los dispositivos cliente deben suscribirse al intermediario de red para recibir datos de los sensores. Para recibir datos, los dispositivos de los clientes inscritos deben establecer una conexión con el corredor y solicitar datos. El corredor toma los datos del editor (sensores inalámbricos) y los envía al cliente que los solicita. Incluso si la conexión con el dispositivo cliente se interrumpe después de realizar la solicitud, el corredor guarda los datos en un caché para que cuando el dispositivo cliente se vuelva a conectar al corredor, pueda recibir los datos del sensor solicitados. Asimismo, si la conexión entre el editor y el corredor se interrumpe después de que se haya realizado la solicitud, el corredor reenvía las instrucciones apropiadas enviadas por el editor para que el dispositivo del cliente pueda volver a conectarse y recibir los datos solicitados.

Por lo tanto, MQTT funciona bien incluso cuando la conexión entre el corredor y el editor o el corredor y el cliente se interrumpe debido al ancho de banda de red limitado. Esta capacidad de lidiar con retrasos o latencias en la red hace que este protocolo sea muy adecuado para redes inalámbricas.

Figura 1: Imagen que muestra la arquitectura del protocolo MQTT

Una sesión MQTT se puede dividir en cuatro pasos:

1) Conexión

2) Autenticación

3) comunicación

4) Terminación

Conexión y autenticación: en este paso, el cliente (como un dispositivo móvil o una computadora portátil) inicia una conexión TCP-IP con el intermediario (servidor) utilizando un puerto estándar o un puerto definido por el operador de red. Los puertos predeterminados son generalmente 1883 para comunicación no cifrada y 8883 para comunicación cifrada a través de SSL o TLS. En la comunicación cifrada, el servidor envía un certificado de servidor para autenticarse ante el cliente y el cliente también puede enviar un certificado al servidor para autenticarse. Aunque incluso en comunicaciones cifradas, la autenticación del cliente no forma parte de la especificación y tampoco es común. Aun así, normalmente la autenticación del cliente se realiza pasando un nombre de usuario y contraseña del cliente al corredor (servidor).

Comunicación: los datos del sensor se comunican al cliente mediante pequeños códigos. Aunque el término "área de código pequeña" no se especifica exactamente en el protocolo, generalmente contiene un encabezado de 2 bytes de longitud, un encabezado opcional de longitud variable, datos del sensor como carga útil del mensaje limitada a 250 Mb de tamaño e indicación del nivel de calidad de servicio. Puede haber tres niveles de Calidad de Servicio (QoS): Servicio no reconocido (QoS Nivel 0), Servicio Reconocido (QoS Nivel 1) y Servicio Garantizado (QoS Nivel 2). Cada nivel de QoS que se excede requiere más ancho de banda de red y tolerancia a la latencia.

Puede haber cuatro tipos de operaciones que puede realizar un cliente: publicar, suscribirse, cancelar suscripción y hacer ping. El cliente puede suscribirse a temas específicos en la red, del mismo modo que un dispositivo móvil puede suscribirse a un corredor para leer la temperatura actual de una ciudad. Para suscribirse, el cliente debe enviar un par de paquetes SUBSCRIBE/SUBACK al corredor. De manera similar, para cancelar la suscripción (de un tema), el cliente debe enviar un par de paquetes UBSUBSCRIBE/UNSUBACK al servidor. La operación de ping puede ser realizada por un dispositivo cliente para verificar la conexión activa con el corredor. En la operación de publicación, los datos se comunican entre el corredor y el cliente sobre un tema específico.

4) Terminación: el editor o cliente puede finalizar la conexión enviando un mensaje DESCONNECT al intermediario, después del cual se finaliza la conexión TCP-IP. Si la conexión se interrumpe repentinamente (debido al ancho de banda de red limitado) sin una solicitud de terminación, el corredor envía los mensajes almacenados en caché del editor al cliente.

SMQTT: basado en MQTT, el protocolo de transporte seguro de telemetría de cola de mensajes (SMQTT) es un protocolo de mensajería ligero basado en cifrado. En comparación con una sesión MQTT, la sesión SMQTT tiene cuatro etapas: configuración, cifrado, publicación y descifrado. Tiene una arquitectura basada en intermediario similar a MQTT; sin embargo, en este protocolo tanto el suscriptor como el editor deben registrarse con el intermediario mediante una clave maestra secreta. Los datos también se cifran antes de ser publicados por el editor y luego se descifran por parte del suscriptor. Puede haber cualquier algoritmo de cifrado que pueda utilizar el desarrollador.

CoAP: protocolo de aplicación restringido está diseñado específicamente para hardware restringido (limitado). El hardware que no admite HTTP o TCP/IP puede utilizar el protocolo CoAP. Entonces, básicamente los diseñadores de este protocolo inspirados en HTTP diseñaron el protocolo CoAP utilizando el protocolo UDP e IP. Es un protocolo liviano que necesita una aplicación IoT de bajo consumo, como para la comunicación entre dispositivos IoT que funcionan con baterías. Al igual que HTTP, también sigue el modelo cliente-servidor. Los clientes pueden OBTENER, PONER, BORRAR o PUBLICAR recursos de información a través de la red.

CoAP utiliza dos tipos de mensajes: solicitudes y respuestas. Los mensajes contienen un encabezado base seguido del cuerpo del mensaje cuya longitud está especificada por el datagrama. Los mensajes o paquetes de datos son de tamaño pequeño, por lo que pueden comunicarse entre dispositivos restringidos sin pérdida de datos. Los mensajes pueden ser confirmables o no confirmables. Para mensajes confirmables, el cliente debe responder con un acuse de recibo después de recibir el paquete de datos. Los mensajes de solicitud pueden contener cadenas de consulta para implementar funciones adicionales como búsqueda, clasificación o paginación.

Por seguridad, el protocolo utiliza Datagram Transport Layer Security (DTLS) sobre UDP. En HTTP es muy complicado conocer el nuevo estado de una variable. en HTTP, el cliente tiene que sondear repetidamente, lo que significa que el cliente tiene que preguntar cada segundo para ver si hay algún estado nuevo de la variable que está observando. En CoAP, los servicios CoAP intentan resolver el problema creando un indicador de vigilancia, de modo que si el dispositivo original envía el indicador de vigilancia con el comando GET, cada vez que el servidor u otros dispositivos noten que hay un cambio en el estado de la variable luego, el servidor o los dispositivos enviarán la notificación automática al dispositivo original que realmente está encontrando la baliza de observación.

El protocolo también proporciona un mecanismo adicional para el descubrimiento de recursos por parte de los dispositivos cliente. El servidor debe proporcionar una lista de recursos junto con metadatos a los que se puede acceder, como el enlace o el tipo de medio de la aplicación. Al navegar por la lista, un cliente puede encontrar recursos disponibles (información o datos) y descubrir sus tipos de medios.

Los propios nodos sensores de la red actúan como servidores en lugar de clientes. Los sensores se pueden enrutar directamente y la comunicación de datos es individual entre el sensor y los dispositivos cliente. Para implementar estos protocolos, los sensores deben ser capaces de recibir paquetes de datos y responder a ellos.

DDS: diseñado por Object Management Group (OMG), el servicio de distribución de datos es un protocolo de capa de aplicación M2M para sistemas en tiempo real. Basada en un estándar de publicación-suscripción como MQTT, la arquitectura del protocolo tiene nodos configurados como editor, suscriptor o ambos. El protocolo no requiere ningún middleware de red, por lo que los editores pueden publicar información sobre temas específicos (como un sensor de temperatura puede revelar la temperatura actual de una ubicación) y el protocolo mismo puede entregársela al suscriptor (como un dispositivo móvil que muestra la temperatura actual). de un lugar). La implementación del protocolo no requiere ninguna programación de red, ya que el protocolo no requiere verificación de la existencia o ubicación de nodos y tampoco requiere confirmación de la entrega del mensaje.

XMPP: Protocolo extensible de presencia y mensajería (XMPP) es un protocolo de mensajería basado en XML. XML es un lenguaje de marcado para codificar documentos que son legibles tanto por humanos como por máquinas. XML evolucionó para extender HTML y permitir agregar etiquetas y elementos personalizados a la web. Al ser una extensión de HTML, permite la estructuración de datos junto con la extensionalidad. Tradicionalmente, XMPP se ha utilizado para comunicaciones en tiempo real, como mensajería instantánea, presencia, chat entre varias partes, llamadas de voz y vídeo, colaboración, distribución de contenidos, etc.

El uso de XMPP para IOT permite la creación de redes escalables y en tiempo real entre dispositivos o cosas. Las cosas (dispositivos) tienen uno o más nodos y cada nodo tiene varios campos (informativos). Cada campo contiene un valor legible y grabable. Los nodos deben hacerse amigos enviando y aceptando solicitudes de amistad. Una vez que el otro acepta la solicitud de amistad de un nodo, puede recibir actualizaciones del otro nodo. Si otro nodo también necesita recibir actualizaciones del primer nodo, también debe enviar una solicitud de amistad y necesita confirmación. Si ambos nodos se hacen amigos en la red, esto se denomina suscripción dual; de lo contrario, se denomina firma unilateral. Los datos se comunican entre nodos individualmente, donde un nodo puede leer o escribir valores de campo en el otro nodo.

AMQP: al igual que XMPP, el Protocolo avanzado de cola de mensajes (AMQP) también es un protocolo de capa de aplicación estándar abierto para middleware orientado a mensajes. Se utiliza para pasar mensajes comerciales entre aplicaciones u organizaciones. Conecta sistemas, alimenta los procesos de negocio con la información que necesitan y transmite de manera confiable instrucciones que logran sus objetivos.

Este es un estándar de mensajería interoperable y multiplataforma. En la arquitectura del protocolo, el cliente pasa el mensaje junto con un encabezado a un corredor o intercambio. Por lo tanto, existe una única cola a la que un productor pasa el mensaje. Desde el intercambio o corredor, el mensaje se puede reenviar a una o más colas. El encabezado contiene información sobre cada byte del mensaje. También contiene la información de ruta. El corredor o bolsa sigue siendo responsable de leer los encabezados y recibir, enrutar y entregar mensajes a las aplicaciones del cliente. La comunicación en este protocolo sigue siendo uno a uno entre dos nodos.

RESTful HTTP: transferencia de estado representacional (REST) ​​​​o RESTful es un protocolo de comunicación interoperable y sin estado. El protocolo le permite identificar recursos web (recursos de información) mediante URL únicas y le permite entregarlos como un archivo HTTP, JSON o XML. Los recursos se exponen como URI de estructura de directorios. Un cliente puede acceder a recursos para mensajes GET, PUT, DELETE o POST para representaciones donde las representaciones son objetos de datos y sus atributos en formato HTML, XML o JSON. GET, PUT, DELETE y POST son métodos de solicitud HTTP para recibir, modificar y enviar datos. Al tratarse de una comunicación sin estado, no se envía ni recibe ninguna confirmación para confirmar la entrega del mensaje. Sin embargo, la solicitud HTTP puede ser respondida por un código de estado que indica éxito, redirección, información, error del cliente o error del servidor.

MQTT-SN: MQTT-Sensor Network es un protocolo de publicación/suscripción abierto y liviano diseñado específicamente para dispositivos restringidos, es decir, red de sensores inalámbricos (WSN). La red de sensores inalámbricos que no tiene una pila TCP/IP en la parte superior, como la red de sensores inalámbricos basada en Zigbee o WSN basada en Bluetooth, pueden enviar sus datos a Internet con el protocolo MQTT-SN.

MQTT-SN está diseñado para ser lo más cercano posible a MQTT, pero está adaptado a las peculiaridades de un entorno de comunicación inalámbrica, como ancho de banda bajo, fallas de enlace elevadas, longitud de mensajes corta, etc. Dispositivos de bajo costo que funcionan con baterías y con recursos limitados de procesamiento y almacenamiento.

En comparación con MQTT, se han introducido los siguientes cambios en MQTT-SN:

• Los nombres de los temas se reemplazan con ID de temas, lo que reduce la sobrecarga de transmisión.

• Los temas no requieren registro, ya que están prerregistrados.

• Los mensajes también se dividen para que sólo se envíe la información necesaria.

• Para conservación de energía, existe un procedimiento fuera de línea para clientes que se encuentran en estado suspendido. Los mensajes pueden almacenarse en un buffer y luego ser leídos por los clientes cuando se despiertan.

• Los clientes se conectan al corredor a través de un dispositivo de puerta de enlace, que reside en la red de sensores y se conecta al corredor.

En la arquitectura MQTT-SN, hay tres tipos de componentes MQTT-SN: clientes MQTT-SN, puertas de enlace (GW) MQTT-SN y reenviadores MQTT-SN. Los clientes MQTT-SN se conectan a un servidor MQTT a través de un GW MQTT-SN utilizando el protocolo MQTT-SN. Un MQTT-SN GW puede estar integrado o no con un servidor MQTT. En el caso de una GW independiente, el protocolo MQTT se utiliza entre el servidor MQTT y la GW MQTT-SN. Su función principal es la traducción entre MQTT y MQTT-SN.

Figura 2: Imagen que muestra la arquitectura del protocolo MQTT-SN

Los clientes MQTT-SN también pueden acceder a un GW a través de un reenviador si el GW no está conectado directamente a su red. El reenviador simplemente encapsula las tramas MQTT-SN que recibe en el lado inalámbrico y las reenvía sin cambios al GW; en sentido contrario, libera las tramas que recibe del gateway y las envía a los clientes, también sin cambios.

STOMP: protocolo de mensajería orientada a texto simple o en streaming (STOMP) es un protocolo basado en texto para middleware orientado a mensajes. Está basado en TCP y utiliza comandos similares a HTTP. Está diseñado para proporcionar interoperabilidad entre plataformas, idiomas e intercambios. Los datos se comunican entre un cliente y un corredor en marcos de varias líneas que contienen comando, encabezado y contenido. El comando puede ser CONECTAR, DESCONECTAR, ACK, NACK, SUBSCRIBE, UNSUBSCRIBE, SEND, BEGIN, COMMIT o ABORT.

SMCP: el Protocolo simple de control de medios (SMCP) es una pila de protocolos CoAP para dispositivos integrados. Está desarrollado en lenguaje C y se puede utilizar para enviar y recibir respuestas CoAP asincrónicas.

LLAP (Protocolo ligero de automatización local) es un protocolo de mensajería breve y simple que se puede ejecutar en cualquier medio de comunicación. El protocolo está diseñado para mensajería directa entre dispositivos integrados, independientemente del protocolo de capa física de bajo nivel utilizado por los dispositivos.

SSI – Simple Sensor Interface (SSI) es un protocolo de capa de aplicación diseñado para la comunicación entre computadoras y sensores. Basado en UART, el protocolo le permite sondear sensores y transmitir datos de sensores. Los datos se comunican mediante sensores a las computadoras en pequeños espacios de código. En el protocolo, el mensaje entre el sensor y la computadora contiene un encabezado de 2 bytes y la carga útil del mensaje. El encabezado contiene una dirección de un solo byte y un comando o tipo de mensaje de un solo byte.

LWM2M: Lightweight M2M (LWM2M) es un protocolo de administración de dispositivos para redes de sensores. Open Mobile Alliance (OMA) desarrolló este protocolo para administrar dispositivos livianos y de bajo consumo en una variedad de redes. La pila de protocolos se basa en REST y CoAP.

M3DA: M3DA es una pila de protocolos para comunicar datos binarios entre servidores M2M y aplicaciones que se ejecutan en puertas de enlace integradas. Está diseñado para la gestión de dispositivos y activos, de modo que el ancho de banda de la red se utilice de manera óptima.

XMPP-IOT: así como XMPP se utiliza para la comunicación interoperable, XMPP-IOT es una pila de protocolos para la comunicación M2M independiente de la máquina.

ONS 2.0 – Servicio de nombres de objetos (ONS) es una pila de protocolos para localizar metadatos y servicios utilizando una clave de identificación GS1 determinada. GS1 es un estándar de mensajería comercial electrónica para automatizar transacciones comerciales en una cadena de suministro.

SOAP: el Protocolo simple de acceso a objetos (SOAP) es una pila de protocolos basada en XML que se utiliza para implementar servicios web en Internet. Utiliza métodos de solicitud HTTP para mensajes entre clientes en una red.

Websocket: la interfaz JavaScript de WebSocket define una conexión de un solo socket full-duplex a través de la cual se pueden enviar mensajes entre el cliente y el servidor. El estándar simplifica la complejidad de la comunicación web bidireccional y la gestión de conexiones.

Reactive Streams: Reactive Streams es una pila de protocolos para el procesamiento de flujos asincrónicos con contrapresión sin bloqueo. Es una especificación que se puede implementar en Java o JavaScript. Se utiliza para manejar flujos de datos en vivo cuyo volumen se desconoce.

HTTP/2: la versión 2 de HTTP será la próxima versión del protocolo HTTP. Utilizará compresión de campos de encabezado para reducir la latencia y permitir múltiples intercambios simultáneos en la misma conexión.

IOT JavaScript: no se trata de ningún estándar ni protocolo. Se refiere al uso de JavaScript y particularmente de Node.js (un JavaScript del lado del servidor) con placas IOT para diversas aplicaciones. Algunos de los proyectos de IoT basados ​​en JavaScript incluyen NodeMCU, Jerryscript, Socket.IO, Ruff, NodeRed, KinomaJS, CHIRIMEN, Mosca, Nodebots, heimcontrol.js, Resin, UPM, i2C, node-http2, onoff, node-serialport, mdns, IoT.js, Favor, Serverless, noduino, duino, Pijs.io, etc.

En el próximo tutorial, se analizarán la nube y los servicios de IoT.