Conheça os principais protocolos para IoT 1

Já faz algum tempo que se ouve falar em Internet das Coisas (se você ainda não sabe, corre para o post Internet das Coisas: o que é IoT? que a gente te explica tudo direitinho). Com a tecnologia que temos disponível hoje, é facilmente possível encher um banco de dados com informações que antes eram feitas numa prancheta, acionar equipamentos a distância por um aplicativo ou ainda enviar dados de sensores para a nuvem. Mas e os protocolos  IoT por trás da interação entre “coisa” e internet?

Com este post seremos capazes de escolher a melhor opção de protocolo para o nosso projeto respondendo questões comuns como:

• Qual protocolo usar para conectar na internet e para enviar e receber dados?
• Os dados serão enviados 1 vez por segundo, 1 vez por minuto, 1 vez por hora, 1 vez por dia ou quando acontecer algum evento?
• Qual a segurança que os dados serão trafegados?
• E se esses dados caírem em mãos de pessoas mal-intencionadas?
• Economizar banda importa?
• É melhor enviar “0” e “1” ou “desligado” e “ligado”?
• Precisa ter confirmação que os dados foram entregues?
• E se os dados não chegarem, quais serão as consequências?
• E a bateria do meu produto (se houver)?
• O produto precisa ficar “ouvindo” a internet o tempo todo ou dá pra entrar em modo de economia de energia?

Enfim, daria para levantar ainda mais pontos para ajudar a compor nosso produto IoT, mas a questão é: quais protocolos IoT melhor atendem as nossas necessidades?

Os protocolos IoT estão separados em três camadas: física, transporte e aplicação e vamos explicar cada uma delas abaixo. Confira!

Protocolos IoT da camada física

Ethernet (IEEE 802.3)

Apesar de ser um padrão desenvolvido no final da década de 70, a Ethernet ainda é muito utilizada em indústrias e residências. A Ethernet é um tipo de conexão com fio, ou seja, depende de cabos para que a conexão com a internet ocorra. Portanto, se a ligação de fios não é um problema para você, esse tipo de conexão pode ser uma boa opção, pois ela garante uma alta velocidade na troca de dados por um baixo custo.

A conexão Ethernet pode ser encontrada em placas de desenvolvimento como a Raspberry Pi 3 Model B+, ou em shields para Arduino, como o Ethernet Shield W5100 (imagem acima).

Vantagem: Alta velocidade, baixo custo.

Desvantagem: A conexão é feita por cabos.

Wi-Fi (IEEE 802.11)

Bom, mas como nem tudo na vida é um mar de rosas, nem sempre temos a disposição um cabo prontinho ali esperando para trafegar os dados do nosso produto. Então é agora que a brincadeira começa. Imagine que você recebeu um projeto com os seguintes requisitos: deve ser sem fio, num lugar que não tem eletricidade e deserto. Agora, faça um LED piscar nesse lugar (haha)! Brincadeiras à parte, vamos para os protocolos wireless.

Atualmente, o protocolo Wi-Fi atua nas frequências 2,4 GHz e 5 GHz. Quanto maior a frequência, maior a taxa de transferência porém menor o alcance do sinal. Quando a instalação de cabos não é uma opção para seu projeto, mas no local possui uma rede ligada à internet e um roteador, o protocolo Wi-Fi pode ser o mais indicado.

Para conhecer melhor os protocolos de autenticação e aprender a deixar sua rede Wi-Fi mais segura acesse o post Aumente o nível de segurança da Wi-Fi com a Raspberry Pi.

Podemos encontrar o protocolo Wi-fi na frequência 2,4 GHz em placas de desenvolvimento como o ESP8266 (imagem acima) e o ESP32.

Vantagem: Elimina a necessidade de cabos para a comunicação.

Desvantagem: Sinal de curto alcance.

Redes Móveis

As redes móveis sempre estiveram presentes em projetos embarcados que precisavam de acesso à internet. Os módulos com comunicação GSM/GPRS, assim como suas evoluções (com redes 3G e 4G) são os mais conhecidos quando estamos falando de redes móveis. Porém, um grande problema para esse tipo de comunicação é a cobertura do sinal, principalmente para projetos voltados para o agronegócio.

Por isso as empresas de telefonia estão começando a trabalhar com protocolos voltados para o IoT que utilizam redes móveis (como o NB-IoT e o LTE-M). Eles prometem um alcance de sinal melhor e também um menor consumo de bateria (ponto muito relevante para projetos IoT).

Podemos encontrar o módulo GSM/GPRS em forma de shield para Arduino, como o GSM GPRS Shield para Arduino EFCom SIM900 + Antena (imagem acima).

Vantagem: Possui um bom custo benefício

Desvantagem: Consumo de bateria e área de cobertura limitada (desconsiderando NB-IoT e LTE-M)

LPWA – Low Power Wide Area

As redes que vêm conquistando espaço no mundo IoT também, são as LPWA (Low Power Wide Area), com destaque para LoraWAN e Sigfox. Como o próprio nome diz, são redes voltadas para baixo consumo de energia e que conseguem trafegar dados a longa distância (distância exata depende de vários fatores que podem atenuar o sinal de rádio-frequência, mas falamos na casa dos km).

Com largura de banda baixa, devemos trafegar mensagens curtas por essas redes. Por isso é ideal para monitoramento de sensores que não precisam ficar enviando dados sem parar (tanto é que a Sigfox possui limite de mensagens diárias que podem ser trafegadas pela rede).

Podemos encontrar placas de desenvolvimento que suportem LoRa, como esse módulo ESP32 LoRa SX1276 868/915 MHZ com OLED (imagem acima).

Vantagem: Possui longo alcance e baixo consumo de energia.

Desvantagem: Baixo tráfego de dados, limite de mensagens/dia (sigfox).

6LoWPAN – IPv6 over Low power Wireless Personal Area Network

Com o aumento dos equipamentos conectados na internet, a faixa de IPs disponíveis utilizados com o protocolo IPv4 diminui. Quando os pesquisadores perceberam que isso seria um problema, começaram os estudos para o desenvolvimento do protocolo IPv6. Para não ter perigo de que um dia falte IP para alguém exageraram tanto que hoje daria para cada gota do oceano ter seu próprio endereço IP!

Baseado no IPv6, temos a tecnologia 6loWPAN (IPv6 over Low power Wireless Personal Area Network), que permite trafegar dados via IPv6 pela rede WPAN padrão 802.15.4. Quando nos referimos a WPAN (Wireless Personal Area Network), falamos de curtas distâncias. Um bom exemplo de WPAN é a rede formada entre um mouse sem fio e o dongle bluetooth USB.

O termo low power do 6LoWPAN vem da baixa largura de banda utilizada e também do gerenciamento inteligente do rádio. Por não trabalhar o tempo todo com o rádio ativo, ao ligar o rádio, o dispositivo envia uma pergunta para saber se há alguma mensagem para ele.

Abaixo um módulo RF compatível com o padrão 802.15.4 para ser utilizado em redes 6loWPAN.

Vantagem: Compatibilidade com IPv6 e baixo consumo de energia.

Desvantagem: Sinal de curto alcance.

Protocolos IoT da camada de transporte

Bom, até agora vimos os protocolos de camadas física, que são protocolos que determinam o meio e como serão conectados os dispositivos que compõem a rede. Agora veremos os protocolos IoT da camada de transporte, TCP e UDP.

TCP / UDP

A principal diferença entre os protocolos TCP e UDP é que TCP é orientado a conexão e UDP não. Mas o que isso significa? Vamos lá, quando você tem dois dispositivos comunicando via TCP, o TCP segura uma conexão para esses dispositivos e para encerrá-la, ambos os dispositivos devem sinalizar que estarão encerrando a conexão.

Quando essa conexão está estabelecida, temos controle de fluxo, retransmissões de pacotes perdidos, sinalização para rede congestionada, fragmentação de pacotes, handshake para cada pacote enviado, número de sequência de pacote, entre outros… Já o protocolo UDP, por não ser orientado a conexão, a comunicação é mais simples.

Os dados são enviados para um destino e pronto, o UDP não segura uma conexão, um dispositivo não se conecta em outro! No máximo tem um checksum no cabeçalho do frame enviado. Neste caso, você não tem nenhum controle se o pacote foi recebido, sendo assim, pode ser necessário implementar algum tipo de confirmação em nível de aplicação.

Determinar se você vai utilizar TCP ou UDP, vai depender muito da sua aplicação. O TCP é mais confiável e tem o QoS bacana. Mas ás vezes todo esse “overhead” gerado pelo protocolo TCP pode ser desnecessário para certos tipos de aplicações. Um exemplo é um streaming de mídia em tempo real.

Se você está assistindo uma transmissão ao vivo, e um frame do vídeo não foi entregue, não é interessante que o vídeo fique parando para recuperar os pacotes perdidos ou ainda que você veja o frame em ordem errada, por isso essas aplicações utilizam UDP.

Abaixo, vemos a diferença do cabeçalho de pacotes TCP e UDP, percebam quanta informação a mais o cabeçalho TCP têm em relação ao cabeçalho UDP.

Essa explicação dos protocolos TCP e UDP foi bastante superficial, é mais para termos uma base para o nosso próximo assunto, que são os protocolos da camada de aplicação. Assim quando eu falar se o protocolo é baseado em TCP ou UDP vocês já sabem no que isso impacta.

Protocolos IoT da camada de aplicação

MQTT – Message Queue Telemetry Transport

Acredito que esse seja o protocolo para IoT mais famoso na comunidade maker. Ele é baseado em TCP com segurança SSL, é um protocolo conceituado como M2M. Ou seja, quando se tem dois ou mais dispositivos trocando informações entre si, essas informações são utilizadas por esses dispositivos para fazerem ou não determinada ação.

A troca de mensagens entre os dispositivos se dá pelo padrão pub / sub, ou seja, as mensagens têm como destino tópicos. Assim sendo, um dispositivo pode publicar uma mensagem em um tópico e um ou mais dispositivos podem estar subscritos em determinados tópicos (nada impede de um dispositivo ser publicador e também ser subscrito de algum tópico).

Esses tópicos ficam centralizados em um servidor, também chamado de broker, que é o responsável por receber as mensagens e enviá-las para os dispositivos interessados. Conheça um pouco mais sobre MQTT nesse post.

Vantagem: Alta confiabilidade, QoS garante entrega das mensagens.

Desvantagem: Não é escalável para um número grande de dispositivos conectados em um broker.

CoAP – Constrained Application Protocol

É um protocolo bem leve, feito para microcontroladores com footprint baixo. Baseado em UDP com segurança DTLS. Também conceituado como M2M, possui um mecanismo que permite descobrir os dispositivos que estão na rede comunicando sobre o protocolo CoAP. Cada mensagem possui um ID e pode ser sinalizada para receber uma confirmação ou não do dispositivo que receber a mensagem. As mensagens seguem o formato de requisições e respostas.

Como já falamos,  o UDP não implementa nenhum tipo de confirmação ou controle de fluxo, por isso as mensagens possuem ID (para identificar se é uma mensagem retransmitida) e confirmação de recebimento. No site oficial do protocolo tem vários exemplos em várias linguagens de aplicações tanto client quanto server para utilizar o protocolo CoAP.

Vantagem: Necessita de pouco recurso para implementar o protocolo.

Desvantagem: Payload pequeno das mensagens.

AMQP – Advanced Message Queuing Protocol

É um protocolo baseado em TCP com segurança TLS. Uma característica interessante é a sua arquitetura flexível, que permite que as trocas de mensagens sejam configuradas como mensagem direta, pub/sub ou broadcast. No início do desenvolvimento do protocolo AMQP, o projeto recebeu apoio de grandes empresas como Red Hat e Cisco.

Há duas versões importantes nesse protocolo, a primeira é a 0.9 que é suportada pelo broker mais utilizado em AMQP (rabbitMQ), e a segunda é a 1.0, que é a versão regulamentada no padrão ISO/IEC 19464.

Na versão 0.9, quando uma mensagem é recebida pelo broker, ela é tratada por um mecanismo interno chamado de exchange. Este é responsável por separar as mensagens e colocá-las nas filas que interessam para as aplicações que irão receber essas mensagens (chamadas de consumers).

As configurações que contêm o destino das mensagens e outros critérios para enfileiramento destas são chamadas de binding. É possível enviar vários tipos de mensagens, desde mensagens básicas, até streaming de áudio/vídeo e voz.

Na versão 1.0, o exchange foi descontinuado e o protocolo agora tem três itens importantes: container, nodes e link. Pode-se dizer que o link ficou no lugar do exchange; nodes são as filas; e os tópicos e containers são onde os nodes ficam, podendo ser as aplicações e os brokers.

Portanto, o papel do link é interligar os nodes que ficam agrupados em containers.

Vantagem: arquitetura flexível, bastante seguro.

Desvantagem: versão mais nova não é compatível com a versão anterior, que é a mais utilizada.

XMPP – Extensible Message and Presence Protocol

O Protocolo XMPP é baseado em TCP e com segurança SASL e TLS. Sua arquitetura é client e server (apenas uma observação, no protocolo XMPP, um server também pode comunicar com outro server).

Seu workflow é baseado em troca de mensagens utilizando XML (por isso o ‘X’ no nome do protocolo) e também é utilizado para verificar o status de um dispositivo ou aplicação na rede (por isso o ‘P’ de Presence no nome do protocolo).

É um protocolo bastante utilizado para aplicações em que se deseja saber o status de um endpoint e aplicações de mensagens instantâneas.

Mas também é possível ter uma aplicação com troca simples de mensagens, pub/sub ou até mesmo streaming de mídia.  Grandes empresas utilizam o XMPP em suas aplicações, são alguns exemplos: Google (Google Talk), Apple (push notification dos IPhones e IPads), Nintendo (plataforma Nintendo Switch), WhatsApp (utilizam uma variação do XMPP, o FunXMPP), Fortnite e League of Legends (status: online/offline).

No site oficial do protocolo há vários códigos fonte para aplicações client/server, bibliotecas em várias linguagens e plataformas para serem utilizadas de acordo com as finalidades citadas aqui. Vale a pena dar uma conferida.

Vantagem: arquitetura descentralizada, troca de mensagens com payloads pesados.

Desvantagem: exige um dispositivo com alto footprint para implementar o protocolo.

DDS – Data Distribution Service

O protocolo DDS é baseado em sua maior parte em TCP com segurança TLS e um protocolo proprietário chamada DDS Security, mas também utiliza UDP com segurança DTLS para mensagens broadcast, seu funcionamento também é pub/sub, porém sua arquitetura descentralizada permite comunicação P2P.

Possui um mecanismo interno que permite descobrir os dispositivos que estão na rede (Dynamic Discovery), assim como o CoAP.

A filosofia do protocolo é facilitar ao máximo a vida do desenvolvedor, para que ele tenha que se preocupar apenas em enviar mensagens para o DDS Domain. Para isso, utiliza um conceito de middleware (intermédio entre aplicação e sistema operacional), onde fica localizada toda a complexidade da lógica de negócio do protocolo.

É bastante flexível com relação aos dados. Você pode configurar limites de mensagens, horários, de quanto em quanto tempo enviá-las, se estas serão armazenadas ou apagadas do DDS Domain ou ainda enviar mensagens apenas se satisfizerem determinado critério (ex.: enviar dados de um sensor de temperatura apenas se estiver acima de 40°C).

Além disso, também é possível trabalhar com triggers, exemplo: se chegar certo tipo de mensagem, dispara para a aplicação fazer uma determinada ação. O protocolo possui um QoS que prioriza economia de tráfego na rede, confiabilidade, gerenciamento no uso de recursos e garantia na entrega das mensagens.

Vantagem: comunicação P2P.

Desvantagem: consome mais largura de banda em relação a outros protocolos IoT, como o MQTT.

HTTP – HyperText Transfer Protocol

HTTP é um protocolo muito utilizado na web, pois acompanha a World Wide Web desde o início, sendo o protocolo utilizado para server e navegadores se comunicarem. É baseado em TCP com segurança TLS.

A troca de mensagens se dá a partir de requisições e respostas, sendo um protocolo client/server. Por ser um protocolo bastante difundido, com bastante material na internet, a comunidade maker acaba utilizando bastante em aplicações IoT. Basicamente, mensagens simples contêm:

• Cabeçalho com as informações de versão do protocolo
•  O método que determina a finalidade da mensagem (os mais utilizados são: GET, POST, PUT e DELETE)
• Tipo de dado que tem no corpo da mensagem (também conhecido como MIME-type (Multiporpose Internet Mail Externsions). Criado junto com as primeiras aplicações de correio eletrônico, informa o tipo da mensagem que o corpo do e-mail continha.
•  Em seguida, vem o corpo da mensagem em si.

Existem ainda muitas opções que podem ser inseridas no cabeçalho: como versão de navegador, status da conexão, última vez que a aplicação foi modificada ou acessada, charset, linguagem, cookies.

Na versão 1.0 do protocolo, a cada troca de mensagem, a conexão era aberta e em seguida encerrada.

A partir da versão 1.1 já é possível abrir a conexão, enviar uma requisição, receber uma resposta, enviar outra requisição, receber outra resposta, até que se determine encerrar a conexão conscientemente ou por timeout de conexão inativa.

Utilizando uma técnica chamada pipelining é possível enviar mais de uma requisição sem ter recebido resposta das requisições anteriores.

Vantagem: Bastante difundido, encontra muito material na internet.

Desvantagem: alto consumo de energia.

Conclusão

O objetivo do post foi dar uma visão geral dos principais protocolos  que estão sendo utilizados em aplicações IoT, desde a camada física até a camada de aplicação. Apesar da Internet das Coisas ser algo relativamente recente, os protocolos que a permeiam nasceram, há pelo menos 15 ou 20 anos atrás (exceto CoAP que possui 6 anos).

E você conhece outros protocolos IoT que ficaram de fora do post? Então comenta aí embaixo e contribua para a disseminação de conteúdo para a comunidade. Muito obrigado e até a próxima!