IV SRST SEMINRIO DE REDES E SISTEMAS DE TELECOMUNICAES
INSTITUTO NACIONAL DE TELECOMUNICAES INATEL
ISSN 2358-1913
AGOSTO DE 2016
Internet das Coisas: o desafio de estabelecer um
padro nico de protocolo
Henrique Osako1 & Edson Josias Cruz Gimenez2
AbstractThis document presents the knowledge acquired
through researches, the concept, definitions and challenges
regarding the Internet of Things. Also describes, the challenge to
find an unique protocol standard to be used in all devices and
services. In this article, 4 of these protocols, 6LoWPAN, ZigBee,
MQTT and CoAP, are presented with their definitions, their
mains features, for which environments are recommended and
highlighting why they are candidates to become this unique
standard.
Index Terms Internet of Things, challenge, protocol, devices,
services.
ResumoEste documento apresenta os conhecimentos
adquiridos atravs de pesquisas, os conceitos, definies e
desafios a respeito da Internet das Coisas. Descreve tambm, o
desafio em se encontrar um padro nico de protocolo para ser
utilizado em todos os dispositivos e servios. Neste artigo, 4 desses
protocolos, 6LoWPAN, ZigBee, MQTT e CoAP, so apresentados
com suas definies, suas caractersticas principais, para quais
ambientes so aconselhveis e destacando porque so candidatos
a esse padro nico.
Palavras chaveInternet das Coisas, desafio, protocolo,
dispositivos, servios.
I. INTRODUO
As revolues so consideradas mudanas ou
transformaes radicais que rompem uma ordem j
estabelecida, dessa forma quando se fala de revoluo da
internet, imediatamente lembra-se da primeira revoluo que,
sem dvida nenhuma, foi a comunicao entre computadores e
dados, onde a internet era utilizada principalmente no meio
acadmico para pesquisas. Logo em sequncia, na memria
recente, a comunicao de pessoas e processos, que marca a
era das redes sociais.
A Internet das Coisas vem sendo tratada como mais uma
revoluo, tendo como principal objetivo conectar numa
infraestrutura comum a internet, as pessoas e as coisas, que
podem ser objetos reais ou virtuais, tais como um dispositivo
ou um servio web [1].
O futuro finalmente parece estar chegando, os sonhos
futursticos que antes pareciam impossveis comeam a
parecer alcanveis. Aquela ideia de casa inteligente que se
via nos filmes, capaz de regular a temperatura e acender as
luzes conforme o gosto de quem l reside, permitir acordar
Trabalho de Concluso de Curso apresentado ao Instituto Nacional de
Telecomunicaes, como parte dos requisitos para a obteno do Certificado
de Ps-Graduao em Engenharia de Redes e Sistemas de Telecomunicaes
e Desenvolvimento de Software. Orientador: Prof. Msc. Edson Josias Cruz
Gimenez. Trabalho aprovado em 08/2016.
com um alarme que consegue avisar a cafeteira que est na
hora de preparar o caf, parece estar cada vez mais se
tornando realidade.
Inmeros benefcios esto sendo trazidos por essa onda
revolucionria, e o mais importante, existem j inmeros
projetos da Internet das Coisas que prometem at mesmo
reduzir a diferena existente entre ricos e pobres, alm disso,
estima-se ainda que em 2020 sero 50 bilhes de dispositivos
conectados internet e desses, uma incrvel mdia de 6,58
dispositivos conectados por pessoa [2].
Infelizmente, junto com as novas ideias, sempre surgem
inmeros desafios e, sem dvida nenhuma, um dos maiores
desafios da Internet das Coisas estabelecer um padro nico
de protocolo [3]. Dentro deste contexto, esse trabalho visa
apresentar e detalhar algumas das principais caractersticas de
quatro dos principais protocolos candidatos a se tornarem esse
padro nico, dentre inmeros existentes no mercado, sendo
eles: 6LoWPAN, ZigBee, MQTT e CoAP.
II. PROTOCOLOS PARA INTERNET DAS COISAS
A Internet das Coisas possui inmeros protocolos
disponveis, sendo a maioria deles baseado em IP (Internet
Protocol), fazendo uso de diferentes redes j disponveis como
Wi-Fi, Ethernet, celular, entre outras. Dentre esses vrios
protocolos, quatro deles tem ganhado destaque em diferentes
aplicaes de IoT, sendo suas principais caractersticas
apresentadas a seguir.
A. 6LoWPAN
O 6LoWPAN um acrnimo para IPv6 over Low Power
Wireless Personal Area Network, ou seja, um protocolo ou
padro de comunicao que permite com que dispositivos de
baixo consumo de energia se comuniquem e troquem dados
atravs de uma rede j existente do tipo rea pessoal sem fio,
WPAN (Wireless Personal Area Network) .
A IETF (Internet Engineering Task Force) define na RFC
(Request for Comments) 6282 o 6LoWPAN como um
protocolo ou padro aberto. A vantagem de se ter um
protocolo aberto a independncia de fabricantes, e
consequentemente, uma reduo nos custos dos dispositivos
em funo da concorrncia que naturalmente surge no
mercado. Alm disso, os protocolos abertos como o
6LoWPAN, ZigBee, MQTT e COAP so adequados para o
uso em dispositivos com baixo consumo de energia, baixa
memria e microcontroladores com baixo poder de
processamento [4].
 O IETF IPv6 (Internet Protocol version 6) define tambm
uma camada intermediria, chamada camada de adaptao
(adaptation layer), com o objetivo de mapear os endereos do
IEEE820.15.4 nos endereos IPv6 [5].
A camada de adaptao capaz de realizar a compresso
dos cabealhos para sua transmisso na rede, realizando
tambm a fragmentao e remontagem dos pacotes quando
necessrio, caso em que a MTU (Maximum Transmission
Unit) da camada fsica menor do que o mnimo especificado
pelo IPv6. Alm disso, tambm permitida a emulao de
broadcast e o suporte a protocolos de roteamento para as redes
em malha (mesh).
O 6LoWPAN trabalha nas camadas 1, 2 e 3 para
transmisso de dados, conseguindo assim agilizar o processo
sem complexidades [6]. A figura 1 mostra uma comparao
entre o padro 6LoWPAN em relao ao modelo de referncia
ISO/OSI.
Fig. 1. Comparao entre o padro 6LoWPAN em relao ao modelo de
referncia ISO/OSI [6].
A integrao de uma rede IEEE 802.15.4 utilizando o
6LoWPAN com a internet ou outras redes IP ocorre de
maneira bastante simples, por se tratar do mesmo protocolo,
sendo necessria apenas a implementao de um gateway para
a camada de rede [6], conforme ilustra a figura 2.
Fig. 2. Gateway 6LoWPAN / IP [6].
Assim como no IPv6, tambm foram criados cabealhos
opcionais no 6LoWPAN, servindo para dar suporte s
inmeras funes da camada, sendo utilizados apenas quando
necessrio. A figura 3 ilustra um exemplo de encadeamento de
cabealhos no 6LoWPAN.
Fig. 3. Exemplo de encadeamento de cabealhos no 6LoWPAN [6].
O 6LoWPAN utiliza a tcnica de compresso stateless,
como mostrado na figura3, permitindo a compresso dos 40
bytes do cabealho IPv6 em apenas 2 bytes, j que os
endereos IPv6 so formados a partir dos endereos fsicos
dos dispositivos IEEE 802.15.4, alm de uma srie de outras
simplificaes. Os campos em verde da figura 4 so
suprimidos ou comprimidos e apenas o limite de hops
enviado integralmente, entretanto os campos podem ser
transmitidos integralmente quando necessrio:
Fig. 4. Cabealho IPv6 comprimido (HC1), melhor caso [6].
Assim, com essas caractersticas apresentadas, o 6LoWPAN
tem se tornado uma das melhores solues para integrao das
redes WPAN internet e s redes IP, e consequentemente,
cada vez mais novos produtos tem utilizado esse protocolo. A
ISA (International Society of Automation) iniciou inclusive
um processo para criao de uma famlia de padres para
redes sem fio para automao industrial, o ISA100.11a,
possuindo as camadas de rede e transporte baseadas no
6LoWPAN [7].
B. ZigBee
O padro ZigBee foi criado em conjunto com a ZigBee
Alliance e o IEEE, tendo como objetivo disponibilizar uma
rede com baixssima potncia de operao, a fim de ocasionar
um baixo consumo de energia nos dispositivos, estendendo
dessa forma a vida til de suas baterias. Alm disso, tudo isso
implicaria num baixo custo, tendo em vista que para os
usurios, baixo custo significa aparelhos, instalao e
manuteno mais baratas e acessveis [8].
Curiosamente, o nome da tecnologia ZigBee foi tirado de
uma dana que as abelhas fazem para comunicar informaes
a respeito da fonte de alimentos recentemente descobertos
para outros membros da colnia [9]. podendo ser comparada figura 2 (Gateway 6LoWPAN/IP).
O alcance do ZigBee fica na faixa de 10 a 100 metros, com
uma taxa de transmisso que varia de 20 a 250kb/s, possuindo
trs faixas de frequncias que operam nas faixas de rdio
industriais, cientficas e mdicas (ISM): 868-868,6MHz na
Europa, 902-928MHz nos EUA e 2,4-2,4835GHz no resto do
mundo, sendo que a maioria dos equipamentos funcionam na
banda de 2,4GHz.
Os padres ZigBee e Bluetooth, muitas vezes confundidos,
possuem objetivos diferentes. O ZigBee trabalha com
dispositivos que no necessitam de taxas de transmisso to
altas quanto as permitidas pelo Bluetooth, possibilitando assim
Fig. 6. Gateway ZigBee / IP [6].
uma das suas principais caractersticas que o baixo consumo.
O RFD (Reduced Function Device) e o FFD (Full Function
Na tabela I possvel verificar as principais diferenas entre o
Device) so os dois tipos de dispositivos definidos pelo padro
Bluetooth at a verso 2.0 e o ZigBee [10].
IEEE para as redes ZigBee.
TABELA I O padro ZigBee define 3 tipos de ns: coordenador,
COMPARAO ENTRE ZIGBEE E BLUETOOTH AT VERSO 2.0 [10]. roteador e dispositivo final. O coordenador atua como o
corao da rede e o n inicial da rede, sendo assim, opera em
BLUETOOTH (AT ZIGBEE
V2.0) estado ativo para efetuar o controle da rede e costuma ser
Taxa de transferncia 1Mbps-3Mbps 250kb/s alimentado diretamente pelos roteadores, reduzindo o risco de
Corrente de transmisso 40mA 30mA falha no n centralizador da rede. Os roteadores so
Corrente em standby 200A 3A
dispositivos FFD e atravs das tabelas de roteamento
Memria < 100KB >32KB
Tempo de acesso a rede 3s 30ms permitem encontrar o menor caminho para se chegar ao
Tempo de transio mestre- destino, sendo ainda utilizados em topologias malha (mesh) e
3s 30ms
escravo (master-slave) rvore (tree) para dar maior robustez rede. Os dispositivos
Tempo de acesso ao canal 2ms 15ms
finais se comunicam diretamente com o roteador pai e podem
Alcance 1m-100m 1m-100m
Nmero de dispositivos 8 65535 ser implementados com microcontroladores ainda menores
Consumo de bateria dias anos (em termos de memria e potncia) passando quase todo o
tempo em estado inativo. Por serem dispositivos RFD no
Assim como o 6LoWPAN, o ZigBee foi criado para ser fazem funo de roteamento e nem coordenam a rede [11]. A
utilizado em conjunto com o IEEE 802.15.4, entretanto no figura 7 ilustra, para o modelo de rede do Zigbee, os tipos de
deve se achar que os dois so a mesma coisa, pois o ZigBee dispositivos e suas ligaes.
implementa a camada de rede que no est presente no IEEE
802.15.4, conforme ilustrado na figura 5.

Fig. 7. Modelo de rede ZigBee [11].

Fig. 5. Comparao entre o padro ZigBee em relao ao modelo de
referncia ISO/OSI [6].
Porm, ao contrrio do 6LoWPAN, o ZigBee no
facilmente integrado s redes IP e internet por meio de
gateways, pois os protocolos so diferentes, tornando isso
complexo, uma vez que no gateway se exige processamento
das informaes at na camada de aplicao. A figura 6 ilustra
o exemplo de funcionamento de um gateway ZigBee/IP,
Os dispositivos FFD so aptos a funcionar em qualquer um
dos modos de operao: coordenador, roteador ou dispositivo
final, podendo ainda se comunicar com qualquer outro
dispositivo FFD ou RFD. J os dispositivos RFD podem
apenas se comunicar com dispositivos FFD, pois so
dispositivos mais simples e de menor custo, buscando um
consumo de energia ainda menor [11].
Enfim, o ZigBee conquistou muitos adeptos, principalmente
no segmento de automao industrial e residencial para
transmisso de dados em dispositivos de baixo consumo, uma
vez que surgiu com uma proposta diferente das redes sem fio
j existentes, como Bluetooth ou Wi-Fi. Por isso se tornou
tambm um grande candidato a padro nico de protocolo
para Internet das Coisas.
C. MQTT
O MQTT (Message Queue Telemetry Transport) foi
concebido pela IBM e Eurotech, e assim como o 6LoWPAN e
o ZigBee um protoco aberto, simples, leve e fcil de se
implementar.
um protocolo de mensagens baseado na arquitetura
publish/subscribe, sendo considerado ideal para ambientes
restritos, em dispositivos com bateria, processador e memria
limitada. Alm disso, o transporte com pequeno overhead
torna o MQTT uma interessante soluo para redes inseguras Fig. 9. Publicao de mensagem no broker [13].
com restrio de recursos, como baixa largura de banda e alta A verso 3.1.1 do MQTT se tornou um padro OASIS
latncia [12]. (Organization for the Advancement of Structured Information
O MQTT opera em um modelo cliente/servidor, em que cada Standards) [14].
sensor um cliente e se conecta com um servidor, broker, via A estrutura de controle de pacote do MQTT consiste em 3
protocolo TCP. Toda mensagem publicada para um endereo partes: cabealho fixo, presente em todos os controles de
conhecido como topic, dessa forma os clientes podem se pacote MQTT, cabealho varivel e payload, ambos presentes
subscrever a mltiplos topics, sendo que todo cliente subscrito em alguns dos controles de pacotes MQTT. A figura 10 ilustra
a um topic recebe qualquer mensagem publicada nesse topic o formato do cabealho fixo para controle de pacote MQTT:
[13]. A figura 8 mostra um exemplo de uma rede simples que
possui 3 clientes (A, B e C) e um broker central, onde os 3
clientes abrem conexo via TCP com o broker e os clientes B
e C subscrevem para o topic temperatura.
Fig. 10. Cabealho. Fixo do controle de pacote [14].
Os 4 primeiros bits so referentes ao campo de marcadores
(flags) de cada tipo de controle de pacote MQTT, sendo que
quase todos os tipos de controle possuem o marcador como
reservado, com exceo do PUBLISH, conforme ilustra a
tabela II.

TABELA II
MARCADOR DO TIPO DE CONTROLE PUBLISH [14].

MARCADOR DE
NOME BIT 3 BIT 2 BIT 1 BIT 0
CABEALHO FIXO
PUBLISH Usado no MQTT 3.1.1 DUP QOS QOS Retain
O DUP (Duplicated delivery) um marcador referente a
entrega duplicada, dessa forma quando o bit est 0 significa
que a primeira ocasio que o cliente ou servidor tentou
enviar o pacote de publicao MQTT, j quando o bit est em
1 indica que pode ser uma reentrega de uma tentativa anterior
Fig. 8. Subscrio de topic ao broker [13]. para enviar o pacote.
Posteriormente, como exemplo, o cliente A publica um O marcador Retain possui uma srie de condies:
valor de 22.5 para o topic temperatura e o broker encaminha a Se o Retain definido como 1 em um pacote publicado
mensagem para todos os clientes subscritos, dessa forma os enviado pelo cliente ao servidor, o servidor deve armazenar a
clientes se comunicam um a um, um para muitos ou muitos mensagem e seu QoS para que possa ser entregue para futuros
para muitos. Esse exemplo pode ser visto na figura 9. clientes subscritos;
Se o servidor recebe um marcador de QoS como 0 e um
marcador Retain como 1, deve ser descartada qualquer
mensagem retida anteriormente para o topic;
Quando um pacote publicado pelo cliente ao servidor, o
Retain deve ser configurado como 1 se uma mensagem
enviada como resultado de uma nova subscrio feita pelo depende do tipo de pacote, sendo que o campo de identificador
cliente; de pacotes do cabealho varivel bem comum em vrios
O marcador Retain deve ser configurado como 0 quando tipos de pacotes. Na figura 11 possvel verificar o campo de
um pacote publicado enviado ao cliente porque ele coincide identificador de pacotes.
com uma subscrio estabelecida, independentemente de
como o marcador foi configurado na mensagem recebida
O QoS (Quality of Service) um marcador que indica o
nvel de garantia da entrega de uma mensagem PUBLISH. Os
nveis e valores de QoS so mostrados na tabela III. Fig. 11. Identificador de pacote [14].
O componente do cabealho varivel de muitos tipos de
TABELA III controle de pacotes incluem 2 bytes no campo identificador de
VALORES DE QOS [14]. pacotes, conforme ilustrado na figura11. Os controles de
pacotes que requerem um identificador de pacotes so listados
VALOR DE QOS BIT 2 BIT 1 DESCRIO
0 0 0 No mximo uma entrega
na tabela V.
1 0 1 Ao menos uma entrega
TABELA V
2 1 0 Exatamente uma entrega
CONTROLE DE PACOTES QUE POSSUEM UM PAYLOAD[14].
- 1 1 Reservado = no deve ser usado
A tabela IV exibe os valores do tipo de controle de pacote. PACOTE DE CONTROLE PAYLOAD
CONNECT No
TABELA IV CONNACK Sim (se QoS > 0)
VALORES DO TIPO DE CONTROLE DE PACOTE MQTT [14]. PUBLISH Sim
PUBACK Sim
NOME VALOR DIREO DO FLUXO DESCRIO PUBREC Sim
Reserved 0 Proibido Reservado PUBREL Sim
Requisio de PUBCOMP Sim
Cliente para
CONNECT 1 conexo do cliente SUBSCRIBE Sim
Servidor
ao servidor SUBACK Sim
Servidor para UNSUBSCRIBE Sim
CONNACK 2 Conexo confirmada
Cliente
UNSUBACK Sim
Cliente para
Publicao de PINGREQ No
PUBLISH 3 Servidor ou Servidor
mensagem PINGRESP No
para Cliente
DISCONNECT No
Cliente para
Confirmao para
PUBACK 4 Servidor ou Servidor
publicar Alguns dos controles de pacote MQTT possuem tambm
para Cliente
Cliente para Publicao recebida um payload como parte final do pacote. A tabela VI exibe os
PUBREC 5 Servidor ou Servidor (garantia de entrega pacotes de controle que requerem um payload.
para Cliente parte 1)
Cliente para Publicao liberada
TABELA VI
PUBREL 6 Servidor ou Servidor (garantia de entrega
CONTROLE DE PACOTES QUE POSSUEM UM IDENTIFICADOR DE PACOTES [14].
para Cliente parte 2)
Cliente para Publicao completa
PACOTE DE CONTROLE PACKAGE IDENTIFIER FIELD
PUBCOMP 7 Servidor ou Servidor (garantia de entrega
CONNECT Obrigatrio
para Cliente parte 3)
CONNACK Nenhum
Cliente para Requisio de
SUBSCRIBE 8 PUBLISH Opcional
Servidor subscrio do cliente
Servidor para Subscrio PUBACK Nenhum
SUBACK 9 PUBREC Nenhum
Cliente confirmada
Requisio de PUBREL Nenhum
UNSUBSCRIB Cliente para PUBCOMP Nenhum
10 cancelamento de
E Servidor SUBSCRIBE Obrigatrio
subscrio do cliente
Confirmao de SUBACK Obrigatrio
Servidor para UNSUBSCRIBE Obrigatrio
UNSUBACK 11 cancelamento de
Cliente UNSUBACK Nenhum
subscrio
Cliente para PINGREQ Nenhum
PINGREQ 12 PING requisitado PINGRESP Nenhum
Servidor
Servidor para DISCONNECT Nenhum
PINGRESP 13 PING respondido
Cliente Sem dvida nenhuma, o MQTT um dos melhores
Cliente para Cliente protocolos de mensagem e que ganhou mais destaque ainda
DISCONNECT 14
Servidor desconectando
Reserved 15 Proibido Reservado quando se tornou um padro OASIS.
O campo de comprimento restante (Remaining Length) no D. CoAP
byte 2 da figura 10 o nmero de bytes restantes do pacote
O CoAP (Constrained Application Protocol) foi concebido,
atual, incluindo os dados do cabealho varivel e o payload.
assim como o 6LoWPAN, pela IETF, por um grupo de
O cabealho varivel uma das partes da estrutura de
trabalho chamado CoRE (Constrained RESTful
controle de pacotes do MQTT, sendo localizado entre o
Environments). Adaptado do HTTP (HyperText Transfer
cabealho fixo e o payload. O contedo do cabealho varivel
Protocol), foi otimizado para dispositivos com capacidade de
bateria e processamento limitada, alm disso, usualmente
aplicado para aplicaes M2M (Machine-To-Machine), como
automao residencial e smart energy [15].
Em comparao com o HTTP, o CoAP realiza menos troca
de dados entre cliente e servidor, resultando assim em um
menor consumo de energia quando est sendo utilizado em
equipamentos de menor custo em ambos os lados da conexo
[16].
A caractersticas do CoAP so definidas na RFC 7252, Fig. 12. Formato de Mensagem CoAP [15].
sendo algumas delas descritas a seguir: Os campos do formato de mensagem CoAP so definidos
Protocolo Web que cumpre com os requisitos M2M em da seguinte maneira pela RFC 7252:
ambientes restritos; Verso (Ver): inteiro no negativo de dois bits que indica
Binding em UDP (User Datagram Protocol) com o nmero correspondente verso do CoAP;
confiabilidade opcional suportando requisies tanto unicast Tipo (T): inteiro no negativo de dois bits. Indica se a
quanto musticast; mensagem do tipo CON, NON, ACK ou RST;
Troca de mensagens de forma assncrona; Largura do Token (TKL): inteiro no negativo de quatro
Suporte a URI (Uniform Resource Identifier) e Content- bits. Indica o tamanho varivel do token (0-8 bytes);
Type; Cdigo (code): inteiro no negativo de oito bits que
Capacidade simples de Proxy e caching; caracteriza o tipo da mensagem, podendo indicar um mtodo
Baixo overhead no cabealho e anlise de complexidade. de requisio ou um cdigo de resposta;
So definidas ainda 4 tipos de mensagens: CON ID da mensagem (message ID): inteiro no negativo de
(Confirmable), NON (Non-Confirmable), ACK 16 bits usado para detectar duplicao de mensagens e
(Acknowledgment) e RST (Reset). tambm para comparao de mensagens do tipo ACK.
CON uma mensagem que necessita ser confirmada pelo O token utilizado para relacionar requisies e
destino, dessa forma quando no h perda de pacotes, cada respostas, sendo gerado no cliente e transportado junto com a
mensagem deste tipo resulta em uma mensagem do tipo ACK requisio;
ou RST. O cabealho e o token so seguidos pelas opes
NON no precisa de confirmao no recebimento, sendo (options), quando aplicvel, sendo que uma opo pode ser
extremamente til no caso de uma aplicao que recebe seguida pelo fim da mensagem, por outra opo ou pelo
leituras constantes de um sensor em um espao curto de payload;
tempo, pois a perda de uma mensagem no seria preocupante. Quando a mensagem possui payload, este deve ser
ACK uma mensagem que confirma o recebimento de uma indicado por um marcador de um byte que indica o fim das
mensagem CON, mas vale ressaltar que por si s no indica opes, sendo que a ausncia do marcador indica um payload
sucesso ou falha de nenhuma requisio encapsulada na de tamanho 0 bytes e um marcador seguido por um payload de
mensagem CON. 0 bytes considerado um erro no formato da mensagem.
RST indica que uma mensagem CON ou NON foi recebida, A tabela VII ilustra um comparativo entre esses dois
mas por algum motivo no pode ser devidamente processada, protocolos:
como por exemplo se algum dispositivo foi reiniciado e a
mensagem enviada no foi devidamente interrompida. TABELA VII
O CoAP baseado em troca de mensagens compactas VALORES DO TIPO DE CONTROLE DE PACOTE MQTT [17].
transportadas sobre UDP, podendo ser usado tambm DTLS MQTT COAP
(Datagram Transport Layer Security). Alm disso, suas Protocolo de
TCP UDP
mensagens so codificadas em um formato binrio simples, Transporte
sendo que a mensagem comea com um tamanho fixo de 4 Tipo de Payload Binrio Binrio
Adequado para
bytes de cabealho, seguido por um token de tamanho Sim Sim
microcontroladores
varivel, que pode ser entre 0 e 8 bytes. Aps o token pode Segurana SSL / TLS DTLS
no haver nenhuma ou uma srie de opes (options) no Escalabilidade Simples Complexo
formato TLV (Type-Length-Value), que so opcionalmente Baseado em broker Cliente / servidor
Arquitetura de rede
(publish/subscriber) (request/response)
seguidas por um payload, ocupando assim o resto do Padro de
Baseado em Topic Arquitetura REST
datagrama. Esse formato de mensagem CoAP pode ser Comunicao
observado na figura 12 [15]. Opes de QoS Sim Sim
Disponibilidade de
Sim Sim
cdigo aberto
Enfim, o CoAP um timo protocolo usado para transporte
de mensagem, assim como o MQTT, entretanto ambos tem
caractersticas diferentes.
 III. CONCLUSES
Neste artigo foram apresentados quatro tipos de protocolos
candidatos a padro nico de protocolo para a Internet das
Coisas, entretanto, como foi possvel perceber, esta definio
no uma tarefa muito fcil, pois cada um dos protocolos
possui caractersticas exclusivas e. justamente por essa razo,
todos eles tornam-se fortes candidatos. Uma coisa em comum
dentre os quatro protocolos estudados, que por se tratarem de
protocolos abertos, todos beneficiam dispositivos de baixo
consumo de energia, baixo processamento e baixa capacidade
de memria, ou seja, dispositivos com capacidades limitadas.
O 6LoWPAN apresenta um diferencial muito grande por
trabalhar em cima do IPv6, tornando-se uma das melhores
opes para a integrao das WPANs internet e s redes IP.
Por isso possvel notar um crescente interesse da
comunidade tcnica e cientfica, alm disso, o mercado
tambm tem voltado os seus olhos para esse protocolo e dessa
forma, tem surgido inmeros novos produtos baseado no
mesmo.
Por outro lado temos o Zigbee, que j bem conhecido no
mercado e tem ganhando tambm bastante destaque,
principalmente com o ZigBee IP, sendo que essa aceitao do
mercado acaba sendo um dos seus trunfos.
O MQTT e o CoAP so dois excelentes protocolos para
transporte de mensagem. Enquanto o MQTT mais voltado
para uma comunicao muitos para muitos, para transportar
mensagens entre vrios clientes atravs de um servidor central
broker e utilizando os protocolos da pilha TCP/IP, o CoAP
mais voltado para uma comunicao um para um, para
transferncia de informao entre cliente e servidor, utilizando
o protocolo UDP/IP.
Finalmente, possvel perceber que existe um esforo
muito grande tambm por parte de algumas organizaes em
promover esses protocolos, como o OASIS com o MQTT e o
IETF com o 6LoWPAN e CoAP; entretanto, enquanto no
houver um padro nico de protocolo, a escolha deste
depender do cenrio de aplicao, assim como os requisitos
do sistema. Dessa forma, ainda haver um mercado enorme
para a Internet das Coisas, com inmeros dispositivos e
diferentes protocolos.
REFERNCIAS
[1] W. Leister and T.Schulz, Ideas for a Trust Indicator in the Internet of
Things. The First International Conference on Smart Systems, Devices
and Technologies, 2012,no. c, pp. 31-34.
[2] D. Evans, The Internet of Things How the Next Evolution of the
Internet Is Changing Everything. CISCO, white paper 2011, pp. 02-03.
[3] J. Gubbi, R. Buyya, S.Marusic, M. Palaniswami, Internet of Things
(IOT): A vision, architectural elements, and future directions. Future
Generation Computer Systems 2013, pp. 10-11.
[4] M. Kovatsch, S.Duquennoy and A.Dunkels, A Low-Power CoAP for
Contiki, 2011 IEEE Eighth Int. Conf. Mob. Ad-Hoc Sens. Syst., Oct.
2011, pp. 855-860.
[5] G. Montenegro, N. Kushalnagar, J.Hui, D. Culler, RFC 4944
Transmission of IPv6 Packets over IEEE 802.15.4 Networks, 2007.
[6] IPV6.br, ZigBee usa agora 6LoWPAN! Sua prxima lmpada ter
IPv6?,2013. Disponvel: http://ipv6.br/post/zigbee-usa-agora-6lowpan-
sua-proxima-lampada-tera-ipv6/
[7] M. Nixon, A comparison of WirelessHART and ISA100.11a,
Whitepaper, 2012, pp-11.
[8] P. Kinney, ZigBee Technology: Wireless Control that Simply Works,
Communications Designer Conference, Oct. 2013, pp. 03.
[9] D. Gislason, ZigBee Wireless Networking, Elsevier, 2008, pp. 111.
[10] R. Costa, L. Mendes, Evoluo das Redes Sem Fio: Um Estudo
Comparativo Entre Bluetooth e ZigBee, Fundao Presidente Antnio
Carlos, 2006, pp.8.
[11] B. L. R. P. Vasques, I. B. A. Coutinho, M. F. Lima, V. P. O. Carneval,
ZigBee, Engenharia Eletrnica e de Computao - Redes de
Computadores I, URFJ, 2010. Disponvel:
http://www.gta.ufrj.br/grad/10_1/zigbee/dispositivos.html
[12] International Business Machines Corporation (IBM), Eurotech, MQTT:
Message Queuing Telemetry Transport, version 3.1, 2010, pp. 1-42.
[13] T. Jeffey, MQTT and COAP, IOT protocols, 2014. Disponvel :
http://www.eclipse.org/community/eclipse_newsletter/2014/february/arti
cle2.php
[14] OASIS, MQTT, version 3.1.1 plus errata 01, 2015, pp. 1-81.
[15] Z.Shelby, RFC 7252: The Constrained Application Protocol (CoAP),
2014, pp. 1-112.
[16] T. Lev, O. Mazhelis, H. Suomi, Comparing the cost-efficiency of
CoAP and HTTP in Web of Things applications, Decis.Support Syst.,
vol.63, Jul. 2014, pp. 23-38.
[17] E. Frigieri, D. Mazzer, L. Parreira, M2M Protocols for Constrained
Environments in the Context of IoT: A Comparison of Approaches,
XXXIII Simpsio Brasileirode Telecomunicaes, 2015, pp. 5.
Henrique Osako nasceu em So Paulo, SP, em
03 de Setembro de 1987. Recebeu os ttulos de
Eletricista de Manuteno (SENAI, 2004),
Engenheiro Eletricista com nfase em
Eletrnica (FEI, Junho/2012) e est cursando a
Ps-Graduao em Engenharia de Redes e
Sistemas de Telecomunicaes e
Desenvolvimento de Software (INATEL,
previso Agosto, 2016).
Desde julho de 2012 atua na rea de
Engenharia de Testes de Software para
celulares, onde recebeu o certificado CTFL
Certified Tester Foundation Level (ISTQB, license 13-CTFL-02749-BR) e o
prmio de melhor funcionrio (2013 Exceptional Performance Award). Tem
interesse na rea de testes, qualidade, automao de casos de testes e
telecomunicaes em geral, mas principalmente nas tecnologias de rede GSM,
WCDMA e LTE.
Edson Josias Cruz Gimenez - graduao em Engenharia Eltrica pelo
Instituto Nacional de Telecomunicaes (1987), especializao em
Informtica Gerencial pela Faculdade de Administrao e Informtica (1994),
especializao em Educao Matemtica pela Pontifcia Universidade
Catlica de Campinas (1987) e mestrado em Telecomunicaes pelo Instituto
Nacional de Telecomunicaes (2004). Professor titular do Inatel.