Captulo

1
Internet das Coisas: da Teoria Prtica.

Bruno P. Santos, Lucas A. M. Silva, Clayson S. F. S. Celes, Joo B. Borges

Neto, Bruna S. Peres, Marcos Augusto M. Vieira, Luiz Filipe M. Vieira,
Olga proliferationN. Goussevskaia e Antonio A. F. Loureiro

Departamento de Cincia da Computao Instituto de Cincias Exatas

Universidade Federal de Minas Gerais (UFMG) Belo Horizonte, MG Brasil
{bruno.ps, lams, claysonceles, joaoborges, bperes, mmvieira, lfvieira,
olga, loureiro}@dcc.ufmg.br

Abstract

The prospective scale of smart objects with capabilities of sensing, processing and com-
munication has grown in recent years. In this scenario, the Internet of Things (IoT) is
born by empower smart objects to connect to the Internet and provides communication
with users and devices. IoT enables a huge amount of new applications, with which aca-
demics and industries can benefit, e.g., they can propose applications for smart cities,
health care or automation. On the other hand, emerge several social, theoretical and
practical issues, e.g., we need efficient way to address and connect billions of smart ob-
jects with the Internet. To answer these issues, we need to overcome some challenges like
dealing with smart objects constraints (processing, memory and energy supply), limited
bandwidth and hardware dimension. Thus, we need to explore new communication pa-
radigms, routing protocols, architecture designs for hardware and software. Besides that
questions about IP addressing and adaptations need be answered to maintain interope-
rability with Internet. On the side of IoT applications interesting issues rise up, e.g., how
to collect, store, process and extract knowledge from information obtained from the smart
objects. In this sense, the goal of the chapter is describe the IoT state-of-the-art by using
theoretical and practical approaches. Also, we explore challenges, research issues and
trends through of a IoT review.
 Resumo

A proliferao de objetos inteligentes com capacidade de monitoramento, proces-

samento e comunicao tem sido crescente nos ltimos anos. Neste cenrio, a Internet
das Coisas (Internet of Things (IoT)) surge ao habilitar que estes objetos estejam conecta-
dos Internet e promovam comunicao entre usurios e dispositivos. A IoT possibilita
uma nova gama de aplicaes das quais tanto a academia quanto a industria podem
se beneficiar, por exemplo, pode-se propor aplicaes para cidades inteligentes, sade,
automao de ambientes, dentre outros. Por outro lado, emergem diversos desafios no
mbito social, terico e prtico, por exemplo, necessrio um modo eficiente para en-
derear e conectar bilhes de objetos inteligentes. Para de responder a estas questes
preciso entender e lidar com outros problemas tais como os restries sobre recursos dos
objetos inteligentes (processamento, memria e fonte de alimentao), limitada largura
de banda e dimenso do hardware. Deste modo, se faz necessrio explorar novos para-
digmas de comunicao, protocolos de roteamento, arquiteturas de hardware e software.
Alm disso, as questes sobre o endereamento IP e adaptaes devem ser respondidas,
para que seja possvel conectar os objetos Internet mantendo interoperabilidade. No
que tange aplicaes IoT, outras questes surgem, por exemplo, como coletar, armazenar,
processar e extrair conhecimento de modo eficiente das informaes obtidas dos objetos
inteligentes. Neste sentido, o objetivo deste captulo descrever o estado-da-arte da IoT
aplicando uma abordagem terico e prtica. Alm disso, desafios, questes de pesquisa
e tendncia sobre IoT so abordados atravs de uma viso geral da rea.

1.1. Introduo
A Internet das Coisas (do ingls Internet of Things (IoT)) emergiu dos avanos
de vrias reas como sistemas embarcados, microeletrnica, comunicao e tecnologia
de informaes. De fato, a IoT tem ganhado enfoque no cenrio acadmico e industrial,
porque espera-se que seu impacto seja significante. Este captulo aborda a Internet das
Coisas atravs de uma perspectiva terica e prtica. O contedo aqui abordado explora
a estrutura, a organizao e os eventuais desafios e aplicaes da IoT. Nesta seo, sero
conceituadas a IoT e os objetos inteligentes. Alm disso, so postos em evidncia a
perspectiva histrica da Internet das Coisas e as motivaes que influenciam o aumento
dos interesses, expectativas e pesquisas na rea. Logo em seguida, so introduzidos os
blocos bsicos de construo da IoT. Para iniciar a discusso, ser levantada a seguinte
questo: o que a Internet das Coisas?
A Internet das Coisas, em poucas palavras, nada mais que uma extenso da In-
ternet atual. Esta extenso feita ao proporcionar que objetos do dia-a-dia (quaisquer
que sejam) se conectem Internet. A conexo com a rede mundial de computadores
viabilizar, primeiro, controlar remotamente os objetos e, segundo, permitir que os pr-
prios objetos sejam acessados como provedores de servios. Estas novas habilidades, dos
objetos comuns, geram um grande nmero de oportunidades tanto no mbito acadmico
quanto no industrial. Todavia, estas possibilidades apresentam riscos e acarretam amplos
desafios tcnicos e sociais.
A IoT tem alterado aos poucos o conceito de redes de computadores, neste sentido,
possvel notar a evoluo do conceito ao longo do tempo como mostrado a seguir. Para
Tanenbaum [Tanenbaum 2002], Rede de Computadores um conjunto de computadores
autnomos interconectados por uma nica tecnologia. Entende-se que tal tecnologia de
conexo pode ser de diferentes tipos (fios de cobre, fibra tica, ondas eletromagnticas
ou outras). Em 2011, Peterson definiu em [Peterson and Davie 2011] que a principal
caracterstica das Redes de Computadores a sua generalidade, isto , elas so construdas
sobre dispositivos de propsito geral e no so otimizadas para fins especficos tais como
as redes de telefonia e TV. J em [Kurose and Ross 2012], os autores argumentam que o
termo Redes de Computadores comea a soar um tanto envelhecido devido grande
quantidade de equipamentos e tecnologias no tradicionais que so usadas na Internet.

Figura 1.1. Volume de pesquisas no Google sobre Wireless Sensor

Networks e Internet of Things2 .

Os objetos inteligentes, definidos mais adiante, possuem papel fundamental na

evoluo acima mencionada. Isto porque os objetos possuem capacidade de comunica-
o e processamento aliados a sensores, os quais transformam a utilidade destes objetos.
Atualmente, no s computadores convencionais esto conectados grande rede, como
tambm uma grande heterogeneidade de equipamentos tais como TVs, Laptops, auto-
mveis, smartphones, consoles de jogos, webcams e a lista aumenta a cada dia. Neste
novo cenrio, a pluralidade crescente e previses indicam que mais de 40 bilhes de
dispositivos estaro conectados at 2020 [Forbes 2014]. Usando os recursos deses obje-
tos ser possvel detectar seu contexto, control-lo, viabilizar troca de informaes uns
com os outros, acessar servios da Internet e interagir com pessoas. Concomitantemente,
uma gama de novas possibilidades de aplicaes surgem (ex: cidades inteligentes (Smart
Cities), sade (Healthcare), casas inteligentes (Smart Home)) e desafios emergem (re-
gulamentaes, segurana, padronizaes). importante notar que um dos elementos
cruciais para o sucesso da IoT encontra-se na padronizao das tecnologias. Isto permi-
tir que a heterogeneidade de dispositivos conectados Internet cresa, tornando a IoT
uma realidade. Tambm essencial frisar que nos ltimos meses e nos prximos anos
sero vivenciados os principais momentos da IoT, no que tange as definies dos blocos
bsicos de construo da IoT.
2 Fonte: https://www.google.com/trends/
 Parafraseado os autores [Mattern and Floerkemeier 2010], ao utilizar a palavra
Internet"no termo Internet of Things"como acima mencionado, pode-se fazer uma ana-
logia com a Web nos dias de hoje, em que brevemente as coisas"tero habilidades de
comunio umas com as outras, provero e usaro servios, provero dados e podero
reagir a eventos. Outra analogia, agora mais tcnica, que IoT vista como uma pilha de
protocolos utilizados nos objetos inteligentes.
Na IoT, eventualmente, a unidade bsica de hardware apresentar ao menos uma
das seguintes caractersticas [Ruiz et al. 2004, Loureiro et al. 2003]: i) unidade(s) de pro-
cessamento; ii) unidade(s) de memria; iii) unidade(s) de comunicao e; iv) unidade(s)
de sensor(es) ou atuador(es). Aos dispositivos com essas qualidades dado o nome de ob-
jetos inteligentes (Smart Objects). Os objetos, ao estabelecerem comunicao com outros
dispositivos, manifestam o conceito de estarem em rede, como discutido anteriormente.

1.1.1. Perspectiva histrica da IoT

Kevin Ashton comentou, em junho de 2009 [Ashton 2009], que o termo Internet
of Things foi primeiro utilizando em seu trabalho titulado I made at Procter & Gam-
ble"em 1999. Na poca, a IoT era altamente relacionada ao uso da tecnologia RFID.
Contudo, o termo ainda no era foco de grande nmero de pesquisas como pode ser visto
na Figura 1.1. Por volta de 2005, o termo bastante procurado (tanto pela academia quando
indstria) e que apresenta relao com a IoT foi Redes de Sensores Sem Fio (RSSF) (do
ingls Wireless Sensor Networks (WSN)). Estas redes trazem avanos na automao re-
sidencial e industrial [Kelly et al. 2013, Da Xu et al. 2014], bem como tcnicas para ex-
plorar as diferentes limitaes dos dispositivos (ex: memria e energia), escalabilidade e
robustez da rede [Loureiro et al. 2003]. Nos anos seguintes (entre 2008 e 2010), o termo
Internet das Coisas ganhou popularidade rapidamente. Isto se deve ao amadurecimento
das RSSF e o crescimento das expectativas sobre a IoT. A Figura 1.1 mostra que em 2010,
a buscas para IoT dispararam chegando a ultrapassar as pesquisas sobre RSSF.
A IoT foi identificada como uma tecnologia emergente em 2012 por especialistas da
rea [Gartner 2015]. A Figura 1.2 apresenta uma maneira de representar o surgimento,
adoo, maturidade e impacto de diversas tecnologias chamada de Hype Cycle. Em 2012,
foi previsto que a IoT levaria entre 5 e 10 anos para ser adotada pelo mercado e hoje
vivenciado o maior pico de expectativas sobre a tecnologia no mbito acadmico e indus-
trial. Tambm pode-se notar o surgimento das primeiras plataformas da IoT (discutidas
mais adiante) que recebem grande expectativa da comunidade nos prximos anos. Estes
fatos podem servir de incentivo inicial para despertar a curiosidade do leitor para a rea,
bem como indica o motivo do interesse da comunidade cientfica e industrial para a IoT.

1.1.2. Motivao para manuteno da evoluo da IoT

Ao conectar objetos com diferentes recursos a uma rede, potencializa-se o sur-
gimento de novas aplicaes. Neste sentido, conectar esses objetos Internet significa
criar a Internet das Coisas. Na IoT, os objetos podem prover comunicao entre usurios,
dispositivos. Com isto emerge uma nova gama de aplicaes, tais como coleta de dados
de pacientes e monitoramento de idosos, sensoriamento de ambientes de difcil acesso e

4 Fonte: http://www.gartner.com/newsroom/id/3114217
inspitos, entre outras [Sundmaeker et al. 2010].
Entretanto, ao passo
que a possibilidade de novas
aplicaes crescente, os de-
safios de conectar os obje-
tos Internet surgem. Na-
turalmente, os objetos so
heterogneos, isto , diver-
gem em implementao, re-
cursos e qualidade e, em
geral, apresentam limitaes
[Loureiro et al. 2003] de ener-
gia, capacidade de processa-
mento, memria e comunica-
o. Questes tanto tericas
quanto prticas surgem, por
Figura 1.2. Tecnologias emergentes4 . exemplo, como prover ende-
reamento aos dispositivos,
como encontrar rotas de alta vazo e melhor taxa de entrega mantendo o baixo o uso
dos recursos limitados. Deste modo, fica evidente a necessidade da adaptao dos pro-
tocolos existentes (ex: o IP). Alm disso, sabe-se que os paradigmas de comunicao
e roteamento nas redes de objetos inteligentes podem no seguir os mesmos padres de
uma rede como a Internet [Chaouchi 2013], sendo assim como devem ser explorados para
extrair melhor desempenho das redes de objetos inteligentes.
Novos desafios surgem enquanto so criadas novas aplicaes para IoT. Os dados
providos pelos objetos agora podem apresentar imperfeies (calibragem do sensor), in-
consistncias (fora de ordem, outliers), serem de diferentes tipos (gerados por pessoas,
sensores fsicos, fuso de dados). Assim, as aplicaes e algoritmos devem ser capazes
de lidar com esses desafios sobre os dados. Outro exemplo diz respeito ao nvel de confi-
ana sobre os dados obtidos dos dispositivos da IoT e como/onde pode-se empregar esses
dados em determinados cenrios. Deste modo, os desafios impostos por essas novas apli-
caes devem ser explorados e solues devem ser propostas para que a IoT contemplem
as expectativas em um futuro prximo como previsto na Figura 1.2.
Alguns autores j pressupem que a IoT ser a nova revoluo da tecnologia da
informao [Ashton 2009, Forbes 2014, Wang et al. 2015]. Sendo assim, a IoT possivel-
mente no deve ser entendida como um fim, mas sim um meio de alcanar algo maior, a
saber a computao ubqua. Desde modo, esta relao entre IoT e a computao ubqua
ser objeto de detalhamento em momento oportuno ao longo do captulo.

1.1.3. Blocos Bsicos de Construo da IoT

A IoT pode ser vista como um combinado de diversas tecnologias, as quais so
complementares no sentido de viabilizar a integrao dos objetos no ambiente fsico ao
mundo virtual. A Figura 1.3 apresenta os blocos bsicos de construo da IoT sendo eles:
6 Imagem e texto baseados em [Al-Fuqaha et al. 2015, Mattern and Floerkemeier 2010].
 Identificao: um dos blocos mais impor-
tantes, visto que primordial identificar os
objetos unicamente para ento conect-los
Internet. Tecnologias como RFID, NFC
(Near Field Communication) e enderea-
mento IP podem ser empregados para iden-
tificar os objetos.
Sensores/Atuadores: os objetos coletam in-
formaes sobre o contexto ao seu redor, em
seguida, eles podem armazenar esses dados
ou encaminhar para data warehouse, clouds
ou centros de armazenamento. No caso de
Atuadores, os objetos podem manipular o
ambiente ou reagir de acordo ao dados lidos.
Figura 1.3. Blocos bsicos da IoT6 . Comunicao: a comunicao tambm
um dos blocos fundamentais, pois atravs
dela possvel conectar os objetos inteligen-
tes. Alm disso, este bloco desempenha papel importante no consumo de energia dos
objetos, sendo portanto um fator crtico, visto que grande quantidade de energia (recurso
limitado) empregada para realizar a comunicao. Exemplos de tecnologias utilizadas
nesse item so: WiFi, Bluetooth, IEEE 802.15.4, RFID.
Computao: diz respeito unidade de processamento, por exemplo, micro controlado-
res, processadores, FPGAs. Em outras palavras, tudo o que d aos objetos inteligentes a
capacidade de computar.
Servios: em geral a IoT pode prover diversas classes de servios, dentre elas, destacam-
se os Servios de Identificao, o quais so os mais bsicos e importantes servios, pois as
aplicaes os utilizam para mapear as Entidades Fsicas (EF) (de interesse do usurio) em
Entidades Virtuais (EV), em outras palavras, estes servios facilitam mapear objetos do
mundo real e os respectivos objetos do mundo virtual. Os Servios de Agregao de In-
formaes, os quais coletam e sumariza dados brutos obtidos dos objetos inteligentes que
precisam ser processados e enviados para as aplicaes. Os Servios de Colaborao e
Inteligncia so aqueles que agem sobre os servios de agregao de informaes usando
os dados obtidos e processados para tomar decises e reagir de modo adequado. Para
finalizar, ser pontuado os Servios de Ubiquidade visam prover Servios de colaborao
e Inteligncia em qualquer momento e qualquer lugar em que eles sejam necessrios.
Semntica: refere-se habilidade de extrao de conhecimento da diversidade de objetos
na IoT. Em outras palavras, a semntica trata da descoberta e uso inteligente dos recursos,
para possibilitar o provimento de determinado servio. Alm disso, deve efetuar o re-
conhecimento e anlise dos dados para realizar corretamente a tomada de decises. Para
tanto, podem ser usadas diversas tecnologias tais como: Resource Description Framework
(RDF), Web Ontology Language (OWL) e Efficient XML Interchange (EXI).
1.1.4. Objetivos do minicurso
Este captulo tem por objetivo apresentar ao leitor uma viso geral da Internet das
Coisas. Neste sentido, um amplo espectro de conhecimento ser posto para apreciao
do leitor. Isto ser realizado de modo a deixar o mais claro possvel o real significado, a
funcionalidade e posicionamento dos principais blocos de construo da IoT.
Aps a breve apresentao dos blocos da IoT (Seo 1.1.3) fica evidente o quo
ampla a rea. Diante disto, sero discutidos somente alguns destes blocos ao longo
do captulo sendo eles: Identificao, Comunicao e Servios/Semntica. Sempre
pontuando em momento oportuno questes que envolvem os demais blocos. Estes blocos
foram escolhidos, pois capturam a essncia da IoT e d ao leitor condies de explorar
com maior facilidade os demais blocos bsicos de construo.

1.1.5. Estrutura do captulo

Este captulo dividido em 5 partes principais. A primeira, Seo 1.2 sero abor-
dados pontos sobre os dispositivos e as tecnologias de comunicao para IoT. A segunda,
Seo 1.3, discute sobre os softwares que orquestram a operao da IoT, pontuando a
identificao nica dos dispositivos com IPv6, bem como modelos de conectividade, pro-
tocolos de roteamento e aplicao para IoT e ambientes de desenvolvimento. Na terceira
parte, Seo 1.4, sero realizadas duas prticas para consolidar os contedo visto. Estas
prticas sero o elo para o contedo da quarta parte do captulo, Seo 1.5, a qual aborda
o gerenciamento e anlise de dados que permeiam os blocos bsicos de semntica e servi-
os. O quinto momento, Seo 1.6, focar na perspectiva futura da IoT, apresentando um
olhar diferenciado para a IoT, em que ela um meio para se atingir a Computao Ub-
qua. Finalmente, na Seo 1.7, sero apresentadas as consideraes finais e destacados
os pontos que no foram cobertos no captulo, mas sempre fazendo referncias para que
o leitor possa ter um ponto de partida para eventuais leituras extra.

1.2. Dispositivos e Tecnologias de Comunicao

Nesta primeira seo, sero abordados em mais detalhes a arquitetura bsica dos
dispositivos inteligentes e as tecnologias de comunicao. O bloco de construo foco
desta seo o de comunicao, o qual permite interligar dispositivos. As tecnologias
sem fio so evidenciadas, pois capturam a essncia sem fio do ambiente IoT.

1.2.1. Arquiteturas bsica dos dispositivos

A arquitetura bsica dos objetos inteligentes composta por 4 unidades: proces-
samento/memria, comunicao, energia e sensores/atuadores. A Figura 1.4 mostra uma
viso geral da arquitetura de um dispositivo e a interligao entre seus componentes, os
quais so descritos a seguir:
(i) Unidade(s) de processamento/memria: esta unidade composta de uma memria in-
terna para armazenamento de dados e programas, um microcontrolador e um conversor
analgico-digital para receber sinais dos sensores. As CPUs utilizadas para os dispo-
sitivos so, em geral, as mesmas utilizadas em sistemas embarcados e comumente no

8 Imagem e texto baseados em [Ruiz et al. 2004, Loureiro et al. 2003]

apresentam alto poder computacional. Frequentemente existe uma memria externa do
tipo flash, que serve como memria secundria, por exemplo, manter um log de da-
dos. As caractersticas desejveis para estas unidades so pouco consumo de energia e o
componente deve ocupar o menor espao possvel.
(ii) Unidade(s) de comunicao: esta
unidade consiste de um canal de co-
municao com ou sem fio, sendo
mais comum o meio sem fio. Neste (i) Processador/ (ii) Rdio
ltimo caso, a maioria das plataformas Memria
(3)
usam rdio de baixa potncia e custo.
Como consequncia, a comunicao (4)

de curto alcance e apresentam perdas

frequentes. Esta unidade bsica ser
objeto de estudo mais aprofundado na
prxima seo.
(2) (1)
(iii) Fonte de energia: a unidade
(iv) Sensores (iii) Fonte de Energia
responsvel por alimentar de energia
os componentes do objeto inteligente.
Normalmente, a fonte de energia con- Figura 1.4. Arquitetura dos dispositivos8 .
siste de uma bateria (recarregvel ou
no) e um conversor ac-dc e tem a fun-
o de alimentar os componentes. Entretanto, existem diversas outras fontes de alimenta-
o como energia eltrica, solar e outras.
(iv) Unidade(s) de sensor(es) ou atuador(es): estas unidades so realizam o monitora-
mento do ambiente em que o objeto est imerso. O sensores so responsveis por lidar
com grandezas fsicas como temperatura, umidade, presso, presena, etc. Atuadores so
dispositivos que produzem movimento, atendendo a comandos que podem ser manuais,
eltricos ou mecnicos.

1.2.2. Tecnologias de comunicao

Nesta seo sero abordadas as principais tecnologias de comunicao utilizadas
em IoT, sempre pontuando as caractersticas mais relevantes de cada um das tecnologia.
Ethernet O padro Ethernet (IEEE 802.3) foi oficializado em 1983 e est presente em
grande parte das redes de hoje. Seu da tecnologia devida a sua simplicidade e a facili-
dade de adaptao, manuteno e custo. Atualmente, existem dois tipos de cabos, o cabo
de par tranado e os de fibra ptica. Cada tipo de cabo pode alcanar uma vazo de dados
diferente. Os cabos de par tranado podem atingir velocidades de at 1Gbps (categoria
5) e so limitados a ter 100m de comprimento (para distncias maiores necessrio o
uso de repetidores). Os cabos de fibra-ptica alcanam valores de vazo de 10Gbps e
possuem a limitao de comprimento de at 2000m [Tanenbaum 2011]. O uso do padro
Ethernet apresenta as vantagens de baixo requisito de energia, alta vazo de dados e sim-
plicidade. Entretanto, usar Ethernet em geral implica que os dispositivos estaro fixos
(sem mobilidade), o que pode limitar as aplicaes em IoT.
Wi-Fi O Wi-Fi a tecnologia de comunicao mais popular, pois elas est presente em
quase todos os lugares, fazendo parte do cotidiano das casas, escritrios, indstrias e at
espaos pblicos das cidades. O padro IEEE 802.11 (Wi-Fi) define um conjunto de
padres de transmisso e codificao, que hoje esto disponvel em 25% das casas pelo
mundo [Alliance 2015]. Uma das principais preocupaes do Wi-Fi a vazo, a primeira
verso do padro IEEE 802.11, lanada em 1997, alcanava a vazo de 2 Mbps, a prxima
verso elevou esse valor para 11 Mbps. Atualmente, os valores disponveis para vazo so
600 Mbps ou 1300 Mbps na verso IEEE 802.11 ac.
O Wi-Fi foi desenvolvido como uma alternativa para o padro cabeado Ether-
net, com pouca, ou talvez nenhuma preocupao com dispositivos que possuem consumo
energtico limitado, como o caso das aplicaes para IoT. Neste sentido, no esperado
que muitos dispositivos utilizados em IoT adotem o padro Wi-Fi como principal pro-
tocolo de comunicao. Contudo, o Wi-Fi possui algumas vantagens, como alcance de
conexo e vazo, o que o torna adequado para navegao na Internet em dispositivos m-
veis, como smartphones e tablets. A principal desvantagem do Wi-Fi o maior consumo
de energia, quando comparado com outras tecnologias de comunicao.
ZigBee O padro ZigBee baseado na especificao IEEE 802.15.4 para a camada de
enlace. As principais caractersticas do ZigBee so a baixa vazo, reduzido consumo
energtico, e baixo custo. O ZigBee opera na frequncia 2.4-GHz ISM, mas capaz de
operar em outras duas frequncias, 868 MHz ou 915 MHz ISM. Esta tecnologia pode
alcanar a vazo de 250Kbps, mas na prtica somente taxas inferiores so alcanveis. O
ZigBee tambm permite que os dispositivos entrem em modo sleep por longos intervalos
de tempo para economizar o consumo de energia, fazendo com que a vida til da bateria
seja prolongada. Atualmente, novos dispositivos ZigBee permitem o uso tcnicas de co-
lheita de energia do ambiente (Energy Harvesting, discutida mais adiante) para diminuir
o uso da bateria por operaes [Reiter 2014].
O padro ZigBee mantido pela ZigBee Alliance, organizao que responsvel
por gerir o protocolo e garantir a interoperabilidade entre dispositivos. O padro ZigBee
tambm atende a especificao IP, compatvel com IPv6 e formao de rede utilizando a
topologia Malha (Mesh)9 . O ZigBee j adotado em aplicaes residenciais e comerciais.
A sua integrao ao ambiente de Internet das Coisas depende de um gateway. Neste caso,
o gateway o elemento de rede responsvel por permitir a comunicao entre dispositivos
que usam ZigBee e os que no usam.
Bluetooth Low Energy Bluetooth um protocolo de comunicao inicialmente criado
pela Ericsson para substituir a comunicao serial RS-232 10 . Atualmente, o rgo Blu-
etooth Special Interes Group (SIG) responsvel por criar, testar e manter a tecnologia.
Alm disso, Bluetooth uma das principais tecnologias de rede sem fio para Personal
Area Networks PANs, que utilizada em smartphones, headsets, PCs e outros. O Blueto-
oth se divide em: Bluetooth Clssico Basic Rate/Enhanced Data Rate (BR/EDR), que so
as verses 2.0 ou inferiores; Bluetooth High Speed (HS), verso 3.0; e o Bluetooth Low
Energy (BLE), verso 4.0 ou superior. As verses mais antigas do Bluetooth, focadas em

9 http://www.zigbee.org/zigbee-for-developers/network-specifications/
10 https://www.bluetooth.com/what-is-bluetooth-technology/

bluetooth-fact-or-fiction
aumentar a vazo, tornou o protocolo mais complexo e, por consequncia, no otimizado
para dispositivos com limitaes energticas. Ao contrrio das verses anteriores, o BLE
possui especificao voltada para baixo consumo de energia, permitindo dispositivos que
usam baterias do tamanho de moedas (coin cell batteries) prolonguem a sua vida til, ao
passo que mantm comunicao.
Atualmente o BLE possui trs verses, so elas 4.0, 4.1 e 4.2, lanadas em 2010,
2013, e 2014 respectivamente. BLE 4.0 e 4.1 possuem o Maximum Transmit Unit (MTU)
de 27 bytes, diferentemente da mais nova verso (BLE 4.2) que possui 251 bytes. Outra
diferena entre as verses o tipo de topologia de rede que cada verso pode criar. Na
verso 4.0 apenas a topologia estrela disponvel, cada dispositivo pode atuar exclusiva-
mente como Master ou como Slave. A partir da verso 4.1, um dispositivo capaz de
atuar como Master ou Slave ao mesmo tempo, permitindo a criao de topologias em
malha (Mesh). Recentemente foi proposta uma camada de adaptao para dispositivos
BLE similar a 6LoWPAN chamada de 6LoBTLE. A especificao do 6LoBTLE pode
ser consultada na RFC 766811 .
3G/4G Os padres Celular 3G/4G podem tambm ser aplicados no cenrio da IoT. Proje-
tos que precisam alcanar grandes distncias podem aproveitar as redes 3G/4G. Por outro
lado, o consumo energtico da tecnologia 3G/4G alto em comparao com outras tecno-
logias. Porm, a sua utilizao em locais afastados e baixa mobilidade podem compensar
esse gasto. No Brasil, a frequncia utilizada para o 3G 1900MHz e 2100MHz (UMTS), j
o padro 4G (LTE) utiliza a frequncia 2500MHz. A vazo de dados alcanada no padro
3G de cerca de 1Mbps e no padro 4G pode alcanar at 10Mbps 12 .
LoRaWan O Long Range Wide Area Network, foi projetado e otimizado para prover redes
de longa distncia (Wide Area Networks (WANs)). Como principais caractersticas tem-se
o baixo custo, a mobilidade, e segurana na comunicao para IoT. Alm disso, o padro
oferece suporte a IPv6, a adaptao 6LoWPAN e opera sobre a topologia estrela 13 . O fa-
tor atrativo do LoRAWAN o seu baixo custo e a quantidade de companhias de hardware
que esto adotando. A vazo de dados alcanada desta tecnologia alcana valores entre
0.3kbps a 50kbps. O consumo de energia da LoRaWan considerada pequena, o que per-
mite que os dispositivos mantenham-se ativos por longos perodos. A LoRaWANs utiliza
a frequncia ISM sub-GHz, o que permite que as ondas penetrem grandes estruturas e
superfcies com raio de 2km a 5km em meio urbano e 45km no meio rural. Os valores de
frequncia mais usadas pelo LoRaWan so: 109 MHz, 433 MHz, 866 MHz, 915 MHz. O
MTU adotado pelo padro LoRaWAN de 256 bytes14 .
Sigfox O padro SigFox utiliza a tecnologia Ultra Narrow Band (UNB) que foi projetada
para lidar com pequenas taxas de transferncia dados. O padro ainda bastante recente,
e j possui uma larga cobertura que abrange dezenas de milhares de dispositivos, os quais
esto espalhados na Europa e na Amrica do Norte. A SigFox atua como uma operadora
para IoT, com suporte a uma srie de dispositivos. A principal funo abstrair dificul-
dades de conexo e prover uma API para que os usurios implementem sistemas IoT com

11 https://tools.ietf.org/html/rfc7668
12 https://www.opensensors.io/connectivity
13 http://www.semtech.com/wireless-rf/lora/LoRa-FAQs.pdf
14 https://www.lora-alliance.org
maior facilidade. O raio de cobertura oficialmente relatada, em zonas urbanas, est entre
3km e 10km e em zonas rurais entre 30km a 50km. A vazo de dados varia entre 10bps e
1000bps. O MTU utilizado de 96 bytes. O SigFox possui baixo consumo de energia e
opera na faixa de 900MHz15 .
Finalmente, a Tabela 1.1 resume as tecnologias de comunicao apresentadas
nesta seo. As principais caractersticas de cada uma so elencadas, o que permite
compar-las. Neste sentido, destaca-se a grande variedade de possibilidades para conec-
tar dispositivos. Portanto, preciso ponderar acerca das caractersticas das tecnologias e
finalidade do dispositivo para escolher a melhor forma de conect-lo.

Protocolo Alcance Frequncia Vazo IPv6 Topologia

Ethernet 100/2000m N/A 10Gbps Sim Variada
Wi-Fi 50m 2.4/5GHz 1300Mbps Sim Estrela
BLE 80m 2.4GHz 1Mbps Sim* Estrela/Mesh
ZigBee 100m 915MHz/2.4GHz 250kbps Sim Estrela/Mesh
3G/4G 35/200km 1900/2100/2500Mhz 1/10Mbps Sim Estrela
SigFox 10/50km 868/902MHz 10-1000bps - -
LoraWan 2/5km Sub-GHz 0.3-50kbps Sim Estrela
Tabela 1.1. Tabela Comparativa entre tecnologias de conexo.

1.2.3. Perspectivas e desafios sobre os objetos inteligentes LOUREIRO

A evoluo nas tecnologias de hardware empregados na RFID, RSSF , consequen-
temente, na IoT dinmica. Os dispositivos esto cada vez menores e ainda apresentam as
caractersticas mencionadas nas sees anteriores. Contudo, notrio que as tecnologias
de hardware empregadas na IoT hoje, certamente no sero as empregadas no futuro. Isto
se deve a possibilidade de empregar novas tecnologias aos dispositivos inteligentes tais
como circuitos impressos ou sistemas-em-um-chip [Vasseur and Dunkels 2010]. Neste
sentido, esta seo trata das perspectivas e desafios para a IoT. A seguir sero abordados
dois pontos centrais. No primeiro, sobre a questo da fonte de energia, no segundo sobre
as futuras tecnologias de hardware para dispositivo IoT.

1.2.3.1. Bateria e Colheita de Energia (Energy Harvesting)

Como mostrado na Figura 1.4, os dispositivos da IoT requerem uma fonte de

energia. Atualmente, os objetos inteligentes so alimentados, em geral, por baterias,
entretanto existem diversas outras fontes de alimentao como energia eltrica, solar e
outras. As baterias (recarregveis ou no) so as fontes de alimentao mais empregadas
nos dispositivos IoT hoje, embora no sejam as mais adequadas para a tarefa. Isto por-
que, em geral, os dispositivos esto em locais de difcil acesso (ex: embutidos em outros
dispositivos) ou simplesmente no desejvel manipul-los fisicamente para substituio
das baterias. Neste sentido, tanto o hardware quando to software devem ser pensados para
estender ao mximo a vida til destes equipamentos [RERUM 2015].
15 http://makers.sigfox.com
 Uma possvel estratgia para mitigar o problema da energia fazer uso tcnica
de colheita de energia (do ingls Energy Harvesting) [Ramos et al. 2012]. A estratgia
consiste em derivar energia de fontes externas ao dispositivo, por exemplo, energia so-
lar, trmica, elica, cintica. A energia colhida (geralmente em pequenas quantidades)
armazenada e deve ser utilizada para suprir as necessidades dos objetos como comunica-
o e processamento, como feito pelos autores [Liu et al. 2013]. Contudo, a colheita de
energia tambm trs ao menos um outro desafio que discutiremos a seguir, o qual pode
ser ponto de partida para novas pesquisas.
Dado que os dispositivos possuam a capacidade de colher energia do ambiente em
que esto inseridos diversas questes surgem. Por exemplo, como programar as atividades
que o dispositivo deve desempenhar dado o oramento de energia (Energy Budget). Em
outras palavras, como gastar a energia em funo das atividades que se deve fazer? Para
exemplificar, imagine a situao em que dispositivo deve realizar tarefas durante as 24
horas do dia, porm somente quando h luz do sol possvel captar energia do ambiente
e o dispositivo no est acessvel fisicamente. Alm disso, sabe-se que a carga da bateria
no suporta 24 horas com o dispositivo em operao perenemente. Sendo assim, as ati-
vidades do dispositivo deve ser realizada de modo intermitente, ou seja, alterando entre
realizar os comandos requeridos e entrar em modo de espera ou baixa potncia (sleep
mode). Portanto, a atividade deve ser realizada de modo inteligente dado a demanda de
atividades e oramento de energia residual e adquerida do ambiente.

1.2.3.2. Tecnologias de hardware

Diante do que foi mencionado nas sees anteriores fica claro que os objetos in-
teligentes e tecnologias de comunicao apresentam diferentes caractersticas e limita-
es. Ao passo que os equipamentos IoT diminuem, as limitaes tendem a aumentar
devido seu espao reduzido. Anos atrs foi previsto a possibilidade de criar dispositivos
em escala nanomtrica e hoje isto uma realidade com os Microelectromechanical sys-
tems (MEMS) [Angell et al. 1983]. J hoje, estas ideias esto se consolidando com os con-
ceitos Claytronics e Programmable Matter [Goldstein et al. 2005]. A ideia dos concei-
tos consiste em combinar robs de escala nanomtrica (claytronic atoms ou catoms)
para formar outras mquinas. Os catoms eventualmente sero capazes se comunicar-
se, mover-se e se conectar com outros catoms para apresentar diferentes formas e uti-
lidades. Uma outra perspectiva futura quanto ao hardware diz respeito ao System on a
Chip (SoC). Neste conceito, a ideia ter um circuito integrado que detm todos os com-
ponentes de um computador. Para o caso dos objetos inteligentes, este sistema integrar
o rdio, o microcontrolador e sensores/atuadores. Entretanto, atualmente isto um pro-
blema, pois o componente rdio requer sofisticado arranjo para ser posto em um nico
chip [Vasseur and Dunkels 2010].
H poucos anos era possvel apontar o fator custo como limitante para adoo e
desenvolvimento dos objetos inteligentes. Entretanto, hoje possvel encontrar solues
IoT disponveis no mercado com custo regular. No que tange desenvolver para IoT,
possvel afirmar que o custo do hardware j acessvel diante de produtos como o Rasp-
berry Pi, Arduino e similares permitem desde de a prototipagem at a produo final de
solues IoT a baixo custo, por exemplo, o Raspberry Pi 3 custa US$ 35.

1.3. Softwares e Ambientes de Desenvolvimentos para IoT

Esta seo aborda assuntos referentes a camada de software que orquestra a lgica
de operao dos objetos inteligentes. O bloco bsico de identificao e os mecanismos
de comunio so os pontos centrais da seo. Alm disso, sero pontuados os sistemas
operacionais para IoT, bem como os principais ambientes desenvolvimento. O tpico
a seguir introduz alguns argumentos e requisitos para softwares utilizados na IoT. Os
desdobramentos dos pontos levantados sero objetos de anlise ao longo da seo.

1.3.1. Software para rede de objetos inteligentes

RSSF foi objeto de grande anlise por acadmicos e industriais nos ltimos anos
como exposto na Seo 1.1. Em seguida, a conexo entre as RSSF e a Internet foi uma
evoluo natural. Entretanto, pesquisadores da rea notam que uso dos protocolos da
Internet (TCP/IP), sem modificaes, impraticvel nos dispositivos com recursos limi-
tados, os quais so bastante utilizados na IoT de hoje. Para alcanar as demandas da IoT
por escalabilidade e robustez, a experincia em RSSF mostra que so necessrios algorit-
mos e protocolos especializados, por exemplo, protocolos que viabilizem processamento
ao longo da rede (in-network processing) [Santos et al. 2015b, Fasolo et al. 2007] para
mitigar as restries impostas pelos dispositivos e prover escalabilidade e eficincia. Por
outro lado, a arquitetura fim-a-fim da Internet no foi planejada para essas exigncias (ex:
dezenas de milhares de dispositivos em uma nica sub-rede e extremas limitaes de ener-
gia), portanto tal arquitetura necessita de ajustes para comportar essas novas demandas.
As RSSF e sua evoluo, a IoT, cresceram em um ambiente com maior liberdade
de desenvolvimento do que a Internet, por exemplo, no era preciso enfrentar questes
de compatibilidade. Diante desta autonomia diversas ideias surgiram tanto ao nvel de
software quanto de hardware. Entretanto, muitas dessas ideias no frutificaram, pois no
eram completamente interoperveis com a Internet, o que diminui significativamente o
impacto da tcnica no mundo real. Essas novas ideias, que no empregam o uso da ar-
quitetura da Internet, foram obrigadas a usar um gateway para intercambiar informaes
entre os objetos inteligentes e outros sistemas na Internet. A implementao de um ga-
teway , em geral, complexa e o seu gerenciamento complicado, pois alm de realizarem
funes de traduo, possuem encargos semntico e o de provedor de servios para a ca-
mada de aplicaes. A complexidade destas funes torna o gateway um gargalo para
IoT em dois sentidos. No primeiro, toda informao de e para a rede de objetos inteligen-
tes transita atravs do gateway. No segundo, a lgica de operao da Internet diz que a
inteligncia do sistema deve ficar nas pontas [Saltzer et al. 1984], porm com o emprego
dos gateways a inteligncia da IoT fica no meio da rede, o que contradiz os princpios da
arquitetura da Internet. Para tratar desses problemas a Internet Engineering Task Force
(IETF) criou dois grupos para gerenciar, padronizar e levantar os requisitos para as redes
de baixa potncia (Low-Power and Lossy Networks (LLN)) relacionadas a seguir:
6LoWPAN: IETF atribuiu ao IPv6 in Low-Power Wireless Personal Area Networks Wor-
king Group a responsabilidade de padronizar o Internet Protocol version 6 (IPv6) para
redes que fazem uso de rdios sobre o padro IEEE 802.15.4 que, por sua vez, especifica
as regras das camada mais baixas (enlace e fsica) para redes sem fio pessoais de baixas
potncia de transmisso.
RoLL: Routing over Low-Power and Lossy Links Working Group caracterizado pelo
IETF como a organizao que padronizar o protocolo de roteamento, que utilizar o
IPv6 em dispositivos com limitaes de recursos. O grupo j definiu o protocolo: IPv6
Routing Protocol for Low-Power and Lossy Networks (RPL). Este protocolo o estado-
da-arte em roteamento para IoT, o qual constri uma topologia robusta com mnimo de
estados necessrios. O RPL ser objeto de discusso mais adiante.

1.3.2. Arquitetura para IoT

Para conectar bilhes de objetos inteligentes Internet se faz necessrio um arqui-
tetura flexvel. Na literatura possvel notar uma variedade de propostas de arquitetura so-
fisticadas, que se baseiam nas necessidades da academia e industria [Al-Fuqaha et al. 2015].
O modelo bsico de arquitetura apresenta 3 camadas, como exibido na Figura 1.5.
A primeira camada
a de objetos inteligentes ou
camada de percepo. Esta
Camada de Aplicao camada representa os obje-
tos fsicos, os quais atravs
de sensores coletam e pro-
Camada de Rede
cessam informaes. Na Ca-
mada de Rede, as abstraes
Camada de Percepo das tecnologias de comuni-
cao, servios de gerenci-
amento, roteamento e iden-
Figura 1.5. Arquitetura de 3 camadas para IoT. 17 tificao devem ser realiza-
dos. Logo acima, encontra-
se a Camada de Aplicao, a
qual responsvel por prover servios para os clientes, por exemplo, uma aplicao pode
medies de temperatura e umidade para clientes que requisitam estas informaes.

1.3.3. IP para IoT

As redes de computadores foram criadas inicialmente para conectar as universida-
des, e no era esperado que ela se expandisse para os computadores pessoais. Neste novo
contexto, a tecnologia IPv4 foi o padro utilizado para enderear os dispositivos de rede e
suportar a Internet, entretanto, no era imaginado que a Internet cresceria e poderia conter
dezenas de milhares de pontos finais em uma nica sub-rede, tal como agora previsto
para a IoT (veja Seo 1.1). O crescimento da rede mundial de computadores implicou
em menor quantidade de endereos IPv4 disponveis. Isto mostrou que o IPv4 no era
escalvel o suficiente para atender a demanda da IoT.
O IPv6 uma abordagem mais eficaz para solucionar a escassez de endereos
IPv4. Os 32 bits alocados originalmente para o protocolo IPv4 foram expandidos para
128 bits, viabilizando que qualquer dispositivo no mundo possua um IP vlido na Internet.
17 Imagem e texto baseados em [Khan et al. 2012, Al-Fuqaha et al. 2015].
O IPv6 um passo importante em direo nova fase da Internet, chamada de Internet
das Coisas. Na IoT, os elementos da rede so endereados unicamente usando IPv6 e
geralmente possuem o objetivo de enviar pequenas quantidades de dados contendo estados
dos dispositivos. Para operar plenamente, o IPv6 requer 256 bits para endereos e MTU
de 1280 bytes e outros bits para cabealho. Contudo, o IPv6 no se adequa as limitaes
na maioria dos dispositivos empregados na IoT, por exemplo, dispositivos sobre o padro
IEEE 802.15.4 esto limitados a pacotes de 128 bytes. Para resolver estes problemas,
IETF criou o 6LoWPAN [Kushalnagar et al. 2007].
6LoWPAN18 uma camada de adaptao primariamente desenvolvida para o pa-
dro IEEE 802.15.4. A principal ideia realizar a compresso de pacotes IPv6 (ID-
6lowpan-hc19 ), permitindo a dispositivos com baixo poder computacional o uso do IPv6.
A compresso do 6LoWPAN possvel atravs da utilizao de informaes de proto-
colos presentes em outras camadas. Por exemplo, o 6LoWPAN pode utilizar parte do
endereo MAC do dispositivo para atribuir um endereo IPv6 para o objeto inteligente.
Desta forma, o 6LoWPAN requer menos bits que o IPv6 para realizar o endereamento.
O pesquisador Adam Dunkels20 realizou uma srie de contribuies na rea da
Internet das Coisas. Trs de suas principais contribuies so as implementaes da pilha
TCP/IP para dispositivos de baixa potncia. Estas implementaes so conhecidas como:
low weight IP (lwIP), o micro IP (IP) e o sistema operacional para IoT Contiki.
A lwIP uma implementao reduzida da pilha TCP/IP para sistemas embarca-
dos21 . A lwIP possui mais recursos do que a pilha IP, discutida a seguir. Porm, a
lwIP pode prover uma vazo maior. Atualmente esta pilha de protocolos mantida por
desenvolvedores espalhados pelo mundo22 . A lwIP utilizada por vrios fabricantes de
sistemas embarcados como, por exemplo, Xilinx e Altera. lwIP conta com os seguintes
protocolos IP, ICMP, UDP, TCP, IGMP, ARP, PPPoS, PPPoE. As aplicaes includas
so: servidor HTTP, cliente DHCP, cliente DNS, ping, cliente SMTP e outros.
A IP (Micro IP) uma das menores pilhas TCP/IP completas do mundo23 . De-
senvolvida para pequenos microcontroladores (processadores de 8-bit ou 16-bit), sistemas
onde, o tamanho do cdigo e memria RAM disponvel so escassos, IP precisa de no
mximo 5 kilobytes de espao de cdigo e de poucas centenas de bytes de RAM. Atual-
mente, a IP foi portado para vrios sistemas24 e integra o Contiki.

1.3.4. Modelos de conectividade em redes de objetos inteligentes

Nesta subseo, sero abordados os modelos de conectividade para uma rede IPv6
de objetos inteligentes. Os modelos de conectividade sero classificados como um espec-
tro que varia de uma rede de objetos inteligentes autnoma sem conexo com a Internet,
at a, aqui considera, autntica Internet of Things em que os objetos possuem acesso a

18 https://tools.ietf.org/html/rfc4919
19 https://tools.ietf.org/html/draft-ietf-6lowpan-hc-15
20 http://www.dunkels.com/adam/
21 http://www.ece.ualberta.ca/~cmpe401/docs/lwip.pdf
22 http://savannah.nongnu.org/projects/lwip/
23 https://github.com/adamdunkels/uip
24 http://www.dunkels.com/adam/software.html
 (I)
Objeto
Conexo
Internet
Servidor

(II)
Internet Firewall

Conexo confivel:
Via servidor
Direto ao objeto
inteligente

Proxy:
Servidor
Servios em nuvem para IoT Roteador/Servidor

Roteador

(III)
Roteador

Conexo

Internet Servidor

(I) (II) (III)

Sem conexo Acesso limitado Total acesso
com a Internet atravs da Internet pela conexo
com a Internet

Figura 1.6. Modelos de conectividade dos objetos inteligentes. (I)

Rede autnoma em que objetos inteligentes no possuem conexo
com a Internet pblica; (II) Rede de objetos inteligentes limitada,
pois o acesso aos dispositivos restrito; (III) IoT autntica em
que os objetos esto conetados Internet pblica.26

Internet pblica. As redes de objetos inteligentes sero parte de nossas vidas nos prximos
anos. Por isso, entender as bases da IoT no que tange seus paradigmas de comunicao e
modelos de conectividade de grande importncia, pois inevitavelmente estes dois quesi-
tos sero as chaves para construir novas aplicaes sobre a IoT. A Figura 1.6 destaca trs
modelos de conectividade de uma rede de objetos inteligentes. A seguir sero discutidas
cada um dos modelos de conectividade:

Rede de Objetos Inteligentes Autnoma: neste modelo a rede de objetos no

possui conexo com a Internet pblica. Existem diversos casos de uso para este
modelo, por exemplo, em uma rede de automao industrial (ex: usina nuclear)
pode-se requerer uma rede de objetos conectados entre si, porm completamente
inacessvel atravs da Web, ou seja, o uso da rede estritamente interno da corpo-
rao. A Figura 1.6 (I) apresenta uma abordam esquemtica do modelo.
Uma questo pode ser levantada aqui : Neste modelo de conectividade neces-
srio que os objetos inteligentes sejam endereados com IP? Para responder a esta
questo preciso refletir sobre a experincia passada com o IP em redes convenci-
onais. O IP apresenta diversas caractersticas que indicam um sim como resposta.
Por exemplo, a arquitetura IP interopervel, no sentido de que ele opera sobre a
camada de enlace e fsica com diferentes caractersticas. Outro argumento a favor
do sim, que o IP verstil e evolutivo, pois a arquitetura baseada no princpio
26 Imagem e texto baseados em [Vasseur and Dunkels 2010].
 fim-a-fim, em que a inteligncia da rede (aplicaes) residem nos pontos finais, en-
quanto a rede mantida simples (somente encaminhando pacotes). Isto permitiu a
evoluo contnua do procolo ao longo do tempo. Tendo dito isto, vlido alegar
que ao usar IP neste modelo, e os demais apresentados a seguir, a rede manter
compatibilidade com a arquitetura da Internet e estar de acordo com as tendncias
regidas pelos grupos RoLL e 6LoWPAN.

Internet Estendida: o termo Internet Estendida refere-se ao posicionamento

central deste modelo de conectividade em relao rede de objetos autnoma
e a autntica IoT. Em outras palavras, este modelo apresenta as redes de obje-
tos inteligentes parcialmente ou complementante conectadas com a Internet, porm
com apropriados requisitos de proteo e segurana [Vasseur and Dunkels 2010].
Aplicaes para Cidades Inteligentes (Smart Cities) so exemplos desse modelo de
conectividade. Estas aplicaes produziro informaes teis para que seus habi-
tantes possam melhorar a qualidade de vida e tomar decises importantes diaria-
mente. Para viabilizar as cidades inteligentes, pode-se usar o modelo apresentado
na Figura 1.6 (II), em que o acesso rede de objetos se d via firewall e proxy,
os quais possuem a tarefa de controle de acesso seguro s redes privadas de obje-
tos inteligentes. Deste modo, o modelo de conectividade estende a Internet por
permitir o acesso aos objetos inteligentes que at ento estavam isolados.

Internet das Coisas: este modelo, no espectro considerado, o extremo oposto ao

modelo de rede de objetos autnoma. Na IoT, os objetos inteligentes esto verda-
deiramente conectados Internet. Deste modo, os objetos podem prover servios
tais como quaisquer outros dispositivos na Internet, por exemplo, um objeto in-
teligente pode ser um servidor web. Qualquer usurio da Internet, seja humano
ou mquina, podero ter acesso aos recursos dos objetos inteligentes. Como mos-
trado na Figura 1.6 (III), o acesso se d ou conectando-se diretamente com o objeto
ou atravs de proxy27 . Estes servidores podem est localizados dentro ou fora da
sub-rede de objetos inteligentes e possuem a tarefa de coletar informaes dos dis-
positivos. Ao usar proxy tem-se que a Internet conecta o usurio ao servidor proxy,
o qual est conectado aos dispositivos. Assim, tcnicas de processamento dentro
da rede (in-networking processing) podem ser utilizadas, na rede entre o proxy e os
dispositivos, para preservar os recursos e manter o princpio fim-a-fim.

1.3.5. Paradigmas de comunicao para objetos inteligentes

A IoT uma evoluo e combinao de diversas tecnologias como discutido na
Seo 1.1. Neste sentido, existe interseo entre RSSF e IoT no que tange os paradigmas
de comunicao. Esta seo sero abordados tais paradigmas, classificando-os em qua-
tro categorias como mostrado na Figura 1.7. Os paradigmas diferem significativamente,
sendo assim o modo de comunicao pode acarretar em maior ou menor impacto no uso
dos recursos, em especial de memria, energia e na viabilidade de aplicaes sobre a rede.
A seguir cada um dos paradigmas ser descrito, bem como exemplificado atravs de um
protocolo que o implementa:
27 Um proxy um servidor (sistema de computador ou uma aplicao) que age como um intermedirio
para requisies de clientes solicitando recursos de outros servidores
(a) Muitos- para-Um (b) Um-para-Muitos (c) Mescla de (a) e (b) (d) Um-para-Um
Figura 1.7. Paradigmas de comunicao.

Muitos-para-Um (Many-to-One): em que os objetos inteligentes reportam infor-

maes, as quais so coletadas por estaes base (Raiz na Figura 1.7). Este para-
digma conhecido como coleta de dados, sendo o mais comum dos paradigmas,
visto que atende s demandas de comunicao de muitas aplicaes. Para realizar
a coleta de dados cria-se uma rvore de roteamento com raiz nas estaes base.
Em geral, este paradigma no acarreta em grande consumo de memria e energia.
Entretanto, aplicaes que necessitam de confirmao de entrega de dados so in-
viabilizadas, pois no existem rotas reversas entre a razes e os objetos na rede;
O exemplo estado-da-arte no que tange a coleta de dados o Collection Tree Proto-
col (CTP) [Gnawali et al. 2009]. O CTP emprega a mtrica Expected Transmission
count (ETX) [Javaid et al. 2009] e Trickle [Levis et al. 2004] para respectivamente
criar rotas de alta qualidade e manter tais rotas a baixo custo.

Um-para-Muitos (One-to-Many): conhecido como disseminao de dados, o

qual tem caracterstica reversa ao do paradigma de coleta de dados. Na dissemi-
nao de dados, comumente as estaes base enviam comandos para um ou vrios
objetos da rede. O intuito, em geral, reconfigurar ou modificar parmetros dos
dispositivos na rede. Para realizar a disseminao de dados pode-se, por exemplo,
efetuar inundaes na rede para alcanar os dispositivos alvo. Entretanto, no
possvel confirmar se os dados enviados foram entregues tal como ocorre com o
CTP para a coleta de dados. O custo em nmero de mensagens tambm pode ser
alto, caso sejam realizadas diversas inundaes na rede.
Deluge um exemplo de protocolo de disseminao [Chlipala et al. 2004]. O pro-
tocolo otimizado para disseminao para grandes quantidades de dados e faz isso
utilizando a mtrica ETX para encontrar rotas de alta qualidade;

Um-para-Muitos e vice-versa (One-to-Many and Many-to-One): um paradigma

que combina os dois anteriormente apresentados. Nesta abordagem, os objetos in-
teligentes podem se comunicar com as estaes base e vice versa. Isto amplia a
gama de aplicaes antes no possveis, tal como protocolos de transporte confi-
veis. Entretanto, o paradigma necessita de algum custo de memria adicional para
manter as rotas bi-direcionais.
 O eXtend Collection Tree Protocol (XCTP) [Santos et al. 2015a] um exemplo
desta categoria. Os autores argumentam que o XCTP uma extenso do CTP e,
por esse motivo, mantm todas as caractersticas do CTP ao mesmo tempo que o
estende ao viabilizar rotas reversas entre o sorvedouro e os elementos da rede.

Um-para-Um (Any-to-Any): esse paradigma o mais geral possvel, pois permite

que quaisquer dois objetos inteligentes da rede se comuniquem. Por ser mais abran-
gente, esta abordagem a mais complexa e geralmente exige maior quantidade de
recursos, principalmente de armazenamento, pois se faz necessrio manter rotas
para todos os dispositivos alcanveis na rede. Por outro lado, no apresenta res-
tries significativas para as aplicaes, exceto se os recursos computacionais dos
dispositivos for bastante limitados.
O principal protocolo de roteamento da Internet das Coisas reside nesta categoria.
O protocolo RPL, descito em detalhes a seguir, flexvel o suficiente para permitir
rotas um-para-um, alm de possibilitar que elementos de rede com diferentes capa-
cidades sejam empregados para otimizar o armazenamento das rotas. Ainda existe
um modo de operao em que, o RPL, opera sob o paradigma muitos-para-um,
sendo portanto, um protocolo flexvel no que tange as suas opes de operao.

1.3.6. IPv6 Routing Protocol for Low-Power and Lossy Networks

O Routing Protocol for Low-Power and Lossy Networks (RPL) um protocolo de
roteamento projetado para LLNs, projetado e padronizado pelo ROLL Working Group in
the IETF. Ele foi projetado para ser o protocolo padro que utiliza IPv6 para LLNs.

1.3.6.1. Grafo Acclico Direcionado

Dispositivos de rede executando RPL es-

to conectados de maneira acclica. Para esse
propsito, um Grafo Acclico Direcionado Orien- Rank = 0

tado ao Destino (DODAG, do ingls Destination-

Oriented Directed Acyclic Graph) criado, como Rank = 1 Rank = 1

mostra a Figura 1.8. Cada n mantm a melhor

rota para a raiz do DODAG. Para encontrar a me-
lhor rota os ns usam uma funo objetivo (OF)
que define a mtrica de roteamento (ex: ETX da Rank = 2

rota [Javaid et al. 2009]) a ser computada. Rank = 3 Rank = 3

O RPL utiliza quatro tipos de mensagens de Figura 1.8. DODAG RPL29 .

controle, elencadas a seguir, para manter e atuali-
zar as rotas. O processo de roteamento inicia pela
construo do DAG. A raiz anuncia informaes sobre seu DODAG (de um nico n) para
todos vizinhos alcanveis. Em cada nvel da rvore de roteamento os ns toam decises
sobre rotas baseadas na OF. Uma vez que o n se junta ao DODAG, ele escolhe uma raiz
como seu pai e calcula seu rank. O rank uma mtrica que indica as coordenadas do n
29 Imagem e texto baseados em [Vasseur et al. 2011, Cordero et al. 2013].
na hierarquia da rede [Vasseur et al. 2011]. Os demais ns iro repetir esse processo de
seleo do pai e notificao as informaes do DODAG para possveis novos dispositi-
vos. Quando esse processo se estabiliza, o roteamento de dados pode ento comear. O
processo descrito cria rotas ascendentes (dos ns para uma rais), para construir as rotas
descendentes o RPL emite mensagens especiais discutidas a seguir.

1.3.6.2. Mensagens

O RPL especifica trs tipos de mensagens utilizando o ICMPv6: DODAG Desti-

nation Advertisement Object (DAO), DODAG Information Object (DIO) e DODAG In-
formation Solicitation Message (DIS) descritas a seguir:
DIO: mensagens desse tipo so utilizadas para anunciar um DODAG e suas caractersti-
cas. Dessa forma, elas so usadas para a descoberta de DODAGs, sua formao e ma-
nuteno. O intervalo de envio de DIO controlado de modo eficiente pelo algoritmo
Trickle [Levis et al. 2004].
DIS: esse tipo de mensagem similar a mensagens de solicitao de rotas (RS) do IPv6, e
so usadas para descobrir DODAGs na vizinhana e solicitar DIOs de ns vizinhos, sem
possuir corpo de mensagem.
DAO: mensagens DAO so utilizadas durante o processo de notificao de rotas descen-
dentes. Elas so enviadas em sentido ascendente (dos ns que manifestam o desejo de
receber mensagens para seus pais preferenciais) para propagar informaes de destino ao
longo do DODAG. Essas informaes so utilizadas para o preenchimento das tabelas
de roteamento descendente, que permitem o trfego P2MP (ponto a multi-ponto) e P2P
(ponto a ponto).

1.3.6.3. Rotas Descendentes

As rotas descendentes, da raiz para os ns, so ativadas por meio de mensagens

DAO propagadas como unicast por meio dos pais em direo raiz. Essas mensagens
contm informaes sobre a quais prefixos pertencem a qual roteador RPL e quais pre-
fixos podem ser alcanados atravs de qual roteador RPL. O protocolo especifica dois
modos de operao para o roteamento descendente: storing e non-storing. Ambos os
modos requerem a gerao de mensagens DAO, que so enviadas e utilizadas de maneira
diferente em cada modo de operao. Os dois modos de operao so descritos a seguir:

Modo storing: No modo de operao storing, cada roteador RPL deve armazenar
rotas para seus destinos em um DODAG. Essas informaes so repassadas dos
ns para seus pais preferenciais. Isso faz com que, em ns mais prximos da raiz,
o armazenamento necessrio seja definido pelo nmero de destinos na rede. Com
isso, a memria necessria em um n prximo raiz e um outro distante da raiz
pode variar drasticamente, o que faz com que algum tipo de implementao e ma-
nuteno administrativa contnua nos dispositivos sejam necessrias, conforme a
rede evolui [Clausen et al. 2013]. Entretanto, tal interveno invivel, devido ao
perfil dinmico da rede.
 Cliente Servidor Cliente Servidor Cliente Servidor Cliente Servidor Cliente Servidor
CON [0xbc90]
CON [0xbc90] CON [0xbc90] GET /temperature
CON [0x7d34] GET /temperature GET /temperature
ACK [0xbc90]
NON [0x01a0]
Algum tempo depois

ACK [0x7d34] ACK [0xbc90] ACK [0xbc91]

2.05 Content 4.04 Not Found ACK [0xbc90]
"22.5 C" "Not found" 2.05 Content
"22.5 C"

(d) Requisio com respostas

(a) Mensagem com confirmao (b) Mensagem sem confirmao (c) Mensagem de requisio e resposta
separadas

Figura 1.9. Tipos de mensagem do CoAP32 .

Modo non-storing: No modo non-storing cada n gera e envia mensagens DAO

para a raiz do DODAG. O intervalo no qual o DAO enviado varia de acordo com
a implementao. Entretanto, a especificao do protocolo sugere que esse inter-
valo seja inversamente proporcional distncia do n a raiz. Dessa forma, um n
folha gera mais mensagens que um n intermedirio, por exemplo. Aps coletar
toda informao necessria, a raiz agrega essa informao. Se ela precisa enviar
uma mensagem descendente na rede, ela deve utilizar um cabealho IPv6 para rote-
amento de origem (source routing). Dessa forma, os ns encaminham a mensagem
at que ela alcance seu destino [Tsvetko 2011]. Ou seja, caso os ns no possuam
capacidade de armazenamento para operarem no modo storing, a rede sofre maior
risco de fragmentao e, portanto, perda de pacotes de dados, consumindo a capa-
cidade da rede com o roteamento de origem [Clausen et al. 2013].

1.3.7. Protocolos da camada de aplicaes para IoT

O famoso protocolo HTTP foi utilizado para acessar informaes na Internet
usando a estratgia requisio/resposta sobre o paradigma cliente/servidor. O HTTP foi
desenvolvido para redes predominantemente formada por PCs. Diferentemente dos PCs,
os dispositivos usados na IoT possui poder computacional restrito, o que limita a utiliza-
o do protocolo HTTP nesses dispositivos. Para resolver esse problema, dois protocolos
da camada de aplicao desenvolvidos especificamente para recuperar informaes de
dispositivos com baixo poder computacional.
O Constrained Application Protocol (CoAP) definido e mantido pelo IETF Cons-
trained RESTful Environments (CoRE) working group30 . O CoAP define uma forma de
transferir dados tal como feito atravs do REpresentational State Transfer (REST) e,
para tanto, utiliza funcionalidades similares ao do HTTP tais como: GET, POST, PUT,
DELETE. REST permite que clientes e servidores acesse ou consumam servios web de
maneira fcil usando Uniform Resource Identifiers (URIs). O CoAP diferente do REST
por usar o protocolo UDP, o que o coloca como mais adequado para aplicaes em IoT.
O CoAP apresenta duas camadas em sua arquitetura interna, objetivando de per-
mitir que dispositivos de baixa potncia possam interagir atravs de RESTfull. A primeira
30 https://datatracker.ietf.org/doc/charter-ietf-core/
32 Fonte: https://tools.ietf.org/html/rfc7252
camada implementa implementa os mecanismos de requisio/resposta. A segunda, de-
tecta mensagens duplicadas e fornece comunicao confivel sobre o UDP. O CoAP uti-
liza quatro tipos de mensagens: confirmable, non-confirmable, reset e acknowl edgement.
Estas imagens esto exibidas na Figura 1.9. A confiabilidade do protocolo CoAP im-
plementada ao combinar as mensagens confirmable e non-confirmable sobre o UDP.
As URIs CoAP so utilizadas da seguinte forma coap://URI. Para facilitar o
acesso aos recursos existem algumas extenses que so utilizadas para integrar o CoAP
aos browsers, por exemplo, a Copper para Firefox. Outras informaes podem ser encon-
tradas na RFC 725233 e o conjunto de implementaes existentes podem ser encontradas
no site de um dos autores do CoAP34 .
O Message Queue Telemetry Trans-
port (MQTT) um protocolo da camada de apli- Publisher Broker Subscriber
cao para IoT. O MQTT foi projetado para
dispositivos extremamente limitados e utiliza a Subscribe(tpico)

estratgia de publish/subscribe para transferir Publish (tpico, info)

mensagens. O principal objetivo do MQTT Publish (tpico, info)
minimizar o uso de largura de banda da rede e
recursos dos dispositivos. Alm disso, o MQTT
prover mecanismos para a garantia de entrega 36
de mensagens. MQTT utiliza o TCP/IP como Figura 1.10. publish/subscribe .
protocolos das camada de transporte e rede res-
pectivamente. O cabealho do protocolo MQTT pode assumir tamanho fixo ou varivel.
O tamanho fixo possui 2 bytes. Um exemplo de uma implementao open source do
MQTT o Mosquitto37 .
O MQTT consiste de trs componentes bsicos: o subscriber, o publisher e o
broker. A Figura 1.10, mostra a ordem de operao do MQTT. Inicialmente dispositivos
se registram (subscribe) a um broker para obter informaes sobre dados especficos,
para que o broker os avise sempre que publicadores (publishers) publicarem os dados
de interesse. Os dispositivos inteligentes (publishers) transmitem informaes para os
subscriber atravs do broker.

1.3.8. Ambientes de desenvolvimento

Assim como softwares para computadores de propsito geral, o software que roda
no microcontrolador dentro de um objeto inteligente tambm escrito em uma linguagem
de programao e compilado para o cdigo de mquina para o microcontrolador. O cdigo
de mquina escrito na ROM do microcontrolador e quando o objeto inteligente ligado,
esse software executado [Vasseur and Dunkels 2010].

33 https://tools.ietf.org/html/rfc7252
34 http://coap.technology
36 Imagem baseada no contedo do site: http://mqtt.org/.
37 http://mosquitto.org
1.3.8.1. Sistemas Operacionais

Assim como os computadores domsticos, os objetos inteligentes tambm utili-

zam Sistemas Operacionais (SO). Entretanto, como os objetos inteligentes possuem re-
cursos fsicos limitados, devido ao pequeno tamanho, baixo custo e baixo consumo de
energia, os sistemas operacionais para esses objetos devem ser muito menores e consu-
mir menos recursos. Nesta Seo, sero descritos brevemente os dois principais siste-
mas operacionais para objetos inteligentes: Contiki e TinyOS, alm do sistema operaci-
onal Android que opera em grande parte dos dispositivos de sensoriamento participativo
(smartphones) e algumas variaes do sistema Linux orientadas a Internet das coisas.
Todos esses sistemas operacionais so cdigo aberto e os respectivos cdigos fonte po-
dem ser encontrados na web. Ao final, a Tabela 1.2 apresenta uma comparao entre os
principais sistemas apresentados.

Contiki 38 : Contiki um sistema operacional leve de cdigo aberto para sistemas

embarcados de rede, que fornece mecanismos para o desenvolvimento de softwa-
res para IoT e mecanismos de comunicao que permitem a comunicao dos dis-
positivos inteligentes. Alm disso, o Contiki tambm fornece bibliotecas para a
alocao de memria, abstraes de comunicao e mecanismos de redes de r-
dios de baixa potncia. O Contiki foi o primeiro sistema operacional para objetos
inteligentes a fornecer comunicao IP com a pilha IP TCP/IP e, em 2008, o sis-
tema incorporou o IPv6, a menor pilha IPv6 do mundo. Por utilizar IP, o Contiki
pode se comunicar diretamente com outros aplicativos baseados em IP e servios
de web [Vasseur and Dunkels 2010]. Tanto o sistema operacional quanto suas apli-
caes so implementados na linguagem C, o que faz o sistema ser altamente por-
tvel [Dunkels et al. 2004].
TinyOS39 : Assim como o Contiki, o TinyOS um sistema operacional de cdigo
aberto para redes de sensores e objetos inteligentes. Um programa do TinyOS
descrito em [Levis et al. 2005] como um grafo de componentes, cada um sendo
uma entidade computacional independente que expe uma ou mais interfaces. Os
componentes podem ser chamados comandos (requisies a um componente para
executar algum servio), eventos (sinalizam a finalizao desse servio) ou tarefas
(usadas para expressar a concorrncia intra-componente). TinyOS possui um mo-
delo de programao baseado em componentes, codificado pela linguagem NesC,
um dialeto do C. O modelo de programao fornecido pela linguagem NesC se
baseia em componentes que encapsulam um conjunto especfico de servios, e se
conectam (comunicam) por meio de interfaces.
Android40 : Android uma plataforma de software de cdigo aberto para dispo-
sitivos mveis que inclui um sistema operacional, middleware e aplicativos41 . Os
vrios componentes do sistema operacional so projetados como uma pilha, com o
38 https://github.com/contiki-os
39 https://github.com/tinyos
40 O Android disponibilizado sob licena de cdigo aberto, apesar da maior parte dos dispositivos
apresentarem uma combinao de software livre e privado: https://github.com/android
41 http://developer.android.com/guide/basics/what-is-android
 Sistema Min. RAM Min. ROM Linguagem
Contiki <2kB <30kB C
TinyOS <1kB <4KB nesC e oTcl
RIOT 1.5kB 5kB C e C++
Snappy 128 MB Python, C/C++, Node JS e outras
Raspbian 256MB Python, C/C++, Node JS e outras
Tabela 1.2. Comparativo entre os principais SOs para IoT.

ncleo do Linux na camada mais baixa. Acima da camada do Linux, esto as bibli-
otecas nativas do Android, o que permite ao dispositivo manusear diferentes tipos
de dados. Na mesma camada que as bibliotecas est tambm o Android Runtime,
que possui um tipo de mquina virtual Java utilizada para a execuo de aplicativos
no dispositivo Android. A prxima camada est relacionada com o Framework de
aplicao, que fornece vrios servios de alto nvel ou APIs para os desenvolvedo-
res de aplicativos. Por fim, no topo da pilha, est a camada de aplicao.

Linux: Com a popularizao e o crescimento no desenvolvimento e pesquisa em

IoT, alguns sistemas operacionais baseados em Linux foram desenvolvidos. o RIOT 42
um sistema gratuito de cdigo aberto 43 desenvolvido por uma comunidade base
formada por empresas, acadmicos e amadores, distribudos em todo o mundo.
Essa plataforma baseada em Linux roda em 8, 16 ou 32-bits e possui suporte s
linguagens C e C++. Alm disso, possui suporte para IoT com implementaes
6LoWPAN, IPv6, RPL, e UDP. O Ubuntu tambm possui sua verso IoT, chamada
Ubuntu Core ou Snappy 44 . Essa verso reduzida em comparao ao Ubuntu
Desktop, uma vez que exige apenas 128 MB de memria RAM e um processador
de 600 Mhz. O desenvolvimento pode ser feito em diversas linguagens, como o
de uma aplicao Linux comum. Raspian 45 um sistema operacional gratuito ba-
seado no Debian e otimizado para o hardware do Raspberry Pi. Oferece mais de
35.000 pacotes deb de software, que esto pr-compilados, para serem facilmente
instalados no Raspberry Pi. O sistema est disponvel em trs verses: Raspbian
Wheezy, DRaspbian Jessie e Raspbian Jessie Lite.

1.3.8.2. Emuladores e Simuladores

Simulaes e emulaes so muito teis durante a fase de avaliao de arquiteturas

e protocolos para redes em geral. Estes ambientes de desenvolvimento permitem modelar
uma rede de computadores arbitrria especificando o comportamento dos elementos da
rede, bem como os enlaces de comunicao. Esta seo apresentar os principais simula-
dores e emuladores de redes de computadores que possuem suporte para IoT.
42 http://www.riot-os.org/
43 https://github.com/RIOT-OS/RIOT
44 http://www.ubuntu.com/internet-of-things
45 https://www.raspbian.org/
 Essencialmente h diferenas entre os emuladores e simuladores como desta-
cado em [Bagula and Erasmus 2015]. Emulador um sistema de hardware ou software
que permite que um sistema de computador (chamado de host) se comporte como um
outro sistema de computador (chamado de guest). Em outras palavras, o emulador se
comporta exatamente como o guest permitindo que o host execute software ou dispositi-
vos perifricos projetados para o sistema gest, por exemplo, o emulador Cooja do Contiki
permite que um computador se comporte como um dispositivo inteligente Tmote Sky46 .
J o simulador, por sua vez, uma tentativa de modelar (imitao) uma situao da vida
real ou hipottica em um computador. Com a simulao possvel estudar e ver como o
sistema simulado deveria operar no mundo real, por exemplo, um simulador de voo d a
sensao de que o usurio est voando em um avio, mas o usurio est completamente
desconectado da realidade, alm disso, possvel aplicar regras ao prazer do usurio e
posteriormente analisar os resultados.

ns-2/ns-3: Ns-2 um simulador de eventos discretos para rede de computadores

de cdigo aberto. As simulaes para ns-2 so compostas por cdigo em C++ e
scrips oTcl. O cdigo utilizado para modelar o comportamento dos ns, enquanto
o script controlam a simulao e especificam aspectos adicionais, como a topologia
da rede. Ns-3 tambm um simulador de eventos discretos, mas no uma exten-
so de seu antecessor, ns-2. Assim como o ns-2, o ns-3 adota a linguagem C++ para
a implementao dos cdigos, mas no utiliza mais scripts oTcl. Com isso, as si-
mulaes podem ser implementadas em C++, com partes opcionais implementadas
usando Python [Weingrtner et al. 2009].
Cooja: Cooja (Contiki OS Java) um emulador de aplicaes do sistema operaci-
onal Contiki, desenvolvido da linguagem Java. As simulaes no Cooja consistem
em ns sendo simulados, cada n possuindo seu tipo de n, sua prpria memria
e um nmero de interfaces [sterlind and of Computer Science 2006]. Um n si-
mulado no Cooja um sistema Contiki real compilado e executado. Esse sistema
controlado e analisado pelo Cooja 47 . Cooja possui uma interface para analisar e
interagir com os ns simulados, o que facilita o trabalho e a visualizao da rede.
Alm disso, possvel criar simulaes altamente personalizadas.
Tossim: Tossim o simulador de eventos discretos do sistema operacional TinyOS.
Ao invs de compilar uma aplicao TinyOS para um n sensor, os usurios podem
compil-lo para o TOSSIM, que executado em um PC. No Tossim possvel si-
mular milhares de ns, cada n, na simulao, executa o mesmo programa TinyOS.
O simulador se concentra em simular o TinyOS e sua execuo, ao invs de simular
o mundo real. Por isso, apesar de poder ser usado para entender as causas do com-
portamento observado no mundo real, no capaz de capturar todos eles e pode no
ser o mais fidedigno para avaliaes absolutas [Levis and Lee 2010]. Na abstrao
do Tossim, a rede um grafo orientado no qual cada vrtice um n e cada aresta
(enlace) tem uma probabilidade de erro de bit. O simulador fornece um conjunto
de servios que permitem interao com aplicativos externos [Levis et al. 2003].
46 http://www.eecs.harvard.edu/~konrad/projects/shimmer/references/

tmote-sky-datasheet.pdf
47 https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja
Nome Suporte GUI Licena Linguagem Sistema Operacional
GNU/Linux, FreeBSD,
ns-2 No Cdigo aberto C++ e oTcl
Mac OS e Windows
GNU/Linux, FreeBSD,
ns-3 Limitado Cdigo aberto C++ e python
Mac OS e Windows
Cooja Sim Cdigo aberto C Linux
Linux ou Cygwin no
Tossim Limitado Cdigo aberto nesC e python
Windows
Linux, Mac OS
OMNet++ Sim Comercial e cdigo aberto C++
e Windows
Castalia Sim Cdigo aberto C++ Linux e Windows
Linux, Mac OS
Sinalgo Sim Cdigo aberto Java
e Windows

Tabela 1.3. Comparativo entre os principais simuladores/emulado-

res para IoT.

OMNet++/Castalia: OMNeT++ um simulador de eventos discretos para modelar

redes de comunicao, multiprocessadores e outros sistemas distribudos ou parale-
los [Varga and Hornig 2008]. O OMNet++ fornece o maquinrio e as ferramentas
para criar simulaes de diferentes tipos de redes. OMNeT++ oferece uma IDE ba-
seada no Eclipse, um ambiente de execuo grfica e uma srie de outras ferramen-
tas. Existem extenses para simulao em tempo real, emulao de rede, integrao
de banco de dados, integrao de sistemas, entre outras funes [Varga et al. 2001].
Castalia um simulador para RSSF e outras redes de dispositivos embarcados de
baixa potncia. Ele baseado na plataforma do OMNeT++ e pode ser usado para
pesquisas e desenvolvimento que requerem testar algoritmos distribudos e/ou pro-
tocolos em modelos realistas de canais sem fio e rdio [Boulis et al. 2011].

Sinalgo: Sinalgo (Simulator for Network Algorithms) um framework de simu-

lao para testar e validar algoritmos de rede. Diferente da maioria dos outros
simuladores de rede, que passam a maior parte do tempo simulando as diferentes
camadas da pilha de rede, o Sinalgo foca na verificao de algoritmos de rede. Ele
oferece uma vazo da troca de mensagens na rede, sendo capaz de capturar bem a
viso dos dispositivos reais de rede. Apesar de ter sido desenvolvido para simulao
de redes sem fio, no limitado para apenas essa tecnologia. O Sinalgo utiliza a
linguagem JAVA, o que torna o desenvolvimento mais fcil e rpido, se comparado
com as linguagens especficas do hardware, alm de facilitar o processo de debug48 .

1.3.8.3. Testbeds

Testbed uma plataforma para implantar aplicaes em um contexto real, ou seja,

utilizando hardware real em larga escala, apropriada para a gesto de experimentao.
Atualmente, existem vrios testbeds em todo o mundo, que permitem a experimentao
48 http://dcg.ethz.ch/projects/sinalgo/
mais rpida, com tamanho, hardware e topologias diferentes. A lista a seguir apresenta os
principais testbeds para a experimentao em IoT.

WHY-NET: WHY-NET um testbed escalvel para Redes Sem-Fio Mveis. Ele

investiga diferentes tipos de tecnologias sem fio, individualmente e em conjunto.
As tecnologias sem fio diferentes incluem, Redes de Sensores e Antenas inteligen-
tes [Patel and Rutvij H. 2015].

ORBIT: ORBIT consiste de 400 ns de rdio que so fixos. Cada n fsico est
logicamente ligado a um n virtual em uma rede. Os ns de rdio possuem duas
interfaces 802.11x e Bluetooth. As medies podem ser realizados no nvel fsico,
MAC e rede [Patel and Rutvij H. 2015].

MiNT: Neste testbed, n de rdio 802.11 so aplicados em robs de controle re-

moto. Para evitar fontes de rudo, o testbed configurado em uma nica sala de
laboratrio. MiNT suporta reconfigurao topologia completa e mobilidade de n
irrestrita [Patel and Rutvij H. 2015].

IoT-LAB: IoT-LAB oferece uma infra-estrutura de grande escala adequada para

testar pequenos dispositivos sensores sem fios e comunicao de objetos heterog-
neos. Alm disso, ele oferece ferramentas web para desenvolvimento de aplicaes,
juntamente com o acesso de linha de comando direto plataforma. Firmwares de
ns sensores podem ser construdas a partir da fonte e implantado em ns reserva-
dos, atividade de aplicao pode ser controlada e monitorada, o consumo de energia
ou interferncia de rdio podem ser medidos usando as ferramentas fornecidas49 .

Indriya: Indriya um testbed de rede de sensores sem fio, que possui 127 motes
TelosB. Mais de 50% dos motes so equipados com diferentes mdulos de sensores,
incluindo infravermelho passivo (PIR), magnetmetro, acelermetro, etc. Indriya
usa o software de interface do usurio do Motelab, que fornece acesso baseado na
web para os ns do testbed. O testbed est localizado na Universidade Nacional de
Singapura [Doddavenkatappa et al. 2012].

1.3.9. Desafios e questes de pesquisa

Nesta seo, sero abordados dois pontos da IoT que apresentam desafios de im-
plementao e questes de pesquisa. O primeiro discute sobre a presena do elemento
gateway na rede IoT. J o segundo momento aborda segurana para IoT.

1.3.10. Gateway
Em IoT comum que os dispositivos apresentem tecnologias de comunicao
heterogneas, por exemplo BLE, ZigBee, e outros. Para conectar esses dispositivos
Internet, preciso que um elemento de rede realize a traduo entre os diversas tecnolo-
gias utilizadas, este elemento chamado de gateway. Na Figura 1.11 so apresentadas
duas vises possveis do gateway. Na Figura superior, o gateway realiza a traduo de
49 https://www.iot-lab.info
51 Imagem e texto baseados em [Shelby and Bormann 2011, Vasseur and Dunkels 2010].
 Figura 1.11. Pilha de protocolos de um gateway: Comunicao fim-
a-fim (superior); Comunicao atravs de um proxy (inferior)51 .

tecnologias distintas e o encaminhamento de mensagens. Neste caso, o gateway respeita

o princpio fim-a-fim, porm a complexidade aos nveis de hardware/software e geren-
ciamento aumentam, por exemplo, o gateway precisa implementar todas as interfaces de
comunicao da sub rede IoT, bem como a interface que o conecta Internet. Alm disso,
preciso um software para controlar e gerenciar as regras de operao da rede.
O gateway tambm pode ser visto como um prestador de servios da rede. Um
exemplo pode ser identificado na Figura 1.11 inferior. Neste caso, o gateway funciona
como um proxy, realizando compresso transparente para que aplicaes que utilizem
protocolo IP no necessitem de modificaes. Um local tpico para alocao de um proxy
seria no gateway, ou em um servidor proxy local [Shelby and Bormann 2011].

1.3.10.1. Segurana

Para que um sistema IoT seja seguro preciso estabelecer quais so os objetivos
de segurana desejveis. Existem ao menos trs grupos de objetivos desejveis para se-
gurana em IoT [Shelby and Bormann 2011]: (i) Confidencialidade: neste requisito os
dados transmitidos podem somente ser escutados e entendidos por elementos partici-
pantes da comunicao, isto , elementos sem autorizao sabem que ocorreu comuni-
cao, mas no sabem o contedo da comunicao; (ii) Integridade: aqui, os dados no
podem ser alterados por elementos da rede sem devida autorizao. comum que hackers
adulterem mensagens sem deixar vestgios e a quebra da integridade passe despercebida.
De modo geral, implementa-se integridade criptografando as mensagens e verificando-as
no lado do receptor; (iii) Disponibilidade: deseja-se manter o sistema sempre disponvel
e seguros contra ataques maliciosos. Entretanto, as redes sem fio esto sujeitas a interfe-
rncias de comunicao e hackers podem agir nesta vulnerabilidade. Neste sentido, o
sistema IoT deve ser capaz de identificar e tratar problemas como este para evitar ataques
Denial of Service (DoS).
 O modelo de ameaas (threat model) da IoT (6LoWPAN) semelhante ao uti-
lizado nos protocolos da Internet52 . Assume-se que o hacker possui controle sobre a
rede podendo ler, alterar ou remover qualquer mensagem na rede, portanto sem o suporte
a criptografia torna-se invivel proteger ou detectar adulteraes indevidas no sistema. O
suporte a segurana pode ser implementado em diferentes camadas da pilha de protoco-
los. Por exemplo, na camada de enlace pode-se aplicar o algoritmo Advanced Encryption
Standard (AES) em conjunto com Counter with CBC-MAC (CCM)53 para manter con-
fidencialidade a cada salto na rota entre os comunicantes, entretanto esta tcnica no
oferece qualquer segurana sobre a integridade dos dados. Por outro lado, na camada
de rede pode-se empregar IPsec54 para alcanar integridade, entretanto IPsec padro
considerado grande para as comuns restries dos dispositivos IoT, sendo assim, pre-
ciso adapt-lo. Vale pontuar que os requisitos de segurana para IoT variam de aplicao
para aplicao, portanto deve-se considerar um ou mais dos objetivos de segurana acima
mencionados ao implementar uma aplicao.

1.4. IoT na prtica

As sees anteriores trouxeram uma viso geral sobre as bases da IoT. Foram dis-
cutidas diversas caractersticas dos objetos inteligentes permeando particularidades teri-
cas e artefatos existentes j empregados na IoT. J esta seo traz uma perspectiva prtica
na IoT. Diante do que j foi discutido, o leitor est apto a por em prtica os conceitos
vistos. Os exerccios prticos visam que o leitor consolide e associe os conceitos teri-
cos e artefatos previamente discutidos. Alm disso, uma das prticas servir de ncora
para assuntos das prximas sees, vinculando as redes de objetos inteligentes, at aqui
apresentadas, com os desafios e prximos passos em relao ao futuro da IoT.
Os exemplos apresentados a seguir foram extrados do conjunto de exemplos do
sistema operacional Contiki verso 3.0. Presume-se que o leitor j tenha o Contiki insta-
lado e operacional55 . Todos os exemplos so de cdigo livre e hospedados no repositrio
oficial do Contiki. Inicialmente ser exemplificado como conectar os objetos inteligen-
tes utilizando IPv656 , em seguida, ser pleiteado o Erbium que uma implementao do
CoAP57 para redes de objetos de baixa potncia no Contiki.
Os experimentos sero apresentados visam atender o maior publico possvel. Para
isto, ao longo do texto a prtica exemplificada atravs do uso de simulador. Entretanto,
o minicurso tambm apresenta uma pgina web 58 e l existem materiais extra construdos
por ns autores ou referncias de livre acesso. No site encontra-se vdeo tutoriais, textos,
referncias e outros contedos relacionados.

52 O RFC 3552 apresenta boas prticas e discusses acerca de segurana em IoT: https://tools.
ietf.org/html/rfc3552
53 RFC 3610: https://www.ietf.org/rfc/rfc3610.txt
54 RFC 4301: https://tools.ietf.org/html/rfc4301
55 http://www.contiki-os.org/start.html
56 https://github.com/contiki-os/contiki/tree/master/examples/ipv6/rpl-border-router
57 https://github.com/contiki-os/contiki/tree/master/examples/er-rest-example
58 http://homepages.dcc.ufmg.br/~bruno.ps/iot-tp-sbrc-2016/
1.4.1. Rede objetos inteligentes IPv6
No primeiro experimento prtico, ser criada uma rede IPv6 de objetos inteli-
gentes utilizando Cooja (veja a Seo 1.3.8). O Contiki oferece uma implementao do
6LoWPAN em conjunto com o protocolo de roteamento RPL [Hui 2012]. Alm disso, o
sistema operacional tambm oferece suporte a pilha de protocolos IP TCP/IP (veja Se-
o 1.3.3). Para comear, inicie o Cooja atravs do atalho da rea de trabalho ou execute
o comando abaixo e, em seguida, crie uma nova simulao:
Inicie o Cooja executando os comandos abaixo:
$ cd <DIR>+contiki/tools/cooja/
$ ant run

Dando seguimento prtica, dispositivos Tmote Sky sero emulados. Um dos motes ser-
vir como roteador de borda da rede de objetos IPv6. O roteador de borda o dispositivo
responsvel por configurar um prefixo de rede e iniciar a construo da rvore de rotea-
mento do RPL. Em outras palavras, o roteador de borda nada mais que a raiz da rvore
de roteamento e interlocutor entre a rede de objetos e a rede externa.
O cdigo do roteador de borda est localizado em:
<DIR>+contiki/examples/ipv6/rpl-border-router/border-router.c

Com o Cooja aberto, v at a aba de criao de mote e adicione um Sky mote. Na tela
seguinte, compile e carregue, como firmeware, o cdigo do roteador de borda. Finalmente
adicione 1 mote deste tipo.
Aps configurar o roteador de borda, a prxima etapa povoar a rede com objetos
inteligentes. O cdigo sky-websense.c ajudar nesta fase.
O cdigo do sky-websense.c est localizado em:
<DIR>+contiki/examples/ipv6/sky-websense/sky-websense.c

Este cdigo uma aplicao que produz dados sensoreados e prover acesso a estas in-
formaes via webserver. Adicione alguns59 motes desse tipo. recomendvel que o o
leitor investigue o cdigo sky-websense.c para entender o que ele faz. Retorne para o Co-
oja. Na aba chamada Network, localize o roteador de borda e no seu menu de contexto
selecione a opo mostrada abaixo. O Cooja informar que o roteador de borda criou um
socket e est escutando na porta local 60001. Em seguida inicialize a simulao.
No Menu-Contexto do Roteador de Borda selecione:
Mote tools for sky/Serial socket (SERVER)"

Abra um novo terminal e execute os seguintes comandos:

Comandos para executar o programa tunslip6
$ cd <DIR>+contiki/examples/ipv6/rpl-border-router/
$ make connect-router-cooja TARGET=sky

59 Adicione 2 ou 5 motes para manter a carga de processamento e consumo de memria baixos.

Estes comandos acabam por executar o programa tunslip6. O programa configura
uma interface na pilha de protocolos do Linux, em seguida, conecta a interface ao socket
em que o roteador de borda est escutando. O tunslip6 far com que todo o trfego
endereado ao prefixo aaaa:60 seja direcionado para a interface do Cooja.

Terminal 2 tunslip6

ifconfig tun0 inet hostname up

ifconfig tun0 add aaaa::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0 Link encap:UNSPEC HWaddr 00-00...

inet addr:127.0.1.1 P-t-P:127.0.1.1
Mask:255.255.255.255
inet6 addr: fe80::1/64 Scope:Link
inet6 addr: aaaa::1/64 Scope:Global
...

Address:aaaa::1 => aaaa:0000:0000:0000

Got configuration message of type P
Setting prefix aaaa::
Server IPv6 addresses:
aaaa::212:7401:1:101
fe80::212:7401:1:101

O tunslip6 apresentar uma sada semelhante a mostrada na caixa de ttulo Terminal 2

e o Cooja apresentar algo como mostrado na figura ao lado61 . Agora j possvel verifi-
car se os Tmotes Sky emulados esto acessveis atravs de ferramentas como o ping6.
Realize testes com os seguintes comandos:
$ping6 aaaa::212:7401:1:101 (Roteador de borda)
$ping6 aaaa::212:7402:2:202 (Tmote rodando sky-websense)

Em seu navegador acesse o endereo do roteador de borda http://[aaaa::212:7401:1:101]/

O Roteador de Borda responder com:
A rede de exemplo possui 3 motes
e apresenta topologia exibida na fi- Neighbors

gura abaixo, em que :101 o rote- fe80::212:7402:2:202

ador de borda. Routes

aaaa::212:7402:2:202/128 via fe80::212:7402:2:202 16711412s

aaaa::212:7403:3:303/128 via fe80::212:7402:2:202 16711418s

A resposta a requisio feita ao roteador de borda conter duas partes. A primeira, exibe
a tabela de vizinhana, ou seja, os ns diretamente ligados na rvore de roteamento do
RPL (Neighbor Table). Na segunda, so listados os ns alcanveis (Routes) e o prximo
salto na rota at aquele destinatrio.
Agora acesse, pelo navegador, os recursos (luminosidade e temperatura) providos pelos
Tmotes rodado sky-websense como mostrado a seguir:

60 Vale ressaltar que os endereos aqui apresentados sero expressos em modo comprimido. Por exemplo,
aaaa : 0000 : 0000 : 0000 : 0212 : 7401 : 0001 : 0101 o mesmo que aaaa :: 212 : 7401 : 1 : 101
61 Note que os motes executando websense no foram exibidos.
 Exemplo de resposta:
http://[aaaa::212:7403:3:303]/l
Acesse os Tmotes pelo browser com:
http://[IPv6 do Tmote]/
http://[IPv6 do Tmote]/l
http://[IPv6 do Tmote]/t

Exemplo de requisio:
http://[aaaa::212:7403:3:303]/l

1.4.2. Erbium (Er) REST: uma implementao CoAP no Contiki-OS

Esta prtica abordar o uso de Representational State Transfer (REST), em portu-
gus Transferncia de Estado Representacional. Para tanto, ser utilizado o Erbium (Er),
uma implementao do IETF CoAP de RTF 7252 (veja a Seo 1.3.7). O Er foi projetado
para operar em dispositivos de baixa potncia [Kovatsch et al. 2011] e tem cdigo livre
disponvel junto com o sistema operacional Contiki. Para iniciar ser feita uma breve
reviso da implementao e uso do CoAP no Contiki.

1.4.2.1. CoAP API no Contiki

No CoAP, os servios disponibilizados pelo servidor so vistos como recursos, os

quais so identificados por URIs nicas. O CoAP oferece diferentes mtodos para realizar
operaes bsicas CRUD sendo eles: POST para criar um recurso; GET para recuperar
um recurso; PUT para atualizar algum recurso e; DELETE para apagar um recurso.
A implementao do CoAP no Contiki est localizada no diretrio:
<DIR>+contiki/apps/er-coap<version>

Para cada recurso disponibilizado no servidor usando CoAP existe uma funo (handle
function), a qual a aplicao REST chama sempre que ocorre uma requisio de um cli-
ente. Com a handlefunction, o servidor capaz de tratar cada requisio e responder
adequadamente com o contedo do recurso solicitado.
As macros62 a seguir so providas pela implementao do CoAP/Erbium do Con-
tiki para facilitar a criao de novos recursos para o servidor:
Normal Resource: este tipo de recurso serve de base para todos as demais macros. O
Normal Resource associa uma URI a uma handle function.
1 # d e f i n e RESOURCE( name , a t t r i b u t e s , g e t _ h a n d l e r , p o s t _ h a n d l e r , p u t _ h a n d l e r ,
delete_handler )

Parent Resource: destinado a gerenciar diversos sub-recursos de uma URI. Por exemplo,
a URI test/parent/<sub-recursos>.
62 Mais
detalhes sobre as macros, atributos e estruturas so encontrados em: https://github.com/
contiki-os/contiki/tree/master/apps/er-coap
 1 # d e f i n e PARENT_RESOURCE( name , a t t r i b u t e s , g e t _ h a n d l e r , p o s t _ h a n d l e r , p u t _ h a n d l e r ,
delete_handler )

Separate Resource: esta macro bastante utilizada quando necessrio enviar informa-
es em partes. Por exemplo, quando se tem algum arquivo na memria do dispositivo.
Deste modo, o arquivo pode ser enviado em partes separadas para o cliente que o solicitou.
1 # d e f i n e SEPARATE_RESOURCE ( name , a t t r i b u t e s , g e t _ h a n d l e r , p o s t _ h a n d l e r , p u t _ h a n d l e r ,
delete_handler , resume_handler )

Event Resource e Periodic Resource: no primeiro, a ideia que quando um evento

ocorra o dispositivo envie uma mensagem para algum cliente que esteja observando
aquele recurso, por exemplo, quando um boto no dispositivo pressionado envia-se uma
mensagem para o cliente. No segundo, existe uma periodicidade no envio das mensagens,
para isto um parmetro extra indica o perodo. Vale pontuar que os dois recursos so
observveis, isto , um cliente ao assinar o feed daquele recurso receber notificaes
sempre que ocorrer mudanas naquele recurso.
1 # d e f i n e EVENT_RESOURCE( name , a t t r i b u t e s , g e t _ h a n d l e r , p o s t _ h a n d l e r , p u t _ h a n d l e r ,
delete_handler , event_handler )

1 # d e f i n e PERIODIC_RESOURCE ( name , a t t r i b u t e s , g e t _ h a n d l e r , p o s t _ h a n d l e r , p u t _ h a n d l e r ,
delete_handler , period , periodic_handler )

Para exemplificar a implementao de um recurso, ser tomado como modelo o

recurso helloworld do arquivo er-example-server.c do conjunto de exemplo do Er. Abaixo
exibido um fragmento do arquivo e alguns comentrios traduzidos.
1 /
2 A s s i n a t u r a do metodo : nome do r e c u r s o , metodo que o r e c u r s o m a n i p u l a e URI .
3 /
4 RESOURCE( h e l l o w o r l d , METHOD_GET, " h e l l o " , " t i t l e = \ " H e l l o w o r l d ? l e n = 0 . . \ " ; r t = \ " T e x t \ " " ) ;
5
6 /
7 H a n d l e e r f u n c t i o n [ nome do r e c u r s o ] _ h a n d l e ( Deve s e r i m p l e m e n t a d o p a r a c a d a r e c u r s o )
8 Um p o n t e i r o p a r a b u f f e r , no q u a l a c o n t e u d o ( p a y l o a d ) da r e s p o s t a s e r a a n e x a d o .
9 R e c u r s o s s i m p l e s podem i g n o r a r o s p a r a m e t r o s p r e f e r r e d _ s i z e e o f f s e t , mas devem
10 r e s p e i t a r REST_MAX_CHUNK_SIZE ( l i m i t e do b u f f e r ) .
11 /
12 void helloworld_handler ( void request , void response , u i n t 8 _ t buffer , u i n t 1 6 _ t
preferred_size , int32_t offset ) {
13 c o n s t c h a r l e n = NULL ;
14 c h a r c o n s t c o n s t m e s s a g e = " H e l l o World ! " ;
15 i n t length = 12; / |<>| /
16
17 / A URI s o l i c i t a d a pode s e r r e c u p e r a d a u s a n d o r e s t _ g e t _ q u e r y ( ) ou u s a n d o um p a r s e r
que r e t o r n a chave v a l o r . /
18 i f ( REST . g e t _ q u e r y _ v a r i a b l e ( r e q u e s t , " l e n " , &l e n ) ) {
19 length = atoi ( len ) ;
20 i f ( l e n g t h <0) l e n g t h = 0 ;
21 i f ( l e n g t h >REST_MAX_CHUNK_SIZE ) l e n g t h = REST_MAX_CHUNK_SIZE ;
22 memcpy ( b u f f e r , message , l e n g t h ) ;
23 } else {
24 memcpy ( b u f f e r , message , l e n g t h ) ;
25 }
26
27 REST . s e t _ h e a d e r _ c o n t e n t _ t y p e ( r e s p o n s e , REST . t y p e . TEXT_PLAIN ) ;
28 REST . s e t _ h e a d e r _ e t a g ( r e s p o n s e , ( u i n t 8 _ t ) &l e n g t h , 1 ) ;
29 REST . s e t _ r e s p o n s e _ p a y l o a d ( r e s p o n s e , b u f f e r , l e n g t h ) ;
30 }
31
32 / I n i c i a l i z a a REST e n g i n e . /
33 rest_init_engine () ;
34
35 / H a b i l i t a o recurso . /
36 r e s t _ a c t i v a t e _ r e s o u r c e (& h e l l o w o r l d ) ;

Na linha 4 declarado um Normal Resource, indicando o nome do recurso, bem

como o mtodo que o recurso aceita (pode aceitar mais de um mtodo), seguidos
da URI e de um texto de descrio.

Na linha 12 declarada a funo que manipula as requisies para a URI do recurso.

O padro [nome do recurso]_handler deve ser mantido. Ao ser invocada,
a funo envia uma mensagem Hello World para o cliente. Alm disso, se o
parmetro len for passado e o valor for menor que o comprimento da string
Hello World, ento a funo retorna somente os caracteres [0:len]. Se o
parmetro contiver valor 0, ento a funo retorna uma string vazia.

Entre as linhas 18 e 25 o processamento da requisio realizado e o buffer de

resposta preenchido adequadamente.

Nas linhas 27 e 29 o cabealho da mensagem de resposta preenchido indicando

respectivamente o tipo da mensagem (TEXT_PLAIN) e o comprimento da mensa-
gem. Finalmente na linha 31 a carga da mensagem preenchida.

Uma vez que o recurso j foi declarado e implementado preciso inicializar o

framework REST e iniciar o processo CoAP, isto realizado na linha 33. Alm
disso, preciso habilitar o recurso para que ele esteja disponvel para o acesso via
URI, isto feito na linha 36.

Este um esboo da implementao de um recurso. recomendvel a leitura dos arquivos

citados, bem como o material extra do minicurso para completo entendimento.

1.4.2.2. CoAP Erbium Contiki

Nesta etapa ser apresentado o uso do Erbium Contiki.

Mude para o seguinte diretrio:
<DIR>+/contiki/examples/er-rest-example/

Neste diretrio existe uma conjunto de arquivos de exemplo do uso do Erbium63 . Por
exemplo, o arquivo er-example-server.c mostra como desenvolver aplicaes REST do
lado servidor. J er-example-client.c mostra como desenvolver um cliente que consulta
um determinado recurso do servidor a cada 10s. Antes de iniciar a prtica conveniente
realizar algumas configuraes. A primeira delas diz respeito aos endereos que sero
utilizados. Deste modo, realize as operaes abaixo:
63 Para mais detalhes sobre os arquivo consulte:
https://github.com/contiki-os/contiki/
tree/master/examples/er-rest-example
 Defina os endereos dos Tmotes no arquivo /etc/hosts
Adicione os seguintes mapeamentos:
aaaa::0212:7401:0001:0101 cooja1
aaaa::0212:7402:0002:0202 cooja2
...

Alm disso, adicione a extenso Copper (CU)64 CoAP user-agent no Mozilla Firefox.
No arquivo er-example-server.c verifique se as macros REST_RES_[HELLO e TOG-
GLE] possuem valor 1 e as demais macros em 0. Em caso negativo, modifique de acordo.
Agora as configuraes preliminares esto prontas.
Na pasta do exemplo Erbium Rest execute o comando abaixo:
make TARGET=cooja server-only.csc

Este comando iniciar uma simulao previamente salva. Esta simulao consta 2 dispo-
sitivos Tmotes, o dispositivo de ID 1 um roteador de borda e o ID 2 emula um dispositivo
executando er-example-server.c como firmeware.
Em um novo terminal execute o comando abaixo:
make connect-router-cooja

Como na primeira prtica (Seo 1.4.1), este comando executar o programa tunslip6
e realizar o mesmo procedimento anteriormente citado. Inicie a simulao, abra o Mo-
zilla Firefox e digite: coap://cooja2:5683/65 .
Como resultado
o Mozilla Firefox de-
ver abrir o ambiente do
Copper. A Figura 1.12
exemplifica a situao
atual. No lado esquerdo
possvel verificar os re-
cursos disponveis pelo
servidor (cooja2). Para
experimentar os recur-
sos providos pelo co-
oja2, selecione o recurso
Figura 1.12. Resultado para coap://cooja2:5683/. hello. Note que a URI
foi alterada, em seguida,
pressione o boto GET do ambiente Copper e observe o resultado. J no recurso tog-
gle pressione o boto POST e observe que o LED RED do cooja2 (no simulador) estar
ligado, repita o processo e verifique novamente o LED.
recomendvel que os leitores alterem os recursos disponveis pelo cooja2 no
arquivo er-example-server.c modificando os recursos ativos no CoAP server conveniente-
mente. Para fazer isto, comente ou descomente os rest_activate_resource()
64 https://addons.mozilla.org/en-US/firefox/addon/copper-270430
65 importante frisar que o CoAP utiliza a porta 5683 como padro.
presentes no cdigo. No material extra do curso, existem outras simulaes e exemplos
de uso. Vale ressaltar, que o mote emulado (Tmote Sky) apresenta limitaes de memria,
como a maioria, dos objetos inteligentes e, por esse motivo, nem sempre todos os recursos
podero est ativos ao mesmo tempo. Em caso de excesso de memria, o simulador ou
compilador para o dispositivo alertar tal problema.
Comentrios no primeiro exerccio foi possvel empregar na prtica os conceitos apren-
didos na sees anteriores. Mostrou-se como funciona uma rede de objetos inteligentes
utilizando os protocolos estado da arte para enderear dispositivos (6LoWPAN) e rotear
mensagens (RPL) atravs de implementaes disponveis no Contiki. Na segunda prtica,
foi mostrado como acessar, de modo padronizado, os recursos dos objetos inteligentes
por meio do protocolo CoAP, o qual emprega REST e URI para identificar unicamente
os recursos disponveis nos objetos inteligentes. No contedo web do captulo66 existem
exemplos para implementao em dispositivos reais.
O contedo terico e prtico visto at o momento elucidaram as bases que susten-
tam o funcionamento da IoT hoje. Os conceitos e prticas visto so importantes para me-
lhor compreenso das prximas sees, pois ser assumido que uma rede de inteligentes
funcional e que os recursos providos pelos dispositivos possam ser acessados utilizando,
por exemplo, o CoAP ou similares.

1.5. Gerenciamento e Anlise de Dados

Uma das principais caractersticas da IoT diz respeito sua capacidade de pro-
porcionar conhecimento sobre o mundo fsico, a partir da grande quantidade de dados
coletados pelos seus sensores. Por meio da minerao destes dados possvel descobrir
padres comportamentais do ambiente ou usurios e realizar inferncias eles. Por exem-
plo, possvel concluir, apartir dos dados obtidos, sobre fenmenos naturais, de modo
a permitir que aplicaes possam antecipar condies meteorolgicas e tomar decises
com base nisso. Obviamente, os maiores beneficiados com isto so os prprios usurios,
que tero melhorias na qualidade de suas vidas.
Contudo, para poder-se extrair todo o potencial contido nos dados da IoT neces-
srio que, primeiro, algumas medidas sejam tomadas. Nesta seo destacamos as princi-
pais caractersticas e desafios encontrados ao se lidar com dados oriundos destes sensores.
Alm disso, apresentamos algumas das principais tcnicas utilizadas para modelagem e
processamento destes dados, at a extrao de conhecimento, para melhoria da qualidade
dos servios em cenrios nos quais a IoT empregada. Por fim, apontamos possveis
direcionamentos para aqueles que desejarem se aprofundar mais no assunto.

1.5.1. Descrio do Problema

Do ponto de vista dos usurios e suas aplicaes, a raison dtre (razo de
ser) da IoT , justamente, a extrao de conhecimento a partir dos dados coletados pe-
los seus sensores. Extrair um conhecimento refere-se a modelar e analisar dados de-
finindo uma semntica de forma a tomar decises adequadas para prover um determi-
nado servio [Barnaghi et al. 2012]. Tomando como exemplo o cenrio de smart grids

66 http://homepages.dcc.ufmg.br/~bruno.ps/iot-tp-sbrc-2016/
[Yan et al. 2013], uma arquitetura de IoT pode auxiliar a controlar e melhorar o servio
de consumo de energia em casas e edifcios. Por meio da IoT, as fornecedoras de energia
podem controlar os recursos proporcionalmente ao consumo e possveis falhas na rede
eltrica. Isso acontece por meio das diversas leituras que so coletadas por objetos inte-
ligentes e so analisadas para preveno e recuperao de falhas, aumentando, assim, a
eficincia e qualidade dos servios.

(a) Representao da sequncia ideal.

(b) Representao da sequncia na prtica.

Figura 1.13. Etapas para extrao de conhecimento a partir de da-
dos de sensores.

Para melhor entender o processo de extrao de conhecimento, na Figura 1.13a

so apresentadas as etapas ideais, que vo desde a coleta dos dados brutos at a extrao
de conhecimento a partir deles. As etapas de adequao dos dados a um modelo, de
pr-processamento e armazenamento so essenciais para que eles estejam aptos a serem
processados e para que tcnicas de inferncias possam ser aplicadas sobre eles.
Do ponto de vista do conhecimento em si, uma outra abordagem que pode-se apli-
car sobre este processo est ilustrada na Figura 1.14. Nela, a transformao da informao
a partir de dados brutos de sensores pode ser entendida por meio de uma hierarquia de
nveis de conhecimento. Estes nveis podem ser sub-divididos em dois momentos: (i) mo-
delagem e (ii) anlise e inferncia. Na modelagem, cujo principal objetivo o de adicionar
semntica aos dados, depara-se com um grande volume de dados oriundos de diversos ti-
pos de sensores. Uma particularidade desafiadora para manipular esses dados o fato de
serem originados de mltiplas fontes e, em muitos casos, heterogneas. Nesse sentido,
algumas tcnicas de pr-processamento, como fuso e representao de dados, podem
ser adotadas, aps isso, os dados so armazenados em uma representao adequada. O
segundo momento consiste em interpretar tais dados visando obter contexto a partir deles
e, com isso, realizar inferncias para se extrair conhecimento quanto situao de um
determinado aspecto, seja ele um fenmeno natural ou estado de uma entidade.
Contudo, apesar de cada uma destas etapas ser de fundamental importncia para
o processo de extrao de conhecimento como um todo, na prtica no bem isso o
que acontece. Como ilustrado na Figura 1.13b, o que geralmente acontece a ausncia
 Figura 1.14. Hierarquia dos nveis de conhecimento a partir de da-
dos brutos de sensores.

da etapa de pr-processamento dos dados antes que eles sejam armazenados. Os dados
coletados dos sensores so simplesmente armazenados para posterior utilizao, o que
pode comprometer todas as inferncias subsequentes. Assim, uma vez de posse dos dados
armazenados, o que podemos fazer realizar as atividades de pr-processamento em uma
etapa adicional, antes que os dados sejam utilizados para a extrao de conhecimento.
Considerando o cenrio representado pelo que ocorre na prtica, no restante desta
seo aprofundamos nossas consideraes sobre cada uma destas etapas.

1.5.2. Modelagem de dados

Dados brutos obtidos pelos sensores dificilmente possuem explicitamente uma or-
ganizao hierrquica, relacionamentos ou mesmo um formato padro para manipulao.
Esta etapa de modelagem refere-se em definir uma representao para manipular e traba-
lhar com esses dados visando uma interoperabilidade e formatos padres interpretveis.
Nesse sentido, aplica-se a modelagem que consiste em definir um conjunto de fatores tais
como atributos, caractersticas e relaes do conjunto de dados sensoriados. Tais fatores
variam de acordo com o domnio da aplicao e consequentemente uma determinada so-
luo de modelagem se torna mais adequada que outra. A modelagem aqui empregada
consiste em representaes conceituais de como representar a informao. As represen-
taes apresentadas so: key-value, markup scheme, graphical, object based, logic based
e ontology based modeling. A aplicabilidade dessas representaes pode variar de acordo
com o domnio da aplicao. Portanto, cada representao descrita abaixo considerando
suas vantagens e desvantagens em uma perspectiva geral. Um estudo mais aprofundado
pode ser encontrado em [Bettini et al. 2010].

Key-value based: nesta representao os dados so modelados como um conjunto

de chaves e valores em arquivos de texto. Apesar dessa ser a forma mais simples
de representao da informao entre as apresentadas aqui, possui muitas desvan-
tagens como a complexidade de organizar e recuperar quando o volume de dados
 aumenta, alm da dificuldade de realizar relacionamentos entre os dados.

Markup scheme based: um markup scheme utiliza tags para modelar os dados. Lin-
guagens de marcao (e.g., XML67 ) e mecanismos de troca de dados (e.g, JSON68 )
podem ser utilizados para este fim e so bastante aplicados para armazenamento e
transferncia de dados. A vantagem dessa tcnica consiste na estruturao hierr-
quica dos dados e acesso aos dados utilizando as tags. Recentemente, o W3C ado-
tou o EXI 69 o qual consiste de uma representao compacta do XML. EXI pode
ser uma relevante alternativa ao XML para IoT, pois adequado para aplicaes
com recursos computacionais limitados. A SensorML70 (Sensor Model Language)
prov uma especificao exclusiva para sensores considerando diversos aspectos
como localizao e metadados.

Object based: esta tcnica permite a construo de uma modelagem considerando

o relacionamento e a hierarquia entre os dados. Um Markup scheme apresenta li-
mitaes no sentido que as tags so palavras chaves de um domnio e no fornecem
uma semntica para a interpretao pela mquina. Tcnicas de modelagem como
UML (Unified Modelling Language) e ORM (Object Role Modelling) so prefer-
veis Markup scheme, pois permitem capturar relacionamentos em um contexto.
Esse tipo de modelagem pode ser facilmente vinculada a uma linguagem de pro-
psito geral e, consequentemente, integrvel sistemas de inferncia e cientes de
contexto. No entanto, no tem a mesma predisposio para realizar inferncia das
representaes baseadas em lgica e ontologia.

Logic based: neste tipo de modelagem expresses lgicas e regras so usadas para
representar a informao. A representao lgica mais expressiva que as anteri-
ores do ponto de vista que possibilita a gerao de novas informaes a partir dos
dados. Dessa forma, a partir de informaes de baixo nvel pode-se ter regras para
compor informaes de alto nvel. A desvantagem dessa representao a dificul-
dade em generalizao das regras, dificultando a reusabilidade e aplicabilidade.

Ontology based: nesta forma de representao as informaes so modeladas como

ontologia seguindo os conceitos da Semantic Web. Uma ontologia define um con-
junto de tipos, propriedades e relacionamentos de entidades dentro de um tema
considerando aspectos espaciais e temporais [Jakus et al. 2013]. Para a rea de sen-
sores e IoT, surgiu a Sensor Semantic Web que refere-se a aplicar o conhecimento
da Web Semntica contemplando o domnio de sensores. Dessa forma, tecnologias
consolidadas podem ser utilizadas, tais como RDF e OWL, para modelar o conhe-
cimento de domnio e estruturar as relaes definidas na ontologia. A desvantagem
da representao baseada em ontologia concentra-se no consumo de recursos com-
putacionais.
67 https://www.w3.org/XML/
68 https://tools.ietf.org/html/rfc4627
69 https://www.w3.org/TR/exi/
70 http://www.sensorml.com/index.html
1.5.3. Armazenamento
Para que a grande quantidade de dados gerados pelos sensores da IoT possa ser
posteriormente analisada e processada, a etapa de armazenamento faz-se essencial. Como
apresentado na Figura 1.6(III), uma das principais formas de acesso a estes dados, e a mais
comumente encontrada na prtica, acontece por meio de servidores de armazenamento.
Muitos destes esto disponveis sob a forma de plataformas computacionais especifica-
mente voltadas para prover servios para a IoT. Na Tabela 1.4 apresentamos algumas
plataformas para IoT atualmente disponveis, destacando algumas das suas principais ca-
ractersticas.
A maioria destas plataformas baseiam suas funcionalidades de acordo com os mo-
delos de dados definidos, assim, logo aps coletados, os dados quando adequados ao
modelo sero armazenados de forma a possibilitar sua consulta subsequente. Porm, ao
contrrio do que foi discutido quanto os aspectos de modelagem mais adequados ao do-
mnio de aplicao, o que geralmente ocorre, na prtica, a utilizao de um modelo mais
simples e genrico possvel, que se adeque ao mais variado nmero de aplicaes. Neste
caso, os modelos que se encontram nas principais plataformas so baseados em key-value
e markup scheme. Estes modelos so utilizados para que os usurios possam dar semn-
tica aos seus dados, descrevendo coisas como os tipos dos dados, formatos, etc. Alm
disso, algumas outras meta informaes tambm podem ser providas, como a localiza-
o dos sensores, uma descrio textual do que o sensor representa e algumas tags que
podero ser usadas como palavras-chave para consultas.
Alm do armazenamento, algumas plataformas tambm disponibilizam outros ser-
vios, como a marcao de tempo (timestamp) de todos os dados recebidos, algumas fun-
cionalidades de processamento, que geralmente so pr-definidos e acessados sob a forma
de wizards ou dashboards, definio de regras para a execuo de atividades com base em
eventos ou comportamento dos dados, entre outros. Para mais detalhes sobre o projeto e
implementao de plataformas para IoT, ver o trabalho de [Paulo F. Pires 2015].

1.5.4. Pr-processamento
Para que os dados possam ser processados adequadamente eles devem possuir
certa qualidade, que seja suficiente para os processos a serem empregados. Apesar de
ser difcil de se conceituar, uma forma simples de entender a qualidade aqui discutida se
refere aos dados que esto aptos ao uso [Bisdikian et al. 2013]. Nesse sentido, um passo
fundamental para contornar possveis problemas existentes nos dados coletados, de forma
a torn-los aptos ao uso, a de pr-processamento. Contudo, como visto na Figura 1.13b,
apesar de sua importncia, esta etapa de pr-processamento muitas vezes inexistente,
sendo os dados armazenados com suas imperfeies. Assim, diante do exposto, uma
alternativa que se tem a insero desta etapa de pr-processamento logo antes dos dados
serem utilizados para a extrao de conhecimento.
A seguir sero discutidos alguns dos principais problemas que ocorrem no dados
da IoT e algumas tcnicas comumente utilizadas para reduzir seu impacto durante a etapa
de extrao de conhecimento.
Plataforma Endereo Descrio Tipo de conta
AWS IoT aws.amazon.com/iot Plataforma da Amazon voltada para empre- Possui conta gratuita, mas pede car-
sas. to de crdito para confirmar.
Arrayent arrayent.com Plataforma com foco empresarial. No disponibiliza conta gratuita.
Axeda axeda.com Plataforma com foco empresarial. Prov ser- No disponibiliza conta gratuita.
vios de gerenciamento e comunicao entre
dispositivos.
Beebotte beebotte.com Plataforma com interessantes recursos, in- Possui conta gratuita, mas com li-
cluindo a possibilidade de criao de dispo- mite de 3 meses de histrico.
sitivos pblicos.
BugLabs dweet.io Permite publish-subscribe para disponibili- Possui conta gratuita, mas os dados
zao dos dados e integrao entre sensores. so apagados aps 24h.
Carriots carriots.com Plataforma com foco empresarial. Prov ser- Possui conta gratuita, mas com v-
vios de gerenciamento de e comunicao rias limitaes, e.g., nmero de dis-
entre dispositivos positivos e acessos.
Electric imp electricimp.com Plataforma em nuvem que integra o conjunto Possui conta gratuita.
de solues dos dispositivos electric imp.
Evrythng evrythng.com Plataforma com foco empresarial. Permite Disponibiliza conta gratuita para
publish/subscribe para disponibilizao dos desenvolvedor.
dados de sensores.
Exosite exosite.com Plataforma com foco empresarial. Possui conta gratuita, mas limitada.
Flowthings flowthings.io Plataforma com interessantes conceitos para Possui conta gratuita para desenvol-
a integrao de sensores. vedor.
IBM Bluemix bluemix.net Plataforma da IBM com foco empresarial. Possui conta gratuita, mas pede car-
to de crdito para confirmar.
Kaa kaaproject.org Middleware open source disponvel para a Gratuita.
criao de sua prpria plataforma para IoT.
Lelylan lelylan.com Projeto open source com interessantes con- Gratuita.
ceitos de arquitetura que pode ser utilizado
para a criao de sua prpria plataforma.
Linkafy linkafy.com Plataforma voltada para o controle de dispo- Possui conta gratuita, mas limitada
sitivos residenciais. a apenas dispositivo.
mbed mbed.com Plataforma que integra o conjunto de solu- Possui conta gratuita, com limita-
es que suportam os dispositivos mbed da es.
ARM.
Microsoft Azure IoT microsoft.com/iot Plataforma da Microsoft voltada a IoT com Possui conta gratuita de um ms
foco empresarial. para testes.
Open.sen.se open.sen.se Plataforma interessante para integrao dos Conta apenas aps requisio.
sensores e seus dados.
OpenSensors opensensors.io Plataforma robusta com o foco principal para Conta gratuita disponvel, paga-se
sensores abertos. Permite publish-subscribe apenas para ter sensores privados.
para disponibilizao dos dados de sensores.
PubNub pubnub.com Plataforma robusta com diversas funcionali- Possui conta gratuita com limita-
dades voltadas para IoT. es.
SensorCloud sensorcloud.com Plataforma com foco empresarial. Possui conta gratuita, mas limitada.
SensorFlare sensorflare.com Plataforma para integrao de sensores, mas Possui conta gratuita.
apenas suporta alguns fabricantes e modelos.
Sentilo sentilo.io Projeto gratuito e disponvel para a criao Gratuita.
de sua prpria plataforma. Voltada s arqui-
teturas de smart cities.
Shiftr shiftr.io Interessantes conceitos para a integrao de Possui conta gratuita.
sensores de forma intuitiva.
ThingPlus thingplus.net Plataforma sul koreana com o foco interes- Possui conta gratuita, mas limitada.
sante sistema de definio de regras para in-
tegrao entre sensores.
ThingSquare thingsquare.com Plataforma voltada ao controle de dispositi- Possui conta de desenvolvedor gra-
vos e integrao via celular. tuita.
ThingSpeak thingspeak.com Plataforma robusta, com vrias funcionalida- Conta gratuita disponvel.
des, como sensores pblicos e busca por his-
trico.
ThingWorx thingworx.com Plataforma com recursos interessantes, mas Conta gratuita, mas com limitaes.
mais voltada a solues empresariais.
Xively xively.com Plataforma robusta, disponibiliza vrias fun- Foco empresarial, com conta paga
cionalidades como busca por sensores pbli- disponvel e gratuita apenas via so-
cos e histrico. licitao.

Tabela 1.4. Algumas das principais plataformas para IoT.

1.5.4.1. Principais problemas dos dados

Para melhor compreendimento dos principais problemas que podem ocorrer nos
dados provenientes dos sensores de IoT, [Khaleghi et al. 2013] definem uma taxonomia
de classificao partindo de problemas bsicos relativos aos aspectos dos dados, nos quais
os principais so descritos abaixo.

Imperfeio: refere-se aos efeitos causados por alguma impreciso ou incerteza

nas medidas capturadas pelos sensores. As causas destes problemas podem ser
vrias, desde a problemas nas leituras devido a falhas de hardware ou calibragem
dos sensores, at a fatores externos ao sensor, como do seu posicionamento em
locais que adicionam rudos s suas leituras.

Inconsistncia: surge principalmente dos seguintes problemas: (i) dados fora de

sequncia, isto , em que a ordem em que foram armazenados ou temporalmente
demarcados difere da real ordem de ocorrncia no mundo fsico, (ii) presena de ou-
tliers nos dados, observaes que esto bem distantes das demais observaes rea-
lizadas, causadas por alguma situao inesperada, e (iii) dados conflitantes, quando
diferentes sensores medindo um mesmo fenmeno geram dados diferentes, agre-
gando uma dvida sobre qual sensor seria mais confivel.

Discrepncia: este um problema causado, principalmente, quando diferentes ti-

pos de sensores so utilizados para coletar dados sobre um mesmo fenmeno. Por
exemplo, sensores fsicos coletando informaes sobre o trfego, comparados com
cmeras de monitoramento, ou ainda, sensores sociais, que coletam informaes
dadas por usurios em seus aplicativos mveis [Silva et al. 2014].

Alm destes problemas, tambm podemos destacar outros problemas dos dados,
principalmente no cenrio atual da IoT, onde usurios comuns tambm esto participando
de forma colaborativa da gerao destes dados [Borges Neto et al. 2015]. Devido popu-
larizao e reduo dos custos dos sistemas computacionais embarcados, muitos usurios
esto criando seus prprios sensores, seguindo um modelo DIY (Do It Yourself ). Neste
cenrio, eles so responsveis pela implantao, coleta e distribuio dos dados dos senso-
res, geralmente tornando-os pblicos atravs das principais plataformas de IoT. Contudo,
por se tratarem de sensores particulares, no h nenhuma garantia quanto qualidade
dos dados gerados, nem mesmo da disponibilidade dos sensores.
Assim, alguns problemas que podem surgir neste novo cenrio so: (i) ausncia
de descrio dos dados gerados, quando os usurios submetem os dados coletados pelos
seus sensores para uma plataforma sem descrever de que se trata o dado, dificultando qual-
quer posterior utilizao deste dado por outros usurios, (ii) disponibilidade dos sensores,
quando os sensores param de funcionar, temporria ou permanentemente, sem mais deta-
lhes se voltaram a operar ou no, geralmente de acordo com as necessidades dos prprios
usurios, (iii) impreciso das leituras causadas pelo baixo custo e qualidade dos sensores
caseiros, geralmente utilizando-se de tcnicas alternativas para medir um fenmeno, as
leituras destes sensores dos usurios podem diferir em magnitude dos dados coletados por
sensores mais profissionais quanto a um mesmo fenmeno.
 Para exemplificar isto, a Figura 1.15 apresenta duas medies distintas para um
mesmo fenmeno, a velocidade do vento, na regio da Espanha, realizadas por um sen-
sor pblico, disponibilizado por um usurio atravs da plataforma ThingSpeak71 e pelo
servio meteorolgico do Weather Underground72 , no perodo entre 12 de setembro a 31
de outubro de 2015. Observa-se que embora bem relacionadas, com um coeficiente de
correlao equivalente a 0.915 entre eles, suas magnitudes so diferentes. Alm disso,
tambm pode-se notar a incompletude destes dados, quando h lacunas devido falta de
dados coletados pelos sensores.

4
Velocidade Vento (km/h)

Sep 12 Sep 19 Sep 26 Oct 03 Oct 10 Oct 17 Oct 24 Oct 31

Data

Sensor Pblico Weather Underground

Figura 1.15. Velocidade do Vento (km/h) coletada na regio de Ma-

dri, Espanha, medida por um sensor pblico, disponvel na plata-
forma ThingSpeak (linha tracejada) e pelo servio meteorolgico
do Weather Underground (linha slida).

1.5.4.2. Principais tcnicas de pr-processamento

O pr-processamento consiste na aplicao de tcnicas, em sua maioria estatsticas

e demais operaes matemticas, sobre os dados com o intuito melhorar a sua qualidade,
contornando possveis problemas existentes e removendo imperfeies. A complexidade
desta etapa pode ser alta, principalmente neste cenrio em questo, quando os dados so
heterogneos, oriundos de diversas fontes e com diferentes problemas. Nesse sentido, a
deciso sobre qual tcnica aplicar varia de acordo com o problema encontrado nos dados
e, alm disso, do que se espera fazer com estes dados. Assim, a seguir ser apresen-
tada uma viso geral sobre algumas das tcnicas comumente utilizadas para alguns dos
problemas citados, e apontamos algumas referncias, para que leitores mais interessados
possam se aprofundar no assunto.
71 https://thingspeak.com
72 https://www.wunderground.com
 Imprecises e outliers: A presena de imprecises e outliers em dados um pro-
blema muito comum em diversas reas e um ponto bastante estudado pela comu-
nidade cientfica. As solues mais comumente utilizadas para contornar estes
problemas so baseadas em tcnicas de suavizao dos dados. Por exemplo, (i)
a utilizao de mdias mveis (moving average), onde as amostras so suaviza-
das por meio da mdia de amostras vizinhas, e (ii) de interpolao (polinomial ou
splines), onde so definidas funes, e.g., polinomiais, que melhor se ajustam s
amostras contidas nos dados. Com isto, possvel diminuir o efeito dos rudos
causados pelas imperfeies nos dados. Para mais detalhes, uma consulta pode ser
[Morettin and Toloi 2006].

Lacunas nos dados: O caso de lacunas nos dados acontece por fatores diversos e
que podem causar diferentes nveis de prejuzo em sua extrao de conhecimento.
Um caso mais simples seria a lacuna causada por uma falha espordica na operao
dos sensores, por razes no associadas ao fenmeno monitorado, causando uma
lacuna aleatria ou MAR (missing at random). Este tipo de falha pode ser contor-
nada de forma mais fcil, por exemplo, por meio de interpolao para completar os
dados faltantes. Mas, dependendo da forma como isso acontece, podem ser inseri-
dos lacunas de forma sistemticas nos dados, prejudicando a sua posterior anlise.
Por exemplo, um sensor que pra de coletar dados quando a temperatura atinge cer-
tos nveis de valores, ou quando um usurio desliga o sensor noite quando deixa
o escritrio. Este tipo de lacunas que no so geradas aleatoriamente, ou MNAR
(missing not at random) so mais problemticas para o seu processamento. Outras
tcnicas tambm podem ser aplicadas, desde a simples remoo do perodo con-
tendo lacunas at a imputao dos dados faltantes por meio da estimativa a partir
dos demais dados existentes. Mais detalhes em [Schafer and Graham 2002].

Diferena de granularidade: Devido grade quantidade de sensores heterogneos,

um problema relevante que surge diz respeito s diferenas de amostragem que cada
sensor possui. Isso pode causar diferenas significativas na granularidade dos dados
de diferentes sensores. Por exemplo, para um mesmo fenmeno em um mesmo
intervalo de tempo, podemos ter um sensor coletando dados a cada 5 segundos e
outro a cada 1 minuto. Para que seja possvel combinar os dados destes sensores,
um primeiro pr-processamento seria igualar a quantidade de amostras de cada um
deles. Para isto, algumas tcnicas podem ser utilizadas e, uma simples mas eficaz
a PAA (Piecewise Aggregate Approximation), que empregada pelo algoritmo de
clusterizao SAX (Symbolic Aggregate approXimation) [Lin et al. 2003], para a
reduo da dimenso do conjunto de dados por meio da agregao de dados, similar
ao que feito com mdias mveis. Assim, pode-se transformar os dados de forma
a possurem a mesma dimenso. Ainda sobre a reduo de dimenso, esta uma
tcnica bem vlida para o cenrio de IoT, pois espera-se uma grande quantidade
de dados sendo gerados. Outras estratgias tambm podem ser adotadas, como
a transformao via wavelets ou Fourier, mais detalhes em [Rani and Sikka 2012,
Warren Liao 2005].

Combinao de diversas fontes: Para a combinao de dados de diversas fontes,

como o caso da IoT, tcnicas de fuso de dados podem ser aplicadas de forma
 a compor uma nica representao destes dados. Fuso de dados o mtodo de
combinar dados de diversos sensores para produzir uma semntica mais precisa e
muitas vezes invivel de ser obtida a partir de um nico sensor. A utilizao de fu-
so de dados nesta etapa de pr-processamento tem o intuito principal de cobrir os
problemas dos dados de um sensor atravs dos dados coletados por outros sensores
similares, gerando assim um novo dado combinado mais preciso. Dessa forma, so
aplicados mtodos automticos ou semiautomticos para transformar dados de dife-
rentes fontes em uma representao que seja significativa para a tomada de deciso
e inferncia. Em cenrios de IoT nos quais existem milhares de sensores a fuso
de dados uma poderosa ferramenta tanto processo de extrao de conhecimento
quanto para reduzir recursos computacionais semelhante ao que ocorre em redes de
sensores sem fio. Vrias tcnicas de fuso podem ser aplicadas, como, por exem-
plo, filtros de Kalman [Khaleghi et al. 2013]. Outra tcnicas muito utilizadas para
a combinao de sensores distintos se baseiam na clusterizao de dados similares,
com base em alguma mtrica de distncia, mas mais detalhes sobre isso algumas
tcnicas de clusterizao vide [Rani and Sikka 2012, Warren Liao 2005].

1.5.5. Extrao de conhecimento

Como visto na Figura 1.14 a modelagem consiste em explorar os dados brutos para
estrutur-los em uma especfica representao. Aumentando o nvel de abstrao na hie-
rarquia, contexto refere-se a qualquer informao que pode ser utilizada para caracterizar
a situao de uma entidade. Sendo essa entidade um objeto, lugar ou pessoa que con-
siderada relevante para interao entre um usurio e uma aplicao, incluindo o usurio
e a prpria aplicao [Dey 2001]. Enquanto que uma situao representa a interpretao
semntica de contextos, geralmente derivado pela combinao de diversas informaes
contextuais, proporcionando conhecimento sobre o mundo fsico [Dobson and Ye 2006].
Particularmente, a etapa de anlise e inferncia busca definir o contexto e a situao a
partir dos dados coletados por sensores.
Para exemplificar um cenrio, Bettini [Bettini et al. 2010] especifica uma situao
reunio est ocorrendo considerando as seguintes informaes contextuais: localizao
de vrias pessoas e agenda de atividades delas, informao de sensores nos pisos, quais
os dispositivos ativos na sala, o som ambiente e as imagens de cmeras. Ao longo do
tempo essas informaes contextuais vo se alterando, mas a situao ainda a mesma.
Alm disso, outras informaes contextuais podero ser incorporadas, enquanto essas
utilizadas podem se tornar obsoletas. Dessa forma, o objetivo da inferncia refere-se a es-
tratgia de extrair um conhecimento (i.e., semntica de uma situao) baseado nos dados
coletados. Esta etapa relacionada com a etapa de modelagem, pois algumas tcnicas
de modelagem so preferveis de serem utilizadas com determinado tipo de tcnica de
inferncia. A seguir, so apresentadas algumas categorias de tcnicas teis para infern-
cia de situaes. Uma reviso mais abrangente sobre tais tcnicas pode ser encontrada
em [Bettini et al. 2010, Perera et al. 2014].

Aprendizagem Supervisionada: Nesse tipo de tcnica, uma primeira coleo de

dados coletada para compor o conjunto de treinamento. Para tanto, esse dados
 devem ser rotulados em classes especficas [Mitchell 1997] [Bishop 2006]. Em se-
guida, cria-se um modelo (ou funo) que aprende a classificar dados de acordo
com os dados que foram utilizados na etapa de treinamento. As rvores de deciso,
redes neurais artificiais baseadas neste tipo de aprendizado e mquinas de vetores
de suporte so exemplos de tcnicas de aprendizagem supervisionada. Dois fato-
res importantes so a seleo de caractersticas significativas e uma considervel
quantidade de dados para classificao.

Aprendizagem no supervisionada: Nesta categoria de tcnicas, no existe nenhum

conhecimento a priori sobre que padres ocorrem nos dados e o objetivo encon-
trar um modelo (ou funo) que descubra padres implcitos em um conjunto de
dados no rotulados [Mitchell 1997] [Bishop 2006]. Dessa forma, difcil uma
confivel validao dos resultados obtidos e os resultados geralmente no so pre-
visveis. Exemplos clssicos desta categoria so as tcnicas de clusterizao tais
como K-Means e clusterizao hierrquica que agrupam os elementos se baseando
em mtricas de similaridade entre eles.

Regras: Este tipo de tcnica consiste em definir regras condicionais. Apesar de ser
a forma mais simples de inferncia, ela apresenta dificuldades de generalizao e
pouca extensibilidade para diferentes aplicaes.

Ontologias: Nessa categoria, ontologias podem ser utilizadas tanto na modelagem

como para a inferncia [Min et al. 2011]. Assim, j se tem a vantagem de modelar
um conhecimento sabendo o domnio da aplicao e o mapeamento das possibilida-
des de inferncia. No entanto, apresenta a desvantagem de no tratar ambiguidades
ou resultados inesperados. Essas desvantagens podem ser contornadas fazendo a
combinao com regras.

Lgica probabilstica: Tambm conhecida como inferncia probabilstica refere-se

a utilizar a teoria de probabilidade para lidar com as incertezas existentes em um
processo dedutivo [Murphy 2012]. Ao contrrio das ontologias, esta categoria de
tcnicas pode lidar com ambiguidades considerando as probabilidades associadas
para realizar a inferncia. A desvantagem consiste em descobrir tais probabilidades.
Hidden Markov Models (HMM) um exemplo clssico e tem sido aplicado em
cenrios de reconhecimento de atividades de pessoas.

1.6. IoT como o meio para a Computao Ubqua e pervasiva LOUREIRO

(MAX 1 PG)
Definio de entidades

Diferentes tipos
Diferentes contextos (Fsico e Lgicos)

Aquisio de contexto atravs dos dados dos dispositivos inteligentes

Elementos para monitoramento (sensores)

 O papel da Cloud Computing

Exemplos de Aplicaes (Automao residencial, Smart Cities, Urban Networks,

Monitoramento de Sade)

1.7. Consideraes Finais

No decorrer do captulo, o leitor foi apresentado a diversos pontos da Internet
das Coisas, passando por questes tanto tericas quanto prticas da IoT. Por ser uma
rea extensa, ainda existem contedos que no foram discutidos ao longo do texto e, por
esse motivo, alguns desses assuntos sero brevemente referenciados aqui e no contedo
online73 como leitura complementar.
A IoT, neste momento, passa por questes que dizem respeito a sua forma, pro-
prietrios e regulamentaes. Neste sentido, os prximos anos sero fundamentais para
as definies e padronizaes das tecnolgicas para IoT. Neste sentido, empresas como
Google, Apple e outras esto lanando seus prprios ecossistemas IoT, respectivamente
Google Weave e Apple HomeKit. Entretanto, cada um possui protocolos, tecnologias
de comunicao e padres particulares. Isto torna a IoT no padronizada e consequente-
mente um ecossistema onde a IoT pode no prosperar. Assim, preciso que a comunidade
acadmica e empresarial atentem-se s padronizaes e na construo de um ecossistema
favorvel IoT. Com isto ser possvel tornar os dispositivos Plug & Play e tornar a IoT
livre de padres proprietrios. Em [Ishaq et al. 2013], os autores realizam uma reviso
geral das padronizaes em IoT.
Outra questo altamente relevante a segurana para IoT. Este ponto, uma das
principais barreiras que impedem a efetiva adoo da IoT, pois os usurios esto preocu-
pados com a violao dos seus dados. Deste modo, a segurana desempenha papel chave
para a adoo da IoT. O escritor Dominique Guinard resume, em seu artigo sobre polticas
para IoT74 , que A segurana dos objetos inteligentes to forte quanto seu enlace mais
fraco, isto , as solues de segurana ainda no esto consolidadas, portanto solues
devem ser propostas e discutidas detalhadamente.
Neste trabalho foram descritos alguns dos princpios bsicos da IoT atravs de
uma abordagem terico e prtica. O aspecto dos objetos inteligentes e as tecnologias
de comunicao foram abordados primeiramente. De forma complementar, discutiu-se
sobre os software que orquestram o funcionamento da IoT. Foram realizadas duas ativida-
des prticas para consolidar o contedo. Tambm apresentou-se o modo como gerenciar
e analisar dados oriundos de dispositivos inteligentes, destacando as principais tcnicas
utilizadas. Alm disso, apresentou-se uma perspectiva futura da IoT, como um meio para
alcanar a computao ubqua.

Referncias
[Al-Fuqaha et al. 2015] Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M., and Ayyash,
M. (2015). Internet of things: A survey on enabling technologies, protocols, and applications.
Communications Surveys & Tutorials, IEEE, 17(4):23472376.
73 http://homepages.dcc.ufmg.br/~bruno.ps/iot-tp-sbrc-2016/
74 http://techcrunch.com/2016/02/25/the-politics-of-the-internet-of-things/
[Alliance 2015] Alliance, W.-F. (2015). Who we are.

[Angell et al. 1983] Angell, J. B., Barth, P. W., and Terry, S. C. (1983). Silicon micromechanical
devices. Scientific American, 248:4455.

[Ashton 2009] Ashton, K. (2009). That internet of things thing. RFiD Journal, 22(7):97114.

[Bagula and Erasmus 2015] Bagula, B. and Erasmus, Z. (2015). Iot emulation with cooja. ICTP-
IoT Workshop.

[Barnaghi et al. 2012] Barnaghi, P., Wang, W., Henson, C., and Taylor, K. (2012). Semantics
for the Internet of Things. International Journal on Semantic Web and Information Systems,
8(1):121.

[Bettini et al. 2010] Bettini, C., Brdiczka, O., Henricksen, K., Indulska, J., Nicklas, D., Ranga-
nathan, A., and Riboni, D. (2010). A survey of context modelling and reasoning techniques.
Pervasive and Mobile Computing, 6(2):161180.

[Bisdikian et al. 2013] Bisdikian, C., Kaplan, L. M., and Srivastava, M. B. (2013). On the quality
and value of information in sensor networks. ACM Transactions on Sensor Networks, 9(4):1
26.

[Bishop 2006] Bishop, C. M. (2006). Pattern Recognition and Machine Learning (Information
Science and Statistics). Springer-Verlag New York, Inc., Secaucus, NJ, USA.

[Borges Neto et al. 2015] Borges Neto, J. B., Silva, T. H., Assuno, R. M., Mini, R. A. F., and
Loureiro, A. A. F. (2015). Sensing in the Collaborative Internet of Things. Sensors, 15(3):6607
6632.

[Boulis et al. 2011] Boulis, A. et al. (2011). Castalia: A simulator for wireless sensor networks
and body area networks. NICTA: National ICT Australia.

[Chaouchi 2013] Chaouchi, H. (2013). The internet of things: connecting objects. John Wiley &
Sons.

[Chlipala et al. 2004] Chlipala, A., Hui, J., and Tolle, G. (2004). Deluge: data dissemination for
network reprogramming at scale. University of California, Berkeley, Tech. Rep.

[Clausen et al. 2013] Clausen, T., Yi, J., Herberg, U., and Igarashi, Y. (2013). Observations of rpl:
Ipv6 routing protocol for low power and lossy networks. draft-clausen-lln-rpl-experiences-05.

[Cordero et al. 2013] Cordero, J. A., Yi, J., Clausen, T. H., and Baccelli, E. (2013). Enabling
Multihop Communication in Spontaneous Wireless Networks. In H. Haddadi, O. B., editor,
Recent Advances in Networking, volume 1 of ACM SIGCOMM eBook. ACM.

[Da Xu et al. 2014] Da Xu, L., He, W., and Li, S. (2014). Internet of Things in industries: A
survey. Industrial Informatics, IEEE Transactions on, 10(4):22332243.

[Dey 2001] Dey, A. K. (2001). Understanding and using context. Personal and ubiquitous com-
puting, 5(1):47.

[Dobson and Ye 2006] Dobson, S. and Ye, J. (2006). Using fibrations for situation identification.
In Pervasive 2006 workshop proceedings, pages 645651.
[Doddavenkatappa et al. 2012] Doddavenkatappa, M., Chan, M. C., and Ananda, A. L. (2012).
Testbeds and Research Infrastructure. Development of Networks and Communities: 7th In-
ternational ICST Conference,TridentCom 2011, Shanghai, China, April 17-19, 2011, Revised
Selected Papers, chapter Indriya: A Low-Cost, 3D Wireless Sensor Network Testbed, pages
302316. Springer Berlin Heidelberg, Berlin, Heidelberg.
[Dunkels et al. 2004] Dunkels, A., Gronvall, B., and Voigt, T. (2004). Contiki - a lightweight and
flexible operating system for tiny networked sensors. In Proceedings of the 29th Annual IEEE
International Conference on Local Computer Networks, LCN 04, pages 455462, Washington,
DC, USA. IEEE Computer Society.
[Fasolo et al. 2007] Fasolo, E., Rossi, M., Widmer, J., and Zorzi, M. (2007). In-network aggre-
gation techniques for wireless sensor networks: a survey. Wireless Communications, IEEE,
14(2):7087.
[Forbes 2014] Forbes (2014). Internet of Things By The Numbers: Market Estimates And Fore-
casts.
[Gartner 2015] Gartner, I. (2015). Gartners 2015 Hype Cycle for Emerging Technologies Iden-
tifies the Computing Innovations That Organizations Should Monitor.
[Gnawali et al. 2009] Gnawali, O., Fonseca, R., Jamieson, K., Moss, D., and Levis, P. (2009).
Collection Tree Protocol. In Proceedings of the 7th ACM Conference on Embedded Networked
Sensor Systems.
[Goldstein et al. 2005] Goldstein, S. C., Campbell, J. D., and Mowry, T. C. (2005). Programmable
matter. Computer, 38(6):99101.
[Hui 2012] Hui, J. W. (2012). The routing protocol for low-power and lossy networks (rpl) option
for carrying rpl information in data-plane datagrams.
[Ishaq et al. 2013] Ishaq, I., Carels, D., Teklemariam, G. K., Hoebeke, J., Abeele, F. V. d., Poorter,
E. D., Moerman, I., and Demeester, P. (2013). Ietf standardization in the field of the internet of
things (iot): a survey. Journal of Sensor and Actuator Networks, 2(2):235287.
[Jakus et al. 2013] Jakus, G., Milutinovic, V., Omerovic, S., and Tomazic, S. (2013). Concepts,
Ontologies, and Knowledge Representation. Springer Publishing Company, Incorporated.
[Javaid et al. 2009] Javaid, N., Javaid, A., Khan, I., and Djouani, K. (2009). Performance study
of ETX based wireless routing metrics. In 2nd IC4 2009.
[Kelly et al. 2013] Kelly, S. D. T., Suryadevara, N. K., and Mukhopadhyay, S. C. (2013). Towards
the implementation of IoT for environmental condition monitoring in homes. Sensors Journal,
IEEE, 13(10):38463853.
[Khaleghi et al. 2013] Khaleghi, B., Khamis, A., Karray, F. O., and Razavi, S. N. (2013). Multi-
sensor data fusion: A review of the state-of-the-art. Information Fusion, 14(1):2844.
[Khan et al. 2012] Khan, R., Khan, S. U., Zaheer, R., and Khan, S. (2012). Future internet:
the internet of things architecture, possible applications and key challenges. In Frontiers of
Information Technology (FIT), 2012 10th International Conference on, pages 257260. IEEE.
[Kovatsch et al. 2011] Kovatsch, M., Duquennoy, S., and Dunkels, A. (2011). A low-power coap
for contiki. In Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th International Confe-
rence on, pages 855860. IEEE.
[Kurose and Ross 2012] Kurose, J. F. and Ross, K. W. (2012). Computer Networking: A Top-
Down Approach (6th Edition). Pearson, 6th edition.

[Kushalnagar et al. 2007] Kushalnagar, N., Montenegro, G., and Schumacher, C. (2007). Ipv6
over low-power wireless personal area networks (6lowpans): overview, assumptions, problem
statement, and goals. Technical report.

[Levis and Lee 2010] Levis, P. and Lee, N. (2010). TOSSIM: A Simulator for TinyOS Networks.

[Levis et al. 2003] Levis, P., Lee, N., Welsh, M., and Culler, D. (2003). Tossim: Accurate and
scalable simulation of entire tinyos applications. In Proceedings of the 1st International Con-
ference on Embedded Networked Sensor Systems, SenSys 03, pages 126137, New York, NY,
USA. ACM.

[Levis et al. 2005] Levis, P., Madden, S., Polastre, J., Szewczyk, R., Whitehouse, K., Woo, A.,
Gay, D., Hill, J., Welsh, M., Brewer, E., and Culler, D. (2005). Ambient Intelligence, chapter
TinyOS: An Operating System for Sensor Networks, pages 115148. Springer Berlin Heidel-
berg, Berlin, Heidelberg.

[Levis et al. 2004] Levis, P., Patel, N., Culler, D., and Shenker, S. (2004). Trickle: A self-
regulating algorithm for code propagation and maintenance in wireless sensor networks. In
Proceedings of the 1st Conference on Symposium on Networked Systems Design and Imple-
mentation - Volume 1, NSDI04, pages 22, Berkeley, CA, USA. USENIX Association.

[Lin et al. 2003] Lin, J., Keogh, E., Lonardi, S., and Chiu, B. (2003). A symbolic representation
of time series, with implications for streaming algorithms. In Proceedings of the 8th ACM
SIGMOD workshop on Research issues in data mining and knowledge discovery - DMKD 03,
pages 2 11, New York, New York, USA. ACM Press.

[Liu et al. 2013] Liu, V., Parks, A., Talla, V., Gollakota, S., Wetherall, D., and Smith, J. R. (2013).
Ambient backscatter: wireless communication out of thin air. ACM SIGCOMM Computer
Communication Review, 43(4):3950.

[Loureiro et al. 2003] Loureiro, A. A., Nogueira, J. M. S., Ruiz, L. B., Mini, R. A. d. F., Na-
kamura, E. F., and Figueiredo, C. M. S. (2003). Redes de Sensores Sem Fio. In Simpsio
Brasileiro de Redes de Computadores (SBRC), pages 179226.

[Mattern and Floerkemeier 2010] Mattern, F. and Floerkemeier, C. (2010). From the internet of
computers to the internet of things. In From active data management to event-based systems
and more, pages 242259. Springer.

[Min et al. 2011] Min, Z., Bei, W., Chunyuan, G., and Zhao qian, S. (2011). Applied Informa-
tics and Communication: International Conference, ICAIC 2011, Xian, China, August 20-21,
2011, Proceedings, Part IV, chapter Application Study of Precision Agriculture Based on On-
tology in the Internet of Things Environment, pages 374380. Springer Berlin Heidelberg,
Berlin, Heidelberg.

[Mitchell 1997] Mitchell, T. M. (1997). Machine Learning. McGraw-Hill, Inc., New York, NY,
USA, 1 edition.

[Morettin and Toloi 2006] Morettin, P. A. and Toloi, C. M. C. (2006). Anlise de Sries Tempo-
rais. Blucher, So Paulo, 2nd edition.
[Murphy 2012] Murphy, K. P. (2012). Machine Learning: A Probabilistic Perspective. The MIT
Press.

[sterlind and of Computer Science 2006] sterlind, F. and of Computer Science, S. I. (2006).
A Sensor Network Simulator for the Contiki OS. SICS technical report. Swedish institute of
computer science.

[Patel and Rutvij H. 2015] Patel, K. N. and Rutvij H., J. (2015). A survey on emulation testbeds
for mobile ad-hoc networks. Procedia Computer Science, 45:581591.

[Paulo F. Pires 2015] Paulo F. Pires, Flavia C. Delicato, T. B. (2015). Plataformas para a Internet
das Coisas.

[Perera et al. 2014] Perera, C., Zaslavsky, A., Christen, P., and Georgakopoulos, D. (2014). Con-
text aware computing for the internet of things: A survey. Communications Surveys & Tutorials,
IEEE, 16(1):414454.

[Peterson and Davie 2011] Peterson, L. L. and Davie, B. S. (2011). Computer Networks, Fifth
Edition: A Systems Approach. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA,
5th edition.

[Ramos et al. 2012] Ramos, H. S., Oliveira, E. M., Boukerche, A., Frery, A. C., and Loureiro,
A. A. (2012). Characterization and mitigation of the energy hole problem of many-to-one
communication in wireless sensor networks. In Computing, Networking and Communications
(ICNC), 2012 International Conference on, pages 954958. IEEE.

[Rani and Sikka 2012] Rani, S. and Sikka, G. (2012). Recent Techniques of Clustering of Time
Series Data: A Survey. International Journal of Computer Applications, 52(15):19.

[Reiter 2014] Reiter, G. (2014). Wireless connectivity for the internet of things: One size does
not fit all. page 11.

[RERUM 2015] RERUM (2015). Advanced techniques to increase the lifetime of smart objects
and ensure low power network operation. RERUM.

[Ruiz et al. 2004] Ruiz, L. B., Correia, L. H. A., Vieira, L. F. M., Macedo, D. F., Nakamura, E. F.,
Figueiredo, C. M., Vieira, M. A. M., Bechelane, E. H., Camara, D., Loureiro, A. A., et al.
(2004). Arquiteturas para redes de sensores sem fio.

[Saltzer et al. 1984] Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). End-to-end arguments in
system design. ACM Transactions on Computer Systems (TOCS), 2(4):277288.

[Santos et al. 2015a] Santos, B., Vieira, M., and Vieira, L. (2015a). eXtend collection tree pro-
tocol. In Wireless Communications and Networking Conference (WCNC), 2015 IEEE, pages
15121517.

[Santos et al. 2015b] Santos, B. P., Menezes Vieira, L. F., and Menezes Vieira, M. A. (2015b).
CRAL: a centrality-based and energy efficient collection protocol for low power and lossy
networks. In Computer Networks and Distributed Systems (SBRC), 2015 XXXIII Brazilian
Symposium on, pages 159170. IEEE.

[Schafer and Graham 2002] Schafer, J. L. and Graham, J. W. (2002). Missing data: Our view of
the state of the art. Psychological Methods, 7(2):147177.
[Shelby and Bormann 2011] Shelby, Z. and Bormann, C. (2011). 6LoWPAN: The wireless em-
bedded Internet, volume 43. John Wiley & Sons.

[Silva et al. 2014] Silva, T., Vaz De Melo, P., Almeida, J., and Loureiro, A. (2014). Large-scale
study of city dynamics and urban social behavior using participatory sensing. Wireless Com-
munications, IEEE, 21(1):4251.

[Sundmaeker et al. 2010] Sundmaeker, H., Guillemin, P., Friess, P., and Woelffl, S. (2010). Vi-
sion and challenges for realising the Internet of Things, volume 20. EUR-OP.

[Tanenbaum 2002] Tanenbaum, A. (2002). Computer Networks. Prentice Hall Professional Te-
chnical Reference, 4th edition.

[Tanenbaum 2011] Tanenbaum, A. (2011). Computer Networks. Prentice Hall Professional Te-
chnical Reference, 5th edition.

[Tsvetko 2011] Tsvetko, T. (2011). Rpl: Ipv6 routing protocol for low power and lossy networks.
In Seminar Sensorknoten: Betrieb, Netze und Anwendungen SS.

[Varga et al. 2001] Varga, A. et al. (2001). The omnet++ discrete event simulation system. In
Proceedings of the European simulation multiconference (ESM2001), volume 9, page 65. sn.

[Varga and Hornig 2008] Varga, A. and Hornig, R. (2008). An Overview of the OMNeT++ Si-
mulation Environment. In Proceedings of the 1st International Conference on Simulation Tools
and Techniques for Communications, Networks and Systems & Workshops, Simutools 08, pa-
ges 60:160:10, ICST, Brussels, Belgium, Belgium. ICST (Institute for Computer Sciences,
Social-Informatics and Telecommunications Engineering).

[Vasseur et al. 2011] Vasseur, J., Agarwal, N., Hui, J., Shelby, Z., Bertrand, P., and Chauvenet,
C. (2011). Rpl: The ip routing protocol designed for low power and lossy networks. Internet
Protocol for Smart Objects (IPSO) Alliance.

[Vasseur and Dunkels 2010] Vasseur, J.-P. and Dunkels, A. (2010). Interconnecting Smart Ob-
jects with IP: The Next Internet. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.

[Wang et al. 2015] Wang, F., Hu, L., Zhou, J., and Zhao, K. (2015). A Survey from the Pers-
pective of Evolutionary Process in the Internet of Things. International Journal of Distributed
Sensor Networks, 2015.

[Warren Liao 2005] Warren Liao, T. (2005). Clustering of time series data - A survey. Pattern
Recognition, 38(11):18571874.

[Weingrtner et al. 2009] Weingrtner, E., Vom Lehn, H., and Wehrle, K. (2009). A performance
comparison of recent network simulators. In Proceedings of the 2009 IEEE International Con-
ference on Communications, ICC09, pages 12871291, Piscataway, NJ, USA. IEEE Press.

[Yan et al. 2013] Yan, Y., Qian, Y., Sharif, H., and Tipper, D. (2013). A Survey on Smart Grid
Communication Infrastructures: Motivations, Requirements and Challenges. IEEE Communi-
cations Surveys & Tutorials, 15(1):520.