Protocolos de camada de aplicativo para IoT: IoT Parte 11

Esta camada é responsável pela formatação e apresentação dos dados. A camada de aplicação na Internet é normalmente baseada no protocolo HTTP. No entanto, o HTTP não é adequado em ambientes com recursos limitados porque é extremamente pesado e, portanto, incorre em uma grande sobrecarga de análise. Portanto, existem muitos protocolos alternativos que foram desenvolvidos para ambientes IOT. Alguns dos protocolos populares da camada de aplicação IOT são os seguintes –

•MQTT

•SMQTT

• CoAP

• DDS

•XMPP

• AMQP

• HTTP RESTful

• MQTT-SN

• PISÃO

•SMCP

• LLAP

• SSI

• LWM2M

•M3DA

• XMPP-IOT

•ONS 2.0

• SABÃO

• WebSocket

• Fluxos reativos

•HTTP/2

• JavaScript IOT

MQTT – Message Queuing Telemetry Transport é um protocolo de mensagens leve. Ele usa a forma de comunicação publicar-assinar e é por isso que é usado para comunicação M2M (máquina para máquina). É baseado no protocolo TCP-IP e foi projetado para operar em largura de banda limitada. Na terminologia do protocolo, a largura de banda limitada da rede é referida como “pequena área de cobertura de código”. No entanto, o significado exato de largura de banda de rede limitada não está claro na especificação.

Este protocolo foi especialmente projetado para redes de sensores e redes de sensores sem fio. MQTT permite que dispositivos enviem ou publiquem informações de dados sobre um determinado tópico para um servidor. Existe um corretor MQTT (Broker-Mosquitto) entre o editor e o assinante. A corretora então transfere as informações para os clientes previamente inscritos.

Os sensores fazem interface com um corretor, que é um dispositivo ou servidor IOT que lê e publica dados do sensor. Os outros dispositivos que assinam e solicitam dados do sensor são chamados de clientes. Os próprios sensores são chamados de editores na rede. O cliente pode ser um laptop, smartphone, tablet ou outro dispositivo móvel. Os dispositivos clientes precisam se inscrever no corretor da rede para receber dados do sensor. Para receber dados, os dispositivos clientes inscritos devem estabelecer conexão com o corretor e solicitar dados. A corretora pega os dados do editor (sensores wireless) e os envia ao cliente que os solicita. Mesmo que a conexão com o dispositivo cliente seja interrompida após a solicitação ter sido feita, o corretor salva os dados em um cache para que, quando o dispositivo cliente se reconectar ao corretor, ele possa receber os dados do sensor solicitados. Da mesma forma, se a conexão entre o editor e o corretor for interrompida após a solicitação ter sido feita, o corretor encaminha as instruções apropriadas enviadas pelo editor, para que o dispositivo cliente possa se reconectar e receber os dados solicitados.

Portanto, o MQTT funciona bem mesmo quando a conexão entre o corretor e o editor ou o corretor e o cliente é interrompida devido à largura de banda de rede limitada. Esta capacidade de lidar com atrasos ou latências na rede torna este protocolo bastante adequado para redes sem fio.

Uma sessão MQTT pode ser dividida em quatro etapas –

1) Conexão

2) Autenticação

3) Comunicação

4) Rescisão

Conexão e Autenticação – Nesta etapa, o cliente (como um dispositivo móvel ou laptop) inicia uma conexão TCP-IP com o broker (servidor) usando uma porta padrão ou uma porta definida pela operadora de rede. As portas padrão são geralmente 1883 para comunicação não criptografada e 8883 para comunicação criptografada através de SSL ou TLS. Na comunicação criptografada, o servidor envia um certificado de servidor para se autenticar pelo cliente e o cliente também pode enviar um certificado ao servidor para se autenticar. Embora mesmo na comunicação criptografada, a autenticação do cliente não faz parte da especificação e também não é comum. Ainda assim, normalmente, a autenticação do cliente é feita passando um nome de usuário e senha do cliente para a corretora (servidor).

Comunicação – Os dados do sensor são comunicados ao cliente usando pequenos códigos. Embora o termo 'pequena área de código' não seja exatamente especificado no protocolo, ele geralmente contém um cabeçalho longo de 2 bytes, um cabeçalho opcional de comprimento variável, dados do sensor como carga útil da mensagem limitada a 250 Mb em tamanho e indicação de nível de qualidade de serviço. Pode haver três níveis de Qualidade de Serviço (QoS) – Serviço Não Reconhecido (Nível de QoS 0), Serviço Reconhecido (Nível de QoS 1) e Serviço Garantido (Nível de QoS 2). Cada nível de QoS excedente requer mais largura de banda de rede e tolerância à latência.

Pode haver quatro tipos de operações que podem ser executadas por um cliente – publicar, assinar, cancelar assinatura e executar ping. O cliente pode se inscrever em tópicos específicos da rede, assim como um dispositivo móvel pode se inscrever em um corretor para ler a temperatura atual de uma cidade. Para assinar, o cliente precisa enviar um par de pacotes SUBSCRIBE/SUBACK ao corretor. Da mesma forma, para cancelar a assinatura (de um tópico), o cliente precisa enviar um par de pacotes UBSUBSCRIBE/UNSUBACK ao servidor. A operação de ping pode ser executada por um dispositivo cliente para verificar a conexão ativa com o corretor. Na operação de publicação, os dados são comunicados entre a corretora e o cliente sobre um tema específico.

4) Encerramento – O editor ou cliente pode encerrar a conexão enviando uma mensagem DISCONNECT ao corretor, após a qual a conexão TCP-IP é encerrada. Se a conexão for interrompida repentinamente (devido à largura de banda limitada da rede) sem solicitação de encerramento, o corretor envia as mensagens em cache do editor para o cliente.

SMQTT – Baseado em MQTT, o protocolo Secure Message Queue Telemetry Transport (SMQTT) é um protocolo de mensagens leve baseado em criptografia. Comparada a uma sessão MQTT, a sessão SMQTT tem quatro estágios – configuração, criptografia, publicação e descriptografia. Possui arquitetura baseada em corretor semelhante ao MQTT, porém, neste protocolo tanto o assinante quanto o editor precisam se registrar no corretor usando uma chave mestra secreta. Os dados também são criptografados antes de serem publicados pelo editor e depois descriptografados no final do assinante. Pode haver qualquer algoritmo de criptografia que possa ser usado pelo desenvolvedor.

CoAP – Constrained Application Protocol é projetado especificamente para hardware restrito (limitado). O hardware que não suporta HTTP ou TCP/IP pode usar o protocolo CoAP. Então, basicamente os projetistas deste protocolo inspirados no HTTP projetaram o protocolo CoAP usando UDP e protocolo IP. É um protocolo leve que precisa de aplicação IOT de baixo consumo de energia, como para comunicação entre dispositivos IOT alimentados por bateria. Assim como o HTTP, também segue o modelo cliente-servidor. Os clientes podem GET, PUT, DELETE ou POST recursos informativos pela rede.

O CoAP utiliza dois tipos de mensagens – solicitações e respostas. As mensagens contêm um cabeçalho base seguido pelo corpo da mensagem cujo comprimento é especificado pelo datagrama. As mensagens ou pacotes de dados são de tamanho pequeno, de modo que podem ser comunicados entre dispositivos restritos sem perdas de dados. As mensagens podem ser confirmáveis ​​ou não confirmáveis. Para mensagens confirmáveis, o cliente precisa responder com uma confirmação após receber o pacote de dados. As mensagens de solicitação podem conter strings de consulta para implementar funcionalidades adicionais como pesquisa, classificação ou paginação.

Para segurança, o protocolo usa Datagram Transport Layer Security (DTLS) sobre UDP. No HTTP é muito complicado saber o novo estado de uma variável. no HTTP, o cliente precisa fazer pesquisas repetidas vezes, o que significa que o cliente precisa perguntar a cada segundo para ver se há algum novo estado da variável que está observando. No CoAP, os serviços CoAP tentam resolver o problema criando um sinalizador de observação, portanto, se o dispositivo original enviar o sinalizador de observação com o comando GET, toda vez que o servidor ou os outros dispositivos perceberem que há uma mudança no estado da variável então o servidor ou os dispositivos enviarão a notificação push para o dispositivo original que está realmente encontrando o sinalizador do observador.

O protocolo também fornece um mecanismo adicional para descoberta de recursos pelos dispositivos clientes. O servidor deve fornecer uma lista de recursos junto com metadados que podem ser acessados ​​como link ou tipo de mídia de aplicativo. Ao navegar pela lista, um cliente pode encontrar os recursos disponíveis (informações ou dados) e descobrir seus tipos de mídia.

Os próprios nós sensores da rede atuam como servidores em vez de clientes. Os sensores são roteáveis ​​diretamente e a comunicação de dados é individual entre o sensor e os dispositivos clientes. Para implementação destes protocolos, os sensores devem ser capazes de receber pacotes de dados e respondê-los.

DDS – Projetado pelo Object Management Group (OMG), o Data Distribution Service é um protocolo de camada de aplicação M2M para sistemas em tempo real. Baseada em um padrão de publicação-assinatura como MQTT, a arquitetura do protocolo possui nós configurados como editor, assinante ou ambos. O protocolo não requer nenhum middleware de rede, então os editores podem liberar informações sobre tópicos específicos (como um sensor de temperatura pode liberar a temperatura atual de um local) e o próprio protocolo consegue entregá-las ao assinante (como um dispositivo móvel mostrando a temperatura atual de um local). A implementação do protocolo não requer nenhuma programação de rede, pois o protocolo não requer verificação da existência ou localização dos nós e também não necessita de confirmação da entrega da mensagem.

XMPP – Extensible Messaging and Presence Protocol (XMPP) é um protocolo de mensagens baseado em XML. XML é uma linguagem de marcação para codificação de documentos que são legíveis por humanos e também por máquinas. O XML evoluiu para estender o HTML e permitir a adição de tags e elementos personalizados à web. Por ser uma extensão do HTML, permite a estruturação de dados juntamente com a extensionalidade. Tradicionalmente, o XMPP tem sido usado para comunicação em tempo real, como mensagens instantâneas, presença, bate-papo com vários participantes, chamadas de voz e vídeo, colaboração, distribuição de conteúdo, etc.

O uso de XMPP para IOT permite redes escaláveis ​​e em tempo real entre dispositivos ou coisas. As coisas (dispositivos) possuem um ou mais nós e cada nó possui vários campos (informativos). Cada campo contém um valor legível e gravável. Os nós precisam se tornar amigos enviando e aceitando solicitações de amizade. Depois que a solicitação de amizade de um nó for aceita pelo outro, ele poderá receber atualizações do outro nó. Se outro nó também precisar obter atualizações do primeiro nó, ele também precisará enviar uma solicitação de amizade e precisar de confirmação. Se ambos os nós se tornarem amigos na rede, isso é chamado de assinatura dupla; caso contrário, é chamado de assinatura unilateral. Os dados são comunicados entre os nós individualmente, onde um nó pode ler ou escrever valores de campo no outro nó.

AMQP – Assim como o XMPP, o Advanced Message Queue Protocol (AMQP) também é um protocolo de camada de aplicativo de padrão aberto para middleware orientado a mensagens. É usado para passar mensagens comerciais entre aplicativos ou organizações. Ele conecta sistemas, alimenta os processos de negócios com as informações necessárias e transmite de forma confiável as instruções que atingem seus objetivos.

Este é um padrão de mensagens interoperável e multiplataforma. Na arquitetura do protocolo, a mensagem junto com um cabeçalho é passada pelo cliente para um corretor ou bolsa. Portanto, existe uma única fila para a qual a mensagem é passada por um produtor. Da bolsa ou corretora, a mensagem pode ser repassada para uma ou mais filas. O cabeçalho contém informações sobre cada byte da mensagem. Ele também contém as informações de roteamento. O corretor ou bolsa continua responsável por ler os cabeçalhos e receber, rotear e entregar mensagens às aplicações clientes. A comunicação neste protocolo permanece um para um entre dois nós.

RESTful HTTP – Representational State Transfer (REST) ​​ou RESTful é um protocolo de comunicação sem estado e interoperável. O protocolo permite identificar recursos da web (recursos informativos) por URLs exclusivos e permite entregá-los como arquivo HTTP, JSON ou XML. Os recursos são expostos como URIs de estrutura de diretório. Um cliente pode acessar recursos para mensagens GET, PUT, DELETE ou POST para representações onde as representações são objetos de dados e seus atributos em formato HTML, XML ou JSON. GET, PUT, DELETE e POST são métodos de solicitação HTTP para receber, modificar e enviar dados. Por ser uma comunicação sem estado, nenhuma confirmação é enviada ou recebida para confirmação da entrega da mensagem. No entanto, a solicitação HTTP pode ser respondida por um código de status indicando sucesso, redirecionamento, informação, erro do cliente ou erro do servidor.

MQTT-SN – MQTT-Sensor Network é um protocolo de publicação/assinatura aberto e leve projetado especificamente para dispositivos restritos, ou seja, rede de sensores sem fio (WSN). A rede de sensores sem fio que não possui pilha TCP/IP em sua parte superior, como rede de sensores sem fio baseada em Zigbee ou WSN baseada em Bluetooth, eles podem enviar seus dados para a Internet com o protocolo MQTT-SN.

O MQTT-SN foi projetado para ser o mais próximo possível do MQTT, mas é adaptado às peculiaridades de um ambiente de comunicação sem fio, como baixa largura de banda, altas falhas de link, comprimento curto de mensagens, etc. dispositivos de baixo custo, operados por bateria, com recursos limitados de processamento e armazenamento.

Comparado ao MQTT, as seguintes alterações foram introduzidas no MQTT-SN –

• Os nomes dos tópicos são substituídos por IDs de tópicos, o que reduz os custos indiretos de transmissão.

• Os tópicos não necessitam de registro, pois são pré-inscritos.

• As mensagens também são divididas para que apenas as informações necessárias sejam enviadas.

• Para conservação de energia, existe um procedimento offline para clientes que estão em estado de suspensão. As mensagens podem ser armazenadas em buffer e posteriormente lidas pelos clientes quando eles acordam.

• Os clientes se conectam ao corretor por meio de um dispositivo gateway, que reside na rede de sensores e se conecta ao corretor.

Na arquitetura do MQTT-SN, existem três tipos de componentes MQTT-SN – clientes MQTT-SN, gateways MQTT-SN (GW) e encaminhadores MQTT-SN. Os clientes MQTT-SN se conectam a um servidor MQTT por meio de um GW MQTT-SN usando o protocolo MQTT-SN. Um MQTT-SN GW pode ou não ser integrado a um servidor MQTT. No caso de um GW independente, o protocolo MQTT é usado entre o servidor MQTT e o GW MQTT-SN. Sua principal função é a tradução entre MQTT e MQTT-SN.

Os clientes MQTT-SN também podem acessar um GW por meio de um encaminhador, caso o GW não esteja diretamente conectado à sua rede. O encaminhador simplesmente encapsula os quadros MQTT-SN que recebe no lado sem fio e os encaminha inalterados para o GW; no sentido oposto, libera os frames que recebe do gateway e os envia aos clientes, também inalterados.

STOMP – Simple or Streaming Text Orientated Messaging Protocol (STOMP) é um protocolo baseado em texto para middleware orientado a mensagens. É baseado em TCP e usa comandos semelhantes a HTTP. Foi projetado para fornecer interoperabilidade entre plataformas, idiomas e corretoras. Os dados são comunicados entre um cliente e um corretor em quadros multilinhas contendo comando, cabeçalho e conteúdo. O comando pode ser CONNECT, DISCONNECT, ACK, NACK, SUBSCRIBE, UNSUBSCRIBE, SEND, BEGIN, COMMIT ou ABORT.

SMCP – Simple Media Control Protocol (SMCP) é uma pilha de protocolos CoAP para dispositivos embarcados. É desenvolvido em linguagem C e pode ser utilizado para envio e recebimento de respostas CoAP assíncronas.

LLAP – Lightweight Local Automation Protocol é um protocolo de mensagens simples e curto que pode ser executado em qualquer meio de comunicação. o protocolo foi projetado para mensagens diretas entre dispositivos incorporados, independentemente do protocolo de camada física de baixo nível usado pelos dispositivos.

SSI – Simple Sensor Interface (SSI) é um protocolo de camada de aplicação projetado para comunicação entre computadores e sensores. Baseado em UART, o protocolo permite sondar sensores e transmitir dados de sensores. Os dados são comunicados pelos sensores aos computadores em pequenos espaços de código. No protocolo, a mensagem entre o sensor e o computador contém um cabeçalho de 2 bytes e a carga útil da mensagem. O cabeçalho contém um endereço de byte único e um comando ou tipo de mensagem de byte único.

LWM2M – Lightweight M2M (LWM2M) é um protocolo de gerenciamento de dispositivos para redes de sensores. A Open Mobile Alliance (OMA) desenvolveu este protocolo para gerenciar dispositivos leves e de baixo consumo de energia em uma variedade de redes. A pilha de protocolos é baseada em REST e CoAP.

M3DA – M3DA é uma pilha de protocolos para comunicação de dados binários entre servidores M2M e aplicativos executados em gateways incorporados. Ele foi projetado para gerenciamento de dispositivos e ativos para que a largura de banda da rede seja melhor utilizada da maneira ideal.

XMPP-IOT – Assim como o XMPP é usado para comunicação interoperável, o XMPP-IOT é uma pilha de protocolos para comunicação M2M independente de máquina.

ONS 2.0 – Object Name Service (ONS) é uma pilha de protocolos para localização de metadados e serviços por meio de uma determinada chave de identificação GS1. GS1 é um padrão de mensagens comerciais eletrônicas para automação de transações comerciais em uma cadeia de suprimentos.

SOAP – Simple Object Access Protocol (SOAP) é uma pilha de protocolos baseada em XML usada para implementação de serviços da web na Internet. Ele usa métodos de solicitação HTTP para mensagens entre clientes em uma rede.

Websocket – A interface WebSocket JavaScript define uma conexão de soquete único full-duplex através da qual as mensagens podem ser enviadas entre o cliente e o servidor. O padrão simplifica a complexidade da comunicação bidirecional na Web e do gerenciamento de conexões.

Fluxos reativos – Fluxos reativos é uma pilha de protocolos para processamento de fluxo assíncrono com contrapressão sem bloqueio. É uma especificação que pode ser implementada em Java ou JavaScript. É usado para lidar com fluxos de dados ao vivo cujo volume não é conhecido.

HTTP/2 – HTTP versão 2 será a próxima versão do protocolo HTTP. Ele usará compactação de campo de cabeçalho para reduzir a latência e permitirá múltiplas trocas simultâneas na mesma conexão.

JavaScript IOT – Este não é nenhum padrão ou protocolo. Refere-se ao uso de JavaScript e particularmente Node.js (um JavaScript do lado do servidor) com placas IOT para várias aplicações. Alguns dos projetos IOT baseados em JavaScript incluem 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.

No próximo tutorial, serão discutidos serviços e nuvem IOT.