O Protocolo CoAP para IoT

Já falamos um pouco sobre o protocolo CoAP (Constrained Application Protocol – Protocolo de Aplicação Restrita) para a IoT (Internet of Things – Internet das coisas) aqui. Agora, neste artigo, voltamos com mais detalhes sobre esse protocolo definido pela RFC 7252.

O CoAP é um protocolo de transferência web especializado para uso com nós restritos em redes da Internet das Coisas. O protocolo é projetado para M2M (de máquina-para-máquina), como, por exemplo, aplicações em energia inteligente e automação predial.

O modelo de interação do CoAP é semelhante ao modelo cliente/servidor do protocolo HTTP. No entanto, as interações máquina-máquina normalmente resultam em uma implementação do CoAP que atua nas funções do cliente e do servidor.

Um pedido CoAP é equivalente ao do HTTP e é enviado por um cliente para solicitar uma ação (usando um Código de Método) em um recurso (identificado por uma URI) em um servidor. O servidor envia uma resposta com um código, sendo que esta resposta pode incluir uma representação de recursos.

Ao contrário do HTTP, o CoAP lida com esses intercâmbios de forma assíncrona ao longo de um transporte orientado a datagramas, como o UDP. Isso é feito logicamente usando uma camada de mensagens que suporta uma confiabilidade opcional (com back-off exponencial). O CoAP define quatro tipos de mensagens:

  • confirmação;
  • não confirmação;
  • reconhecimento;
  • reset.

O protocolo CoAP se posiciona, na arquitetura TCP/IP, entre as camadas de Aplicação e Transporte, criando duas subcamadas – Requisição/Resposta e Mensagem, conforme figura 1.

 

Posição do protocolo CoAP na Arquitetura TCP/IP
Figura 1 – Posição do protocolo na Arquitetura TCP/IP

 

Modelo de Mensagens

O modelo de mensagens CoAP baseia-se na troca de mensagens UDP entre os pontos finais, sendo que o CoAP usa um pequeno cabeçalho binário de comprimento fixo (4 bytes) que pode ser seguido de opções binárias compactas e uma carga útil. Este tipo de mensagem compartilha tanto as solicitações como as respostas.

Cada mensagem contém um identificador (ID) de mensagem usado para detectar duplicatas e para uma confiabilidade opcional. O ID da mensagem é compacto e seu tamanho de 16 bits permite até cerca de 250 mensagens por segundo, de um ponto final para outro, estabelecendo parâmetros desta conexão.

A confiabilidade é fornecida marcando uma mensagem como confirmável (CON). Uma mensagem confirmável, figura 2, é retransmitida usando um tempo limite padrão entre retransmissões, até o destinatário, enviando uma mensagem de confirmação (ACK) com o mesmo ID de mensagem.

 

Figura 2 – Transmissão de uma mensagem confiável
Figura 2 – Transmissão de uma mensagem confiável

 

Quando um destinatário não é capaz de processar uma mensagem como confirmável (não é capaz de fornecer uma resposta de erro adequada), ele responde com uma mensagem Reset (RST) em vez de um reconhecimento (ACK).

Uma mensagem que não requer transmissão confiável (por exemplo, uma única medida fora de um fluxo de dados de um sensor) pode ser enviada como uma mensagem não confirmável (NON). Estas não são reconhecidas, mas ainda têm um ID de mensagem para detecção duplicada (neste exemplo, 0x01a0, figura 3). Quando um destinatário não for capaz de processar uma mensagem não confirmável, pode-se responder com uma mensagem Reset (RST).

 

Figura 3 - Transmissão de mensagem não confirmável
Figura 3 – Transmissão de mensagem não confirmável

 

Como o CoAP é executado sobre UDP, que é um protocolo não confiável, também suporta o uso dos endereços multicast IP de destino, permitindo solicitações multicast CoAP, como precaução para evitar o congestionamento da resposta.

Vários modos de segurança são definidos para CoAP, que vão desde sem segurança para segurança baseada em certificados. A RFC especifica uma ligação ao DTLS para garantir o protocolo. O uso do IPsec com o CoAP também é discutido na RFC em [IPsec-CoAP].

 

Modelo de Solicitação/Resposta

A solicitação de CoAP e a semântica de resposta são realizadas nas mensagens do CoAP, que incluem um Código de Método ou Código de Resposta, respectivamente.

Informações de solicitação e resposta opcionais (ou padrão), como a URI, e tipo de mídia de carga são transportados como opções CoAP. Um Token é usado para corresponder as respostas aos pedidos, independentemente das mensagens subjacentes. (Observe que o Token é um conceito separado a partir da identificação da mensagem.)

Uma mensagem de pedido a um determinado elemento da IoT é enviada como confirmável (CON) ou não-confirmável (NON) e, se disponível imediatamente, a resposta a um pedido é também transportada em uma mensagem de confirmação (ACK), conforme figura 4. Isso é chamado de resposta piggybacked. (Não há necessidade de reconhecimento de uma das respostas encaminhadas, uma vez que o cliente irá retransmitir o pedido, se a mensagem de resposta for perdida). Na figura 4, temos dois exemplos para um pedido GET básico de um determinado valor de temperatura em um sensor, com uma resposta, mostrando o caso bem-sucedido com o retorno de 22,5ºC e um caso com erro ou resultando em uma resposta 4.04 (não encontrada).

 

Figura 4 – Dois pedidos GET com respostas encadeadas
Figura 4 – Dois pedidos GET com respostas encadeadas

 

Se o servidor não puder responder imediatamente a uma solicitação realizada em uma mensagem confirmável, ele simplesmente responde com um vazio de mensagem de confirmação para que o cliente possa parar de retransmitir o pedido. Quando a resposta está pronta, o servidor envia-o em uma nova mensagem confirmável (que, por sua vez, deve ser reconhecida pelo cliente). Isso é chamado de “resposta separada”, como ilustrado na figura 5.

 

Figura 5 – um pedido GET com uma resposta separada
Figura 5 – um pedido GET com uma resposta separada

 

Se uma solicitação for enviada em uma mensagem não confirmável, a resposta é enviada usando uma nova mensagem não confirmável, embora o servidor possa, em vez disso, enviar uma mensagem confirmável. Esse tipo de troca é ilustrado na figura 6.

 

Figura 6 – Um pedido e uma resposta realizada em mensagens não confirmáveis
Figura 6 – Um pedido e uma resposta realizada em mensagens não confirmáveis

 

O CoAP faz uso de métodos GET, PUT, POST e DELETE de forma semelhante ao HTTP. A semântica detalhada dos métodos CoAP possui algumas diferenças dos métodos HTTP. Para quem vai trabalhar com este protocolo, vale a pena ler a RFC para maior detalhamento e as diferenças em relação ao HTTP.

Além dos quatro métodos básicos mencionados anteriormente, podem ser adicionados ao CoAP, em separado, novos métodos que não precisam necessariamente usar pedidos e respostas em pares. Mesmo para os métodos existentes, um único pedido pode produzir respostas múltiplas, por exemplo, para um pedido de multicast  com a opção Observe (Observe especifica uma extensão de protocolo simples para CoAP que permite aos clientes do CoAP “observar” os recursos, ou seja, recuperar uma representação de um recurso e manter esta representação atualizada pelo servidor durante um período de tempo).

O suporte a URI em um servidor é simplificado, já que o cliente já analisa o URI e o divide em componentes de host, porta, caminho e consulta, fazendo uso de valores padronizados. Os códigos de resposta se relacionam para um pequeno subconjunto de códigos de status HTTP com alguns códigos específicos do CoAP.

 

Conclusão

Do ponto de vista do desenvolvedor, o CoAP se parece muito com o HTTP. Obter um valor de um sensor de pressão, temperatura, entre outros, não é muito diferente de obter um valor de uma API da Web.

Como o HTTP e o CoAP compartilham o modelo REST, eles podem ser facilmente conectados usando proxies inter-protocolos independentes do aplicativo. Um cliente da Web pode nem sequer perceber que ele acessou apenas um recurso de sensor.

 

Bibliografia

RFC 7252 – The Constrained Application Protocol (CoAP) – IETF Tools

 

Protocolos Envolvidos na IoT

Trabalha-se para definir um modelo ou arquitetura para a IoT (Internet of Things – Internet das Coisas), mas já existem alguns protocolos que estão na vanguarda desta tecnologia. São os protocolos CoAP, MQTT, XMPP e AMQP.

Neste artigo, estaremos apresentando, de forma resumida, a função de cada um destes protocolos para que possamos tratar mais profundamente os elementos sensores, o transporte de informação e a atuação de elementos por meio de aplicações.

 

CoAP (Constrained Application Protocol)

CoAP (Constrained Application Protocol – Protocolo de Aplicação Restrita), definido pela RFC 7252, é um protocolo de transferência Web especializado para uso com nós restritos e redes na Internet das Coisas. O protocolo é projetado para M2M (de-máquina-para-máquina), como, por exemplo, aplicações em energia inteligente e automação predial.

Como o HTTP, o CoAP é baseado no modelo REST: servidores disponibilizam recursos em um URL e os clientes acessam esses recursos usando métodos como GET, PUT, POST e DELETE.

Do ponto de vista do desenvolvedor, o CoAP se parece muito com o HTTP. Obter um valor de um sensor de pressão, temperatura, entre outros, não é muito diferente de obter um valor de uma API da Web.

Como o HTTP e o CoAP compartilham o modelo REST, eles podem ser facilmente conectados usando proxies inter-protocolos, independentes do aplicativo. Um cliente da Web pode nem sequer perceber que ele acessou apenas um recurso de sensor.

Como o HTTP, o CoAP pode carregar diferentes tipos de cargas úteis e pode identificar qual tipo de carga útil está sendo usado. CoAP integra-se com XML, JSON, CBOR, ou qualquer formato de dados de sua escolha.

A Internet das Coisas precisará de bilhões de nós, muitos dos quais precisam ser baratos. CoAP foi projetado para trabalhar com microcontroladores com baixa capacidade de memória como 10 KiB de RAM e 100 KiB de espaço de código (RFC 7228).

O CoAP foi projetado para usar recursos mínimos, tanto no dispositivo quanto na rede. Em vez de uma pilha de transporte complexa, é encapsulado no UDP e no IP respectivamente.  Um cabeçalho fixo de 4 bytes e uma codificação compacta de opções permite mensagens pequenas que causam pouca ou nenhuma fragmentação na camada de enlace. Muitos servidores podem operar de uma forma completamente sem estado, além de permitir um diretório de recursos que fornece uma maneira de descobrir as propriedades dos nós em sua rede.

Este protocolo foi projetado para durar décadas, principalmente levando em conta o controle de congestionamento usando o estado da arte.

Em relação à segurança, o CoAP utiliza parâmetros DTLS, que é equivalente a chaves RSA de 3072 bits, funcionando bem nos menores nós.

 

MQTT (Message Queue Telemetry Transport)

O MQTT é um protocolo de conectividade de-máquina-para-máquina (M2M) também utilizado em Internet das Coisas. Foi projetado para ser extremamente leve e publicar/subscrever o transporte de mensagens. É útil para conexões remotas com pequena largura de banda, como é o caso de informações extraídas de sensores. Por exemplo, tem sido utilizado em sensores que se comunicam por meios físicos via satélite ou numa gama de domótica e cenários de dispositivos pequenos. Também é ideal para aplicações móveis devido ao seu pequeno tamanho, baixo consumo de energia, pacotes de dados minimizados e distribuição eficiente de informações para um ou mais receptores.

O MQTT foi projetado para redes de baixa largura de banda e alta latência no final da década de 1990/início de 2000. Como resultado, os designers fizeram uma série de escolhas fundamentais que influenciaram a forma como “olha e sente”, além de fornecer um sólido bloco de construção que pode ser facilmente integrado em outras soluções.

É útil para a maioria das aplicações de sensor e permite que os dispositivos fiquem online e publiquem “material” que não tenha sido previamente conhecido ou predefinido.

Arquitetura:

  • MQTT tem um modelo cliente/servidor, onde cada sensor é um cliente e se conecta a um servidor, conhecido como um agente (broker), sobre TCP.
  • MQTT é orientado a mensagem. Cada mensagem é um pedaço discreto de dados, opaco para o agente.
  • Cada mensagem é publicada para um endereço, conhecido como um tópico. Os clientes podem assinar vários tópicos. Cada cliente inscrito em um tópico recebe todas as mensagens publicadas no tópico.

Exemplo:

Imagine uma rede simples com três clientes e um agente central. Todos os três clientes abrem conexões TCP com o agente. Os Clientes B e C subscrevem a temperatura do tópico, como mostra a figura 1.

 

Exemplo Protocolo MQTT
Figura 1 – Exemplo Protocolo MQTT

 

Posteriormente, o Cliente A publica um valor de temperatura de  22,5 ºC para a temperatura do tópico. O agente encaminha a mensagem para todos os clientes inscritos, como na figura 2.

 

Exemplo Protocolo MQTT
Figura 2 – Exemplo Protocolo MQTT

 

O modelo de assinante permite que clientes MQTT comuniquem-se de um-para-um, um-para-muitos e muitos-para-um.

 

XMPP (Extensible Messaging and Presence Protocol)

O XMPP é um protocolo para streaming de elementos XML (Extensible Markup Language), a fim de trocar mensagens e informações de presença em tempo aproximado. O principal recurso do XMPP é: Core [XMPP-CORE]. Esse recurso, principalmente os fluxos de XML, fornecem os blocos de construção para muitos tipos de eventos, quase reais, que podem ser colocados em camadas no topo do núcleo enviando dados específicos do aplicativo qualificados por espaços de nomes XML específicos [XML-NAMES].

É um protocolo de comunicação para middleware orientado a mensagens, baseado em XML. Permite o intercâmbio em tempo quase real de dados estruturados, porém extensíveis, entre quaisquer duas ou mais entidades de rede. Originalmente chamado Jabber, o protocolo foi desenvolvido pela comunidade de código aberto Jabber em 1999 para mensagens instantâneas em tempo real (IM), informações de presença e manutenção de listas de contatos. Projetado para ser extensível, o protocolo tem sido usado também para sistemas de subscrição de publicação, sinalização para VoIP, vídeo, transferência de arquivos, jogos etc.

Ao contrário da maioria dos protocolos de mensagens instantâneas, o XMPP é definido em um padrão aberto e usa uma abordagem de sistemas abertos de desenvolvimento e aplicação, através da qual qualquer pessoa pode implementar um serviço XMPP e interoperar com implementações de outras organizações. As implementações podem ser desenvolvidas usando qualquer licença de software. Embora muitas implementações de servidor, cliente e biblioteca sejam distribuídas como software livre e de código aberto, também existem numerosas implementações de software comercial.

 

AMQP (Advanced Message Queuing Protocol)

AMQP é um padrão aberto para passar mensagens de negócios entre aplicativos ou organizações. Ele conecta sistemas, alimenta os processos de negócios com as informações de que eles precisam, transmitindo de forma confiável as instruções que atingem seus objetivos, criando interoperabilidade entre clientes e intermediários (ou seja, middleware de mensagens). O objetivo é permitir que uma ampla gama de diferentes aplicações e sistemas sejam capazes de trabalhar em conjunto com mensagens padronizadas em escala industrial.

O AMQP inclui definições tanto para a forma como a rede deve funcionar, como para a forma que os aplicativos de mensagens de agente funcionam. Isto significa que as especificações são para:

  • operações de roteamento e armazenamento de mensagens;
  • definir um conjunto de regras de funcionamento dos componentes envolvidos;
  • implementar como as comunicações entre os clientes e os agentes que executam as operações funcionam.

 

Conclusão:

A Internet das Coisas concebeu um sistema de sensores onipresentes conectando o mundo físico à Internet. Embora as coisas, a Internet e a conectividade sejam os três componentes principais da IoT, ainda é necessário trabalhar as lacunas entre os mundos físico e digital. Vamos estar atentos às oportunidades que esta tecnologia irá nos proporcionar.

 

Bibliografia

http://coap.technology/

https://eclipse.org/community/eclipse_newsletter/2014/february/article2.php

https://xmpp.org/rfcs/rfc3921.html

https://www.amqp.org/