Captulo

1Internet das Coisas: da Teoria Prtica

Bruno P. Santos, Lucas A. M. Silva, Clayson S. F. S. Celes, Joo B. BorgesNeto, Bruna S. Peres, Marcos Augusto M. Vieira, Luiz Filipe M. Vieira,

Olga N. Goussevskaia e Antonio A. F. Loureiro

Departamento de Cincia da ComputaoUniversidade Federal de Minas Gerais (UFMG)

Belo Horizonte, MG, Brasil

{bruno.ps, lams, claysonceles, joaoborges, bperes, mmvieira, lfvieira,olga, loureiro}@dcc.ufmg.br

Abstract

The proliferation of smart objects with capability of sensing, processing and communi-cation has grown in recent years. In this scenario, the Internet of Things (IoT) connectsthese objects to the Internet and provides communication with users and devices. IoTenables a huge amount of new applications, with which academics and industries canbenefit, such as smart cities, health care and automation. On the other hand, there are se-veral social, theoretical and practical issues we need to address. To answer these issues,we need to overcome some challenges like dealing with objects constraints (e.g., proces-sing, memory and energy supply), limited bandwidth and hardware dimension. Thus, weneed to explore new communication paradigms, protocols including questions about IPaddressing and adaptations to interoperate with the Internet, hardware architecture andsoftware design. Besides that, IoT applications need to deal with the process of collecting,storing, processing and extracting knowledge from data obtained from the smart objects.The goal of this chapter is to describe the state-of-the-art of IoT by discussing theoreticaland practical questions.

Resumo

A proliferao de objetos inteligentes com capacidade de sensoriamento, proces-samento e comunicao tem aumentado nos ltimos anos. Neste cenrio, a Internet dasCoisas (Internet of Things (IoT)) conecta estes objetos Internet e promove a comuni-cao entre usurios e dispositivos. A IoT possibilita uma grande quantidade de novasaplicaes, as quais tanto a academia quanto a industria podem se beneficiar, tais comocidades inteligentes, sade e automao de ambientes. Por outro lado, existem diver-sos desafios que devemos enfrentar no mbito social, terico e prtico. Para respondera essas questes, precisamos vencer alguns desafios como, por exemplo, restries dosobjetos inteligentes (processamento, memria e fonte de alimentao), largura de bandalimitada e dimenso do hardware. Deste modo, devemos explorar novos paradigmasde comunicao, protocolos incluindo questes sobre o endereamento IP e adaptaespara interoperar com a Internet, arquitetura de hardware e projeto de software. Almdisso, aplicaes de IoT precisam tratar questes como coletar, armazenar, processar eextrair conhecimento de dados obtidos dos objetos inteligentes. O objetivo deste captulo descrever o estado-da-arte de IoT discutindo questes tericas e prticas.

1.1. IntroduoA Internet das Coisas (do ingls Internet of Things (IoT)) emergiu dos avanos de

vrias reas como sistemas embarcados, microeletrnica, comunicao e sensoriamento.De fato, a IoT tem recebido bastante ateno tanto da academia quanto da indstria, de-vido ao seu potencial de uso nas mais diversas reas das atividades humanas. Este captuloaborda a Internet das Coisas atravs de uma perspectiva terica e prtica. O contedo aquiabordado explora a estrutura, organizao, desafios e aplicaes da IoT. Nesta seo, seroconceituadas a IoT e os objetos inteligentes. Alm disso, so apresentadas a perspectivahistrica da Internet das Coisas e as motivaes que levam aos interesses, expectativas epesquisas na rea. Logo em seguida, so introduzidos os blocos bsicos de construoda IoT. Para iniciar a discusso, ser levantada a seguinte questo: o que a Internet dasCoisas?

A Internet das Coisas, em poucas palavras, nada mais que uma extenso daInternet atual, que proporciona aos objetos do dia-a-dia (quaisquer que sejam), mas comcapacidade computacional e de comunicao, se conectarem Internet. A conexo com arede mundial de computadores viabilizar, primeiro, controlar remotamente os objetos e,segundo, permitir que os prprios objetos sejam acessados como provedores de servios.Estas novas habilidades, dos objetos comuns, geram um grande nmero de oportunidadestanto no mbito acadmico quanto no industrial. Todavia, estas possibilidades apresentamriscos 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. ParaTanenbaum [Tanenbaum 2002], Rede de Computadores um conjunto de computadoresautnomos interconectados por uma nica tecnologia. Entende-se que tal tecnologia deconexo pode ser de diferentes tipos (fios de cobre, fibra tica, ondas eletromagnticasou outras). Em 2011, Peterson definiu em [Peterson and Davie 2011] que a principalcaracterstica das Redes de Computadores a sua generalidade, isto , elas so construdas

sobre dispositivos de propsito geral e no so otimizadas para fins especficos tais comoas redes de telefonia e TV. J em [Kurose and Ross 2012], os autores argumentam que otermo Redes de Computadores comea a soar um tanto envelhecido devido grandequantidade de equipamentos e tecnologias no tradicionais que so usadas na Internet.

Os objetos inteligentes, definidos mais adiante, possuem papel fundamental naevoluo 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, comotambm uma grande heterogeneidade de equipamentos tais como TVs, Laptops, auto-mveis, smartphones, consoles de jogos, webcams e a lista aumenta a cada dia. Nestenovo cenrio, a pluralidade crescente e previses indicam que mais de 40 bilhes dedispositivos estaro conectados at 2020 [Forbes 2014]. Usando os recursos deses obje-tos ser possvel detectar seu contexto, control-lo, viabilizar troca de informaes unscom os outros, acessar servios da Internet e interagir com pessoas. Concomitantemente,uma gama de novas possibilidades de aplicaes surgem (ex: cidades inteligentes (SmartCities), sade (Healthcare), casas inteligentes (Smart Home)) e desafios emergem (re-gulamentaes, segurana, padronizaes). importante notar que um dos elementoscruciais para o sucesso da IoT encontra-se na padronizao das tecnologias. Isto permi-tir que a heterogeneidade de dispositivos conectados Internet cresa, tornando a IoTuma realidade. Tambm essencial frisar que nos ltimos meses e nos prximos anossero vivenciados os principais momentos da IoT, no que tange as definies dos blocosbsicos de construo da IoT.

Parafraseado os autores [Mattern and Floerkemeier 2010], ao utilizar a palavraInternet"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 decomunio umas com as outras, provero e usaro servios, provero dados e poderoreagir a eventos. Outra analogia, agora mais tcnica, que IoT vista como uma pilha deprotocolos utilizados nos objetos inteligentes.

Na IoT, eventualmente, a unidade bsica de hardware apresentar ao menos umadas 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 outrosdispositivos, 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 ofThings foi primeiro utilizando em seu trabalho intitulado I made at Procter & Gambleem 1999. Na poca, a IoT era associada ao uso da tecnologia RFID. Contudo, o termoainda 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 inglsWireless Sensor Networks WSN). Estas redes trazem avanos na automao residenciale industrial [Kelly et al. 2013, Da Xu et al. 2014], bem como tcnicas para explorar as

Figura 1.1. Volume de pesquisas no Google sobre Wireless SensorNetworks e Internet of Things

diferentes limitaes dos dispositivos (e.g., memria e energia), escalabilidade e robustezda rede [Loureiro et al. 2003]. Nos anos seguintes (entre 2008 e 2010), o termo Internetdas Coisas ganhou popularidade rapidamente. Isto se deve ao amadurecimento das RSSFse ao crescimento das expectativas sobre a IoT. A Figura 1.1 mostra que em 2010, as buscaspara IoT dispararam chegando a ultrapassar as pesquisas sobre RSSFs.

Figura 1.2. Tecnologias emergentes

A IoT foi identificada comouma tecnologia emergenteem 2012 por especialistas darea [Gartner 2015]. A Fi-gura 1.2 apresenta uma ma-neira de representar o surgi-mento, adoo, maturidade eimpacto de diversas tecnolo-gias chamada de Hype Cycle,ou Ciclo de Interesse. Opesquisador Clarke , pesqui-sador do MIT, props a curvados dois elefantes, que

Em 2012, foi previstoque a IoT levaria entre cincoe dez anos para ser adotadapelo mercado e, hoje, vi-

venciado o maior pico de expectativas sobre a tecnologia no mbito acadmico e indus-trial. Tambm pode-se notar o surgimento das primeiras plataformas de IoT (discutidasmais adiante) que tm gerado uma grande expectativa de seu uso. Estes fatos certamenteservem de incentivo para despertar a curiosidade do leitor para a rea, bem como indica omotivo 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 significacriar 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 dadosde pacientes e monitoramento de idosos, sensoriamento de ambientes de difcil acesso einspitos, entre outras [Sundmaeker et al. 2010].

Neste cenrio, a possibilidade de novas aplicaes crescente, mas temos no-vos desafios de conectar Internet objetos com restries de processamento, memria,comunicao e energia [Loureiro et al. 2003]. Naturalmente, nesse caso os objetos soheterogneos, isto , divergem em implementao, recursos e qualidade. Algumas dasquestes tericas quanto prticas que surgem so, por exemplo, prover endereamentoaos dispositivos, encontrar rotas de boa vazo e que usem parcimoniosamente os recursoslimitados dos objetos. Deste modo, fica evidente a necessidade da adaptao dos protoco-los existentes. Alm disso, sabe-se que os paradigmas de comunicao e roteamento nasredes de objetos inteligentes podem no seguir os mesmos padres de uma rede como aInternet [Chaouchi 2013].

Novos desafios surgem enquanto so criadas novas aplicaes para IoT. Os dadosprovidos pelos objetos agora podem apresentar imperfeies (calibragem do sensor), in-consistncias (fora de ordem, outliers) e serem de diferentes tipos (gerados por pessoas,sensores fsicos, fuso de dados). Assim, as aplicaes e algoritmos devem ser capazesde 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 essesdados 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 contemplemas expectativas em um futuro prximo como previsto na Figura 1.2.

Alguns autores apontam que a IoT ser a nova revoluo da tecnologia da infor-mao [Ashton 2009, Forbes 2014, Wang et al. 2015]. Sendo assim, a IoT possivelmenteno deve ser entendida como um fim, mas sim um meio de alcanar algo maior como acomputao ubqua.

1.1.3. Blocos Bsicos de Construo da IoT

A IoT pode ser vista como a combinao de diversas tecnologias, as quais socomplementares no sentido de viabilizar a integrao dos objetos no ambiente fsico aomundo virtual. A Figura 1.3 apresenta os blocos bsicos de construo da IoT sendo eles:

Identificao: um dos blocos mais importantes, visto que primordial identificar os ob-jetos unicamente para conect-los Internet. Tecnologias como RFID, NFC (Near FieldCommunication) e endereamento IP podem ser empregados para identificar os objetos.

Sensores/Atuadores: sesnsores coletam informaes sobre o contexto onde os objetosse encontam e, em seguida, armazenam/encaminham esses dados para data warehouse,clouds ou centros de armazenamento. Atuadores podem manipular o ambiente ou reagirde acordo com os dados lidos.

Comunicao: diz respeito s diversas tcnicas usadas para conectar objetos inteligen-

tes. Tambm desempenha papel importante no consumo de energia dos objetos sendo,portanto, um fator crtico. Algumas das tecnologias usadas so WiFi, Bluetooth, IEEE802.15.4 e RFID.

Computao: inclui a unidade de processamento como, por exemplo, micro-controladores, processadores e FPGAs, responsveis por executar algoritmos locais nosobjetos inteligentes.

Figura 1.3. Blocos bsicos da IoT

Servios: a IoT pode prover diversas clas-ses de servios, dentre elas, destacam-seos Servios de Identificao, responsveispor mapear Entidades Fsicas (EF) (de in-teresse do usurio) em Entidades Virtuais(EV) como, por exemplo, a temperatura deum local fsico em seu valor, coordenadasgeogrficas do sensor e instante da coleta;Servios de Agregao de Dados que co-letam e sumarizam dados homogneos/he-terogneos obtidos dos objetos inteligen-tes; Servios de Colaborao e Intelign-cia que agem sobre os servios de agrega-o de dados para tomar decises e reagirde modo adequado a um determinado cenrio; e Servios de Ubiquidade que visam pro-ver servios de colaborao e inteligncia em qualquer momento e qualquer lugar em queeles sejam necessrios.

Semntica: refere-se habilidade de extrao de conhecimento dos objetos na IoT. Tratada descoberta de conhecimento e uso eficiente dos recursos existentes na IoT, a partir dosdados existentes, com o objetivo de prover determinado servio. Para tanto, podem serusadas diversas tcnicas como Resource Description Framework (RDF), Web OntologyLanguage (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 dasCoisas IoT, o que inclui diversos aspectos das Tecnologias da Informao e Comuni-cao (TICs). Para isso, apresentaremos o significado e funcionalidade dos principaisblocos relacionados IoT.

Aps a breve apresentao dos blocos da IoT, ficar evidente o quo ampla area. Em seguida, sero discutidos os seguintes blocos bsicos: Identificao, Comuni-cao e Servios/Semntica. A discusso tratar no apenas cada bloco individualmente,mas tambm como se relaciona com os demais. Esses blocos foram escolhidos por cap-turarem a essncia da IoT e possibilitarem ao leitor condies de explorar com maiorfacilidade outros blocos da IoT.

1.1.5. Estrutura do captulo

Este captulo dividido em seis sees, sendo esta a primeira. A Seo 1.2 abordapontos sobre os dispositivos e as tecnologias de comunicao para IoT. A Seo 1.3 dis-

cute sobre os softwares que orquestram a operao da IoT, pontuando a identificaonica dos dispositivos com IPv6, bem como modelos de conectividade, protocolos de ro-teamento e aplicao para IoT, e ambientes de desenvolvimento. A Seo 1.4 apresentaduas prticas para consolidar o contedo visto at ento. Essas prticas sero o elo para ocontedo da Seo 1.5, a qual aborda o gerenciamento e anlise de dados que permeiamos blocos bsicos de semntica e servios na IoT. Finalmente, a Seo 1.6 apresenta asconsideraes finais e destaca os pontos que no foram cobertos no captulo, apresentandoreferncias para que o leitor possa complementar seus estudos.

1.2. Dispositivos e Tecnologias de ComunicaoEsta seo aborda em mais detalhes a arquitetura bsica dos dispositivos inteli-

gentes e as tecnologias de comunicao, principalmente as solues de comunicao semfio que tendem a se popularizar no ambiente de IoT.

1.2.1. Arquiteturas bsica dos dispositivos

(1)(2)

(3)

(4)

(ii) Rdio(i) Processador/ Memria

(iii) Fonte de Energia(iv) Sensores

Figura 1.4. Arquitetura dos dispositivos

A arquitetura bsica dos obje-tos inteligentes composta por qua-tro unidades: processamento/mem-ria, comunicao, energia e senso-res/atuadores. A Figura 1.4 apresentauma viso geral da arquitetura de umdispositivo e a interligao entre seuscomponentes, os quais so descritos aseguir:

(i) Unidade(s) de processamento/-memria: composta de uma memriainterna para armazenamento de dadose programas, um microcontrolador eum conversor analgico-digital parareceber sinais dos sensores. As CPUsutilizadas nesses dispositivos so, emgeral, as mesmas utilizadas em siste-mas embarcados e comumente no apresentam alto poder computacional. Frequente-mente existe uma memria externa do tipo flash, que serve como memria secundria,por exemplo, para manter um log de dados. As caractersticas desejveis para estasunidades so consumo reduzido de energia e ocupar o menor espao possvel.

(ii) Unidade(s) de comunicao: consiste de pelo menos um canal de comunicao comou sem fio, sendo mais comum o meio sem fio. Neste ltimo caso, a maioria das plata-formas usam rdio de baixo custo e baixa potncia. Como consequncia, a comunicao de curto alcance e apresentam perdas frequentes. Esta unidade bsica ser objeto deestudo mais detalhado na prxima seo.

(iii) Fonte de energia: responsvel por fornecer energia aos componentes do objeto inte-ligente. Normalmente, a fonte de energia consiste de uma bateria (recarregvel ou no) eum conversor AC-DC e tem a funo de alimentar os componentes. Entretanto, existem

outras fontes de alimentao como energia eltrica, solar e mesmo a captura de energiado ambiente atravs de tcnicas de converso (e.g., energia mecnica em energia eltrica),conhecidas como energy harvesting.

(iv) Unidade(s) de sensor(es)/atuador(es): realizam o monitoramento do ambiente noqual o objeto se encontra. Os sensores capturam valores de grandezas fsicas como tem-peratura, umidade, presso e presena. Atualmente, existem literalmente centenas de sen-sores diferentes que so capazes de capturar essas grandezas. Atuadores, como o nomeindica, so dispositivos que produzem alguma ao, atendendo a comandos que podemser manuais, eltricos ou mecnicos.

1.2.2. Tecnologias de comunicao

Esta seo trata das principais tecnologias de comunicao utilizadas em IoT,identificando as caractersticas mais relevantes de cada um delas.

Ethernet. O padro Ethernet (IEEE 802.3) foi oficializado em 1983 pelo IEEE e estpresente em grande parte das redes locais com fio existentes atualmente. Sua popularidadese deve simplicidade, facilidade de adaptao, manuteno e custo. Atualmente, existemdois tipos de cabos: par tranado e fibra ptica, que oferecem taxas de comunicaodiferentes. Os cabos de par tranado podem atingir taxas de at 1 Gbps (categoria 5),limitados a 100 m (para distncias maiores necessrio o uso de repetidores). Os cabosde fibra ptica alcanam taxas de 10 Gbps, limitados a 2000 m [Tanenbaum 2011]. O usodo padro Ethernet sugerido para dispositivos fixos, i.e., sem mobilidade, o que podeser inadequado para essas aplicaes.

Wi-Fi. A tecnologia Wi-Fi uma soluo de comunicao sem fio bastante popular, poisest presente nos mais diversos lugares, fazendo parte do cotidiano de casas, escritrios,indstrias, lojas comerciais e at espaos pblicos das cidades. O padro IEEE 802.11(Wi-Fi1) define um conjunto de padres de transmisso e codificao. Desde o seu lana-mento em 1997, j foram propostas novas verses do padro IEEE 802.11 e, atualmente,a verso IEEE 802.11ac prev taxas de comunicao de 600 Mbps ou 1300 Mbps.

O Wi-Fi foi desenvolvido como uma alternativa ao padro cabeado Ethernet, compouca preocupao com dispositivos que possuem consumo energtico limitado, como ocaso das aplicaes para IoT. Assim, no se espera que muitos dispositivos utilizados emIoT adotem o padro Wi-Fi como principal protocolo de comunicao. Contudo, o Wi-Fipossui algumas vantagens, como alcance de conexo e vazo, o que o torna adequado paranavegao na Internet em dispositivos mveis, como smartphones e tablets. A principaldesvantagem do Wi-Fi o maior consumo de energia, quando comparado com outrastecnologias de comunicao sem fio.

ZigBee. O padro ZigBee baseado na especificao do protocolo IEEE 802.15.4 para acamada de enlace. As suas principais caractersticas so a baixa vazo, reduzido consumoenergtico e baixo custo. O ZigBee opera na frequncia 2.4 GHz (faixa ISM), mas capaz de operar em outras duas frequncias, 868 MHz e 915 MHz. Essa tecnologia pode

1Por um abuso de linguagem, chamamos o padro IEEE 802.11 de Wi-Fi, que na verdade representaa Aliana Wi-Fi (http://www.wi-fi.org/) responsvel por certificar a conformidade de produtosque seguem a norma IEEE 802.11.

http://www.wi-fi.org/

alcanar uma taxa mxima de 250 kbps, mas na prtica temos taxas inferiores . O ZigBeetambm permite que os dispositivos entrem em modo sleep por longos intervalos de tempopara economizar energia e, assim, estendendo a vida til do dispositivo.

O padro ZigBee mantido pela ZigBee Alliance, organizao que responsvelpor gerir o protocolo e garantir a interoperabilidade entre dispositivos. O padro ZigBeepode ser usado com o protocolo IP (incluindo o IPv6) e tambm utilizando a topologiaem malha (Mesh2). O ZigBee j adotado em aplicaes residenciais e comerciais esua utilizao em IoT depende de um gateway, dispositivo responsvel por permitir acomunicao entre dispositivos que usam ZigBee e os que no usam.

Bluetooth Low Energy. O Bluetooth um protocolo de comunicao proposto pelaEricsson para substituir a comunicao serial RS-232 3. Atualmente, o Bluetooth Spe-cial Interest Group responsvel por criar, testar e manter essa tecnologia. Alm disso,Bluetooth uma das principais tecnologias de rede sem fio para PANs Personal AreaNetworks, que utilizada em smartphones, headsets, PCs e outros dispositivos. O Blu-etooth se divide em dois grupos: Bluetooth clssico que por sua vez se divide em BasicRate/Enhanced Data Rate (BR/EDR), que so as verses 2.0 ou anteriores e o BluetoothHigh Speed (HS), verso 3.0; e o Bluetooth Low Energy (BLE), verso 4.0 ou superior.As verses mais antigas do Bluetooth, focadas em aumentar a taxa de comunicao, tor-nou o protocolo mais complexo e, por consequncia, no otimizado para dispositivos comlimitaes energticas. Ao contrrio das verses anteriores, o BLE possui especificaovoltada para baixo consumo de energia, permitindo dispositivos que usam baterias dotamanho de moedas (coin cell batteries).

Atualmente, o BLE possui trs verses: 4.0, 4.1 e 4.2, lanadas em 2010, 2013e 2014, respectivamente. BLE 4.0 e 4.1 possuem um mximo de mensagem (MaximumTransmit Unit MTU) de 27 bytes, diferentemente da mais nova verso (BLE 4.2) quepossui 251 bytes. Outra diferena entre as verses o tipo de topologia de rede que cadaverso pode criar. Na verso 4.0, apenas a topologia estrela disponvel, ou seja, cadadispositivo pode atuar exclusivamente como master ou como slave. A partir da verso 4.1,um dispositivo capaz de atuar como master ou slave simultaneamente, permitindo a cri-ao de topologias em malha. Recentemente foi proposta uma camada de adaptao paradispositivos BLE, similar ao padro 6LoWPAN, chamada de 6LoBTLE. A especificaodo 6LoBTLE pode ser consultada na RFC 76684.

3G/4G. Os padres de telefonia celular 3G/4G tambm podem ser aplicados IoT. Pro-jetos que precisam alcanar grandes distncias podem aproveitar as redes de telefoniacelular 3G/4G. Por outro lado, o consumo energtico da tecnologia 3G/4G alto emcomparao a outras tecnologias. Porm, a sua utilizao em locais afastados e baixamobilidade podem compensar esse gasto. No Brasil, as frequncias utilizadas para o 3Gso 1900 MHz e 2100 MHz (UMTS), enquanto o padro 4G (LTE) utiliza a frequncia de2500 MHz. A taxa de comunicao alcanada no padro 3G de 1 Mbps e no padro 4G

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

bluetooth-fact-or-fiction4https://tools.ietf.org/html/rfc7668

http://www.zigbee.org/zigbee-for-developers/network-specifications/https://www.bluetooth.com/what-is-bluetooth-technology/bluetooth-fact-or-fictionhttps://www.bluetooth.com/what-is-bluetooth-technology/bluetooth-fact-or-fictionhttps://tools.ietf.org/html/rfc7668

10 Mbps 5.

LoRaWAN is a Low Power Wide Area Network (LPWAN) specification intendedfor wireless battery operated Things in regional, national or global network. LoRaWANtarget key requirements of internet of things such as secure bi-directional communication,mobility and localization services.

LoRaWan. A especificao LoRaWAN (Long Range Wide Area Network) foi projetadapara criar redes de longa distncia, numa escala regional, nacional ou global, formadapor dispositivos operados por bateria e com capacidade de comunicao sem fio. A es-pecificao LoRaWan trata de requisitos presentes na IoT como comunicao segura ebi-direcional, mobilidade e tratamento de servios de localizao. Alm disso, o padrooferece suporte a IPv6, adaptao ao 6LoWPAN e funciona sobre a topologia estrela 6. Ofator atrativo do LoRAWAN o seu baixo custo e a quantidade de empresas de hardwareque esto o adotando. A taxa de comunicao alcana valores entre 300 bps a 50 kbps. Oconsumo de energia na LoRaWan considerado pequena, o que permite aos dispositivosse manterem ativos por longos perodos. A LoRaWANs utiliza a frequncia ISM sub-GHzfazendo com que as ondas eletromagnticas penetrem grandes estruturas e superfcies, adistncias de 2 km a 5 km em meio urbano e 45 km no meio rural. Os valores de frequn-cia mais usadas pelo LoRaWan so: 109 MHz, 433 MHz, 866 MHz e 915 MHz. O MTUadotado pelo padro LoRaWAN de 256 bytes7.

Sigfox. O SigFox8 utiliza a tecnologia Ultra Narrow Band (UNB), projetada para lidarcom pequenas taxas de transferncia de dados. Essa tecnologia ainda bastante recente ej possui bastante aceitao, chegando a dezenas de milhares de dispositivos espalhadospela Europa e Amrica do Norte. A SigFox atua como uma operadora para IoT, comsuporte a uma srie de dispositivos. A principal funo abstrair dificuldades de conexoe prover uma API para que os usurios implementem sistemas IoT com maior facilidade.O raio de cobertura oficialmente relatada, em zonas urbanas, est entre 3 km e 10 km e emzonas rurais entre 30 km a 50 km. A taxa de comunicao varia entre 10 bps e 1000 bpse o MTU utilizado de 96 bytes. O SigFox possui baixo consumo de energia e opera nafaixa de 900 MHz.

A Tabela 1.1 resume as tecnologias de comunicao apresentadas nesta seo. Asprincipais caractersticas de cada uma so elencadas, o que permite compar-las. Emparticular, destaca-se a grande variedade de possibilidades para conectar dispositivos.Portanto, preciso ponderar acerca das caractersticas das tecnologias e finalidade dodispositivo para escolher a melhor forma de conect-lo.

1.2.3. Perspectivas e desafios sobre os objetos inteligentes

A evoluo nas tecnologias de hardware utilizadas em RFID, RSSF, e, consequen-temente, na IoT impressionante quando olhamos apenas a ltima dcada. Os disposi-tivos esto cada vez menores e possuem mais recursos. Pode-se esperar ainda que essaevoluo continue e, no futuro, possivelmente veremos outras tecnologias de hardware

5https://www.opensensors.io/connectivity6http://www.semtech.com/wireless-rf/lora/LoRa-FAQs.pdf7https://www.lora-alliance.org8http://makers.sigfox.com

https://www.opensensors.io/connectivityhttp://www.semtech.com/wireless-rf/lora/LoRa-FAQs.pdfhttps://www.lora-alliance.orghttp://makers.sigfox.com

Protocolo Alcance Frequncia Taxa IPv6 Topologia

Ethernet 100/2000 m N/A 10 Gbps Sim VariadaWi-Fi 50 m 2.4/5 GHz 1300 Mbps Sim EstrelaBLE 80 m 2.4 GHz 1 Mbps Sim* Estrela/MeshZigBee 100 m 915 MHz/2.4 GHz 250 kbps Sim Estrela/Mesh3G/4G 35/200 km 1900/2100/2500 MHz 1/10 Mbps Sim EstrelaSigFox 10/50 km 868/902 MHz 101000 bps LoraWan 2/5 km Sub-GHz 0.3-50 kbps Sim Estrela

Tabela 1.1. Comparao entre as tecnologias de comunicao

empregadas na IoT, diferentes das de hoje. Atualmente, temos dispositivos inteligentescomo sistemas-em-um-chip (system on a chip SoC) [Vasseur and Dunkels 2010], queclaramente uma evoluo quando analisamos os ltimos 10 a 15 anos. Esta seo tratadas perspectivas e desafios para a IoT. A seguir, sero abordados dois pontos centrais. Noprimeiro, a questo da fonte de energia e o segundo as futuras tecnologias de hardwarepara 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 ener-gia. Atualmente, os objetos inteligentes so alimentados, em geral, por baterias, muitasvezes no recarregveis. No entanto, existem outras fontes de alimentao como ener-gia eltrica e solar. As baterias (recarregveis ou no) so as fontes de alimentao maisempregadas nos dispositivos de IoT, embora no sejam as mais adequadas para a tarefa.Isto porque, em geral, os dispositivos esto em locais de difcil acesso (e.g., embutidosem outros dispositivos) ou simplesmente no desejvel manipul-los fisicamente parasubstituir as baterias. Assim, tanto o hardware quando o software devem ser projetadospara estender ao mximo a vida til desses dispositivos [RERUM 2015].

Uma possvel estratgia para mitigar o problema da energia fazer uso da tcnicade colheita de energia (do ingls Energy Harvesting) [Ramos et al. 2012]. A estratgiaconsiste em transformar energia de fontes externas ao dispositivo como, por exemplo,solar, trmica, elica e cintica em energia eltrica e armazen-la em uma bateria re-carregvel. A energia colhida (geralmente em pequenas quantidades) armazenada edeve ser utilizada para suprir as necessidades dos objetos como comunicao e processa-mento [Liu et al. 2013]. Contudo, a colheita de energia tambm traz ao menos um outrodesafio que discutiremos a seguir, o qual pode ser o ponto de partida para novas pesquisas.

Caso os dispositivos tenham a capacidade de colher energia do ambiente ondeesto inseridos, surgem diversas questes a serem tratadas. Por exemplo, como progra-mar as atividades que o dispositivo deve executar considerando o oramento de energia(energy budget)? Em outras palavras, como gastar a energia em funo das atividadesque devem ser feitas? Para exemplificar, imagine a situao na qual o dispositivo deverealizar tarefas durante 24 horas/dia. No entanto, 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 consegue fornecer energia para 24 horas de operao.Sendo assim, as atividades do dispositivo devem ser realizadas de modo intermitente, ouseja, alterando entre realizar os comandos requeridos e entrar em modo de espera ou debaixa potncia (sleep mode). Portanto, a atividade deve ser realizada de modo inteligentedado a demanda de atividades e oramento de energia residual e adquirida do ambiente.Tcnicas mais sofisticadas podem ainda adaptar a computao a ser feita em funo daenergia disponvel ou de expectativas de se ter energia no futuro, em funo do que foipossvel captar de energia do passado. Nesse caso, isso envolve tcnicas de predio.

1.2.3.2. Tecnologias de hardware

Considerando a discusso anterior, fica claro que os objetos inteligentes e tecno-logias de comunicao apresentam diferentes caractersticas e limitaes. medida queos dispositivos de IoT diminuem, por um lado as limitaes tendem a aumentar devidoao espao reduzido, mas por outro podemos ter avanos tecnolgicos que mitiguem essasrestries. Por exemplo, anos atrs foi prevista a possibilidade de existirem dispositivosem escala nanomtrica, o que j uma realidade com os microelectromechanical sys-tems (MEMS) [Angell et al. 1983]. J hoje, existem propostas de utilizarmos Claytronicse Programmable Matter [Goldstein et al. 2005], que consistem em combinar robs deescala nanomtrica (claytronic atoms ou catoms) para formar outras mquinas. Oscatoms eventualmente sero capazes de se comunicarem, moverem e conectarem com ou-tros catoms para apresentar diferentes formas e utilidades. Uma outra perspectiva futuraquanto ao hardware diz respeito aos SoCs, onde um circuito integrado possui todos oscomponentes de um elemento computacional. Para o caso dos objetos inteligentes, essesistema ter rdio, microcontrolador e sensores/atuadores. Entretanto, atualmente isso um problema, pois o rdio requer um arranjo sofisticado para ser posto em um nicochip [Vasseur and Dunkels 2010].

H poucos anos atrs, era possvel apontar o fator custo como limitante para ado-o e desenvolvimento de objetos inteligentes. Entretanto, hoje possvel encontrar so-lues de IoT disponveis no mercado de baixo custo. Para esse segmento, possvelafirmar que o custo do hardware j acessvel, se analisarmos o preo de produtos comoo Raspberry Pi, Arduino e similares que permitem desde a prototipagem at a produofinal de solues de IoT a baixo custo. Por exemplo, possvel encontrar o Raspberry Piao custo de US$ 35.

1.3. Softwares e Ambientes de Desenvolvimentos para IoTEsta seo aborda assuntos referentes camada de software que orquestra a lgica

de operao dos objetos inteligentes. O bloco bsico de identificao e os mecanismosde comunicao so os pontos centrais da seo. Alm disso, sero descritos os sistemasoperacionais para IoT, bem como os principais ambientes de desenvolvimento. O tpico,a seguir, apresentar alguns argumentos e requisitos para softwares utilizados na IoT. Osdesdobramentos 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 pesquisadores tanto da academia quanto daindstria nos ltimos anos como exposto na Seo 1.1. A interconexo entre as RSSF ea Internet foi uma evoluo natural. Entretanto, o uso dos protocolos da Internet (arqui-tetura TCP/IP), sem modificaes, impraticvel nos dispositivos com recursos limita-dos, os quais so comuns na IoT. Para alcanar as demandas da IoT por escalabilidadee robustez, a experincia em RSSF mostra que so necessrios algoritmos e protocolosespecializados como, por exemplo, protocolos que viabilizem processamento ao longoda rede (in-network processing) [Santos et al. 2015b, Fasolo et al. 2007] para mitigar asrestries impostas pelos dispositivos e prover escalabilidade e eficincia. Por outro lado,a arquitetura fim-a-fim da Internet no foi planejada para essas exigncias (e.g., dezenasde milhares de dispositivos em uma nica sub-rede e limitaes de energia). Portanto, talarquitetura necessita de ajustes para comportar essas novas demandas.

As RSSF e sua evoluo, a IoT, cresceram em um ambiente com maior liber-dade de desenvolvimento do que a Internet como, por exemplo, a questo de compatibili-dade. Diante desta autonomia diversas ideias surgiram tanto do ponto de vista de softwarequanto de hardware. Entretanto, muitas dessas ideias no avanaram, pois no eram com-pletamente interoperveis com a arquitetura TCP/IP da Internet. Essas novas ideias, queno empregam a arquitetura da Internet, foram obrigadas a usar um gateway para trocarinformaes entre os objetos inteligentes e elementos na Internet. A implementao deum gateway , em geral, complexa e o seu gerenciamento complicado, pois alm derealizarem funes de traduo, devem tratar da semntica de servios para a camada deaplicao. A complexidade destas funes torna o gateway um gargalo para a IoT em doissentidos. No primeiro, toda informao de e para a rede de objetos inteligentes transitaatravs do gateway. No segundo, a lgica de operao da Internet diz que a intelignciado sistema deve ficar nas pontas [Saltzer et al. 1984], porm com o emprego dos gatewaysa inteligncia da IoT fica no meio da rede, o que contradiz com os princpios da arquite-tura 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 baixapotncia (Low-Power and Lossy Networks (LLN)) relacionadas a seguir:

6LoWPAN: o IPv6 in Low-Power Wireless Personal Area Networks Working Group ficouresponsvel por padronizar o Internet Protocol version 6 (IPv6) para redes que fazemuso de rdios sobre o padro IEEE 802.15.4 que, por sua vez, especifica as regras dascamada mais baixas (enlace e fsica) para redes sem fio pessoais de baixas potncia detransmisso.

RoLL: o Routing over Low-Power and Lossy Links Working Group ficou responsvel porpadronizar o protocolo de roteamento que utilizar o IPv6 em dispositivos com limitaesde recursos. O grupo j definiu o protocolo: IPv6 Routing Protocol for Low-Power andLossy Networks (RPL). Esse protocolo representa o estado-da-arte em roteamento paraIoT, o qual constri uma topologia robusta para comunicao na Internet das Coisas. ORPL ser objeto de discusso mais adiante.

1.3.2. Arquitetura para IoT

Para conectar bilhes de objetos inteligentes Internet, deve-se ter uma arquiteturaflexvel. Na literatura, temos uma variedade de propostas de arquiteturas sofisticadas, quese baseiam nas necessidades da academia e indstria [Al-Fuqaha et al. 2015]. O modelobsico de arquitetura apresenta trs camadas, como ilustrado na Figura 1.5. A primeiracamada a de objetos inteligentes ou camada de percepo. Esta camada representa osobjetos fsicos, os quais utilizam sensores para coletarem e processarem informaes.Na camada de rede, as abstraes das tecnologias de comunicao, servios de gerenci-amento, roteamento e identificao devem ser realizados. Logo acima, encontra-se a ca-mada de aplicao, a qual responsvel por prover servios para os clientes. Por exemplo,uma aplicao solicita medies de temperatura e umidade para clientes que requisitamestas informaes.

1.3.3. IP para IoT

Camada de Rede

Camada de Percepo

Camada de Aplicao

Figura 1.5. Arquitetura para IoT

O protocolo IPv4 foi o padro utilizadopara enderear os dispositivos em rede e criara cola da Internet, i.e., para estar conectado Internet era necessrio ter o protocolo IP. Noentanto, no se imaginou que a Internet cresce-ria e poderia ter dezenas de milhares de pontosfinais em uma nica sub-rede, tal como agora previsto para a IoT (veja Seo 1.1). O cresci-mento da rede mundial de computadores levouao esgotamento de endereos IPv4 disponveis.Isto mostrou que o IPv4 no era escalvel o su-ficiente para atender a demanda da IoT.

O IPv6 uma abordagem mais eficazpara solucionar a escassez de endereos IPv4. Os 32 bits alocados originalmente para oprotocolo IPv4 foram expandidos para 128 bits, aumentando imensamente a quantidadede dispositivos endereveis na Internet. Na IoT, os elementos da rede so endereadosunicamente usando o IPv6 e, geralmente, tm o objetivo de enviar pequenas quantida-des de dados obtidos pelos dispositivos. Contudo, o IPv6 tem um tamanho de pacotemaior que o tamanho do quadro dos protocolos usados pelos dispositivos na IoT (o pa-cote IPv6 transmitido dentro da rea de dados do quadro do protocolo de acesso aomeio). Por exemplo, o padro IEEE 802.15.4, usado para acesso ao meio fsico de co-municao, limita os pacotes a 128 bytes. Para resolver esse problema, a IETF criou o6LoWPAN [Kushalnagar et al. 2007].

6LoWPAN9 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-hc10), 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

9https://tools.ietf.org/html/rfc491910https://tools.ietf.org/html/draft-ietf-6lowpan-hc-15

https://tools.ietf.org/html/rfc4919https://tools.ietf.org/html/draft-ietf-6lowpan-hc-15

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 Dunkels11 realizou uma srie de contribuies na rea daInternet das Coisas. Trs de suas principais contribuies so as implementaes da pilhaTCP/IP para dispositivos de baixa potncia. Estas implementaes so conhecidas comolow 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-dos12. A lwIP possui mais recursos do que a pilha IP, discutida a seguir. Porm, alwIP pode prover uma vazo maior. Atualmente esta pilha de protocolos mantida pordesenvolvedores espalhados pelo mundo13. A lwIP utilizada por vrios fabricantes desistemas embarcados como, por exemplo, Xilinx e Altera. lwIP conta com os seguintesprotocolos: IP, ICMP, UDP, TCP, IGMP, ARP, PPPoS, PPPoE. As aplicaes includasso: servidor HTTP, cliente DHCP, cliente DNS, ping, cliente SMTP e outros.

O IP (Micro IP) uma das menores pilhas TCP/IP existentes14. Desenvolvidapara pequenos microcontroladores (processadores de 8 ou 16 bits), onde o tamanho docdigo e memria RAM disponvel so escassos, IP precisa de no mximo 5 kilobytesde espao de cdigo e de poucas centenas de bytes de RAM. Atualmente, o IP foiportado para vrios sistemas15 e integra o Contiki.

1.3.4. Modelos de conectividade em redes de objetos inteligentes

Nesta seo, sero abordados os modelos de conectividade para uma rede IPv6 deobjetos inteligentes. Os modelos de conectividade sero classificados como um espectroque varia de uma rede de objetos inteligentes autnoma sem conexo com a Internet ata autntica Internet of Things, na qual os objetos possuem acesso Internet efetiva-mente. 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 mode-los de conectividade de grande importncia, pois estes dois quesitos sero as chaves paraconstruir novas aplicaes para a IoT. A Figura 1.6 destaca trs modelos de conectividadede uma rede de objetos inteligentes. A seguir, sero discutidos cada um dos modelos deconectividade: Rede autnoma de objetos inteligentes: neste modelo a rede de obje-tos no possui conexo com a Internet pblica. Existem diversos casos de uso paraeste modelo como, por exemplo, em uma rede de automao industrial (e.g., usina nu-clear). Pode-se requerer uma rede de objetos conectados entre si, porm completamenteinacessvel externamente, ou seja, o uso da rede estritamente interno da corporao. AFigura 1.6 (I) apresenta uma abordam esquemtica do modelo.

Uma questo que pode ser levantada aqui : Neste modelo de conectividade necessrio que os objetos inteligentes sejam endereados com IP? Para responder a estaquesto preciso refletir sobre a experincia passada com o IP em redes convencionais.O IP apresenta diversas caractersticas que indicam um sim como resposta. Por exemplo,

11http://www.dunkels.com/adam/12http://www.ece.ualberta.ca/~cmpe401/docs/lwip.pdf13http://savannah.nongnu.org/projects/lwip/14https://github.com/adamdunkels/uip15http://www.dunkels.com/adam/software.html

http://www.dunkels.com/adam/http://www.ece.ualberta.ca/~cmpe401/docs/lwip.pdfhttp://savannah.nongnu.org/projects/lwip/https://github.com/adamdunkels/uiphttp://www.dunkels.com/adam/software.html

Internet

(I)

(II)

(III)

Sem conexocom a Internet

Total acesso pela conexocom a Internet

Acesso limitadoatravs da Internet

(I) (II) (III)

Servidor

Conexo

Roteador

Servidor

Conexo

Objeto

Internet

Servios em nuvem para IoT

Internet

Proxy: Servidor Roteador/Servidor

Firewall

Conexo confivel: Via servidor Direto ao objeto

inteligente

Roteador

Figura 1.6. Modelos de conectividade dos objetos inteligentes. (I)Rede autnoma na qual os objetos inteligentes no possuem cone-xo com a Internet; (II) Rede de objetos inteligentes limitada, poiso acesso aos dispositivos restrito; (III) IoT autntica na qual osobjetos esto conectados Internet

a arquitetura TCP/IP interopervel, no sentido de que ela opera sobre as camadas deenlace e fsica com diferentes caractersticas. Outro argumento a favor do sim, queo IP verstil e evolutivo, pois a arquitetura baseada no princpio fim-a-fim, em quea inteligncia da rede (aplicaes) residem nos pontos finais, enquanto a rede mantidasimples (somente encaminhando pacotes). Isto permitiu a evoluo contnua do protocoloao longo do tempo. Tendo dito isto, vlido alegar que ao usar IP neste modelo, eos demais apresentados a seguir, a rede manter compatibilidade com a arquitetura daInternet e estar de acordo com as tendncias regidas pelos grupos RoLL e 6LoWPAN.

Internet estendida: o termo Internet estendida refere-se ao posicionamento centraldeste modelo de conectividade em relao rede de objetos autnomos e a autnticaIoT. Em outras palavras, este modelo apresenta as redes de objetos inteligentes parci-almente ou completamente conectadas Internet, porm com requisitos apropriados deproteo e segurana [Vasseur and Dunkels 2010]. Aplicaes para Cidades Inteligentes(Smart Cities) so exemplos desse modelo de conectividade. Essas aplicaes produzi-ro informaes teis para seus habitantes terem uma melhor qualidade de vida e tomardecises importantes diariamente. Para viabilizar as cidades inteligentes, pode-se usar omodelo apresentado na Figura 1.6 (II), em que o acesso rede de objetos se d via fi-rewall e proxy, os quais possuem a tarefa de controle de acesso seguro s redes privadasde objetos inteligentes. Deste modo, o modelo de conectividade estende a Internet porpermitir o acesso aos objetos inteligentes que at ento estavam isolados.

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

delo de rede autnoma de objetos. Na IoT, os objetos inteligentes esto verdadeiramenteconectados Internet. Deste modo, os objetos podem prover servios tais como quais-quer outros dispositivos na Internet, por exemplo, um objeto inteligente pode ser umservidor Web. Qualquer usurio da Internet, seja humano ou mquina, poder ter acessoaos recursos dos objetos inteligentes. Como mostrado na Figura 1.6 (III), o acesso se dconectando-se diretamente com o objeto ou atravs de um proxy16. Estes servidores po-dem estar localizados dentro ou fora da sub-rede de objetos inteligentes e possuem a tarefade coletar informaes dos dispositivos. Ao usar o proxy tem-se que a Internet conectao usurio ao servidor proxy, o qual est conectado aos dispositivos. Assim, tcnicas deprocessamento dentro da rede (in-networking processing) podem ser utilizadas, na redeentre 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) Muitos- para-Um (b) Um-para-Muitos (c) Mescla de (a) e (b) (d) Um-para-Um

Figura 1.7. Paradigmas de comunicao

A IoT uma evoluo e combinao de diversas tecnologias como discutido naSeo 1.1. Neste sentido, h interseo entre RSSF e IoT no que tange os paradigmas decomunicao. Esta seo aborda tais paradigmas, classificando-os em quatro categoriascomo mostrado na Figura 1.7. Os paradigmas diferem significativamente, sendo assim omodo 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 protocoloque o implementa:

Muitos-para-Um (Many-to-One): os objetos inteligentes reportam informaes, as quaisso coletadas por estaes base (raiz na Figura 1.7). Este paradigma conhecido comocoleta de dados, sendo o mais comum dos paradigmas, visto que atende s demandas decomunicao de muitas aplicaes. Para realizar a coleta de dados, cria-se uma rvore deroteamento com raiz nas estaes base. Em geral, este paradigma no acarreta em grandeconsumo de memria e energia. Entretanto, aplicaes que necessitam de confirmaode entrega de dados so inviabilizadas, pois no existem rotas reversas entre a raiz e osobjetos na rede;

16Um proxy um servidor (sistema de computador ou uma aplicao) que age como um intermediriopara requisies de clientes solicitando recursos de outros servidores

O exemplo que ilustra o estado-da-arte deste paradigma 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 rotasde alta qualidade e manter tais rotas a baixo custo.

Um-para-Muitos (One-to-Many): conhecido como disseminao de dados, o qual tema caracterstica reversa do paradigma de coleta de dados. Na disseminao de dados, asestaes base comumente enviam comandos para um ou vrios objetos da rede. O intuito,em geral, reconfigurar ou modificar parmetros dos dispositivos na rede. Para realizara disseminao de dados pode-se, por exemplo, efetuar inundaes na rede para alcanaros dispositivos alvo. Entretanto, no possvel confirmar se os dados enviados foramentregues tal como ocorre com o CTP para a coleta de dados. O custo em nmero demensagens tambm pode ser alto, caso sejam realizadas diversas inundaes na rede.

Deluge um exemplo de protocolo de disseminao [Chlipala et al. 2004]. Oprotocolo otimizado para disseminao para grandes quantidades de dados e faz issoutilizando a mtrica ETX para encontrar rotas de alta qualidade;

Um-para-Muitos e vice-versa (One-to-Many and Many-to-One): um paradigma quecombina os dois anteriormente apresentados. Nesta abordagem, os objetos inteligentespodem se comunicar com as estaes base e vice-versa. Isto amplia a gama de aplicaesantes no possveis, tal como protocolos de transporte confiveis. Entretanto, o paradigmanecessita de memria adicional para manter as rotas bi-direcionais.

O eXtend Collection Tree Protocol (XCTP) [Santos et al. 2015a] um exemplodesta categoria. Os autores argumentam que o XCTP uma extenso do CTP e, poresse motivo, mantm todas as caractersticas do CTP ao mesmo tempo que o estende aoviabilizar rotas reversas entre a raiz e os elementos da rede.

Um-para-um (Any-to-Any): esse paradigma o mais geral possvel, pois permite quequaisquer dois objetos inteligentes da rede se comuniquem. Por ser mais abrangente,esta abordagem a mais complexa e, geralmente, exige maior quantidade de recursos,principalmente de armazenamento, pois se faz necessrio manter rotas para todos os dis-positivos alcanveis na rede. Por outro lado, no apresenta restries significativas paraas aplicaes, exceto se os recursos computacionais dos dispositivos forem bastante limi-tados.

O principal protocolo de roteamento da Internet das Coisas reside nesta categoria.O protocolo RPL, descrito em detalhes a seguir, flexvel o suficiente para permitir ro-tas um-para-um, alm de possibilitar que elementos de rede com diferentes capacidadessejam empregados para otimizar o armazenamento das rotas. Ainda existe um modo deoperao em que, o RPL, opera sob o paradigma muitos-para-um, sendo portanto, umprotocolo 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 deroteamento para LLNs, projetado e padronizado pelo ROLL Working Group in the IETF,sendo o protocolo padro que utiliza IPv6 para LLNs.

1.3.6.1. Grafo Acclico Direcionado

Rank = 0

Rank = 1Rank = 1

Rank = 2

Rank = 3Rank = 3

Figura 1.8. DODAG RPL

Dispositivos de rede executando RPL es-to conectados de maneira acclica. Assim, umGrafo Acclico Direcionado Orientado ao Destino(DODAG, do ingls Destination-Oriented DirectedAcyclic Graph) criado, como mostra a Figura 1.8.Cada n mantm a melhor rota para a raiz do DO-DAG. Para encontrar a melhor rota os ns usamuma funo objetivo (OF) que define a mtrica deroteamento (e.g., ETX da rota [Javaid et al. 2009])a ser computada.

O RPL utiliza quatro tipos de mensagens decontrole, descritas abaixo, para manter e atualizaras rotas. O processo de roteamento inicia pela cons-truo do DAG. A raiz anuncia informaes sobre seu DODAG (de um nico n) paratodos vizinhos alcanveis. Em cada nvel da rvore de roteamento, os ns tomam deci-ses sobre rotas baseadas na OF. Uma vez que o n se junta ao DODAG, ele escolhe umaraiz como seu pai e calcula seu rank, que uma mtrica que indica as coordenadas do nna hierarquia da rede [Vasseur et al. 2011]. Os demais ns iro repetir esse processo deseleo do pai e notificao das informaes do DODAG para possveis novos dispositi-vos. Quando esse processo se estabiliza, o roteamento de dados pode ento comear. Oprocesso descrito cria rotas ascendentes (dos ns para uma raiz). Para construir as rotasdescendentes 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 deste tipo so utilizadas para anunciar um DODAG e suas caracters-ticas. Assim, elas so usadas para a descoberta de DODAGs, sua formao e manuten-o. O intervalo de envio de DIO controlado de modo eficiente pelo algoritmo Tric-kle [Levis et al. 2004].

DIS: esse tipo de mensagem similar a mensagens de solicitao de rotas (RS) do IPv6, eso usadas para descobrir DODAGs na vizinhana e solicitar DIOs de ns vizinhos, sempossuir 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 dereceber mensagens para seus pais preferenciais) para propagar informaes de destino aolongo do DODAG. Essas informaes so utilizadas para o preenchimento das tabelasde 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 mensagensDAO propagadas como unicast por meio dos pais em direo raiz. Essas mensagenscontm informaes sobre quais prefixos pertencem a qual roteador RPL e quais prefixospodem ser alcanados atravs de qual roteador RPL. O protocolo especifica dois modosde operao para o roteamento descendente: storing e non-storing. Ambos os modos re-querem a gerao de mensagens DAO, que so enviadas e utilizadas de maneira diferenteem cada modo de operao. Os dois modos de operao so descritos a seguir.

Modo storing: Neste modo, cada roteador RPL deve armazenar rotas para seus destinosem um DODAG. Essas informaes so repassadas dos ns para seus pais preferenci-ais. Isso faz com que, em ns mais prximos da raiz, o armazenamento necessrio sejadefinido pelo nmero de destinos na rede. Com isso, a memria necessria em um nprximo raiz e um outro distante da raiz pode variar drasticamente, o que faz com quealgum tipo de implementao e manuteno administrativa contnua nos dispositivos se-jam necessrias, conforme a rede evolui [Clausen et al. 2013]. Entretanto, tal interveno invivel, devido ao perfil dinmico da rede.

Modo non-storing: Neste modo, cada n gera e envia mensagens DAO para a raiz doDODAG. O intervalo no qual o DAO enviado varia de acordo com a implementao.Entretanto, a especificao do protocolo sugere que esse intervalo seja inversamente pro-porcional distncia do n a raiz. Assim, um n folha gera mais mensagens que um nintermedirio. Aps coletar toda informao necessria, a raiz agrega essa informao.Se precisar enviar uma mensagem descendente na rede, a raiz deve utilizar um cabealhoIPv6 para roteamento de origem (source routing). Dessa forma, os ns encaminham amensagem at que ela alcance seu destino [Tsvetko 2011]. Ou seja, caso os ns no pos-suam capacidade de armazenamento para operarem no modo storing, a rede sofre maiorrisco de fragmentao e, portanto, perda de pacotes de dados, consumindo a capacidadeda rede com o roteamento de origem [Clausen et al. 2013].

1.3.7. Protocolos da camada de aplicaes para IoT

O protocolo HTTP usado na Internet para acessar informaes seguindo a estra-tgia requisio/resposta no paradigma cliente/servidor. O HTTP foi desenvolvido pararedes com computadores tipo PC. Diferentemente dos PCs, os dispositivos usados na IoTpossuem poder computacional restrito, o que limita a utilizao do protocolo HTTP nesseselementos. Para resolver esse problema, foram desenvolvidos dois protocolos da camadade aplicao especificamente para recuperar informaes de dispositivos com baixo podercomputacional: CoAP e MQTT.

O Constrained Application Protocol (CoAP) definido e mantido pelo IETFConstrained RESTful Environments (CoRE) working group17. O CoAP define uma formade 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 acessem ou consumam servios Webde maneira fcil usando Uniform Resource Identifiers (URIs). O CoAP diferente do

17https://datatracker.ietf.org/doc/charter-ietf-core/

https://datatracker.ietf.org/doc/charter-ietf-core/

Cliente Servidor

NON [0x01a0]

Cliente Servidor

CON [0x7d34]

ACK [0x7d34]

Cliente Servidor

CON [0xbc90]GET /temperature

ACK [0xbc90]2.05 Content"22.5 C"

Cliente Servidor

ACK [0xbc91]4.04 Not Found"Not found"

Cliente ServidorCON [0xbc90]GET /temperature

ACK [0xbc90]2.05 Content"22.5 C"

ACK [0xbc90]

Algum tempo depois

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

CON [0xbc90]GET /temperature

Figura 1.9. Tipos de mensagem do CoAP

REST por usar o protocolo UDP, o que o coloca como mais adequado para aplicaes emIoT.

O CoAP apresenta duas camadas em sua arquitetura interna, permitindo que dis-positivos de baixa potncia possam interagir atravs de RESTfull. A primeira camadaimplementa os mecanismos de requisio/resposta. A segunda, detecta mensagens du-plicadas e fornece comunicao confivel sobre o UDP. O CoAP utiliza quatro tipos demensagens (Figura 1.9): confirmable, non-confirmable, reset e acknowledgement. A con-fiabilidade do protocolo CoAP conseguida ao combinar as mensagens confirmable enon-confirmable sobre o UDP.

As URIs CoAP so utilizadas da seguinte forma coap://URI. Para facilitar oacesso aos recursos, existem algumas extenses que so utilizadas para integrar o CoAPaos browsers, por exemplo, a Copper para Firefox. Outras informaes podem ser encon-tradas na RFC 725218 e o conjunto de implementaes existentes podem ser encontradasno site de um dos autores do CoAP19.

Subscribe(tpico)

Publish (tpico, info)

Publish (tpico, info)

Publisher Broker Subscriber

Figura 1.10. publish/subscribe

O Message Queue Telemetry Trans-port(MQTT) um protocolo projetado para dis-positivos extremamente limitados e utiliza aestratgia de publish/subscribe para transferirmensagens. O principal objetivo do MQTT minimizar o uso de largura de banda da rede erecursos dos dispositivos. Alm disso, o MQTTprov mecanismos para a garantia de entrega demensagens. MQTT utiliza os protocolos das ca-mada de transporte e rede da arquitetura TCP/IP.O cabealho do protocolo MQTT pode ter tama-nho fixo (dois bytes) ou varivel. Um exemplo de uma implementao open source doMQTT o Mosquitto20.

O MQTT consiste de trs componentes bsicos: o subscriber, o publisher e obroker. A Figura 1.10 mostra a ordem de operao do MQTT. Inicialmente dispositivos

18https://tools.ietf.org/html/rfc725219http://coap.technology20http://mosquitto.org

https://tools.ietf.org/html/rfc7252http://coap.technologyhttp://mosquitto.org

se registram (subscribe) a um broker para obter informaes sobre dados especficos,para que o broker os avise sempre que publicadores (publishers) publicarem os dadosde interesse. Os dispositivos inteligentes (publishers) transmitem informaes para ossubscriber atravs do broker.

1.3.8. Ambientes de desenvolvimento

Assim como softwares para computadores de propsito geral, o software que exe-cuta no microcontrolador dentro de um objeto inteligente tambm escrito em uma lin-guagem 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 cdigo executado [Vasseur and Dunkels 2010].

1.3.8.1. Sistemas Operacionais

Assim como os PCs, os objetos inteligentes tambm utilizam sistemas operaci-onais. Entretanto, como os objetos inteligentes possuem recursos fsicos limitados, osSOs para esses objetos devem ser muito menores e consumir menos recursos. Esta seodescreve brevemente os dois principais sistemas operacionais para objetos inteligentes:Contiki e TinyOS, alm do sistema operacional Android que opera em grande parte dossmartphones e algumas variaes do sistema Linux orientadas IoT. Todos esses siste-mas operacionais so de cdigo aberto. Ao final desta seo, a Tabela 1.2 apresenta umacomparao entre os principais sistemas apresentados.

Contiki 21: um SO leve para sistemas embarcados de rede, que fornece mecanismospara o desenvolvimento de softwares para IoT e mecanismos de comunicao que permi-tem a comunicao dos dispositivos inteligentes. Alm disso, o Contiki tambm fornecebibliotecas para a alocao de memria, abstraes de comunicao e mecanismos de re-des de rdios de baixa potncia. O Contiki foi o primeiro SO para objetos inteligentesa fornecer comunicao IP com a pilha IP TCP/IP e, em 2008, o sistema incorporou oIPv6, a menor pilha IPv6. Por utilizar IP, o Contiki pode se comunicar diretamente comoutros aplicativos baseados em IP e servios Wweb [Vasseur and Dunkels 2010]. Tantoo sistema operacional quanto suas aplicaes so implementados na linguagem C, o quefaz o sistema ser altamente portvel [Dunkels et al. 2004].

TinyOS22: Assim como o Contiki, o TinyOS um SO para redes de sensores e objetosinteligentes. Um programa do TinyOS descrito em [Levis et al. 2005] como um grafo decomponentes, cada um sendo uma entidade computacional independente que expe umaou mais interfaces. Os componentes podem ser chamados comandos (requisies a umcomponente para executar algum servio), eventos (sinalizam a finalizao desse servio)ou tarefas (usadas para expressar a concorrncia intra-componente). TinyOS possui ummodelo de programao baseado em componentes, codificado pela linguagem NesC, umdialeto da linguagem C. O modelo de programao fornecido em NesC se baseia emcomponentes que encapsulam um conjunto especfico de servios, e se comunicam pormeio de interfaces.

21https://github.com/contiki-os22https://github.com/tinyos

https://github.com/contiki-oshttps://github.com/tinyos

Sistema Min. RAM Min. ROM Linguagem

Contiki < 2 KB < 30 KB CTinyOS < 1 KB < 4 KB nesC e oTclRIOT 1.5 KB 5 KB C e C++Snappy 128 MB Python, C/C++, Node JS e outrasRaspbian 256 MB Python, C/C++, Node JS e outras

Tabela 1.2. Comparativo entre os principais SOs para IoT

Android23: uma plataforma para dispositivos mveis que inclui um SO, middlewaree aplicativos24. Os vrios componentes do SO so projetados como uma pilha, com oncleo do Linux na camada mais baixa. Acima da camada do Linux, esto as bibliotecasnativas do Android, o que permite ao dispositivo manusear diferentes tipos de dados. Namesma camada das bibliotecas est o Android Runtime, que possui um tipo de mquinavirtual Java utilizada para a execuo de aplicativos no dispositivo Android. A prximacamada est relacionada com o framework de aplicao, que fornece vrios servios dealto nvel ou APIs para os desenvolvedores de aplicativos. Por fim, no topo da pilha, esta camada de aplicao.

Linux: com a popularizao da IoT, alguns SOs baseados em Linux foram desenvolvidos.o RIOT 25 26 foi desenvolvido por uma comunidade formada por empresas, acadmicose amadores, distribudos em todo o mundo. Essa plataforma executa em 8, 16 ou 32bits e possui suporte s linguagens C e C++. Alm disso, possui suporte para IoT comimplementaes 6LoWPAN, IPv6, RPL, e UDP. O Ubuntu tambm possui sua versoIoT, chamada Ubuntu Core ou Snappy 27. Essa verso reduzida em comparao aoUbuntu desktop, uma vez que exige apenas 128 MB de memria RAM e um processadorde 600 MHz. O desenvolvimento pode ser feito em diversas linguagens, como o de umaaplicao Linux comum. Raspian 28 um SO baseado no Debian e otimizado para ohardware do Raspberry Pi. Oferece mais de 35 mil pacotes deb de software, que esto pr-compilados, para serem facilmente instalados no Raspberry Pi. O sistema est disponvelem 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 arquite-turas e protocolos para redes em geral. Esses ambientes de desenvolvimento permitemmodelar uma rede de computadores arbitrria, especificando o comportamento dos ele-mentos da rede, bem como os enlaces de comunicao. Esta seo apresenta os principais

23O Android disponibilizado sob licena de cdigo aberto, apesar da maior parte dos dispositivosapresentarem uma combinao de software livre e privado: https://github.com/android

24http://developer.android.com/guide/basics/what-is-android25http://www.riot-os.org/26https://github.com/RIOT-OS/RIOT27http://www.ubuntu.com/internet-of-things28https://www.raspbian.org/

https://github.com/androidhttp://developer.android.com/guide/basics/what-is-androidhttp://www.riot-os.org/https://github.com/RIOT-OS/RIOThttp://www.ubuntu.com/internet-of-thingshttps://www.raspbian.org/

simuladores e emuladores de redes de computadores que possuem suporte para IoT.

Essencialmente, h diferenas entre os emuladores e simuladores como desta-cado em [Bagula and Erasmus 2015]. Emulador um sistema de hardware e/ou softwareque permite a um sistema de computador (chamado de host) se comportar como um outrosistema de computador (chamado de guest). Em outras palavras, o emulador se com-porta exatamente como o guest permitindo ao host executar um software projetado parao sistema guest. Por exemplo, o emulador Cooja do Contiki permite a um computadorse comportar como um dispositivo inteligente Tmote Sky29. J o simulador, por sua vez, modela (imita) uma situao da real ou hipottica em um computador. Com a simu-lao possvel estudar como o sistema simulado deve operar, caso o modelo reflita ascaractersticas do mundo real.

A seguir, so apresentadas algumas dessas plataformas.

Cooja: um emulador de aplicaes do sistema operacional Contiki, desenvolvido nalinguagem Java (Cooja Contiki OS Java). As simulaes no Cooja consistem em cen-rios onde cada n possui um tipo, memria e um nmero de interfaces [sterlind ]. Umn no Cooja um sistema Contiki real compilado e executado. Esse sistema controladoe analisado pelo Cooja 30, que possui uma interface para analisar e interagir com os ns,o que facilita o trabalho e a visualizao da rede. Alm disso, possvel criar cenriospersonalizados.

ns-2/ns-3: Ns-2 um simulador de eventos discretos para rede de computadores de c-digo aberto. As simulaes para ns-2 so compostas por cdigo em C++ e scrips oTcl. Ocdigo utilizado para modelar o comportamento dos ns, enquanto os scripts controlama simulao e especificam aspectos adicionais, como a topologia da rede. O ns-3 tambm um simulador de eventos discretos, mas no uma extenso 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 simulaes podem ser implementadas emC++, com partes opcionais implementadas usando Python [Weingrtner et al. 2009].

Tossim: o simulador de eventos discretos do SO TinyOS. Ao invs de compilar umaaplicao TinyOS para um n sensor, os usurios podem compil-lo para o TOSSIM, que executado em um PC. No Tossim possvel simular milhares de ns, cada n, na simula-o, executa o mesmo programa TinyOS. O simulador se concentra em simular o TinyOSe sua execuo, ao invs de simular o mundo real. Por isso, apesar de poder ser usadopara entender as causas do comportamento observado no mundo real, no capaz de cap-turar todos eles e pode no ser o mais fidedigno para avaliaes [Levis and Lee 2010]. Naabstrao do Tossim, a rede um grafo orientado no qual cada vrtice um n e cadaaresta (enlace) tem uma probabilidade de erro de bit. O simulador fornece um conjuntode servios que permitem interao com aplicativos externos [Levis et al. 2003].

OMNet++/Castalia: um simulador de eventos discretos para modelar re-des de comunicao, multiprocessadores e outros sistemas distribudos ou parale-los [Varga and Hornig 2008]. O OMNet++ fornece o ferramental para criar simulaes

29http://www.eecs.harvard.edu/~konrad/projects/shimmer/references/tmote-sky-datasheet.pdf

30https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja

http://www.eecs.harvard.edu/~konrad/projects/shimmer/references/tmote-sky-datasheet.pdfhttp://www.eecs.harvard.edu/~konrad/projects/shimmer/references/tmote-sky-datasheet.pdfhttps://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja

Nome Suporte GUI Licena Linguagem Sistema Operacional

Cooja Sim Cdigo aberto C Linux

ns-2 No Cdigo aberto C++ e oTclGNU/Linux, FreeBSD,Mac OS e Windows

ns-3 Limitado Cdigo aberto C++ e pythonGNU/Linux, FreeBSD,Mac OS e Windows

Tossim Limitado Cdigo aberto nesC e pythonLinux ou Cygwin noWindows

OMNet++ Sim Comercial e cdigo aberto C++Linux, Mac OSe Windows

Castalia Sim Cdigo aberto C++ Linux e Windows

Sinalgo Sim Cdigo aberto JavaLinux, Mac OSe Windows

Tabela 1.3. Comparativo entre os principais simuladores/emulado-res para IoT

de diferentes tipos de redes, tendo uma IDE baseada no Eclipse, um ambiente de execu-o grfica e outras funcionalidades. Existem extenses para simulao em tempo real,emulao de rede, integrao de banco de dados, integrao de sistemas, entre outrasfunes [Varga et al. 2001]. Castalia um simulador para RSSFs e outras redes de dispo-sitivos embarcados de baixa potncia. Ele baseado na plataforma do OMNeT++ e podeser usado para pesquisas e desenvolvimento que requerem testar algoritmos distribudose/ou protocolos em modelos realistas de canais sem fio e rdio [Boulis et al. 2011].

Sinalgo: um framework para avaliar algoritmos em rede (Sinalgo (Simulator forNetwork Algorithms)), abstraindo a pilha de protocolos de comunicao entre os elemen-tos computacionais. Assim, o Sinalgo foca no comportamento de algoritmos em rede.Apesar de ter sido desenvolvido para simulao de redes sem fio, pode ser usado pararedes com fio. O Sinalgo utiliza a linguagem JAVA, o que torna o desenvolvimento maisfcil e rpido, alm de facilitar o processo de depurao31.

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 que permitem a experimentao mais rpida. A lista,a seguir, apresenta os principais testbeds para a experimentao em IoT.

WHY-NET: um testbed escalvel para redes sem fio mveis. Possui diferentes tecnolo-gias sem fio como Redes de Sensores e Antenas inteligentes [Patel and Rutvij H. 2015].

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

31http://dcg.ethz.ch/projects/sinalgo/

http://dcg.ethz.ch/projects/sinalgo/

MiNT: neste testbed, o n de rdio IEEE 802.11 conectado a cada rob de con-trole remoto. Para evitar fontes de rudo, o testbed configurado em uma nica salade laboratrio. MiNT suporta reconfigurao de topologia e mobilidade irrestrita don [Patel and Rutvij H. 2015].

IoT-LAB: oferece uma infraestrutura de grande escala adequada para testar pequenosdispositivos sensores sem fios e comunicao de objetos heterogneos. Tambm ofereceferramentas Web para desenvolvimento de aplicaes, juntamente com o acesso de linhade comando direto plataforma. Firmwares de ns sensores podem ser construdas a par-tir da fonte e implantado em ns reservados. A atividade de aplicao pode ser controladae monitorada, o consumo de energia e interferncia de rdio podem ser medidos usandoas ferramentas fornecidas32.

Indriya: um testbed de rede de sensores sem fio, que possui 127 motes TelosB. Maisde 50% dos motes so equipados com diferentes mdulos de sensores, incluindo infraver-melho passivo (PIR), magnetmetro e acelermetro. Indriya usa o software de interfacedo usurio do Motelab, que fornece acesso baseado na Web para os ns do testbed, queest localizado na Universidade Nacional de Singapura [Doddavenkatappa et al. 2012].

1.3.9. Gateway

Na IoT, comum que os dispositivos apresentem tecnologias de comunicaoheterogneas, por exemplo BLE, ZigBee, e outros. Para conectar esses dispositivos In-ternet, preciso que um elemento de rede realize a traduo entre os diversas tecnologiasutilizadas, este elemento chamado de gateway. Na Figura 1.11 so apresentadas duasvises possveis do gateway. Na parte superior da figura, o gateway realiza a traduo detecnologias distintas e o encaminhamento de mensagens. Neste caso, o gateway respeitao princpio fim-a-fim, porm a complexidade de hardware/software e gerenciamento au-mentam. Por exemplo, o gateway precisa implementar todas as interfaces de comunicaoda sub-rede IoT, bem como a interface que o conecta Internet. Alm disso, preciso umsoftware para controlar e gerenciar as regras de operao da rede.

O gateway tambm pode ser visto como um prestador de servios da rede. Umexemplo pode ser identificado na parte inferior da Figura 1.11. Nesse caso, o gatewayfunciona como um proxy, realizando compresso transparente para que aplicaes queutilizem protocolo IP no necessitem de modificaes. Um local tpico para alocao deum proxy seria no gateway, ou em um servidor proxy local [Shelby and Bormann 2011].

1.3.10. Segurana

Para que um sistema IoT seja seguro preciso estabelecer quais so os objetivosde segurana desejveis. Existem pelo menos trs grupos de objetivos desejveis parasegurana em IoT [Shelby and Bormann 2011]: (i) confidencialidade requisito onde osdados transmitidos podem ser escutados e entendidos por elementos participantes dacomunicao, isto , elementos sem autorizao sabem que ocorreu comunicao, masno sabem o contedo da comunicao; (ii) integridade os dados no podem ser alte-rados por elementos da rede sem devida autorizao. comum que hackers adulteremmensagens sem deixar vestgios e a quebra da integridade passe despercebida. De modo

32https://www.iot-lab.info

https://www.iot-lab.info

Figura 1.11. Pilha de protocolos de um gateway: Comunicao fim-a-fim (superior); Comunicao atravs de um proxy (inferior)

geral, implementa-se integridade criptografando as mensagens e verificando-as no lado doreceptor; (iii) disponibilidade deseja-se manter o sistema sempre disponvel e seguroscontra ataques maliciosos. Entretanto, as redes sem fio esto sujeitas a interferncias decomunicao e hackers podem agir nesta vulnerabilidade. Assim, o sistema IoT deveser 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 utili-zado nos protocolos da Internet33. Assume-se que o hacker possui controle sobre a redepodendo ler, alterar ou remover qualquer mensagem na rede. Portanto, sem o suporte criptografia torna-se invivel proteger ou detectar adulteraes indevidas no sistema. Osuporte segurana pode ser implementado em diferentes camadas da pilha de protoco-los. Por exemplo, na camada de enlace pode-se aplicar o algoritmo Advanced EncryptionStandard (AES) em conjunto com Counter with CBC-MAC (CCM)34 para manter con-fidencialidade a cada salto na rota entre os comunicantes. Entretanto, esta tcnica nooferece qualquer segurana sobre a integridade dos dados. Por outro lado, na camadade rede pode-se empregar o IPsec35 para alcanar integridade. No entanto, o padro IP-sec considerado pesado para as restries dos dispositivos IoT e, assim, precisoadapt-lo. Vale mencionar que os requisitos de segurana para IoT variam de aplicaopara aplicao e, assim, devem considerar um ou mais dos objetivos de segurana acimamencionados ao implementar uma aplicao.

1.3.11. Desafios e questes de pesquisa

A Internet das Coisas apresenta vrios desafios de implementao, como os dis-cutidos acima. Esses desafios j levaram e continuam a levar investigao de vrias

33O RFC 3552 apresenta boas prticas e discusses acerca de segurana em IoT: https://tools.ietf.org/html/rfc3552

34RFC 3610 https://www.ietf.org/rfc/rfc3610.txt35RFC 4301: https://tools.ietf.org/html/rfc4301

https://tools.ietf.org/html/rfc3552https://tools.ietf.org/html/rfc3552https://www.ietf.org/rfc/rfc3610.txthttps://tools.ietf.org/html/rfc4301

questes de pesquisa decorrentes das restries dos dispositivos existentes na IoT, dosprotocolos e solues de interconexo desses dispositivos e da escalabilidade da rede.Alm disso, medida que a Internet das Coisas se tornar cada vez mais presente na so-ciedade, o projeto de aplicaes e servios, que esto sendo propostos para os diversossegmentos das atividades humana, trar tambm novas questes de pesquisa relacionadasprincipalmente ao tratamento de dados coletados por esses dispositivos. Em outras pala-vras, essa uma rea extremamente frtil para explorar novas questes de pesquisa quetm o potencial de impactar o estado-da-arte.

1.4. IoT na prticaAs 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 prticada IoT. Diante do que j foi discutido, o leitor est apto a por em prtica os conceitosvistos. Os exerccios prticos visam consolidar e associar os conceitos tericos e artefatospreviamente discutidos. Alm disso, uma das prticas servir de ncora para assuntos dasprximas sees, vinculando as redes de objetos inteligentes, at aqui apresentadas, comos desafios e prximos passos em relao ao futuro da IoT.

Os exemplos apresentados, a seguir, foram extrados do conjunto de exemplos dosistema operacional Contiki verso 3.0. Presume-se que o leitor j tenha o Contiki insta-lado e operacional36. Todos os exemplos so de cdigo livre e hospedados no repositriooficial do Contiki. Inicialmente ser exemplificado como conectar os objetos inteligentesutilizando IPv637 e, em seguida, ser pleiteado o Erbium que uma implementao doCoAP38 para redes de objetos de baixa potncia no Contiki.

Os experimentos apresentados visam atender o maior publico possvel. Para isto,ao longo do texto a prtica exemplificada atravs do uso de simulador. Entretanto, ominicurso tambm apresenta uma pgina Web39 onde podem ser encontrados materiaisextra preparados pelos autores. Nesse endereo, encontram-se vdeo tutoriais, textos,referncias e outros contedos relacionados.

1.4.1. Rede de 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 do6LoWPAN em conjunto com o protocolo de roteamento RPL [Hui 2012]. Alm disso, oSO tambm oferece suporte pilha de protocolos IP TCP/IP (veja Seo 1.3.3). Para co-mear, inicie o Cooja atravs do atalho da rea de trabalho ou execute o comando abaixoe, em seguida, crie uma nova simulao:

36http://www.contiki-os.org/start.html37https://github.com/contiki-os/contiki/tree/master/examples/ipv6/

rpl-border-router38https://github.com/contiki-os/contiki/tree/master/examples/

er-rest-example39http://homepages.dcc.ufmg.br/~bruno.ps/iot-tp-sbrc-2016/

http://www.contiki-os.org/start.htmlhttps://github.com/contiki-os/contiki/tree/master/examples/ipv6/rpl-border-routerhttps://github.com/contiki-os/contiki/tree/master/examples/ipv6/rpl-border-routerhttps://github.com/contiki-os/contiki/tree/master/examples/er-rest-examplehttps://github.com/contiki-os/contiki/tree/master/examples/er-rest-examplehttp://homepages.dcc.ufmg.br/~bruno.ps/iot-tp-sbrc-2016/

Inicie o Cooja executando os comandos abaixo:

$ cd +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 dispositivoresponsvel 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 rvorede roteamento e interlocutor entre a rede de objetos e a rede externa.

O cdigo do roteador de borda est localizado em:

+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 telaseguinte, compile e carregue, como firmeware, o cdigo do roteador de borda. Finalmenteadicione 1 mote deste tipo.

Aps configurar o roteador de borda, a prxima etapa povoar a rede com objetosinteligentes. O cdigo sky-websense.c ajudar nesta fase.

O cdigo do sky-websense.c est localizado em:

+contiki/examples/ipv6/sky-websense/sky-websense.c

Este cdigo uma aplicao que produz dados sensoriados e prover acesso a estas in-formaes via webserver. Adicione alguns40 motes desse tipo. recomendvel que o oleitor 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 contextoselecione a opo mostrada abaixo. O Cooja informar que o roteador de borda criou umsocket 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 +contiki/examples/ipv6/rpl-border-router/$ make connect-router-cooja TARGET=sky

Estes comandos acabam por executar o programa tunslip6. O programa configurauma interface na pilha de protocolos do Linux, em seguida, conecta a interface ao socketem que o roteador de borda est escutando. O tunslip6 far com que todo o trfegoendereado ao prefixo aaaa:41 seja direcionado para a interface do Cooja.

40Adicione 2 ou 5 motes para manter a carga de processamento e consumo de memria baixos.41Vale 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

Terminal 2 tunslip6

ifconfig tun0 inet hostname upifconfig tun0 add aaaa::1/64ifconfig tun0 add fe80::0:0:0:1/64ifconfig tun0

tun0 Link encap:UNSPEC HWaddr 00-00...inet addr:127.0.1.1 P-t-P:127.0.1.1Mask:255.255.255.255inet6 addr: fe80::1/64 Scope:Linkinet6 addr: aaaa::1/64 Scope:Global...

Address:aaaa::1 => aaaa:0000:0000:0000Got configuration message of type PSetting prefix aaaa::Server IPv6 addresses:aaaa::212:7401:1:101fe80::212:7401:1:101

O tunslip6 apresentar uma sada semelhante a mostrada na caixa de ttulo Terminal 2e o Cooja apresentar algo como mostrado na figura ao lado42. 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]/

A rede de exemplo possui trs mo-tes e apresenta topologia exibida nafigura abaixo, em que :101 o ro-teador de borda.

O Roteador de Borda responder com:

Neighbors

fe80::212:7402:2:202

Routes

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

A resposta requisio feita ao roteador de borda conter duas partes. A primeira exibe atabela de vizinhana, ou seja, os ns diretamente ligados na rvore de roteamento do RPL(Neighbor Table). A segunda lista os ns alcanveis (Routes) e o prximo salto na rotaat aquele destinatrio.

Agora acesse, pelo navegador, os recursos (luminosidade e temperatura) providos pelosTmotes rodado sky-websense como mostrado a seguir:

Acesse os Tmotes pelo browser com:

http://[IPv6 do Tmote]/http://[IPv6 do Tmote]/lhttp://[IPv6 do Tmote]/t

Exemplo de requisio:

http://[aaaa::212:7403:3:303]/l

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

42Note que os motes executando websense no foram exibidos.

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

Esta prtica abordar o uso de Representational State Transfer (REST) Trans-ferncia de Estado Representacional. Para tanto, ser utilizado o Erbium (Er), uma im-plementao do IETF CoAP de RTF 7252 (veja a Seo 1.3.7). O Er foi projetado paraoperar em dispositivos de baixa potncia [Kovatsch et al. 2011] e tem cdigo livre dispo-nvel junto com o sistema operacional Contiki. Para iniciar ser feita uma breve revisoda 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, osquais so identificados por URIs nicas. O CoAP oferece diferentes mtodos para realizaroperaes bsicas CRUD sendo eles: POST para criar um recurso; GET para recuperarum recurso; PUT para atualizar algum recurso e; DELETE para apagar um recurso.

A implementao do CoAP no Contiki est localizada no diretrio:

+contiki/apps/er-coap

Para cada recurso disponibilizado no servidor usando CoAP existe uma funo (handlefunction), 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 responderadequadamente com o contedo do recurso solicitado.

As macros43 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. ONormal 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 ,d e l e t e _ h a n d l e r )

Parent Resource: destinado a gerenciar diversos sub-recursos de uma URI. Por exemplo,a URI test/parent/.

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 ,d e l e t e _ h a n d l e r )

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 ,d e l e t e _ h a n d l e r , r e s u m e _ h a n d l e r )

Event Resource e Periodic Resource: no primeiro, a ideia que quando um eventoocorra o dispositivo envie uma mensagem para algum cliente que esteja observandoaquele recurso, por exemplo, quando um boto no dispositivo pressionado envia-se uma

43Mais detalhes sobre as macros, atributos e estruturas so encontrados em: https://github.com/contiki-os/contiki/tree/master/apps/er-coap

https://github.com/contiki-os/contiki/tree/master/apps/er-coaphttps://github.com/contiki-os/contiki/tree/master/apps/er-coap

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 soobservveis, isto , um cliente ao assinar o feed daquele recurso receber notificaessempre 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 ,d e l e t e _ h a n d l e r , e v e n t _ h a n d l e r )

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 ,d e l e t e _ h a n d l e r , p e r i o d , p e r i o d i c _ h a n d l e r )

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