Livro de Minicursos

Copyright © 2015 Sociedade Brasileira de ComputaçãoTodos os direitos reservados

Capa: Carlos Bao, Atêlie Eventos (Vitória/ES)Produção editorial: Rodolfo Villaça, UFES

Cópias Adicionais: Sociedade Brasileira de Computação (SBC) Av. Bento Gonçalves, 9500 – Setor 4 – Prédio 43.412 – Sala 219 Bairro Agronomia – CEP 91.509-900 – Porto Alegre – RS Fone: (51) 3308-6835 E-mail: [email protected]

Dados Internacionais de Catalogação na PublicaçãoSimpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (33. :

2015 : Vitória, ES)Minicursos / XXXIII Simpósio Brasileiro de Redes de Computadores e

Sistemas Distribuídos; organização: Magnos Martinello, Moises Renato Nunes Robeiro, Antônio Augusto Aragão Rocha — Porto Alegre: Sociedade Brasileira de Computação, 2015.

325 p. il. 21 cm.

Vários autoresInclui bibliografiasISSN: 2177-4978

1. Redes de Computadores. 2. Sistemas Distribuídos. I. Martinello, Magnos. II. Ribeiro, Moises Renato Nunes. III. Rocha, Antônio Augusto Aragão. IV. Título.

Minicursos do XXXIII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos — SBRC 2015

i

Sociedade Brasileira de Computação – SBC

PresidênciaPaulo Roberto Freire Cunha (UFPE), PresidenteLisandro Zambenedetti Granville (UFRGS), Vice-Presidente

DiretoriasRenata de Matos Galante (UFRGS), Diretora AdministrativaCarlos André Guimarães Ferraz (UFPE), Diretor de FinançasAltigran Soares da Silva (UFAM), Diretor de Eventos e Comissões EspeciaisMirella Moura Moro (UFMG), Diretora de EducaçãoJosé Viterbo Filho (UFF), Diretor de PublicaçõesClaudia Lage da Motta (UFRJ), Diretora de Planejamento e Programas EspeciaisMarcelo Duduchi Feitosa (CEETEPS), Diretor de Secretarias RegionaisEdson Norberto Cáceres (UFMS), Diretor de Divulgação e Marketing

Diretorias ExtraordináriasRoberto da Silva Bigonha (UFMG), Diretor de Relações ProfissionaisRicardo de Oliveira Anido (UNICAMP), Diretor de Competições CientíficasRaimundo Macêdo (UFBA), Diretor de Cooperação com Sociedades CientíficasAvelino Francisco Zorzo (PUC-RS), Diretor de Articulação de Empresas

ContatoAv. Bento Gonçalves, 9500Setor 4 - Prédio 43.412 - Sala 219Bairro Agronomia91.509-900 – Porto Alegre RSCNPJ: 29.532.264/0001-78http://www.sbrc.org.br

Laboratório Nacional de Redes de Computadores – LARC

Diretoria (2014-2016)Elias P. Duarte Jr. (UFPR), Vice-Diretor ExecutivoRonaldo Alves Ferreira (UFMS), Vice-Diretor do Conselho Técnico-científicoRossana Maria de C. Andrade (UFC), Diretora do Conselho Técnico-científicoPaulo André da Silva Gonçalves (UFPE), Diretor Executivo

Membros InstitucionaisSESU/MEC, INPE/MCT, UFRGS, UFMG, UFPE, UFCG, UFRJ, USP, PUC-Rio,UNICAMP, LNCC, IME, UFSC, UTFPR, UFC, UFF, UFSCar, CEFET-CE, UFRN,UFES, UFBA, UNIFACS, UECE, UFPR, UFPA, UFAM, UFABC, PUCPR, UFMS,UNB, PUC-RS, UNIRIO, UFS, UFU.


ii

Organização do SBRC 2015

Coordenadores GeraisMagnos Martinello (UFES)Moises Renato Nunes Ribeiro (UFES)

Coordenadores do Comitê de ProgramaChristian Esteve Rothenberg (UNICAMP)Jussara Almeida (UFMG)

Coordenador de Palestras e TutoriaisMarinho Barcellos (UFRGS)

Coordenador de Painéis e DebatesAntônio Abelém (UFPA)

Coordenador de MinicursosAntônio Augusto de Aragão Rocha (UFF)

Coordenador de WorkshopsSidney Lucena (UNIRIO)

Coordenador do Salão de FerramentasCesar Marcondes (UFSCAR)Alfredo Goldman (USP)

Comitê ConsultivoDorgival Guedes (UFMG) Joni Fraga (UFSC) Frank Siqueira (UFSC) Luciano Gaspary (UFRGS) Markus Endler (PUC-Rio) Jacir Luiz Bordim (UnB) Rafael Timóteo de Sousa Júnior (UnB) William Ferreira Giozza (UnB) Carlos André Guimarães Ferraz (UFPE) José Augusto Suruagy Monteiro (UFPE) Paulo André da Silva Gonçalves (UFPE)


iii

Mensagem dos Coordenadores Gerais

Boas-vindas a todos os participantes do 33º Simpósio Brasileiro de Redes deComputadores e Sistemas Distribuídos (SBRC 2015). Através dos anos, o SBRC vem seconsolidando com um dos principais eventos científicos da área de Informática no país,trazendo sempre conceitos e práticas inovadoras nas áreas de Redes de Computadores eSistemas Distribuídos. Nos sentimos extremamente honrados pela confiança em nósdepositada para realizar esse importante evento pela primeira vez em Vitória, EspíritoSanto.

O SBRC se caracteriza por proporcionar uma rica troca de ideias e experiências entreprofessores, pesquisadores, profissionais e estudantes atuantes na área de interesse dosimpósio. É sempre um desafio manter o SBRC nos padrões de qualidade que o temcaracterizado em suas exitosas edições passadas.

A programação do SBRC 2015 engloba um conjunto de atividades bastante abrangentee de alta qualidade técnica. São 18 sessões técnicas nas quais serão apresentados 58artigos completos, selecionados por meio de um rigoroso trabalho de revisão,envolvendo uma grande variedade de temas pertinentes e atuais relacionados às áreas deRedes de Computadores e Sistemas Distribuídos. A programação inclui ainda seispalestras proferidas por pesquisadores internacionalmente renomados e três painéisabordando temas extremamente atuais. São oferecidos seis minicursos, voltados àformação e atualização dos participantes sobre tópicos selecionados através de chamadapública. Adicionalmente, oito workshops são realizados em paralelo ao SBRC, focadosem temas específicos e emergentes relacionados à área de interesse do simpósio. Nestaedição, também homenageamos com o prêmio Destaque SBRC uma personalidade dasáreas de Redes de Computadores e Sistemas Distribuídos por sua contribuiçãosignificativa para a evolução da pesquisa e para a estruturação de uma sólidacomunidade científica no Brasil.

As excelentes atividades programadas nesta edição são produto dos esforços de seusrespectivos coordenadores. Um agradecimento muito especial a Jussara Almeida,Christian Esteve Rothenberg, Marinho Barcellos, Antônio Abelém, Antônio Augusto deAragão, Sidney Lucena, Cesar Augusto Marcondes e Alfredo Goldman pelo tempo eempenho na efetivação das várias trilhas do SBRC 2015.

Ressaltamos o trabalho intenso e extremamente competente realizado pelo integrantesdo Comitê de Organização Local ao qual gostaríamos de agradecer especialmente aoRodolfo Villaça, Renato Moraes, Maxwell Monteiro, Maria José Pontes, Sabrina Felix,Marcia Paiva, Roberta Lima Gomes e Celso Alberto Saibel Santos. Agradecemos aindaàs diretorias da SBC e do LARC, promotores do SBRC, pela confiança e pelocompetente apoio organizacional prestado pela equipe administrativa da SBC. Somostambém gratos aos integrantes do Comitê Consultivo do SBRC e à coordenação daComissão Especial de Redes de Computadores e Sistemas Distribuídos da SBC, pelosaconselhamentos e pelo suporte financeiro prestado à organização do SBRC 2015.

Gostaríamos de agradecer ainda aos patrocinadores do Simpósio: o Comitê Gestor daInternet no Brasil, às agências governamentais de fomento – CNPq, CAPES e FAPES –


iv

e às empresas patrocinadoras por reconhecerem o SBRC como um evento importantepara o fomento à pesquisa e inovação nas áreas de Redes de Computadores e SistemasDistribuídos.

Por fim, agradecemos aos Departamentos de Informática e Engenharia Elétrica daUFES, e aos Programas de Pós-Graduação em Informática (PPGI) e Elétrica (PPGEE)por prestarem o indispensável suporte para a realização do SBRC.Desejamos a todos os participantes que tenham uma excelente estadia em Vitória e quetirem proveito de todo o conhecimento que as atividades o SBRC 2015 tem a lhesoferecer.

Vitória, 18 de maio de 2015. Magnos Martinello (UFES)

Moisés Renato Nunes Ribeiro (UFES)Coordenadores Gerais


v

Mensagem do Coordenador de Minicursos

Este livro apresenta a seleção de Minicursos da 33a edição do Simpósio Brasileiro deRedes de Computadores e Sistemas Distribuídos (SBRC), realizado em Vitória-ES,entre os dias 18 e 22 de maio de 2015. As sessões de minicursos do evento representamuma oportunidade para acadêmicos e profissionais se aprofundarem em temasrelevantes e atuais da área, e que normalmente não são cobertos em grades curricularesdas universidades. O SBRC possui, tradicionalmente em sua programação técnica, umasérie desses minicursos. Em 2015, foram submetidas 20 propostas, das quais 6 foramselecionadas para publicação e apresentação, representando assim uma taxa de aceitaçãode 30%. Os números demonstram o rigor do processo e, sem dúvida, refletem também aqualidade das propostas selecionadas. O comitê de avaliação dos minicursos foicomposto por 17 renomados pesquisadores, que desempenharam um excelente trabalhono processo de elaboração dos pareceres para seleção das propostas.

Esta edição reúne, portanto, seis capítulos, produzidos pelos autores das propostasaceitas. No Capítulo 1, os autores discutem sobre os problemas de aplicação de redesdefinidas por software em sistemas de computação em nuvem. O Capítulo 2 discorresobre a geração distribuída de energia, seus desafios e perspectivas em redes decomunicação. No capítulo 3, os autores discorrem sobre plataformas para a Internet dascoisas. O Capítulo 4 apresenta a plataforma NetFPGA para processamento de pacotesem hardware. O Capítulo 5 apresenta uma introdução a rádios definidos por softwarecom aplicações em GNU radio. E, finalmente, o Capítulo 6 aborda os desafios eoportunidades das pesquisas em redes de sensoriamento participativo.

Como Coordenador de Minicursos, gostaria de agradecer a todos envolvidos naprodução deste livro. Primeiramente aos coordenadores gerais do SBRC 2015, MagnosMartinello (UFES) e Moisés R. N. Ribeiro (UFES), pelo convite para a coordenação deminicursos, além de todo o suporte necessário para a realização do evento. Agradeçotambém a todos os membros do comitê de avaliação por terem aceitado o meu convite ededicado grande esforço para produzir as revisões de alta qualidade para todos ostrabalhos submetidos. Por fim, agradeço a todos que submeteram propostas, algumas demuita qualidade não puderam ser aceitas devido à limitação de espaço no evento, masagradeço especialmente aos autores que tiveram seus trabalhos aceitos e que sededicaram imensamente para produzir este livro e apresentações de qualidade ímpar.

Antonio Augusto de Aragão RochaProfessor da Universidade Federal FluminenseCoordenador de Minicursos do SBRC 2015


vi

Comitê de Avaliação de Minicursos do SBRC 2015

Artur Ziviani (LNCC)Ana Paula Couto da Silva (UFMG)Igor Moraes (UFF)Michele Nogueira (UFPR)Antonio Abelém (UFPA)Stenio Fernandes (UFPE)Marinho Pilla Barcellos (UFRGS)Daniel Figueiredo (UFRJ)Jose F. de Rezende (UFRJ)Carlos Alberto Vieira Campos (UNIRIO)Aldri Santos (UFPR)Daniel Macêdo Batista (IME-USP)Gustavo Bittencourt Figueiredo (UFBA)Jose Augusto Suruagy Monteiro (UFPE)Miguel Elias Mitre Campista (UFRJ)Flávia Delicato (UFRJ)Alex Vieira (UFJF)


vii

Sumário

1. Applying Software-defined Networks to Cloud Computing Tereza Carvalho (Universidade de São Paulo), Marcos Simplicio Jr (Escola Politécnica – USP), Bruno Barros (Universidade de São Paulo), Marco Rojas (Universidade de São Paulo), Fernando Redigolo (Universidade de Sao Paulo), Dino Magri (Universidade de São Paulo), Gustavo Cavalcanti (UDESC), Ewerton Andrade (Universidade de Sao Paulo) ...................................................1

2. Geração Distribuída de Energia: Desafios e Perspectivas em Redes de ComunicaçãoYona Lopes (Universidade Federal Fluminense), Natalia Castro Fernandes (Universidade Federal Fluminense), Debora Muchaluat Saade (UFF) …..........55

3. Plataformas para a Internet das CoisasPaulo Pires (UFRJ – Brazil), Flavia Delicato (UFRJ – Brazil), Thais VasconcelosBatista (UFRN – Brazil), Thomaz Avila (UFRJ – Brazil), Everton Cavalcante (UFRN – Universidade Federal do Rio Grande do Norte – Brazil), Marcelo Pitanga (Universidade Federal do Rio de Janeiro – Brazil) ..............................110

4. NetFPGA: Processamento de Pacotes em HardwarePablo Goulart (Universidade Federal de Minas Gerais – Brazil), Italo Cunha (Universidade Federal de Minas Gerais – Brazil), Marcos Vieira (UFMG – Brazil), Cesar Marcondes (Universidade Federal de São Carlos – Brazil), Ricardo Menotti (Universidade Federal de São Carlos – Brazil), Dorgival Guedes (UFMG – Brazil) .................................................................................170

5. Introdução a Rádios Definidos por Software com aplicações em GNU RadioWendley Silva (Universidade Federal do Ceará – Brazil), Jefferson Rayneres S. Cordeiro (UFMG – Brazil), Jose-Marcos Nogueira (Universidade Federal de Minas Gerais – Brazil), Daniel Fernandes Macedo (Universidade Federal de Minas Gerais – Brazil), Marcos Vieira (UFMG – Brazil), Luiz Filipe Vieira (UFMG – Brazil) ..............................................................................................216

6. Redes de Sensoriamento Participativo: Desafios e OportunidadesThiago Silva (UFMG – Brazil), Pedro Olmo Vaz de Melo (Universidade Federalde Minas Gerais – Brazil), Jussara Almeida (DCC-UFMG – Brazil), João Borges(Universidade Federal do Rio Grande do Norte – Brazil), Clayson Celes (Universidade Federal de Minas Gerais (UFMG) – Brazil), Anna Izabel Tostes (Universidade Federal de Minas Gerais – Brazil), Felipe Domingos da Cunha (UFMG – Brazil), Antonio Alfredo Ferreira Loureiro (UFMG – Brazil) ........266


viii

Capítulo

1Applying Software-defined Networks to CloudComputing

Bruno Medeiros de Barros (USP), Marcos Antonio Simplicio Jr. (USP),Tereza Cristina Melo de Brito Carvalho (USP), Marco Antonio Torrez Rojas(USP), Fernando Frota Redígolo (USP), Ewerton Rodrigues Andrade (USP),Dino Raffael Cristofoleti Magri (USP)

Abstract

Network virtualization and network management for cloud computing systems have be-come quite active research areas in the last years. More recently, the advent of theSoftware-Defined Networks (SDNs) introduced new concepts for tackling these issues,fomenting new research initiatives oriented to the development and application of SDNsin the cloud. The goal of this course is to analyze these opportunities, showing howthe SDN technology can be employed to develop, organize and virtualize cloud network-ing. Besides discussing the theoretical aspects related to this integration, as well as theensuing benefits, we present a practical a case study based on the integration betweenOpenDaylight SDN controller and OpenStack cloud operating system.

1.1. IntroductionThe present section introduces the main topics of the course, providing an evolutionaryview of network virtualization in cloud computing and distributed systems. We present themain changes occurred in the field in the latest years, focusing in the advent of Software-defined Networks (SDN) and its implications in the current research scenario.

1.1.1. The Role Networking in Cloud Computing

Cloud computing has ushered the information technology (IT) field and service providersinto a new era, redefining how computational resources and services are delivered andconsumed. With cloud computing, distinct and distributed physical resources such ascomputing power and storage space can be acquired and used in an on-demand ba-sis, empowering applications with scalability and elasticity at low cost. This allowsthe creation of different service models, generally classified as [Mell and Grance 2011]:


1 c©2015 SBC — Soc. Bras. de Computação

Infrastructure-as-a-Service (IaaS), which consists in providing only fundamental comput-ing resources such as processing, storage and networks; Platform-as-a-Service (PaaS), inwhich a development platform with the required tools (languages, libraries, etc.) is pro-vided to tenants; and Software-as-a-Service (SaaS), in which the consumer simply usesthe applications running on the cloud infrastructure.

To actually provide cost reductions, the cloud needs to take advantage ofeconomies of scale, and one key technology for doing so is resource virtualization. Afterall, virtualization allows creation of a logical abstraction layer above the pool of physi-cal resources, thereby enabling a programmatic approach to allocate resource whereverneeded while hiding the complexities involved in their management. The result is poten-tially very efficient resource utilization, better manageability, on-demand and program-matic resource instantiation, and resource isolation for better control, accounting andavailability.

In any cloud environment, the network is a critical resource that connects variousdistributed and virtualized components, such as servers, storage elements, appliances andapplications. For example, it is the network that allows aggregation of physical servers,efficient virtual machine (VM) migration, and remote connection to storage systems, ef-fectively creating the perception of large, monolithic resource pool. Furthermore, it isalso the network that enables delivery of cloud based applications to end users. Yet, whileevery component in a cloud is getting virtualized, the physical network connecting thesecomponents is not. Without virtualization, the network is one physical common network,shared by all cloud end-users and cloud components. Without virtualization, the networklikely becomes a single complex system in the cloud as the cloud evolves to provide newservices with diverse requirements while trying to sustain the scale.

1.1.2. The Advent of Software-Defined Networks (SDNs)

The term SDN originally appeared in [Greene 2009], referring to the ability of Open-Flow [McKeown et al. 2008] to support the configuration of table flows in routers andswitches using software. However, the ideas behind SDNs come from the goal of hav-ing a programmable network, whose research started short after the emergence of theInternet, led mainly by the telecom industry. Today, the networking industry has shownenormous interest in the SDN paradigm, given the expectations of reducing both cap-ital and operational costs with service providers and enterprise data centers with pro-grammable, virtualizable and easily partitionable networks. Actually, programmabilityis also becoming a strategic feature for network hardware vendors, since it allows amany devices to be programmed and orchestrated in large network deployments (e.g.,data centers). In addition, discussions related to the future Internet has led to the stan-dardization of SDN-related application programming interfaces (API), with new com-munication protocols being successfully deployed on experimentation and real scenarios[Kim et al. 2013, Pan et al. 2011].

These features of SDNs make them highly valuable for cloud computing systems,where the network infrastructure is shared by a number of independent entities and, thus,network management becomes a challenge. Indeed, while the first wave of innovationin the cloud focused on server virtualization technologies and on how to abstract com-

1: Applying Software-defined Networks to Cloud Computing.


putational resources such as processor, memory and storage, SDNs are today promot-ing a second wave with network virtualization [Lin et al. 2014]. The emergence of largeSDN controllers focused on ensuring availability and scalability of virtual networking forcloud computing systems (e.g., OpenDayLight [Medved et al. 2014] and OpenContrail[OpenContrail 2014]) is a clear indication of this synergy between both technologies.

Besides the cloud, SDNs have also been adopted in other computing scenarios,with device vendors following the SDN path and implementing most of control logicin software over standard processors. This has led to the emergence of software-definedbase stations, software defined optical switches, software-defined radios, software-definedrouters, among others.

1.2. Cloud Computing and Network VirtualizationThis section aims to introduce the concepts and technologies related to network virtual-ization in cloud computing systems. We start by describing the main virtualization tech-nologies used to implement multitenant networks. Then, we present an architectural viewof virtual networks in the cloud, discussing the main components involved, their respon-sibilities and existing interfaces. Finally, we focus on security, scalability and availabilityaspects of the presented solutions.

1.2.1. Cloud Computing and Resource Virtualization

Virtualization is not a new concept in computing, having in fact appeared in the 70’s[Jain and Paul 2013a, Menascé 2005]. The concept of virtualization has evolved withtime, however, going from virtual memory to processor virtualization (e.g., Hyper-V,AMD-V, Hyper-threading) up to the virtualization of network resources (e.g., SDN, Open-vSwitch, etc).

With the advent of cloud computing and the demand of virtualizing entirecomputing environments, new virtualization techniques were developed, among them[Amazon 2014]:

• Full Virtualization or Hardware VM: all hardware resources are simulated viasoftware. The hardware itself is not directly accessed by VMs, as the hypervisor translatesall interruptions and calls between the virtual and physical appliances. Obviously, thistechnique incurs performance penalties due to I/O limitations, so it is less efficient thanits counterparts. However, it offers high flexibility, as systems running on VMs do notneed to be altered if there is a change on the underlying physical hardware;

• Para-Virtualization: the hardware is not simulated, but divided in different do-mains so they can be accessed by VMs. Systems running on VMs need to be adaptedso that they can directly access the physical machine’s hardware resources. Performancehere is close to the performance on the physical machine (bare-metal), with the drawbackof limited flexibility, as hardware upgrades may demand changes on VMs.

• Para-virtualized drivers (Para+Full Virtualization): a combination of the pre-vious techniques. As para-virtualized storage and networking devices have a much betterperformance than their full-virtualized counterparts [Amazon 2014], this is the techniqueapplied to these devices, while full-virtualization (and the consequent flexibility brought



by it) is applied to devices whose performance is not critically affected. This approachallows minimum changes when physical hardware upgrades are needed.

Several studies highlight the benefits of virtualization on a computing environ-ment. Among them, the following can be cited [Menascé 2005, Kotsovinos 2010]:

• Resource sharing: when a device has more resources than what can be con-sumed by a single entity, those resources can be shared among different users or processesfor better usage efficiency. For example, the different user applications or VMs runningon a server can share its multiple processors, storage disks or network links. If properlyexecuted, the economy achieved in small server consolidation onto VMs, for example,can be from 29 % to 64 % [Menascé 2005];

• Resource aggregation: devices with a low availability of resources can be com-bined to create a larger-capacity virtual resource. For example, with an adequate filemanagement system, small-size magnetic disks can be combined to create the impressionof a large virtual disk.

• Ease of management: one of the main advantages of virtualization is that itfacilitates maintenance of virtual hardware resources. One reason is that virtualizationusually provides standard software interfaces that abstract the underlying hardware (ex-cept for para-virtualization). In addition, legacy applications placed in virtualized en-vironments can keep running even after being migrated to a new infrastructure, as thehypervisor becomes responsible to translate old instructions into those comprehensibleby the underlying physical hardware.

• Dynamics: with the constant changes to application requirements and work-loads, rapid resource realocation or new resource provisioning becomes essential for ful-filling these new demands. Virtualization is a powerful tool for this task, since virtualresources can be easily expanded, realocated, moved or removed without concerns aboutwhich physical resources will support the new demands. As an example, when a userprovisions a dynamic virtual disk, the underlying physical disk does not need to have thatcapacity available at provisioning time: it just needs to be available when the user actuallyneeds to use it.

• Isolation: multiple users environments may contain users that do not trust oneach other. Therefore, it is essential that all users have their resources isolated from otherusers, even if this is done logically (i.e., in software). When this happens, malicious usersare unable to monitor and/or interfere with other users’ activities, preventing a vulnera-bility or attack to a given machine from affecting other users.

Despite their benefits, there are also disadvantages of virtualized environments,such as [Kotsovinos 2010]:

• Performance: even though there is no single method for measuring perfor-mance, it is intuitive that the extra software layer of the hypervisors leads to higher pro-cessing costs than a comparable system with no virtualization.

• Management: virtual environments abstract physical resources in software andfiles, so they need to be instantiated, monitored, configured and saved in an efficient and



auditable manner, which is not always an easy task.

• Security: whereas isolation is a mandatory requirement for VMs in many realcase scenarios, completely isolating a virtualized resource from another, or applicationsrunning on the physical hardware from virtualized ones, are involved (if not impossible)tasks. Therefore, it is hard to say whether or not a physical server hosting several virtual-ized applications is monitoring them with the goal of obtaining confidential information,or even whether a VM is somehow attacking or monitoring another VM.

1.2.2. Mechanisms for Network Virtualization

To understand the mechanisms that can implement network virtualization, first we needto understand which resources can be virtualized in a network. In terms of resources,networks are basically composed by network interface cards (NICs) connected to a layer2 network through a switch. These layer 2 networks can be connected through routers toform a layer 3 network, which in turn can be connected via routers to compose the Inter-net. Each of these network components — NIC, L2 network, L2 switch, L3 networks, andL3 routers — can be virtualized [Jain and Paul 2013b]. However, there are multiple, oftencompeting, mechanism for virtualizing these resources, as discussed in what follows:

• Virtualization of NICs: Every networked computer system is composed by atleast one NIC. In virtualized environments with multiple VMs, it becomes, thus, necessaryto provide every VM with its own virtual NIC (vNIC). This need is currently satisfied bythe hypervisor software, which is able to provide as many vNICs as the number of VMsunder its responsibility. The vNICs are connected to the physical NIC (pNIC) througha virtual switch (vSwitch), just like physical NICs can be connected through a physicalswitch to compose layer 2 networks. This NIC virtualization strategy has benefits such astransparency and simplicity and, thus, is generally proposed by software vendors. Never-theless, there is an alternative design proposed by pNIC (chip) vendors, which is to vir-tualize NIC ports using single-route I/O virtualization (SR-IOV) [PCI-SIG 2010] on theperipheral-component interconnect (PCI) bus. This approach directly connects the VMsto the pNICs, potentially providing better performance (as it eliminates intermediary soft-ware) and resource isolation (as the traffic does not go through a shared vSwitch). A thirddesign approach, promoted by physical switch vendors, is to provide virtual channels forinter-VM communication using a virtual Ethernet port aggregator (VEPA) [IEEE 2012b],which in turn passes VM frames to an external switch that implements inter-VM com-munication. This approach not only frees up server resources, but also provides bettervisibility and control over the traffic between any pair of VMs.

• Virtualization of L2 Switches: The number of ports in a typical switch is lim-ited, and possibly lower than the number of physical machines that need to be connectedon an L2 network. Therefore, several layers of L2 switches need to be connected to ad-dress network scalability requirements. To solve this issue, IEEE Bridge Port Extensionstandard 802.1BR [IEEE 2012a] proposes a virtual bridge with a large number of portsusing physical or virtual port extenders (like a vSwitch).

• Virtualization of L2 Networks: In a multitenant data center, VMs in a sin-gle physical machine may belong to different clients and, thus, need to be in different



virtual LANs (VLANs) [IEEE 2014]. VLANs implement package tagging for allowingL2 devices to isolate clients’ traffic in different logical L2 networks, so different virtualnetworks can use the same addressing space for different clients.

• Virtualization of L3 Networks: When the multitenant environment is extendedto a layer 3 network, there are a number of competing proposals to solve the problem. Ex-amples include: virtual extensible LANs (VXLANs) [Mahalingam et al. 2014b]; networkvirtualization using generic routing encapsulation (NVGRE) [Sridharan et al. 2011]; andthe Stateless Transport Tunneling (STT) protocol [Pan and Wu 2009].

• Virtualization of L3 Router: Multicore processors allow the design of network-ing devices using software modules that run on standard processors. By combiningmany different software-based functional modules, any networking device (L2 switch, L3router, etc.) can be implemented in a cost-effective manner while providing acceptableperformance. Network Function Virtualization (NFV) [Carapinha and Jiménez 2009]provides the conceptual framework for developing and deploying virtual L3 routers andother layer 3 network resources.

1.2.3. Virtual Network Applications in Cloud Computing

As discussed in Section 1.1.1 the interest surrounding network virtualization has been fu-eled by cloud computing and its isolation and scalability requirements. All the networkvirtualization mechanisms presented in Section 1.2.2 can be applied to solve specific net-work issues in cloud computing, in especial for the implementation of multitenant datacenters. Specifically, as depicted in Figure 1.1, a data center consist mainly of serversin racks interconnected via a top-of-rack Ethernet switch, which in turn connects to anaggregation switch, also known as an end-of-rack switch. The aggregation switches thenconnect to each other, as well as the other servers in the data center. A core switch con-nects the various aggregation switches and provides connectivity to the outside world,typically through layer 3 networks. In multitenant data centers, client VMs are com-monly placed in a different server, connected through the L2 network composed by thisswitch-enabled infrastructure. The virtualization of L2 switches via mechanisms such asVLAN enables the abstraction of tenant L2 networks on the distributed cloud data cen-ter, allowing traffic isolation of tenant networks with a different logical addressing space.Similarly, the virtualization of L3 routers using technologies such as VXLAN and GREtunneling enable the abstraction of layer 3 networks, connecting multiple data centers andallowing tenant networks to be distributed in different sites.

Another inherent characteristic of multitenant data centers is the virtualization ofservers, enabling the instantiation of multiple VMs. VMs deployed in the same cloudserver commonly belong to different tenants and share the same computing resources,including the network interface (NIC). Mechanisms to virtualize server NICs such as vir-tual switches (i.e., in software) and SR-IOV (i.e., in hardware) are necessary to addressmulti-tenancy. Besides virtual switches, other software-based virtualization mechanismsare enabled by the NFV approach. NFV consists on the virtualization of network func-tional classes, such as routers, firewalls, load balancers and WAN accelerators. Theseappliances take the form software-based modules that can be deployed in one or moreVMs running on top of servers.



Figure 1.1. Cloud data center network.

1.2.4. Security, Scalability and Availability aspects

The widespread adoption of cloud computing has emerged important security concernsinherited from multi-tenant environments. The need for isolating the server and networkresources consumed by different tenants is an example of the security requirements intro-duced by cloud computing. Virtualization technologies such as the presented in section1.2.2 play a crucial role in these scenario as mechanisms to enforce the resource isolation.Considering the cloud networking scenario, virtualization technologies should provide se-cure network domains for the cloud tenants, enabling secure connectivity for the servicesrunning inside the cloud. Understand the nature of security threats is a fundamental com-ponent of managing risks and implementing secure network services for cloud tenants.According to [Barros et al. 2015], there are three threat scenarios in cloud computing net-working. The scenarios are explained below.

• Tenant-to-Tenant: Threats related to attacks promoted by a legitimate tenant tar-geting another legitimate tenant exploiting security vulnerabilities in the cloud networkinginfrastructure.

• Tenant-to-Provider: Threats related to cloud vulnerabilities that allow a legit-imate tenant to disrupt the operation of the cloud infrastructure, preventing the cloudprovider from delivering the service in accordance with the service level agreements(SLAs) established with other legitimate tenants.

• Provider-to-Tenant: Threats related to vulnerabilities in the cloud provider in-frastructure, which allows malicious insider attacks from employees and other agents with



direct access to the cloud infrastructure.

Different scenarios can also originate different groups of security threats in cloudnetworking scenarios. Consequently, different groups of security solutions built upon net-work virtualization mechanisms should be applied to ensure secure cloud services provi-sion. Also according to [Barros et al. 2015], the sources of security threats concerned tocloud networking scenario are described as follow.

• Physical isolation: Security threats originated from shared phyisical resourcesin the underlying network infrastructure, such as server NICs, switches and routers. At-tacks are commonly related to hijacking and analyzing tenant data from shared resourcesor even causing resource exhaustion on shared physical network elements.

• Logical isolation: Security threats originated from shared virtual resources suchas virtual switches, Linux bridge and virtual routers. Security attacks commonly exploitvulnerabilities in software-based virtualization mechanisms to access unauthorized dataand to reduce the quality of cloud network services.

• Authentication: Security threats originated from authentications vulnerabilitiesrelated to inadequate authentication, which allow attackers to mask their real identities.This can be accomplished by exploiting authentication protocols, acquiring credentialsand/or key materials by capturing data traffic, or via password recovery attacks (e.g.,brute force or dictionary attacks).

• Authorization: Security threats originated by vulnerabilities related to autho-rization problems, allowing granting or scaling rights, permissions or credentials to orfrom an unauthorized user. For example, the attacker can exploit a vulnerability in thecloud platform authorization modules, or even in the victim computer, to create or changeit’s credentials in order to obtain privileged rights.

• Insecure API: Security threats related to failures, malfunctions and vulnerabil-ities in APIs that compose the cloud system. Attacks of this class try to exploit insecureinterfaces for accessing or tampering with services running in other tenants or cloud ad-ministrative tools.

Following the principles of cloud computing, the cloud networking should behighly scalable. Tha scalability of cloud networks are directly related to the features pro-vided by the network virtualization mechanisms. The use of technologies such as VLANand SR-IOV have intrinsic scalability limitations related to the number of VMs hostedin the same node. The capacity to replicate and migrate virtual domains in cloud com-puting are fundamental keys to ensure the availability of cloud services. Redundant linksin the underlying infrastructure, as well as eliminating single point of failure in physicaland virtual network resources, are good practices for network availability in multi-tenantenvironments.

1.3. Software-defined Networks (SDNs)The current section introduces the concept of SDNs, as well as its importance in the net-work virtualization scenario. Introducing the conceptual and practical division between



control plane and data plane, we explore the opportunities to apply SDN technologiesin different network architectures, focusing on the role of SDN control layer in networkvirtualization deployments. We also present a reference architecture to implement virtualnetworks in real scenarios. This section also present an evolutionary view of the SDNcontrollers currently available in the market, aiming to support network professionals anddecision maker to adopt the right SDN approach in his deployment. We finish by focusingon security, scalability and availability aspects of the presented solutions.

1.3.1. Creating Programmable Networks: a Historical Perspective

Recently, there has been considerable excitement surrounding the SDN concept, whichis explained by the emergence of new application areas such as network virtualizationand cloud networking. However, the basic ideas behind the SDN technology are actuallya result of more than 20 years of advances in the network field, in especial the interestof turning computer networks into programmable systems. Aiming to give an overviewof this evolution, we can divide the historical advancements that culminated in the SDNconcept into the three different phases [Feamster et al. 2013], as follows:

1. Active Networks (from the mid-1990s to the early 2000s): This phase followsthe historical advent of the Internet, a period in which the demands for innovation in thecomputer networks area were met mainly by the development and tests of new proto-cols in laboratories with limited infrastructure and simulation tools. In this context, theso-called “active networks” appeared as a first initiative aiming to turn network devices(e.g., switches and routers) into programmable elements and, thus, allow furthers inno-vations in the area. This programmability could then allow a separation between the twomain functionalities of networking elements: the control plane, which refers to the de-vice’s ability to decide how each packet should be dealt with; and the data plane, whichis responsible for forwardind packets at high speed following the decisions made by thecontrol plane. Specifically, active networks introduced an new paradigm for dealing withthe network’s control plane, in which the resources (e.g., processing, storage, and packetqueues) provided by the network elements could be accessed through application pro-gramming interfaces (APIs). As a result, anyone could develop new functionalities forcustomizing the treatment given to the packets passing by each node composing the net-work, promoting innovations in the networking area However, the criticism received dueto the potential complexity it would add to the Internet itself, allied to the fact that thedistributed nature of the Internet’s control plane was seen as a way to avoid single pointsof failure, reduced the interest and diffusion of the active network concept in the industry.

2. Control- and data-plane separation (from around 2001 to 2007): After the In-ternet became a much more mature technology in the late 1990’s, the continuous growth inthe volume of traffic turned the attention of the industry and academic communities to re-quirements such as reliability, predictability and performance of computer networks. Theincreasing complexity of network topologies, together with concerns regarding the perfor-mance of backbone networks, led different hardware manufacturers to develop embeddedprotocols for packet forwarding, promoting the high integration between the control anddata planes seen in today’s Internet. Nevertheless, network operators and Internet ServiceProviders (ISPs) would still seek new management models to meet the needs from net-



work topologies ever larger and more complex. The importance of a centralized controlmodel has become more evident, as well as the need of a separation between the controland data planes. Among the technological innovations arising from this phase, we can citethe creation of open interfaces for communications between the control and data planessuch as ForCES (Forwarding and Control Element Separation)[Yang et al. 2004], whosegoal was to enable a locally centralized control over the hardware elements distributedalong the network topology [Caesar et al. 2005, Lakshman et al. 2004]. To ensure the ef-ficiency of centralized control mechanisms, the consistent replication of the control logicamong the data plan elements would play a key role. The development of such distributedstate management techniques is also among the main technological contributions fromthis phase. There was, however, considerable resistance from equipment suppliers toimplement open communication interfaces, which were seen as a factor that would facil-itate the entry of new competitors in the network market. This ended up hindering thewidespread of the separation of data and control planes, limiting the number and varietyof applications developed for the control plane in spite of the possibility of doing so.

3. OpenFlow and Network Operating System (from 2007 to 2010): Theever growing demand for open interfaces in the data plane led researchers to ex-plore different clean slate architectures for logically centralized network control[Casado et al. 2007, Greenberg et al. 2005, Chun et al. 2003]. In particular, the Ethaneproject [Casado et al. 2007] created a centralized control solution for enterprise networks,reducing switch control units to programmable flow-tables. The operational deploymentof Ethane in the Stanford computer science department, focusing on network experi-mentation inside the campus, was indeed huge success, and resulted in the creation ofOpenFlow protocol [McKeown et al. 2008]. OpenFlow enables fully programmable net-works by providing a standard data plane API for existing packet switching hardware.The creation of the OpenFlow API, on its turn, allowed the emergence of SDN controlplatforms such as NOX [Gude et al. 2008], thus enabling the creation of a wide range ofnetwork applications. OpenFlow provided an unified abstraction of network devices andits functions, defining forwarding behavior through traffic flows based on 13 different in-structions. OpenFlow also led to the vision of a network operating system that, differentfrom the node-oriented system preconized by active networks, organize the network’s op-eration into three layers: (1) a data plane with an open interface; (2) a state managementlayer that is responsible for maintaining a consistent view of the overall network state; and(3) control logic that performs various operations depending on its view of network state[Koponen et al. 2010]. The need for integrating and orchestrating multiple controllers forscalability, reliability and performance purposes also led to significant enhancements ondistributed state management techniques. Following these advances, solutions such asOnix [Koponen et al. 2010] and its open-source counterpart, ONOS (Open Network Op-erating System) [Berde et al. 2014], introduced the idea of a network information basethat consists of a representation of the network topology and other control state shared byall controller replicas, while incorporating past work in distributed systems to satisfy stateconsistency and durability requirements.

Analyzing this historical perspective and the needs recognized in each phase, itbecomes easier to see that the SDN concept emerged as a tool for allowing further net-work innovation, helping researchers and network operators to solve longstanding prob-



lems in network management and also to provide new network services. SDN has beensuccessfully explored in many different research fields, including areas such as networkvirtualization and cloud networking.

1.3.2. SDNs and the Future Internet

Today’s Internet was designed more than 30 years ago, with specific requirements toconnect, in a general and minimalist fashion, the (few) existing networks at the time.After it was proven to be very successful at this task, the TCP/IP model became widelyadopted, in especial due to the possibility of running many distinct applications over itsinfrastructure while keeping the core of the network as simple as possible. However,the increase in the number of applications, users and devices making intense use of thenetwork resources would bring many (usually conflicting) requirements with each newtechnology developed, turning the Internet into a completely different environment filledwith disputes regarding its evolution [Moreira et al. 2009].

While in the early days of the Internet the simplicity of the TCP/IP model wasconsidered one of its main strengths, enabling the rapid development of applications andthe growth of the network itself, it became a weakness because it would imply an unintel-ligent network.

Figure 1.2. Ossification of the Internet

That is the main reason why TCP/IP’s simplicity is sometimes accused of beingresponsible for the “ossification of the Internet” (See Figure 1.2): without the ability ofadding intelligence to the core of the network itself, many applications had to take cor-rective actions on other layers; many patches would be sub-optimal, imposing certainrestrictions on the applications that could be deployed with the required levels of secu-rity, performance, scalability, mobility, maintainability, etc. Therefore, even though theTCP/IP model displays a reasonably good level of efficiency and is able to meet many ofthe original requirements of the Internet, many believe it may not be the best solution forthe future [Alkmim et al. 2011].

Many of the factors pointed out as the cause of the Internet’s ossification are re-lated to the strong coupling between the control and data planes, so the decision on howto treat the data flow and the execution of this decision are both handled by the same



device. In such environment, new network applications or features have to be deployeddirectly into the network infrastructure, a cumbersome task given the lack of standard in-terfaces for doing so in a market dominated by proprietary solutions. Actually, even whena vendor does provide interfaces for setting and implementing policies into the networkinfrastructure, the presence of heterogeneous devices with incompatible interfaces endsup hindering such seemingly trivial tasks.

This ossification issue has led to the creation of dedicated appliances for tasksseem as essential for the correct network’s operation, such as firewalls, intrusion detectionsystems (IDS), network address translators (NAT), among others [Moreira et al. 2009].Since such solutions are many times seen as palliative, studies aimed at changing thisossification state became more prominent, focusing especially in two approaches. Thefirst, more radical, involved the proposal of a completely new architecture that couldreplace the current Internet model, based on past experiences and identified limitations.This “clean state” strategy has not received much support, however, not only to the highcosts involved in its deployment, but also because it is quite possible that, after years ofeffort to build such specification, it might become outdated after a few decades due to theappearance of new applications with unanticipated requirements. The second approachsuggests evolving the current architecture without losing compatibility with current andfuture devices, thus involving lower costs. By separating the data and control planes, thusadding flexibility to how the network is operated, the SDN paradigm gives support to thissecond strategy [Feamster et al. 2014].

According to [Open Networking Foundation 2012], the formal definition of anSDN is: “an emerging architecture that is dynamic, manageable, cost-effective, and adapt-able, making it ideal for the high-bandwidth, dynamic nature of today’s applications. Thisarchitecture decouples the network control and forwarding functions enabling the net-work control to become directly programmable and the underlying infrastructure to beabstracted for applications and network services.” This definition is quite comprehensive,making it clear that the main advantage of the SDN paradigm is to allow different policiesto be dynamically applied to the network by means of a logically centralized controller,which has a global view of the network and, thus, can quickly adapt the network con-figuration in response to changes [Kim and Feamster 2013]. At the same time, it enablesindependent innovations in the now decoupled control and data planes, besides facilitat-ing the network state visualization and the consolidation of several dedicated networkappliances into a single software implementation [Kreutz et al. 2014]. This flexibility isprobably among the main reasons why companies from different segments (e.g., devicemanufacturers, cloud computing providers, among others) are increasingly adopting theSDN paradigm as the main tool for managing their resources in an efficient and cost-effective manner [Kreutz et al. 2014].

1.3.3. Data and Control Planes

Given that the separation between data and control planes is at the core of the SDN tech-nology, it is important to discuss them in some detail. Figure 1.3 shows a simplifiedSDN architecture and its main components, showing that the data and control planes areconnected via a well-defined programming interface between the switches and the SDNcontroller.



Figure 1.3. SDN architecture overview

The data plane corresponds to the switching circuitry that interconnects all de-vices composing the network infrastructure, together with a set of rules that define whichactions should be taken as soon as a packet arrives at one of the device’s ports. Examplesof common actions are to forward the packet to another port, rewrite (part of) its header,or even to discard the packet.

The control plane, on its turn, is responsible for programming and managingthe data plane, controlling how the routing logic should work. This is done by one ormore software controllers, whose main task is is to set the routing rules to be followedby each forwarding device through standardized interfaces, called the southbound inter-faces. These interfaces can be implemented using protocols such as OpenFlow 1.0 and1.3 [OpenFlow 2009, OpenFlow 2012], OVSDB [Pfaff and Davie 2013] and NETCONF[Enns et al. 2011] The control plane concentrates, thus, the intelligence of the network,using information provided by the forwarding elements (e.g., traffic statistics and packetheaders) to decide which actions should be taken by them [Kreutz et al. 2014].

Finally, developers can take advantage of the protocols provided by the controlplane through the northbound interfaces, which abstracts the low-level operations for con-trolling the hardware devices similarly to what is done by operating systems in computingdevices such as desktops. These interfaces can be provided by remote procedure calls(RPC), restful services and other cross-application interface models. This greatly facili-tates the construction of different network applications that, by interacting with the controlplane, can control and monitor the underlying network. This allows them to customize thebehavior of the forwarding elements, defining policies for implementing functions suchas firewalls, load balancers, intrusion detection, among others.



1.3.4. The OpenFlow Protocol

The OpenFlows protocol is one of the most commonly used southbound interfaces, beingwidely supported both in software and hardware, and standardized by the Open Network-ing Foundation (ONF). It works with the concept of flows, defined as groups of packetsmatching a specific (albeit non-standard) header [McKeown et al. 2008], which receivemay be treated differently depending how the network is programmed. OpenFlow’s sim-plicity and flexibility, allied to the high performance at low cost, ability to isolate experi-mental traffic from production traffic, and to cope with vendors’ need for closed platforms[McKeown et al. 2008], are probably among the main reasons for this success.

Whereas other SDN approaches take into account other network elements, suchas routers, OpenFlow focus mainly on switches [Braun and Menth 2014]. Its architecturecomprises, then, three main concepts [Braun and Menth 2014]: (1) the network’s dataplane is composed by OpenFlow-compliant switches; (2) the control plane consists ofone or more controllers using the OpenFlow protocol; (3) the connection between theswitches and the control plane is made through a secure channel.

An OpenFlow switch is basically a forwarding device endowed with a Flow Table,whose entries define the packet forwarding rules to be enforced by the device. To accom-plish this goal, each entry of the table comprises three elements [McKeown et al. 2008]:match fields, counters, and actions. The match fields refer to pieces of information thatidentify the input packets, such as fields of its header or its ingress port. The counters, ontheir turn, are reserved for collecting statistics about the corresponding flow. They can,for example, be used for keeping track of the number of packets/bytes matching that flow,or of the time since the last packet belonging to that flow was seen (so inactive flows canbe easily identified) [Braun and Menth 2014]. Finally, the actions specify how the pack-ets from the flow must be processed, the most basic options being: (1) forward the packetto a given port, so it can be routed to through the network; (2) encapsulate the packet anddeliver it to a controller so the latter can decide how it should be dealt with (in this case,the communication is done through the secure channel); or (3) drop the packet (e.g., forsecurity reasons).

There are two models for the implementation of an OpenFlow switch[McKeown et al. 2008]. The first, consists in a dedicated OpenFlow switch, which isbasically a “dumb” device that only forwards packets according to the rules defined by aremote controller.

In this case (See Figure 1.4), the flows can be broadly defined by the applications,so the network capabilities are only limited by how the Flow Table is implemented andwhich actions are available. The second, which may be preferable for legacy reasons, is aclassic switch that supports OpenFlow but also keeps its ability to make its own forward-ing decisions. In such hybrid scenario, it is more complicated to provide a clear isolationbetween OpenFlow and “classical” traffic. To be able to do so, there are basically twoalternatives: (1) to implement one extra action to the OpenFlow Table, which forwardspackets to the switches normal processing pipeline, or (2) to define different VLANs foreach type of traffic.

Whichever the case, the behaviors of the switch’s OpenFlow-enabled portion may



Figure 1.4. OpenFlow switch proposed by [McKeown et al. 2008].

be either reactive or proactive. In the reactive mode, whenever a packet arrives at theswitch, it tries to find an entry in its Flow Table matching that packet. If such an entryis found, the corresponding action is executed; otherwise, the flow is redirected to thecontroller, which will insert a new entry into the switch’s Flow Table for handling theflow and only then the packet is forwarded according to this new rule. In the proactivemode, on the other hand, the switch’s Flow Table is pre-configured and, if an arriving flowdoes not math any of the existing rules, the corresponding packets are simply discarded[Hu et al. 2014a].

Operating in the proactive mode may lead to the need of installing a large numberof rules beforehand on the switches, one advantage over the reactive mode is that inthis case the flow is not delayed by the controller’s flow configuration process. Anotherrelevant aspect is that, if the switch is unable to communication with the controller in thereactive mode, then the switch’s operation will remain limited to the existing rules, whichmay not be enough for dealing with all flows. In comparison, if the network is designedto work in the proactive mode from the beginning, it is more likely that all flows will behandled by the rules already installed on the switches.

As a last remark, it is interesting to notice that implementing the controller as acentralized entity can provide a global and unique view of the network to all applications,potentially simplifying the management of rules and policies inside the network. How-ever, as any physically centralized server, it also becomes a single point of failure, po-tentially impairing the network’s availability and scalability. This issue can be solved byimplementing a a physically distributed controller, so if one controller is compromised,only the switches under its responsibility are affected. In this case, however, it wouldbe necessary to implement synchronization protocols for allowing a unique view of thewhole network and avoid inconsistencies. Therefore, to take full advantage of the benefitsfrom a distributed architecture, such protocols must be efficient enough not to impact theoverall network’s performance.



1.3.5. SDN Controllers

An SDN controller, also called a network operating system, is a software platform whereall the network control applications are deployed. SDN controllers commonly containa set of modules that provide different network services for the deployed applications,including routing, multicasting, security, access control, bandwidth management, trafficengineering, quality of service, processor and storage optimization, energy usage, andall forms of policy management, tailored to meet business objectives. The network ser-vices provided by the SDN controller consist of network applications running upon thecontroller platform, and can be classified as follows:

• Basic Network Service: Basic network applications that implement protocol,topology and device essential functions. Examples of basic network services are topologymanagement, ARP handling, host tracking, status management and device monitoring.Basic network services are commonly used by other network services deployed in thecontroller platform to implement more complex control functionalities.

• Management Services: Management network applications that make use of ba-sic functions to implement business-centric management functionalities. Examples ofmanagement services are authentication and authorization services, virtual tenant networkcoordination, network bandwidth slicing and network policy management.

• Core Services: Core network applications oriented to manage and orchestratethe operation of the control platform, including managing communication between othernetwork services and shared data resources. Examples of core services are messaging,control database managing and service registering.

• Custom Application Services: Custom network applications consist of any ap-plication developed by the platform users. The applications commonly use other networkservices deployed in the same SDN control platform to implement different network so-lutions. Examples of custom application services oriented toward security are DDoSprevention, load balancing and firewalling. Custom application services can also targetareas such as QoS implementation, enforcement of policies and integration with cloudcomputing orchestration systems.

Open source controllers have been an important vector of innovation in the SDNfield. The dynamics of the open source community led the development of lots of SDNprojets, including software-based switches and SDN controllers [Casado 2015]. To eval-uate and compare different open-source controller solutions and their suitability to eachdeployment scenario, one can employ the following metrics:

• Programming Language: The programming language used to build the con-troller platform. The controller language will also dictate the programming languageused to develop the network services, and can directly influence other metrics such asperformance and learning curve. Moreover, some operating systems may not provide fullsupport for all programming languages.

• Performance: The performance of the controller can be determinant whenchoosing the correct platform for production purposes. The performance of an SDN con-



troller can be influenced by many factors, including the programming language, designpatterns adopted and hardware compatibility.

• Learning Curve: The learning curve of the control platform is a fundamentalmetric to consider when starting a project. It measures the experience necessary to learnthe SDN controller platform and build the necessary skills. The learning curve directlyinfluences the time to develop a project and also the availability of skilled developers.

• Features: The set of network functions provided by the SDN controller. In ad-diction to basic network services, control platforms can also provide specialized servicesrelated to controlling and managing network infrastructures. Two important groups offeatures are the set of protocols supported in the southbound API of the controller (e.g.,OpenFlow, OVSDB, NETCONF), which will determine the supported devices in the un-derlying network infrastructure, and the support for integration with cloud computingsystems.

• Community Support: The support provided by the open source community isessential to measure how easy it would be to solve development and operating questions,as well as the frequency in which new features are released. Some open source SDNprojects are also supported or maintained by private companies, which is likely to accel-erate releases and lead to better support for specific business demands.

To give a concrete example on the usefulness of these metrics, we canapply them to some of the most popular open source SDN controller projects,namely: NOX [Gude et al. 2008, NOXRepo.org 2015], POX [NOXRepo.org 2015],Ryu [Ryu 2015], Floodlight [Floodlight 2015] and OpenDaylight [Medved et al. 2014,Linux Foundation 2015].

NOX Controller: The NOX controller is part of the first generation of OpenFlowcontrollers, being developed by Nicira Networks side-by-side with the OpenFlow proto-col. As the oldest OpenFlow controller, it is considered very stable by the industry and theopen source community, and is largely deployed in production and educational environ-ments. The NOX controller has two versions. The first, NOX-Classic, was implementedin C++ and Phyton, and supports the development of network control application usingboth languages. This cross-language design was later proved to be less efficient than de-signs based on a single language, since it ended up leading to some inconsistency in termsof features and interfaces. Possibly due to these issues, NOX-Classic is no longer sup-ported, being superseded by the second version, called simply NOX or “new NOX”. Thissecond version of NOX was implemented using the C++ programming language, sup-porting network application services developed with the same language using an event-oriented programming model. The code NOX was also reorganized to provide betterperformance and programmability compared with NOX-Classic, introducing support forboth 1.0 and 1.3 versions of the OpenFlow protocol. A modern NOX SDN controller isrecommended when: users know the C++ programming language; users are willing to uselow-level facilities and semantics of the OpenFlow protocol; users need production levelperformance.

POX Controller: POX is a Python implementation of the NOX controller, beingcreated to be a platform for rapid development and prototyping of network control soft-



ware. Taking advantage of Python’s flexibility, POX has been used as basis for many SDNprojects, being applied for prototyping and debugging SDN applications, implementingnetwork virtualization and designing new control and programming models. The POXcontroller has also official support from the NOX community. POX support the version1.0 only of the OpenFlow protocol and provides better performance when compared withPython applications deployed on NOX-Classic. However, since Python is an interpretedinstead of compiled language, POX does not provide production level performance asNOX controller do. Therefore, a POX SDN controller is recommended when: users knowthe Python programming language; users are not much concerned with the controller’sperformance; users need a rapid SDN platform for prototyping and experimentation, e.g.,for research, experimentation, or demonstrations purposes; users are looking for an easyway to learn about SDN control platforms (e.g., for educational purposes).

Ryu Framework: Ryu is a Python component-based SDN framework that pro-vides a large set of network services through a well-defined API, making it easy for devel-opers to create new network management and control applications for multiple networkdevices. Differently from NOX and POX SDN controllers, which support only Open-Flow protocols in their southbound API, Ryu supports various protocols for managingnetwork devices, such as OpenFlow (versions 1.0 and 1.2 – 1.4), Netconf and OF-config.Another important feature of the Ryu framework is the integration with the OpenStackcloud orchestration system [OpenStack 2015], enabling large deployments on cloud datacenters. Even though Ryu was implemented using Python, its the learning curve is mod-erated, since it provides a large set of service components and interfaces that need tobe understood before it can be integrated into new applications. As a result, the RyuSDN framework is recommended when: users know the Python programming language;users are not much concerned with the controller’s performance; the control applicationsrequire versions 1.3 or 1.4 of the OpenFlow protocol or some of the other supported pro-tocols; users intend to deploy the SDN controller on a cloud data center that makes use ofOpenStack’s orchestration system.

Floodlight Controller: The Floodlight Open SDN Controller is a Java-basedOpenFlow Controller supported by an open source community of developers that includesa number of engineers from Big Switch Networks. Floodlight is the core of Big SwitchNetworks commercial SDN products and is actively tested and improved by the industryand the developers community. Floodlight was created as a fork from the Beacon JavaOpenFlow controller [Erickson 2013], the first Java-based controller to implement fullmultithread and runtime modularity features. Even though it has a quite extensive docu-mentation and counts with official support from both the industry and open source com-munity, Floodlight has a steep learning curve due to the large set of features implemented.Among those features, we can cite the ability to integrate with OpenStack orchestrationsystem and the use of RESTful interfaces [Richardson and Ruby 2008] in the northboundAPI, enabling easy integration with external business applications. Floodlight controlleris recommended when: users know the Java programming language; users need pro-duction level performance and would like to have industry support; applications shouldinteract with the SDN controller through a RESTful API; users intend to deploy the SDNcontroller on a cloud data center that makes use of OpenStack’s orchestration system.



OpenDaylight Controller: OpenDaylight is a Java-based SDN controller built toprovide a comprehensive network programmability platform for SDN. It was created asa Linux Foundation collaborative project in 2013 and intends to build a comprehensiveframework for innovation in SDN environment. OpenDaylight project is supported by aconsortium of network companies such as Cisco, Ericsson, IBM, Brocade and VMware,besides the open source community and industry that collaborate in the project. Open-Dayligh is also based on the Beacon OpenFlow controller and provides production levelperformance with support for different southbound protocols, such as OpenFlow 1.0 and1.3, OVSDB and NETCONF. It also provides integration with OpenStack’s cloud or-chestration system. The OpenDaylight controller proposes an architectural framework byclearly defining the southbound and northbound APIs and how they interact with externalbusiness applications and internal network services. A a drawback, OpenDaylight has asteep learning curve due to its architectural complexity and the large set of services em-bedded in the controller. It is, nevertheless, recommended when: users know the Javaprogramming language; users need production level performance and would like to haveindustry support; users intend to deploy the SDN controller on a cloud data center thatmakes use of OpenStack’s orchestration system; target applications require modularitythrough an architectural design; applications need to integrate with third party businessapplications, as well as with heterogeneous underlying network infrastructures.

Table 1.1 presents a summary of the main characteristics of the described opensource SDN controllers, based on the metrics hereby discussed.

Table 1.1. Summary of the main characteristics of open source SDN controllers

NOX POX Ryu Floodlight ODLLanguage C++ Python Python Java Java

Performance High Low Low High High

Distributed No No Yes Yes Yes

OpenFlow 1.0 1.0 1.0, 1.2–1.4 1.0, 1.3 1.0, 1.3

Multi-tenant clouds No No Yes Yes Yes

Learning curves Moderate Easy Moderate Steep Steep

1.3.6. Network Virtualization using SDNs

Even though network virtualization and SDN are independent concepts, the relationshipbetween these two technologies has become much closer in recent years. Network virtual-ization creates the abstraction of a network that is decoupled from the underlying physicalequipment, allowing multiple virtual networks to run over a shared infrastructure with atopology that differs from the actual underlying physical network.

Even though network virtualization has gained prominence as a use case for SDN,the concept has in fact evolved in parallel with programmable networking. In especial,both technologies are tightly coupled by the programmable networks paradigm, whichpresumes mechanisms for sharing the infrastructure (across multiple tenants in a datacenter, administrative groups in a campus, or experiments in an experimental facility) andsupporting logical network topologies that differ from the physical network. In what fol-lows, we provide an overview of the state of the art on network virtualization technologies



before and after the advent of SDN.

The creation of virtual networks in the form of VLANs and virtual private net-works has been supported by multiple network equipment vendors for many years. Thesevirtual networks could only be created by network administrators and were limited to runthe existing protocols, delaying the deployment of new network technologies. As an alter-nate, researchers started building overlay networks by means of tunneling, forming theirown topology on top of a legacy network to be able to run their own control-plane proto-cols. In addition to the significant success of peer-to-peer applications, built upon overlaynetworks, the networking community reignited research on overlay networks as a way ofimproving the network infrastructure. Consequently, virtualized experimental infrastruc-tures such as PlanetLab [Chun et al. 2003] were built to allow multiple researchers to runtheir own overlay networks over a shared and distributed collection of hosts. The successof PlanetLab and other shared experimental network platforms motivated investigationson the creation of virtual topologies that could run custom protocols inside the underlyingnetwork [Bavier et al. 2006], thus enabling realistic experiments to run side by side withproduction traffic. As an evolution of these experimental infrastructures, the GENI project[Berman et al. 2014] took the idea of a virtualized and programmable network infrastruc-ture to a much larger scale, building a national experimental infrastructure for researchin networking and distributed systems. These technologies ended up by leading some toargue that network virtualization should be the basis of a future Internet, allowing mul-tiple network architectures to coexist and evolve over time to meet needs in continuousevolution [Feamster et al. 2007, Anderson et al. 2005, Turner and Taylor 2005].

Researches on network virtualization evolved independently of the SDN con-cept. Indeed, the abstraction of the physical network in a logical network does not re-quire any SDN technology, neither does the separation of a logically centralized con-trol plane from the underlying data plane imply some kind of network virtualization.However, a symbiosis between both technologies has emerged, which has begun to cat-alyze several new research areas, since SDN can be seen as an enabling technology fornetwork virtualization. Cloud computing, for example, introduced the need for allow-ing multiple customers (or tenants) to share a same network infrastructure, leading tothe use of overlay networks implemented through software switches (e.g., Open vSwitch[Open vSwitch 2015, Pfaff et al. 2009]) that would encapsulate traffic destined for VMsrunning on other servers. It became natural, thus, to consider using logically centralizedSDN controllers to configure these virtual switches with the rules required to control howpackets are encapsulated, as well as to update these rules when VMs move to new physicallocations.

Network virtualization, on its turn, can be used for evaluating and testing SDNcontrol applications. Mininet [Handigol et al. 2012a, Lantz et al. 2010], for example,uses process-based network virtualization to emulate a network with hundreds of hosts,virtual switches and SDN controllers on a single machine. This environment enables re-searchers and network operator to develop control logic applications and easily evaluate,test and debug them on a full-scale emulation of the production data plane, accelerat-ing the deployment on the real production networks. Another contribution from networkvirtualization to the development of SDN technologies is the ability to slice the underly-ing network, allowing it to run simultaneous and isolated SDN experiments. This con-



cept of network slicing, originally introduced by the PlanetLab project [Chun et al. 2003],consists in separate the traffic-flow space into different slices, so each slice has a shareof network resources and can be managed by a different SDN controller. FlowVisor[Sherwood et al. 2010], for example, provides a network slicing system that enablesbuilding testbeds on top of the same physical equipment that carries the production traf-fic.

1.3.7. SDN Applications in Network Virtualization

SDN facilitates network virtualization and may, thus, makes it easier to implement fea-tures such as dynamic network reconfiguration (e.g., in multitenant environments). How-ever, it is important to recognize that the basic capabilities of SDN technologies do notdirectly provide these benefits. Some SDN features and their main contributions to im-prove network virtualization are:

• Control plane and data plane separation: The separation between control anddata planes in SDN architectures, as well as the standardization of interfaces for the com-munication between those layers, allowed to conceptually unify different vendor networkdevices under the same control mechanisms. For network virtualization purposes, theabstraction provided by the control plane and data plane separation facilitates deploying,configuring, and updating devices across virtualized network infrastructures. The controlplane separation also introduces the idea of network operating systems, which consistsof a scalable and programmable platform for managing and orchestrating virtualized net-works.

• Network programmability: Programmability of network devices is one of themain contributions from SDN to network virtualization. Before the advent of SDN, net-work virtualization was limited to the static implementation of overlay technologies (suchas VLAN), a task delegated to network administrators and logically distributed amongthe physical infrastructure. The programming capabilities introduced by SDN provide thedynamics necessary to rapidly scale, maintain and configure new virtual networks. More-over, network programmability also allows the creation of custom network applicationsoriented to innovative network virtualization solutions.

• Logically centralized control: The abstraction of data plane devices provided bySDN architecture gives the network operating system, also known as SDN orchestrationsystem, a unified view of the network. Therefore, it allows custom control applications toaccess the entire network topology from a logically centralized control platform, enablingthe centralization of configurations and policy management. This way, the deploymentand management of network virtualization technologies becomes easier than in early dis-tributed approaches.

• Automated management: the SDN architecture enhances network virtualizationplatforms by providing support for automation of administrative tasks. The centralizedcontrol and the programming capabilities provided by SDN allow the development ofcustomized network applications for virtual network creation and management. Auto-scaling, traffic control and QoS are examples of automation tools that can be applied tovirtual network environments.



Among the variety of scenarios where SDN can improve network virtualizationimplementations, we can mention campus network testbeds [Berman et al. 2014], enter-prise networks [Casado et al. 2007], multitenant data centers [Koponen et al. 2014] andcloud networking [Jain and Paul 2013b]. Despite this successful application of SDNtechnologies in such network virtualization use cases scenarios, however, much work isneeded both to improve the existing network infrastructure and to explore SDN’s poten-tial for solving problems in network virtualization. Examples include SDN applications toscenarios such as home networks, enterprise networks, Internet exchange points, cellularnetworks, Wi-Fi radio access networks, and joint management of end-host applications.

1.3.8. Security, Scalability and Availability aspects

Since the SDN concept became a prominent research topic in the area of computer net-works, many studies have discussed fundamental aspects such as its scalability, availabil-ity and, in especial, security.

Even though scalability issues apply both to the controller and to forwardingnodes, the latter are not specifically affected by the SDN technology and, thus, we onlyfocus on the former. Specifically, there are three main challenges for attaining controllerscalability [Yeganeh et al. 2013, Sezer et al. 2013], both of which originate in the factthe network’s intelligence is moved from the distributed forwarding nodes to the controlplane: (1) the latency incurred by the communications between the forwarding nodes andthe controller(s); (2) the size of the controller’s flow database, and (3) the communicationbetween controllers in a physically distributed control plane architecture. As previouslymentioned in Section 1.3.4, the first challenge may be tackled with proactive approach,i.e., by installing most flow rules on the SDN-enable switches so they do not need to con-tact the controllers too frequently. Even though this might sacrifice flexibility, this maybe inevitable especially for large flows.

Another strategy for tackling latency issues in the control plane, as well as the sizeof the flow databases, consists in using multiple controllers. As a result, they can share thecommunication burden, reducing delays potentially caused by queuing requests comingfrom switches, and also the storage of flow information, as each controller is responsibleby a subset of forwarding elements. However, this also aggravates the third challenge,due to the need of further interactions between controllers to ensure a unified view ofthe network [Sezer et al. 2013]. Nonetheless, since a distributed controller architecturealso improves availability by improving the system’s resiliency to failures, there havebeen many proposals focused on improving the scalability of this approach. One exampleis HyperFlow [Tootoonchian and Ganjali 2010], an NOX-oriented application that can in-stalled on all network controllers to create a powerful event propagation system based on apublish/subscribe messaging paradigm: basically, each controller publishes events relatedto network changes to other controllers, which in turn replay those events to proactivelypropagate the information throughout the whole control plane. Another strategy, adoptedin Onix [Koponen et al. 2010] and ONOS [Berde et al. 2014], consists in empoweringcontrol applications with general APIs that facilitate access to network state information.All things considered, ensuring scalability and state consistency among all controllers, aswell as a reasonable level of flexibility, ends up being an important design trade-off inSDNs [Yeganeh et al. 2013].



Regarding security, the SDN technology brings both new opportunities and chal-lenges (for a survey on both views, see [Scott-Hayward et al. 2013]). On the posi-tive side, SDN can enhance network security when the control plane is seen as a toolfor packet monitoring and analysis that is able to propagate security policies (e.g.,access control [Nayak et al. 2009]) along the entire network in response to attacks[Scott-Hayward et al. 2013]. In addition, with the higher control over how the packetsare routed provided SDN, one can install security appliances such as firewalls and IDSin any part of the network, not only on its edges [Gember et al. 2012]: as long as thecontrollers steer the corresponding traffic to those nodes, the packets can be analyzedand treated accordingly. This flexibility is, for example, at the core of the Software De-fined Perimeter (SDP) concept [Bilger et al. 2013], by means of which all devices tryingto access a given network infrastructure must be authenticated and authorized before theflow rules that allows its entrance are installed in the network’s forwarding elements. Itis also crucial to thwart denial-of-service (DoS) attacks, since then the task of discardingmalicious packets is not concentrated on one or a few security devices near the attack’starget, but distributed along the network [YuHunag et al. 2010]. Another interesting ap-plication of SDNs for thwarting DoS, as well as other threats targeting a same static IP(e.g. port scanning or worm propagation), is to create the illusion of a “moving target”,i.e., by having the SDN translate the host’s persistent address to different IPs over time[Jafarian et al. 2012].

Whereas the security enhancements resulting from the SDN approach is com-monly recognized, it also brings security risks that need to be addressed. In[Kreutz et al. 2013], seven main threat vectors are identified, the first three being SDN-specific: (1) attacks on control plane communications, especially when they are madethrough insecure channels; (2) attacks on and vulnerabilities in controllers, (3) lack ofmechanisms to ensure trust between the controller and management applications; (4)forged traffic flows; (5) attacks exploring vulnerabilities in switches; (6) attacks on andvulnerabilities in administrative stations that access the SDN controllers, and (7) thelack of trusted resources for forensics and remediation. Such threats usually requireholistic solutions providing authentication and authorization mechanisms for handlingthe different entities configuring the network and detecting anomalies. This need is ad-dressed, for example, by the FortNOX security kernel [Porras et al. 2012], as well asby its successor, Security-Enhanced Floodlight [Porras et al. 2015], which enable au-tomated security services while enforcing consistency of flow policies and role-basedauthorization; it is also the focus of FRESCO [Shin et al. 2013], an application frame-work that facilitates the development and deployment of security applications in Open-Flow Networks. There are also solutions focused on specific issues, such as identify-ing conflicts and inconsistencies between the policies defined by multiple applications[Al-Shaer and Al-Haj 2010, Canini et al. 2012, Khurshid et al. 2013] or facilitating au-diting and debugging [Handigol et al. 2012b, Khurshid et al. 2013]. Nevertheless, thereis much place for innovation in the field, as the number of articles proposing solutions forSDN security issues are still considerably less prevalent in the literature than those focus-ing on using the SDN paradigm to provide security services [Scott-Hayward et al. 2013].



1.4. Cloud Network Virtualization using SDNThis section discusses the connection between cloud computing and SDNs. We starting byanalyzing the synergy between the concepts and technologies involving both paradigms.We then describe an integration architecture that takes advantage of this synergy for de-ploying new services (namely, Network- and Security-as-a-Service), which may be inte-grated with Network Function Virtualization (NFV) technologies.

1.4.1. Synergy between SDNs and clouds

As previously discussed, networking plays a key role in clouds, both as a shared resourceand as part of the infrastructure needed for sharing other computational resources. As anyinfrastructure, the network in a cloud environment should attend some critical require-ments of modern networks, in especial [Cheng et al. 2014]: adaptability to new appli-cation needs, business policies, and traffic behavior, which new feature being integratedwith minimal disruption of the network operation; automation of network changes prop-agation, reducing (error-prone) manual interventions; provision of high level abstractionsfor easier network management, so administrators do not need to configure each indi-vidual network element; capability of accommodating the nodes’ mobility and securityfeatures as a core service, rather than as add-on solutions; and on-demanding scaling.

To fulfill these requirements, cutting-edge network equipments with advanced ca-pabilities are likely to be needed. Nevertheless, the cloud cannot take full advantage ofsuch resources without orchestration engines with deep knowledge of the available net-work capabilities. Unfortunately, such deep knowledge may require features that are veryspecific to a given proprietary network hardware and software, leading to vendor lock-in issues and, consequently, limiting the creation of new network features or services.In addition, it is often the case that the services must be orchestrated over multi-carrierand multi-technology communication infrastructure (e.g., composed by packet switching,circuit switching and optical transport networks) [Autenrieth et al. 2013], or even amongdifferent cloud providers [Mechtri et al. 2013]. SDNs tackle this issue by placing an ab-straction layer with standard APIs over the (proprietary) hardware, facilitating the accessto the corresponding features and, thus, to innovations. In an environment as dynamic asthe cloud, the flexibility and programmability provided by SDNs is essential to allow thenetwork to evolve together with the services using it.

1.4.2. Integration Architectures

SDNs and clouds display similar designs, with a 3-layer architecture composed by a In-frastructure Layer with computational resources controlled by a Control Layer, which inturn is controlled via APIs by applications in an Application Layer (see Figure 1.5). Onesimple form of integrating SDNs and clouds is to run their stacks in parallel, with bothtechnologies being integrated by the applications themselves. Even though applicationscan benefit from both technologies with this strategy, it also brings a significant overheadto application developers. After all, applications would need to be SDN- and cloud-aware,assimilating and accessing APIs for both technologies in an effective manner, which isprone to complicate their design and implementation.

To avoid these issues, an alternative approach would be to use a special cloud



Figure 1.5. SDN/Cloud Integration by applications. Adapted from [Autenrieth et al. 2013]

control/orchestration subsystem capable of controlling SDN devices directly, using SDNdata plane control protocols (e.g. OpenFlow) instead of a separate SDN controller. Thisstrategy, illustrated in Figure 1.6, brings some SDN benefits to the cloud infrastructurewhile hiding its complexity to applications: they would need to use only cloud APIs,remaining unaware of the SDN-enabled network infrastructure. Nevertheless, there arealso some drawbacks: as it demands a specialized cloud orchestrator, development of newnetwork control features is tied to the development of the orchestrator itself, or to the APIsit provides, possibly limiting innovation It may also restrict the deployment of proprietarySDN solutions.

Figure 1.6. SDN Functions incorporated in the Cloud Control/Orchestration subsystem

Finally, a third and probably preferable is to consider the cloud control/orchestra-



tion system as an SDN application to the SDN controller. In this scenario, depicted inFigure 1.7, the Cloud Control/Orchestration subsystem is augmented with modules thattranslate Cloud Operations to SDN operations, using existing SDN controllers APIs. Thisapproach brings the benefits of the second approach while allowing greater flexibility: itis possible to evolve both the Cloud and SDN infrastructures separately, with minimal orno changes to their integration interface. It would also allow the use of existing SDN so-lutions without alterations, including proprietary SDN solutions or hardware-based con-trollers.

Figure 1.7. SDN Integration inside the Cloud

1.4.3. Network as a Service (NaaS) supported by SDN

In a cloud computing environment, users (tenants) are provisioned with virtual compu-tational resources, including virtual networks, by the cloud orchestrator. Usually, thesevirtual networks are also used as an infrastructure for the other computational resources.There are, however, some limitations with this approach [Costa et al. 2012]: little or nocontrol over the network; indirect access or management to the network infrastructure(i.e., switches or routers); limited visibility over the network resources; inefficient over-lay networks; no multicast support. To face these shortcomings, it is possible to sharenetworking resources as services, similarly to that is done with computational resources.This model is called Network-as-a-Service (NaaS) [Costa et al. 2012].

In NaaS, networking resources are used and controlled through standard inter-faces/APIs. In principle, a network service may represent any type of networking com-ponent at different levels, including a domain consisting of a set of networks, a singlephysical or virtual network, or an individual network node. Multiple network services canthen be combined into a composite inter-network service by means of a service compo-sition mechanism [Duan 2014]. NaaS and SDN can, thus, be combined: while the SDNtechnology provides dynamic and scalable network service management and facilitatesthe implementation of NaaS, the latter allows a control mechanism over a (possibly het-erogeneous) underlying network infrastructure. This approach also enables the creation



of richer NaaS services: if a given feature is not fully implemented on the underlying net-work, it can be implemented as a SDN application inside the cloud control/orchestrationlayer and offered to users via cloud APIs.

One possible solution for offering NaaS services through the combination of SDNand Cloud Computing is the OpenNaaS project1. It offers an open source framework forhelping creating different types of network services in an OpenStack cloud computingenvironment. The framework provides a virtual representation of physical resources (e.g.,networks, routers, switches, optical devices or computing servers), which can be mappedinside OpenNaaS to SDN resources for the actual implementation of these networkingelements [Aznar et al. 2013].

1.4.4. Security as a Service (SecaaS) using SDN

Security as a Service (SecaaS) refers to the provision of security applications and ser-vices via the cloud, either to cloud-based infrastructure and software, or to customers’on-premise systems [CSA 2011]. To consume cloud security resources, end-users mustbe aware of the nature and limitations of this new computing paradigm, whereas cloudproviders must take special care when offering security services. Aiming to provide guid-ance for interested users and providers, the Cloud Security Alliance (CSA) has publishedsecurity guides that, based on academic results, industry needs and end-user surveys, dis-cuss the main concerns that SecaaS applications must deal with [CSA 2011]:

• Identity and Access Management (IAM): refers to controls for identity verifica-tion and access management.

• Data Loss Prevention: related to monitoring, protecting and verifying the secu-rity of data at rest, in motion and in use.

• Web Security: real-time protection offered either on-premise, through soft-ware/appliance installation, or via the cloud, by proxying or redirecting web traffic tothe cloud provider.

• Email Security: control over inbound and outbound email, protecting the orga-nization from phishing or malicious attachments, as well as enforcing corporate polices(e.g., acceptable use and spam prevention), and providing business continuity options.

• Security assessments: refers to third-party audits of cloud services or assess-ments of on-premises systems.

• Intrusion Management: using pattern recognition to detect and react to statisti-cally unusual events. This may include reconfiguring system components in real time tostop or prevent an intrusion.

• Security Information and Event Management (SIEM): analysis of logs and eventinformation analysis aiming to provide real-time reporting and alerting on incidents thatmay require intervention. The logs are likely to be kept in a manner that prevents tamper-ing, thus enabling their use as evidence in any investigations.

• Encryption: providing data confidentiality by means of encryption algorithms.

1Projet home page: http://opennaas.org



• Business Continuity and Disaster Recovery: refers to measures designed andimplemented to ensure operational resiliency in the event of service interruptions.

• Network Security: security services that allocate, access, distribute, monitor,and protect the underlying resource services.

Security service solutions for the Internet can be commonly found nowadays, inwhat constitutes a segmentation of the Software as a Service (SaaS) market. This can beverified, for example, in sites that provide credit card payment services, that offer onlinesecurity scanning (e.g. anti-malware/anti-spam) to a user’s personal computer, or evenon Internet access providers that offer firewall services to its users. These solutions areclosely related to the above-mentioned Web Security, Email Security and Intrusion Man-agement categories, and have as main vendors Cisco, McAfee, Panda Software, Syman-tec, Trend Micro and VeriSign [Rouse 2010].

However, this kind of services has been deemed insufficient to attract the trust ofmany security-aware end-users, especially those that have knowledge of cloud inner work-ings or are in search of IaaS services. Aiming to attract this audience and, especially, toimprove cloud internal security requirements, organizations have been investing in SDNsolutions capable of improving security on (cloud) virtual networks. To cite a recentexample of cloud-oriented SDN firewall, we can mention Flowguard [Hu et al. 2014b]Besides basic firewall features, Flowguard also provides a comprehensive framework forfacilitating detection and resolution of firewall policy violations in dynamic OpenFlow-based networks: security policy violations can be detected in real time, when the networkstatus is updated, allowing a (tenant or cloud) administrators to decide whether to adoptdistinct security strategies for each network state [Hu et al. 2014b].

Another recent security solution is Ananta [Patel et al. 2013], an SDN-based loadbalancer for large scale cloud computing environments. In a nutshell, the solution consistsof a layer-4 load balancer that, by placing one agent in every host, allows packet modifi-cation tasks to be distributed along the network, thus improving scalability Finally, for thepurpose of detecting or preventing intrusions, one recent solution is the one introduced in[Xiong 2014], which can be seen as an SDN-based defensive system for detection, anal-ysis, and mitigation of anomalies. Specifically, the proposed solution takes advantage ofthe flexibility, compatibility and programmability of SDN to propose a framework witha Customized Detection Engine, Network Topology Finder, Source Tracer and furtheruser-developed security appliances, including protection against DDoS attacks.

1.4.5. Integration with Network Function Virtualization (NFV) Technologies

The specifications of NFV are being developed by the European TelecommunicationsStandards Institute (ETSI). Their main goal is to transform the way that operators de-sign their networks, by using standard IT virtualization technologies to consolidate net-work equipments onto industry-standard high volume servers, switches and storage de-vices, which could be located in data centers, network nodes or in the end-user premises[ETSI 2012]. The idea behind NFV is to allow the implementation of network functions(e.g., routing, firewalling, and load-balancing), normally deployed in proprietary boxes,in the form of software that can run on standard server hardware. As any software, the



network function could then be instantiated in (or moved to) any location in the network,as illustrated in Figure 1.8. The NFV Infrastructure (NFVI) could then provide computingcapabilities comparable to an those of an IaaS cloud computing model, as well as dynamicnetwork connectivity services similar to those provided by the NaaS concept discussed inSection 1.4.3.

Figure 1.8. Concept of NFV [Jammal et al. 2014]

It is interesting to notice that, although the NFV and SDN concepts are consideredhighly complementary, they do not dependent on each other [ETSI 2012]. Instead, bothapproaches can be combined to promote innovation in the context of network: the ca-pability of SDN to abstract and programmatically control network resources are featuresthat fit well to the need of NFV to create and manage a dynamic and on-demand networkenvironment with performance. This synergy between these concepts has lead ONF andETSI to work together with the common goal of evolving both approaches and provide astructured environment for their development. Table 1.2 provides a comparison betweenboth SDN and NFV concepts.

Table 1.2. Comparison between SDN and NFV (Adapted from [Jammal et al. 2014]).

SDN NFVMotivation Decoupling of control and data planes; Pro-

viding centralized controller and networkprogrammability

Abstraction of network functions from dedi-cated hardware appliances to Commercial off-the-shelf (COTS) servers

Network Loca-tion

Data centers Service provider networks

Network Devices Servers and switches Servers and switches

Protocols OpenFlow Not Applicable

Applications Cloud orchestration and networking Firewalls, gateways, content delivery networks

StandardizationCommittee

Open Networking Forum (ONF) ETSI NFV group

1.5. Case Study with OpenDaylight and OpenStackThis section presents a a case study involving the creation and management of virtualnetworks using the OpenDaylight SDN controller and the OpenStack cloud orchestra-tion system, both open source projects widely adopted by academia and industry. After



presenting the main virtualization components provided by each system, as well as theirfunctions and interfaces, we propose a practical analysis toward their integration for build-ing a consistent and fully functional cloud virtual networking environment.

1.5.1. OpenStack Cloud Operating System

OpenStack [OpenStack 2015] is a cloud computing project created in 2010, derived fromNASA RackSpace initiative. The project is part of an effort to create an open-source,standards-based, highly-scalable, and advanced cloud computing platform that can bedeployed on commodity server hardware [OpenStack 2015, Wen et al. 2012]. All Open-Stack code is, thus, open for anyone wishing to build and provide cloud computing ser-vices, as well as to create applications on top of the platform.

In its current version (named Juno), the OpenStack platform is composed of 11core components, listed and briefly described in Table 1.3.

Table 1.3. Components of OpenStack Juno and their functions.

Service Code-Name Description

Cloud Management Nova Controls the IaaS infrastructure, allocating or releasing computational resources,such as network, authentication, among others.

Network Service Neutron Provisions network services for Nova-managed components. Specifically, al-lows users to create and attach virtual Network Interface Cards (vNICs) to thesecomponents.

Object Storage Swift Allows the storage and retrieval of files not mounted on directories. It is a long-term storage system for static or permanent data.

Block Storage Cinder Provides block storage for VMs.Identity Service Keystone Provides authentication and authorization to all OpenStack services.Image Service Glance Provides a catalog and repository for virtual disk images managed by Nova.Control Panel /Dashboard

Horizon Provides a web interface for all OpenStack components, allowing their manage-ment straight from a common web browser.

Accounting Ceilometer Monitors OpenStack components, providing metrics that can be used for gener-ating usage statistics, billing or performance monitoring, among others.

Orchestration Heat Orchestrates the cloud, allowing the management of the other components froma single interface

Database Trove Provides relational and non-relational databases to the cloud.Elastic Map Reduce Sahara Creates and manages Hadoop clusters from a set of user-defined parameters,

such as Hadoop version, cluster topology, hardware details, among others.

1.5.2. OpenStack Neutron

Neutron is OpenStack’ component responsible for providing network services for tenantinfrastructures, virtualizing and managing network resources operated by other Open-Stack modules (e.g., Nova’s computing services). Neutron implements the virtualizationlayer over the network infrastructure in the OpenStack system, providing a pluggable,scalable and API-driven system for managing networks. As such, it must ensure thatthe network does not become the bottleneck in a cloud deployment and provision a self-service environment for users. The main Neutron service capabilities are described asfollows.

• Provides flexible networking models, suiting the needs of different applicationsor user groups. Standard models include flat networks or VLANs for separation of net-works and traffic flows.



• Manages IP addresses, allowing dedicated static IPs or DHCP service. FloatingIPs allow traffic to be dynamically rerouted to any compute resource, so users can havetheir traffic redirected during maintenance procedures or in the case of failures.

• Creates tenant networks, controls traffic and connects servers and devices toone or more networks.

• Provides a pluggable back-end architecture that allow users to take advantageof commodity gear or advanced networking services from third party vendors.

• Integrates with SDN technology such as OpenFlow, facilitating configurationand management of large-scale multitenant networks.

• Provides an extension framework that allows the deployment of additional net-work services, such as intrusion detection systems (IDS), load balancing, firewalls andvirtual private networks (VPN).

1.5.2.1. Components

The Neutron service comprises several components. To explain how these componentsare deployed in an OpenStack environment, it is useful to consider a typical deploymentscenario with dedicated nodes for network, compute and control services, as shown inFigure 1.9. The roles of each Neutron component illustrated in this figure are:

Figure 1.9. Neutron components in an OpenStack deployment with a dedicatednetwork node [OpenStack 2015].

• neutron-server: The Neutron server component provides the APIs for all net-



work services implemented by Neutron. In the deployment shown in Figure 1.9, thiscomponent is located inside the cloud controller node, the host responsible to provide theAPIs for all the OpenStack services running inside the cloud through the API network.The controller node can provide API access for both the other OpenStack and the endusers of the cloud, respectively through the management network and the internet.

• neutron-*-plugin-agent:Neutron plug-in agents implement the network servicesprovided by the Neutron API, such as layer 2 connectivity and firewall. The plug-ins aredistributed among network and compute nodes and provide different levels of networkservices for the OpenStack cloud infrastructure.

• neutron-l3-agent: The Neutron L3 agent is the component that implementsNeutron API’s layer 3 connectivity services. It connects tenant VMs via layer 3 net-works, including internal and external networks. The Neutron L3 agent is located on thenetwork node, which is connected to the Internet via the External network.

• neutron-dhcp-agent: The Neutron DHCP agent provides dynamic IP distribu-tion for tenant networks. It also implements the floating IP service, which provides exter-nal IP addresses for tenant VM, enabling Internet connectivity. It is also located on thenetwork node and connected to the Internet via the External network.

Figure 1.9 also depicts a standard deployment architecture for physical data centernetworks, which are:

• Management Network: Provides internal communication between OpenStackcomponents. IP addresses on this network should be reachable only within the data center.

• Data Network: Provides VM data communication within the cloud deployment.The IP addressing requirements of this network depend on the Networking plug-in beingused.

• External Network: Provides VMs with Internet access in some deployment sce-narios. Anyone on the Internet can reach IP addresses on this network.

• API Network: Exposes all OpenStack APIs, including the Networking API, totenants. IP addresses on this network should be reachable by anyone on the Internet. TheAPI network might be the same as the External network, as it is possible to create anexternal-network subnet that has allocated IP ranges that use less than the full range of IPaddresses in an IP block.

Besides these components and physical networks, Neutron makes use of virtu-alized network elements such as virtual switches and virtual network interfaces to pro-vide connectivity to tenant VMs. The concept of bridges is particularly important here:bridges are instances of virtual switches implemented by a software such as Open vSwitch[Open vSwitch 2015, Pfaff et al. 2009] and used to deploy network virtualization for ten-ant VMs. There are three types of bridges created and managed by Neutron in an Open-Stack deployment:

• br-int: Integration bridges provide connectivity among VMs running in thesame compute node, connecting them via their virtual network interfaces.



• br-tun: Tunneling bridges provide connectivity among different compute nodesby using a layer 2 segmentation mechanism, such as VLAN [IEEE 2014], or a tunnelingprotocol such as GRE [Farinacci et al. 2000] or VXLAN [Mahalingam et al. 2014a].

• br-ex: External bridges provide tenant VMs with connectivity to the externalnetwork (Internet) by using Neutron routing services.

1.5.2.2. Communication Flows

The connectivity architecture provided by Neutron, with the relationships between VMs,physical nodes and VMs, is illustrated in Figure 1.10. In this figure, it is assumed thesame deployment scenario presented in Figure 1.9, focusing on the network and computenodes of the OpenStack infrastructure.

Figure 1.10. Implementation of virtual networks using neutron and virtual switches.

To facilitate the discussion VMs’ communication flows, it is useful to separate theexplanation in three different scenarios, Intra-node communication, Inter-VM communi-cation and Internet communication, which are described in what follows.

• Intra-node communication: The scenario where VMs communicate with eachother inside the same compute node (e.g., VM1-to-VM2). In this case, the traffic sent byVM1 is forwarded to VM2 using the integration bridge (br-int). The forward rule in br-intis configured inside the the compute node virtual switch’s flow table, using OpenFlow.

• Inter-VM communication: The scenario where VMs located different computenodes communicate with each other (e.g., VM1-to-VM3). In this case, VM1’s trafficis sent to br-int, which forwards the traffic to the tunneling bridge (br-tun), where it isencapsulated using a tunneling protocol (e.g., GRE or VXLAN) and sent through the data



network to the other compute node. When the traffic arrives at the destination computenode, it is decapsulated by br-tun and forwarded to the br-int bridge, from which it isfinally send to VM3.

• Internet communication: The scenario where a VM communicates with theoutside world (e.g., VM1 to the Internet). Similarly to the previous scenario, in this casethe traffic originated in VM1 is sent to br-int, forwarded to br-tun for encapsulation witha tunneling protocol, and sent via the data network to the network node. There, the trafficis decapsulated on the network node’s br-tun and forwarded to the br-int bridge, whichmakes use of the routing services provided by Neutron and forward the traffic to theinternet. This communication model involves at least one compute node and one networknode.

Other two important components of the Neutron networking are the networknode’s router and dhcp components (see Figure 1.10). They are implemented by meansof network namespace, which is a kernel facility that allows groups of processes to havea network stack (interfaces, routing tables, iptables rules) distinct from that of the under-lying host. More precisely, a Neutron router is a network namespace with a set of routingtables and iptables rules that handle the routing between subnets, while the DHCP serveris an instance of the dnsmasq software running inside a network namespace, providingdynamic IP distribution or floating IPs for tenant networks.

1.5.3. Neutron Plugin: Modular Layer 2 (ML2)

Neutron plugins are fundamental components in the OpenStack network architecture, asthey are responsible for implementing the entire set of network services provided by theNeutron API. The plugins are segmented according to the different network services pro-vided, with each service being implemented by a Neutron plugin. In Neutron, they canbe classified into two main categories: core plugins, which implement core layer 2 con-nectivity services; and service plugins, which provide additional network services such asload balancing, firewall and VPN.

Figure 1.11 shows Neutron’s control flow when handling network service re-quests. After receiving a request from the Neutron API, a neutron plugin executes therequested operation over the cloud network by using neutron plugin agents, hardware andsoftware appliances and external network controllers. Some of Neutron’s network pluginsare able to implement API requests using different back-ends, delegating the actual exe-cution to drivers, such as the Modular Layer 2 (ML2), Firewall, Load Balancing and VPNplugins. In particular, the ML2 plugin plays a key role in our the experimental scenariohereby discussed, so it is worthy detailing it further.

The ML2 plugin is a framework that allows OpenStack Networking to simultane-ously use the variety of layer 2 networking technologies found in real-world data centers.It currently works with openvswitch, linuxbridge, and hyperv L2 agents, and is intendedto replace and deprecate the monolithic plugins associated with those L2 agents (moreprecisely, starting with OpenStack’s Havana release, openvswitch and linuxbridge mono-lithic plugins are being replaced by equivalent ML2 drivers). The ML2 framework isalso intended to simplify the task of adding support for new L2 networking technologies,



Figure 1.11. Execution workflow for Neutron network services

requiring less initial and ongoing effort than adding a new monolithic core plugin.

Figure 1.12. Overall architecture of Neutron ML2 plugin.

Figure 1.12 presents the overall architecture of the Neutron ML2 plugin. As thename implies, the ML2 framework has a modular structure, composed of two differentset of drivers: one for the different network types (TypeDrivers) and another for the dif-ferent mechanisms for accessing each network type, as multiple mechanisms can be usedsimultaneously to access different ports of the same virtual network (MechanismDriver).Mechanisms can access L2 agents via remote procedure calls (RPC) and/or use mecha-nism drivers to interact with external devices or controllers.

• Type drivers: Each available network type is managed by an ML2 TypeDriver.TypeDrivers maintain any needed type-specific network state, and perform provider net-work validation and tenant network allocation. ML2 plugin currently includes drivers forlocal, flat, VLAN, GRE and VXLAN network types.

• Mechanism drivers: The MechanismDriver is responsible for taking the in-formation established by the TypeDriver and ensuring that it is properly applied, given



Figure 1.13. Overview of OpenDaylight functions and benefits

the specific networking mechanisms that have been enabled. The MechanismDriver in-terface currently supports the creation, update, and deletion of network resources. Forevery action taken on a resource, the mechanism driver exposes two methods: a precom-mit method (called within the database transaction context) and a postcommit method(called after the database transaction is complete). The precommit method is used bymechanism drivers to validate the action being taken and make any required changes tothe mechanism driver’s private database, while the postcommit method is responsible forappropriately pushing the change to the resource or to the entity responsible for applyingthat change.

The ML2 plugin architecture facilitates the type drivers to support multiple net-working technologies, and mechanism drivers to facilitate the access to the networkingconfiguration in a transactional model.

1.5.4. OpenDaylight SDN Controller

Created in April 2013 as a Linux Foundation collaborative project, OpenDaylight is anopen source OpenFlow controller and also a scalable SDN framework for the developmentof several network services, including data plane protocols. As such, OpenDaylight canbe the core component of any SDN architecture. Figure 1.13 shows an overview of themain functions and benefits provided by the OpenDaylight framework.

The OpenDaylight architecture follows the traditional SDN design, implementingthe control layer as well as the northbound and southbound interfaces. However, differ-ently from the majority of controllers, the OpenDaylight architecture clearly separates itsdesign and implementation aspects. Figure 1.14 presents an overview of the OpenDay-light architecture on the Helium release.

The OpenDaylight SDN controller is composed by the following architectural lay-ers:

• Network Applications, Orchestration and Services: Business applicationsthat make use of the network services provided by the controller platform to implementcontrol, orchestration and management applications.

• Controller Platform: Control layer that provides interfaces for all the networkservices implemented by the platform via a REST northbound API. The controller plat-



Figure 1.14. OpenDaylight architecture overview [Linux Foundation 2015]

form also implements a service abstraction layer (SAL), which provides a high-level viewof the data plane protocols to facilitate the development of control plane applications.

• Southbound Interfaces and Protocol Plugins: Southbound interfaces containthe plugins that implement the protocols used for programming the data plane.

• Data Plane Elements: Physical and virtual network devices that compose thedata plane and are programmed via the southbound protocol plugins. The variety ofsouthbound protocols supported by the OpenDaylight controller allows the deploymentof network devices from different vendors in the underlying network infrastructure.

The service abstraction layer (SAL) is one of the main innovations of the Open-Daylight architecture To enable communication between plugins, this message exchangemechanism ignores the role of southbound and northbound plugins and builds uponthe definition of Consumer and Provider plugins (see Figure 1.15): providers are plu-gins that expose features to applications and other plugins through its northbound API,whereas consumers are components that make use of the features provided by one or moreProviders. This change implies that every plugin inside OpenDaylight can be seen as botha provider and a consumer, depending only on the messaging flow between the pluginsinvolved.

In OpenDaylight, SAL is responsible for managing the messaging between all theapplications and underlying plugins. Figure 1.16 shows the life of a package inside theOpenDaylight architecture, depicting the following steps:

1. A packet arriving at Switch1 is sent to the appropriate protocol plugin;



Figure 1.15. Communication between producer and consumer plugins using SAL.

Figure 1.16. Life of a package in OpenDaylight.



Figure 1.17. Execution flow for Neutron API request.

2. The plugin parses the packet and generates an event for SAL;

3. SAL dispatches the packet to the service plugins listening for DataPacket;

4. Module handles the packet and sends is out via the IDataPacketService;

5. SAL dispatches the packet to the southbound plugins listening for DataPacket;

6. OpenFlow message sent to appropriate switch

1.5.5. Integration Architecture

The OpenStack cloud orchestration system and OpenDaylight SDN controller are inte-grated via a Neutron ML2 mechanism driver called ODL (acronym for OpenDayLight).This driver executes the layer 2 connectivity services provided by the Neutron API, aswell as a Neutron service application running inside the OpenDaylight controller. Thecontroller, in its turn, makes use of other OpenDaylight service applications to performthe requested actions over the layer 2 network.

Figure 1.17 illustrates the execution flow of a request from the Neutron L2 APIto the OpenDaylight controller. After receiving the request from Neutron L2 API, theML2 plugin selects the ODL mechanism driver based on Neutron static configurationfiles and calls the driver’s methods with the parameters necessary for fulfilling the re-quest. The ODL driver then implements the ML2 service methods by sending commandsto the OpenDaylight controller via a Neutron REST API. Neutron REST API extends theOpenDaylight REST API to incorporate Neutron service features. Figure 1.18 depicts theexecution flow inside the SDN controller. Inside OpenDaylight, the request is forwardedto the the Neutron service application, which in turn executes the necessary actions overthe data plane using the southbound protocol plugins, communicating with them via SAL.The southbound protocol plugins implement the communication protocols necessary fordata plane programming, such as OpenFlow and OVSDB; for example, in the case ofOpenStack, this programming refers mainly to the Open vSwitch bridges detailed in Sec-tion 1.5.2.



Figure 1.18. Execution flow for ODL requests inside the OpenDaylight controller.

Table 1.4. Hardware and software requirements for the OpenStack nodes.

1.5.6. Deploying Cloud Networking with OpenStack and OpenDaylight

In what follows, we conduct a simple and didactic experiment showing how to build anarchitecture that bring the benefits of SDN to cloud computing systems. For this, we useOpenStack and OpenDaylight, giving a practical example of the OpenStack networking inan SDN architecture, analyzing the interactions between Neutron and the OpenDaylightcontroller, as well as their specific roles in this deployment.

To reproduce the experiment hereby presented, the reader needs at least two phys-ical or virtual servers for installing separate nodes for the OpenStack’s computing andnetworking services. For convenience, the demo session already provides two VMs forthose who want to execute the experiment in their own computer during the presenta-tion or at a later date. The software and hardware requirements for each server nodeare presented in Table 1.4. It is important to notice that, in our deployment scenario,the OpenStack controller services run in the same node as the network services (i.e., inthe Network Node) This is not strictly necessary, however, as it could run in any serverconnected to the same subnet as the Network Node.



Figure 1.19. Network topology used in the experiment.

1.5.6.1. Bootstrapping the Compute and Network Nodes

As explained before, this experiment will be performed based on two VMs configured asdescribed in Table 1.4. Any virtualization system can be adopted to perform the experi-ment in a virtualized environment, which means running the compute and network nodesas VMs. The only important restriction is that both nodes should be connected in the samelocal network. For the purpose of this demo, we assume the network configurations pre-sented in Figure 1.19. Before proceeding with the experiment, it is important to executeping requests between the nodes, with the corresponding IP addresses, to ensure there isconnectivity between them.

1.5.6.2. Starting Open vSwitch

To proceed with the setup of OpenStack, we should start the Open vSwitch software[Open vSwitch 2015], the switch virtualization software that is used to create the virtualbridges for both compute and network nodes, as discussed in Section 1.5.2. During theOpenStack startup process, Neutron makes use of the running Open vSwitch software tobuild the necessary bridges in the server nodes. To run the Open vSwitch software in theexperiment’s servers, the following command should be executed on the terminal of bothcompute and network nodes.

$ sudo /sbin/service openvswitch start

To verify that there is no existing bridges so far, the following command shouldbe run on the terminal of both compute and network nodes:

$ sudo ovs-vsctl show

The expected result is an empty list, indicating that the nodes have no bridgeconfigured. If that is not the case, the existing bridges should be removed. This can beaccomplished by running the following command, which deletes the bridge named br0and all of its configurations:

$ sudo ovs-vsctl del-br br0



1.5.6.3. Running the OpenDaylight Controller

We are now ready to run the OpenDaylight SDN controller, which will be used by Neutronto dynamically program the created virtual network bridges. As explained in Section1.5.5, the SDN controller receives REST requests from the ODL driver, which implementsthe methods called by ML2 plugin for implementing the layer 2 network services providedby Neutron API. To run OpenDayligh, the following commands should be executed onthe Network and Controller node:

$ cd odl/opendaylight/$ ./run.sh -XX:MaxPermSize=384m -virt ovsdb -of13

This command starts OpenDaylight, limiting the memory consumption to 384MB(-XX:MaxPermSize=384m), and also allowing support for the version 1.3 of the Open-Flow protocol (-of13). While running the controller, the terminal presents a dynamic logregister of all the controller operations, including bridge creation, flow configuration andnew service applications deployments.

1.5.6.4. Running DevStack

Now that we have the OpenvSwitch and the OpenDaylight SDN controller running, wecan start the OpenStack services on the compute node and on the network and controllernode. These nodes will then make use of these software resources to create the entirevirtual network infrastructure.

In this experiment, we run OpenStack through the Devstack project[Devstack 2015], which consists of an installation script to get the whole stack of Open-Stack services up and running. Created for development purposes, Devstack providesa non-persistent cloud environment that supports the deployment, experimentation, de-bugging and test of cloud applications. To start the necessary OpenStack services in ourdeployment, the following commands should be executed on both compute and networknodes.

$ cd devstack$ ./stack.sh

The initialization can take a few minutes. The reason is that the script “stack.sh”contains the setup commands to start all the specified OpenStack services in the localnode. For the purpose of this demo, the Devstack scripts located inside the nodes arepre-configured to run network, controller and compute services inside the network nodeand only compute services inside the compute node. For didactic purposes, we also startcompute services inside the network node. This allows us to have two compute nodesin our deployment infrastructure, so we can distribute the instantiated VMs in differentservers over the layer 2 configuration. To verify that we have two compute nodes up andrunning, the following command should be run on the network node:

$ . ./openrc admin demo$ nova hypervisor-list



As a result of this command, the ID and the hostname of two hypervisors runningin both compute and network node should be shown.

After executing the Devstack script, we should see new log messages in the Open-Daylight terminal, inside the network node. The messages correspond to the creation oftwo virtual networks by Neutron using the virtual bridges. The networks created corre-spond to the default private and public OpenStack networks, used to connect the VMs ofthe default tenant in a private virtual LAN and to provide connectivity to the Internet forthose VMs. By running the following command inside each OpenStack node, we shouldable to visualize the virtual bridges created by Neutron during the setup process with theOpenDaylight controller.

$ sudo ovs-vsctl show

The results obtained should be different for the compute and the network nodes.This happens because Neutron creates the external bridge (br-ex) only for the networknode, enabling the network node to provide Internet connectivity for cloud VMs.

1.5.6.5. Instantiating Virtual Machines in OpenStack

In this step, we instantiate two VMs for the default gateway of the OpenStack cloud.Then, we analyze their communication through the virtual network architecture createdby Neutron. The following commands instantiate the VMs, named demo-vm1 and demo-vm2:

$ nova boot --flavor m1.tiny --image cirros-0.3.1-x86_64-uec --nicnet-id=$(neutron net-list | grep private | awk ’{print $2}’) demo-vm1

$ nova boot --flavor m1.tiny --image cirros-0.3.1-x86_64-uec --nicnet-id=$(neutron net-list | grep private | awk ’{print $2}’) demo-vm2

To check the status of both VMs and verify if they were successfully created, thefollowing command should be used. The command should show that both VMs are active.

$ nova list

To verify the node where each VM is running, use the following command:

$ sudo virsh list

Now, to make sure that the created VMs are reachable in the network created byNeutron, we can ping them from both the router and the dhcp servers created as compo-nents of the virtual network infrastructure deployed in the network node. To be able to dothat, we should first run the following command on the network node:

$ ip netns

From the output of the previous command, we are able to identify the namespacesof the qrouter and of the qdhcp services running inside the network node. The names-paces are necessary to ping the VMs from both qrouter and qdhcp using the VMs’ privatenetwork IPs, as illustrated by the following command.



qdhcp-3f0cfbd2-f23c-481a-8698-3b2dcb7c2657qrouter-992e450a-875c-4721-9c82-606c283d4f92

$ sudo ip netns execqdhcp-3f0cfbd2-f23c-481a-8698-3b2dcb7c2657 ping 10.0.0.2

If everything was correctly configured, we should be able to successfully pingthe VM, since the dhcp instance is connected to them via the internal and the tunnelingbridges (br-int and br-tun).

1.5.6.6. Accessing the OpenDaylight GUI

Finally, we can visualize the network topology created by Neutron via the OpenDaylighGUI (Graphical User Interface). To do that, the following url should be accessed fromany of the server nodes:

http://192.168.56.20:8080

The Open Daylight GUI should show all the network bridges (represented by net-work devices) created and configured by Neutron using the controller. It is possible tovisualize the flow tables of each virtual bridge, as well as to insert and delete flows. TheOpenDaylight GUI also acts as a control point for the entire data plane elements supportedby the southbound API protocols, enabling monitoring, management and operation func-tions over the network.

1.6. Final Considerations, Challenges and PerspectivesIn this course we introduced the role of network virtualization on implementing and deliv-ering cloud computing services. We presented the available network virtualization mech-anisms and describe how they can address the cloud networking requirements. The adventof SDN introduced new forms of approaching network virtualization and network controlinside and outside the cloud. Together with the NFV approach, SDN improved cloud net-work control and accelerated the provision of innovative network services. To illustratethe feasibility of integrating both cloud computing and SDN paradigms, we presenteda practical study of the deployment of OpenStack and OpenDaylight. Both OpenStackand OpenDaylight are wide open source projects supported by the user and the industrycommunities.

It is important to analyze the different challenges experienced when virtualizingnetworks inside cloud data centers, as well to understand how SDN and available vir-tualization mechanisms can help to face these challenges. The first main challenge ondeploying virtual network in cloud computing is to ensure predefined performance levelsfor different tenant applications running inside the cloud. Cloud providers should be ableto provide specific network services for tenant applications such as bandwidth, predefinedin a service level agreement (SLA). Insufficient bandwidth can cause significant latencyon the interaction between users and the application, reducing the quality of the service(QoS) provided to and by cloud tenants. The emergence of control models such as SDN,together with hardware-assisted virtualization technologies such as SR-IOV, is expected



to improve the control capacity over the shared network resources. Efficient architecturesto integrate both control and virtualization technologies in the same cloud platform shouldbe developed aiming to address the control granularity necessary to provide different ser-vice levels for different tenants. Ensure the flexible deployment of security applianceson tenant network infrastructure is also a challenging task for cloud networking. Orga-nizations usually deploy a variety of security appliances in their network, such as deeppacket inspection (DPI), intrusion detection systems (IDSs) and firewalls to protect theirvaluable resources. These are often employed alongside other appliances that performload balancing, caching, and application acceleration. The network virtualization infras-tructure should provide for cloud tenants the flexibility to deploy security appliances in-side their cloud infrastructure. The use of network programmability provided by SDNplatforms and data plane protocols such as OpenFlow provides the capability to delivernetwork security solutions as a service inside the cloud. SDN-based solutions can alsoabstract the implementation of these security services, providing cloud agnostic solutionsand furthering standardization efforts.

SDN and NFV appliances can also address the challenges on policy enforcementcomplexity. These policies define the configuration of each virtual and physical resourcein the cloud network. Traffic isolation and access control to end users are among the mul-tiple forwarding policies that can be enforced by deploying SDN and NFV solutions in thecloud. SDN also provides the framework to implement support for vendor-specific proto-cols, addressing the challenge of building, operating, and interconnecting a cloud networkat scale. The need for rewriting or reconfiguring applications to address network relatedconstraints, such as the lack of a broadcast domain abstraction and the cloud-assignedIP addresses for virtual servers, also represents a barrier for the adoption of cloud com-puting. The separation between control plane and data plane provided by SDN enablesthe development of network services that abstracts the underlying network implementa-tion for cloud applications. Tunneling protocols such as VXLAN enables the L2 overlayschemes over a L3 network, also providing transparency to build tenant networks insidethe cloud.

Dealing with different requirements for topology designs in cloud data centers in-creases the management complexity of network configurations. Network topologies opti-mized for communication among servers inside the data center are not the same topologiesfor communication among servers and the Internet. The topology design also depends onhow L2 and/or L3 is utilizing the effective network capacity, and evolving the topologybased on traffic pattern changes also requires complex and dynamic configuration of L2and L3 forwarding rules. Traffic monitoring, network intelligence and dynamic data planeconfiguration are requirements that can be addressed by SDN control frameworks, inte-grated to the cloud data centers through the control and/or the application layers. Topol-ogy design and implementation are also key components to deal with the VM migrationchallenges. Network appliances are typically tied to statically configured physical net-works, which implicitly creates a location dependence constraint VMs. Compute node IPaddress is usually based on the VLAN or the subnet to which it belongs, both configuredin the physical switch ports. Therefore, a VM can not be easily migrated across the cloudnetwork, decreasing the levels of flexibility and resource utilization. The centralizationof the control over the logical abstraction of the underlying network, both enabled by the



SDN paradigm, facilitates the IP management tasks in VM migration. Technologies suchas SR-IOV also provides the abstraction of shared virtualization mechanisms such as vir-tual switches, approaching VM migration with mechanisms similar to those applied to themigration of physical servers in a L3 network.

As observed in the last paragraphs and also during this course, the network vir-tualization in cloud computing presents major challenges. Although, the new networkorganization paradigm introduced by SDN, added to virtualization technologies such asNFV and SR-IOV, provides not only an entire set of virtualization and control mech-anisms to meet the challenges on cloud networking, but also a new model of thinkingabout networking. Therefore, exploring SDN in cloud computing environments can beseen as a promising path to the innovation in the network field.

References[Al-Shaer and Al-Haj 2010] Al-Shaer, E. and Al-Haj, S. (2010). FlowChecker: Config-

uration analysis and verification of federated Openflow infrastructures. In Proc. of the3rd ACM Workshop on Assurable and Usable Security Configuration (SafeConfig’10),pages 37–44, New York, NY, USA. ACM.

[Alkmim et al. 2011] Alkmim, G., Batista, D., and Fonseca, N. (2011). Mapeamento deredes virtuais em substratos de rede. In Anais do Simpósio Brasileiro de Redes de Com-putadores e Sistemas Distribuídos – SBRC’2011, pages 45–58. Sociedade Brasileira deComputação – SBC.

[Amazon 2014] Amazon (2014). Virtualization Types – Amazon Elastic Com-pute Cloud. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/

virtualization_types.html. Accessed: 2015-03-13.

[Anderson et al. 2005] Anderson, T., Peterson, L., Shenker, S., and Turner, J. (2005).Overcoming the Internet impasse through virtualization. Computer, 38(4):34–41.

[Autenrieth et al. 2013] Autenrieth, A., Elbers, J.-P., Kaczmarek, P., and Kostecki, P.(2013). Cloud orchestration with SDN/OpenFlow in carrier transport networks. In15th Int. Conf. on Transparent Optical Networks (ICTON), pages 1–4.

[Aznar et al. 2013] Aznar, J., Jara, M., Rosello, A., Wilson, D., and Figuerola, S. (2013).OpenNaaS based management solution for inter-data centers connectivity. In IEEE 5thInt. Conf. on Cloud Computing Technology and Science (CloudCom), volume 2, pages75–80.

[Barros et al. 2015] Barros, B., Iwaya, L., Andrade, E., Leal, R., Simplicio, M., Car-valho, T., Mehes, A., and Näslund, M. (2015). Classifying security threats in cloudnetworking. In Proc. of the 5th Int. Conf. on Cloud Computing and Services Science(CLOSER’2015) (to appear). Springer.

[Bavier et al. 2006] Bavier, A., Feamster, N., Huang, M., Peterson, L., and Rexford, J.(2006). In VINI veritas: Realistic and controlled network experimentation. In Proc. ofthe 2006 Conf. on Applications, Technologies, Architectures, and Protocols for Com-puter Communications (SIGCOMM’06), pages 3–14, New York, NY, USA. ACM.



[Berde et al. 2014] Berde, P., Gerola, M., Hart, J., Higuchi, Y., Kobayashi, M., Koide, T.,Lantz, B., O’Connor, B., Radoslavov, P., Snow, W., and Parulkar, G. (2014). ONOS:towards an open, distributed SDN OS. In Proc. of the 3rd Workshop on Hot topics insoftware defined networking, pages 1–6. ACM.

[Berman et al. 2014] Berman, M., Chase, J., Landweber, L., Nakao, A., Ott, M., Ray-chaudhuri, D., Ricci, R., and Seskar, I. (2014). GENI: A federated testbed for innova-tive network experiments. Computer Networks, 61:5–23.

[Bilger et al. 2013] Bilger, B., Boehme, A., Flores, B., Schweitzer, J., and Islam, J.(2013). Software Defined Perimeter. Cloud Security Alliance – CSA. https://cloudsecurityalliance.org/research/sdp/. Accessed: 2015-03-13.

[Braun and Menth 2014] Braun, W. and Menth, M. (2014). Software-defined network-ing using OpenFlow: Protocols, applications and architectural design choices. FutureInternet, 6(2):302–336.

[Caesar et al. 2005] Caesar, M., Caldwell, D., Feamster, N., Rexford, J., Shaikh, A., andvan der Merwe, J. (2005). Design and implementation of a routing control platform.In Proc. of the 2nd Symposium on Networked Systems Design & Implementation, vol-ume 2, pages 15–28. USENIX Association.

[Canini et al. 2012] Canini, M., Venzano, D., Perešíni, P., Kostic, D., and Rexford, J.(2012). A NICE way to test Openflow applications. In Proc. of the 9th USENIX Conf.on Networked Systems Design and Implementation (NSDI’12), pages 10–10.

[Carapinha and Jiménez 2009] Carapinha, J. and Jiménez, J. (2009). Network virtual-ization: a view from the bottom. In Proc. of the 1st ACM workshop on Virtualizedinfrastructure systems and architectures, pages 73–80. ACM.

[Casado 2015] Casado, M. (2015). List of OpenFlow software projects. http://yuba.stanford.edu/~casado/of-sw.html. Accessed: 2015-03-01.

[Casado et al. 2007] Casado, M., Freedman, M., Pettit, J., Luo, J., McKeown, N., andShenker, S. (2007). Ethane: Taking control of the enterprise. In Proc. of the 2007Conference on Applications, Technologies, Architectures, and Protocols for ComputerCommunications (SIGCOMM’07), pages 1–12, New York, NY, USA. ACM.

[Cheng et al. 2014] Cheng, Y., Ganti, V., Lubsey, V., Shekhar, M., and Swan, C.(2014). Software-Defined Networking Rev. 2.0. White paper, Open Data CenterAlliance, Beaverton, OR, USA. http://www.opendatacenteralliance.org/

docs/software_defined_networking_master_usage_model_rev2.pdf.Accessed: 2015-03-13.

[Chun et al. 2003] Chun, B., Culler, D., Roscoe, T., Bavier, A., Peterson, L., Wawrzo-niak, M., and Bowman, M. (2003). PlanetLab: an overlay testbed for broad-coverageservices. ACM SIGCOMM Computer Communication Review, 33(3):3–12.



[Costa et al. 2012] Costa, P., Migliavacca, M., Pietzuch, P., and Wolf, A. (2012). NaaS:Network-as-a-service in the cloud. In Proc. of the 2nd USENIX Conf. on Hot Topics inManagement of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE’12),pages 1–1, Berkeley, CA, USA. USENIX Association.

[CSA 2011] CSA (2011). SecaaS: Defined categories of service 2011. Technical report,Cloud Security Alliance. https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_V1_0.pdf.

[Devstack 2015] Devstack (2015). DevStack - an OpenStack Community Pro-duction. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/

virtualization_types.html. Accessed: 2015-03-13.

[Duan 2014] Duan, Q. (2014). Network-as-a-service in software-defined networks forend-to-end qos provisioning. In 23rd Wireless and Optical Communication Confer-ence, (WOCC’2014), pages 1–5.

[Enns et al. 2011] Enns, R., Bjorklund, M., Schoenwaelder, J., and Bierman, A. (2011).RFC 6241 – network configuration protocol (NETCONF). https://tools.ietf.org/html/rfc6241.

[Erickson 2013] Erickson, D. (2013). The Beacon OpenFlow controller. In Proc. of the2nd SIGCOMM Workshop on Hot topics in software defined networking, pages 13–18.ACM.

[ETSI 2012] ETSI (2012). Network functions virtualisation: An introduction, benefits,enablers, challenges & call for action. White paper, European TelecommunicationsStandards Institute (ETSI). http://portal.etsi.org/NFV/NFV_White_Paper.pdf.

[Farinacci et al. 2000] Farinacci, D., Li, T., Hanks, S., Meyer, D., and Traina, P. (2000).RFC 2784 – generic routing encapsulation (GRE). https://tools.ietf.org/html/rfc2784.

[Feamster et al. 2007] Feamster, N., Gao, L., and Rexford, J. (2007). How to leasethe internet in your spare time. ACM SIGCOMM Computer Communication Review,37(1):61–64.

[Feamster et al. 2013] Feamster, N., Rexford, J., and Zegura, E. (2013). The road toSDN. Queue, 11(12):20–40.

[Feamster et al. 2014] Feamster, N., Rexford, J., and Zegura, E. (2014). The road toSDN: An intellectual history of programmable networks. SIGCOMM Comput. Com-mun. Rev., 44(2):87–98.

[Floodlight 2015] Floodlight (2015). Floodlight OpenFlow Controller. http://www.

projectfloodlight.org/floodlight/. Accessed: 2015-03-01.

[Gember et al. 2012] Gember, A., Prabhu, P., Ghadiyali, Z., and Akella, A. (2012). To-ward software-defined middlebox networking. In Proc. of the 11th ACM Workshop onHot Topics in Networks, HotNets-XI, pages 7–12, New York, NY, USA. ACM.



[Greenberg et al. 2005] Greenberg, A., Hjalmtysson, G., Maltz, D. A., Myers, A., Rex-ford, J., Xie, G., Yan, H., Zhan, J., and Zhang, H. (2005). A clean slate 4d approachto network control and management. ACM SIGCOMM Computer Communication Re-view, 35(5):41–54.

[Greene 2009] Greene, K. (2009). TR10: Software-defined networking. TechnologyReview (MIT).

[Gude et al. 2008] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown,N., and Shenker, S. (2008). NOX: towards an operating system for networks. ACMSIGCOMM Computer Communication Review, 38(3):105–110.

[Handigol et al. 2012a] Handigol, N., Heller, B., Jeyakumar, V., Lantz, B., and McKe-own, N. (2012a). Reproducible network experiments using container-based emulation.In Proc. of the 8th Int. Conf. on Emerging networking experiments and technologies,pages 253–264. ACM.

[Handigol et al. 2012b] Handigol, N., Heller, B., Jeyakumar, V., Maziéres, D., and McK-eown, N. (2012b). Where is the debugger for my software-defined network? In Proc.of the 1st Workshop on Hot Topics in Software Defined Networks (HotSDN’12), pages55–60, New York, NY, USA. ACM.

[Hu et al. 2014a] Hu, F., Hao, Q., and Bao, K. (2014a). A survey on software-definednetwork and OpenFlow: From concept to implementation. IEEE CommunicationsSurveys & Tutorials, 16(4):2181–2206.

[Hu et al. 2014b] Hu, H., Han, W., Ahn, G.-J., and Zhao, Z. (2014b). FlowGuard: Build-ing robust firewalls for software-defined networks. In Proc. of the 3rd Workshop onHot Topics in Software Defined Networking (HotSDN’14), pages 97–102, New York,NY, USA. ACM.

[IEEE 2012a] IEEE (2012a). 802.1BR-2012 – IEEE standard for local and metropolitanarea networks–virtual bridged local area networks–bridge port extension. Technicalreport, IEEE Computer Society.

[IEEE 2012b] IEEE (2012b). IEEE standard for local and metropolitan area networks–media access control (MAC) bridges and virtual bridged local area networks–amendment 21: Edge virtual bridging. IEEE Std 802.1Qbg-2012, pages 1–191.

[IEEE 2014] IEEE (2014). IEEE standard for local and metropolitan area networks–bridges and bridged networks. IEEE Std 802.1Q-2014, pages 1–1832.

[Jafarian et al. 2012] Jafarian, J., Al-Shaer, E., and Duan, Q. (2012). Openflow ran-dom host mutation: Transparent moving target defense using software defined net-working. In Proc. of the 1st Workshop on Hot Topics in Software Defined Networks(HotSDN’12), pages 127–132, New York, NY, USA. ACM.

[Jain and Paul 2013a] Jain, R. and Paul, S. (2013a). Network virtualization and softwaredefined networking for cloud computing: a survey. Communications Magazine, IEEE,51(11):24–31.



[Jain and Paul 2013b] Jain, R. and Paul, S. (2013b). Network virtualization and softwaredefined networking for cloud computing: a survey. Communications Magazine, IEEE,51(11):24–31.

[Jammal et al. 2014] Jammal, M., Singh, T., Shami, A., Asal, R., and Li, Y. (2014).Software-defined networking: State of the art and research challenges. CoRR,abs/1406.0124.

[Khurshid et al. 2013] Khurshid, A., Zou, X., Zhou, W., Caesar, M., and Godfrey, P.(2013). VeriFlow: Verifying network-wide invariants in real time. In Proc. of the 10thUSENIX Conference on Networked Systems Design and Implementation (NSDI’13),pages 15–28, Berkeley, CA, USA. USENIX Association.

[Kim et al. 2013] Kim, D., Gil, J.-M., Wang, G., and Kim, S.-H. (2013). Integrated sdnand non-sdn network management approaches for future internet environment. In Mul-timedia and Ubiquitous Engineering, pages 529–536. Springer.

[Kim and Feamster 2013] Kim, H. and Feamster, N. (2013). Improving network manage-ment with software defined networking. Communications Magazine, IEEE, 51(2):114–119.

[Koponen et al. 2014] Koponen, T., Amidon, K., Balland, P., Casado, M., Chanda, A.,Fulton, B., Ganichev, I., Gross, J., Gude, N., Ingram, P., et al. (2014). Network virtu-alization in multi-tenant datacenters. In USENIX NSDI.

[Koponen et al. 2010] Koponen, T., Casado, M., Gude, N., Stribling, J., Poutievski, L.,Zhu, M., Ramanathan, R., Iwata, Y., Inoue, H., Hama, T., et al. (2010). Onix: Adistributed control platform for large-scale production networks. In OSDI, volume 10,pages 1–6.

[Kotsovinos 2010] Kotsovinos, E. (2010). Virtualization: Blessing or Curse? Queue,8(11):40:40–40:46.

[Kreutz et al. 2013] Kreutz, D., Ramos, F., and Verissimo, P. (2013). Towards secure anddependable software-defined networks. In Proc. of the 2nd ACM SIGCOMM Workshopon Hot Topics in Software Defined Networking (HotSDN’13), pages 55–60, New York,NY, USA. ACM.

[Kreutz et al. 2014] Kreutz, D., Ramos, F. M. V., Veríssimo, P., Rothenberg, C. E.,Azodolmolky, S., and Uhlig, S. (2014). Software-defined networking: A compre-hensive survey. CoRR, abs/1406.0440.

[Lakshman et al. 2004] Lakshman, T., Nandagopal, T., Ramjee, R., Sabnani, K., andWoo, T. (2004). The softrouter architecture. In Proc. ACM SIGCOMM Workshopon Hot Topics in Networking, volume 2004.

[Lantz et al. 2010] Lantz, B., Heller, B., and McKeown, N. (2010). A network in a lap-top: rapid prototyping for software-defined networks. In Proc. of the 9th ACM SIG-COMM Workshop on Hot Topics in Networks, page 19. ACM.



[Lin et al. 2014] Lin, Y., Pitt, D., Hausheer, D., Johnson, E., and Lin, Y. (2014).Software-defined networking: Standardization for cloud computing’s second wave.Computer, 47(11):19–21.

[Linux Foundation 2015] Linux Foundation (2015). OpenDaylight, a Linux FoundationCollaborative Project. http://www.opendaylight.org/. Accessed: 2015-03-01.

[Mahalingam et al. 2014a] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,L., Sridhar, T., Bursell, M., and Wright, C. (2014a). Virtual extensible local area net-work (VXLAN): A framework for overlaying virtualized layer 2 networks over layer3 networks. Internet Req. Comments.

[Mahalingam et al. 2014b] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,L., Sridhar, T., Bursell, M., and Wright, C. (2014b). Vxlan: A framework for overlay-ing virtualized layer 2 networks over layer 3 networks. draft-mahalingam-dutt-dcops-vxlan-08.

[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Pe-terson, L., Rexford, J., Shenker, S., and Turner, J. (2008). OpenFlow: enabling in-novation in campus networks. ACM SIGCOMM Computer Communication Review,38(2):69–74.

[Mechtri et al. 2013] Mechtri, M., Houidi, I., Louati, W., and Zeghlache, D. (2013).SDN for inter cloud networking. In IEEE SDN for Future Networks and Services(SDN4FNS), pages 1–7.

[Medved et al. 2014] Medved, J., Varga, R., Tkacik, A., and Gray, K. (2014). Open-Daylight: Towards a Model-Driven SDN Controller architecture. In 2014 IEEE 15thInternational Symposium on, pages 1–6. IEEE.

[Mell and Grance 2011] Mell, P. and Grance, T. (2011). The nist definition of cloudcomputing. Technical Report 800-145, National Institute of Standards and Technology(NIST).

[Menascé 2005] Menascé, D. A. (2005). Virtualization: Concepts, applications, and per-formance modeling. In CMG Conference, pages 407–414.

[Moreira et al. 2009] Moreira, M. D. D., Fernandes, N. C., Costa, L. H. M. K., andDuarte, O. C. M. B. (2009). Internet do futuro: Um novo horizonte. Minicursos doSimpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos – SBRC’2009,2009:1–59.

[Nayak et al. 2009] Nayak, A., Reimers, A., Feamster, N., and Clark, R. (2009). Reso-nance: Dynamic access control for enterprise networks. In Proc. of the 1st ACM Work-shop on Research on Enterprise Networking (WREN’09), pages 11–18, New York, NY,USA. ACM.

[NOXRepo.org 2015] NOXRepo.org (2015). About NOX. http://www.noxrepo.

org/pox/about-nox/. Accessed: 2015-03-01.



[NOXRepo.org 2015] NOXRepo.org (2015). About pox. Accessed: 2015-03-01.

[Open Networking Foundation 2012] Open Networking Foundation (2012). Software-Defined Networking: The New Norm for Networks. White paper, Open NetworkingFoundation, Palo Alto, CA, USA.

[Open vSwitch 2015] Open vSwitch (2015). Production Quality, Multilayer Open Vir-tual Switch. http://openvswitch.org/. Accessed: 2015-02-28.

[OpenContrail 2014] OpenContrail (2014). OpenContrail: An open-source network vir-tualization platform for the cloud. http://www.opencontrail.org/. Accessed:2015-02-28.

[OpenFlow 2009] OpenFlow (2009). Specification, openflow switch – v1.0.0.

[OpenFlow 2012] OpenFlow (2012). Specification, openflow switch – v1.3.0.

[OpenStack 2015] OpenStack (2015). OpenStack: Open source cloud computing soft-ware. https://www.openstack.org/. Accessed: 2015-02-28.

[Pan et al. 2011] Pan, J., Paul, S., and Jain, R. (2011). A survey of the research on futureinternet architectures. Communications Magazine, IEEE, 49(7):26–36.

[Pan and Wu 2009] Pan, L. and Wu, H. (2009). Smart trend-traversal: A low delay andenergy tag arbitration protocol for large rfid systems. In INFOCOM 2009, IEEE, pages2571–2575. IEEE.

[Patel et al. 2013] Patel, P., Bansal, D., and Yuan, L. (2013). Ananta: Cloud scale loadbalancing. In Proc. of SIGCOMM 2013, pages 207–218, New York, NY, USA. ACM.

[PCI-SIG 2010] PCI-SIG (2010). Single Root I/O Virtualization and Sharing 1.1Specification. PCI-SIG. http://docs.aws.amazon.com/AWSEC2/latest/

UserGuide/virtualization_types.html. Accessed: 2015-03-13.

[Pfaff and Davie 2013] Pfaff, B. and Davie, B. (2013). The Open vSwitch Database Man-agement Protocol. RFC Editor.

[Pfaff et al. 2009] Pfaff, B., Pettit, J., Amidon, K., Casado, M., Koponen, T., andShenker, S. (2009). Extending networking into the virtualization layer. In Hotnets.

[Porras et al. 2015] Porras, P., Cheung, S., Fong, M., Skinner, K., and Yegneswaran, V.(2015). Securing the Software-Defined Network Control Layer. In Proc. of the 2015Network and Distributed System Security Symposium (NDSS).

[Porras et al. 2012] Porras, P., Shin, S., Yegneswaran, V., Fong, M., Tyson, M., and Gu,G. (2012). A security enforcement kernel for openflow networks. In Proc. of the 2stWorkshop on Hot Topics in Software Defined Networks (HotSDN’12), pages 121–126,New York, NY, USA. ACM.

[Richardson and Ruby 2008] Richardson, L. and Ruby, S. (2008). RESTful web services." O’Reilly Media, Inc.".



[Rouse 2010] Rouse, M. (2010). Security as a Service (SaaS). http://

searchsecurity.techtarget.com/definition/Security-as-a-Service.Accessed: 2015-03-01.

[Ryu 2015] Ryu (2015). Component-based software-defined networking framework.http://osrg.github.io/ryu/. Accessed: 2015-03-01.

[Scott-Hayward et al. 2013] Scott-Hayward, S., O’Callaghan, G., and Sezer, S. (2013).SDN security: A survey. In Future Networks and Services (SDN4FNS), 2013 IEEESDN for, pages 1–7.

[Sezer et al. 2013] Sezer, S., Scott-Hayward, S., Chouhan, P., Fraser, B., Lake, D.,Finnegan, J., Viljoen, N., Miller, M., and Rao, N. (2013). Are we ready for SDN? Im-plementation challenges for software-defined networks. Communications Magazine,IEEE, 51(7):36–43.

[Sherwood et al. 2010] Sherwood, R., Gibb, G., Yap, K.-K., Appenzeller, G., Casado,M., McKeown, N., and Parulkar, G. M. (2010). Can the production network be thetestbed? In OSDI, volume 10, pages 1–6.

[Shin et al. 2013] Shin, S., Porras, P., Yegneswaran, V., Fong, M., Gu, G., and Tyson,M. (2013). FRESCO: Modular composable security services for software-defined net-works. In 20th Annual Network and Distributed System Security Symposium (NDSS).The Internet Society.

[Sridharan et al. 2011] Sridharan, M., Greenberg, A., Venkataramiah, N., Wang, Y.,Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., and Tumuluri, C. (2011). Nvgre:Network virtualization using generic routing encapsulation. IETF draft.

[Tootoonchian and Ganjali 2010] Tootoonchian, A. and Ganjali, Y. (2010). HyperFlow:A distributed control plane for OpenFlow. In Proc. of the 2010 Internet Network Man-agement Conference on Research on Enterprise Networking (INM/WREN’10), pages1–6, Berkeley, CA, USA. USENIX Association.

[Turner and Taylor 2005] Turner, J. and Taylor, D. (2005). Diversifying the Internet. InIEEE Global Telecommunications Conference (GLOBECOM’05), volume 2, pages 6–pp.

[Wen et al. 2012] Wen, X., Gu, G., Li, Q., Gao, Y., and Zhang, X. (2012). Comparisonof open-source cloud management platforms: OpenStack and OpenNebula. In 20129th Int. Conf. on Fuzzy Systems and Knowledge Discovery, pages 2457–2461.

[Xiong 2014] Xiong, Z. (2014). An SDN-based IPS development framework in cloudnetworking environment. Master’s thesis, Arizona State University, Arizona, USA.

[Yang et al. 2004] Yang, L., Dantu, R., Anderson, T., and Gopal, R. (2004). RFC 3746 –forwarding and control element separation (ForCES) framework. https://tools.ietf.org/html/rfc3746.



[Yeganeh et al. 2013] Yeganeh, S., Tootoonchian, A., and Ganjali, Y. (2013). On scala-bility of software-defined networking. Communications Magazine, IEEE, 51(2):136–141.

[YuHunag et al. 2010] YuHunag, C., MinChi, T., YaoTing, C., YuChieh, C., and YanRen,C. (2010). A novel design for future on-demand service and security. In 12th IEEEInt. Conf. on Communication Technology (ICCT), pages 385–388.



Capítulo

2Geração Distribuída de Energia: Desafios ePerspectivas em Redes de Comunicação

Yona Lopes1, Natalia Castro Fernandes2, Débora Christina Muchaluat-Saade1

1Departamento de Ciência da Computação–IC, 2Dep. de Engenharia de TelecomunicaçõesLaboratório MídiaCom – Universidade Federal Fluminense (UFF) – Niterói, RJ – Brasil

Abstract

Recently, interests about distributed energy generation have been renovated. Distribu-ted Generation (DG), an issue that motivates this chapter, allows the creation of a greenpower system, control of peaking use, reduction of losses in the system, reduction of en-vironmental impact and increase insertion of renewable energy sources. DG growth hasincreased considerably and communication networks have a key role in its success. Thus,the focus of this chapter is the discussion about challenges of communication solutions forDG. This chapter addresses the main features of DG, control and management of this newgeneration model and main challenges in communication networks for the developmentof a reliable, flexible, sustainable and expandable DG model.

Resumo

Atualmente, o interesse pela geração de eletricidade de forma distribuída tem se reno-vado. A Geração Distribuída (GD), tema motivador deste capítulo, além de permitir acriação de uma rede elétrica mais “verde”, permite o controle do horário de pico, aredução de perdas no sistema, a diminuição dos impactos ambientais e o aumento dainserção de fontes de energia renováveis na matriz energética. Seu crescimento tem au-mentado consideravelmente e as redes de comunicação têm um papel fundamental para oseu sucesso. Assim, o foco central deste capítulo é a discussão sobre desafios de soluçõesde comunicação para GD. São abordadas as principais características da GD, o controlee o gerenciamento desse novo modelo de geração, e quais as perspectivas e desafios emredes de comunicação para o desenvolvimento de um modelo de GD confiável, flexível,sustentável e expansível.



2.1. IntroduçãoUma rede elétrica inteligente, conhecida como Smart Grid, traz propostas inovadoras quemudam de forma profunda a maneira como a energia é provida desde a geração até osconsumidores finais. Dentre as novas propostas, destacam-se a geração de energia deforma distribuída, o amplo uso de fontes renováveis, o uso de carros elétricos, um intensomonitoramento da rede elétrica, o uso de medidores inteligentes, entre outros. Com as re-des elétricas inteligentes, o consumidor passa a ser parte fundamental do funcionamento econtrole da rede elétrica. Os consumidores, que no sistema tradicional apenas consomemenergia, podem ter nesse novo modelo também o papel de produtor de energia elétrica.Além disso, os medidores inteligentes localizados nas residências passam a gerar umaquantidade enorme de informação que poderá ser usada para o gerenciamento e controledo sistema. Portanto, para que o desenvolvimento da rede elétrica inteligente seja possí-vel, a inteligência e as tecnologias, antes existentes apenas em parte do Sistema Elétricode Potência (SEP), se tornam imprescindíveis da geração até o consumidor final. Umaconsequência desse processo é que as redes de comunicação passarão a ser um elementocrítico para lidar com esse grande sistema distribuído.

A Geração Distribuída (GD), além de ser uma área chave para a sustentabilidadee geração de energia limpa, causa um grande impacto em todo o sistema de transmissão edistribuição de energia, uma vez que altera toda a concepção do sistema atual se tornandoum tema chave de alta criticidade. De fato, com o advento das novas tecnologias de gera-ção de energia de forma distribuída, as redes elétricas e de comunicação passarão a inter-ligar milhões de fontes de energia renovável estocásticas [Keshav and Rosenberg 2011].Usinas hidrelétricas que não tenham reservatório, a geração de energia eólica que de-pende da força do vento e a geração de energia solar que depende da incidência solar sãoexemplos em que a geração de energia estará exposta a variações meteorológicas incon-troláveis. Isso leva a um funcionamento intermitente da geração de energia elétrica, quefuncionará em alguns momentos e em outros não.

Um cenário bem comum no Brasil envolve regiões distantes com uma quantidadepopulacional mais baixa que na região Sudeste, por exemplo. Para atender essas regiões,as concessionárias gastariam muito para transmitir a energia e não teriam grande retornoeconômico, o que faz com que regiões com essa característica ainda não tenham energiaelétrica. Segundo a Agência Nacional de Energia Elétrica (ANEEL), cerca de um milhãode residências ainda não tem acesso à energia elétrica 1. A grande maioria desses domi-cílios, segundo o Instituto Brasileiro de Geografia e Estatística (IBGE), estão em regiõesrurais onde a quantidade populacional é mais baixa 2. A GD é uma solução em discussãopara ajudar a prover energia para esses lugares [Kagan and Gouvea 2013]. Ressalta-se,que mesmo com a inclusão de geração distribuída, essas regiões terão que ser interligadasao sistema de energia elétrica para fazer parte das redes elétricas inteligentes.

Outro ponto de grande atenção é a crise hídrica que o Brasil está enfrentando.Sabe-se que a energia elétrica no Brasil é fornecida, em primeiro lugar, por grandes usi-nas hidrelétricas que precisam da força das águas para funcionar. Em uma crise hídrica,

1http://oglobo.globo.com/economia/um-milhao-de-lares-brasileiros-nao-tem-energia-eletrica-71328902http://ultimosegundo.ig.com.br/brasil/mais-de-27-milhoes-de-brasileiros-nao-tem-energia-eletrica-

revela-censo-2010/n1597368876772.html

2: Geração Distribuída de Energia: Desafios e Perspectivas em Redes de Comunicação.


outras formas de geração precisam ser acionadas. Uma forma atraente para tratar esseproblema no Brasil seria a instalação de outras fontes menores de energia renováveis,impulsionando a implantação da GD.

Porém, a implantação desse tipo de geração não é trivial, visto que a presença deGD nas redes de distribuição de energia elétrica requer recursos e procedimentos operati-vos adicionais em relação às redes convencionais, bem como padrões de conexão e práti-cas de planejamento da expansão [Kagan and Gouvea 2013]. Essa implantação não afetasomente a área de energia elétrica mas também as áreas de telecomunicações, computa-ção, automação, dentre outras. Sistemas de telecomunicações precisarão dar o suportepara sistemas de gerenciamento e controle, para tratamento de dados, para proteção dossistemas, etc. Além disso, são essenciais para sistemas de estabilização das demandas etarifação que possibilitam a garantia de resposta à demanda adequada e o livre mercadopara compra e venda de energia em tempo real por consumidores finais. Para tanto, seránecessária uma rede de comunicação altamente segura, confiável e com baixo retardo, deforma que o monitoramento e o controle da rede elétrica possam ser realizados.

As principais questões para a construção de uma rede de comunicação que ofe-reça suporte à GD estão relacionadas à escalabilidade e à segurança. A modelagem de umsistema distribuído escalável, que permita o tráfego Machine-to-Machine (M2M) consi-derando o alto volume de tráfego e o grande número de fontes de tráfego, e a qualidade deserviço, para que a rede de controle e monitoração seja suficiente para atender as deman-das do sistema elétrico, é de alta complexidade. A segurança também é um fator chave, jáque milhões de clientes que geram e consomem energia passam a influenciar diretamenteno serviço oferecido pela rede de dados e pela rede elétrica [Müller et al. 2012].

O principal objetivo deste capítulo é a discussão sobre os principais conceitos, de-safios e perspectivas para redes de comunicação na geração distribuída de energia, área degrande oportunidade para pesquisa e desenvolvimento. Espera-se que os principais con-ceitos relacionados à geração de energia distribuída sejam compreendidos, com foco nosrequisitos de comunicação para esse novo tipo de rede elétrica. Temas como controle, ge-rência, interoperabilidade, escalabilidade e segurança têm destaque especial, assim comosoluções e projetos relativos aos principais desafios de comunicação.

O restante deste capítulo está organizado da seguinte forma. As Seções 2.2 e 2.3apresentam os principais conceitos relacionados à GD e como esse tema se encaixa comos outros elementos de uma rede elétrica inteligente. Na Seção 2.4, serão discutidosos principais desafios de comunicação relacionados à GD, considerando aspectos comoescalabilidade, confiabilidade, segurança e gerência da rede. A Seção 2.5 apresenta al-gumas das principais soluções para os desafios de comunicação, assim como apresentaalguns projetos de GD que estão sendo desenvolvidos. Por fim, a Seção 2.6 apresenta asconsiderações finais, destacando os desafios para pesquisa na área.

2.2. Redes Elétricas InteligentesOs problemas do sistema elétrico tradicional levaram à necessidade de modernização doSEP, o que deu origem a novos conceitos e elementos, constituindo as redes elétricasinteligentes ou Smart Grids. O surgimento de redes elétricas inteligentes vem causandouma grande revolução nas redes de energia elétrica, aumentando os ganhos em confiabili-



dade, eficiência energética, participação dos consumidores e geração de uma energia maislimpa [Patel et al. 2011]. Tal revolução está ocorrendo porque as redes elétricas inteligen-tes são baseadas em conceitos como a monitoração inteligente e transmissão dos fluxos decomunicação e de energia de forma bidirecional. Nesse cenário, o consumidor pode usar,gerar e vender energia sendo consumidor e produtor de energia ao mesmo tempo. Esses eoutros conceitos como a geração de forma distribuída, a incorporação de fontes de ener-gia renováveis, o armazenamento de energia e a maior participação do consumidor serãoabordados na Seção 2.3. Esses conceitos permitirão uma recuperação rápida e automáticada rede elétrica em caso de problemas que possam resultar em possíveis apagões. A Fi-gura 2.1 ilustra as principais diferenças da rede elétrica tradicional com fluxo de energiaunidirecional e da rede elétrica inteligente com os fluxos de energia e comunicação emduas vias e com inclusão de novos conceitos.

(a) Redes Elétricas Tradicionais.

(b) Redes Elétricas Inteligentes.

Figura 2.1. Comparação das Redes Elétricas Tradicionais com as Redes ElétricasInteligentes.

Um ponto importante é que esse novo sistema elétrico depende de uma sofisticadainfraestrutura de redes de comunicação para dar suporte à comunicação entre os disposi-tivos inteligentes que monitoram e atuam na rede. Além disso, é necessário dar suporteàs empresas de distribuição de energia e aos usuários, que podem consumir ou gerar ener-



gia [Ericsson 2004, Budka et al. 2010a]. Novas necessidades surgem, como o aumentoda confiabilidade da rede, o aumento da eficiência operacional da rede, a melhora da qua-lidade para o consumidor e o aumento da variedade dos serviços providos. Porém, todasessas melhoras trazem diversos desafios para as redes de comunicação. Conhecer os pro-blemas do sistema tradicional, a visão de futuro do sistema elétrico de potência e comoesse novo modelo altera o sistema, ajuda a entender esses desafios e suas possibilidadesde solução.

2.2.1. Os Problemas no Sistema Elétrico Tradicional

O sistema de potência tradicional e as tecnologias e redes de comunicação usadas atéagora têm funcionado bem, porém não serão suficientes para enfrentar as mudanças ad-vindas das redes elétricas inteligentes. Um exemplo é que atualmente ainda são usadasem subestações, e entre subestações, tecnologias de comunicação com baixa largura debanda e baixa taxa de transmissão. É improvável que a integração eficiente da GD sejafeita sem mudanças. A transmissão e estrutura de rede de distribuição provavelmente sãoas que mais irão sofrer modificações. Uma premissa básica para implementação das re-des elétricas inteligentes é que toda a estrutura da rede de distribuição até o consumidorseja completamente automatizada e inteligente, cenário oposto ao atual. O planejamentoe procedimentos operacionais utilizados atualmente são voltados para um sistema sem aparticipação do consumidor e com uma rede de distribuição passiva, que requerem pro-cedimentos operacionais e planejamentos muitos diferentes dos necessários nas redes in-teligentes. Novos procedimentos deverão ser criados para incluir a geração distribuída,a rede de distribuição ativa e consumidores participativos. Outro ponto importante é ocontrole e gerenciamento, que deverão ser muito mais efetivos e precisarão abranger to-dos os componentes da rede inteligente. Esse cenário irá gerar uma grande quantidade detráfego, às vezes com requisitos de tempo real, necessitando de uma rede de comunicaçãorápida, robusta e confiável.

O sistema tradicional é antigo, o que coloca em risco a operação do sistema deenergia sob uma perspectiva de longo prazo [Lo and Ansari 2012]. Ressalta-se que asinstalações de energia de alta tecnologia, microprocessadores e sensores de comunicaçãonão estavam disponíveis no momento em que a rede foi construída [Lo and Ansari 2012].Com isso, as instalações do sistema elétrico são compostas basicamente de equipamen-tos fisicamente robustos, com uma vida útil muito longa, mas que em contrapartida nãopossuem recursos de comunicação e as vantagens proporcionada por microprocessado-res. Substituir todos esses equipamentos em funcionamento por dispositivos com umatecnologia mais recente é economicamente inviável, e por esse motivo, de forma geral,os equipamentos só são substituídos quando param de funcionar. Por isso, observa-seuma defasagem tecnológica da rede elétrica atual [Lo and Ansari 2012], piorando aindamais a situação de construções com equipamentos ainda defasados, e com um sistemaheterogêneo.

Além disso, a rede foi projetada para uma geração centralizada, longe dos grandescentros consumidores, com um fluxo unidirecional de comunicação e de energia. Ou-tro grande problema a ser resolvido no sistema atual é que não há interação entre osserviços e os consumidores [Pepermans et al. 2005]. Ademais, devido ao aumento dapopulação e ao crescimento do número de equipamentos em uso nas residências, a de-



manda por energia tem crescido cada vez mais nos últimos anos. No Brasil, a partirdo ano de 1964, dispõe-se de uma base de dados em que o setor é dividido em quatrosubsetores: residencial, comercial, industrial e outros. A Figura 2.2 apresenta o con-sumo anual de energia elétrica no Brasil, de 1964 até 2008, onde percebe-se que aolongo destes 45 anos de acompanhamento o consumo total de energia elétrica cresceumais de 16 vezes, o que significa um incremento médio anual de pouco mais de 6,6%aa [Amaral and Monteiro 2010].

Figura 2.2. Consumo Anual de Energia Elétrica no Brasil(GWh) [Amaral and Monteiro 2010]

A crescente demanda de energia significa uma carga ainda maior na infraestruturade energia elétrica, que já está superutilizada, estressada e frágil [Gungor et al. 2010].Essa demanda, em conjunto com a natureza complexa da rede de distribuição de energiaelétrica, tem causado graves problemas na rede. De forma geral, em certos momentos, ademanda por energia é maior do que a quantidade de energia que está sendo gerada pelosistema, que não está preparado para lidar com as necessidades atuais e com usuários cadavez mais exigentes.

Esses fatores tornaram-se as principais causas de grandes apagões que aconte-ceram nos últimos anos. A rede elétrica tradicional sofre com a falta de uma comuni-cação efetiva e universal, monitoramento e diagnóstico de falhas, o que aumenta aindamais a possibilidade de colapso do sistema devido ao efeito cascata iniciado por umaúnica falha [Gungor et al. 2010]. Assim sendo, a infraestrutura de controle, geração,transmissão e distribuição de energia está envelhecendo e o consumo de energia aumen-tando [Budka et al. 2010b].

Alguns dos problemas mais discutidos do sistema legado serão pontuados a seguir:

• Geração de energia de forma não-renovável e alterações climáticas:Ultimamente, um dos problemas atuais mais debatidos tem sido as alterações climá-ticas. Muitos governos concordam que as emissões de gases de efeito estufa preci-sam ser contidas para controlar ou prevenir as alterações climáticas [Galli et al. 2011].



Porém, atualmente, mais de 80% dos recursos utilizados para a produção de ener-gia ao longo do mundo é de combustíveis fósseis [EIA 2014], ou seja, recursosnão-renováveis. Percebe-se que a queima de combustíveis não era historicamenteuma preocupação. Infelizmente, o efeito estufa tem causado consideráveis mudan-ças climáticas e impacto ambiental [Lo and Ansari 2012]. No Brasil, como mostraa Figura 2.3, o uso das termelétricas aumentou, e isso ocorreu devido à falta dechuvas. As termelétricas agiram para substituir parte da geração hidrelétrica e, comisso, ajudaram a poupar água para que a situação no Brasil não ficasse mais grave.Mas como as termelétricas funcionam por meio da queima de combustíveis, comogás e óleo, a energia que produzem costuma ser muito mais cara e a conta é repas-sada ao consumidor [Amato 2013].

Figura 2.3. Aumento da geração de energia com uso de termelétricas no Bra-sil [Amato 2013].

• Infraestrutura fragilizada e antiga:Segundo [Budka et al. 2010b] a infraestrura está envelhecendo e se tornando muitasvezes obsoleta. Esse tipo de problema coloca em risco a operação de todo sistema,principalmente sobre uma ótica de longo prazo.

• Geração de energia centralizada:Quando diz-se que a geração de energia é feita de forma centralizada, não significadizer que a geração é realizada em somente um ponto. Na verdade, a geração é feitaem grandes usinas distantes e dispostas em várias regiões. Este conceito é relacio-nado ao fato de que uma grande quantidade de energia é gerada em poucas usinasmuito distante do consumidor, tendo então que ser transmitida por longas distân-cias, gerando muitas perdas e com custo elevado. Com isso, essa forma de geraçãode energia por meios tradicionais não consegue mais acompanhar o crescimento dademanda [Galli et al. 2011, Gungor et al. 2011].

• Aumento da população e crescente demanda de energia:É notório o crescimento da população mundial, o que naturalmente aumenta o con-sumo de energia. Além disso, há um aumento no ritmo de industrialização nos



países em desenvolvimento, como China e Índia, que gera também um grande au-mento na demanda de energia. O aumento da demanda não poderá ser facilmentecontrolado [Lo and Ansari 2012], o que leva à necessidade de aumento na geraçãoe equilíbrio no sistema.

• Custos dos combustíveis:O fenômeno da manipulação de fontes de energia e competição por recursos ener-géticos tem impulsionado as nações a reavaliar o preço da dependência da energiaimportada [Lo and Ansari 2012]. O Brasil, por exemplo, não tem como hábito aimportação de energia, porém, depois do último apagão em janeiro de 2015 queatingiu 11 estados e o Distrito Federal, o Brasil importou energia da Argentina paracomplementar o atendimento da demanda no período de pico de consumo. Alémdisso, segundo o Operador Nacional do Sistema (ONS) essa importação tende aaumentar 3, o que vai pesar no bolso do consumidor.

• A deterioração da confiança:O sistema elétrico atual é solicitado a ser 99,97% confiável, mas ainda permite afalta de energia e interrupções [SGD 2008]. A falta de confiabilidade no sistemaelétrico atual advém do uso de fontes de energia centralizadas e longe dos grandescentros, infraestrutura essa que é ineficiente e antieconômica para acompanhar oritmo da crescente demanda.

• Monopólio da concessionária:De fato, a concessionária é o único fornecedor de energia para consumidores resi-denciais. Os consumidores são obrigados a pagar pelo serviço da concessionáriaque só informa o quanto de energia foi usada e quanto tem que ser pago por essegasto no final do ciclo de faturamento, já que não acompanham o uso de energia emtempo real [Lo and Ansari 2012].

• Fluxo unidirecional de comunicação e de energia:Este é outro grande problema do sistema atual: não há interação entre os serviçose os consumidores. Os medidores só podem transmitir unidirecionalmente. E comisso o consumidor não pode interagir com serviços, fazendo suas próprias escolhassobre como usar a energia. O sistema utilizado não permite que o consumidorperceba os reflexos decorrentes da forma de usar a eletricidade e tome ações deacordo com as informações recebidas. O consumidor industrial pode por exemploescolher de onde compra energia, pois recebe informações sobre os preços e origemdesta. O consumidor residencial não recebe essas informações e não pode escolherde onde comprar a energia.

• Limitação de inovação e modernização:A rede de energia sem alterar o seu modelo de infraestrutura e operação atual difi-cilmente poderá melhorar os serviços e beneficiar a sociedade a longo prazo. Porexemplo, a dependência de combustíveis fósseis e o modelo atual centralizado elonge dos grandes centros pode restringir ou impedir o crescimento do sistema paraatender a demanda de energia [Lo and Ansari 2012].

3 http://g1.globo.com/jornal-nacional/noticia/2015/01/brasil-compra-energia-da-argentina-apos-apagao-de-segunda-feira-19.html



2.2.2. O Futuro do Sistema de Energia Elétrica

As redes de energia são sistemas complexos, integrados e com uma interação sensívelentre fontes de geração, sistemas de rede e as demandas de energia. A rede elétrica tradi-cional, como visto anteriormente, tem como principais características uma infraestruturade geração centralizada e consumidores com participação passiva sem contribuir com agestão operacional das fontes de geração de energia. Cada usuário é simplesmente um nófinal para entrega de eletricidade. O fluxo de comunicação e de energia é unidirecional e,de forma geral, o objetivo do sistema elétrico é o fornecimento de energia para os usuáriosfinais.

O novo modelo de rede elétrica inteligente propõe diversas novidades. A maisdiscutida e mais amplamente implementada é infraestrutura de medição inteligente. Nessesentido, toda a medição, que exigia a presença de um técnico para anotar o consumo decada medidor analógico nas unidades consumidoras, é substituída por medidores digitais,capazes de se comunicar diretamente com uma central. Esse medidor digital, permite,entre outras funcionalidades, uma comunicação bidirecional com a central de energia.Assim, ao invés de o usuário apenas informar o seu consumo de energia, ele passa tambéma receber dados da empresa concessionária.

Dentre as vantagens desse novo modelo, estão a possibilidade de diferenciar opreço da energia ao longo do dia e informar ao cliente em tempo real as mudanças depreço e o seu consumo, e, ainda, controlar a carga dos clientes em caso de aumentoexcessivo da demanda. Nesse caso, seria possível enviar notificações aos clientes paraque se reduza o consumo desligando alguns aparelhos de forma a evitar o corte de energiaem toda uma região.

Portanto, nesse novo modelo, toda a inteligência e automação que antes só exis-tiam em parte do sistema, como em subestações, deverão ser levadas para todo o sistema,chegando à casa dos consumidores. Na proporção que o sistema muda, não só a infra-estrutura elétrica é afetada como também a comunicação no sistema. Nessa nova arqui-tetura, a comunicação entre a concessionária de energia e os consumidores é um passofundamental para o progresso das redes elétricas inteligentes [Li and Zhang 2010].

Outra vantagem que a infraestrutura de medição inteligente traz é a geração deenergia pelo cliente. Muitas vezes, ao se falar em GD, se pensa nas formas de geraçãoalternativas, como fazendas para geração de energia eólica ou usinas construídas parafuncionar com a variação das marés. Tudo isso é parte da iniciativa sustentável parareduzir a emissão de poluentes, conectando à rede plantas virtuais de energia renovávelem escala industrial. Contudo, a GD inclui também a geração de energia pelos clientes.Assim, uma residência equipada com um painel solar ou uma pequena turbina eólica podeser uma fonte geradora para todo o sistema, disponibilizando o excesso de energia que foigerado. Isso só é possível devido à comunicação bidirecional dos medidores.

Assim, a GD, os medidores inteligentes e outras tecnologias do lado da demandaestão se tornando cada vez mais necessários para controlar a demanda de energia, tantodurante o horário de pico quanto fora do pico [Budka et al. 2010a]. Essas e outras carac-terísticas mudaram o paradigma de geração de energia e distribuição. O sistema deixa deser centralizado e unidirecional para formar uma rede de energia e comunicação. Com



isso, o sistema de comunicação passa a ser totalmente integrado.

O futuro do sistema de energia elétrica inclui muitos pontos de mudança introdu-zidos pela modernização do sistema. Os pontos mais fortes considerados aqui incluem ocliente, a rede de distribuição e a rede de transmissão do sistema. As empresas de dis-tribuição terão que lidar com clientes mais conscientes das possibilidades oferecidas pelomercado, que terão essa resposta online. Estas possibilidades incluem tarifas flexíveiscom preços competitivos; geração de energia local; suporte a programas de energias re-nováveis; programas de economia de energia; geração pelo lado da demanda; e serviçosde comunicação e de faturamento [Bayod-Rújula 2009]. Além disso, os eletrodomésticospoderão receber, em tempo real, o preço da energia via rede de comunicação. Com isso,os próprios dispositivos poderão otimizar o seu nível de consumo de acordo com o preçoatual de energia [Li and Zhang 2010]. Dessa forma, a eficiência na utilização da energiaaumenta e o consumo é reduzido, o que ajuda a combater a crise de recursos energéticos.

As aplicações de automação residencial e de gerenciamento de energia residencialtendem a crescer e a incorporar novas funcionalidades. A tecnologia de rede usada paraautomatizar uma casa terá que coexistir com a rede de comunicação com a concessionária.Existe ainda uma grande discussão sobre qual tecnologia deverá ser usada para a rede queirá interligar casas inteligentes, concentradores e medidores inteligentes.

No lado da demanda, o uso de aparelhos inteligentes, a adoção de veículos elé-tricos e a geração distribuída fazem com que o perfil de carga do consumidor seja vari-ado [Simmhan et al. 2013]. Os dados gerados do lado da demanda deverão ser filtrados etratados a fim de gerar informação útil para as concessionárias [dos Santos 2014].

A rede de distribuição será muito mais ativa. A GD poderá ser conectada às redesde distribuição ou ainda em redes de transmissão, e o controle deverá ser coordenado. Afunção da rede de distribuição ativa é interligar de forma eficiente as fontes geradoras deenergia com a demanda dos consumidores, permitindo uma operação em tempo real. Aestrutura deste modelo é baseada no aumento da conectividade do sistema, como ilustradona Figura 2.4(b). Os tipos de geração deverão ser iniciados ou deixados em standby deacordo com o mercado de energia e com o controle da rede.

A necessidade de supervisão dessa rede aumenta já que o equilíbrio entre ofertae demanda, também chamado de balanceamento de carga, é essencial para um forneci-mento estável e confiável de eletricidade. A rede deverá interagir com o consumidor epara isso o nível de controle necessário é muito maior do que em sistemas de distribuiçãoatuais. Além disso, essa rede precisará ser protegida, e proteção requer tecnologias decusto competitivo, bem como novos sistemas de comunicação com mais sensores e atua-dores do que no sistema de distribuição atual [Bayod-Rújula 2009]. O uso de tecnologiada informação, comunicação e infraestruturas de controle serão necessárias devido ao au-mento da complexidade de gerenciamento do sistema. O controle poderá ser distribuídoem microgrids e Virtual Power Plants (VPPs) para facilitar a gestão do sistema e sua in-tegração tanto no sistema físico como no mercado [Bayod-Rújula 2009]. Esses conceitosserão explicados com maiores detalhes nas Seções 2.3.2 e 2.3.3.

A GD tem características diferentes das plantas tradicionais. Como será vistoadiante, as fontes de energia renováveis apresentam maior intermitência. Um painel solar,



(a) Geração de energia de forma convencional [Lopes et al. 2012].

(b) Geração Distribuída.

Figura 2.4. Comparação da Geração de energia da forma tradicional com a Gera-ção Distribuída.

por exemplo, não gera energia durante a noite. Esse modelo deverá ser tratado com oapoio de tecnologias e sistemas inteligentes de previsão de comportamento para tomarações benéficas para o sistema.



As redes de transmissão de longa distância estão sendo equipadas com Unidadesde Medição Fasorial (Phasor Measurement Units (PMU)) para detectar e prevenir falhasem cascata. E uma rede robusta será necessária para compartilhar esses dados. Em todasas partes das redes elétricas inteligentes, o futuro do sistema depende fortemente de umarede de comunicação eficiente, escalável, robusta, flexível e segura.

Ressalta-se que a migração bem sucedida para um futuro sistema de energia sus-tentável envolve não só as empresas de transmissão, de distribuição e geração, mas simtodos os interessados: governos, entidades reguladoras, consumidores, geradores, comer-ciantes, fornecedores de equipamentos de energia, prestadores de serviços de telecomu-nicações, etc. Todos os interessados precisam se envolver para alcançar o sucesso dasredes elétricas inteligentes. Além disso, algumas ações são necessárias: a exploraçãocontínua de novas fontes de energia e investimento em desenvolvimento de recursos re-nováveis; a modernização das instalações e equipamentos no sistema de energia elétrica;a inclusão e aumento da geração distribuída de energia, das fontes de energia renováveis,e do armazenamento de energia; a inovação das tecnologias de informação e comunica-ção; a integração com a infraestrutura legada e a motivação e participação por parte dosconsumidores.

2.2.3. Áreas Chaves e Forças Motrizes

O modelo conceitual das redes elétricas inteligentes foi proposto pelo National Insti-tute of Standards and Technology (NIST) [NIST 2010] e é ilustrado na Figura 2.5 comfluxos bidirecionais de informação. O NIST divide o modelo em sete domínios que,juntos, representam a comunidade de redes inteligentes de interesse. Esses domíniossão [Guimarães et al. 2013]:

• Domínio de geração de energia: composto pelas tradicionais plantas de geração epelo armazenamento de energia. Para que possa trocar informações sobre a quan-tidade de energia gerada, troca dados com a operação da rede elétrica e com omercado de energia.

• Domínio dos consumidores: a geração de energia em pequena escala se encontranesse domínio. Além disso, agrega funcionalidades como consumo e armazena-mento energético. Para isso, se comunica com os domínios de operação da rede ede mercado de energia.

• Domínio de Distribuição e Domínio de Transmissão: passam a ser muito mais ati-vos, trocando informação com a operação da rede elétrica, com consumidores eseus medidores inteligentes e com o mercado de energia.

• Domínio de provedores de serviços: se comunica com os consumidores para fa-turamento, operações de resposta à demanda e serviços de terceiros. Para obterinformações de medições e controle da rede elétrica, se comunica também com odomínio de mercado e de operação da rede elétrica.

• Domínio do mercado de energia (atacado, varejo e comércio): é responsável pelobalanceamento de oferta e demanda de energia e, portanto, coleta e envia infor-



mações de oferta e demanda aos domínios de geração, provedores de serviços eoperação da rede elétrica inteligente.

• Domínio da operação da rede elétrica: se comunica com todos os outros domíniosa fim de coletar os dados para garantir o controle e a operação eficiente do sistema.

Esses domínios se comunicam entre si conforme mostrado na Figura 2.5.

Figura 2.5. Atores das redes elétricas inteligentes e a comunicação entreeles [NIST 2010].

Apesar de serem domínios separados, são intimamente relacionados. Uma aplica-ção de um domínio pode interferir na outra, pode necessitar de dados de outros domínios,pode se comunicar com outra aplicação, etc. Além disso, aplicações tradicionais deve-rão coexistir com as novas aplicações advindas das redes elétricas inteligentes. Exemplosdestas aplicações são a teleproteção e o Sistema de Supervisão e Aquisição de Dados - Su-pervisory Control and Data Acquisition (SCADA) também chamado de software supervi-sório. A teleproteção usa um sistema de comunicação entre duas subestações, com isso seum equipamento de proteção em uma subestação detecta uma falha em uma extremidade,a outra extremidade é notificada e ações de proteção são iniciadas a fim de isolar a falha.Já o sistema SCADA, que no passado era suportado por mainframes e sistemas fechadosde fornecedores, atualmente, faz uso da rede de comunicação para interconectar todos osequipamentos das subestações que são supervisionados por ele. O SCADA é utilizadopara supervisionar, controlar, otimizar e gerenciar os sistemas de geração e transmissãode energia elétrica. Entre os benefícios trazidos pelos sistemas SCADA, destacam-se aanálise de consumo e demanda, a análise da carga dos consumidores, a verificação defalhas, o rearranjo da topologia, a análise da carga nos transformadores, a medição inteli-gente, entre outros [Lopes et al. 2012]. Com a evolução para as redes elétricas inteligen-tes, o SCADA incorporará novos elementos inteligentes, tais como: unidades de mediçãofasorial, relés inteligentes, novas fontes de geração de energia com utilização de fontesrenováveis, armazenamento de energia em veículos elétricos (EV), etc [Giani et al. 2011].



Ao permitir geração de energia pelo consumidor, uma rede elétrica inteligentepromove uma estreita relação entre compradores e vendedores, clientes e concessionárias.Um fluxo bidirecional de energia e comunicação bem como as capacidades plug-and-play são seu objetivo final e permitirão que várias tecnologias possam fornecer, entregare utilizar os recursos de forma confiável, eficiente e segura.

Com base no que foi discutido, nota-se que as redes elétricas inteligentes permitemnovas estratégias de gestão de rede [Palensky and Dietrich 2011, Calderaro et al. 2011],além de novas aplicações e benefícios para a sociedade.

2.2.4. Gerenciamento pelo lado da demanda (DSM) e a resposta à demanda (DR)

Segundo o EPRI (Electric Power Research Institute), resposta à demanda (Demand Res-ponse (DR)) é uma mudança temporária no consumo de energia em resposta às condiçõesde fornecimento de energia ou aos eventos na rede [EPRI 2009]. A inclusão de novasfontes de energia e elementos de armazenamento combinados com a necessidade de re-duzir os picos de carga impulsionaram a introdução de aplicações de resposta à demanda.Para isso, incentivos monetários podem ser usados de modo a evitar preços elevados deenergia. Essas aplicações objetivam prover confiabilidade através de uma série de açõesque visam reduzir a carga da rede no horário de pico, quando a concessionária está pertoda sua capacidade máxima. Por exemplo, pode-se reduzir a quantidade de energia consu-mida pelos aparelhos durante o período de pico de potência, evitando inclusive apagões.Nesse cenário, o cliente passa a ter um papel ativo no fornecimento de energia elétrica.Esse sistema permite que consumidores transfiram o consumo de energia para momen-tos fora do horário de pico, tomando vantagem do preço da energia em tempo real, dasinformações da rede, controle da carga, etc [Bayod-Rújula 2009].

Conceitualmente, a resposta à demanda é equivalente ao aumento de geração noprocesso de equilíbrio do sistema. A solução de reduzir o uso de energia e utilizar a gera-ção distribuída quando a oferta de energia é baixa tem ganhado cada vez mais aceitaçãono mercado. A DR e a Demand Side Management (DSM) reduzem a carga e acrescentama capacidade de geração em caso de emergência.

A DR, muitas vezes, usa a GD de forma que a energia passe a ser provida de umponto mais próximo do consumo ou passe a receber energia de outras fontes conectadasà rede. Assim, em alguns casos, a DR pode não só reduzir o consumo global de energia,mas também mudar a origem da geração para uma GD. Ressalta-se que para que sejapossível a implementação da DR, outro driver da rede elétrica inteligente precisa sem im-plementado, a automação da distribuição (Distribution Automation (DA)). A DA é a ideiade se estender o monitoramento e controle da rede até a distribuição, de forma que dispo-sitivos que antes não eram automatizados passem a ser. Atualmente, empresas de energiaestão acostumadas com a gestão de um número limitado de pontos de monitoramento econtrole, por exemplo, centenas de subestações. Novas tecnologias de comunicação de-vem ser introduzidas na distribuição a fim de conectar dezenas de milhares de endpointsencontrados na automação da distribuição.



2.3. Geração Distribuída de EnergiaUma breve revisão da literatura mostra que não há consenso sobre uma definição precisado conceito de GD, que engloba muitas tecnologias e aplicações [Pepermans et al. 2005,Ackermann et al. 2001, El-Khattam and Salama 2004]. Em geral, o conceito de geraçãodistribuída é baseado na inserção de novas fontes geradoras de energia, de forma distri-buída, no sistema elétrico. Mesmo as organizações de caráter técnico, como o Instituteof Electrical and Electronic Engineers (IEEE), o International Council on Large ElectricSystems (CIGRE) e o International Energy Agency (IEA) divergem em algum momentocom relação à definição de GD. No entanto, essa diversidade de opiniões não representauma situação de falta de entendimento, mas, sim, indica a recente evolução conceitualde um tema e a dificuldade de se definir uma tendência razoavelmente nova na indús-tria, no mercado e nas agências reguladoras de energia elétrica [Ackermann et al. 2001].[Ackermann et al. 2001] e [El-Khattam and Salama 2004] listaram várias definições pro-postas na literatura em que os seguintes aspectos foram analisados individualmente:

• O propósito: relaciona o objetivo da GD. É praticamente consenso entre os autoresque o propósito da GD é prover fontes de energia elétrica ativas.

• A localização: a grande maioria dos trabalhos na literatura definem a localizaçãoda GD no lado da rede de distribuição. Porém, alguns autores também a incluem nolado do consumidor e na rede de transmissão. Um exemplo dessa conexão ocorrequando fazendas eólicas são conectadas diretamente na rede de transmissão, umcaso típico de GD. Porém, caso essa localização não seja aceita como definição,essa geração não seria considerada GD. Ressalta-se que o o art. 14 do Decreton.◦ 5.163/2004, primeira norma brasileira a definir GD, define a geração distribuídaestando conectada à distribuição.

• O nível de tensão: esse atributo é um dos que mais divergem na literatura como podeser visto em [El-Khattam and Salama 2004, Ackermann et al. 2001]. A seguir esseassunto será detalhado.

• A área de entrega da energia gerada: refere-se ao local onde a energia deve ser con-sumida, por exemplo, no local que é gerada. Porém, segundo [Ackermann et al. 2001]e [El-Khattam and Salama 2004], a definição da área de entrega de energia restritaao local onde foi gerada pode desqualificar um projeto como GD, já que uma dasideias da GD é prover energia para outros em momentos de pico.

• A tecnologia: refere-se ao tipo de tecnologia usada para geração de energia, comopor exemplo energia solar.

• A propriedade: refere-se a ideia da geração ser classificada como GD apenas sefor propriedade de um consumidor ou de um produtor independente de energia.[Ackermann et al. 2001] não considera esse fator para definição de GD.

• O nível de penetração: quantidade total de GD vinculada a uma rede de distribuição.

Dentre estes aspectos, somente a localização foi citada em todas as definições,seguido do propósito, nível de tensão e da tecnologia para geração de energia. Os outros



aspectos são citados em poucos trabalhos. Com isso, a definição em termos de conexão elocalização é a mais discutida e vai ao encontro da ideia defendida pelo INEE (InstitutoNacional de Eficiência Energética), que define GD como a geração elétrica realizada juntoou próxima dos consumidores, independente da potência, tecnologia e fonte de energia.O conceito envolve, ainda, equipamentos de medida, controle e comando que articulam aoperação dos geradores e o eventual controle de cargas para que estas se adaptem à ofertade energia.

Figura 2.6. Capacidade de produção dos diferentes tipos deGD [El-Khattam and Salama 2004]

Para Rujula et al. [Bayod-Rújula 2009], a tendência para GD é a geração em tornode 1kW até 1MW, o que é uma potência bem menor que a dos geradores tradicionais, queficam longe das cargas e centralizados, que costumam gerar entre 100MW e 1GW. NoBrasil, pela Resolução Normativa no 482/2012 da Agência Nacional de Energia Elétrica- ANEEL de abril de 2012, uma microgrid, detalhada a seguir na Seção 2.3.2, tambémchamada de microgeração distribuída, possui potência instalada menor ou igual a 100 kWe a mini-rede, ou minigeração distribuída possui potência instalada superior a 100 kW einferior a 1 MW. A Figura 2.6 ilustra a classificação relacionada à capacidade de geraçãoda GD, segundo a visão de El-Khattam e Salama [El-Khattam and Salama 2004]. Emcomparação com a visão da Resolução no 482/2012 da ANEEL, nota-se que são visõesbem distintas. Nesse capítulo, é adotada a definição do INEE e não serão detalhadas asvárias definições na literatura, nem defendido uma valor de capacidade de geração. Asautoras concordam que o conceito envolve uma geração mais próxima dos consumidorescom um sistema que deixa de ser centralizado em poucas usinas de grande porte e passaa contar com outros tipos de geração, sem necessariamente ficar preso a sua capacidadede geração. Assim, a Figura 2.7 mostra que a existência da GD faz com que a gera-ção e distribuição de energia deixe de se parecer com uma árvore, como foi ilustrado naFigura 2.4(a) e pareça uma malha, o que aumenta a confiabilidade no sistema elétrico.

Exemplos de tecnologias para GD são painéis fotovoltaicos, microturbinas ou cé-lulas de combustível. Ressalta-se que uma unidade de GD pode utilizar fontes renováveisde energia ou não. O impacto que esse novo modelo de geração de energia traz para osistema é enorme. Para entender como a mudança na infraestrutura elétrica pode afetar arede de comunicação, é necessário o entendimento sobre conceitos básicos desse tipo degeração. A capacidade de atender o sistema no horário de pico, o uso de veículos elétricose de energia gerada pelo consumidor para provimento de energia, as microgrids e as VPPs,como será discutido mais adiante, são características desse novo modelo. Ressalta-se quea geração tradicional, de forma centralizada, e a sua transmissão em grandes quantidadese em alta tensão ainda desempenharão um papel importante no sistema, mesmo que a GDseja completamente implementada.



Figura 2.7. Malha de distribuição de energia com diversas fontes geradoras,devido ao uso da GD, aumentando a confiabilidade da rede elétrica.

2.3.1. Breve Histórico e Conceitos Básicos

A geração de eletricidade em pequena escala é um conceito relativamente novo no mer-cado de energia, mas a ideia por trás deste conceito não é nova [Pepermans et al. 2005,El-Khattam and Salama 2004]. No início das redes de energia elétrica, a geração dis-tribuída era regra e não exceção [Bayod-Rújula 2009]. As primeiras usinas de energiasó forneciam eletricidade para os clientes numa vizinhança próxima da planta de ge-ração [Pepermans et al. 2005]. As primeiras redes de energia eram baseadas em cor-rente contínua (Direct Current (DC)), e, por conseguinte, a tensão de alimentação eralimitada, assim como a distância entre o gerador e o consumidor [Bayod-Rújula 2009,Pepermans et al. 2005].

O equilíbrio entre a demanda e o fornecimento de energia era parcialmente feitocom o uso de armazenamento local. Um exemplo é o uso de baterias que podem ser liga-das diretamente à rede DC. Mais tarde, as evoluções tecnológicas, tais como o surgimentode redes de corrente alternada (Alternating Current (AC)), permitiram que a eletricidadefosse transportada por longas distâncias. Com isso, a eletricidade passou a ser geradade forma centralizada, longe dos grandes centros e em grande escala, como acontece nosistema tradicional. Essa estrutura atual do sistema de energia elétrica, em particular nosEUA, permanece quase inalterada em comparação com o que se construiu há mais de umséculo atrás [Strachan and Farrell 2006], cenário muito parecido com o Brasil. O sistemaexistente passa apenas por melhorias e atualizações sobre os tipos de materiais utilizadospara transformadores, linhas de transmissão, postes e isoladores [Lo and Ansari 2012],mas grandes revoluções tecnológicas ainda não aconteceram [Gungor et al. 2011].

Além da característica centralizada do sistema tradicional de geração de energia,ressalta-se que as demandas são passivas, incontroláveis e conectadas ao sistema de dis-tribuição que também é passivo [Bayod-Rújula 2009]. O sistema é projetado para levar



pelo sistema de transmissão a energia gerada e distribuir aos clientes de forma unidireci-onal. Com o advento das redes elétricas inteligentes e com o uso da GD, vários pequenosgeradores estarão distribuídos e ligados à rede de distribuição (ou transmissão). Essasunidades de GD podem funcionar de maneira independente para suprir demandas locaisou de forma integrada fazendo parte das microgrids.

Existem muitos fatores, na última década, que contribuíram para um interesserenovado pela GD. Muitos autores atribuem o interesse pela geração de forma distri-buída à inovação tecnológica crescente e à mudança no ambiente regulatório e econô-mico. Outros, enfocam nas preocupações ambientais, tema muito debatido nos últimosanos. Porém, a Agencia Internacional de Energia (IEA) lista cinco fatores principais quecontribuem para a evolução da GD [(IEA) 2002]:

• as preocupações com relação à mudança climática;

• o crescente desenvolvimento das tecnologias para geração distribuída;

• as restrições com relação à construção de novas linhas de transmissão;

• o aumento da demanda dos clientes por energia elétrica altamente confiável;

• a liberalização do mercado da eletricidade.

A situação atual do Brasil não é boa. O país passa por uma crise hídrica forte,racionamentos e, mesmo assim, os incentivos fiscais para implementação de geração deenergia do lado do cliente ainda são insatisfatórios.

Por outro lado, com um planejamento eficiente e com uma operação inteligentedessa rede, será possível que a GD tenha um papel maior no futuro, contribuindo paraa melhoria da eficiência energética, redução no custo de distribuição e melhoria da qua-lidade de energia [Bayod-Rújula 2009]. Ressalta-se que a integração eficiente de umaparcela crescente de geradores distribuídos exige fortes inovações de rede. Além disso,um controle coordenado e um gerenciamento inteligente são premissas importantes.

De acordo com o IEA [(IEA) 2002], a produção local pode resultar em uma eco-nomia de cerca de 30% do custo da eletricidade, devido a transmissão e distribuição. Emgeral, quanto menor o tamanho do cliente, maior a proporção dos custos de transmis-são e distribuição no preço da eletricidade (acima de 40% para as famílias por exemplo).Além disso, uma vez que os locais de geração distribuída são preferencialmente próxi-mos da carga, a GD também contribui para a redução de perdas na rede [(IEA) 2002,Bayod-Rújula 2009].

Identificar as necessidades de informação dos elementos do sistema e determinaruma forma para atender a essas necessidades é um fator importante para o sucesso da ge-ração distribuída de energia. Uma vez que os recursos são gerenciados até o consumidor,questões como qualidade de serviço na rede de telecomunicações passam a ser essenciaispara o projeto das novas infraestruturas. Assim, torna-se necessária uma análise extensados requisitos da rede, devido à diversidade de desempenho da rede elétrica inteligente,particularmente em sua latência, prioridade e criticidade. Diversas cargas e demandaspodem possuir diferentes prioridades na rede e gerenciar esse sistema não é tarefa fácil.



2.3.1.1. Tecnologias, Aplicações para GD e Armazenamento de Energia

O conceito de GD não envolve apenas geração com fontes limpas. Cabe observar quequando se fala em energia limpa, não se trata apenas de fontes de geração que não cau-sem nenhum impacto ambiental. Na verdade, trata-se de fontes de geração de energiaque não lançam poluentes na atmosfera. Entre as formas de energia que atendem a essesrequisitos estão: energia eólica, energia solar, energia maremotriz, energia geotérmica,energia hidráulica, etc. Estas podem ainda ser separadas em energias renováveis intermi-tentes ou não variáveis como ilustra a Figura 2.8. As fontes de energia não renováveis,como nuclear, por natureza não são variáveis.

A geração de energia de forma distribuída ganha um impulso maior com geraçõesrenováveis mas ainda conta com a geração tradicional. Exemplos de tipos e tecnologiasde geração distribuída são apresentados na Figura 2.8, onde:

(a) Tecnologias de Geração. Adaptado de [EPRI 2009].

(b) Tipos de geração distribuída. Adaptada de [El-Khattam and Salama 2004].

Figura 2.8. Tecnologias e tipos de Geração Distribuída.



• Biocombustíveis: a energia da Biomassa é aquela que utiliza fontes orgânicas deorigem animal ou vegetal [Kagan and Gouvea 2013]. Dois que chamam a atençãoatualmente são o etanol, produzido no Brasil a partir da cana-de-açúcar e, em outrospaíses, como os Estados Unidos, a partir do milho; e o biodiesel, obtido a partirde óleos vegetais, residuais (como de frituras) e gorduras animais [Fogaça 2015].Atualmente as usinas térmicas a biomassa representam 6,6% da matriz de energiaelétrica do Brasil [Kagan and Gouvea 2013].

• Energia eólica: instalações eólicas são compostas por hélices presas em um pilar,que captam a energia mecânica produzida pelos ventos para transformá-la em ener-gia elétrica [Fogaça 2015]. O Brasil possui um imenso potencial para aplicação deenergia eólica, possuindo ventos em faixas superiores a muitos países onde essa tec-nologia já é amplamente utilizada, porém essa energia contribui com apenas 0,7%da matriz energética brasileira [Kagan and Gouvea 2013].

• Energia solar: um sistema de geração fotovoltaica é uma fonte de energia que,utilizando células fotovoltaicas, converte diretamente energia luminosa em eletrici-dade [Kagan and Gouvea 2013]. Entre os impactos ambientais, temos os que ocor-rem somente na extração e no processamento do silício [Fogaça 2015]. O Brasilpossui um grande potencial de irradiação solar, maior do que duas vezes o poten-cial da Alemanha, pais líder de sistemas fotovoltaicos em capacidade instalada,porém os sistemas fotovoltaicos conectados à rede brasileira são poucos, e aindanão aparecem no ONS [Kagan and Gouvea 2013].

• Energia geotérmica: “geo” significa terra e “térmica” corresponde a calor, portanto,a energia geotérmica é a energia calorífica da terra [Fogaça 2015], calor que existeno interior da terra [Kagan and Gouvea 2013]. Esse calor faz a água de camadassubterrâneas evaporar e esse vapor é conduzido por meio de tubos até lâminas deuma turbina que são giradas por ele. Um gerador transforma essa energia mecânicaem elétrica [Fogaça 2015]. No Brasil, não há nenhuma unidade em operação, nemsob a forma experimental [Kagan and Gouvea 2013].

• Energia das marés (maremotriz): pode ser captada de duas formas: energia po-tencial, pelas variações do nível do mar, e energia cinética, pela correntes Maríti-mas [Kagan and Gouvea 2013].

• Energia hidráulica: são construídas usinas hidrelétricas de pequeno porte, cha-madas de PCH (Pequena Central Hidrelétrica), ou de grande porte, que aprovei-tam o movimento das águas dos rios que possuem desníveis naturais ou artifici-ais [Fogaça 2015]. Funcionam através da pressão da água que gira uma turbina,transformando a energia potencial em energia mecânica. Depois de passar pela tur-bina, o gerador transforma a energia potencial em energia elétrica. Essa energia to-taliza a maior contribuição da matriz energética Brasileira [Kagan and Gouvea 2013],e continua aumentando como pode ser visto na perspectiva de evolução da capaci-dade instalada até 2020 apresentada pelo ONS, ilustrada na Figura 2.9.

Além das energias solar e eólica, ilustradas na Figura 2.8(a), a energia das maréstambém se enquadra como energia renovável intermitente. A energia intermitente nem



Figura 2.9. Evolução da Capacidade Instalada - Perspectiva do Plano Decenal2020 [Brasil 2012].

sempre está disponível e não há uma forma de controlar a sua disponibilidade. Contudo,a energia solar e da marés tem variações regulares e mais previsíveis, ao contrário daenergia eólica que é menos regular conforme ilustram os gráficos da Figura 2.10.

(a) Intermitência da Geração Solar. (b) Intermitência da Geração Eólica.

Figura 2.10. Intermitência da Geração de Energia [Brasil 2012].

As energias renováveis intermitentes tem uma grande variabilidade, e as mudan-ças ocorrem em curto prazo, o que pode causar um desequilíbrio de energia no SEP. Poresse motivo, esse tipo de geração precisa ser minuciosamente controlado, visto que essesdesequilíbrios têm que ser regularizados rapidamente. Outro ponto importante é que ospróprios geradores de energia possuem controles próprios, já que a fonte de geração podeaumentar rapidamente e em grade escala. Por exemplo, um gerador eólico pode se des-ligar, para proteção mecânica, quando os ventos ficarem muito fortes. Se o sistema nãofor capaz de absorver toda a geração de energia renovável que estiver sendo produzida,a geração deve diminuir ou cessar para que o sistema não desequilibre. A integração defontes de energia renováveis em grande escala deverá, portanto, contar com o apoio detecnologias avançadas tanto na área de elétrica quanto de comunicação com um sistemade controle robusto.



Para compensar ou atenuar a intermitência causada por esse tipo de geração, pode-se usar o armazenamento de energia que tem um papel estratégico no futuro do sistema deenergia além de ser uma forma de tornar o sistema mais eficiente. O armazenamento deenergia consiste em um estágio intermediário entre a produção de energia e seu consumo.Ele reduz a exportação da energia gerada para o sistema de distribuição, pois desvia parteda energia gerada para um dispositivo de armazenamento, como baterias.

Com o uso do armazenamento de energia, a possibilidade de equilíbrio entre ageração de energia e demanda de energia é possível tanto armazenando energia quandoessa é gerada em excesso, quanto utilizando a energia armazenada quando o forneci-mento não for suficiente. Portanto, o armazenamento de energia torna o sistema maisflexível para atender as demandas. Ao contrário do controle de carga, a energia armaze-nada pode ser recuperada na forma elétrica e não requer a participação dos consumidores.O uso de baterias ainda é uma opção que envolve um alto custo de investimento, porémos estudos nessa área estão avançando. O foco da pesquisa nesse cenário encontra-senas tecnologias de armazemento de energia, incluindo soluções avancadas para baterias,sistemas SMES (Superconducting Magnetic Energy Storage), armazenamento de energiaem ar comprimido, ultracapacitores e flywheels - conhecidos como rotores de inércia emportuguês [Bayod-Rújula 2009]. Uma abordagem economicamente viável para mitigar aintermitência das fontes de energia renováveis é o armazenamento de água em hidrelétri-cas.

Uma abordagem alternativa é o armazenamento em baterias de veículos elétri-cos. O uso de veículos elétricos em redes inteligentes extrapola a ideia de apenas a redeser usada como fornecedor de energia. Grid-to-Vehicle/Vehicle-to-Grid são dois concei-tos dos quais o primeiro usa um veículo elétrico, também chamado de Plug-in- HybridEletric Vehicle (PHEV), como armazenamento e o segundo o usa como fonte de ener-gia. Assim vários veículos elétricos podem formar um sistema de geração distribuídona rede [Lopes et al. 2012]. Um veículo elétrico pode ser carregado ou descarregado nacasa do consumidor, ou em estações especiais de abastecimento. Os veículos elétricosirão adicionar dezenas de milhares de terminais móveis não só para a rede elétrica, mastambém para redes de comunicação [Budka et al. 2010b].

Uma segunda abordagem interessante para atenuar a intermitência na geração,mas que depende da ação dos consumidores, é a tarifa flexível. Com medidas que alteremo consumo para horários onde a disponibilidade de recursos energéticos é maior, pode-seaproveitar melhor os recursos energéticos renováveis.

Diferentes métodos e tecnologias deverão ser utilizados para implementação doleque de possíveis aplicações trazidas pela GD. Essas aplicações variam de acordo comseus requisitos, incluindo carga, tipo de GD utilizada, objetivos, dentre outros. As princi-pais aplicações para GD são mencionadas a seguir [El-Khattam and Salama 2004]:

• standby: a geração distribuída pode ser utilizada como uma reserva para fornecerenergia para cargas sensíveis, como indústrias e hospitais, durante interrupções darede onde o sistema convencional é afetado.

• Stand alone: áreas isoladas, que normalmente possuem obstáculos geográficos quetornam cara a infraestrutura para conexão à rede, usam a geração distribuída como



fornecedor de energia em vez de se conectar à rede elétrica.

• carga de pico: o custo de energia elétrica varia de acordo com as curvas de demandade energia, os tipos e quantidade de geração disponíveis em determinado período.Por isso, a GD pode ser usada para fornecer energia em períodos de pico, o quereduz o custo de energia elétrica para grandes clientes industriais que pagam tarifashoro-sazonais (TOU) 4. Além disso, com o auxílio de armazenamento de energia,a energia gerada em momentos em que a sua produção é mais barata pode ser ar-mazenada para uso em momentos onde a geração de energia é cara. Com isso,pode-se tirar proveito da flutuação do preço da energia no mercado, armazenando eliberando energia em momentos convenientes.

• aplicações rurais e remotas: a geração distribuída pode fornecer às aplicações re-motas a energia necessária. Estas aplicações incluem iluminação, aquecimento, re-frigeração, comunicação e pequenos processos industriais, desde que haja um bomsistema de armazenamento. Além disso, a GD pode apoiar e regular a tensão dosistema em aplicações rurais (cargas sensíveis) conectadas à rede.

Portanto, o controle, a coordenação e a operação do sistema elétrico têm muitaimportância. Por exemplo, recursos de energia solar produzem o seu máximo durante odia e recursos eólicos produzem o seu máximo durante a noite, como pode ser observadonos gráficos da Figura 2.10. Além disso, o sistema contém também geração de formaconstante, como hidrelétricas, onde a geração só aumenta ou diminui se a usina receberessa ordem. Com isso, pode-se pensar em uma produção resultante mais uniforme comum equilíbrio entre essas gerações. Atualmente, quem coordena essas operações é o ONSque conta com centros de operação espalhados pelo país, que atuam sem interrupção fa-zendo a coordenação, a supervisão e o controle da operação de toda a matriz de energiaelétrica brasileira. Com o advento das redes elétricas inteligentes e da geração distribuída,com uma quantidade enorme de fontes diferenciadas, esse conceito poderá mudar. Con-trolar residências para que parem de gerar energia e disponibilizá-la na rede, as diversasformas de geração, o armazenamento de energia, os veículos elétricos, etc, não são tarefasfáceis. A forma com que a GD será gerenciada é um desafio enorme, tanto para a área deelétrica quanto para a área de redes de comunicação e computação.

Quando a geração distribuída, o armazenamento de energia e outros aspectos co-meçam a se interligar tornam possíveis o desenvolvimento de várias aplicações chavedas redes elétricas inteligentes, como é o caso das microgrids e das VPPs que dependemdiretamente da GD para existirem.

2.3.2. Microgrids

A microgrid é um novo paradigma que consiste na criação de pequenos sistemaselétricos localizados e compostos por geração, armazenamento e cargas com a ideia de serautossuficiente. É um novo paradigma que pode combinar vários Recursos Energéticos

4É o sistema de tarifação atualmente utilizado em que o preço das tarifas é diferenciado para os diferenteshorários do dia (ponta e fora de ponta) e períodos do ano (seco e úmido).



Distribuídos (Distributed Energy Resources (DER)) para formar um todo. As unidades deDER são as fontes geradoras de energia que podem ser compostas por unidades de geraçãodistribuída e por unidades de armazenamento distribuído, incluindo veículos elétricos.

Assim, esse conceito inclui GD, armazenamento de energia, conexão entre GDe rede externa de energia, e mecanismos de controle [Pan et al. 2014]. Várias micro-grids interligadas, de acordo com o conceito plug and play, podem criar uma rede ma-cro, chamada de macrogrid [Lopes et al. 2012]. Com isso, o controle de uma micro-grid deve considerar três camadas, sendo elas o fluxo de informação, o fluxo de tensãoe a camada física (real), mostrada na Figura 2.11. Embora a microgrid opere principal-mente ligada à rede de distribuição [Bayod-Rújula 2009], ela pode operar na forma de“ilha", onde a própria energia gerada pela geração distribuída supre a necessidade da de-manda [Lopes et al. 2012]. Esse modo, também chamado de ilhamento, faz com que amicrogrid funcione de forma autônoma, desligada da rede externa. Esse modo propor-ciona continuidade do fornecimento em caso de falhas na rede externa. Nesse caso, amicrogrid pode ser ressincronizada com o macrossistema após a restauração da rede ex-terna [Bayod-Rújula 2009]. Dessa forma, as microgrids podem melhorar a confiabilidadeno fornecimento de energia, pois se baseiam na premissa de que a geração de energia, oua maior parte dela, está próxima ao consumidor e restrita a uma área menor.

Figura 2.11. Exemplo de uma microgrid, onde a comunição e a distribui-ção elétrica coexistem, interligando as diversas fontes de geração distribuí-das [Fang et al. 2012].

Dentro do contexto de uma microgrid, as fontes de energia podem ser de geradoresou ainda de bancos de armazenamento de energia. Um tipo de banco de armazenamentoque pode ser de grande utilidade no momento de uma falha do fornecimento são as bate-rias dos carros elétricos.

É desafiadora a necessidade de tornar o lado do consumidor mais inteligente, maiseficiente e rentável. Especialmente no futuro, a GD e as microgrids serão muito comunscom casas e prédios fazendo uso da energia renovável. Quando a capacidade das fontesgeradoras exceder a própria demanda, o restante de energia deverá ser exportada para



a microgrid e a macrogrid. Uma programação dinâmica e otimizada destes geradoresdistribuídos pode alimentar as demandas e reduzir o custo total, além de alcançar umamaior eficiência energética em escala.

Em uma microgrid, são usados controladores, que são dispositivos que são co-nectados aos geradores e às cargas para controlar o funcionamento destes. As cargas sãoquaisquer dispositivos elétricos conectados à rede que necessitem de energia elétrica parafuncionar, os consumidores de energia. As cargas podem ter características bem diferen-tes, podendo ser usuários residenciais, comerciais e industriais.

A maioria das microgrids podem ainda ser descritas por uma das quatro catego-rias [mic 2015]:

• Off-grid microgrids: inclui ilhamento, sites remotos e outras microgrids não conec-tadas a rede elétrica local.

• Utility-integrated campus microgrids: estão totalmente interligadas com a rede elé-trica local, porém podem manter algum nível de serviço de forma isolada, comodurante a falta de energia elétrica. Exemplos típicos são universidades, campuscorporativos, prisões e bases militares.

• Community microgrids: são integrados a rede da concessionária. Tais microgridsatendem múltiplos clientes ou uma comunidade.

• Nanogrids: atendem edifícios ou locais individuais, tais como instalações comerci-ais, industriais, residências, sistemas de tratamento de água e estações de bombea-mento.

Ressalta-se que a microgrid tem seus próprios requisitos de controle entre gerado-res e consumidores de energia devido à sua escala limitada e, portanto, requisitos especí-ficos. Os métodos de controle utilizados dentro das microgrids podem ser centralizados,distribuídos ou hierárquicos ou métodos que combinam vários tipos. O mecanismo decontrole deve permitir a adição e remoção flexível de geradores distribuídos em um estilo“plug-and-play”, sem perturbar o resto do sistema ou sem a necessidade de reconfigu-rar todo o sistema. O controle também pode atribuir diferente prioridade às cargas, quepodem ser priorizadas de acordo com a sua importância como mais ou menos críticas.

2.3.3. VPP (Virtual Power Plant)

Uma VPP, também conhecida como Virtual Utility, pode ser definida como umnovo modelo de infraestrutura de energia que consiste na integração de diferentes tiposde GD controlados por um sistema de gerenciamento de energia (Energy ManagementSystem (EMS)). A rede é composta por um controle centralizado de diferentes gruposde geração distribuída, chamados de clusters. Cada um destes clusters é controlado poruma estação de gerenciamento local (Local Management Station (LMS)) e cada LMS teminformações sobre os requisitos de energia dos usuários conectados ao seu cluster, comoeletricidade, nível de água no tanque, etc [Bayod-Rújula 2009]. Esse sistema é ilustradona Figura 2.12.



(a) Modelo de VPP, com o controle local e central das várias fontes geradoras.

(b) Agregação de GD com resposta à demanda, através da gestãode diversas VPPs integradas.

Figura 2.12. Conceito de Virtual Power Plant (VPP).

O EMS recebe as informações de cada LMS e define a entrada ou saída de ener-gia de cada cluster na rede. Com a informação da EMS, o LMS configura o cluster paraque ele entre em funcionamento ou fique em standby. Além disso, o EMS pode prio-rizar o uso de recursos de energia distribuídos (DERs) ao invés do uso de combustíveisfósseis. A produção de energia elétrica na rede está subordinada à necessidade de cadausuário [Bayod-Rújula 2009].

Os benefícios da VPP estão relacionados à otimização do rendimento de utilização



de toda a rede, à alta confiabilidade da produção de energia, ao controle total da rede paraatingir o principal objetivo da EMS, a alta velocidade necessária para acompanhar as mu-danças rápidas na demanda do sistema e a alta integração dos DERs [Bayod-Rújula 2009].

Para um operador de rede ou concessionária de energia, a compra de energia apartir de uma VPP é equivalente a compra a partir de uma planta convencional. O conceitode VPP não é por si só uma nova tecnologia, mas sim um método de organização degeração e armazenamento descentralizado de uma forma que maximiza o valor da energiagerada para a concessionária. A VPP usando GD, DER e armazenamento de energia tempotencial para substituir a planta convencional [Bayod-Rújula 2009].

2.3.4. Os Benefícios da Geração de Energia em Pequena Escala

A geração de energia de forma distribuída, organizada por meio de microgrids e VPPs,traz muitas vantagens, tanto para o consumidor quanto para as concessionárias. Entreessas vantagens, destacam-se:

• Diminuição do congestionamento de energia: Quando um sistema de transmissãoestá congestionado, uma GD adequadamente localizada pode reduzir o congestio-namento e, portanto, pode adiar a necessidade de investimentos em novas infraes-truturas [Bayod-Rújula 2009], especialmente quando o crescimento do congestio-namento é baixo [(IEA) 2002].

• Aumento do benefício ambiental: a utilização em larga escala de geração distri-buída irá reduzir o consumo de combustíveis fósseis e as emissões de gases de efeitoestufa, bem como as emissões nocivas, tais como óxido de enxofre e nitrogênio(SOx/NOx) , portanto, beneficiando o meio ambiente [Strachan and Farrell 2006].

• Segurança no abastecimento: com o aumento da GD, o abastecimento terá umamaior segurança visto que poderá contar com a energia do sistema externo e tam-bém com a geração em pequena escala [Bayod-Rújula 2009].

• Redução de perdas no sistema de distribuição e de transmissão: a GD vai mini-mizar as perdas do sistema, reduzindo a demanda de energia no sistema. Alémdisso, se um gerador distribuído ficar perto de uma grande carga, então sua ener-gia gerada pode ser exportada, o que também tende a reduzir as perdas do sis-tema [(IEA) 2002]. A geração local reduz a quantidade de energia que deve sertransmitida pela planta centralizada e evita as perdas de transmissão resultantesdesse processo [Bayod-Rújula 2009]

• Redução dos custos de transmissão e distribuição de energia: a geração local reduzos custos de transmissão e de distribuição. Uma parte significativa, acima de 30%,do custo total de eletricidade representa perdas no sistema [Bayod-Rújula 2009].

• Aumento da confiabiliade do sistema: a GD pode oferecer aos clientes uma con-tinuidade e confiabilidade maior do fornecimento de energia. Quando uma quedade energia ocorre em uma região, restaurar o provimento de energia em um curto es-paço de tempo é fundamental, e a GD auxilia esse fornecimento [Bayod-Rújula 2009].



• Aumento das oportunidades de mercado e da concorrência: todas essas tecnolo-gias oferecem novas oportunidades de mercado e aumento da competitividade in-dustrial. A GD também pode estimular a concorrência no fornecimento, o quesignifica um ajuste de preços no mercado. Em um ambiente de concorrência nomercado, o operador de uma GD pode comprar ou vender energia à rede elétrica,exportando energia apenas no horário de pico e comprando energia fora do horáriode pico [Bayod-Rújula 2009] com a energia mais barata.

• Investimento facilitado: de um ponto de vista de investimento, é geralmente maisfácil encontrar locais para instalação de pequenos geradores do que locais para umagrande usina. Além disso, um gerador local é colocado online muito mais rapida-mente. Com isso, numa visão ampla, o risco e as despesas de capital envolvidas como aumento do crescimento da demanda local são reduzidos [Bayod-Rújula 2009].

• Flexibilidade para instalação: a GD em muitos casos, fornece flexibilidade devidoàs suas pequenas dimensões e tempos de construção que são vantajosos por seremcurtos quando comparados com a maioria dos tipos de usinas [Bayod-Rújula 2009].

2.3.5. Requisitos de Comunicação

O advento das redes elétricas inteligentes traz novos conceitos e aplicações, e, com isso,novas necessidades. Uma infraestrutura de comunicação integrada [Jeon 2011] e confiá-vel é necessária para interconectar vários dispositivos na rede elétrica inteligente e proveruma rede eficiente. Além disso, a arquitetura das redes elétricas inteligentes precisa su-portar tanto as aplicações legadas quanto as aplicações emergentes. O SCADA e a tele-proteção são exemplos de aplicações legadas que deverão ser melhoradas. Como exemplode aplicações emergentes, temos a Infraestrutura de Medição Avançada - Advanced Mete-ring Infrastructure (AMI), os sincrofasores, a DA, a DR, os veículos elétricos, e a gestãodas microgrids [Deshpande et al. 2011]. Porém, essas aplicações possuem necessidades erequisitos de Qualidade de Serviço - Quality of Service (QoS) distintos, e seus vários tiposde mensagens com usos singulares podem ter requisitos de QoS muito diferentes, depen-dendo do seu seu tipo. A Figura 2.13 mostra uma representação gráfica dos requisitos deQoS para um conjunto de aplicações identificadas e quantizadas em [Hossain et al. 2012].Os autores ilustraram os requisitos de QoS para cada aplicação dispostos em dois eixos,confiabilidade e latência. Por exemplo, a confiabilidade e os tempos de latência para todasas mensagens associadas com os sistemas de controle centralizado para DR são maioresque 99.5% e menores que 5s respectivamente. Algumas aplicações se encaixam em faixasdiferentes. Por exemplo, o PHEV tem tipos de mensagem que se encaixam em diferentesvalores: confiabilidade maior que 98% e latência menor que 15s; confiabilidade maiorque 99% e latência menor que 10s; confiabilidade maior que 99% e latência menor que15s e confiabilidade maior que 99,5% e latência menor que 10s. Esse comportamentoreforça a ideia de diversidade entre os requisitos de QoS das aplicações em redes elétricasinteligentes.

Como as redes elétricas inteligentes vão incorporar um grande número de dispo-sitivos, os tipos e quantidade de tráfego irão aumentar exponencialmente. Esse aumentopode criar um gargalo na infraestrutura de comunicação das redes elétricas inteligentes.



Figura 2.13. Aplicações nas redes elétricas inteligentes categorizadas por atrasoe requisitos de confiabilidade. Adaptada de [Hossain et al. 2012].

Como resultado, a latência e a perda de pacotes, devido a congestionamentos, podem sergraves [Hossain et al. 2012].

Além disso, o tráfego pode ser gerado de forma periódica, onde os dados são en-viados automaticamente em intervalos pré determinados, ou por demanda, quando men-sagens de controle, comando ou alertas são enviadas da central para os dispositivos. Noprimeiro caso, a leitura pode ser calculada para não sobrecarregar a rede. Porém, nosegundo caso, dependendo da quantidade de dados requeridos, a rede pode ficar conges-tionada com a resposta enviada por todos os medidores inteligentes.

Para que o congestionamento da rede não atrapalhe o fluxo de dados de aplicaçõesprioritárias, faz-se necessária a implementação de mecanismos de QoS na rede. Devidoà grande quantidade de tráfego e à ampla gama de aplicações, com diferentes requisitosde latência e perda, o provimento de QoS em redes elétricas inteligentes se torna es-sencial [Jeon 2011, Vallejo et al. 2012, Deshpande et al. 2011, Li and Zhang 2010]. Emconsequência da variação nos requisitos de QoS das aplicações, a rede precisará imple-mentar um tratamento de mensagens baseado em QoS levando em conta os requisitos delatência e perda de pacote de cada mensagem [Hossain et al. 2012].

Alto desempenho, confiabilidade e uma rede de comunicação segura são partesintegrantes da evolução das redes inteligentes. A rede de comunicação tem que suportar,simultaneamente, a grande quantidade de requisitos de qualidade de serviço de inúmerasaplicações das redes elétricas inteligentes e aplicações legadas [Deshpande et al. 2011].Para tratar possíveis interrupções no sistema, uma infraestrutura altamente confiável, es-calável, segura, robusta, com uma boa relação custo-benefício e que suporte QoS é al-tamente necessária [Jeon 2011]. Para isso, a infraestrutura de comunicação deve utilizartecnologias capazes de prover todas essas características.



No caso da GD e da AMI existem diversas tecnologias de comunicação que po-dem ser usadas para implantar essa infraestrura, sendo elas cabeadas ou não. A GD éconectada em medidores concentradores (gateways), que são responsáveis por agregaros dados coletados dos medidores inteligentes. O concentrador se conecta ao sistemade gerenciamento de dados de medição - Meter Data Management System (MDMS). Aquantidade de medidores pode variar muito de acordo com o tipo de arquitetura usada. .A tecnologia cabeada que mais tem visibilidade nessa área é o Power Line Communica-tions (PLC). Porém, sabe-se que, em caso de falha na rede elétrica, onde os dispositivostêm que continuar se comunicando, o PLC traria problemas, pois iria falhar junto com arede elétrica. Uma infraestrutura de comunicação pode ser facilmente implantada usandotecnologias sem fio. Segundo [NIST 2011], onde os concentradores são também cha-mados de Data Aggregation Points (DAPs), as tecnologias sem fio são muito atrativaspara uso na AMI, devido à sua facilidade de implementação e custos reduzidos, além darapidez na implementação.

Outro fator importante é que o uso de GD permite que se reaja rapidamente àsmudanças dos preços da energia. Inclusive a GD pode servir como uma proteção contraas flutuações das tarifas e este é um dos principais drivers para a demanda de geraçãodistribuída, ou seja, utilizar a geração distribuída para o uso contínuo ou para o horáriode pico. Isso acontece porque a GD permite que os participantes do setor elétrico possamresponder, de forma flexível, às mudanças nas condições de mercado. Tecnologias degeração distribuída, em muitos casos, fornecem flexibilidade devido às suas pequenasdimensões e os tempos de entrega e construção curtos em comparação com a maioria dostipos de usinas centrais maiores. Com isso, são flexíveis em relação a operação, tamanho,capacidade de expansão e uso. Cada elemento na GD precisa ser tratado de acordo com asua prioridade e a rede e os sistemas precisam dar suporte à transferência de informaçõesgeradas pelos diferentes componentes de uma rede elétrica inteligente.

2.4. Desafios para a Rede de Comunicação na Geração DistribuídaCom a inclusão da geração distribuída no sistema de energia e com os conceitos e sis-temas que a GD torna possível, como as microgrids e as VPPs, uma gama nova deaplicações e serviços irão surgir. Essas aplicações ajudarão a concessionária a forne-cer energia de forma mais eficiente, além de permitir que os consumidores possam gerirde forma eficaz o seu consumo. No entanto, esses serviços e aplicações terão requisi-tos de comunicação que não podem ser atendidos com a infraestrutura de comunicaçãoatual [Bouhafs et al. 2012].

O programa de substituição de medidores no Brasil é o primeiro passo para a im-plementação de uma infraestrutura de geração distribuída no país. O uso de monitoraçãointeligente, que inclui uma monitoração diferenciada tanto no usuário quanto no núcleoda rede, associada ao uso de fontes renováveis, agrega valores significativos para a gera-ção e o consumo de energia. Entre esses valores, destacam-se: a redução de perdas nãotécnicas na rede elétrica, questão importante para o Brasil; a implementação de tarifasvariáveis, com foco na redução no horário de pico do sistema; a implementação de gestãopelo lado da demanda; e a possibilidade de novos serviços para os clientes. Contudo,esses benefícios dependem da solução de desafios na rede de comunicação. Controlar osistema e gerenciar os recursos da rede são parte dos principais desafios encontrados para



as redes elétricas de nova geração. Nos novos modelos, o controle e o gerenciamento de-pendem da coleta de informações distribuídas ao longo da rede e das mensagens enviadaspor cada uma das entidades que participam do sistema. A coleta de informações permiteum controle mais robusto, mas, por outro lado, também gera uma grande quantidade dedados, o que dificulta a coleta, o armazenamento e o processamento das informações. Ocontrole e o gerenciamento de uma rede diversificada como essa é de fato um dos maioresdesafios na área.

O desafio técnico e econômico para GD será integrar de forma ideal este aumentodo número de pequenas unidades de produção em um sistema elétrico que até agora temsido muito centralizado, integrado e planejado. As tecnologias de comunicação e redescriam uma conectividade universal entre uma grande variedade de dispositivos de rede,incluindo os recursos de produção de energia, nós da rede e as cargas locais. Isto pro-porciona novas e melhores técnicas para controlar à distância redes altamente distribuídasem larga escala. A conectividade entre as fontes de GD, a rede de comunicação, as cargaslocais e todos os elementos das redes elétricas inteligentes é um elemento chave para aboa gestão de qualquer rede de energia no futuro [Bayod-Rújula 2009].

Na ausência de suporte computacional para decisões automatizadas, os operadoresde rede estão mal equipados para examinar e utilizar milhões de dados e pontos de con-trole para gerenciar o dinamismo nos padrões de uso de energia [Simmhan et al. 2013].

O sucesso das redes elétricas inteligentes depende da capacidade do sistema detec-tar dados que mostrem o seu comportamento e sejam capazes de automatizar os controlesdisponíveis. Esse grande desafio requer técnicas de controle e gerenciamento avançadas.Milhões de medidores inteligentes gerarão informações de tempos em tempos, que preci-sam ser coletadas e correlacionadas com o perfil histórico do consumidor. A mineraçãode dados e reconhecimento de padrões são necessários para a detecção em tempo real desituações críticas [Simmhan et al. 2013, dos Santos 2014].

2.4.1. Infraestrutura de Comunicação dos Sistemas de Controle

A geração distribuída junto com a infraestrutura de medição avançada irão gerar bilhõesde pontos de dados de milhares de dispositivos do sistema de centenas de milhares declientes [Bouhafs et al. 2012]. Os dados coletados a partir de medidores inteligentes, deeletrodomésticos, de subestações, e outras fontes serão de uma quantidade enorme.

Esses dados, gerados por aplicações e dispositivos de controle, deverão ser trans-portados de forma eficiente para a concessionária e para centros de controle. Para isso, énecessário que a infraestrutura de comunicação seja robusta, com uma largura de bandasuficiente para lidar com uma grande quantidade de dados que precisarão ser constan-temente trocados. No entanto, as redes de comunicação utilizadas atualmente em redeselétricas foram projetadas para sistemas de controle tradicionais, que trabalham com umaquantidade limitada de dados, e, portanto, não podem satisfazer as exigências das aplica-ções e operações de controle para as redes elétricas inteligentes.

A infraestrutura de comunicação do sistema legado segue uma infraestrutura decomunicação centralizada como solução para supervisão e controle de sistemas de gera-ção, transmissão e distribuição de energia elétrica e utilizam o SCADA para monitorar



e supervisionar as variáveis e os dispositivos das subestações de energia. Esses siste-mas legados são compostos por dispositivos de controle intitulados Unidades TerminaisRemotas (UTR), do inglês Remote Terminal Unit (RTU) [Bouhafs et al. 2012]. Nessaarquitetura, a comunicação é feita em um modelo mestre-escravo podendo existir váriasUTRs escravas por mestre, normalmente localizadas em campo. Exemplos de protocolosusados pelas UTRs são o MODBUS [Mod 2012] e DNP3 [Dnp 2010, Dnp 2012].

A organização hierárquica e centralizada destes sistemas também se reflete naforma como que os protocolos de comunicação operam. Como as UTRs escravas sãoconectadas às UTRs mestres, ou dispositivos mestres, o procedimento principal de comu-nicação é o envio de dados para o mestre, que pode enviar comandos e solicitações para osescravos. Essa abordagem centralizada não satisfaz os requisitos do sistema de controlepara redes elétricas inteligentes [Bouhafs et al. 2012].

Com a inclusão da geração distribuída nesses sistemas, além de outros elemen-tos das redes elétricas inteligentes, os sistemas de controle deixarão de funcionar em ummodelo puramente centralizado e passivo e passarão a operar de forma mais distribuídae ativa. A implementação desses sistemas de controle exige que os protocolos usadossejam mais robustos e mais flexíveis, podendo funcionar em um modelo cliente servidorou publicador/assinante (publish/subscribe). Além disso, os dispositivos devem ser con-trolados em grupos e não somente individualmente [Bouhafs et al. 2012]. O controle dosistema vai abranger uma área muito maior do que a que abrange atualmente. A inclusãode geração de energia de forma distribuída, em pequena escala, faz com os sistemas decontrole tenham que se adaptar para incluir esse novo elemento e essa nova área geográ-fica que deverá ser controlada. Com isso, algumas funcionalidades serão necessárias narede, como:

• Roteamento de dados: com a inclusão de GD e a necessidade de coordenação dessenovos elementos a abrangência geográfica do controle da rede deverá ir além dadistribuição, chegando até a residências inteligentes. Muitas redes inter e intrassu-bestações e entre subestações e centro de controle atualmente operam apenas emcamada 2. Como o controle deverá chegar a cada elemento da GD, o roteamento dedados entre o gerador distribuído e o centro de controle se torna essencial.

• Broadcast e Multicast: a quantidade de dispositivos conectados ao sistema e tro-cando informações entre si e com o centro de controle aumenta radicalmente com ainclusão de medidores inteligentes e GD. O uso de multicast para evitar inundaçãoda rede e consequente degradação do desempenho também será fortemente neces-sário nesse cenário. O envio de determinada informação para apenas um grupo dedispositivos será função muito utilizada nesse sistema. Por exemplo, determinadainformação de controle poderá ser enviada apenas para os grupos de geração deenergia solar. O broadcast será utilizado apenas quando a difusão de uma informa-ção para toda a rede for necessária.

• Priorização de pacotes: naturalmente algumas aplicações serão mais prioritáriasque outras. As informações geradas pela GD, por exemplo, são mais importantesque informações enviadas para consumidores para simples visualização. Informa-ções para proteção do sistema são mais importantes que informações enviadas pela



GD devido a sua restrição temporal. Com isso, o uso de técnicas de priorização depacotes e QoS se tornam premissas básicas para o bom funcionamento da rede.

• Virtual Local Area Networks (VLANs): com o intuito de limitar o domínio broad-cast para também ajudar no desempenho do sistema, o uso de VLANs poderá serusado.

Essas e outras funcionalidades precisam estar presentes nessa nova geração derede de comunicação para a rede elétrica, além de toda e qualquer técnica que torne essainfraestrutura distribuída mais robusta e confiável.

Todas essas novas funcionalidades precisam ser inseridas na rede de comunica-ção atual de forma a viabilizar a implantação das smart grids e da GD. Em um primeiromomento é natural imaginar que o cenário ideal seria fazer um upgrade das redes inter eintrassubestações, das redes até o centro de controle, e toda a infraestrutura das concessi-onárias. Mas, certamente, esse tipo de medida teria um custo proibitivo, já que as redesteriam que ser basicamente reimplantadas. Os enlaces de dados usados para os centros decontrole têm uma largura de banda muito baixa atualmente, longe da desejada para umarede do futuro. Com isso, torna-se necessário o estudo de uma solução a respeito dessanova infraestrutura, planejando desde como a migração deverá ser feita, até qual o tipo detecnologia deverá ser usada, o que é um desafio enorme.

2.4.2. Gerenciamento

Em termos de sustentabilidade, no futuro, as residências não irão atuar apenas como con-sumidores de energia mas sim como fontes geradoras de energia. Muitas casas estãosendo instaladas com geradores de energia renováveis como painéis solares, turbinas eó-licas e geradores de energia a partir de biocombustíveis. Essas várias casas inteligentesestarão distribuídas e conectadas fazendo parte de uma microgrid para compartilhar a suacapacidade de geração de energia, podendo funcionar como unidades independentes darede externa. Políticas de geração e consumo local podem reduzir significativamente adependência energética das redes externas [Pan et al. 2014]. Interconectar todas essas ca-sas inteligentes não é tarefa fácil. É necessário criar uma rede de casas inteligentes coma utilização de várias tecnologias a fim de construir uma microgrid. Informações comoconsumo de energia em tempo real e a capacidade de geração daquela unidade precisamser trocadas constantemente. As casas inteligentes precisam trabalhar de forma indepen-dente e ao mesmo tempo se conectar com a rede de energia, de forma a tentar evitar acriação de pontos únicos de falha no sistema.

Além disso, outro ponto importante é o monitoramento e a otimização das micro-grids. A microgrid tem que ser capaz de dinamicamente monitorar e alocar corretamentea capacidade de geração e de consumo de energia em vários pontos da própria microgrid.Segundo Pan et al. [Pan et al. 2014], no topo dos problemas de protocolos e topologiasde rede está o problema de maximização da eficiência enérgica, ou seja, a necessidade deem tempo real se conhecer o consumo de energia e as informações de geração através dainfraestrutura de redes e protocolos de determinada microgrid.

Ressalta-se que uma vez que todas as informações são enviadas para um servidorcentral da microgrid, com informações também da localização distribuída de cada casa



inteligente e de seu território, esse problema pode ser modelado e simplificado como umproblema de otimização computacional. A ideia consiste de se ter múltiplas fontes deenergia distribuídas, em casas ou prédios, e um gerenciamento capaz de alocar a energiaextra, gerada e não utilizada na fonte, para lugares próximos que precisem dessa energia.Fazendo isso, a geração de energia de forma distribuída por “construções verdes” podemser totalmente utilizadas por diversos consumidores. Com um sistema bem modelado einteligente, o uso de energia externa, de fora da microgrid, será reduzido, o que significaredução de custo não só relacionado ao preço da energia da rede externa como tambémàs perdas de energia que acontecem na transmissão por longas distâncias. Além disso,com essa otimização, com o uso da resposta à demanda e de tarifas flexíveis, a demandade energia no horário de pico pode ser reduzida, e uma quantidade significativa de perdade transmissão de energia pode ser economizada, além da economia no investimento emampliações de usinas, por exemplo [Pan et al. 2014].

A estabilização de energia em uma microgrid é um ponto chave para a otimizaçãodo sistema. As fontes de energia podem ser intermitentes, contudo, essa intermitênciapode ser previsível. Por exemplo, a energia solar certamente não gera energia durante anoite. O consumo de energia também segue um padrão, como, por exemplo, o consumoem escritórios que têm um uso elevado durante o dia e a noite pouquíssimo consumo.Pode-se tirar o máximo de proveito desses padrões ou desse comportamento previsívelpara agendar a geração e consumo de energia na microgrid adequadamente. Para isso,abordagens simples podem ser usadas ou até mesmo sistemas de aprendizado inteligente.

Com relação a implementação do gerenciamento e controle da GD, a infraestru-tura é um ponto crucial que é totalmente dependente das tecnologias de telecomunicaçõese da infraestrutura de Tecnologia da Informação (TI) utilizada para coletar e transmitiros dados em tempo real. A infraestrutura de comunicação que poderá ser usada é he-terogênea, com uma mistura de diversas redes cabeadas e sem fio. A gerência de umarede tão diversificada é bastante complexa e o sucesso da implantação das redes elétricasinteligentes dependerá de um sistema de gerência flexível e eficiente [Lopes et al. 2012].

No passado, as distribuidoras de energia implementavam tecnologias de gerenci-amento independentemente das tecnologias de informação. Entretanto, diversos modelosde redes de comunicação e sistemas de TI se fundem à rede elétrica. Por esse motivo,um grande desafio é gerenciar de forma eficiente essa grande rede heterogênea, com di-versas tecnologias, com vários protocolos de diferentes fornecedores, de forma coorde-nada [Enose 2011].

Em especial, um sistema de gerência unificado para a GD e para as redes elétri-cas inteligentes agrega valor aos negócios fornecendo uma visão fim-a-fim dos diversosdispositivos e aplicações. Além disso [Lopes et al. 2012]:

• otimiza e melhora os processos, agiliza a tomada de decisão e reduz os custos;

• melhora a eficiência e a utilização da rede;

• melhora a eficiência com a integração da operação e da prestação de serviços;

• oferece uma única visão dos dispositivos da distribuidora/geradora de energia;



• melhora a utilização dos dispositivos e linhas de transmissão;

• reduz o custo através da integração, da normalização e da consolidação dos dados;

• aumenta o valor do negócio, melhorando a qualidade do serviço ao cliente;

• fornece insights sobre medidas de desempenho;

• prevê correções rápidas na rede de distribuição/geração de energia, evitando inter-rupções críticas.

2.4.3. Convergência e Interligação de Redes

O uso de infraestruturas de rede com padrões e protocolos abertos para permitir que ascasas inteligentes operem como sistemas integrados e de forma harmoniosa torna-se ne-cessário [Pan et al. 2014]. Segundo Pan et al., a convergência tem vários benefícios po-tenciais:

1. redução dos custos iniciais de construção e os custos de manutenção;

2. redução da complexidade das redes no interior das casas inteligentes;

3. facilitação da automação e interação entre os diferentes subsistemas.

Existe uma tendência de aumento dos pro-consumidores (consumidores/produtores),onde os consumidores de energia são também geradores usando a energia que foi geradaalém do seu consumo como fonte para a vizinhança ou para a rede externa. Com isso, anecessidade de interconexão entre as casas inteligentes e a rede externa aumenta, além daintegração com a resposta à demanda, e a tarifação diferenciada.

Cabe observar que toda essa interação depende de uma rede de comunicação efi-ciente que funcione em tempo real. Também será necessário um trabalho com relação aotratamento e privacidade dos dados. Por exemplo, para prever se uma residência deve setornar uma fonte geradora em determinado momento, pode ser interessante o acesso aosdados de consumo do usuário, o que revela dados sobre hábitos e tipos de eletrodomés-ticos presentes em casa. Embora existam muitas ideias, ainda não existem soluções demercado e o campo está aberto para novas propostas por meio de pesquisa e desenvolvi-mento.

2.4.4. Segurança

O aumento do número de usuários com diferentes níveis de confiabilidade cooperandoentre si e atuando no sistema torna o provimento de segurança na comunicação tam-bém um ponto chave [Neuman and Tan 2011, Zhu et al. 2011]. Entre os mecanismos ne-cessários para o provimento de segurança, destacam-se a autenticação das solicitaçõesdos usuários, a autenticação de mensagens enviadas por aparelhos inteligentes, comomensagens de oferta de energia de fontes alternativas [Yan et al. 2011], e as métricaspara avaliar a importância das informações trocadas entre usuários e fornecedores narede [Chim et al. 2011]. A troca de mensagens tem impacto em todo o controle e ge-rência da rede, de forma que a autenticidade e a confiabilidade dos dados trocados devem



ser sempre asseguradas pela infraestrutura da rede elétrica inteligente. A segurança nacomunicação também diz respeito à confidencialidade dos dados da rede e dos usuários,tais como informações de endereço e de cartão de crédito.

Especialmente no cenário de GD, considerando geração residencial, cada casaprecisa saber o quanto de energia tem para ceder e quanto ela precisa receber. Isso, por sisó, já é um grande desafio. Como foi visto, no modelo tradicional de distribuição de ener-gia elétrica, a energia flui unidirecionalmente das usinas geradoras para os usuários. Nomodelo de microgrid, todas as casas podem fornecer e consumir energia da microgrid, detal forma que os fluxos energéticos podem fluir bidirecionalmente e são dinamicamentereconfigurados. É importante que o sistema da microgrid funcione de forma distribuída,mas evitando que mensagens falsas sejam inseridas na rede com o fim de prejudicar adistribuição de energia ou a cobrança posterior ou, ainda, que informações sejam rou-badas para ferir a privacidade dos usuários. Em particular, os roteadores das microgridspodem utilizar enlaces sem fio, os quais são mais susceptíveis a ataques do que redescabeadas [Lopes et al. 2012]. Portanto, a segurança das microgrids e de seus roteadoresdeve contar com mecanismos de controle de acesso, gerência de chaves e certificados,detecção de intrusão e de mau comportamento, entre diversos outros [Zhu et al. 2011].

Para que os dados da GD e da AMI sejam trocados, os medidores inteligentesprecisam estar conectados à rede, enviando e recebendo mensagens. Uma vez que se-gurança é uma preocupação, é natural supor que os medidores serão equipados com astécnicas de segurança padrão, tais como utilização de certificados digitais e criptogra-fia [Lopes et al. 2012]. Contudo, já é sabido que o uso dessas técnicas não é suficientepara impedir que o sistema seja atacado [Cleveland 2008]. Vide a Internet, a qual está mu-nida dessas e outras técnicas, mas ainda sofre com frequentes problemas de segurança, emespecial os ataques de negação de serviço [Wang et al. 2011]. O volume de ataques estáfortemente correlacionado com a quantidade de hackers espalhados pelo mundo. Muitoembora muitos hackers ajam maliciosamente para obter vantagens, muitos são adoles-centes querendo quebrar novas barreiras. No contexto da GD, a preocupação é relativa àqual o impacto que esses hackers teriam sobre a rede elétrica, uma vez que tiverem dentrode suas casas medidores inteligentes capazes de interferir ativamente no funcionamentodo sistema. Os incentivos para criar ataques na rede vão desde conseguir mudar con-tas de luz até conseguir causar apagões em cidades inteiras [Rahman et al. 2012]. Dessaforma, a segurança na AMI interfere não apenas no gerenciamento doméstico da ener-gia, mas também na segurança dos controles de automação das subestações em grids emicrogrids [Lopes et al. 2012].

Outro fator chave para segurança é que as demandas para automação de sistemasde energia controlados por computador têm crescido enormemente devido a sua impor-tância [Cheung et al. 2007]. Os dispositivos eletrônicos inteligentes (IEDs - IntelligentElectronic Devices), que participam da proteção, do controle e da automação do sistemaelétrico, têm uma comunicação autônoma na rede e podem evitar que uma falha no sis-tema elétrico de potência seja propagada causando, por exemplo, um apagão. No entanto,caso tenham um mau funcionamento, devido a um ataque por exemplo, também podemcausar uma falha. O sistema tem que ser seguro o suficiente para que o acesso desses dis-positivos por terceiros mal intencionados não seja permitido. Por exemplo um pequenoatraso na transmissão de dados, para operar o equipamento de proteção, pode resultar em



falha na subestação [Cheung et al. 2007]. É importante ressaltar que a GD passará a seinterconectar com esses sistemas de automação, necessitando que o sistema de comuni-cação seja completamente seguro.

Muito tem se pesquisado na área de segurança pra GD, microgrids e AMI, mas,devido a sua importância e ampla gama de possibilidades de ataque, é uma das áreas commais desafios e oportunidade de pesquisa.

2.4.5. Confiabilidade e Resiliência

Confiabilidade envolve questões de durabilidade e estabilidade. A saúde do sistema émedida por quão estável esse sistema é, e a estabilidade determina também o nível deconfiabilidade que este possui. Por confiabilidade, entende-se que as falhas, que por-ventura venham a ocorrer no sistema, tenham baixa probabilidade. E em caso de falhaem algum componente é necessário que o impacto para o sistema seja minimizado e ocomponente que falhou seja restaurado em tempo mínimo.

A tendência de utilização da geração distribuída, que aproveita as vantagens dasfontes de energia alternativas, como painéis solares ou geradores eólicos, para melhorar aestabilidade e qualidade do sistema [Fang et al. 2011], consequentemente torna o sistemamais confiável. Um estudo feito pela International Energy Agency apontou que um sis-tema elétrico baseado em um número grande de pequenas gerações distribuídas confiáveispode operar com a mesma confiabilidade e limite inferior de capacidade que um sistemade grandes geradores confiáveis [(IEA) 2002].

Nesse caso, a confiabilidade é provida pela capacidade de controlar o nível de ge-ração. Para isso, o controle e o gerenciamento da rede precisam ser muito robustos. Comesse controle, as gerações alternativas podem ser iniciadas em caso de pico no sistema,ou ainda desligadas ou diminuídas em caso de falta de demanda para energia gerada.As microgrids e sua opção de ilhamento também podem fornecer maior confiabilidadeno sistema pela rápida capacidade de reação ante uma falha. Em caso de falha na redeexterna, a microgrid pode se desconectar da rede externa. De maneira similar, em casode indisponibilidade na microgrid, a mesma pode se reconectar a rede externa a fim deusar a energia da macrogrid. Ainda dentro da microgrid, em caso de indisponibilidade deuma unidade geradora, o fornecimento elétrico se recompõe através de fontes vizinhas,agregando flexibilidade e confiabilidade ao sistema.

Com a monitoração e análise do sistema de distribuição em tempo real, as práticasoperacionais do sistema melhoram e, consequentemente, sua confiabilidade. A monito-ração permite a identificação de problemas, como falhas em ativos da rede, fazendo comque a concessionária possa tomar as devidas providências antes que o problema ocorra ouque uma área maior seja afetada [Lopes et al. 2012].

O desafio de confiabilidade e resiliência para a rede de comunicação na GD resideem prover todo o controle e monitoramento necessários nas microgrids de forma eficiente.Nenhum dos métodos e sistemas discutidos até aqui para manter o sistema confiável serãopossíveis sem uma infraestruta robusta de comunicação.

Outra medida importante para manter a rede confiável é a modernização das tec-nologias usadas e componentes. Subestações e outras áreas das redes elétricas inteli-



gentes devem evitar o uso de dispositivos antigos. Esse equipamentos ficam obsoletose, com isso, mesmo que seja detectada uma falha, não há como substituí-los em tempohábil. Além disso, equipamentos antigos, com muito tempo de uso, têm uma probabili-dade maior de falha. O projeto gridWorks [Brown 2008] visa melhorar a confiabilidadedo sistema elétrico através da modernização dos componentes-chave da rede: cabos econdutores, subestações, sistemas de proteção e dispositivos eletrônicos. O plano incluiatividades de longo prazo para desenvolver novas tecnologias, ferramentas e técnicas desuporte.

Outro desafio para prover confiabilidade nesse cenário está relacionado à redun-dância da rede. A decisão de qual a melhor topologia de redundância para prover confiabi-lidade em subestações já é um assunto muito discutido na área. Porém, essa redundânciana comunicação será necessária não só em subestações como em todo o sistema de GD,com VPPs e microgrids a fim de garantir que a comunicação entre os nós não irá falhar.

A confiabilidade está extremamente ligada a todos os outros desafios tratados atéaqui. Garantir uma rede segura, com infraestrutura de comunicação robusta e controle egerenciamento eficientes são essenciais para tornar o cenário da GD mais confiável.

2.5. Soluções e Perspectivas para Redes de Comunicação na Geração Distri-buída

Uma rede de comunicação precisa ser robusta e confiável para que todas as informaçõestrafegadas na rede estejam disponíveis em tempo real. Soluções desenvolvidas para lidarcom a rede de comunicação serão detalhadas nesta seção. Além disso, novas perspectivasserão apresentadas e soluções que lidam com desafios apresentados na seção anteriortambém serão discutidas.

Entre os pontos a serem abordados, estão novas formas de modelar a rede que des-crevam a interligação entre suas entidades [Pérez et al. 2013]. Além disso, novos siste-mas para simulação, considerando a necessidade de escalabilidade da rede também serãoanalisados [Müller et al. 2012]. Propostas de tecnologias de comunicação e uma brevecomparação entre elas também é parte do foco desta seção.

Esta seção também descreverá as principais tecnologias que estão em discussãopara ajudar na implementação bem sucedida da GD como o uso de Big Data, Cloud Com-puting, e Redes Definidas por Software (Software-defined networking (SDN)), dentreoutros temas de destaque para a pesquisa de redes na geração distribuída de energia.

2.5.1. Big Data

Big Data é um campo que lida com dados que são ricos em termos de volume, velo-cidade e variedade. Quando os dados a serem analisados são de um volume elevado,da ordem de Petabytes, Exabytes ou Brontobytes, a velocidade de transmissão é ele-vada e a variedade de dados é enorme. Com isso, o uso de Big Data torna-se obrigató-rio [Mayilvaganan and Sabitha 2013].

A análise de grandes quantidades de dados é necessária para a geração de resul-tados importantes que dificilmente seriam alcançados com um banco de dados com umvolume pequeno. Com as redes elétricas inteligentes, não poderia ser diferente. A geração



distribuída e o controle de todo o sistema de balanceamento de carga e geração de energiagera uma infinidade de dados a cada momento. Com a quantidade de dados gerados o usointeligente de Big Data poderá trazer vantagens enormes.

Os dados podem ser coletados de medidores inteligentes, de eletrodomésticos, desubestações e de qualquer outra fonte que possa ajudar as concessionárias a entender me-lhor o funcionamento da rede, o uso de energia, as condições dos equipamentos, níveis detensão e outros aspectos do sistema de energia [Bouhafs et al. 2012]. A Figura 2.14 ilustraa variedade de fontes de dados disponíveis que oferecem uma oportunidade promissorapara inovação e transformação nessa área.

Figura 2.14. Uso de big data em um modelo de geração distribuída. Adaptadode [Servatius 2015]

O tratamento dessa grande quantidade de informações por processos de Data Mi-ning permite a procura de padrões, regras de associação, sequências temporais, relaciona-mentos sistemáticos e qualquer outro tipo de correlação que ajude a melhorar a qualidadedo serviço prestado na rede elétrica [Lopes et al. 2012]. Esses processos aliados a grandevariedade de informações coletadas em redes elétricas inteligentes permitem a mode-lagem dos hábitos dos clientes que fazem uso do sistema elétrico, como por exemplo,saber a hora que tomam banho, a hora que dormem, como fazem uso de eletrodomés-ticos [Kim et al. 2011]. Pode-se armazenar o histórico de temperatura de determinadoslugares, as demandas do usuário, dados de produção de energia, etc. Com esses dados ecom modelos analíticos e computacionais, pode-se prever o fornecimento e a demanda deenergia. Isso permite que medidas preventivas sejam tomadas para a redução da demandapor notificação dos consumidores [Simmhan et al. 2013].

Vários pesquisadores já estão estudando a aplicação de Big Data em redes elétri-cas inteligentes [Mayilvaganan and Sabitha 2013, Simmhan et al. 2013].



2.5.2. Cloud Computing

Muitos autores [Mayilvaganan and Sabitha 2013, Simmhan et al. 2013, Thilaga et al. 2012,Bera et al. 2014, Genge et al. 2014, Bitzer and Gebretsadik 2013, Maheshwari et al. 2013]defendem o uso da computação em nuvem (Cloud Computing) como auxílio para integra-ção dos dados gerados nas redes elétricas inteligentes. A computação em nuvem é umfator importante que pode potencialmente levar a uma mudança de paradigma na redeelétrica [Pan et al. 2014]. A rede elétrica tradicional gera a energia em um ponto e en-trega em outro sem uma inteligência avançada incorporada. Esse paradigma mudou.

O monitoramento de energia em casas inteligentes e otimização em microgridspode ser feito com o auxílio de computação em nuvem. Os dados de consumo podem serarmazenados em nuvem para que sejam compartilhados mais facilmente sem onerar osproprietários e operadores da rede elétrica com manutenções caras de servidores e dispo-sitivos de rede. Além disso, existe uma ótima interação entre a tecnologia de dispositivosmóveis como smartphones e a tecnologia em nuvem para criação de aplicativos de otimi-zação de energia personalizáveis para uso consciente pelo consumidor, tais como controlee gestão de iluminação e eletrodomésticos em casas inteligentes.

Uma questão fundamental nesse cenário que envolve a GD, as microgrids e asVPPs é a interação entre casas inteligentes com o intuito de otimizar a geração e utili-zação de energia localmente, fazendo uma alocação adequada da capacidade de energia.A computação em nuvem oferece escalabilidade e o seu uso pode ser generalizado paraotimização de microgrids. Com o uso de Cloud Computing, as informações sobre a ge-ração de energia e sobre o consumo de diversas casas inteligentes podem ser comparti-lhadas e trocadas para a criação de uma estratégia de alocação da capacidade de geraçãoda microgrids de forma otimizada. Com isso, pode-se alcançar a máxima eficiência nasmicrogrids.

A rede elétrica tradicional pode se beneficiar da computação em nuvem para ocompartilhamento de informações e armazenamento de dados, sem necessidade de su-porte e manutenção de um datacenter. Com uma otimização local, com uma alocaçãomais eficiente de geração e uso de energia, a utilização de energia global pode ser redu-zida. Aplicações especializadas podem ser construídas em cima de plataformas de com-putação em nuvem, com menores custos, o que aceleraria o desenvolvimento e permitiriauma implementação mais rápida de novos serviços na rede elétrica inteligente.

Um exemplo do uso de Cloud Computing na área de energia é o IBM´s SmartEnergy Cloud [IBM 2015], lançado em março de 2011 pela IBM na conferência Futureof Utilities em Londres. A Smart Energy Cloud é uma solução inteligente com o potencialde fornecer uma visão completa do uso de energia em todo o país além de ser o recurso decomunicação central para apoio de programas de implementação de medidores inteligen-tes do Reino Unido. Ela tem a capacidade de recolher dados em tempo real, muitas vezespor dia, a partir de qualquer medidor inteligente em qualquer lugar do país e armazená-loem uma nuvem segura hospedada no Reino Unido. Os dados podem, então, ser enviadospara as concessionárias que poderão calcular o uso e gerar a conta do usuário. O ReinoUnido pode contar com essa solução para apoiar os programas de implementação de me-didores inteligentes ajudando o sistema a se tornar mais inteligente, mais conectado e, porsua vez, mais sustentável [IBM 2015].



Além da IBM, o laboratório de Pesquisa Sensorweb, do Departamento de Ciên-cias da Computação da GSU (Georgia State University) também investiga o uso de Cloudnesse cenário. A GSU tem um projeto intitulado SmartGridLab [Sensorweb 2015] quepesquisa áreas da computação, como Cloud Computing, para as redes elétricas inteligen-tes. O objetivo geral do projeto é apoiar a alta penetração da GD, das fontes de ener-gia renováveis, das microgrids, dos carros elétricos e dos eletrodomésticos inteligentes.A pesquisa proposta tem três componentes interligados que, em conjunto, abordam asquestões da arquitetura de computação, hierarquia de informação, modelo experimentale validação. Para apoiar a ferramenta desenvolvida pelo projeto, os pesquisadores pro-põem uma arquitetura de computação em nuvem para que as operações sejam escaláveis,consistentes e seguras nas redes elétricas inteligentes. A arquitetura é ilustrada na Fi-gura 2.15. Os pesquisadores usam os dados salvos em nuvem, por exemplo, como basede dados para técnicas de detecção de anomalias nas redes elétricas inteligentes.

Figura 2.15. Hierarquia do SmartGridLab com o uso de Cloud.

Outro exemplo do uso do conceito de Cloud é a chamada Green Cup [gre 2015],uma competição pela redução do uso de energia em casas e repúblicas da WashingtonUniversity, no campus de Saint Louis, que usa geração de energia sustentável e envolve oconceito de Cloud nas casas inteligentes e nas aplicações relacionadas a eficiência ener-gética.



2.5.3. SDN

Redes definidas por software (SDN) também têm sido discutidas no contexto de re-des elétricas inteligentes [Lopes et al. 2015], principalmente para uso em subestações.SDN é uma disciplina emergente que veio para resolver os problemas do plano de con-trole de forma disciplinada e padronizada, usando software [McCauley 2013]. Para isso,modifica-se a arquitetura atual, separando fisicamente os planos de controle e de en-caminhamento. Desse modo, mantém-se o alto desempenho no encaminhamento depacotes em hardware aliado à flexibilidade de se inserir, remover e especializar apli-cações em software por meio de um protocolo aberto para programação da lógica doequipamento [Rothenberg et al. 2011]. Um dos principais exemplos de SDN, o Open-Flow [McKeown et al. 2008], define um protocolo padrão para determinar as ações deencaminhamento de pacotes em dispositivos de rede. Regras e ações são instaladas nosdispositivos de hardware da rede por um elemento externo, denominado controlador, quepode ser implementado em um servidor comum. O OpenFlow tem como objetivo serflexível para atender os seguintes requisitos [McKeown et al. 2008]:

• possibilidade de uso em implementação de baixo custo e de alto desempenho;

• capacidade de suportar uma ampla gama de pesquisas científicas;

• garantia de isolamento entre o tráfego experimental e o tráfego de produção;

• consistência com a necessidade dos fabricantes de não exporem o projeto de suasplataformas.

Figura 2.16. SMARTFlow - Proposta para uso de SDN em redes elétricas inteli-gentes com enfoque em subestações [Lopes et al. 2015].

Em [Sydney et al. 2013] propõe-se um modelo com o arcabouço OpenFlow ofe-recendo recursos de MPLS. Segundo os autores, o OpenFlow teve bons resultados e podeser considerado uma alternativa para as aplicações em redes elétricas inteligentes. Além



disso, no trabalho desenvolvido em [Lopes et al. 2014], chamado SMARTFlow, o sistemaproposto para gerenciamento e controle de fluxos de redes elétricas inteligentes com en-foque em subestação foi testado, obtendo ótimos resultados e atendendo aos requisitostemporais rígidos do sistema elétrico de proteção e controle. O trabalho diminuiu a cargatotal da rede gerada por um switch de camada 2 típico em até 44% no cenário apresen-tado. O atraso na rede controlada pela proposta SMARTFlow não ultrapassou 1,5ms. Aarquitetura do SMARTFlow para subestações é ilustrada na Figura 2.16.

(a) Proposta do SDN4SmartGrids proposta em [Dorsch et al. 2014].

(b) Arquitetura SDN para redes elétricas inteligentes proposta em[Zhang et al. 2013].

Figura 2.17. Propostas para uso de SDN em rede elétricas Inteligentes

Segundo Dorsch et al. [Dorsch et al. 2014], as vantagens do uso de SDN incluemo fornecimento de uma rede de comunicação mais confiável para as redes elétricas inte-ligentes, que é capaz de lidar com cenários complexos de falha com melhor desempenhoque as redes com mecanismos de qualidade de serviço e roteamento tradicional. Em par-



ticular, a rede SDN permite a integração de diversas funções de gerenciamento de redee, portanto, oferece para o sistema elétrico de potência novas opções para lidar com fa-lhas, mesmo no caso de interrupções globais [Dorsch et al. 2014]. A solução propostapor Dorsch et al., também com enfoque em subestações, é intitulada SDN4SmartGrids eé ilustrada na Figura 2.17(a).

Zhang et al. [Zhang et al. 2013] pontuam diversas vantagens do uso de redes SDNpara redes elétricas inteligentes. Apesar de não apresentarem testes, os autores mostramuma arquitetura simplificada, ilustrada na Figura 2.17(b), para agregação de DER e paragerenciamento de casas inteligentes. Dentre os trabalhos descritos, apenas o SMART-Flow [Lopes et al. 2015] apresentou os algoritmos usados no sistema. Os autores doSMARTFlow trabalham ainda em um sistema completo para gerenciamento da GD, mi-crogrids e VPP.

Outra técnica muito interessante para ser usada nas redes elétricas inteligentes éa segmentação do tráfego em slices. Cada slice suportaria um conjunto específico defunções, com isso, os slices poderiam ser definidos por aplicações, ou ainda por um sub-conjuntos dessas aplicações de acordo com suas necessidades. Requisitos específicos deQoS poderiam ser implantados através de uma única plataforma para serem administra-dos individualmente em cada slice. A tecnologia SDN pode ser usada também para proverbalanceamento de carga entre as diversas aplicações nas redes elétricas inteligentes.

Ressalta-se que a empresa SEL (Schweitzer Engineering Laboratories) 5 já estádisponibilizando switches SDN para subestações. Esse é o primeiro switch desenvolvidoespecificamente para sistemas elétricos a utilizar a tecnologia SDN. Isso indica um passoimportante para implementação dessas propostas, visto que as subestações são partes es-senciais das redes elétricas inteligentes.

2.5.4. Projetos no Mundo e no Brasil

A maioria dos projetos em redes elétricas inteligentes engloba não só a geração de energiade forma distribuída, mas o que pode se alcançar com esse tipo de geração. Além disso,para que os benefícios conseguidos com a implementação da GD sejam alcançados, ainfraestrutura de redes tem que estar completa. Isso leva à implementação, por exemplo,de medidores inteligentes, da AMI, de redes de gerenciamento, das VPPs e qualquer outraárea das redes elétricas inteligentes que esteja interligada à geração distribuída. Comintuito de estudar a evolução do sistema elétrico, muito projetos têm sido desenvolvidospelo mundo. Esta seção cita alguns dos principais projetos e seus pontos fortes.

2.5.4.1. Projetos no Mundo

Diversas iniciativas para estudo e implementação de redes elétricas inteligentes e suasdiversas áreas têm sido trabalhadas em todo o mundo. A ideia envolve o estudo de no-vas tecnologias com a realização de simulações que possam compor redes inteligentes decontrole de energia em ambientes diversos. Parcerias entre universidades, institutos depesquisa e concessionárias de energia estão sendo feitas para testar possíveis implemen-

5www.selinc.com.br



tações em seus sistemas.

Na Europa, o projeto GRID4EU [ENEL 2014], uma iniciativa bem conhecida naárea, visa realizar seis testes pilotos (Itália, França, Alemanha, Suécia, Espanha e Repú-blica Checa) envolvendo 27 parceiros e 12 países da União Europeia, com a utilizaçãode uma rede banda larga de suporte à comunicação entre geradores renováveis para con-trole de fluxos de energia, níveis de tensão e testes de armazenamento de energia. Coma intenção de remover a maioria dos obstáculos técnicos que impediam o gerenciamentodas fontes de energia distribuídas e consequentemente a implementação da GD, o projetoEU-DEEP, executado entre 2004 e 2009, integrou oito empresas de energia do sistemade distribuição de vários países da Europa [Fang et al. 2011]. No distrito de Hoogkerk,na Holanda, 25 casas estão interligadas e equipadas com geração distribuída, com micros-sistemas de potência e calor, bombas de calor híbridas, medidores inteligentes, estaçõesde recarga de veículos elétricos e diversas aplicações para casas inteligentes, em um pro-jeto liderado pela firma DNV KEMA Energy and Sustainability chamado PowerMatchingCity [DNV KEMA Energy and Sustainability 2011]. Na ilha dinamarquesa Bornholm, oprojeto ECOGRID EU visa implementar um sistema de energia confiável com a parti-cipação de 2000 consumidores residenciais que receberão, para teste, dispositivos comgateways e controladores inteligentes. Ainda na Europa, o projeto Fenix desenvolveuum sistema integrado que envolvia fontes de energia distribuída, gerenciamento descen-tralizado e Virtual Power Plant durante os anos 2005 e 2009. O projeto foi feito pelaorganização Iberdrola Distribución com oito países [Fang et al. 2011].

Nos Estados Unidos, desde 2005, a Power Engineers - LLC tem se envolvido emprojetos de geração distribuída, eólica e solar, em Massachussets, New England e redon-dezas [LLC 2015]. O programa EPRI IntelliGrid foi fundado em 2001 pelo ElectricPower Research Institute (EPRI), e tem como principal objetivo criar uma nova infra-estrutura do sistema elétrico que integre os avanços em comunicações, computação, esistemas eletrônicos para melhorar a confiabilidade, a capacidade e o serviço aos cli-entes. É composto principalmente por cinco projetos, e um deles trata exclusivamentede redes de comunicação para fontes de energia distribuídas [EPRI 2015]. Além disso,o EPRI apoia o projeto EPRI Advanced Distribution Automation (ADA) para a criaçãodo sistema de distribuição do futuro incluindo dentre outras questões a integração dageração distribuída e o armazenamento de energia [Brown 2008]. Para fornecer comu-nicação bidirecional, geração distribuída com integração de fontes renováveis, armaze-namento de energia, resposta à demanda, aplicações inteligentes, recuperação de falhase integração de veículos elétricos, um dos maiores projetos de redes elétrica inteligen-tes, chamado PNW-SGDP (Pacific Northwest Smart Grid Demonstration Project) estáem desenvolvimento nos estados de Oregon, Idaho, Montana, Washington e Wyoming.Esse projeto envolve 11 empresas do mercado elétrico, três universidades e cinco sóciostecnológicos [Bonneville Power Administration 2010]. O projeto PNW-SGDP é supor-tado pelo Departamento de Energia dos Estados Unidos que apoia ainda outro programa,fundado em 2003, chamado GridWise que tem como missão a modernização da infraes-trutura e operação da rede de distribuição com um fluxo bidirecional de energia e informa-ção [Brown 2008, Hashmi et al. 2011]. Ainda nos Estados Unidos, pelo projeto PerfectPower System for Mesa del Sol, foram instaladas microgrids com GD (geração compainéis solares, células de combustível, gás natural) e armazenamento de energia. Além



disso, as microgrids são integradas em um sistema de gerenciamento automatizado queregula o fornecimento e a distribuição de energia [Galvin Electricity Initiative 2007].

Desde o início dos anos de 1990, o Japão tem feito a integração da energia geradapor telhados fotovoltaicos e é, atualmente, um dos maiores produtores de energia solarjunto com Alemanha e Europa. Já na Coréia do Sul, a Ilha Jeju foi seleciona em 2009como local para implementação de um testbed integral de redes elétricas inteligentes,programadas em três etapas até o ano 2030, e com um setor com enfoque em GD chamadoSmart Renewable [Korea Smart Grid Institute 2014].

2.5.4.2. Projetos no Brasil

No Brasil, as iniciativas nessa área vêm crescendo bastante. Como característica geral, osprojetos brasileiros iniciam-se com a implementação dos medidores inteligentes, já que éum ponto crucial inclusive para o funcionamento da GD. Em seguida, o enfoque passapara GD e o desenvolvimento de sistemas de armazenamento de energia mais eficientes.

Um exemplo é o projeto “Redes Inteligentes Brasil” [RIB 2015] que, dentreoutros assuntos, trata dos requisitos de telecomunicações e tecnologia da informação ne-cessários para suportar as necessidades geradas pelos sistemas de medição, automaçãoe integração de geração distribuída, armazenamento de energia e veículos elétricos plu-gáveis. Esse projeto tem diversos projetos pilotos espalhados pelo Brasil, dentre eles o“Cidade Inteligente Búzios” e o “Smart Grid Light” no Rio de Janeiro, o “Cidade doFuturo” em Minas Gerais, o “InovCity” em São Paulo, o “Paraná Smart Grid” e o “Ar-quipélago de Fernando de Noronha”. Esses projetos, muitos ainda em desenvolvimento,também estudam tecnologias e soluções para redes e telecomunicações. De forma geral,as concessionárias brasileiras têm investido bastante em projetos dessa linha.

O Smart Grid Light, além do amplo investimento em medidores inteligentes, temuma área que trata fortemente do sistema de geração distribuída com o desenvolvimentode um modelo de GD baseada em painéis fotovoltaicos e armazenamento que possibiliteações de DSM. O programa conta ainda com uma interface web de supervisão e controle,um conjunto de 136 painéis fotovoltaicos monocristalinos, uma área total de 220 m2 empainéis, aproximadamente 30 kW de potência de pico e 64 kWh de armazenamento embanco de baterias, além de possuir conexão com a rede de distribuição atualmente emcurso [Light S.A. 2014].

A Cemig, desde o ano 2010, está executando o projeto Cidades do Futuro e, em2014, entregou, na cidade de Sete Lagoas, quatro microusinas fotovoltaicas on-grid parageração de energia elétrica que fazem parte do projeto e serão utilizadas para estudo dainteração dos sistemas de GD na rede elétrica. A estrutura conta com sistemas de mo-nitoramento que permitem acompanhar em tempo real o desempenho dos equipamentos,a geração de energia e o comportamento da rede elétrica. A energia produzida irá abas-tecer em parte a demanda de energia de cada local de implantação. Quando não existirconsumo ela será injetada à rede [Cem 2015].

O InovCity é considerado o maior projeto de redes elétricas inteligentes do país eestá transformando Aparecida em uma cidade mais sustentável, através de ações da ado-



ção de geração distribuída de energia por fontes renováveis, de eficiência energética, dautilização de iluminação pública eficiente, e permitindo a utilização de veículos elétricosentre outras ações, contribuindo de forma significativa para a redução das emissões deCO2 [Ino 2015].

O Paraná Smart Grid criado pelo governo do Paraná em setembro de 2013 foipensado para incentivar a geração distribuída por fontes renováveis. O projeto incluimicrogeração distribuída por fontes solares e eólicas e testes de conceito que abrangemdesde a automação predial até a integração à rede inteligente de eletropostos para carros,bicicletas e ônibus elétricos [Par 2015].

O Arquipélago de Fernando de Noronha será o primeiro local no Estado dePernambuco a contar com redes elétricas inteligentes instaladas pela Celpe. A conces-sionária, por meio de um projeto de P&D, está implantando na ilha um sistema que vaireunir as principais tecnologias nas áreas de medição, telecomunicações, tecnologia dainformação e automação em um único produto. Uma das iniciativas do projeto incluem aUsina Solar Noronha II, que tem previsão para entrar em operação no primeiro semestrede 2015 e, por meio do sistema de compensação de energia, regulamentado pela Aneelpara minigeração, a energia gerada será utilizada para compensar o consumo das unidadesda Administração Estadual da Ilha de Fernando de Noronha [Nor 2015].

A AES Eletropaulo e a Silver Spring Networks estão implantando uma plataformade medição inteligente em São Paulo [Smart Grid News Brasil 2012]. O Sistema Brasi-leiro de Multimedição Avançada (SIBMA), sistema desenvolvido pelo Centro de Estudose Sistemas Avançados do Recife (C.E.S.A.R) que visa automatizar a medição de energiaelétrica à distância, desde a concessionária até o consumidor, já começa a tratar tambéma GD [CES 2015].

2.6. Observações finaisAs redes elétricas inteligentes estão provocando uma revolução nos sistemas de energiaelétrica, pois exigem uma integração do sistema elétrico com diversas outras áreas depesquisa, incluindo fortemente as redes de comunicação. No contexto de redes elétricasinteligentes, a geração distribuída de energia vem recebendo cada vez mais destaque.Nesse novo cenário de rede elétrica, o fluxo de energia deixa de ser unidirecional, comono sistema atual, e passa a ser bidirecional coexistindo com fluxos de dados e de controlebidirecionais, o que muda drasticamente a arquitetura do sistema.

Este capítulo apresentou uma visão geral sobre geração distribuída de energia elé-trica com enfoque no requisitos e desafios que são trazidos às redes de comunicação quedarão suporte à transmissão de dados e mensagens de controle em redes elétricas inte-ligentes. Foram abordados novos conceitos relacionados à GD, tais como microgrids eVPPs, que introduzem novas formas de funcionamento dos sistemas para geração de ener-gia. Foram discutidos diversos desafios de comunicação relacionados à GD, considerandoaspectos como escalabilidade, confiabilidade, segurança e gerência da rede. Este capítulotambém comentou os principais projetos de redes elétricas inteligentes que incluem ageração distribuída de energia no Brasil e no Mundo.



Temas atuais na área de redes e sistemas distribuídos, como computação em nu-vem e redes definidas por software, podem ser aplicados a novas soluções de redes decomunicação que darão suporte a redes elétricas inteligentes e GD, como já vem sendoproposto em trabalhos recentes publicados na literatura. Como ainda não existem solu-ções completas e consolidadas, ainda há bastante espaço para pesquisa e desenvolvimentoem arquiteturas de rede e modelos e protocolos de comunicação que possam ser usadosnas redes elétricas do futuro.

Referências[SGD 2008] (2008). The Smart Grid: An Introduction. Departament of Energy (DOE),

Estados Unidos.

[Dnp 2010] (2010). IEEE Standard for Electric Power Systems Communications – Dis-tributed Network Protocol (DNP3). IEEE Std 1815-2010, pages 1–775.

[Dnp 2012] (2012). IEEE Standard for Electric Power Systems Communications-Distributed Network Protocol (DNP3). IEEE Std 1815-2012 (Revision of IEEE Std1815-2010), pages 1–821.

[Mod 2012] (2012). Modbus Organization - Modbus Application Protocol SpecificationV1.1b3. www.modbus.org.

[IBM 2015] (2015). UK Smart Energy Cloud - Supporting the UK´s Smart Me-ter Implementation Programme. http://www.ibm.com/smarterplanet/uk/en/smart_-grid/article/smart_energy_cloud.html - accessed in 2015.

[gre 2015] (2015). Washington University Green Cup Competition.http://greencup.wustl.edu - accessed in 2015.

[mic 2015] (Acessado em março de 2015). About Microgrids -Definition.http://www.microgridinstitute.org/. Microgrid Institute.

[Par 2015] (Acesso em fevereiro de 2015.). Copel inicia projeto de smart grid em Curi-tiba. http://www.ecilenergia.com.br/download/inovcity.pdf.

[Ino 2015] (Acesso em fevereiro de 2015.). InovCity Aparecida.http://www.ecilenergia.com.br/download/inovcity.pdf.

[Nor 2015] (Acesso em fevereiro de 2015.). Neoenergia inaugura primeira usina so-lar em Fernando de Noronha. http://www.blue-sol.com/energia-solar/neoenergia-inaugura-primeira-usina-solar-em-fernando-de-noronha/.

[CES 2015] (Acesso em fevereiro de 2015). Primeiro passopara medição inteligente e o Smart Grid no Brasil.http://www.abinee.org.br/informac/revista/64/files/assets/downloads/rev64.pdf.

[Cem 2015] (Acesso em fevereiro de 2015). Projeto Cidades do Futuro -Cemig inaugura micro usinas para geração de energia solar em MinasGerais. http://energiabusiness.com.br/conteudo/cemig-inaugura-micro-usinas-para-geracao-de-energia-solar-em-minas-gerais.html.



[RIB 2015] (Acesso em fevereiro de 2015.). Redes Inteligentes Brasil - Projeto Estra-tégico de PD Programa Brasileiro de REDES INTELIGENTES - Chamada ANEEL n011/2010. http://redesinteligentesbrasil.org.br/o-projeto.html.

[EIA 2014] (Acesso em janeiro de 2014.). U.S. Energy Information Administration (EIA)- Independent Statistics and Analysis. www.eia.doe.gov.

[Ackermann et al. 2001] Ackermann, T., Andersson, G., and Söder, L. (2001). Distribu-ted generation: a definition. Electric Power Systems Research, 57(3):195–204.

[Amaral and Monteiro 2010] Amaral, R. M. and Monteiro, M. V. (2010). A demanda porenergia elétrica residencial no brasil: Estimativa das elasticidades, renda e preço apóso apagão. XXX Encontro nacional de Engenharia de Produção.

[Amato 2013] Amato, F. (2013). Conta pelo uso de usinas termelétricas já atinge R$8,6 bilhoes. http://g1.globo.com/economia/noticia/2013/11/conta-pelo-uso-de-usinas-termeletricas-ja-atinge-r-86-bilhoes.html. G1 - Economia.

[Bayod-Rújula 2009] Bayod-Rújula, A. A. (2009). Future development of the electri-city systems with distributed generation. Energy, 34(3):377 – 383. {WESC} 20066th World Energy System Conference Advances in Energy Studies 5th workshop onAdvances, Innovation and Visions in Energy and Energy-related Environmental andSocio-Economic Issues.

[Bera et al. 2014] Bera, S., Misra, S., and Rodrigues, J. J. (2014). Cloud ComputingApplications for Smart Grid: A Survey. IEEE Transactions on Parallel and DistributedSystems, pages 1–1.

[Bitzer and Gebretsadik 2013] Bitzer, B. and Gebretsadik, E. S. (2013). Cloud compu-ting framework for smart grid applications. In 2013 48th International Universities’Power Engineering Conference (UPEC), pages 1–5.

[Bonneville Power Administration 2010] Bonneville Power Administration (2010). Pa-cific Northwest Smart Grid Demonstration Project. http://www.pnwsmartgrid.org.

[Bouhafs et al. 2012] Bouhafs, F., Mackay, M., and Merabti, M. (2012). Links to thefuture: Communication requirements and challenges in the smart grid. Power andEnergy Magazine, IEEE, 10(1):24–32.

[Brasil 2012] Brasil, D. (2012). Impacto da Integração das Fontes Renováveis Alterna-tivas de Energia no Sistema - O SIN do Futuro. http://www.ons.org.br/home/. Rio +20.

[Brown 2008] Brown, R. (2008). Impact of smart grid on distribution system design. InPower and Energy Society General Meeting - Conversion and Delivery of ElectricalEnergy in the 21st Century, pages 1 –4.

[Budka et al. 2010a] Budka, K., Deshpande, J., Hobby, J., Kim, Y.-J., Kolesnikov, V.,Lee, W., Reddington, T., Thottan, M., White, C., Choi, J.-I., Hong, J., Kim, J., Ko,



W., Nam, Y.-W., and Sohn, S.-Y. (2010a). GERI - Bell Labs smart grid research fo-cus: Economic modeling, networking, and security & privacy. In 2010 First IEEEInternational Conference on Smart Grid Communications (SmartGridComm), pages208–213.

[Budka et al. 2010b] Budka, K. C., Deshpande, J. G., Doumi, T. L., Madden, M., andMew, T. (2010b). Communication network architecture and design principles for smartgrids. Bell Labs Technical Journal, 15(2):205–227.

[Calderaro et al. 2011] Calderaro, V., Hadjicostis, C. N., Piccolo, A., and Siano, P.(2011). Failure Identification in Smart Grids Based on Petri Net Modeling. IEEETransactions on Industrial Electronics, 58(10):4613–4623.

[Cheung et al. 2007] Cheung, H., Hamlyn, A., Wang, L., Yang, C., and Cheung, R.(2007). Computer network security strategy for coordinated distribution system ope-rations. In Power Engineering, 2007 Large Engineering Systems Conference on, pages279–283.

[Chim et al. 2011] Chim, T., Yiu, S., Hui, L., and Li, V. (2011). PASS: Privacy-preserving authentication scheme for smart grid network. In 2011 IEEE InternationalConference on Smart Grid Communications (SmartGridComm), pages 196 –201.

[Cleveland 2008] Cleveland, F. (2008). Cyber security issues for advanced metering in-frasttructure (AMI). In IEEE Power and Energy Society General Meeting - Conversionand Delivery of Electrical Energy in the 21st Century, pages 1 – 5.

[Deshpande et al. 2011] Deshpande, J. G., Kim, E., and Thottan, M. (2011). Differentia-ted services QoS in smart grid communication networks. Bell Labs Technical Journal,16(3):61–81.

[DNV KEMA Energy and Sustainability 2011] DNV KEMA Energy and Sustainability(2011). PowerMatching City. http://www.powermatchingcity.nl/.

[Dorsch et al. 2014] Dorsch, N., Kurtz, F., Georg, H., Hagerling, C., and Wietfeld, C.(2014). Software-defined networking for Smart Grid communications: Applications,challenges and advantages. IEEE International Conference on Smart Grid Communi-cations (SmartGridComm), pages 422–427.

[dos Santos 2014] dos Santos, M. A. (2014). Utilizando técnicas de confiança para con-trole adaptativo do intervalo de polling nos sistemas de smart metering. Mestrado,Universidade Federal Fluminense.

[El-Khattam and Salama 2004] El-Khattam, W. and Salama, M. (2004). Distributed ge-neration technologies, definitions and benefits. Electric Power Systems Research,(2):119–128.

[ENEL 2014] ENEL (2014). Grid4EU. http://enel.com/en-GB.

[Enose 2011] Enose, N. (2011). A unified management system for smart grid. In IEEEPES Innovative Smart Grid Technologies - India (ISGT India), pages 328 – 333.



[EPRI 2009] EPRI (2009). Report to nist on the smart grid interoperability standardsroadmap. Electric Power Research Institute.

[EPRI 2015] EPRI (Acesso em março de 2015). Electric Power Research Institute -Intelligrid [Online]. http://intelligrid.epri.com.

[Ericsson 2004] Ericsson, G. (2004). Communication requirements - basis for investmentin a utility wide-area network. IEEE Transactions on Power Delivery, 19(1):92 – 95.

[Fang et al. 2011] Fang, X., Misra, S., Xue, G., and Yang, D. (2011). Smart grid - thenew and improved power grid : A survey. Power, PP, no. 99:1–37.

[Fang et al. 2012] Fang, X., Misra, S., Xue, G., and Yang, D. (2012). Smart Grid ?The New and Improved Power Grid: A Survey. IEEE Communications Surveys &Tutorials, 14:944–980.

[Fogaça 2015] Fogaça, J. (Acessado em março de 2015). Química Ambiental - EnergiaLimpa. http://www.brasilescola.com/quimica/energia-limpa.htm.

[Galli et al. 2011] Galli, S., Scaglione, A., and Wang, Z. (2011). For the Grid and Th-rough the Grid: The Role of Power Line Communications in the Smart Grid. Procee-dings of the IEEE, 99(6):998–1027.

[Galvin Electricity Initiative 2007] Galvin Electricity Initiative (2007). Mesa del Sol - APath to Perfect Power. http://www.galvinpower.org.

[Genge et al. 2014] Genge, B., Beres, A., and Haller, P. (2014). A survey on cloud-based software platforms to implement secure smart grids. 2014 49th InternationalUniversities Power Engineering Conference (UPEC), pages 1–6.

[Giani et al. 2011] Giani, A., Bitar, E., Garcia, M., McQueen, M., Khargonekar, P., andPoolla, K. (2011). Smart grid data integrity attacks: Characterizations and counterme-asures. Cyber and Physical Security and Privacy, pages 232–237.

[Guimarães et al. 2013] Guimarães, P. H. V., Aes, Murillo, A., Andreoni, M., Mattos,D. M. F., Ferraz, L. H. G., Pinto, F. A. V., Costa, L. H. M. K., and Duarte, O. C.M. B. (2013). Capítulo 3- Comunicação em Redes Elétricas Inteligentes: Eficiência,Confiabilidade, Segurança e Escalabilidade. In Minicursos do Simpósio Brasileiro deRedes de Computadores e Sistemas Distribuídos.

[Gungor et al. 2010] Gungor, V., Lu, B., and Hancke, G. (2010). Opportunities and chal-lenges of wireless sensor networks in smart grid. IEEE Transactions on IndustrialElectronics, 57(10):3557–3564.

[Gungor et al. 2011] Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., Cecati, C.,and Hancke, G. (2011). Smart grid technologies: Communication technologies andstandards. IEEE Transactions on Industrial Informatics, 7(4):529–539.



[Hashmi et al. 2011] Hashmi, M., Hänninen, S., and Mäki, K. (2011). Survey of smartgrid concepts, architectures, and technological demonstrations worldwide. In 2011IEEE PES Conference on Innovative Smart Grid Technologies (ISGT Latin America),pages 1 – 7.

[Hossain et al. 2012] Hossain, E., Han, Z., and Poor, H. V., editors (2012). Smart GridCommunications and Networking. Cambridge University Press.

[(IEA) 2002] (IEA), I. E. A. (2002). Distributed Generation in Liberalised ElectricityMarkets. OECD Publishing, Paris.

[Jeon 2011] Jeon, Y. (2011). QoS requirements for the smart grid communications sys-tem. International Journal of Computer Science and Network Security (IJCSNS),11(3):86–94.

[Kagan and Gouvea 2013] Kagan, N. and Gouvea, M. (2013). Redes Elétrica Inteligen-tes no Brasil - Análise de custo e benefícios de um plano nacional de implantação.SYNERGIA, Brasil.

[Keshav and Rosenberg 2011] Keshav, S. and Rosenberg, C. (2011). How internet con-cepts and technologies can help green and smarten the electrical grid. ACM SIGCOMMComputer Communication Review, 41(1):109–114.

[Kim et al. 2011] Kim, Y., Ngai, E. C.-H., and Srivastava, M. B. (2011). Cooperativestate estimation for preserving privacy of user behaviors in smart grid. Cyber andPhysical Security anda Privacy, pages 178–183.

[Korea Smart Grid Institute 2014] Korea Smart Grid Institute (Acesso em julho de2014.). Korea Smart Grid Roadmap 2030. http://www.smartgrid.or.kr/eng.htm.

[Li and Zhang 2010] Li, H. and Zhang, W. (2010). QoS Routing in Smart Grid. In IEEEGlobal Telecommunications Conference (GLOBECOM 2010), pages 1–6.

[Light S.A. 2014] Light S.A. (Acesso em dezembro de 2014). Programa Smart GridLight. http://www.smartgridlight.com.br/.

[LLC 2015] LLC (Acesso em fevereiro de 2015.). Distributed Generation Projects.http://www.powerengineersllc.com/dgprojects.htm.

[Lo and Ansari 2012] Lo, C.-H. and Ansari, N. (2012). The progressive smart grid sys-tem from both power and communications aspects. IEEE Communications SurveysTutorials, 14(3):799–821.

[Lopes et al. 2014] Lopes, Y., Fernandes, N., and Bastos, C. (2014). Uma Proposta paraa Autoconfiguração de Redes de Subestação IEC 61850 Baseada em OpenFlow. XIXWorkshop de Gerência e Operação de Redes e Serviços (WGRS), pages 38–47.

[Lopes et al. 2015] Lopes, Y., Fernandes, N. C., Bastos, C. A. M., and C.Muchaluat-Saade, D. (2015). Smartflow: A solution for autonomic management and control ofcommunication networks for smart grids. ACM/SIGAPP Symposium On Applied Com-puting (SAC).



[Lopes et al. 2012] Lopes, Y., Frazão, R. H., Molano, D. A., dos Santos, M. A., Calhau,F. G. a., Bastos, C. A. M., Martins, J. S. B., and Fernandes, N. C. (2012). Smart Gride IEC 61850: Novos Desafios em Redes e Telecomunicações para o Sistema Elétrico.In Minicursos do XXX Simposio Brasileiro de Telecomunicações, pages 1–44. (SBrT),Sociedade Brasileira de Telecomunicações, 1 edition.

[Maheshwari et al. 2013] Maheshwari, K., Lim, M., Wang, L., Birman, K., and van Re-nesse, R. (2013). Toward a reliable, secure and fault tolerant smart grid state estimationin the cloud. IEEE PES Innovative Smart Grid Technologies Conference (ISGT), pages1–6.

[Mayilvaganan and Sabitha 2013] Mayilvaganan, M. and Sabitha, M. (2013). A cloud-based architecture for Big-Data analytics in smart grid: A proposal. In IEEE Internati-onal Conference on Computational Intelligence and Computing Research, pages 1–4.IEEE.

[McCauley 2013] McCauley, M. (Accesso em janeiro de 2013). What Is SDN All About,Then? http://www.noxrepo.org/2012/03/sdn/.

[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Pe-terson, L., Rexford, J., Shenker, S., and Turner, J. (2008). Openflow: enabling innova-tion in campus networks. SIGCOMM Computer Communication Review, 38(2):69–74.

[Müller et al. 2012] Müller, C., Georg, H., and Wietfeld, C. (2012). A modularized anddistributed simulation environment for scalability analysis of smart grid ict infrastruc-tures. In Proceedings of the 5th International ICST Conference on Simulation Toolsand Techniques, SIMUTOOLS ’12, pages 327–330.

[Neuman and Tan 2011] Neuman, C. and Tan, K. (2011). Mediating cyber and physi-cal threat propagation in secure smart grid architectures. In 2011 IEEE InternationalConference on Smart Grid Communications (SmartGridComm), pages 238–243.

[NIST 2010] NIST (2010). Nist 7628 - guidelines for smart grid cyber security vol. 1:smart grid cyber security strategy, architecture, and high-level requirements. NationalInstitute of Standards and Technology.

[NIST 2011] NIST (2011). Nist 7761 - guidelines for assessing wireless standards forsmart grid applications. National Institute of Standards and Technology.

[Palensky and Dietrich 2011] Palensky, P. and Dietrich, D. (2011). Demand Side Ma-nagement: Demand Response, Intelligent Energy Systems, and Smart Loads. IEEETransactions on Industrial Informatics, 7(3):381–388.

[Pan et al. 2014] Pan, J., JAIN, R., and Paul, S. (2014). A survey of energy efficiencyin buildings and microgrids using networking technologies. IEEE CommunicationsSurveys Tutorials, (3):1709–1731.

[Patel et al. 2011] Patel, A., Aparicio, J., Tas, N., Loiacono, M., and Rosca, J. (2011).Assessing communications technology options for smart grid applications. In IEEE



International Conference on Smart Grid Communications (SmartGridComm), pages126–131.

[Pepermans et al. 2005] Pepermans, G., Driesen, J., Haeseldonckx, D., Belmans, R., andD haeseleer, W. (2005). Distributed generation: definition, benefits and issues. EnergyPolicy, 33(6):787–798.

[Pérez et al. 2013] Pérez, J., Díaz, J., Garbajosa, J., Yagüe, A., Gonzalez, E., and Lopez-Perea, M. (2013). Large-scale smart grids as system of systems. In Proceedings of theFirst International Workshop on Software Engineering for Systems-of-Systems, SESoS’13, pages 38–42. ACM.

[Rahman et al. 2012] Rahman, M., Bera, P., and Al-Shaer, E. (2012). SmartAnalyzer: Anoninvasive security threat analyzer for AMI smart grid. In Proceedings IEEE INFO-COM, pages 2255 – 2263.

[Rothenberg et al. 2011] Rothenberg, C. E., Nascimento, M. R., and Salvador, M. R.(2011). OpenFlow e redes definidas por software : um novo paradigma de controlee inovação em redes de pacotes. Control, 7:65–75.

[Sensorweb 2015] Sensorweb, L. (Acessado em março de 2015). Information and Com-putation Hierarchy for Smart Grids. http://sensorweb.cs.gsu.edu/?q=SmartGrid. Ge-orgia State University.

[Servatius 2015] Servatius, H.-G. (Acessado em março de 2015).Transforming Utilities: Success Based on a Fitness Diagnosis.http://www.business2community.com/strategy/transforming-utilities-success-based-on-a-fitness-diagnosis-0564365sch.

[Simmhan et al. 2013] Simmhan, Y., Aman, S., Kumbhare, A., Liu, R., Stevens, S.,Zhou, Q., and Prasanna, V. (2013). Cloud-Based Software Platform for Big DataAnalytics in Smart Grids. Computing in Science & Engineering, 15:38–47.

[Smart Grid News Brasil 2012] Smart Grid News Brasil (Acesso em ju-lho de 2012). Smart grid: Piloto envolve mil clientes em São Paulo.http://smartgridnews.com.br/smart-grid-piloto-envolve-mil-clientes-em-sao-paulo/.

[Strachan and Farrell 2006] Strachan, N. and Farrell, A. (2006). Emissions from distribu-ted vs. centralized generation: The importance of system performance. Energy Policy,(17):2677–2689.

[Sydney et al. 2013] Sydney, A., Nutaro, J., Scoglio, C., Gruenbacher, D., and Schulz,N. (2013). Simulative comparison of multiprotocol label switching and openflownetwork technologies for transmission operations. Smart Grid, IEEE Transactionson, 4(2):763–770.

[Thilaga et al. 2012] Thilaga, S., Sivapragash, C., and Kumar, S. (2012). AdvancedCloud Computing in Smart Power Grid. IET Chennai 3rd International Conferenceon Sustainable Energy and Intelligent Systems (SEISCON 2012), pages 356–361.



[Vallejo et al. 2012] Vallejo, A., Zaballos, A., Selga, J., and Dalmau, J. (2012). Next-generation QoS control architectures for distribution smart grid communicationnetworks. IEEE Communications Magazine, 50(5):128–134.

[Wang et al. 2011] Wang, J., Yang, X., and Long, K. (2011). Web DDoS detection sche-mes based on measuring user’s access behavior with large deviation. In IEEE GlobalTelecommunications Conference (GLOBECOM 2011), pages 1 – 5.

[Yan et al. 2011] Yan, Y., Qian, Y., and Sharif, H. (2011). A secure and reliable in-network collaborative communication scheme for advanced metering infrastructure insmart grid. In IEEE Wireless Communications and Networking Conference (WCNC),pages 909 –914.

[Zhang et al. 2013] Zhang, J., Seet, B.-c., and Lie, T.-t. (2013). Opportunities forSoftware-Defined Networking in Smart Grid. In International Conference on Infor-mation, Communications & Signal Processing, pages 1–5. IEEE.

[Zhu et al. 2011] Zhu, T., Xiao, S., Ping, Y., Towsley, D., and Gong, W. (2011). A se-cure energy routing mechanism for sharing renewable energy in smart microgrid. In2011 IEEE International Conference on Smart Grid Communications (IEEE Smart-GridComm), pages 143–148.



Capítulo

3

Plataformas para a Internet das Coisas

Paulo F. Pires, Flavia C. Delicato, Thais Batista, Thomaz Barros, Everton Cavalcante e Marcelo Pitanga

Resumo

A Internet das Coisas (IoT) é um paradigma no qual objetos inteligentes colaboram de forma ativa com outros objetos físicos e virtuais disponíveis na Internet. Ambientes de IoT são caracterizados por um alto grau de heterogeneidade de dispositivos e protocolos de rede. Para tratar tal heterogeneidade, várias plataformas de middleware para IoT têm sido propostas visando abstrair as especificidades de tais dispositivos para aplicações e usuários finais, bem como promover interoperabilidade entre eles. Entretanto, a falta de padronização existente em IoT faz com que tais plataformas adotem diferentes modelos de programação e não abordem adequadamente uma série de requisitos importantes nesse contexto. Dessa forma, arquiteturas de referência (ARs) são capazes de definir um conjunto inicial de blocos de construção para ambientes de IoT e fornecer uma base sólida para alavancar sua ampla adoção. Tendo em vista a relevância de plataformas de middleware e arquiteturas de referência em IoT, bem como os desafios e oportunidades de pesquisa existentes, este capítulo tem por objetivos: (i) levantar e discutir requisitos de middleware para IoT; (ii) apresentar ARs e plataformas de middleware para IoT existentes; e (iii) demonstrar o uso prático de uma plataforma de IoT.

Abstract

The Internet of Things (IoT) is a paradigm in which smart objects actively collaborate with other physical and virtual objects available in the Internet. IoT environments are characterized by a high degree of heterogeneity, encompassing devices with different capabilities, functionalities, and network protocols. To address such heterogeneity, several middleware platforms have been proposed aiming at abstracting away the specificities of such devices from applications and/or end-users, as well as promoting interoperability among them. Nevertheless, the lack of standardization in IoT makes these platforms to adopt different programming models and to not properly address several important requirements in this context. Therefore, reference architectures are

3: Plataformas para a Internet das Coisas.


able to define an initial set of building blocks for IoT environments and to provide a solid foundation for leveraging its wide adoption. Due to the relevance of middleware platforms and reference architectures in IoT, as well as the existing research challenges and opportunities, this chapter aims to: (i) elicit and discuss requirements for IoT platforms; (ii) present existing reference architectures and middleware for IoT; (iii); demonstrate the practical use of an IoT middleware platform.

3.1. Introdução A Internet das Coisas (do inglês Internet of Things – IoT) [Atzori et al. 2010] é um paradigma que preconiza um mundo de objetos físicos embarcados com sensores e atuadores, conectados por redes sem fio e que se comunicam usando a Internet, moldando uma rede de objetos inteligentes capazes de realizar variados processamentos, capturar variáveis ambientais e reagir a estímulos externos. Esses objetos interconectam-se entre si e com outros recursos (físicos ou virtuais) e podem ser controlados através da Internet, permitindo o surgimento de uma miríade de aplicações que poderão se beneficiar dos novos tipos de dados, serviços e operações disponíveis. A IoT é uma das principais tecnologias emergentes que contribuem para concretizar novos domínios de aplicação das tecnologias de informação e comunicação (TICs), a exemplo do domínio de cidades inteligentes, no qual o uso de tecnologias avançadas de comunicação e sensoriamento visa prover serviços de valor agregado para os órgãos administrativos de tais cidades e para seus cidadãos [Zanella et al. 2014]. Vários avanços tecnológicos recentes possibilitaram o surgimento da IoT, tais como redes de sensores sem fio, comunicação móvel e computação ubíqua. No entanto, há ainda uma série de desafios a serem superados para alavancar a ampla disseminação desse paradigma, principalmente com relação ao desenvolvimento de aplicações e à alta heterogeneidade decorrente da inerente diversidade de tecnologias de hardware e software desse ambiente. O primeiro desafio diz respeito a heterogeneidade dos ambientes de IoT, a qual demanda soluções para permitir a interoperabilidade e integração dos diversos componentes que fazem parte desses ambientes. Nesse contexto, plataformas de middleware têm surgido como soluções promissoras para prover tal interoperabilidade e gerenciar a crescente variedade de dispositivos associados a aplicações, bem como o consumo de dados por parte dos usuários finais [Teixeira et al. 2011]. Tais plataformas são inseridas entre as aplicações e a infraestrutura (de comunicação, processamento e sensoriamento) subjacente, provendo um meio padronizado para o acesso aos dados e serviços fornecidos pelos objetos através de uma interface de alto nível [Bandyopadhyay et al. 2011]. A adoção de uma plataforma de middleware também pode contribuir para facilitar a construção de aplicações para IoT. Nesse contexto, o desafio reside no fato de que, a fim de permitir a criação de aplicações que combinem recursos do mundo físico disponibilizados via Web, são necessários modelos de alto nível que abstraiam os serviços e dispositivos físicos subjacentes. Com isso, usuários e aplicações consumidores dos dados originados dos dispositivos conectados não precisarão lidar com funcionalidades de baixo nível para a manipulação de tais objetos [Delicato et al. 2013a]. Outros desafios concernem à enorme escalabilidade desses ambientes, em termos do número de dispositivos conectados, à necessidade de gerenciar tais dispositivos e ao grande volume de dados produzidos.



Existem várias propostas de middleware para IoT, cada uma atendendo um subconjunto dos requisitos necessários para viabilizar tais ambientes, principalmente no que tange a comunicação entre dispositivos heterogêneos. O desenvolvimento de plataformas de middleware especificamente voltadas para ambientes de IoT é uma área de pesquisa recente que tem atraído a atenção da indústria e da comunidade acadêmica. Os trabalhos descritos por Pires et al. (2014), Qin et al. (2011) e Gao et al. (2011) são alguns exemplos de plataformas concebidas para endereçar alguns dos desafios anteriormente descritos, principalmente com relação à integração transparente de dispositivos heterogêneos e à provisão de mecanismos de alto nível para desenvolvimento de aplicações. Contudo, tais propostas ainda não atingiram um nível de maturidade, requerendo esforços de pesquisa adicionais, como: (i) a construção de infraestruturas robustas e tolerantes a falha para gerenciar e processar dados provenientes dos vários dispositivos integrados; (ii) o gerenciamento de incertezas e resolução de conflitos, e; (iii) suporte à adaptação de aplicações sob condições dinâmicas do ambiente. No contexto de IoT, a falta de padronização existente na área faz com que tais plataformas de middleware adotem diferentes modelos de programação que, em geral, não são compatíveis entre si, gerando silos verticais que são ainda um obstáculo à plena interoperabilidade requerida por esse paradigma. Outras limitações das soluções existentes dizem respeito ao fato de elas não abordarem requisitos de escalabilidade de forma apropriada, fornecerem modelos inadequados de governança, e negligenciarem questões de privacidade e segurança na sua concepção. Finalmente, faz-se ainda necessária a inclusão de mecanismos para lidar com a massiva quantidade de dados (também potencialmente heterogêneos) produzidos pelos dispositivos interconectados. Tais dados devem ser manipulados de forma eficiente em termos do consumo de recursos dos dispositivos e, ao mesmo tempo, atender as demandas de aplicações, muitas delas em tempo real ou quasi-real. Nesse sentido, faz-se necessária a criação de arquiteturas de referência que definam um conjunto inicial de blocos de construção para ambientes de IoT, levando em conta todos os requisitos desses ambientes, e forneçam uma base sólida para alavancar sua ampla adoção. Uma arquitetura de referência pode ser entendida como uma arquitetura abstrata que envolve conhecimento e experiências em um domínio de aplicação específico, sendo capaz de facilitar e guiar o desenvolvimento, a padronização e a evolução de sistemas de software em tal domínio [Cloutier et al. 2010, Nakagawa et al. 2011]. Tendo em vista a relevância do papel desempenhado por plataformas de middleware e por arquiteturas de referência no contexto de IoT, bem como os desafios e oportunidades de pesquisa existentes, este capítulo tem por objetivos: (i) levantar e discutir requisitos de middleware para IoT; (ii) apresentar arquiteturas de referência para IoT existentes; (iii) descrever plataformas de middleware que implementem soluções para os requisitos levantados, e; (iv) demonstrar o uso prático de uma plataforma de middleware para IoT. Como resultado, será possível conhecer o estado da arte no desenvolvimento de plataformas de middleware e arquiteturas de referência para IoT, fornecer subsídios para avaliar tais soluções, e compreender as tecnologias necessárias para a concretização dos desafios apresentados. O restante do capítulo está organizado como segue. A Seção 3.2 descreve alguns requisitos importantes de plataformas de middleware para IoT. A Seção 3.3 apresenta duas arquiteturas de referencia para IoT. A Seção 3.4 discute algumas plataformas de



middleware encontradas nos meios acadêmico e comercial. A Seção 3.5 descreve, através de cenários de uso típicos do domínio de IoT, como uma plataforma de middleware pode ser usada na construção de aplicações. A Seção 3.6 contém as considerações finais.

3.2. Requisitos de Middleware para IoT No contexto de IoT, plataformas de middleware devem satisfazer a um conjunto de requisitos visando atender às necessidades de aplicações e usuários, bem como endereçar os desafios que surgem nesse cenário. Esta seção aborda alguns dos requisitos considerados fundamentais para plataformas de middleware em IoT [Nagy et al. 2009, Bandyopadhyay et al. 2011, Chaqfeh e Mohamed 2012] e que são frequentemente mencionados na literatura, a saber: (i) interoperabilidade; (ii) descoberta e gerenciamento de dispositivos; (iii) interfaces de alto nível; (iv) ciência de contexto; (v) escalabilidade; (vi) gerenciamento de grandes volumes de dados; (vii) segurança, e; (viii) adaptação dinâmica. É importante mencionar que alguns desses requisitos são inerentes a toda e qualquer plataforma de middleware, independentemente do domínio de aplicação, tais como interoperabilidade e escalabilidade. Outros, por sua vez, são compartilhados com plataformas de middleware em computação ubíqua, paradigma correlato à IoT, a exemplo da ciência de contexto. Por fim, outros requisitos, tais como adaptação dinâmica, apesar de previamente existentes em outros contextos, são de fundamental importância ou mesmo mandatórios nesse novo cenário. Um primeiro requisito a ser imperativamente endereçado por uma plataforma de middleware em IoT diz respeito a prover interoperabilidade entre os diversos dispositivos e plataformas disponíveis no ambiente. Esse é um dos principais desafios para a concretização do paradigma de IoT devido ao grande número de dispositivos a serem integrados e sua heterogeneidade tanto em termos de hardware quanto de software, protocolos (muitos deles proprietários), formatos de dados, etc. Dessa forma, ao endereçar a questão da interoperabilidade, plataformas de middleware passam a desempenhar um papel de suma importância no cenário de IoT por permitirem que aplicações sejam criadas de maneira mais rápida e com maior valor agregado para os usuários, podendo fazer uso de diversos dispositivos e/ou mesmo outras aplicações. Delicato et al. (2013a) destacam que a integração de dispositivos no contexto de IoT perpassa múltiplos níveis:

• em mais baixo nível, é necessário integrar, de maneira transparente, uma miríade de dispositivos físicos heterogêneos de modo a ocultar detalhes com relação à rede, aos formatos de dados empregados, e até mesmo à semântica das informações [Bandyopadhyay et al. 2011];

• em um nível intermediário, a fim de prover serviços de valor agregado aos usuários, é necessário integrar e disponibilizar dados providos por esses dispositivos, podendo incluir simples funções de processamento de dados ou mesmo aplicações Web mais complexas;

• por fim, em mais alto nível, um modelo padronizado de programação pode promover integração no que se refere à agregação e transformação de informações providas pelos dispositivos, de modo que desenvolvedores de aplicações não necessitam ter qualquer conhecimento acerca das especificidades dos dispositivos físicos e do ambiente de rede subjacente.



Uma característica comum da infraestrutura de comunicação em ambientes de IoT diz respeito ao fato de que sua topologia é dinâmica e frequentemente desconhecida, visto que dispositivos podem ser integrados ao ambiente e utilizados de maneira oportunista e não previamente planejada [Delicato et al. 2013b]. Dessa forma, é igualmente importante que uma plataforma de middleware possibilite a descoberta de dispositivos presentes no ambiente em questão, realizada dinamicamente a fim de atender os requisitos das aplicações. Além disso, é necessário prover mecanismos para o gerenciamento de dispositivos, que diz respeito à capacidade de fornecer informações de localização e estado do dispositivo permitindo, dentre outras funcionalidades, desconectar algum dispositivo roubado ou não reconhecido, atualizar software embarcado, modificar configurações de segurança, modificar remotamente configurações de hardware, localizar um dispositivo perdido, apagar dados sensíveis de dispositivos, e até mesmo possibilitar a interação entre dispositivos. Ciência de contexto é outro requisito importante para plataformas de middleware para IoT. De acordo com Dey (2001), contexto é qualquer informação que pode ser utilizada para caracterizar uma pessoa, lugar ou objeto considerado relevante ao ambiente em questão. Dessa forma, informações de contexto, tais como o estado do objeto, seus vizinhos e sua localização, por exemplo, necessitam ser coletadas e processadas com o objetivo de efetuar ações ou reagir a estímulos com base nos dados extraídos [Perera et al. 2014]. Plataformas de middleware em IoT devem então ser responsáveis pela coleta, gerenciamento e processamento de informações de contexto providas por múltiplas fontes, liberando as aplicações e usuários da tarefa de manipulá-las e tornando transparente tal manipulação. Considerando o amplo potencial do paradigma de IoT, a consultoria americana Gartner, Inc. prevê que bilhões de dispositivos estarão aptos a serem utilizados por aplicações em curto prazo de tempo [Gartner 2014]. Dessa forma, uma plataforma de middleware para IoT deve dar suporte à escalabilidade, i.e., deve ser capaz de assimilar um número crescente de dispositivos e requisições e funcionar corretamente, mesmo em situações de uso intenso. Devido à sua facilidade de provisão e uso de recursos computacionais, que podem ser alocados e liberados sob demanda, o paradigma de computação em nuvem tem surgido como uma solução promissora para endereçar a questão da escalabilidade em ambientes de IoT, proporcionando o surgimento da chamada “nuvem de coisas” (cloud-of-things, em Inglês) [Soldatos et al. 2012]. Com o aumento do número de dispositivos presentes em um ambiente de IoT, cresce também o volume de dados providos e transmitidos através da rede. Nesse contexto, o gerenciamento de grandes volumes de dados é um requisito importante de uma plataforma de middleware para IoT, permitindo que ela possa acompanhar a demanda de coleta e análise de dados e, consequentemente, prover respostas, decisões e/ou atuações de maneira eficiente. Nesse contexto, surgem desafios para a persistência, consulta, indexação, processamento e manipulação de transações, que podem ser realizadas na própria plataforma de middleware ou em um banco de dados relacional externo a ela, por exemplo. Recentemente, soluções baseadas em Big Data e também em computação em nuvem têm surgido como uma potencial resposta a alguns desses desafios, a fim de permitir lidar com um imenso volume de dados, diverso e não estruturado [Soldatos et al. 2012, Tracey e Sreenam 2013, Chen et al. 2014].



No contexto de IoT, muitas vezes o papel dos dispositivos integrados é de coletar dados privados que podem inclusive ser transportados através de redes sem segurança adequada. Por essa razão, é importante que uma plataforma de middleware em IoT forneça estratégias de segurança, a fim de manter a integridade e privacidade dos dados disponibilizados, além de proteger tanto os dispositivos envolvidos quanto os recursos expostos à rede. Técnicas como a prevenção à modificação maliciosa de dados (tamperproofing) e ofuscação de código podem ser usadas para endereçar segurança com relação aos dispositivos, enquanto que é possível adotar estratégias para promover a segurança dos recursos, tais como bloqueio de portas abertas não usadas, e o uso de protocolos de segurança e de protocolos de autorização e/ou autenticação. Por fim, considerando a alta dinamicidade dos ambientes de IoT, nos quais dispositivos podem tornar-se indisponíveis pelos mais diversos motivos (e.g., falha, capacidade energética, indisponibilidade de conexão à rede, mobilidade de usuário, etc.), plataformas de middleware devem prover estratégias para adaptação dinâmica, garantindo assim a disponibilidade e qualidade das aplicações durante a sua execução. Esse é um requisito especialmente importante para aplicações em domínios críticos, a exemplo de aplicações de health care que monitoram pacientes, visto que falhas ou degradação de parâmetros de qualidade nesse tipo de aplicação podem ser uma ameaça à vida e à saúde das pessoas. Dessa forma, plataformas de middleware em IoT devem manter-se disponíveis e funcionando adequadamente nesse ambiente dinâmico, coletando, analisando e reagindo a mudanças no contexto em que elas e objetos a ela conectados estão inseridos.

3.3. Arquiteturas de Referência para IoT Apesar das diferentes definições encontradas na literatura, uma arquitetura de referência pode ser entendida como um tipo de arquitetura abstrata que envolve conhecimento e experiências acerca de como projetar sistemas em um determinado domínio, sendo, portanto capaz de guiar o seu desenvolvimento e evolução. Além disso, arquiteturas de referência podem ser utilizadas como um artefato de padronização para permitir interoperabilidade entre sistemas ou componentes de sistemas [Muller 2008, Angelov et al. 2009, Nakagawa et al. 2011]. Não raramente, os termos arquitetura de referência e modelo de referência têm sido utilizados de maneira intercambiável ou mesmo como sinônimos; entretanto, tais termos possuem definições distintas. Um modelo de referência é um artefato abstrato que apresenta um conjunto de conceitos comuns e relacionamentos entre eles (podendo ser representados, por exemplo, através de modelos conceituais, taxonomias ou ontologias) com relação a um domínio específico, sendo, portanto independente de padrões, tecnologias, implementações ou outros detalhes mais concretos [Nakagawa et al. 2014]. Por sua vez, uma arquitetura de referência pode ser concebida com base em um ou mais modelos de referência para especificar, de maneira unificada e não ambígua, regras de negócio, estilos/padrões arquiteturais, decisões arquiteturais, boas práticas de desenvolvimento e elementos de hardware e/ou software necessários à construção de arquiteturas concretas, que dizem respeito aos sistemas propriamente ditos no domínio em questão. Ou seja, um modelo de referência pode ser utilizado para prover a base comum a ser adotada para o estabelecimento de uma arquitetura de referência que, por sua vez, fornece os elementos concretos e abstratos que devem ser considerados para conceber a arquitetura de um sistema, que é apenas uma instância da



arquitetura de referência. A Figura 3.1 ilustra esses relacionamentos entre modelos de referência, arquiteturas de referência e arquiteturas concretas. É importante destacar que, apesar de ser desejável que arquiteturas de referência sejam estabelecidas com base em modelos de referência devido ao vocabulário comum que estes últimos proveem, essa não é uma condição mandatória.

Figura 3.1. Relacionamentos entre modelos de referência, arquiteturas de referência e arquiteturas concretas.

3.3.1. Por que precisamos de uma arquitetura de referência? Entre os principais objetivos de uma arquitetura de referência, destacam-se [Muller 2008, Angelov et al. 2009, Nakagawa et al. 2014]:

• Facilitar o desenvolvimento de sistemas, promovendo redução de tempo e custo. Arquiteturas de referência são capazes de influenciar diretamente a produtividade e a qualidade do desenvolvimento de sistemas, principalmente pelo fato de elas proverem os elementos fundamentais para a construção das arquiteturas concretas desses sistemas. Nessa perspectiva, o desenvolvimento de um sistema cuja arquitetura é baseada numa arquitetura de referência demanda menor esforço por parte da equipe com relação à investigação e ponderação sobre decisões arquiteturais, por exemplo.

• Padronizar arquiteturas de sistemas em um domínio. Através do consenso estabelecido por uma arquitetura de referência em termos de elementos fundamentais a serem considerados e diretrizes a serem seguidas, é possível desenvolver arquiteturas concretas interoperáveis entre si, facilitando assim a integração e compatibilidade entre diferentes sistemas heterogêneos no domínio em questão.

• Guiar a evolução de sistemas existentes. Evolução é um processo natural e necessário aos sistemas atualmente em execução, seja ela motivada pela necessidade de adaptá-los a novos contextos, modificar suas funcionalidades a fim de atender novos requisitos, ou promover melhorias em sua qualidade. Dessa forma, o conhecimento estabelecido em uma arquitetura de referência é de fundamental importância para que tal processo seja conduzido de forma



sistemática a fim de endereçar as mudanças necessárias a serem feitas no sistema, evitando, ao mesmo tempo, a erosão de sua arquitetura.

Assim como em diversos outros domínios, o estabelecimento de arquiteturas de referência é uma questão importante em IoT, tendo em vista os objetivos desse tipo de arquitetura. Em primeiro lugar, os direcionamentos providos por uma arquitetura de referência são elementos essenciais para guiar e facilitar a construção de sistemas de IoT, considerando sua crescente escala e complexidade. Mais ainda, por proverem os blocos de construção fundamentais à construção das arquiteturas concretas de tais sistemas, arquiteturas de referência permitem construir sistemas capazes de atender aos requisitos existentes nesse domínio. Por fim, considerando a alta heterogeneidade e a falta de padronização em termos de dispositivos, protocolos e sistemas intrínsecas à IoT, desenvolver soluções que possam ser integradas entre si é um aspecto de suma importância nesse cenário, e tal interoperabilidade pode ser alcançada projetando-se arquiteturas de sistemas que sejam fundamentadas em uma arquitetura de referência.

Apesar de sua relevância, arquiteturas de referência em IoT são um elemento de pesquisa muito recente, com poucas iniciativas até o presente momento. Nas Seções 3.3.2 e 3.3.3, duas propostas de arquiteturas de referência para IoT são apresentadas e discutidas, a saber: (i) o IoT Architectural Reference Model [Bassi et al. 2013], desenvolvido no contexto do projeto europeu Internet of Things Architecture (IoT-A)1, e (ii) a arquitetura de referência proposta pela empresa WSO2 [Fremantle 2014].

3.3.2. A arquitetura de referência do IoT-A O projeto IoT-A propõe um modelo arquitetural de referência (MAR) que envolve uma arquitetura de referência base e a definição de um conjunto de características chave para sua construção. Essa arquitetura de referência é definida em um alto nível de abstração, fornecendo visões arquiteturais e perspectivas que são relevantes para a construção de várias (e potencialmente diferentes) arquiteturas para IoT. As visões do MAR fornecem descrições variadas que mostram a arquitetura sob diferentes ângulos e podem ser utilizadas durante as fases de projeto e implementação de uma arquitetura concreta. Uma visão é composta de pontos de vista que agregam vários conceitos arquiteturais. O MAR fornece as seguintes visões: (i) funcional; (ii) informação; (iii) operação, e; (iv) implantação.

Além das visões, as perspectivas definidas no MAR definem as decisões arquiteturais que tratam interesses comuns a mais de uma visão ou mesmo para todas. Esses interesses estão frequentemente relacionados a requisitos não funcionais ou atributos de qualidade. Uma perspectiva arquitetural é definida com uma coleção de atividades, táticas e diretrizes que são usadas para garantir que um sistema exiba um conjunto particular de atributos de qualidade relacionados, os quais influenciam um determinado número de visões arquiteturais de um sistema. O MAR fornece as seguintes perspectivas: (i) evolução e interoperabilidade; (ii) disponibilidade e resiliência; (iii) confiabilidade, segurança e privacidade, e; (iv) desempenho e escalabilidade. As próximas subseções detalham as visões e perspectivas da IoT-A.

1 Internet of Things Architecture (IoT-A): http://www.iot-a.eu/



3.3.2.1 Visão funcional Conforme mostrado na Figura 3.2, a visão funcional definida no MAR do IoT-A possui nove grupos de funcionalidades (GFs), a saber: (i) aplicação; (ii) gerenciamento; (iii) organização de serviço; (iv) gerenciamento de processo de IoT; (v) entidade virtual; (vi) serviço IoT; (vii) segurança; (viii) comunicação, e; (ix) dispositivo. Cada um desses GFs envolve um ou mais componentes funcionais (CFs), representados Figura 3.2 por retângulos internos aos GFs. Todavia, apesar de a visão funcional descrever os CFs, ela não especifica as interações que ocorrem entre esses elementos pelo fato de tais interações serem tipicamente dependentes de escolhas de projetos, sendo portanto realizadas durante o desenvolvimento da arquitetura concreta. É importante observar que os GF de aplicação e de dispositivo estão fora do escopo da arquitetura de referência do IoT-A, enquanto que os GF de gerenciamento e de segurança são transversais aos demais GFs. Cada um dos GFs e respectivos CFs são apresentados a seguir.

Figura 3.2. Ponto de vista de decomposição funcional da arquitetura de referência da IoT (adaptado de [Bassi et al. 2013, p. 168]).

3.3.2.1.1. Gerenciamento de processo de IoT O GF Gerenciamento de Processo de IoT refere-se à integração do processo tradicional de gerenciamento de sistemas com o MAR IoT, tendo como objetivo global fornecer os conceitos funcionais e interfaces necessárias para ampliar processos tradicionais (de negócio) com os processos do mundo da IoT. Esse GF engloba dois CFs, a saber, (i) Modelagem de Processo e (ii) Execução de Processo. O CF Modelagem de Processo fornece um ambiente para a modelagem de processos de negócios de IoT que serão serializados e executados no CF Execução de Processo e sua função principal é prover as ferramentas necessárias para modelar processos usando notações padronizadas, ou seja, usando novos conceitos de modelagem especificamente endereçando os comportamentos peculiares do ecossistema



de IoT. Por sua vez, o CF Execução de Processo executa os processos de IoT modelados no CF Modelagem de Processo utilizando os serviços de IoT orquestrados no GF Organização de Serviço. Esse CF é responsável por implantar os modelos de processos nos ambientes de execução, de modo que as atividades de um processo IoT são alocadas a ambientes apropriados de execução que realizam o processo de execução através da busca e invocação dos serviços de IoT apropriados. Para a execução adequada das aplicações, os requisitos de serviços de IoT devem ser resolvidos antes de os serviços de IoT específicos serem invocados. Para essa etapa, o CF Execução de Processo utiliza componentes do GF Organização de Serviço e, após selecionar os serviços de IoT adequados, os respectivos serviços são invocados. Assim, a próxima atividade do processo será executada com base no resultado da invocação do serviço.

3.3.2.1.2. Organização de Serviço O GF Organização de Serviço atua como um ponto de comunicação central entre muitos outros GFs. Uma vez que o conceito primário de comunicação dentro da MAR IoT é a ideia de serviço, a Organização de Serviço é utilizada para compor e orquestrar serviços de diferentes níveis de abstração. Esse GF engloba três CFs: (i) Composição de Serviço, (ii) Orquestração de Serviço, e (iii) Coreografia de Serviço.

O CF Composição de Serviço determina os serviços que são compostos de serviços de IoT e de outros serviços a fim de criar serviços com funcionalidade estendida. Esse CF tem duas funções principais:

• Suporte à composição de serviços flexíveis. Para tal, o CF deve prover resolução dinâmica de serviços complexos, compostos por outros serviços. Esses serviços passíveis de serem combinados são escolhidos com base na sua disponibilidade e nos direitos de acesso do usuário solicitante.

• Aumento da qualidade da informação. A qualidade de informação pode ser aumentada combinando informação de múltiplas fontes. Por exemplo, um valor médio, com uma incerteza intrinsicamente menor , pode ser calculado com base na informação acessada através muitos recursos.

O CF Orquestração de Serviço é responsável por controlar e coordenar os serviços de IoT que são apropriados para atender requisições dos usuários ou do CF Execução de Processos (c.f. Seção 3.3.2.1.1). Se necessário, recursos temporários serão criados para armazenar resultados intermediários que alimentam o CF Composição de Serviço ou para o processamento de eventos complexos.

O CF Coreografia de Serviço provê um mediador (broker) que trata a comunicação publicação/subscrição entre serviços. Um serviço pode oferecer suas capacidades no CF e a função do mediador garante que um cliente interessado na oferta encontrará o serviço com as capacidades desejadas. Por sua vez, os consumidores de serviços podem registrar as suas requisições de serviços para o CF, mesmo que um serviço adequado não esteja disponível no momento em que a requisição foi emitida. Com isso, o consumidor do serviço será notificado tão logo o serviço que atenda a sua requisição estiver disponível.



3.3.2.1.3. Entidade Virtual Entidades físicas são representadas no mundo digital por uma entidade virtual (EV). Há muitos tipos de representações digitais de entidades físicas, tais como modelos 3D, avatares, entradas de banco de dados e objetos (ou instâncias de uma classe em uma linguagem de programação orientada a objetos). No contexto de IoT, uma EV está associada a uma entidade física única, a qual ela representa. Embora haja geralmente apenas uma entidade física para cada EV, é possível que a mesma entidade física seja associada a várias EVs, e.g., uma representação diferente por domínio de aplicação. Cada EV deve ter um identificador unívoco e pode ser classificada como ativa ou passiva. Uma EV ativa refere-se a aplicações, agentes ou serviços que podem acessar outros serviços ou recursos, enquanto que uma EV passiva representa elementos de software passivos tais como entradas de banco de dados. Idealmente, EVs são representações sincronizadas de um determinado conjunto de aspectos (ou propriedades) da entidade física, ou seja, parâmetros digitais relevantes que representam as características da entidade física são atualizados imediatamente após qualquer alteração na entidade física. Da mesma forma, mudanças que afetam o mundo virtual também devem se manifestar na entidade física. O GF Entidade Virtual consiste de três CFs: (i) Resolução de EV, (ii) Serviço de Monitoramento de IoT e EVs, e (iii) Serviço de EV. Resolução de EV é o CF que permite um usuário de IoT recuperar associações entre EVs e serviços de IoT, incluindo a descoberta de novas e dinâmicas associações entre EV e serviços associados. Caso não haja uma associação, ela pode ser criada. O usuário também pode continuamente inscrever-se ou cancelar uma inscrição para receber notificações sobre a descoberta de associação que se encaixam na especificação da EV ou do serviço. No caso de uma notificação, uma função de retorno será chamada. Similarmente, o usuário pode inscrever-se ou cancelar uma inscrição para notificações sobre procura de associações. Esse CF também permite procurar serviços de EV relacionados, como, por exemplo, pesquisar por serviços expondo serviços relacionados a uma EV. Finalmente, ele também permite gerenciar associações, tais como realizar inclusão, exclusão e atualização de associações entre a EV e os serviços de IoT que estão associados à EV.

O CF Serviço de Monitoramento de IoT e EV é responsável por encontrar automaticamente novas associações, que são então incluídas no CF Resolução de EV. Novas associações podem ser derivadas com base em associações existentes, descrições de serviços e informações sobre EVs. As funções desse CF são: (i) declarar associações estáticas, como, por exemplo, criar uma nova associação estática entre EVs e serviços descritos pela associação fornecida; (ii) descobrir associações dinâmicas, i.e., criar uma nova associação dinâmica ou monitorar associações entre EVs e serviços, e; (iii) atualizar e excluir associação do arcabouço de resolução de EVs.

Finalmente, o CF Serviço de EV manipula serviços de entidades. Um serviço de entidade representa um ponto de acesso global para uma entidade específica oferecendo meios para aprender e manipular o seu estado. O serviço fornece acesso a uma entidade via operações que habilitam leituras e/ou atualizações de valores dos seus atributos, operações essas que podem ser de somente leitura, somente escrita ou ambas. Além disso, um serviço específico de EV pode prover a funcionalidade de armazenamento de histórico para a publicação de informações integradas ao contexto, informação de estado de EVs e capacidades de EVs.



3.3.2.1.4. Serviço IoT O GF Serviço IoT contém os serviços IoT e funcionalidades para descoberta, busca e resolução de nomes de serviços IoT. Ele consiste de dois CFs, (i) Serviço IoT e (ii) Resolução de Serviço de IoT. Um CF Serviço IoT expõe um recurso para torna-lo acessível a outras partes do sistema IoT. Tipicamente, serviços IoT podem ser usados para obter informações fornecidas por um recurso recuperado de um dispositivo sensor ou de um recurso de armazenamento conectado através de uma rede. Mais ainda, um serviço IoT pode ser usado para entregar informação para um recurso, controlar dispositivos atuadores ou mesmo configurar um recurso em termos de aspectos não funcionais tais como controle de acesso, disponibilidade e desempenho. Além disso, serviços IoT podem ser invocados de forma síncrona, para responder uma requisição do serviço, ou de forma assíncrona, para enviar notificações de acordo com subscrições previamente realizadas através do serviço. Um tipo particular de serviço IoT é o que armazena o histórico de recursos, que fornece capacidades de armazenamento para as medições geradas pelos recursos.

O CF Resolução de Serviço IoT fornece todas as funcionalidades necessárias para que um cliente seja capaz de procurar e invocar serviços IoT. Ele também fornece aos serviços a capacidade de gerenciar as suas descrições de serviços (tipicamente armazenadas como uma entrada no banco de dados). Assim, eles podem ser procurados e descobertos pelos clientes, que podem ser usuários humanos ou mesmo componentes de software. Descrições de serviços são identificadas por um identificador e contêm um localizador (service locator) que permite o acesso ao serviço. Tipicamente, essas descrições possuem informações adicionais, tais como a saída do serviço, o tipo de serviço ou a área geográfica para o qual o serviço é fornecido. O conteúdo exato, estrutura e representação dependem das escolhas de projeto realizadas, questão deixada em aberto no nível de arquitetura de referência. As funcionalidades oferecidas por esse CF são:

• Descoberta. Utilizado na procura de serviço IoT sem qualquer conhecimento prévio, tal como é realizado por um identificador de serviço. A procura é realizada através da execução de uma consulta (query) e a sua base é dependente da descrição do serviço, por exemplo, as saídas e o tipo do serviço e geolocalização.

• Pesquisa. Permite ao usuário acessar a descrição do serviço tendo conhecimento prévio sobre o identificador do serviço.

• Resolução. Determina os identificadores de serviço através dos quais o usuário pode contatar o serviço. A função de resolução reduz a quantidade de informações que devem ser comunicadas, especialmente se a descrição do serviço é grande e as informações contidas não são necessárias.

• Gerenciamento de descrição de serviços. Permite atualizar, incluir ou excluir descrição de serviços.

3.3.2.1.5. Comunicação O GF de Comunicação é uma abstração que modela a variedade de esquemas de interação derivados das diferentes tecnologias pertencentes a sistemas IoT e fornece



uma interface comum para o GF Serviço IoT. Este GF consiste de três CFs, (i) Salto-a-Salto (Hop-to-Hop); (ii) Fim-a-Fim (End-to-End) e (iii) Rede. O CF Salto-a-Salto fornece a primeira camada de abstração da tecnologia de comunicação dos dispositivos físicos, a qual permite o uso e a configuração de qualquer tecnologia da camada de enlace. A principal função desse CF é transmitir quadros (frames) do CF Rede e de dispositivos para o CF Salto-a-Salto. Os argumentos para a transmissão do quadro podem ser definidos e incluem, por exemplo, confiabilidade, integridade, criptografia e controle de acesso. Além disso, ele é responsável pelo roteamento do quadro. Finalmente, esse CF permite gerenciar a fila do quadro e definir o tamanho e prioridade das filas de entrada e saída de quadros. Essa função pode ser aproveitada para atender requisitos de Qualidade de Serviço (QoS). O CF Rede permite a comunicação entre redes através de localizadores (endereçamento) e resolução de identificadores (IDs). Esse CF tem como função principal transmitir um pacote do CF Salto-a-Salto e do CF Fim-a-Fim para o próprio CF. Os argumentos para transmissão do pacote podem ser configurados e incluem, por exemplo, confiabilidade, integridade, criptografia, endereçamento unicast/multicast e controle de acesso. Mais ainda, esse CF inclui função de roteamento, que permite relacionar espaços de endereços de redes diferentes e diferentes tecnologias de rede, as quais podem ser convergidas através da tradução de protocolos de rede, por exemplo, de IPv4 para IPv6. Outra função é permitir a obtenção de um localizador a partir de um determinado ID, o que pode ser realizado internamente com base em uma tabela de pesquisa (lookup) ou de forma externa através de um framework. Finalmente, esse CF pode gerenciar filas de pacote e configurar o tamanho e prioridades das filas de entrada e saída de pacotes. Essa função pode ser aproveitada para atender requisitos de QoS. O CF Fim-a-Fim é responsável por toda a abstração de comunicação fim-a-fim, envolvendo confiabilidade da transferência, transporte e funcionalidades de tradução, suporte a proxies/gateways e ajustes de parâmetros de configuração quando a comunicação cruza diferentes ambientes de redes. Esse componente é também responsável por transmitir uma mensagem do CF Rede e do Serviço IoT para o próprio CF. Os argumentos para mensagens podem ser configurados e incluem confiabilidade, integridade, criptografia, controle de acesso e multiplexação. Outras funções disponíveis são cache e proxy de mensagem, tradução de protocolos (que permite a tradução entre diferentes protocolos de comunicação fim-a-fim (e.g., HTTP/TCP para COAP/UDP). Uma última função é passar o contexto de protocolos de tradução entre gateways. O contexto pode estar relacionado com endereçamento, métodos específicos para um protocolo RESTful e credenciais de segurança.

3.3.2.1.6. Segurança O GF Segurança é responsável por garantir a segurança e privacidade dos sistemas compatíveis com a IoT-A. Ele consiste de cinco CFs: (i) Autorização; (ii) Autenticação; (iii) Gerenciamento de Identidade; (iv) Gerenciamento de Troca de Chave, e; (v) Reputação e Confiança. O CF Autorização é um front-end para gerenciar políticas de controle de acesso e executar decisões de controle de acesso baseadas nas políticas. Essa tomada de decisão pode ser invocada sempre que é requisitado o acesso a um recurso restrito, e.g., verificar se para um dado usuário é permitida a execução de uma pesquisa por um



recurso requisitado. Duas funcionalidades são oferecidas, a saber: (i) determinar se uma ação está autorizada ou não, com base na informação fornecida pela assertiva (informação que garante a ocorrência de uma autenticação de um cliente em um determinado momento utilizando um método particular de autenticação), na descrição do serviço e no tipo de ação, e (ii) gerenciar políticas, tal como adicionar, atualizar ou excluir uma política de acesso. O CF Autenticação é responsável pela autenticação de serviços e usuários, verificação de credenciais fornecidas por um usuário e, caso estas sejam válidas, devolução de uma assertiva como resultado, requerida para usar o cliente do serviço de IoT. Além de verificar a exatidão das credenciais fornecidas por um novo nó que se junta ao sistema, ele estabelece contextos seguros entre este nó e as várias entidades em seu ambiente local. As duas funcionalidades fornecidas são (i) autenticar um usuário baseado na credencial fornecida e (ii) verificar se uma assertiva fornecida por um usuário é valida ou inválida. O CF Gerenciamento de Identidade lida com questões de privacidade, emissão e gerenciamento de pseudônimos e informação extra para que componentes confiáveis possam operar (utilizar ou prover serviços) de forma anônima. Ele possui somente uma funcionalidade, que é criar uma identidade fictícia (identidade raiz, segunda identidade, pseudônimo ou identidade de grupo) junto com as credenciais de segurança relacionadas para usuários e serviços usarem durante o processo de autenticação. O CF Gerenciamento e Troca de Chave habilita comunicações seguras entre dois ou mais pares que inicialmente não se conhecem ou cuja interoperabilidade não esteja garantida, assegurando integridade e confidencialidade. Esse CF possui duas funcionalidades, (i) distribuir chaves de forma segura e (ii) registrar recursos de segurança. Por fim, o CF Reputação e Confiança coleta a pontuação de reputação de usuários e calcula os níveis de confiança do serviço. Esse CF possui duas funcionalidades: (i) requisição de informação de reputação, que é uma função invocada por uma determinada entidade remota para requisitar informações de reputação sobre outra entidade, e; (ii) fornecimento de informação de reputação, que é uma função invocada por uma determinada entidade remota para prover informação de reputação (recomendações ou feedback) sobre outra entidade.

3.3.2.1.7. Gerenciamento O GF Gerenciamento consiste de cinco CFs: (i) Configuração; (ii) Falha; (iii) Membro; (iv) Relatório; (v) Estado. O CF Configuração é responsável por realizar funções de inicialização da configuração do sistema, tais como coletar e armazenar as configurações dos demais CFs e dispositivos. Esse CF também é responsável por rastrear as mudanças de configuração e realizar planejamento para futuras extensões do sistema. O CF Falha tem como objetivo identificar, isolar, corrigir e registrar falhas que ocorrem no sistema de IoT. Para cada ocorrência de falha, uma notificação é enviada pelo CF correspondente para o CF de Falha, o qual reúne mais dados a fim de identificar a natureza e o grau do problema. Esse CF possui funções para tratar, monitorar e recuperar uma falha.



O CF Membro é responsável pelo gerenciamento de associações de membros do sistema IoT e informações importantes de qualquer entidade relevante (GF, CF, EV, serviço IoT, dispositivo, aplicações, usuário). Esse CF possui três funções principais: (i) monitoramento contínuo de membros; (ii) recuperação de membros, que permite recuperar membros do sistema obedecendo um determinado filtro e permite a subscrição para receber atualizações de entidades pertencentes a um determinado dono, e; (iii) atualização de membro, que permite atualizar metadados do membro no banco de dados de membros e registrar/cancelar o registro de metadados de membros no banco. O CF Relatório permite refinar as informações fornecidas por outros CFs do GF, gerando relatórios ou recuperando relatórios de um histórico. Por exemplo, dentre muitos objetivos de um sistema de relatório, pode-se determinar a eficiência do sistema atual através da coleta e análise de dados de desempenho. O CF Estado visa monitorar e fornecer os estados passado, presente e futuro do sistema IoT que são requeridos pelo CF Falha, possuindo como funções trocar ou aplicar um estado particular no sistema. Ele também permite verificar a consistência de comandos fornecidos para esta função, bem como verificar resultados previsíveis. Também monitora o estado, que é principalmente utilizada no modo de inscrição no qual se monitora o estado do sistema e se notifica os inscritos sobre mudanças de estados relevantes. Outras funções são prever o estado por um determinado tempo, recuperar o estado do sistema através de um histórico e realizar atualização de estado.

3.3.2.2. Visão da Informação Objetos inteligentes conectados à IoT têm como propósito principal a troca de informações entre eles e também com sistemas externos. Entretanto, a forma como definir, estruturar, armazenar, processar, gerenciar e trocar as informações é muito importante. Dessa forma, a Visão da Informação permite visualizar estruturas de informações estáticas e fluxo de informações dinâmicas. Essa visão possui enfoque na descrição, tratamento e ciclo de vida da informação, bem como no fluxo de informações através do sistema e os componentes envolvidos. Sendo assim, nas próximas seções fornecemos um ponto de vista somente da modelagem de Entidades Virtuais (EV).

3.3.2.2.1 Descrição da informação

Descrição de EVs EV é o conceito chave para qualquer sistema de IoT, no qual modelar a entidade física (objeto) é o ponto de interesse real. Uma EV tem um identificador, um tipo (entityType) e atributos que fornecem informação sobre a EV ou podem ser utilizados para trocar o seu estado, desencadeando um estímulo sobre a entidade física modelada. A modelagem do entityType é muito importante uma vez que este pode ser utilizado para determinar quais atributos uma instância de EV pode ter, definindo assim sua semântica. Um entityType pode ser modelado como um elemento simples, conforme pode-se observar na Figura 3.3, ou de forma hierárquica utilizando conceitos como herança de elementos, conforme apresentado na Figura 3.4.



Figura 3.3. Exemplo de um modelo simples de entityType.

Figura 3.4. Exemplo de um modelo hierárquico de entityType.

EntityTypes são similares a classes na programação orientada a objetos. Sendo assim, diagramas de classes UML (Unified Modeling Language)2, como o apresentado na Figura 3.3 e na Figura 3.4, podem ser utilizados para modelar EntityTypes. Em particular, a relação de generalização pode ser usada para modelar subclasses de entityTypes, conforme mostrado na Figura 3.4. Além da UML, linguagens de ontologias como a OWL (Web Ontology Language)3 podem ser usadas de maneira alternativa, já que fornecem meios para modelar classes e subclasses.

Descrições de serviços Serviços fornecem acesso a funções para recuperar informação ou executar tarefas de atuação nos dispositivos IoT e, portanto, precisam ser descritos apropriadamente. Essa tarefa é realizada através de descrições de serviços que contêm informações (tanto sintáticas quanto semânticas) sobre a interface do serviço. Por exemplo, informações de entrada, saídas, pré-condições necessárias e pós-condições. Além disso, a descrição do serviço pode incluir informação a respeito das, funcionalidades, ou sobre o dispositivo no qual o recurso está sendo executando (tais como sua plataforma de hardware ou sua localização geográfica, por exemplo). Apesar da existência de diferentes linguagens para realizar a descrição de um serviço, escolher uma linguagem para realizar essa tarefa não faz parte da definição da arquitetura de referência, e sim depende das escolhas realizadas durante o projeto.

2 Unified Modeling Language (UML): http://www.omg.org/spec/UML/2.4.1/ 3 Web Ontology Language (OWL): http://www.w3.org/2001/sw/wiki/OWL



Associações entre EV e serviços Serviços podem fornecer informações ou permitir atuação, mas porém eles podem não estar cientes de que tipos de informação uma EV pode fornecer ou qual o tipo de atuação ela permite, por exemplo. Esta informação pode ser então representada através de associações que relacionam uma EV a um serviço. Uma associação inclui o atributo da EV para que o serviço forneça a informação ou permita atuação como resultado de uma mudança de seu valor.

3.3.2.2.2. Manipulação da informação Em um sistema de IoT, informações são manipuladas por serviços para fornecer acesso a recursos dos dispositivos como, por exemplo, recursos de sensores que tornam informações sobre o mundo físico acessíveis em tempo real aos sistemas. Outros serviços podem ainda processar e agregar informações fornecidas por outros serviços/recursos de IoT, derivando assim outras informações de maior valor agregado. Além disso, essas informações, sejam elas coletadas por serviços IoT ou adicionadas diretamente pelos usuários, podem ser armazenadas em uma classe especial de serviço IoT, o Repositório de Histórico.

Serviços IoT são registrados em sistemas IoT usando descritores de serviços que podem ser fornecidos por eles mesmos, pelos usuários ou por componentes especiais de gerenciamento que desejam fazer o serviço visível e detectável dentro de um sistema de IoT. O CF Resolução de Serviços IoT (c.f. Seção 3.3.2.1.4) é responsável por gerenciar e fornecer acesso a descrições de serviços por meio de uma interface de descoberta baseada nas especificações do serviço providas pelo solicitante, em termos de seu identificador ou localizador de serviço. Além disso, associações podem ser registradas através do CF Resolução de EV (c.f. Seção 3.3.2.1.3) por serviços que sabem para qual EV eles podem fornecer informação. O registro pode ser realizado pelos usuários ou por componentes especiais de gerenciamento.

3.3.2.2.3 Manipulação da informação por CFs Esta subseção descreve como a informação é tratada e exposta por CFs em um sistema de IoT e apresenta o fluxo de informação entre eles (Figura 3.5). Nesse exemplo, a partir do dispositivo no nível atuador, a informação de temperatura é transferida para o serviço IoT e depois para o serviço EV. Finalmente, a partir do serviço de EV, o valor da temperatura é transferido para o aplicativo Android utilizando o padrão subscrição/notificação (subscribe/notify).



Figura 3.5. Exemplo de um fluxo de informação.

3.3.2.2.4 Ciclo de vida da informação As informações fornecidas por recursos de um sensor são de natureza transiente e não podem ser medidas ou observadas sem uma requisição específica. A informação armazenada por um recurso de armazenamento pode ser permanentemente armazenada ou ter uma data de expiração na qual ela deve ser removida. Além disso, é possível adaptar a granularidade das informações armazenadas ao longo do tempo para que somente partes delas sejam mantidas e outras descartadas. A fim de evitar a manutenção de descrições para um serviço que não existe mais, um mecanismo de expiração de tempo (timeout) precisa ser desenvolvido na resolução de serviço de IoT. Após a expiração de tempo ser alcançada, a descrição do serviço deve automaticamente ser removida. Isso requer que os componentes que fornecem a descrição do serviço renovem o seu registro antes do tempo de expiração ser alcançado. O mesmo se aplica para associações armazenadas pelo CF Resolução de EV.

3.3.2.3. Visão de Operação e Implantação Objetos inteligentes conectados na IoT podem ser realizados de muitas formas e podem se comunicar usando diferentes tecnologias. Além disso, diferentes sistemas podem precisar de comunicação compatível entre eles. Por isso, a Visão de Operação e Implantação é muito importante para tratar como sistemas atuais podem ser realizados pela seleção de tecnologias e fazê-los se comunicarem e operarem de uma forma abrangente, isto é, para alcançarem o maior número de sistemas.

O objetivo da Visão de Operação e Implantação é fornecer a usuários do MAR um conjunto de orientações para guia-los através de diferentes escolhas de projeto enquanto realizam as implementações reais de seus serviços. Todavia, uma completa análise de todas as possibilidades tecnológicas e suas combinações vai além do escopo desta visão, que identificará aquelas categorias que têm grande impacto na realização de sistemas de IoT. Em particular, iniciando a partir do Modelo de Domínio de IoT,



existem três grupos de elementos principais, mostrados na Figura 3.6: Dispositivos, Recursos, e Serviços. Cada um deles possui um problema diferente de implantação, que, por sua vez, se reflete nas capacidades operacionais do sistema.

Figura 3.6. Elementos do modelo de domínio agrupados de acordo com seus aspectos comuns de implantação [Bassi et al. 2013, p. 17].

Os pontos de vista utilizados nesta visão são:

• O Diagrama de Modelo de Domínio de IoT, que é utilizado como uma diretriz para descrever uma aplicação específica de domínio. Dessa forma, diagramas da UML podem ser utilizados para detalhar ainda mais a interação entre os muitos elementos que compõem a aplicação alvo.

• O Modelo Funcional, que é utilizado como uma referência para a definição do sistema. Em particular, define-se grupos funcionais tais como serviços de IoT e grupos de conectividade, que são fundamentais para uma definição correta do sistema.

• Diagramas de Conectividade de Rede, que podem ser utilizados para planejar a topologia de conectividade para habilitar as capacidades de rede desejadas da aplicação alvo. No nível de implantação, o Digrama de Conectividade de Rede será utilizado para definir as hierarquias e o tipo de sub-redes compondo o sistema de rede completo.



• Descrições de Dispositivos, tais como planilhas e manuais de usuário, que podem ser utilizados para mapear o hardware real sobre os serviços e recursos requeridos do sistema alvo.

Dispositivos em sistemas de IoT incluem todo o espectro de tecnologias, variando da mais simples etiqueta de radiofrequência (RFIC) aos mais complexos servidores. As características unificadas são principalmente duas: por um lado, cada dispositivo é conectado com outro formando uma parte da IoT; por outro lado, cada dispositivo é “inteligente”, mesmo com diferentes graus de complexidade. Essas duas características são assuntos da primeira escolha que o projetista do sistema tem de fazer. É importante notar que, para um dado dispositivo ser totalmente interoperável em um sistema em conformidade com a IoT-A, ele deve respeitar as definições funcionais do Modelo Funcional. Portanto, sistemas legados que não suportam totalmente tal Modelo Funcional podem implementar empacotadores (wrappers) e fazerem adaptações de software para tornarem-se compatíveis com o modelo.

Selecionar a complexidade computacional para um dado dispositivo é algo intrínseco para a aplicação alvo. Porém, escolher entre os diferentes tipos de conectividade não é tão simples, pois diferentes escolhas podem fornecer vantagens comparáveis. Pelo mesmo motivo, é possível perceber diferentes sistemas implementando a mesma ou diferentes aplicações a partir da Visão Funcional e que são extremamente diferentes da Visão de Operação e Implantação. Como uma consequência da coexistência de diferentes tecnologias de comunicação no mesmo sistema, a segunda escolha que o projetista do sistema deve considerar está relacionada aos protocolos de comunicação. Em particular, funcionalidades de conectividade para sistemas IoT são definidas na GF de Comunicação (c.f. Seção 3.3.2.1.5). Além disso, para melhor entender a aplicação, é importante descreve-la usando a Visão Funcional. Embora o MAR do IoT-A sugira um conjunto de protocolos de comunicação visando a interoperabilidade entre diferentes tecnologias utilizando o IP como denominador comum, o projetista do sistema pode ser forçado a fazer escolhas de baixa qualidade. Em particular, são identificadas as seguintes possibilidades:

• Conjunto de protocolos padronizados para IoT. Esta é a principal direção indicada pelo projeto IoT-A e fornece a melhor solução para interoperabilidade.

• Soluções ad-hoc proprietárias. Sempre que os requisitos de desempenho da aplicação forem mais importantes que a versatilidade do sistema, soluções ad-hoc podem ser a única direção a seguir.

• Outros padrões. Dependendo do domínio da aplicação alvo, podem existir regulações forçando o projetista do sistema a adotar padrões diferentes daqueles sugeridos pelo conjunto de protocolos de IoT por questões de compatibilidade e continuidade.

Depois de selecionados os dispositivos e seus métodos de comunicação, o projetista do sistema deve analisar os serviços e recursos, tal como definido na Seção 3.3.2.1.4 que descreve o GF Serviço de IoT. Tanto no caso de recursos e quanto para serviços, o ponto chave é escolher onde implantar o software relacionado com um dado dispositivo. As opções são as seguintes:



• Objetos inteligentes. Esta escolha aplica-se à definição de recursos e serviços leves tais como serviços Web que podem ser realizados em algumas dezenas ou centenas de bytes, por exemplo.

• Gateways. Sempre que os dispositivos alvo não são poderosos o suficiente para eles mesmos executarem o software, gateways ou outros dispositivos mais poderosos devem ser implantados para auxiliar dispositivos com menores capacidades.

• Nuvens computacionais. Um sistema IoT pode também ser implantado em nuvens computacionais. Apesar de esta solução aumentar a disponibilidade dos serviços, ela pode diminuir o desempenho em termos de latência e taxa de transferência.

Deve-se notar que tal escolha tem de ser feita pelo tipo do recurso e serviço e depende do dispositivo relacionado. Por exemplo, um sensor de temperatura pode ser implantado em um dispositivo sem fio restrito, capaz de hospedar os recursos de temperatura com um serviço simples para fornecê-lo. Contudo, se um serviço mais complexo for necessário, o software tem que ser implantado em um dispositivo com maiores capacidades computacionais.

Na mesma linha, é importante selecionar onde armazenar a informação coletada pelo sistema. Em tal escolha, um projetista deve levar em consideração a sensibilidade (por exemplo, se o software é capaz ou não de executar a segurança do framework), a necessidade de disponibilidade dos dados e o grau de redundância necessária à resiliência de dados. As opções previstas são as seguintes:

• Somente local. O dado é armazenado somente no dispositivo que o produziu. Neste caso, a localidade dos dados é imposta e o sistema não requer um complexo banco de dados distribuído. Todavia, dependendo da localização de uma requisição, a resposta pode levar muito tempo para ser entregue e, no pior cenário, pode ser perdida.

• Somente Web. Nenhuma cópia local é mantida pelo dispositivo, de modo que tão logo os dados sejam enviados para o servidor, eles são armazenados em banco de dados.

• Local com cache Web. Uma estrutura hierárquica para armazenar dados é mantida a partir dos dispositivos até os servidores de banco de dados.

Finalmente, uma das características principais de sistemas de IoT é a resolução de serviços e entidades, o que é fornecido pelos CFs Resolução de Serviço e Entidade, respectivamente. Esta escolha tem somente duas opções, que são:

• Implantação interna. O modulo principal do CF é instalado nos servidores pertencentes ao sistema e é dedicado para a aplicação alvo ou compartilhado entre diferentes aplicações do mesmo provedor.

• Uso externo. O motor principal é fornecido por terceiros e o projetista deve construir APIs de acesso a esse serviço.

Diferentemente de outras escolhas, esta é dirigida pelo custo associado para a manutenção do módulo principal do sistema. Uma vez que ele é um componente crítico



do sistema, segurança, disponibilidade e robustez devem ser assegurados. Portanto, para pequenas empresas, a solução mais fácil é a de uso externo.

3.3.2.4. Perspectivas O MAR do IoT-A propõe as seguintes perspectivas para sistemas de IoT: (i) evolução e interoperabilidade, (ii) disponibilidade e resiliência, (iii) confiança, segurança e privacidade, e (iv) desempenho e escalabilidade. Para descrever as perspectivas, segue-se uma estrutura sugerida por Rozanski e Wood (2011) apud Bassi et al. (2013), porém ajustada de acordo com as necessidades do ambiente IoT. Cada perspectiva contém as seguintes informações:

• Qualidade desejada. A propriedade de qualidade que a perspectiva está tratando, por exemplo, desempenho, segurança ou escalabilidade.

• Requisitos4. Os requisitos de IoT que a perspectiva trata.

• Aplicabilidade. Aplicabilidade da perspectiva, isto é, os tipos de sistemas aos quais a perspectiva é aplicada.

• Atividades. Um conjunto de atividades possíveis que são sugeridas para atingir a qualidade desejada.

• Tática. Lista de táticas arquiteturais que um arquiteto pode usar quando projeta um sistema. Uma tática arquitetural é uma decisão de projeto para realizar objetivos de qualidade no nível arquitetural.

3.3.3. WSO2 Como abordado nas seções anteriores, a grande variedade de requisitos e dispositivos a serem suportados na IoT tem como resultado uma arquitetura que não é simples de conceber e lidar. Entretanto, uma arquitetura modular e escalável que permita adicionar e remover capacidades, bem como dar suporte a uma vasta quantidade de requisitos, é útil e valiosa. Nesse contexto, esta seção aborda a arquitetura de referência de IoT proposta pela WSO2 [Fremantle 2014]. Essa arquitetura inclui os dispositivos bem as arquiteturas do lado servidor e arquiteturas de nuvem necessária para interagir com e gerenciar os dispositivos. O objetivo é fornecer aos arquitetos e desenvolvedores um ponto de partida eficaz que contemple a maior parte dos requisitos de sistemas e projetos envolvendo IoT. Contudo, não é o foco desta seção detalhar o funcionamento de uma arquitetura em particular de hardware cliente/servidor e/ou computação em nuvem, uma vez que essa proposta de arquitetura de referência é independente de fornecedor e não é específica para um conjunto de tecnologias.

A arquitetura de referência da WSO2, ilustrada na Figura 3.7, consiste de um conjunto de camadas no qual cada camada executa uma determinada função claramente definida. As camadas previstas são: (i) comunicações externas; (ii) processamento de eventos e análises; (iii) camada de agregação/barramento; (iv) comunicações entre dispositivos, e; (v) camada de dispositivos. Há também duas camadas transversais/verticais, que são (i) gerenciamento de dispositivo e (ii) gerenciamento de acesso e identidade. Cada uma dessas camadas pode ser instanciada utilizando 4 Uma lista com tais requisitos pode ser encontrada em:

http://www.iot-a.eu/public/public-documents/d6.2-updated-requirements-list.



tecnologias específicas. A seguir, são discutidas opções para a implementação de cada uma delas.

3.3.3.1. Camada de Dispositivos A camada mais inferior da arquitetura é a Camada de Dispositivos (Devices). Os dispositivos podem ser de diversos tipos, mas para que sejam considerados dispositivos de IoT, eles devem ter alguma comunicação com a Internet, seja de forma direta ou indireta. Conexões diretas são aquelas em que os dispositivos possuem em seu hardware um componente para conexão nativa com a Internet, enquanto conexões indiretas requerem dispositivos auxiliares para estabelecerem uma conexão com a Internet. Como exemplos de dispositivos com conexões diretas, pode-se citar: (i) Arduino, com conexão Ethernet; (ii) Arduino Yun, com conexão WiFi; (iii) Raspberry Pi, que pode ser conectado via Ethernet ou WiFi, e; (iv) Intel Galileo, que também pode ser conectado via Ethernet ou WiFi. Como conexões indiretas, pode-se citar: (i) dispositivos ZigBee conectados através de um gateway ZigBee; (ii) dispositivos Bluetooth ou Bluetooth de baixa potência conectados via telefone celular, e; (iii) dispositivos de comunicação via rádio de baixa potência para um Raspberry Pi.

Figura 3.7. Arquitetura de referência para IoT da WSO2 [Fremantle 2014, p.9].

Além da capacidade de conexão, o dispositivo necessita de uma identidade única, que pode ser: (i) um identificador único (UUID) gravado permanentemente dentro do dispositivo; (ii) UUID provido por um subsistema rádio, por exemplo, identificador Bluetooth ou endereço MAC WiFi; (iii) OAuth25 Refresh/Bearer Token, que pode ser utilizado de maneira adicional a um dos dois anteriores, e; (iv) identificador armazenado em uma memória não-volátil tal como uma EEPROM. Para esta arquitetura de referência, recomenda-se que cada dispositivo possua um UUID, de preferência um ID fixo, não modificável e provido por hardware, bem como um OAuth2 Refresh/Bearer Token armazenado em memória EEPROM. O objetivo do OAuth2 token é prover um token de identidade segura separado do núcleo imutável de identidade de cada dispositivo. Por sua vez, o Bearer Token é utilizado inicialmente e passado para qualquer servidor ou serviço que precisa de identificação, porém ele possui um tempo de vida menor que o Refresh Token. Se o Bearer Token expirar, o

5 OAuth: http://oauth.net/



Refresh Token é passado para a Camada de Identificação, e esta cria um Bearer Token atualizado. Apesar de especificação ser baseada sobre o protocolo HTTP (Hypertext Transfer Protocol)6, a arquitetura de referência também provê suporte a esses fluxos utilizando o protocolo MQTT (Message Queue Telemetry Transport)7.

3.3.3.2. Camada de Comunicações A Camada de Comunicações (Communications) suporta a conectividade dos dispositivos. Há muitos protocolos potenciais para a comunicação entre os dispositivos e arquitetura de rede. Os três protocolos mais conhecidos são: (i) HTTP e seu uso sobre o estilo arquitetural REST [Fielding 2000]; (ii) MQTT, e; (iii) CoAP (Constrained Application Protocol)8.

O protocolo de aplicação HTTP é bem conhecido e existem muitas bibliotecas que o implementam. É um protocolo baseado em texto e mesmo pequenos dispositivos, como os controladores de 8 bits, podem suporta-lo parcialmente, por exemplo, implementando código suficiente para realizar operações POST ou GET sobre um recurso. Os dispositivos baseados em 32 bits podem utilizar bibliotecas clientes com suporte total ao HTTP que implementam apropriadamente o protocolo inteiro.

Há muitos protocolos otimizados para uso em IoT, sendo que os dois mais conhecidos são o MQTT e CoAP. O MQTT é um sistema de publicação-subscrição de mensagens baseado em um modelo de broker e projetado para fluxos sobre TCP. O protocolo tem uma baixa sobrecarga (overhead em torno de 2 bytes por mensagem) e foi projetado para suportar redes com perdas e intermitentemente conectadas. Além disso, há uma especificação projetada para uso em redes de sensores estilo Zigbee chamada MQTT-SN. Por sua vez, o CoAP é um protocolo de camada de aplicação projetado para prover uma solução RESTful (i.e., baseada no estilo arquitetural REST – REpresentational State Transfer) [Fielding 2000] e, portanto, modelado seguindo a semântica HTTP, porém bem mais enxuto e com uma abordagem binária em vez de baseada em texto. O CoAP adota uma abordagem tradicional estilo cliente-servidor em vez de uma abordagem de brokers e foi projetado para ser utilizado sobre UDP (User Datagram Protocol)9.

Para a arquitetura de referência da WSO2, optou-se por selecionar o MQTT como protocolo preferencialmente usado na Camada de Comunicação e o HTTP como uma opção alternativa. As razões para selecionar o MQTT em detrimento do CoAP são: (i) maior adoção; (ii) biblioteca de suporte mais ampla; (iii) uma ponte simplificada para a coleta de eventos existentes e sistemas de processamento de eventos, e; (iv) conexão simples sobre firewalls e redes NAT. Embora ambos os protocolos tenham suas vantagens e desvantagens específicas, haverá situações nas quais o CoAP pode ser preferível e poderá ser utilizado. Entretanto, para ter suporte ao protocolo MQTT, é necessário ter um broker MQTT na arquitetura, bem como bibliotecas de dispositivos.

Um importante aspecto com dispositivos IoT não está relacionado somente ao o fato de o dispositivo enviar dados para o servidor/nuvem, mas também com a comunicação na direção oposta. Isso é um dos benefícios da especificação MQTT: 6 Hypertext Transfer Protocol – HTTP/1.1: http://www.w3.org/Protocols/rfc2616/rfc2616.html 7 Message Queue Telemetry Transport: http://mqtt.org/ 8 Constrained Application Protocol: http://tools.ietf.org/html/draft-ietf-core-coap-18 9 User Datagram Protocol – UDP: http://tools.ietf.org/html/rfc768



como este é um modelo de broker, clientes conectam com uma conexão de saída para o broker, quer o dispositivo esteja ou não atuando como um publicador (Publisher) ou como assinante (subscriber). Isso usualmente evita problemas com firewall porque esta abordagem funciona até mesmo atrás de firewalls ou via NAT. No caso de a comunicação principal ser baseada em HTTP, a abordagem tradicional de envio de dados para o dispositivo seria usar HTTP Polling, porém, tal abordagem é muito ineficiente e custosa, tanto em termos de tráfego de rede como em requisitos de energia. O substituto moderno para isso é o protocolo WebSocket10, que permite uma conexão HTTP ser atualizada em uma conexão totalmente bidirecional. Tal conexão atua então como um socket channel (similar a um canal TCP puro) entre o servidor e o cliente. Uma vez que tenha sido estabelecida, cabe ao sistema escolher um protocolo em andamento para o túnel de conexão. Para a arquitetura de referência da WSO2, novamente recomenda-se o uso de MQTT como um protocolo com WebSockets. É ainda importante observar que apesar de existir algum suporte para WebSocket sobre pequenos controladores (a exemplo do Arduino11), a combinação de código de rede, HTTP e WebSockets utilizaria a maior parte do espaço de código disponível sobre um típico dispositivo Arduino 8 bits. Portanto, o uso de WebSockets é recomendado somente sobre dispositivos de 32 bits ou maiores.

3.3.3.3. A Camada de Agregação/Barramento Uma importante camada da arquitetura de referência é a Camada de Agregação/Barramento (Aggregation/Bus Layer), que agrega e gerencia as conexões. Essa camada é importante por três motivos principais: (i) capacidade para suportar um servidor HTTP e/ou um broker MQTT para comunicação com os dispositivos; (ii) capacidade para agregar e combinar comunicações de diferentes dispositivos e rotear as comunicações para um dispositivo específico, possivelmente via um gateway, e; (iii) capacidade para realizar mapeamentos e conversões entre diferentes protocolos, e.g., para oferecer APIs baseadas em HTTP mediadas em uma mensagem MQTT indo para o dispositivo. Finalmente, esta camada precisa executar dois papéis chaves de segurança: ela deve ser capaz de atuar com um servidor de recursos OAuth2 (validando Bearer Tokens e escopos de acesso a recursos associados), bem como ser capaz de atuar como um ponto de aplicação de políticas (PEP) para acessos baseados em políticas. A camada de gerenciamento de acessos e identidade atua como um ponto de decisões políticas (PDP) neste processo. A camada de barramento implementa então os resultados dessas chamadas para o PDP a fim de permitir ou negar acesso a recursos.

3.3.3.4. Camada de Processamento de Eventos e Análise A Camada de Processamento de Eventos e Análise (Event Processing and Analytics) obtém os eventos do barramento e provê capacidades para processar e agir sobre estes eventos. Uma capacidade principal dessa camada consiste em armazenar o dado em de um banco de dados, o que pode ocorrer de três formas. O modelo tradicional seria escrever uma aplicação do lado servidor, a exemplo de uma aplicação RESTful apoiada por um banco de dados. Entretanto, existem abordagens mais ágeis. A primeira é usar uma plataforma analítica de Big Data [Chen et al. 2014] que consiste em uma

10 The WebSocket Protocol: http://tools.ietf.org/html/rfc6455 11 Arduino: http://arduino.cc/



plataforma de nuvem escalável com suporte a tecnologias como Apache Hadoop12 para prover análises baseadas em map-reduce sobre os dados provenientes dos dispositivos. A segunda abordagem é suportar processamento de eventos complexos para executar atividades de forma próxima a tempo real e ações baseadas nos dados dos dispositivos e do resto do sistema. A recomendação seria então fazer uso das seguintes abordagens: (i) armazenamento de dados altamente escalável para armazenar eventos; (ii) map-reduce para execução em batch (de longa duração) de processamento de dados, ou; (iii) processamento de eventos complexos para rápido processamento em memória e próxima a tempo real e ações autonômicas baseadas nos dados e atividades de dispositivos e outros sistemas. Além disso, a camada pode suportar plataformas de processamento de aplicações tradicionais tais como JavaBeans13, beans dirigidos a mensagem, ou alternativas como node.js, PHP, Ruby ou Python.

3.3.3.5. Camada de Comunicações Externas A arquitetura de referência precisa prover um modo que possibilite o sistema de IoT comunicar-se com o meio externo e vice-versa. Isto pode incluir três abordagens principais: (i) capacidade de criar páginas e portais Web (Web portals) que interajam com dispositivos e com a camada de processamento de eventos; (ii) capacidade de criar painéis de monitoramento (Dashboards) que ofereçam visões para análise e processamento de eventos, e; (iii) capacidade de interagir com sistemas fora dessa rede usando comunicações máquina-a-máquina (APIs). A abordagem recomendada para construir um front-end Web é utilizar uma arquitetura modular tal como um portal que permite compor interfaces de usuário de forma rápida e simples. Certamente a arquitetura também suporta tecnologias Web existentes do lado servidor como Java Servelets/JSP, Php, Python, Ruby, etc. A abordagem recomendada é baseada no arcabouço Java e no mais popular servidor web baseado em Java, o Apache Tomcat. O dashboard é um sistema reutilizável focado na criação de gráficos e outras visualizações de dados vindos dos dispositivos e da camada de processamento de eventos.

A Camada de Gerenciamento de API (API Management) provê três funções principais: (i) um portal focado no desenvolvedor (de forma antagônica ao portal focado no usuário) através do qual desenvolvedores podem encontrar, explorar e utilizar APIs do sistema; (ii) um gateway que gerencia o acesso às APIs, executando a verificação do controle de acesso (para requisições externas) e otimizando o uso baseado nas políticas definidas, além de executar funções de roteamento e balanceamento de carga, e; (iii) um gateway que publique os dados na camada de análise, onde são armazenados e processados para fornecer visões sobre como as APIs são utilizadas.

3.3.3.6. Gerenciamento de Dispositivos O gerenciamento de dispositivos é endereçado por dois componentes, (i) Gerente de Dispositivo (GD) e, (ii) Agente de Gerenciamento de Dispositivo (AGD). O GD é um sistema do lado servidor que comunica-se com os dispositivos através de vários protocolos e provê controle tanto individual como em massa de dispositivos. Ele também gerencia remotamente o software e a implantação de aplicações no dispositivo e pode bloquear e/ou limpar o dispositivo se necessário. O AGD é um conjunto de

12 Apache Hadoop: http://hadoop.apache.org/ 13 JavaBeans: http://en.wikipedia.org/wiki/JavaBeans



componentes genérico que fornece gerenciamento de dispositivos e utilitários como: (i) adaptadores de comunicação para HTTP e MQTT, (ii) inscrição de dispositivos, (iii) gerenciamento de token e, (iv) tipo de plataforma para gerenciar.

O GD trabalha em conjunto com o AGD e há muitos diferentes agentes para diferentes tipos de plataformas e dispositivos. O GD também precisa manter a lista de identidade dos dispositivos e mapeá-los para os respectivos proprietários. Ele também deve trabalhar com a Camada de Gerenciamento de Acesso e Identidade para gerenciar o controle de acesso sobre os dispositivos.

Há três níveis de dispositivos, a saber, (i) não-gerenciados, (ii) semigerenciados, e (iii) totalmente gerenciados. Os dispositivos totalmente gerenciados são aqueles que executam o agente completo de Gerenciamento de Dispositivos (GD). O agente GD oferece suporte a gerenciar o software instalado, habilitar/desabilitar funções dos dispositivos, gerenciar controles de segurança e identificadores, monitorar a disponibilidade do dispositivo, manter um registro da localização do dispositivo, se disponível, bloquear ou limpar o dispositivo remotamente se ele estiver comprometido, entre outros. Dispositivos não-gerenciados podem se comunicar com o resto da rede, mas não há agente envolvido. Dispositivos semigerenciados são aqueles que implementam algumas partes do GD, por exemplo, tais como o controle de características, mas não o gerenciamento de software.

3.3.3.7. Gerenciamento de Identidade e Acesso A última camada é a de Gerenciamento de Identidade e Acesso (Identity and Access Management). Ela precisa fornecer os seguintes serviços: (i) emissão e validação de token OAuth2; (ii) outros serviços de identidade incluindo suporte a SAML2 SSO14 e OpenID Connect15 para identificar requisições de entrada da camada Web; (iii) XACML PDP16; (iv) diretório de usuários, e; (v) gerenciamento de políticas para controle de acesso. Esta camada pode ainda ter outros requisitos específicos para cada gerenciador de acesso e identidade para uma dada instanciação da arquitetura de referência.

3.4. Plataformas de Middleware para IoT Como citado anteriormente, o paradigma de IoT ainda possui diversos desafios em aberto que requerem soluções em nível de hardware e de software. Em particular, faz-se necessária uma camada de software que forneça abstrações para dispositivos e aplicações, diversos níveis de transparência e interoperabilidade, bem como múltiplos serviços para usuários finais e aplicações. Essa camada de software, denominada middleware, oculta dos desenvolvedores de aplicações as complexidades e heterogeneidades referentes ao hardware subjacente, às camadas de protocolos de rede, às plataformas e dependências do sistema operacional, além de facilitar o gerenciamento de recursos do sistema e aumentar a previsibilidade da execução de aplicações [Bernstein 1996].

14 Security Assertion Markup Language (SAML2): https://saml2.codeplex.com/ 15 OpenID: http://openid.net/ 16 Extensible Access Control Markup Language (XACML):

https://www.oasis-open.org/committees/xacml/



No contexto de IoT, uma plataforma de middleware representa um artefato de software residindo entre a camada de aplicação e a infraestrutura de suporte (comunicação, processamento, sensoriamento), fornecendo acesso padronizado aos dados e serviços providos pelos objetos inteligentes através de interfaces de alto nível, além de promover o reuso de serviços genéricos, que podem ser compostos e configurados para facilitar o desenvolvimento de aplicações de forma mais eficiente para o ambiente de IoT. O desenvolvimento de plataformas de middleware para IoT tem atraído cada vez mais a atenção da comunidade acadêmica e da indústria. Por conta disso, diversas pesquisas já foram reportadas na literatura visando a concepção e a implementação de plataformas de middleware abordando os requisitos mencionados anteriormente. As subseções a seguir apresentam algumas propostas de plataformas de middleware para IoT e como tais plataformas procuram atender aos requisitos levantados na Seção 3.2.

3.4.1 EcoDiF A EcoDiF (Ecossistema Web de Dispositivos Físicos) é uma proposta de solução a alguns dos desafios para a materialização do paradigma de IoT, tais como: (i) a necessidade de uma camada de abstração sobre dispositivos e serviços a aplicações e usuários finais; (ii) o fornecimento de serviços de busca e descoberta desses elementos; (iii) a interconexão de objetos e serviços via rede; (iv) o monitoramento do estado e da localização dos objetos conectados, e; (v) o gerenciamento da interoperabilidade entre os objetos envolvidos [Delicato et al. 2013b]. Dessa forma, a EcoDiF integra dispositivos físicos heterogêneos e os conecta à Internet, fornecendo funcionalidades de controle, visualização, processamento e armazenamento de dados em tempo real. A plataforma alinha-se com o paradigma de Web das Coisas (Web of Things – WoT, em Inglês) ao utilizar tecnologias e protocolos da Web, como o protocolo HTTP e URIs (Uniform Resource Identifier) [Guinard e Trifa 2009]. Dessa forma, a EcoDiF possibilita a inclusão de dispositivos físicos no meio digital de modo que seus dados e serviços sejam utilizados em diferentes aplicações como qualquer recurso da Web, alavancando assim a concretização da visão da IoT [Delicato et al. 2013a]. A EcoDiF foi projetada tendo como base princípios REST [Fielding 2000], utilizando assim o HTTP como mecanismo padrão de suporte a todas as interações entre os objetos endereçáveis através de suas principais operações (GET, PUT, POST, DELETE). Dessa forma, a plataforma provê uma interface bem definida para expor as funcionalidades dos objetos na Web, provendo a padronização e a simplificação do processo de desenvolvimento de aplicações, além de minimizar barreiras no tocante à incompatibilidade entre diferentes fabricantes, protocolos proprietários e formatos de dados [Pautasso et al. 2008]. Desse modo, a plataforma soluciona parte das questões de interoperabilidade de dispositivos, requisito essencial para plataformas de middleware no contexto do paradigma de IoT, e consolida a integração de dispositivos físicos heterogêneos. Assim, a EcoDiF é capaz de oferecer um acesso unificado a dados e serviços providos por dispositivos integrados através de interfaces de alto nível, bem como contribuir para tornar mais fácil o desenvolvimento de aplicações em ambientes de IoT altamente distribuídos e heterogêneos. A arquitetura lógica da plataforma é composta de diversos módulos, ilustrados na Figura 3.8 e apresentados a seguir.



Figura 3.8. Arquitetura da EcoDiF.

O Módulo de Conexão de Dispositivos visa facilitar a conexão de dispositivos físicos à IoT, de acordo com a API da EcoDiF e fazendo uso de drivers customizados, desenvolvidos para cada tipo específico de plataforma de dispositivo. Esses drivers desempenham um papel de suma importância em relação à integração de dispositivos com a EcoDiF visto que a heterogeneidade de tais dispositivos é abstraída dos usuários e aplicações que fazem uso dos dados providos por eles. Os drivers da EcoDiF são construídos com base em princípios REST e padrões e protocolos da Web. Com isso, o HTTP não é utilizado apenas como protocolo de comunicação, mas também para oferecer suporte a todas as interações com os dispositivos interconectados, que são visualizados como recursos Web. Além disso, o uso do HTTP elimina barreiras no tocante à incompatibilidade entre diferentes fabricantes, protocolos proprietários e formatos de dados [Pautasso et al. 2008]. Na EcoDiF existem dois tipos de drivers, ativos e passivos. Drivers ativos obtêm os dados coletados por dispositivos fazendo requisições periódicas à API do dispositivo mesmo se os valores dos dados permanecem inalterados. Por sua vez, drivers passivos (ou baseados em eventos) aguardam por notificações da API do dispositivo, notificações essas disparadas sempre que há mudanças nos valores dos dados. Após obter dados dos dispositivos (os chamados feeds), os drivers estruturam tais dados utilizando a linguagem EEML (Extended Environments Markup Language)17, usada para descrever dados obtidos por dispositivos em um dado contexto (ambiente). EEML é baseada na linguagem XML (eXtended Markup Language), padrão para representação de informações na Web, permitindo que dados obtidos por dispositivos sejam representados de modo simples e estruturada. Após a sua representação em EEML, tais dados são enviados à EcoDiF através de requisições HTTP PUT a fim de serem registrados na plataforma pelo Módulo de Manipulação de Dados. O Módulo de Visualização e Gerenciamento provê uma interface Web para permitir que usuários gerenciem os dispositivos conectados à EcoDiF. Através dessa

17 Extended Environments Markup Language (EEML): http://www.eeml.org/



interface, usuários podem monitorar o estado e localização de seus dispositivos, bem como visualizar dados históricos armazenados na plataforma. Além disso, os usuários podem criar triggers, que são mecanismos baseados em eventos para enviar notificações com base em condições predefinidas com relação aos valores atuais dos feeds. Por sua vez, o Módulo de Colaboração visa facilitar a colaboração entre usuários da EcoDiF, permitindo realizar buscas por dispositivos e aplicações a partir de seus respectivos metadados (tipo, usuário, localização, etc.) através da interface Web.

O Módulo de Armazenamento consiste de dois repositórios básicos, um para armazenamento de dados utilizando uma base de dados relacional, e outro para armazenamento de scripts de aplicações em um sistema de arquivos. É importante destacar que esses repositórios podem fazer uso de uma infraestrutura de computação em nuvem para armazenar dados e arquivos, provendo assim atributos de qualidade como robustez, confiabilidade, disponibilidade e escalabilidade [Gao et al. 2011, Soldatos et al. 2012]. Já o Módulo de Serviços Comuns envolve serviços de infraestrutura providos pela plataforma, tais como segurança (autenticidade, confidencialidade, integridade), gerenciamento de ciclo de vida de aplicações, transações, etc. O Módulo de Aplicações provê um modelo e um ambiente para programação e execução de aplicações que fazem uso dos dados (feeds) disponíveis na EcoDiF e geram novas informações que também podem ser disponibilizadas pela plataforma para serem usadas por outros feeds e aplicações mais complexas. Essas aplicações são construídas como mashups [Guinard et al. 2009], aplicações ad-hoc criadas a partir da composição de diferentes tipos de informação providas por diferentes fontes, tais como serviços Web e bases de dados relacionais. Por exemplo, considere-se um sensor que monitora a temperatura de uma dada localidade, e um usuário deseja combinar essa informação com um mapa que informa a localização das medidas coletadas. Dessa forma, uma única aplicação mashup pode compor tais informações de temperatura e localização. O modelo de programação e execução adotado pela EcoDiF é baseado no uso da linguagem EMML (Enterprise Mashup Markup Language)18, uma linguagem declarativa aberta que tem sido usada como padrão para o desenvolvimento de mashups. Aplicações mashup são implementadas como scripts escritos em EMML e executadas em um motor (engine) de execução que processa tais scripts. A EcoDiF foi implementada utilizando a linguagem de programação Java e implantada em um servidor de aplicações JBoss19, que permite o gerenciamento de componentes distribuídos, promove a confiabilidade de aplicações baseadas em um conjunto de serviços acessíveis via Web e em grandes volumes de dados, como é típico em ambientes de IoT. Usuários podem acessar as funcionalidades da EcoDiF através de uma interface Web provida pelo Módulo de Gerenciamento e Visualização e implementada com as tecnologias abertas JavaServer Faces (JSF)20 e Primefaces21. Uma vez que a conexão entre a EcoDiF e os dispositivos integrados é habilitada pelos respectivos drivers (via o Módulo de Conexão de Dispositivos), os dados obtidos dos 18 Enterprise Mashup Markup Language (EMML):

http://en.wikipedia.org/wiki/Enterprise_Mashup_Markup_Language 19 JBoss: http://www.jboss.org 20 JavaServer Faces Technology (JSF):

http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 21 Primefaces: http://www.primefaces.org



dispositivos são enviados à plataforma através de requisições HTTP PUT, provendo assim uma interface RESTful para os clientes (sejam humanos ou aplicações). Para dar suporte a tal abordagem RESTful, foi adotada a implementação RESTEasy22 para o estilo arquitetural REST e a Java API for RESTful Web Services (JAX-RS)23. Os dados (feeds) produzidos pelos dispositivos são estruturados utilizando o protocolo EEML, baseado na linguagem XML, e são tratados pelo Módulo de Manipulação de Dados para serem efetivamente registrados em uma base de dados relacional MySQL utilizando as especificações da Java Persistence API (JPA)24 implementadas no framework Hibernate25. Desenvolvedores de aplicações podem construir aplicações mashup fazendo uso dos dados providos pelos dispositivos (feeds) que são integrados à EcoDiF através do Módulo de Aplicações. Na EcoDiF, aplicações são implementadas usando a linguagem EMML, de modo que quando um feed é vinculado a uma aplicação, o Módulo de Aplicações automaticamente o inclui como uma variável de entrada no script EMML para a aplicação, e os usuários podem então codificar a lógica de programação. Por outro lado, usuários que possuem conhecimento acerca da linguagem EMML podem escrever seus próprios scripts (fora do ambiente da EcoDiF, em um editor de sua escolha) e então importa-los para a plataforma. As aplicações registradas na EcoDiF são executadas utilizando o motor de execução EMML também implantado no servidor de aplicações JBoss e seus respectivos resultados são exibidos para os usuários através interface Web da EcoDiF. Por fim, o Módulo de Serviços Comuns é responsável por serviços de infraestrutura da plataforma, tais como segurança (permite o controle de autenticidade, confidencialidade e integridade de usuários utilizando as especificações Java Authentication and Authorization Service (JAAS)26 implementadas no servidor de aplicações JBoss), gerenciamento do ciclo de vida de aplicações, transações, etc.

3.4.2 Xively A plataforma Xively27 utiliza serviços de nuvem para gerenciar dados providos por dispositivos. A plataforma fornece uma API para envio de dados a partir dos sensores, permitindo assim a visualização de dados históricos e provendo mecanismos para disparar eventos com base nos dados gerados pelos sensores (os chamados triggers). Assim como a EcoDiF, a Xively foi projetada tendo como base princípios REST e padrões da Web, como HTTP e URIs. Dessa forma, a plataforma fornece interfaces bem definidas e padronizadas, minimizando os problemas de incompatibilidade entre os diferentes dispositivos. Na Xively, os dados são organizados em feeds, datapoints e datastreams. Um feed representa os dados de um ambiente (uma sala, por exemplo) com seus respectivos datastreams, que representam dados enviados por um determinado sensor nesse ambiente (por exemplo, temperaturas do ambiente monitorado), enquanto um datapoint representa um único valor de um datastream em um determinado instante de tempo.

22 RESTEasy: http://www.jboss.org/resteasy 23 Java API for RESTful Services (JAX-RS): https://jax-rs-spec.java.net/ 24 Java Persistence API:

http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html 25 Hibernate: http://www.hibernate.org 26 Java Authentication and Authorization Service (JAAS):

http://www.oracle.com/technetwork/java/javase/jaas/index.html 27 Xively – Business solutions for the Internet of Things: http://xively.com



Por se tratar de uma solução comercial e de código fechado, não há detalhes quanto à arquitetura dessa plataforma além do exposto na Figura 3.9. Contudo, sabe-se que há três formas de se recuperar dados aferidos pelos dispositivos conectados à Xively: (i) sensores enviam dados para a plataforma nos formatos JSON, XML (especificamente EEML) ou CSV usando a API REST; (ii) através de sockets, e; (iii) através do protocolo MQTT. No primeiro caso, através dos métodos implementados pelo HTTP, o método GET é utilizado por um programa cliente para recuperar dados de um feed ou datastreams, enquanto o método PUT é utilizado nos dispositivos conectados para o envio de dados. No segundo caso, um socket pode ser criado de modo a evitar o overhead de abrir e fechar comunicações HTTP em condições nas quais muitos dados são trocados. Além disso, os dois primeiros casos permitem a utilização do protocolo SSL/TLS a fim de prover autenticação e criptografia dos dados. Por fim, o terceiro caso utiliza os recursos de publish e subscribe do protocolo MQTT para o envio e a recuperação de dados a partir dos dispositivos.

Figura 3.9. Arquitetura da Xively.

3.4.3 Carriots A Carriots28 também é uma plataforma de middleware para IoT que utiliza serviços de nuvem para gerenciar dados providos por dispositivos, além de conectar dispositivos a dispositivos e a outros sistemas. Portanto, se um sistema for conectado à plataforma, ele também pode ser modelado como um dispositivo. A partir de sua API RESTful, a Carriots tem por objetivo coletar e armazenar qualquer dado originado dos mais diversos dispositivos, utilizá-lo em seu motor de aplicações e disponibilizá-lo a seus usuários não importando o volume de dispositivos conectados. Como ilustrado pela Figura 3.10, as entidades da plataforma possuem uma hierarquia bem definida. Dessa forma, todos os dispositivos conectados ao middleware

28 Carriots: http://www.carriots.com



são associados a serviços (e.g., dispositivos físicos ou algum outro recurso) e todos os serviços pertencem a um projeto. Por exemplo, sensores de estacionamento, independente do seu contexto de utilização (como localização geográfica distinta), pertencem ao mesmo serviço dentro de um projeto. Dessa forma, a primeira atividade de um usuário ao interagir com a plataforma é a criação de um projeto. Por conta dessa hierarquia, se um projeto for desabilitado, isso impactará na desativação de todas as entidades vinculadas à ele. Além disso, triggers nessa plataforma são associados à exportação dos dados dos serviços (ao contrário da EcoDiF e da Xively, nas quais eles são associados a aplicações e a datastreams). Do ponto de vista dos dispositivos, eventos tais como o recebimento ou a persistência de dados podem ser monitorados por listeners, entidades responsáveis por executarem análise e processamento em caso de alguma condição pré-configurada ter sido atendida.

Figura 3.10. Exemplo de hierarquia das entidades da plataforma Carriots.

Como mostra a Figura 3.11, a arquitetura lógica da Carriots é formada pelos seguintes módulos: (i) a API REST; (ii) Big Data; (iii) Gerenciamento de Projetos e Dispositivos; (iv) Regras de Negócio e Processamento de Eventos; (v) Segurança; (vi) Logs e Debug; (vii) Painel de Controle, e; (viii) Módulo de Comunicação Externa.

Figura 3.11. Arquitetura da plataforma Carriots.

Os dados trocados entre os dispositivos, os sistemas conectados e a plataforma podem ser representados de duas formas distintas: (i) sensores enviam dados nos formatos JSON ou XML (em um formato particular da plataforma) usando a API



REST, ou (ii) através do protocolo de mensagens MQTT. O módulo de Big Data provê às aplicações a flexibilidade de gerenciar os dados dos dispositivos de modo que a massa de dados seja armazenada em uma arquitetura de Big Data em formato schemaless, permitindo assim armazenar dados sem que seja necessário normalizá-los. O módulo de Gerenciamento de Projetos e Dispositivos contém os projetos criados pelos usuários e é responsável por atualizações do software embarcado nos dispositivos e por suas configurações. O armazenamento e a execução de eventos em forma de scripts criados utilizando a linguagem de programação Groovy29 e fazendo uso de regras do tipo if-then-else, são responsabilidade do módulo de Regras de Negócio e Processamento de Eventos. A segurança é tratada de quatro formas, a saber: (i) através do uso de chaves pré-compartilhadas para a definição de privilégios de acesso; (ii) através da utilização do protocolo HTTPS para a encriptação dos dados enviados pela rede; (iii) pela utilização de Hash HMAC (Keyed-Hash Message Authentication Code) e senha para autenticação e verificação de conteúdo, e; (iv) por criptografia customizada a partir de scripts criados pelo usuário. O módulo Logs e Debug fornece um console para depuração de erros e registro de mensagens, tornando tais dados acessíveis a partir do painel de controle. Por sua vez, o módulo Painel de Controle permite o gerenciamento pelo usuário de todos os outros módulos e recursos da plataforma. Por fim, o módulo de Comunicação Externa complementa os recursos de interação da plataforma ao permitir o envio de e-mails, SMS e a interação com outros sistemas (como a plataforma de compartilhamento de arquivos Dropbox ou a rede social Twitter).

3.4.4 LinkSmart A LinkSmart (anteriormente chamado Hydra)30 é uma plataforma de middleware baseada em Arquitetura Orientada a Serviços (SOA – Service-Oriented Architecture, em Inglês) para IoT que oferece suporte ao desenvolvimento de aplicações formadas por dispositivos físicos heterogêneos que operam com recursos limitados em termos de poder computacional, energia e memória. Ela oferece interfaces de serviços Web para controle de qualquer tipo de dispositivo físico e permite que desenvolvedores incorporem dispositivos físicos heterogêneos em suas aplicações. Sua arquitetura possui três camadas principais: (i) camada de rede, responsável pela comunicação com os dispositivos; (ii) camada de serviço, responsável pelo gerenciamento de eventos, dispositivos, escalonamento de recursos, dentre outros, e; (iii) camada semântica. A descrição semântica dos dispositivos através do uso de ontologias de dispositivos é uma das características mais importantes dessa plataforma. Responsável por representar todas as meta-informações sobre os dispositivos, a ontologia usada é baseada na ontologia de dispositivos FIPA (Foundation for Intelligent Physical Agents)31 e permite a parametrização semântica para incluir informações dos dispositivos, como seus recursos de segurança. A LinkSmart contém ainda o módulo Application Ontology Manager, que provê uma interface para uso da ontologia de

29 The Groovy Programming Language: http://groovy-lang.org/ 30 LinkSmart: https://linksmart.eu 31 Foundation for Intelligent Physical Agents (FIPA): http://www.fipa.org/specs/fipa00091/index.html



dispositivos, tanto para buscar propriedades e funções dos dispositivos, quanto para descobertas e atualizações de dispositivos. Nesse contexto, a camada semântica da LinkSmart contém: (i) um módulo de inferências (reasoner), responsável por inferir sobre o status dos dispositivo e indicar qual tipo de dispositivo entrou na rede; (ii) um módulo de consulta (query) para recuperar informações sobre os dispositivos e suas capacidades; (iii) um módulo de atualização, que permite inclusão, remoção e mudanças na ontologia; (iv) um módulo de versionamento, que gerencia diferentes versões da ontologia, incluindo diferentes versões dos dispositivos e serviços, e; (v) um módulo de interpretação e anotação, responsável por automaticamente atualizar a ontologia com novos tipos de dispositivos e por realizar análise e anotação dos dispositivos existentes e descrições que são incluídas na ontologia. Por fim, a plataforma distingue dispositivos com recursos restritos (non LinkSmart-enabled device), que não são capazes de hospedá-la (mas são capazes de se comunicar através de gateways), e dispositivos mais poderosos (LinkSmart-enabled devices) que são capazes de hospedá-la.

3.4.5 OpenIoT A plataforma de middleware OpenIoT [Soldatos et al. 2012] tem por objetivo ser uma camada de suporte para aplicações em IoT usando um modelo baseado em infraestrutura de nuvem. Os recursos IoT podem ser acessados por serviços sob demanda que seguem o modelo de computação em nuvem, de modo que, por exemplo, sensoriamento pode ser um serviço disponibilizado na nuvem (Sensing as a Service), e através do uso de serviços de nuvem para IoT, usuários podem configurar, implementar e usar a IoT. O projeto foca na convergência entre IoT e computação em nuvem, visando assim fornecer uma “nuvem de coisas” (cloud of things, em Inglês). Para tal, middleware tem como proposta permitir a customização de ambientes de nuvens auto-organizáveis para aplicações IoT, habilitando a implantação por provedores de serviços de infraestruturas de nuvem que forneçam serviços IoT a usuários. A OpenIoT conecta sensores com o ambiente de nuvem, de forma que os recursos da nuvem poderão ser usados para processamento e gerenciamento de dados, funções especialmente úteis para processamento intensivo de sinais que, em geral, não podem ser realizadas em infraestrutura de IoT devido aos recursos limitados dos dispositivos. Para permitir interoperabilidade entre os vários objetos, a OpenIoT usa a ontologia SSN (Semantic Sensor Network)32, que serve como base para especificação de solicitações dos serviços combinando sensores, fluxos de dados (data streams) e suas propriedades. A arquitetura da OpenIoT (Figura 3.12) é composta por três planos lógicos distintos: (i) Utilidade/Aplicação; (ii) Virtualizado; e (iii) Físico. Tais planos, por sua vez, são compostos por sete módulos principais, apresentados a seguir.

32 Semantic Sensor Network Ontology (SSN): http://www.w3.org/2005/Incubator/ssn/ssnx/ssn



Figura 3.12. Arquitetura da plataforma de middleware OpenIoT.

O plano Utilidades/Aplicações é composto por três módulos: (i) Definição de Solicitação; (ii) Apresentação de Solicitação; e (iii) Configuração e Monitoramento. Através de uma interface Web, o primeiro módulo permite definir solicitações de serviços para a plataforma em tempo de execução, solicitações essas que são enviadas ao Escalonador. O módulo Apresentação de Solicitação permite, também via interface Web, que o usuário selecione mashups de um repositório. O módulo de Configuração e Monitoramento permite o gerenciamento e a configuração dos dispositivos conectados e dos serviços em execução na plataforma. O plano Virtualizado também é composto por três módulos: (i) Escalonador; (ii) Nuvem de Armazenamento de Dados, e; (iii) Prestação de Serviços e Gerenciador de Recursos. O Escalonador processa todas as requisições para serviços originadas no módulo Definição de Solicitação e garante acesso aos recursos necessários. A Nuvem de Armazenamento de Dados tem como objetivo armazenar os fluxos de dados originados dos dispositivos conectados bem como os metadados necessários para o funcionamento da plataforma. Para tal, uma versão adaptada do middleware Linked Stream [Le-Phuoc et al. 2012] é utilizada. O módulo de Prestação de Serviços & Gerenciador de Recursos tem o papel de combinar fluxos de dados para serem entregues aos serviços solicitantes e realizar a contabilidade e o faturamento dos recursos da plataforma. Por fim, o plano Físico é composto apenas pelo módulo Sensor Middleware, responsável por coletar, filtrar, combinar e anotar semanticamente fluxos de dados originários tanto de dispositivos físicos quanto virtuais. Para tal, ele faz uso de uma versão adaptada do middleware GSN (Global Sensor Network)33, que fornece uma API RESTful para a interoperação com os dispositivos, bem como alguns recursos de segurança (e.g., autenticação e permissão de acesso através da definição de papeis).

3.4.6 RestThing Assim como a EcoDiF, RestThing [Qin et al. 2011] é uma infraestrutura de serviços Web baseada em REST cujo objetivo é ocultar a heterogeneidade de dispositivos e prover um modo de integrar dispositivos em aplicações Web. A plataforma visa permitir

33 Global Sensor Network (GSN): https://github.com/LSIR/gsn/wiki



que desenvolvedores criem aplicações usando princípios REST, combinando recursos físicos e Web, de modo que dispositivos e informações Web são ambos representados como recursos e manipulados por uma interface uniforme no estilo REST. Como ilustra a Figura 3.13, os elementos do RestThing são: (i) aplicações; (ii) API RESTful; (iii) provedor de serviço; (iv) camada de adaptação; (v) dispositivos embutidos, e; (vi) recursos Web. A API RESTful permite transmitir dados entre os sensores que usam IP, os gateways, o servidor Web e aplicações Web. O RestThing trabalha com três tipos de formatos de dados, a saber JSON, XML e CSV. Para compartilhamento de dados é usada a linguagem EEML, que descreve a estrutura dos dados. Para acesso aos objetos RESTful, são utilizadas as operações do protocolo HTTP: o método GET é utilizado para recuperar o estado corrente do objeto, o método PUT é utilizado para modificar o estado corrente do objeto, o método POST é utilizado para criar um novo objeto; DELETE para remover um objeto e, adicionalmente, o método LIST, que permite obter todos os objetos conectados à plataforma.

Figura 3.13. Infraestrutura do RestThing.

3.4.7 WoT Enabler A WoT Enabler [Gao et al. 2011], ilustrada na Figura 3.14, é uma plataforma baseada em REST para a integração de sensores e compartilhamento de seus dados. Implementada utilizando a linguagem de programação Ruby, seu servidor se comunica com uma base de dados conectada à arquitetura, responsável pelo armazenamento dos dados os quais são enviados diretamente pelos dispositivos conectados (para dispositivos dotados de conexão direta à Internet) ou por gateways (para dispositivos que não possuem tal capacidade). Assim, tais dados podem ser acessados por aplicações e usuários através de requisições HTTP RESTful ao servidor WoT Enabler, que pode retornar representações de dados nos formatos XML, JSON ou CSV. De modo similar às plataformas EcoDiF, Xively e RestThing, a arquitetura também usa EEML para a estruturação dos dados provenientes dos sensores, diferindo apenas na hierarquia de dados utilizada: (i) um system representa uma coleção de dados referentes a um determinado ambiente; (ii) um sensor representa um sensor individual no contexto de um system e; (iii) um data é um par <chave, valor> que se refere ao valor de uma medida aferida por um sensor em um dado instante de tempo.



Figura 3.14. Arquitetura da plataforma WoT Enabler [Gao et al. 2011].

3.4.8 S3OIA S3OIA (Smart Spaces and Smart Objects Interoperability Architecture) [Vega-Barbas et al. 2012] é uma arquitetura orientada a serviço para integração de diferentes tipos de objetos, físicos ou virtuais usando tuplespace para expressar semanticamente informações dos dispositivos integrados pela plataforma e possibilitar a representação destes. Seus módulos são divididos em cinco grupos de módulos funcionais: (i) Descoberta de Serviços e Dispositivos, (ii) Exposição de Web Services e Triple Spaces, (iii) Repositório de Serviços e Resolução de Dependências, (iv) Interface de Interação, e (v) Composição, Tolerância a Falhas e Dependências Distantes. O grupo Descoberta de Serviços e Dispositivos é composto pelos módulos responsáveis pela integração e pela abstração de todos os dispositivos, não importando o protocolo de comunicação usado pelos mesmos. Por exemplo, através desse grupo, é possível que um Arduino se comunique com qualquer dispositivo que suporte o protocolo UPnP (Universal Plug and Play). Para tal, os gateways de comunicação da plataforma abstraem qualquer heterogeneidade ao oferecer uma interface comum de comunicação, servindo de proxies para os protocolos envolvidos na troca de dados. O grupo Exposição de Web Services e Triple Spaces traz a computação distribuída baseada em tuplespaces para sistemas ubíquos, de forma que dispositivos heterogêneos possam compartilhar informações assincronamente. A computação Triple Space realiza comunicação baseada em espaços de tuplas usando triplas RDF. O grupo Repositório de Serviços e Resolução de Dependências gerencia os serviços disponíveis dentro de um Smart Space e resolve as dependências extraídas da aplicação. Além disso, ele possui um módulo gerenciador de eventos que segue o paradigma publish/subscribe. Dessa forma, quando um novo serviço é disponibilizado



ou quando um serviço já estabelecido se torna indisponível, seu estado é comunicado para todos os outros módulos envolvidos. O grupo Interface de Interação gerencia a interação entre os seres humanos e a plataforma. O principal objetivo desse grupo é recuperar informações sobre as interações entre dois atores (chamadas de intents) e adequar os objetos já implantados às necessidades dos usuários. Por fim, o grupo de Composição, Tolerância a Falhas e Dependências Distantes é responsável por tratar da composição e orquestração de serviços. Além disso, esses módulos gerenciam o acesso aos recursos da plataforma quando dois ou mais objetos requisitam-nos simultaneamente.

3.4.9 Ubiware A Ubiware [Nagy et al. 2009] é uma plataforma de middleware baseada em três requisitos: automação, integração e interoperabilidade. A solução proposta incorpora princípios de sistemas multi-agentes, entidades computacionais com comportamento autônomo que facilitam o desenvolvimento de sistemas complexos. A integração se apresenta como um segundo desafio a ser tratado. Para tal, a Ubiware se utiliza dos princípios de Web Semântica para permitir que tanto humanos quanto máquinas possam entender e processar uma informação. No que tange à interoperabilidade, a proposta se baseia em suportar o máximo número de protocolos e dispositivos possível, por não acreditar no estabelecimento de novos padrões. Para atingir os objetivos estabelecidos, a proposta foca no Ubicore, o núcleo da plataforma de middleware proposta. Esse componente provê a todos os objetos conectados a possibilidade de serem inteligentes ao conectá-los a um agente de software. Dessa forma, tais objetos ganham recursos de comunicação, autocontrole e auto-monitoramento através da utilização do conhecimento e das funcionalidades previamente adquiridos a partir de eventos tanto próprios quanto externos. Já com relação à ciência de contexto, o fato de que cada objeto tem um agente vinculado a ele implica que tal agente tem pleno conhecimento acerca de seu estado. Dessa forma, tal conhecimento pode ser trocado com outros agentes e utilizado para melhorar a execução de outros objetos vinculados à plataforma. Essa característica também influencia em como os dados são armazenados pela plataforma. Ao invés de um repositório de dados centralizados, a plataforma adota uma armazenagem de informações distribuída, na qual os agentes trocam informações entre si e mineram os dados recebidos a fim de encontrar as informações necessárias para sua utilização.

3.4.10 WSO2 Considerada uma instância da arquitetura de referência descrita na Seção 3.3.3, a plataforma WSO2 [Fremantle 2014] pode ser considerada uma arquitetura modular e versátil, permitindo o seu uso em diferentes domínios de aplicações a partir de uma única instalação. Por se tratar de uma solução voltada à iniciativa privada, a plataforma oferece suporte a diferentes ambientes de implantação, tais como servidores tradicionais (com sistemas operacionais Linux ou Windows, por exemplo), nuvens públicas (e.g., Amazon EC2, Microsoft Azure e Google Compute Engine), ou ainda nuvens privadas ou híbridas (tais como OpenStack, Suse Cloud, Eucalyptus, Amazon Virtual Private Cloud e Apache Stratos). A WSO2 é baseada na plataforma WSO2 Carbon que, por sua



vez, é uma implementação do OSGi (Open Service Gateway Initiative)34, um conjunto de especificações que define um sistema dinâmico de componentes para Java. Os módulos da plataforma mapeiam as camadas definidas pela arquitetura de referência WSO2 (c.f. Seção 3.3.3). A Camada de Agregação/Barramento é mapeada em dois módulos: o WSO2 Message Broker e o WSO2 Enterprise Service Bus. O primeiro módulo tem como papel básico lidar com a troca de mensagens dos protocolos do tipo publish-subscribe (AMQP e MQTT). Já o segundo módulo complementa o suporte aos protocolos publish/subscribe, lida com o protocolo HTTP, e lida com controle de acesso (OAuth2 e XACML). A Camada de Análise e Processamento de Eventos é, por sua vez, mapeada em dois módulos: WSO2 Business Activity Monitor e WSO2 Complex Event Processor. O primeiro oferece as funcionalidades: (i) coleta dos dados das camadas inferiores; (ii) armazenamento desses dados através do sistema de banco de dados distribuído Apache Cassandra35; (iii) plataforma de map-reduce baseada no Apache Hadoop; (iv) análise em batch fornecida pelo Apache Hive36, e; (v) painel para a visualização dos dados recebidos. Já o segundo módulo é capaz de realizar análises de alto desempenho em tempo real e operações de provisionamento de recursos em caso de aumento da carga de trabalho. Por fim, a Camada de Identidade de Gerenciamento de Acesso é mapeada no módulo WSO2 Identity Server e fornece as seguintes funcionalidades de gerenciamento de acesso:

• provedor de identidade OAuth2 para emissão, revogação e gerenciamento de tokens.

• suporte a SSO (Single Sign-On) incluindo suporte a SAML2 SSO e OpenID.

• suporte para outros protocolos de identidade incluindo OpenID 2.0 e Kerberos37.

• suporte completo para XACML (incluindo versões 2.0 e 3.0).

• capacidade de integração entre diferentes fornecedores de identidade e fornecedores de serviços incluindo intermediação de identidade.

• suporte para fornecimento de identidade incluindo SPML (Service Provisioning Markup Language)38 e SCIM (System for Cross-domain Identity Management)39.

3.4.11 IoT Middleware @ INRIA ARLES [Teixeira et al. 2011] Com o intuito de propor soluções relativas aos requisitos de escalabilidade, adaptabilidade e heterogeneidade, a plataforma de middleware proposta por Teixeira et al. (2011) utiliza uma abordagem orientada a serviços baseada em semântica para descrever objetos físicos ou virtuais conectados como serviços de software. A partir dessa base, é introduzido o suporte a modelos matemáticos de estimativa de dados e resolução de conflitos de modo a se obter uma arquitetura com dispositivos e serviços

34 OSGi Alliance: http://www.osgi.org/ 35 The Apache Cassandra Project: http://cassandra.apache.org/ 36 Apache Hive TM: https://hive.apache.org/ 37 MIT Kerberos Consortium: http://www.kerberos.org 38 Service Provisioning Markup Language (SPML): https://www.oasis-open.org/committees/provision/ 39 System for Cross-Domain Identity Management (SCIM): http://www.simplecloud.info/



fracamente acoplados. A arquitetura projetada consiste basicamente de: (i) um módulo de descoberta; (ii) um módulo de estimativas, e; (iii) uma base de conhecimento. O processo realizado pelo módulo de descoberta de serviços consiste de duas partes, uma de registro, que é o processo no qual cada dispositivo/objeto se conecta a um servidor para armazenar suas informações, e outra de descoberta, que é o processo de descoberta de serviços que satisfaçam o conjunto de atributos desejados (localização geográfica, modalidades de detecção, etc.). A fim de endereçar escalabilidade, é introduzido o conceito de descoberta probabilística, através do qual provê-se um conjunto de serviços que melhor se aproximam do resultado procurado. Em uma rede extremamente grande com uma base de conhecimento também grande, a busca de uma composição de serviços ótima se torna impraticável. Dessa forma, a proposta adota a abordagem de uma composição aproximadamente ótima fazendo uso de dois conceitos, a saber, expansão inteligente e mapeamento Probabilístico. No primeiro conceito, a fim de evitar cálculos exaustivos de todos os possíveis conjuntos de fluxos de dados equivalentes (dos quais, eventualmente, somente um será selecionado), utiliza-se uma abordagem mais inteligente, onde se produz um conjunto de “bons” fluxos de dados candidatos. Já no contexto do mapeamento probabilístico, tendo como entrada o conjunto selecionado na fase anterior, o mapeamento irá aleatoriamente escolher um pequeno subconjunto de todos os mapeamentos implementáveis através de consultas atômicas ao módulo de descobertas probabilísticas. O módulo de estimativas é responsável por processar as requisições de sensoriamento e atuação, gerando um grafo de fluxo de dados que conecta os serviços disponíveis de modo a produzir a saída desejada com base nos parâmetros de entrada e a saída esperada. A fim de se enfrentar os desafios de localização desconhecida, os autores utilizam a estimativa automatizada que, por sua vez, utiliza-se da base de conhecimento da plataforma de middleware sobre sensoriamento, atuação, dispositivos, etc. Tal abordagem só é possível porque modelos físicos e estatísticos são previamente fornecidos e estão disponíveis na base de conhecimento. Dessa forma, quando uma informação ausente é detectada ou uma precisão maior é requisitada, a plataforma aplica os modelos mencionados a fim de estimar o valor com maior probabilidade de ser verdadeiro. Adicionalmente, é provável que o mesmo arcabouço usado na estimativa automatizada possa ser estendido para oferecer suporte a técnicas de resolução de conflito e de auto-calibração, uma vez que estas dependem de modelos armazenados na base de conhecimento, enfrentando-se, assim, os desafios de metadados incompletos ou inexatos e de resolução de conflitos. Por fim, a base de conhecimento armazena informações sobre sensoriamento, atuação, dispositivos, modelos de dados, etc. descritas na forma de ontologias e que são úteis para o módulo de estimativas. Tais ontologias contêm informações sobre como conceitos físicos diferentes se relacionam (ontologia de domínio), informações relacionadas a dispositivos físicos que podem existir na rede (ontologia de dispositivos), e informações acerca dos diferentes modelos de estimação (ontologia de estimativas). Pelo exposto, essa plataforma de middleware adota uma arquitetura orientada a serviços a fim de abstrair sensores e atuadores como serviços a fim de ocultar suas heterogeneidades, e depende fortemente de uma base de conhecimento que contenha informações sobre sensores, atuadores, fabricantes, conceitos físicos, unidades físicas, modelos de dados, modelos de erros, entre outros. Para tratar os desafios decorrentes da grande escala e da profunda heterogeneidade inerente à IoT, a proposta concentra sua



contribuição em três núcleos: descoberta probabilística, composição aproximadamente ótima e estimação automatizada. Juntas, essas três características permitem à plataforma responder as requisições recebidas enquanto gerencia complexas relações entre precisão e tempo, memória, processamento e restrições energéticas dos dispositivos.

3.4.12. Plataformas de middleware versus requisitos Esta subseção analisa as plataformas de middleware discutidas anteriormente em relação à satisfação dos requisitos vistos na Seção 3.2, a saber: (i) interoperabilidade; (ii) descoberta e gerenciamento de dispositivos; (iii) provisão de interfaces de alto nível; (iv) ciência de contexto; (v) escalabilidade; (vi) gerenciamento de grandes volumes de dados; (vii) segurança, e; (viii) adaptação dinâmica. Na Tabela 3.1 e na Tabela 3.2, o símbolo ! denota que o requisito é completamente atendido, o símbolo " indica que o requisito é parcialmente atendido, e o símbolo # indica que o requisito não é atendido.

Tabela 3.1. Tabela de requisitos (parte 1).

Plataformas de middleware Interoperabilidade

Descoberta e Gerenciamento de

Dispositivos

Interfaces de Alto Nível

Ciência de Contexto

EcoDiF ! " ! "

Xively ! ! ! "

Carriots ! ! ! "

LinkSmart ! ! # !

OpenIoT ! # ! #

RestThing ! # ! "

WoT Enabler ! # ! "

S3OIA ! ! # !

Ubiware ! # # !

WSO2 ! ! ! # INRIA ARLES ! # # !

Tabela 3.2. Tabela de requisitos (parte 2).

Plataformas de middleware Escalabilidade Gerenciamento de Grandes

Volumes de Dados Segurança Adaptação Dinâmica

EcoDiF ! ! ! # Xively ! ! ! # Carriots ! ! ! # LinkSmart # ! ! # OpenIoT ! ! ! # RestThing # # # # WoT Enabler # # # # S3OIA # # # !

Ubiware # # # !

WSO2 ! ! ! !

INRIA ARLES # ! # #



Diante do exposto nas Tabelas 3.1 e 3.2, constata-se que nenhuma plataforma de middleware de IoT foi capaz de atender a todos os requisitos levantados. Tais plataformas tratam apenas subconjuntos dos requisitos, abordando-os de formas diversas. A interoperabilidade é um exemplo. Apesar de ser atendida por todos, EcoDiF e OpenIoT consideram que o uso de protocolos e tecnologias Web amplamente utilizados são suficientes para mitigar os problemas da heterogeneidade entre os dispositivos, enquanto plataformas como Carriots, Xively e WSO2 acreditam que o suporte a outros protocolos é importante. Já requisitos como ciência de contexto e adaptação dinâmica são pouco abordados. A ciência de contexto é abordada pela maioria das plataformas levantadas ao caracterizar os dados coletados através da inclusão de dados semânticos, como localização, horário de coleta e afins, em conjunto com os dados coletados. Por sua vez, a adaptação dinâmica possui abordagens distintas. Enquanto a WSO2 a atende ao utilizar um módulo capaz de redimensionar a utilização dos recursos da plataforma a fim de manter a disponibilidade dos serviços, a plataforma Ubiware se utiliza de compartilhamento de dados entre agentes de software para melhorar o funcionamento dos objetos, tanto físico quanto virtuais, envolvidos.

Por conta disso, é possível concluir que o estado da arte para plataformas de middleware para IoT ainda se encontra em um estágio inicial, onde requisitos importantes não foram exaustivamente explorados. Há várias questões de pesquisa e desenvolvimento em aberto, as tecnologias e abordagens ainda divergem, além de não haver uma solução capaz de englobar todos os requisitos necessários para a concretização do paradigma.

3.5. Estudos de Caso Esta seção apresenta um conjunto de aplicações desenvolvidas como provas de conceito para a EcoDiF, plataforma desenvolvida pelos grupos de pesquisa dos quais participam os autores deste minicurso e validada em diferentes cenários reais [Pires et al. 2014]. Tais provas de conceito foram propostas com o objetivo de demonstrar, de maneira prática, o potencial da EcoDiF para a integração de dispositivos heterogêneos e possibilitar o controle, visualização e processamento de dados por eles providos em tempo real. Conforme apresentado nas subseções a seguir, os diferentes domínios de aplicação nos quais essas aplicações estão inseridas são: (i) monitoramento de Centros de Processamento de Dados (CPDs); (ii) sensoriamento participativo; (iii) monitoramento de redes de dutos para transporte de água e gás, e; (iv) monitoramento remoto de pacientes. Em particular, a aplicação para monitoramento de CPDs é usada nesta seção para ilustrar, de forma completa, as atividades necessárias para a criação de aplicações utilizando a EcoDiF, desde a criação de drivers de integração entre dispositivos e a plataforma, à execução da aplicação propriamente dita fazendo uso de feeds nela cadastrados.

3.5.1. Monitoramento de Centros de Processamento de Dados (CPDs) Em CPDs, é necessário monitorar constantemente equipamentos (ativos) tais como servidores, dispositivos de rede, dispositivos de armazenamento, etc., e notificar gerentes em caso de possíveis anormalidades em sua operação. De maneira adicional aos equipamentos e à infraestrutura lógica do CPD, é necessário monitorar variáveis



relacionadas à sua infraestrutura física, como temperatura, umidade relativa do ar, consumo de energia elétrica, dentre outras.

Em CPDs, as soluções usadas para desempenhar tarefas de monitoramento não são sistemáticas, algumas vezes não automatizadas, e também não são integradas. Consequentemente, gerentes e supervisores de CPDs necessitam, em geral, utilizar software de gerenciamento de propósito geral ou software proprietário de cada dispositivo, acessando-o explicitamente. Além disso, pela falta de integração entre as soluções de monitoramento existentes, eles não conseguem ter uma visão sistêmica da situação real do CPD e sua estrutura física, nem dos equipamentos que o compõem. Nesse contexto, a EcoDiF possibilita a integração desses diversos dispositivos e os dados por eles providos podem ser disponibilizados via Web para os usuários, sendo possível que os gerentes e supervisores do CPD tenham controle sobre o que está acontecendo no ambiente e possam inclusive ser notificados (por e-mail ou por mensagens recebidas em seus dispositivos móveis, por exemplo) acerca dos possíveis eventos que ocorram, conforme ilustra a Figura 3.15.

Figura 3.15. Ilustração de um cenário de monitoramento de CPDs com vistas à integração de dispositivos e disponibilização de dados através da EcoDiF.

A fim de disponibilizar dados coletados por dispositivos e permitir o seu posterior uso por aplicações, usuários da EcoDiF necessitam realizar um conjunto de atividades que envolvem principalmente: (i) o registro dos feeds que irão receber os dados enviados pelos drivers, no formato EEML; (ii) o desenvolvimento dos drivers de integração, que permitem os dispositivos comunicarem-se com a plataforma, enviando dados, e; (iii) o desenvolvimento das aplicações propriamente ditas, como mashups especificados utilizando a linguagem EMML. Uma vez criadas, as aplicações podem ser executadas sobre a EcoDiF fazendo uso dos feeds nela cadastrados. Essas atividades são brevemente descritas a seguir. 1) Criação de feeds na EcoDiF Antes que dispositivos (através de seus respectivos drivers de integração) possam enviar dados à EcoDiF, é necessário criar os feeds que irão receber tais dados. A criação desses feeds é feita através da interface Web da plataforma, que disponibiliza um formulário a



ser preenchido pelo usuário. A Figura 3.16 mostra uma captura de tela referente ao formulário de cadastro de feeds na plataforma. No formulário, o usuário informa o dispositivo que enviará os dados e provê informações adicionais referentes ao feed que está sendo cadastrado, tais como descrição, unidade de medida utilizada e localização. Uma vez criado, o feed recebe um endereço (URI) único para o qual dados obtidos pelo dispositivo em questão deverão ser enviados via requisições HTTP PUT direcionadas a tal endereço.

Figura 3.16. Interface Web para registro de feeds na EcoDiF.

2) Desenvolvimento de drivers de integração Os equipamentos usados em CPDs, tipicamente, podem ser gerenciados usando o protocolo SNMP (Simple Network Management Protocol) [Case et al. 1990], protocolo da camada de aplicação para gerência de dispositivos em uma rede. O SNMP permite coletar diversas informações acerca de tais dispositivos usando os respectivos OIDs (object identifiers)40 definidos na MIB (Management Information Base)41 do dispositivo. Dessa forma, para obter uma dada informação acerca de um dispositivo, são necessários (i) o respectivo OID referente a essa informação, e (ii) o endereço do dispositivo em questão. A obtenção de tal informação dá-se por meio do protocolo SNMP, na camada de aplicação, sobre o protocolo UDP, na camada de transporte. Portanto, para permitir a integração desses dispositivos à EcoDiF e a disponibilização dos dados por eles providos na plataforma, com vistas à aplicação de monitoramento de CPDs, é necessário desenvolver um driver para o protocolo SNMP que, basicamente: (i) realize a captura das informações providas pelos dispositivos utilizando esse protocolo; (ii)

40 Object identifier (OID): http://en.wikipedia.org/wiki/Object_identifier 41 Management information base (MIB): http://en.wikipedia.org/wiki/Management_information_base



realize a estruturação desses dados capturados no formato EEML, adotado pela EcoDiF, e; (iii) envie as informações para a EcoDiF por meio de uma requisição HTTP PUT.

Para a aplicação em questão, foi desenvolvido um driver ativo para o protocolo SNMP como uma aplicação implementada utilizando a linguagem de programação Java e fazendo uso da SNMP4J42, uma implementação de código aberto para o SNMP destinada a essa linguagem de programação. Para que o driver faça a coleta de dados referentes a um determinado equipamento compatível com o SNMP e os envie para a EcoDiF, quatro argumentos devem ser fornecidos como entrada: (i) o endereço Web do feed na EcoDiF no qual as informações deverão ser registradas; (ii) o endereço do equipamento a ser monitorado; (iii) o respectivo OID referente à informação a ser coletada a partir do equipamento, e; (iv) o intervalo de envio periódico dos dados, em segundos. Por exemplo, para obter a temperatura de um dispositivo no endereço 192.168.0.1, o driver poderia ser executado utilizando o seguinte comando:

java -‐jar driver.jar http://www.ecodif.com.br/EcodifAPI/api/feeds/1/datastreams/1

.1.3.6.1.4.1.25506.2.6.1.1.1.1.12.1 udp:192.168.0.1/161

3

o http://www.ecodif.com.br/EcodifAPI/api/feeds/1/datastreams/1 é o endereço do feed no qual os dados referentes à temperatura serão armazenados na EcoDiF e .1.3.6.1.4.1.25506.2.6.1.1.1.1.12.1 é o OID referente à temperatura do dispositivo em questão, conforme definido na sua respectiva MIB. Além disso, conforme especificado no último argumento, os dados de temperatura do equipamento serão coletados periodicamente a cada três segundos.

A Figura 3.17 mostra um trecho de código do driver SNMP referente ao método startSending, que instancia o serviço SNMP definido na SNMP4J para acessar o equipamento cujo endereço foi informado pelo usuário (variável serverSNMP), conforme descrito nas linhas 9 e 10. A informação de interesse é retornada pelo SNMP chamando-se o método getAsString, também definido na SNMP4J, que recebe como parâmetro o OID (variável givenOID) informado pelo usuário referente à informação em questão (linha 12). Uma vez obtida a informação de interesse, o método sendValue (linha 15) é chamado para enviar tal informação via requisição HTTP PUT ao endereço do feed especificado inicialmente pelo usuário como argumento (addressPut).

42 SNMP4J – Free Open Source SNMP API for Java: http://www.snmp4j.org/



Figura 3.17. Trecho de código do driver referente ao método startSending, que instancia o serviço SNMP para coleta de dados do equipamento.

Após coletar o respectivo dado de interesse através do método startSending (Figura 3.17), o driver estrutura tal informação no formato EEML, adotado pela EcoDiF, e a envia para a EcoDiF executando o método sendValue, conforme mostrado na Figura 3.18. O método sendValue recebe como parâmetros o dado coletado pelo dispositivo usando o SNMP e o endereço para o qual ele deve ser enviado (i.e., o endereço do respectivo feed na EcoDiF). O dado recebido como parâmetro (armazenado na variável value) é estruturado no formato EEML, entre as linhas 7 e 19, fazendo uso da classe Eeml_Contract, implementada na EcoDiF e que define como dados devem ser estruturados nesse protocolo. Feito isso, os dados estruturados são efetivamente enviados para a EcoDiF via uma requisição HTTP PUT, através da chamada ao método httpPutContract (linha 21), que recebe como parâmetros o endereço do feed, informado pelo usuário como argumento de entrada, e o objeto representando o dado em EEML.

Figura 3.18. Trecho de código do driver referente ao método sendValue, que estrutura o dado coletado no formato EEML e o envia para a EcoDiF.



A Figura 3.19 mostra um trecho de representação EEML referente ao feed associado à temperatura de um switch H3C® em um CPD da Universidade Federal do Rio Grande do Norte (UFRN), em Natal, representação essa gerada automaticamente pelo driver SNMP após coletar a respectiva informação acerca da temperatura atual do equipamento. Na linguagem EEML, feeds são descritos através do elemento environment (linha 2), que representa os dados do ambiente que está sendo monitorado. Esse elemento estrutura informações que descrevem o feed (e.g., nome, descrição, localização, estado atual, conforme descrevem as linhas 3 a 12), bem como as informações aferidas pelo sensor de temperatura do switch. As medições individuais são organizadas na forma de datapoints (linhas 15 a 21), informando o valor aferido em um determinado instante de tempo. A representação EEML exibida na Figura 3.19 informa ainda que o valor de temperatura do switch aferido mais recentemente (elemento current_value, linha 14) foi 40º C, inferior a valores coletados em medições anteriores (elemento value, linhas 16 a 20).

Figura 3.19. Trecho de representação EEML referente à temperatura de um switch H3C® em um CPD da UFRN.

3) Desenvolvimento de aplicação mashup em EMML Por fim, uma vez que a EcoDiF já está recebendo dados provenientes dos dispositivos integrados à plataforma através dos respectivos drivers, aplicações mashup escritas na linguagem EMML podem ser criadas para fazer uso de tais dados, desde a simples exibição deles de forma agregada através de uma página Web até a realização de tarefas mais complexas, que podem envolver, por exemplo, o processamento desses dados e consequente geração de novas informações de valor agregado para os usuários.

A título de exemplo, foi desenvolvida uma aplicação mashup que possui como objetivo monitorar diferentes variáveis referentes a um switch H3C® em um CPD da UFRN. Esses dados, disponibilizados na EcoDiF na forma de feeds e obtidos pelo driver SNMP anteriormente descrito, são recuperados pela aplicação por meio de requisições HTTP GET à plataforma e organizados em uma página Web, a ser exibida na interface Web da EcoDiF. A Figura 3.20 mostra um trecho de código na linguagem EMML que implementa a aplicação em questão. Através da diretiva directinvoke, a



aplicação realiza requisições HTTP GET aos endereços dos feeds que armazenam os dados referentes a temperatura e porcentagem de uso de processamento do switch monitorado (linhas 18-20 e 24-26, respectivamente), armazenando os resultados em variáveis declaradas no mashup, respectivamente feed1 (declarada na linha 11) e feed2 (declarada na linha 13). Nas linhas 30 a 46, o mashup constrói uma estrutura baseada em XML para organizar os dados obtidos através das requisições HTTP GET, utilizando as diretivas <constructor> e <append>. A fim de obter não apenas o valor dos feeds (no caso, temperatura e porcentagem de uso de processamento), mas também outras informações relevantes para serem exibidas, é possível navegar sobre o documento XML armazenado nas variáveis feed1 e feed2 utilizando expressões XPath (XML Path Language)43. Por exemplo, as expressões XPath especificadas nas linhas 35 a 37 navegam sobre o documento EEML representando o feed de temperatura (feed1) a fim de recuperar a descrição, (description), valor atual (value) e unidade (unit) desse feed. Por fim, essa nova estrutura XML resultante da agregação das informações dos feeds de temperatura e porcentagem de uso de processamento são tratadas por um script XSL (Extensible Stylesheet Language)44, uma linguagem para processamento de documentos baseados em XML. Esse script recebe como entrada a estrutura XML que foi construída e retorna o código HTML a ser renderizado na interface Web da EcoDiF como resultado da execução do mashup, armazenado na variável de saída result (linha 50).

43 XML Path Language (XPath) 3.0: http://www.w3.org/TR/xpath-30/ 44 The Extensible Stylesheet Language Family (XSL): http://www.w3.org/Style/XSL/



Figura 3.20. Trecho de código EMML referente à aplicação que agrega dados coletados de um switch H3C® em um CPD na UFRN.

A Figura 3.21 mostra uma captura de tela da interface Web da EcoDiF com o resultado da execução da aplicação. Na EcoDiF, aplicações mashup escritas em EMML são processadas pelo motor de execução da linguagem, implantado na plataforma, e o resultado de tal execução é renderizado em sua interface Web. Através dessa interface, os usuários podem acompanhar, em tempo real, o estado de diferentes variáveis referentes ao switch, tais como temperatura e porcentagem de uso de processamento, bem como medidas coletadas pelas interfaces de rede do equipamento, e.g., número de octetos de entrada e saída, e número de pacotes de saída em estado de falha.



Figura 3.21. Exibição da aplicação de gerenciamento de um switch H3C em um CPD da UFRN, através do portal Web da EcoDiF.

3.5.2. Sensoriamento Participativo A proliferação de dispositivos móveis conectados à Internet permite a coleta de diversos tipos de informação acerca do ambiente, tempo, tráfego, pessoas etc. a um custo relativamente baixo [Goldman et al. 2009]. Nessa perspectiva, o conceito de sensoriamento participativo (participatory sensing, em Inglês) [Burke et al. 2006] surgiu como uma forma sistemática de recuperar tais informações enfatizando o envolvimento ativo dos usuários como provedores desses dados, que podem ir desde observações pessoais à combinação de dados providos por milhares de indivíduos acerca do local onde vivem [Campbell et al. 2008]. Através de redes de sensores e/ou redes móveis, usuários espalhados por um determinado lugar, por uma cidade ou mesmo pelo mundo, podem prontamente enviar dados a servidores, que os processam e eventualmente os integram com outros tipos de dados, tais como mapas de sistemas de informações geográficas e relatórios meteorológicos. Nos últimos anos, essa abordagem de sensoriamento participativo tem se mostrado bastante útil em diversos cenários, a exemplo de planejamento de transportes, saúde pública, e sustentabilidade ambiental.

Um exemplo de aplicação em sensoriamento participativo é a estimativa de presença de público em determinados ambientes com o objetivo de melhor prover recursos de acordo com a quantidade de pessoas neles presentes. Em uma conferência,



por exemplo, pode ser interessante saber quantas pessoas participaram das diversas sessões do evento (workshops, tutoriais, sessões técnicas, etc.) ou obter informações acerca de parâmetros do ambiente, tais como temperatura, luminosidade e ruído. Nesse cenário, foi desenvolvida uma aplicação que visava informar a quantidade de pessoas nas salas de um centro de convenções no qual estava ocorrendo uma conferência. Para fins de validação, participantes da conferência voluntariamente fizeram o download e instalação de um driver passivo, implementado como um aplicativo para o sistema operacional Android (versão 2.3 Gingerbread ou superior) e disponibilizado publicamente para download através da Google Play Store45. A principal função desse aplicativo era ler códigos QR (QR codes)46 fixados nas salas do prédio no qual estava ocorrendo a conferência e mostrar para os usuários as atividades programadas para a respectiva sala e horário no qual eles fizeram a leitura do código QR. No contexto de sensoriamento participativo, dado que os usuários geralmente proveem informações de maneira voluntária, haver algum tipo de retorno às ações por eles realizadas (retorno esse que possua um valor agregado para tais usuários) é importante para que os motive a estarem envolvidos no provimento das informações necessárias aos sistemas que irão fazer uso delas. Dessa forma, a disponibilização da programação atualizada do evento de acordo com o local/horário do check-in foi uma forma encontrada para incentivar as pessoas que estavam presentes a participarem da demonstração.

Ao executar o aplicativo, os usuários apontavam a câmera dos seus dispositivos (smartphones e/ou tablets) para os códigos QR e, feito isso, os dados de localização eram estruturados no formato EEML e enviados à EcoDiF através de requisições HTTP PUT, a fim de registra-los na plataforma. De modo ideal, o sensor de GPS dos dispositivos poderia ser utilizado para prover a localização dos usuários, porém devido à imprecisão de leitores GPS em ambientes fechados, optou-se por prover tal informação através da leitura dos códigos QR contendo a informação de sua localização. A fim de utilizar as informações de localização providas pelos usuários, foi desenvolvida uma aplicação mashup que recupera tais dados na EcoDiF na forma de feeds. Como resultado, a aplicação exibe um mapa de presença (similar a uma planta do prédio) com o número de participantes presentes às sessões da conferência, conforme mostrado na Figura 3.22.

45 Google Play Store: https://play.google.com/store 46 QR code: http://en.wikipedia.org/wiki/QR_code



Figura 3.22. Mapa de presença referentes às salas de uma conferência exibido através da interface Web da EcoDiF.

3.5.3. Monitoramento de redes de dutos de água e gás A aplicação desenvolvida neste contexto possui como objetivo monitorar o fluxo de água e gás em redes de dutos de companhias públicas da cidade do Rio de Janeiro. Para permitir a coleta de dados, sensores Dialog 3GTM Universal47 foram implantados nos dutos a serem monitorados a fim de medir a vazão desses fluidos em tais dutos. Uma vez coletados, os dados mensurados são estruturados por um driver construído para esse tipo de sensor no formato EEML e, em seguida, enviados à EcoDiF em tempo real. Dessa forma, usuários (a exemplo de operadores e gerentes das companhias proprietárias dos dutos) podem visualizar as últimas medidas aferidas pelos sensores através da interface Web da EcoDiF, bem como podem ser notificados em caso de condições anormais de operação quando, por exemplo, os valores mensurados indicam um possível vazamento de água/gás no duto.

A Figura 3.23 mostra os últimos dados mensurados referente ao fluxo de gás em um duto na Cinelândia, no Centro da cidade do Rio de Janeiro, coletados pelos sensores Dialog 3GTM Universal e enviados à EcoDiF. No gráfico exibido, é possível observar que o fluxo de gás mantém-se em um valor constante (14,66 m3/s), indicando que o duto está sob condições normais de operação.

47 Dialog 3GTM Universal: http://aradtec.com/Product.aspx?ID=6



Figura 3.23. Monitoramento de um duto de gás no Centro da cidade do Rio de Janeiro através da interface Web da EcoDiF.

3.5.4. Monitoramento remoto de pacientes No contexto de e-health, sensores corporais são pequenos dispositivos implantados no corpo humano ou sob a roupa e que são geralmente utilizados para coletar diversos dados relativos aos sinais vitais de quem os utiliza [Yuce 2013]. Esses sensores possuem capacidades de comunicação sem fio, aumentando assim o conforto e a mobilidade do usuário e não impedindo suas atividades normais enquanto o monitoramento é realizado [Sebestyen et al. 2014]. Nessa perspectiva, tais dispositivos são capazes de contribuir para o aumento da qualidade de serviços médicos pelo fato de permitir, a um custo relativamente baixo, a detecção de situações de emergência de



maneira mais rápida, bem como um diagnóstico mais preciso a ser elaborado por profissionais de saúde. Os dados provenientes de sensores corporais podem fornecer importantes informações acerca das condições de saúde atuais de um paciente. A título de exemplo, o monitoramento da temperatura corporal pode ser útil para detectar infecções e doenças, de modo que tal monitoramento constante permite melhor administrar o medicamento adequado. Por outro lado, outros sensores poderiam ser utilizados para confirmar alguns sintomas detectados com base na aferição da temperatura ou frequência respiratória. Através do uso de um sensor de eletrocardiograma (ECG) e da verificação da frequência de batimentos cardíacos, é possível identificar uma variedade de problemas de saúde que podem afetar um paciente, confirmando a sua condição clínica. Entretanto, a inerente heterogeneidade dos sensores que podem ser empregados dificulta a utilização sistêmica desses dados que, uma vez, combinados, permitiriam um diagnóstico mais preciso por parte dos médicos. Dessa forma, uma plataforma de middleware para IoT como a EcoDiF desempenha um papel fundamental nesse cenário, por permitir a integração desses diferentes sensores corporais acoplados a um paciente e agregação das informações por eles providas, ao mesmo tempo que possibilita monitorar, em tempo real, seus sinais vitais, e disparar alertas em caso de condições anormais.

Nessa prova de conceito, três sensores corporais foram acoplados a um voluntário para monitoramento de seus sinais vitais e disponibilização destes na plataforma, conforme ilustrado na Figura 3.24: (i) um sensor de respiração, através de uma máscara fixada no nariz do indivíduo, para medir ciclos de inalação/exalação em intervalos de um minuto; (ii) um sensor de temperatura, fixado no braço do indivíduo, e; (iii) um sensor de ECG com eletrodos fixados no tórax do indivíduo para a medição de batimentos cardíacos por minuto (BPMs). Dessa forma, os dados coletados pelos sensores são enviados à EcoDiF, que permite acompanhar as condições atuais do paciente com base em tais dados.

Figura 3.24. Ilustração do monitoramento remoto de respiração, temperatura e batimentos cardíacos de um paciente, com envio e disponibilização de dados para a EcoDiF.

Para possibilitar a comunicação desses dispositivos com a EcoDiF, os sensores de temperatura, respiração e ECG foram conectados a um shield Cooking Hacks e-



Health Sensor48 acoplado a uma placa de prototipação Arduino Uno49, combinação essa que permite a integração de diversos tipos de sensores biométricos. Os batimentos cardíacos, a temperatura corporal e a frequência respiratória do indivíduo monitorado foram registrados na EcoDiF como feeds, de modo que um driver ativo desenvolvido para o Arduino Uno (i) coleta os dados aferidos pelos sensores, (ii) estrutura-os no formato EEML, e (iii) envia-os via requisições HTTP PUT para que sejam armazenados na plataforma. Com isso, através da interface Web da EcoDiF, é possível visualizar o histórico de eventos e as variações ocorridas nas medidas aferidas para cada variável. No caso da medição de batimentos cardíacos, os dados históricos disponibilizados pela EcoDiF também podem fornecer informações acerca de períodos nos quais o paciente manteve-se em alta e baixa atividade durante o dia, sendo possível, por exemplo, determinar seu consumo calórico. A Figura 3.25 apresenta a leitura dos valores referentes aos batimentos cardíacos do indivíduo monitorado em um intervalo de três minutos.

Figura 3.25. Histórico de monitoramento dos batimentos cardíacos de um paciente visualizado através da interface Web da EcoDiF.

3.6. Conclusão A ideia básica por trás do conceito de IoT é a presença generalizada de uma variedade de objetos (tais como etiquetas RFID, sensores, atuadores, telefones celulares, etc.) que, através de esquemas de endereçamento único e outros mecanismos de suporte baseados em padrões e protocolos ubíquos, são capazes de interagir uns com os outros e cooperar com seus vizinhos para alcançar objetivos comuns. Dessa forma, esse paradigma tem o potencial de contribuir em vários aspectos da vida contemporânea, propiciando uma vasta gama de aplicações que facilitem tarefas cotidianas. Domínios de aplicação como domótica, ambientes de vida assistida, monitoramento ambiental, automação industrial, transporte inteligente e gestão de negócios são apenas alguns dos possíveis cenários de aplicação em que esse novo paradigma irá desempenhar papeis primordiais em um futuro próximo.

48 e-Health Sensor Platform v2.0 for Arduino and Raspberry Pi: http://goo.gl/tdRDzr. 49 Arduino Uno: http://arduino.cc/en/Main/arduinoBoardUno.



Diversos avanços tecnológicos nas últimas décadas permitiram a emergência do paradigma de IoT. Contudo, muitas questões desafiadoras ainda precisam ser abordadas e vários obstáculos tecnológicos ainda precisam ser suplantadas para a concretização e a ampla utilização desse paradigma. Tais desafios, anteriormente mencionados, vão desde soluções que permitam a interoperação e a integração dos diversos componentes que compõem os ambientes de IoT até a facilitação do desenvolvimento de aplicações para esses ambientes, passando por questões relativas à escalabilidade por conta do grande número de objetos (coisas) envolvidos e do grande número de eventos que podem ser gerados espontaneamente por esses mesmos objetos. Além disso, os objetos que irão compor a IoT são caracterizados por baixos recursos computacionais e de energia. Consequentemente, as soluções propostas precisam ter especial consideração por questões relativas à eficiência dos recursos. Nesse contexto, plataformas de middleware devem satisfazer a um conjunto de requisitos a fim de satisfazer as demandas dos desafios apresentados. Questões de interoperabilidade, descoberta e gerenciamento de dispositivos, interfaces de comunicação, ciência de contexto, escalabilidade, gerenciamento de dados, segurança e adaptação dinâmica emergem frequentemente na literatura. Neste capítulo, discutiu-se como arquiteturas de referência e plataformas de middleware existentes lidam com esses desafios e foram apontadas suas deficiências. Tais deficiências indicam que o estado da arte para plataformas de middleware no contexto de IoT ainda não permite a plena concretização desse paradigma, fomentando a emergência de novas plataformas de middleware que abordem os requisitos levantados por completo. Por fim, a utilização de uma plataforma de middleware, a EcoDiF, foi demonstrada através de uma série de estudos de caso, comprovando os potenciais benefícios que tais plataformas podem oferecer.

Referências Angelov, S., Grefen, P., Greefhorst, D. (2009) “A classification of software reference

architectures: Analyzing their success and effectiveness”. Proceedings of the 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture. USA, IEEE, pp. 141-150.

Atzori, L., Iera, A., and Morabito, G. (2010) “The Internet of Things: A survey”. Computer Networks vol. 54, no. 15, pp. 2787-2805.

Bassi, A., Bauer, M., Fiedler, M., Kramp, T., van Kranenburg, R., Lange, S., Meissner, S. eds. (2013) “Enabling things to talk: Designing IoT solutions with the IoT Architectural Reference Model”. Germany, Springer Berlin Heidelberg.

Bandyopadhyay, S., Sengupta, M., Maiti, S., & Dutta, S. (2011) “Role of middleware for internet of things: A study”. International Journal of Computer Science & Engineering Survey, vol. 2, no. 3, pp. 94-105.

Bernstein, P. A. (1996) “Middleware: a model for distributed system services”. Communications of the ACM, vol. 39, no. 2, 86-98.

Burke, J. A., Estrin, D., Hansen, M., Parker, A., Ramanathan, N., Reddy, S., & Srivastava, M. B. (2006) “Participatory Sensing”. Proceedings of the First Workshop on World-Sensor-Web: Mobile Device Centric Sensory Networks and Applications. USA, ACM.



Campbell, A. T. et al. (2008) “The rise of people-centric sensing”, IEEE Internet Computing, vol. 12, no. 4, pp. 12-21.

Case, J., Fedor, M., Schoffstall, M., Davin, J. (1990) “A Simple Network Management Protocol (SNMP) – RFC 1157”. USA, IETF.

Chaqfeh, M. A., Mohamed, N. (2012) “Challenges in middleware solutions for the Internet of Things”, Proceedings of the 2012 International Conference on Collaboration Technologies and Systems. USA: IEEE, pp. 21-26.

Chen, M., Mao, S., Liu, Y. (2014) “Big Data: A survey”, Mobile Networks and Applications, vol. 19, no. 2, pp. 171-209.

Cloutier, R., Muller, G., Verma, D., Nilchiani, R., Hole, E., Bone, M. (2010) “The concept of reference architectures”. Systems Engineering, vol. 13, no. 1, pp. 14-27.

Delicato, F.C., Pires, P.F., Batista, T. (2013a) “Middleware solutions for the Internet of Things”. United Kingdom, Springer London.

Delicato, F. C., Pires, P. F., Batista, T., Cavalcante, E., Costa, B., Barros, T. (2013b) “Towards an IoT ecosystem”. Proceedings of the First International Workshop on Software Engineering for Systems of Systems. USA, ACM, pp. 25-28.

Dey, A. K. (2001) “Understanding and using context”, Personal and Ubiquitous Computing, vol. 5, no. 1, pp. 4-7.

Fielding, R. (2000) “Architectural styles and the design of network-based software architectures”. PhD dissertation, University of California at Irvine, USA.

Fremantle, P. (2014) “A reference architecture for the Internet of Things – version 0.8.2”. Whitepaper, WSO2, USA.

Gao, L., Zhang, C., Sun, L. (2011) “RESTful Web of Things API in sharing sensor data”, Proceedings of the 2011 International Conference on Internet Technology and Applications. USA, IEEE, pp. 1-4.

Gartner (2014) “Gartner says 4.9 billion connected ‘things’ will be used in 2015’, http://www.gartner.com/newsroom/id/2905717.

Goldman, J. et al. (2009) “Participatory Sensing: A citizen-powered approach to illuminating the patterns that shape our world”. Whitepaper, Woodrow Wilson International Center for Scholars, USA.

Guinard, D., Trifa, V. (2009) “Towards the Web of Things: Web mashups for embedded devices”, Proceedings of the 2nd Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web.

Katasonov, A., Terziyan, V. (2008) “Semantic agent programming language (S-APL): A middleware platform for the Semantic Web”, Proceedings of the 2008 IEEE International Conference on Semantic Computing. USA, IEEE, pp. 504-511.

Le-Phuoc, D., Nguyen-Mau, H. Q., Parreira, J. X., Hauswirth, M. (2012) “A middleware framework for scalable management of linked streams”, Web Semantics: Science, Services and Agents on the World Wide Web, vol. 16, pp. 42-51.

Muller, G. (2008) “A reference architecture primer”. Whitepaper, Embedded Systems Institute, The Netherlands.



Nagy, M., Katasonov, A., Szydlowski, M., Khriyenko, O., Nikitin, S., Terziyan, V. (2009) “Challenges of middleware for the Internet of Things”. In: Rodic, A. D., ed. Automation & control – Theory and Practice. Croatia, InTech.

Nakagawa, E. Y., Antonino, P. O., Becker, M. (2011) “Reference architecture and product line architecture: A subtle but critical difference”. In: Crnkovic, I., Gruhn, V., Book, M., eds. Proceedings of the 5th European Conference on Software Architecture. Lecture Notes in Computer Science, vol. 6903. Germany, Springer Berlin Heidelberg, pp. 207-211.

Nakagawa, E. Y., Oquendo, F., Maldonado, J. C. (2014) “Reference architectures”. In: Oussalah, M. C., ed. Software Architecture 1. United Kingdom, ISTE Ltd / John Wiley & Sons, Inc., pp. 55-82.

Pautasso, C., Zimmermann, O., Leymann, F. (2008) “RESTful Web services vs. ‘big’ Web services: Making the right architectural decision”, Proceedings of the 17th International Conference on the World Wide Web. USA, ACM, pp. 805-814.

Perera, C., Zaslavsky, A., Christen, P., Georgakopoulos, D. (2014) “Context aware computing for the Internet of Things: A survey”, IEEE Communications Surveys & Tutorials, vol. 16, no. 1, pp. 414-454.

Pires, P. F., Cavalcante, E., Barros, T., Delicato, F. C., Batista, T., Costa, B. (2014) “A platform for integrating physical devices in the Internet of Things”, Proceedings of the 12th IEEE International Conference on Embedded and Ubiquitous Computing. USA, IEEE, pp. 234-241.

Qin, W., Li, Q., Sun, L., Zhu, H., Liu, Y. (2011) “RestThing: A Restful Web service infrastructure for mash-up physical and Web resources”, Proceedings of the 9th IFIP International Conference on Embedded and Ubiquitous Computing. USA, IEEE, pp. 197-204.

Rozanski, N., Woods, E. (2011) “Software systems architecture: working with stakeholders using viewpoints and perspectives”. Addison-Wesley.

Sebestyen, G., Hangan, A., Oniga, S., Gal, Z. (2014) “eHealth solutions in the context of Internet of Things”, Proceedings of the 2014 International Conference on Automation, Quality and Testing, Robotics. Romania, IEEE, pp. 1-6.

Soldatos, J., Serrano, M., Hauswirth, M. (2012) “Convergence of Utility Computing with the Internet-of-Things”, Proceedings of the 6th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing. USA, IEEE, pp. 874-879.

Teixeira, T., Hachem, S., Issarny, V., Georgantas, N. (2011) “Service oriented middleware for the Internet of Things: A perspective”. In: Abramowicz, W., Llorente, I. M., Surridge, M., Zisman, A., Vayssière, J., eds. Proceedings of the 4th European Conference on Towards a Service-Based Internet. Lecture Notes in Computer Science, vol. 6994. Germany, Springer Berlin Heidelberg, pp. 220-229.

Tracey, D., Sreenam, C. (2013) “A holistic architecture for the Internet of Things, sensing services, and Big Data”, Proceedings of the 13th IEEE/ACM International Symposium on Cluster, Cloud, and Grid Computing. USA, IEEE, pp. 546-553.



Vega-Barbas, M., Casado-Mansilla, D., Valero, M. A., López-de-Ipina, D., Bravo, J., Florez, F. (2012) “Smart spaces and smart objects interoperability architecture (S3OiA)”, Proceedings of the 6th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing. USA, IEEE, pp. 725-730.

Yuce, M. R. (2013) “Recent wireless body sensors: Design and implementation”. Proceedings of the 2013 IEEE MTT-S International Microwave Workshop Series on RF and Wireless Technologies for Biomedical and Healthcare Applications. USA, IEEE Computer Society, pp. 1-3.

Zanella, A., Bui, N., Castellani, A., Vangelista, L., Zorzi, M. (2014) “Internet of Things for smart cities”, IEEE Internet of Things Journal, vol. 1, pp. 22-32.



Capítulo

4NetFPGA: Processamento de Pacotes em Hardware

Pablo Goulart, Ítalo Cunha, Marcos A. M. Vieira (UFMG)Cesar Marcondes, Ricardo Menotti (UFSCar)

Abstract

The NetFPGA platform allows general-purpose network packet processing in hard-ware. NetFPGAs can be used to develop research prototypes and deploy new networkfunctionality. This tutorial will present NetFPGA’s hardware architecture, its program-ming interface, and possible applications. We will demonstrate all steps in the imple-mentation and deployment of a hardware firewall to filter packets depending on the TCPdestination port. The concepts covered in this tutorial will help researchers and program-mers use the NetFPGA with any of its available modules as well as develop new hardwarepacket processing modules.

Resumo

A plataforma NetFPGA permite processamento genérico de pacotes de rede emhardware. A NetFPGA pode ser utilizada para desenvolvimento de protótipos de pesquisabem como implantação de novas funcionalidades. Este minicurso apresentará a arqui-tetura de hardware da NetFPGA, a interface de programação e possíveis aplicações daNetFPGA. Iremos demonstrar passo-a-passo a implementação de um firewall para filtra-gem de pacotes em hardware em função da porta de destino do protocolo TCP. Os con-ceitos do minicurso irão permitir pesquisadores e programadores utilizarem a NetFPGAcom módulos existentes, bem como desenvolverem novos módulos para processamento depacotes em hardware.

4: NetFPGA: Processamento de Pacotes em Hardware.


4.1. IntroduçãoComutadores (switches) e roteadores (routers) atuais suportam uma quantidade limitadade arquiteturas e protocolos de rede. Mesmo para as arquiteturas e protocolos suportados,comutadores e roteadores permitem processamento limitado dos pacotes, como decre-mento do TTL, verificação do checksum, balanceamento de carga e descarte. Esta faltade flexibilidade dificulta a avaliação e implantação de mecanismos como OpenSketch [Yuet al. 2013], de protocolos alternativos como Free-riding Multicast [Ratnasamy et al.2006] e de novas arquiteturas como XIA [Han et al. 2012], CCN [Jacobson et al. 2009],ou SDN [Casado et al. 2009]. O caminho padrão para avaliação e implantação dessassoluções seria desenvolver novas placas de rede e processadores de pacotes específicosem hardware (ASICs), o que é economicamente inviável.

A NetFPGA é uma plataforma aberta que combina um FPGA (field-programmablegate array, ou arranjo de portas programável em campo) memória (SRAM e DRAM) eprocessadores de sinais numa placa com quatro portas Ethernet de 1 Gbps ou 10 Gbps.Desenvolvedores podem programar o FPGA e utilizar a memória para implementar novosmecanismos, protocolos e arquiteturas. A NetFPGA permite modificação dos pacotes emtrânsito, controle total sobre o encaminhamento e manutenção de estado.

A NetFPGA é particularmente útil como uma alternativa de hardware flexível e debaixo custo para avaliação de protótipos de pesquisa. NetFPGAs já foram utilizadas emvários projetos de pesquisa (e.g., [Yu et al. 2013,Naous et al. 2008a,Ghani and Nikander2010, Thinh et al. 2012, Antichi et al. 2012, Lombardo et al. 2012]). Comparada coma abordagem de implementar soluções em software, a NetFPGA garante processamentoe encaminhamento na taxa de transmissão das interfaces (sem sacrificar banda), baixalatência e não onera a CPU do computador.

Neste texto, introduziremos o leitor à NetFPGA. Na seção 4.2 iremos demonstrarnosso firewall em funcionamento do ponto de vista do usuário e descreveremos como con-figurar o ambiente de desenvolvimento da NetFPGA. Na seção 4.3 iremos apresentar asarquiteturas de hardware e software da NetFPGA, dando uma visão geral das funcionali-dades e do desenvolvimento na NetFPGA. Na seção 4.4 iremos demonstrar passo-a-passoa criação de um novo módulo na NetFPGA. Usaremos como exemplo um firewall para fil-tragem de pacotes em hardware em função da porta de destino do protocolo TCP. Nossofirewall é um exemplo didático que cobre a maior parte dos conceitos necessários paradesenvolvimento de um novo projeto, como utilização de memória bem como processa-mento e modificação de pacotes. Por fim, na seção 4.5 iremos discutir outros projetosutilizando a NetFPGA. Acreditamos que os conceitos do minicurso irão permitir pes-quisadores e programadores utilizarem a NetFPGA com módulos existentes bem comodesenvolverem novos módulos para processamento de pacotes em hardware.



4.2. Visão do usuário da aplicação exemplo: um firewall na NetFPGANesta seção iremos explicar como preparar o ambiente de desenvolvimento para NetFPGAe iremos exemplificar a aplicação exemplo que iremos implementar, um firewall. Nossofirewall é detectado pelo sistema operacional como uma interface de rede Ethernet pa-drão. Esta interface pode ser configurada com um endereço IP e transmitir pacotes derede normalmente. Porém, podemos também configurar a interface do firewall para filtrarpacotes TCP destinados a um conjunto de portas que queremos bloquear. Nosso firewallfaz o processamento e filtragem dos pacotes TCP na NetFPGA, sem consumir capacidadede processamento no computador hospedeiro. As portas que queremos bloquear podemser configuradas dinamicamente por programas de espaço do usuário, ou seja, sem a ne-cessidade de reconfiguração do FPGA.

A maioria dos comandos mostrados nesta seção devem ser digitados no terminaldo Linux como superusuário (root). Quando se tratar de comandos a serem incluídos oumodificados em arquivos o caminho completo destes será fornecido.

4.2.1. Preparação do ambiente de desenvolvimento

Nesta seção apresentamos o ambiente de desenvolvimento da NetFPGA. Mostramos comoconfigurar o ambiente de desenvolvimento num computador e utilizamos nosso firewallpara demonstrar passo-a-passo a utilização do ambiente de desenvolvimento.

As instruções são baseadas na documentação oficial da NetFPGA,1 com algumasadições para tratar possíveis dificuldades durante a configuração do ambiente. O nossoambiente de desenvolvimento é baseado no Fedora Linux 13 (32-bits)2 e no Xilinx ISE10.1,3 que são recomendados para uso com a NetFPGA; mas é possível utilizar outrasdistribuições e versões da ferramenta. Fique atento ao consultar a documentação oficial,pois na documentação oficial encontramos instruções relativas a diferentes versões daNetFPGA; em nosso curso usamos a NetFPGA 1G.

A forma mais prática de se obter um ambiente de simulação é fazendo o down-load de uma máquina virtual (VM) pré-configurada. Nas instruções a seguir apresentamoscomo configurar uma máquina virtual. As instruções para instalação de uma máquina vir-tual também se aplicam para a instalação e configuração de uma máquina real, inclusivecom uma placa (hardware) NetFPGA. Neste tutorial utilizamos o VirtualBox4 para exem-plificar a configuração de uma máquina virtual pois este está disponível para Windows,Linux e Mac. Se quiser configurar uma máquina real, grave a imagem do Fedora em umCD ou DVD para posterior instalação.

4.2.1.1. Criação de uma máquina virtual

Nesta seção descrevemos como criar uma máquina virtual no VirtualBox para instalar oambiente de desenvolvimento. Se você deseja instalar uma máquina real inicie o compu-tador a partir do CD ou DVD do Fedora e siga para a seção 4.2.1.2.

1https://github.com/NetFPGA/netfpga/wiki/Guide2http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/13/Live3http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools/archive.html4https://www.virtualbox.org



Instale o VirtualBox em seu sistema, execute-o e abra o tutorial para criação deuma nova máquina virtual utilizando o menu Machine → New. Escolha um nome parasua máquina virtual (por exemplo, “NetFPGA”), configure o tipo de máquina virtual para“Linux” e a versão para “Fedora (32 bit).” No passo seguinte, selecione a quantidade dememória desejada para a máquina virtual. Sugerimos pelo menos 3 GiB para executar oXilinx ISE, mas você pode aumentar este valor se tiver memória disponível no sistemahospedeiro. Na próxima etapa, selecione a segunda opção para criar um novo disco vir-tual (Create a virtual hard drive now). Sugerimos o formato padrão para o disco virtual(VDI). Sugerimos também utilização de alocação dinâmica de espaço para que o discovirtual ocupe apenas o espaço necessário (Dynamically allocated). Para finalizar estaetapa, indique o mesmo nome da máquina virtual para facilitar a identificação do disco(por exemplo, “NetFPGA”) e selecione seu tamanho máximo. É recomendado selecionarum espaço razoável para o disco (pelo menos 20 GB). Como só será alocado o espaçonecessário, aumentar o tamanho máximo não implica custo.

Voltando à tela principal do VirtualBox, clique no botão Start para iniciar a má-quina criada. Na primeira inicialização o VirtualBox irá solicitar uma imagem de CD ouDVD de instalação, indique o arquivo da imagem do Fedora 13. Os passos seguintes sãoos mesmos, tanto para um sistema real quanto para a máquina virtual.

4.2.1.2. Instalação e configuração do sistema

A inicialização a partir do CD ou DVD Live carrega o sistema para a memória RAM, semfazer qualquer alteração no disco. Após a inicialização do sistema, selecione Install tohard drive para instalar o sistema no disco. Siga os passos necessários para selecionar odisco, determinar sua região e definir uma senha para o superusuário (root). Após finalizara instalação, selecione o comando de menu System→ Shut Down e reinicie o computador(Restart). Se estiver em uma máquina real, remova o CD ou DVD da unidade. Se estiverem uma máquina virtual, desligue o computador em vez de reiniciá-lo (Shut Down), váno gerenciador de armazenamento (menu Settings→ Storage) e remova a imagem de CDou DVD para iniciar a máquina virtual a partir do disco virtual.

Após reiniciar o sistema é necessário informar mais algumas configurações e criaruma conta de usuário. Para executar alguns dos comandos usados neste minicurso épreciso ter acesso de superusuário (root), especialmente aqueles que fazem modificaçõesno sistema. Por padrão, o Fedora não permite o login como root no modo gráfico. Paracontornar esta restrição é possível usar o comando su que permite a um usuário comumexecutar um shell como root. Se preferir modificar o sistema para permitir o login comoroot, faça login na conta de usuário, acesse o diretório /etc/pam.d/ e edite os arquivosgdm e gdm-password, comentando a seguinte linha em ambos:

auth required pam_succeed_if.so user != root quiet

Os passos seguintes devem ser executados como root, portanto faça login comoroot ou use o comando su para executar um shell como root. A primeira modificaçãonecessária em nosso sistema é desabilitar o Security-Enhanced Linux (SELinux). Paratal, edite o arquivo /etc/selinux/config e mude a variável SELINUX para disabled.



A seguir, faremos a instalação de alguns pacotes necessários. Acesse o diretório/etc/yum.repos.d/ edite cada um dos arquivos com extensão .repo trocando https dasURLs por http. Em seguida digite os seguintes comandos:

yum updateyum install gcc kernel-devel libnet-devel java-1.6.0-openjdk-devel

python-argparse scapy wget iverilog gtkwave hping3 iperf

Recomendamos também a instalação dos drivers para o VirtualBox através domenu Devices→ Insert Guest Additions CD Image.

4.2.1.3. Instalação das ferramentas

A seguir vamos configurar as ferramentas da Xilinx necessárias para utilização com aNetFPGA. Você precisará se registrar e obter algumas licenças. Faça o download do ISEFoundation 10.1 e depois das atualizações para o Service Pack 3 do ISE Foundations e ISEIP Update, todos para Linux 32-bit. Após descompactar o pacote com o ISE, a instalaçãopode ser feita executando o comando setup.5

tar xvf ise_SFD.tarise/setup

Escolha o caminho /opt/Xilinx/10.1 para a instalação, mantenha todas as op-ções selecionadas e aceite as licenças do software. Depois da instalação, é preciso fazera atualização da ferramenta a partir dos arquivos baixados anteriormente. Isso pode serfeito com os comandos abaixo. Nos instaladores é preciso apontar o caminho onde o ISEFoundation foi instalado, /opt/Xilinx/10.1/ISE.

unzip 10_1_03_lin.zip10_1_03_lin/setupunzip ise_101_ip_update3_install.zipise_101_ip_update3_install/setup

A plataforma NetFPGA 1G utiliza IP cores da Xilinx que são pagos, mas é possí-vel obter uma licença de avaliação por 120 dias. Ela permite simular os exemplos, sinte-tizar o hardware e testá-lo. Acesse http://www.xilinx.com/getlicense/, procure porEvaluation and No Charge Cores e clique em Search Now. A documentação da NetFPGAmenciona os cores DO-DI-PCI32-SP e DO-DI-TEMAC, mas estes foram descontinuados esubstituídos pelos cores EF-DI-PCI32-SP-PROJ e EF-DI-TEMAC-SITE, respectivamente.6

É preciso fazer a busca por estes códigos, adicioná-los à licença desejada e gerar um

5A licença para esta ferramenta deve ser obtida em https://secure.xilinx.com/webreg/register.do?

group=9_sw_regid_request. Selecione apenas ISE Foundation. Você receberá dois códigos, certifique-sede usar o correto, pois a ferramenta alterna automaticamente para a versão grátis se você usar o códigoerrado (WebPACK).

6Acesse http://www.xilinx.com/support/documentation/customer_notices/xcn09015.pdf para detalhes.



único arquivo com os dois itens. Durante o processo será solicitado um Host ID que é aidentificação única do seu computador, neste caso a partir do endereço físico da sua placade rede principal. Num terminal do Fedora 13 é possível obter este valor executando oprograma ifconfig.7 Já na primeira linha o valor desejado aparece depois de HWaddr.

eth0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX

O arquivo obtido deve ser salvo em /opt/Xilinx/Xilinx.lic. Adicione as se-guintes linhas no arquivo /root/.bashrc para que as ferramentas fiquem disponíveis nocaminho do sistema e para que encontrem o arquivo de licenças:

export LM_LICENSE_FILE=/opt/Xilinx/Xilinx.licsource /opt/Xilinx/10.1/ISE/settings32.sh

Finalmente, para instalar o software da NetFPGA e reiniciar o sistema usamos aseguinte sequência de comandos. Estes comandos irão configurar um novo repositóriono Fedora. A instalação do pacote netfpga-base irá instalar várias outras dependênciasnecessárias para utilização do software da NetFPGA.

rpm -Uhv http://netfpga.org/yum/el5/RPMS/noarch/netfpga-repo-1-1_CentOS5.noarch.rpmyum install netfpga-base/usr/local/netfpga/lib/scripts/user_account_setup/user_account_setup.plreboot

Após a reinicialização digite a seguinte sequência no terminal para concluir a ins-talação. Esta sequência irá preparar arquivos necessários para funcionamento do pacotede software da NetFPGA.

cd /root/netfpgamakemake install

Para fazer simulações de alguns exemplos é necessário baixar modelos de simu-lação das memórias presentes na placa. Para tal, edite e execute o seguinte programa,substituindo antes a URL na linha 20 por http://www.dcc.ufmg.br/~cunha/netfpga/256Mb_ddr2.zip.

/root/netfpga/lib/scripts/fetch_mem_models/fetch_mem_models.pl

7Se sua placa de rede for identificada por eth1 ou eth2 em vez de eth0 será necessário editar o arquivo/etc/udev/rules.d/70-persistent-net.rules para fazer a correção.



Se tudo estiver configurado adequadamente o comando a seguir deve executar asimulação de um dos exemplos disponíveis:

nf_test.py --isim --major loopback --minor crc sim

Este comando simulará o projeto apontado pela variável NF_DESIGN_DIR envi-ando pacotes de tamanhos variáveis para as quatro interfaces da NetFPGA, ligadas emloopback. A primeira execução pode levar um longo tempo se os módulos precisarem sersintetizados. Detalharemos o sistema de destes da plataforma NetFPGA na seção 4.4.5.

4.2.2. Utilização do firewall exemplo: passo-a-passo

Descompacte o pacote de software disponibilizado neste projeto.8 O pacote já contém aimagem que deve ser gravada na NetFPGA para configurá-la como uma placa de rede comum firewall integrado capaz de filtrar pacotes destinados a portas TCP específicas. Entreno diretório que contém as imagens de projetos que podem ser gravadas na NetFPGA eutilize o programa nf_download para realizar a gravação.

cd /root/netfpga/bitfilesnf_download firewall.bit

Se quiser sintetizar novamente a imagem do firewall que é gravada na NetFPGA,basta executar os seguintes comandos. Este processo é demorado e não é necessário.

cd /root/netfpga/projects/firewall/synthmake

Após execução do programa nf_download a NetFPGA está programada comoquatro interfaces de rede capazes de descartar pacotes TCP dependendo das portas dedestino. Pode-se configurar a interface de rede para funcionar normalmente no Linuxusando comandos como ifconfig.

ifconfig nf2c0 10.0.0.1 netmask 255.0.0.0

Para testar a placa, iremos utilizar o programa hping3. O programa hping3 per-mite gerar pacotes TCP para uma porta de destino passada como parâmetro.

hping3 -p 5151 10.0.0.2

O parâmetro 10.0.0.2 é o endereço IP de destino de outro computador alcançávelpor uma das interfaces da NetFPGA. O destino provavelmente responderá os pacotes

8Você pode obter o pacote no site do tutorial: http://www.dcc.ufmg.br/ cunha/netfpga/.



enviados pelo hping3 com pacotes ICMP port unreachable (porta não alcançável) oucom pacotes com o flag de reset ligado.9

É possível monitorar o fluxo de pacotes na interface de rede utilizando programascomo wireshark ou tcpdump. Estes programas capturam e mostram o conteúdo de todosos pacotes numa interface de rede. Pode-se executar o tcpdump na interface nf2c0 paraverificar que os pacotes TCP enviados pelo hping3 e as respostas de TCP reset estãopassando pela interface.

tcpdump -i eth0 -n host 10.0.0.1 and port 5151 -vv...12:24:21.326608 IP (ttl 63, id 20588, flags [none], proto TCP (6), length 40)

10.0.0.1.50082 > 10.0.0.2.5151: Flags [none], cksum 0x6245 (correct),seq 519591940, win 512, length 0

12:24:21.326635 IP (ttl 64, id 0, flags [DF], proto TCP (6), length 40)10.0.0.2.5151 > 10.0.0.1.50084: Flags [R.], cksum 0xb6d7 (correct),

seq 0, ack 1680124174, win 0, length 0...

O tcpdump permite a visualização do conteúdo dos pacotes transmitidos pelohping3 e as respostas do outro computador. Observamos, por exemplo, que o tempode vida (TTL, time to live) das sondas (primeiro pacote) têm TTL 63. Isto acontece porque nosso firewall decrementa o TTL de pacotes TCP que passam pelas interfaces. Issoilustra a possibilidade de modificar pacotes em tempo de processamento sem sacrificarbanda de rede, como será detalhado na seção 4.4.2.

Para verificar o correto funcionamento do firewall, pode-se configurar a NetFPGApara filtrar todos os pacotes TCP com porta 5151. Para isso, disponibilizamos o programade usuário chamado nffw que configura quais portas devem ser filtradas. O firewall deexemplo suporta filtrar até quatros portas distintas.

nffw 5151 22 25 80

Depois da execução do nffw, a NetFPGA filtrará todos os pacotes TCP com portade destino 5151, 22, 25 e 80. A NetFPGA não transmitirá os pacotes TCP gerados pelohping3 ao destino, o que pode ser verificado executando o tcpdump no destino. Comoo destino não recebe as sondas geradas pelo hping3, ele não responderá com pacotesTCP reset, o que é visível nas saídas do tcpdump e hping3 executando no computadorcom a NetFPGA. Note que o tcpdump na interface nf2c0 continua mostrando os pacotesenviados pelo hping3. Isto acontece porque o tcpdump funciona em cooperação com oLinux. A filtragem e descarte do pacote só acontece depois do Linux passar o pacote paraprocessamento no hardware da NetFPGA, onde o Linux não tem mais visibilidade nemcontrole sobre o processamento do pacote.

9O computador com IP 10.0.0.2 pode não responder com um pacote ICMP port unreachable ou TCPreset caso esteja com a porta 5151 aberta. Neste caso basta utilizar outro número de porta. O computadortambém pode não enviar respostas ICMP port unreachable se estiver configurado para não enviar pacotesICMP para esse tipo de erro.



Pode-se reconfigurar o firewall na NetFPGA dinamicamente reexecutando o co-mando nffw. Como exemplificado acima, as configurações podem ser testadas utilizandoprogramas como hping3 e tcpdump.

Também realizamos testes com o iperf, que faz troca bidirecional de pacotes.Configuramos a máquina com a NetFPGA com o firewall e o outro computador comum adaptador comum. Usamos o computador com a NetFPGA como cliente e o outrocomputador como servidor. Os pacotes serão enviados através da porta 5001 padrão doiperf. No servidor executamos iperf -s; no cliente observamos:

iperf -c 10.0.0.2 -i 1------------------------------------------------------------Client connecting to 10.0.0.2, TCP port 5001TCP window size: 16.0 KByte (default)------------------------------------------------------------[ 3] local 10.0.0.1 port 43905 connected with 10.0.0.2 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0- 1.0 sec 49.4 MBytes 414 Mbits/sec[ 3] 1.0- 2.0 sec 49.0 MBytes 411 Mbits/sec[ 3] 2.0- 3.0 sec 49.4 MBytes 414 Mbits/sec[ 3] 3.0- 4.0 sec 12.1 MBytes 102 Mbits/sec[ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec[ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec[ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec[ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec[ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec[ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec

Após três segundos executamos o nffw para bloquear todo o tráfego com portaTCP de destino 5001. Vemos que o tráfego é bloqueado instantaneamente. Na próximaseção iremos descrever a arquitetura da NetFPGA, conceitos que servirão de base para aimplementação passo-a-passo do firewall na seção 4.4.



4.3. Arquitetura da NetFPGANesta seção descrevemos a arquitetura de hardware e de software da NetFPGA. Apresen-tamos os componentes de hardware presentes na NetFPGA—FPGA (field-programmablegate array, ou arranjo de portas programável em campo), memórias e portas de rede—que podem ser utilizados para processar pacotes. Também descreveremos o software queacompanha a NetFPGA e que serve de base para desenvolvimento de novos projetos.

4.3.1. Hardware

O modelo clássico da NetFPGA, chamada também de NetFPGA 1G, possui quatro por-tas Ethernet 1 Gbps com processador de camada física da Broadcom. A NetFPGA pos-sui um FPGA Xilinx Virtex-II Pro 50 para processamento de pacotes, com dois núcleosPowerPC, 53.136 elementos lógicos e ciclo de relógio de 8 ns (125 MHz). O FPGA écapaz de processar pacotes recebidos pelas portas Ethernet em plena velocidade (8 Gbpsem modo de operação full-duplex). A NetFPGA possui também um controlador PCI quepermite programação e comunicação com o FPGA.

A NetFPGA possui dois bancos de memória SRAM Cypress com 219 linhas de36 bits cada (espaço total de 4608 KiB). A SRAM pode realizar uma operação de leituraou escrita por ciclo de relógio e retorna dados lidos em três ciclos de relógio. A SRAM éideal para aplicações que fazem acessos frequentes a pequenas quantidades de memória,como encaminhamento de pacotes e implementação de contadores SNMP.

A NetFPGA contém ainda dois bancos de memória DRAM Micron cada um com224 linhas de 16 bits, totalizando 64 MiB. A DRAM funciona de forma assíncrona e requeratualização (refreshing) contínua dos dados. Por estes fatores, o controlador da DRAMé significativamente mais complexo que o controlador da SRAM. Apesar da maior latên-cia, a DRAM tem vazão alta. A DRAM é ideal para aplicações que precisam de umaquantidade maior de memória, como armazenamento temporário (buffering) de pacotes.A DRAM também permite uma hierarquização da memória da NetFPGA. A Figura 4.1mostra uma visão geral da placa da NetFPGA.

A NetFPGA está disponível em outros modelos, todos com arquitetura de hard-ware similar composta de portas Ethernet, FPGA, memória SRAM e memória DRAM.As versões mais novas da NetFPGA suportam Ethernet 10 Gbps, FPGAs mais velozes ememórias de maior capacidade. Neste material iremos nos ater à NetFPGA 1G, que servecomo denominador comum e é de mais fácil acesso. Os conceitos e técnicas utilizados naNetFPGA 1G podem ser diretamente aplicados aos outros modelos de NetFPGA.

4.3.2. Software

A NetFPGA possui um pacote de software construído para facilitar o desenvolvimentode novos projetos. Apesar da NetFPGA permitir total flexibilidade no processamento depacotes, a arquitetura do hardware é fixa e impõe limitações. Como é de se esperar, osoftware da NetFPGA leva a arquitetura de hardware em consideração e apresenta umasérie de interfaces e abstrações que utilizamos para permitir modularização e comunica-ção entre módulos.



Figura 4.1. Componentes da NetFPGA.

4.3.2.1. Projetos de referência

A NetFPGA possui um conjunto de projetos de referência, que a fazem funcionar comouma placa de rede, um comutador Ethernet, ou um roteador IP. Nesta seção descrevemosos projetos de referência, que servem de base para desenvolvimento de projetos maiscomplexos.

Placa de rede de referência

A NetFPGA pode ser configurada como um conjunto de quatro interfaces de rede utili-zando o projeto reference_nic. Cada interface é identificada pelo Linux como nf2cX,com X variando de 0 a 3. Estas interfaces funcionam de forma análoga a interfaces de redecomo eth0, wlan0, e lo.

Pacotes de rede podem ser recebidos pelas interfaces nf2cX pela porta Ethernet,quando outro computador envia um pacote através da rede, ou pelo barramento PCI,quando o hospedeiro envia um pacote que deve ser transmitido pela rede. Para tratar o re-cebimento de pacotes, o reference_nic instancia oito módulos rx_queue para tratar rece-bimento de dados para cada interface da porta Ethernet e barramento PCI (4×2 = 8). Deforma análoga, o reference_nic instancia oito módulos tx_queue para tratar a transmis-são de pacotes por cada interface através da porta Ethernet e barramento PCI. Os módulosrx_queue e tx_queue fazem a interface entre o FPGA, o controlador MAC e o controladorPCI. A figura 4.2 mostra o pipeline completo de processamento do reference_nic, comos módulos rx_queue e tx_queue nas extremidades.

O processamento de pacotes na NetFPGA é realizado serialmente em um pipelinede múltiplos estágios. Pacotes de rede são retirados das filas de chegada (rx_queue) pelo



Figura 4.2. Pipeline de referência da NetFPGA configurada como interfaces derede padrão.

módulo input_arbiter. O input_arbiter decide qual fila de chegada deve ser servida,retira o pacote da fila e o coloca no pipeline de processamento. A política padrão deserviço é iterar sequencialmente através de todas as filas de chegada. Ao colocar o pacoteno pipeline de processamento, o input_arbiter adiciona um meta-cabeçalho ao pacoteindicando em qual porta ele chegou e o envia para o próximo módulo no pipeline deprocessamento.

O próximo módulo no pipeline é o output_port_lookup, que decide a porta desaída do pacote, adiciona essa informação no meta-cabeçalho do pacote e o envia para opróximo módulo no pipeline. A decisão da porta de saída do pacote em geral depende dosendereços IP e MAC do destino, mas podem depender também de outras propriedades dopacote. Por exemplo, em nosso firewall o destino de pacotes TCP depende da porta dedestino. O próximo módulo no pipeline é o output_queues, que demultiplexa o pacotedo pipeline de processamento nas filas de saída (tx_queue).

A interface de comunicação entre os módulos do pipeline de processamento, porexemplo como mostrado na figura 4.3, é padronizada. Existem sinais wr e rdy para con-trolar quando o módulo anterior está pronto para transmitir dados e quando o móduloposterior está pronto para receber, respectivamente. Transmissão de dados de pacotes sóacontece quando os dois sinais estão ligados. A interface tem ainda 8 linhas ctrl quecarregam sinais de controle e 64 linhas data que carregam dados. Quando ctrl é zeroestamos transmitindo dados do pacote. Quando ctrl é diferente de zero estamos trans-mitindo meta-cabeçalhos do pacote. Para cada meta-cabeçalho existe um valor de ctrlpré-definido.10 Desta forma, a NetFPGA processa até 64 bits de dados de pacote por ci-clo de relógio. Dado o ciclo de relógio de 8 ns, o processamento de um pacote de 1500 Bleva da ordem de 2 µs. A figura 4.3 ainda mostra que módulos podem ser logicamenteseparados em duas partes: uma fila para armazenamento temporário de dados e circuitopara processamento do pacote.

10Por exemplo, o meta-cabeçalho criado pelo input_arbiter com informações sobre a recepção de umpacote tem ctrl igual a IO_QUEUE_STAGE_NUM (0xFF).



Figura 4.3. Barramento de encaminhamento de pacotes.

Comutador de referência

O comutador de referência (reference_switch) reutiliza vários dos módulos apresenta-dos na descrição da placa de rede de referência. O único módulo com diferenças é ooutput_port_lookup. No comutador de referência, o módulo output_port_lookup as-socia o endereço MAC da origem à porta Ethernet de entrada toda vez que recebe umpacote. Esta associação é utilizada pelo output_port_lookup para decidir em qual portaEthernet enviar um pacote, verificando em qual porta o endereço MAC do destino foiobservado.

Roteador de referência

Assim como o comutador de referência, o roteador de referência (reference_router),também reutiliza vários módulos apresentados na descrição da placa de rede de referên-cia. O roteador de referência estende o módulo output_port_lookup para decidir a portae saída de pacotes consultando a tabela de roteamento. A tabela de roteamento é imple-mentada utilizando registradores no FPGA como memória ternária.11

Além de rotear pacotes utilizando a tabela de roteamento, o roteador de referênciaprecisa calcular rotas usando protocolos de roteamento como OSPF e BGP. Como essesprotocolos são muito complexos para serem implementados em hardware, eles são im-plementados em programas que executam no espaço do usuário. Em outras palavras, oroteador de referência implementa o encaminhamento de pacotes (plano de dados) emhardware e implementa o cálculo de rotas (plano de controle) em software.12 Como rotasprecisam ser recalculadas apenas quando há mudanças na topologia da rede, recalculá-lasem software não compromete a latência nem a vazão do encaminhamento de pacotes.

Protocolos de roteamento calculam o próximo roteador que deve ser utilizado paraencaminhar um pacote até seu destino. O próximo roteador no caminho é identificadopelo seu endereço IP. Para que o roteador de referência possa efetivamente encaminhar opacote para o próximo roteador, ele precisa converter o endereço IP do próximo roteadornum endereço MAC. Esta operação é realizada pelo protocolo ARP. O plano de controledo roteador de referência também executa o protocolo ARP para informar ao módulooutput_port_lookup quais endereços MAC devem ser utilizados no encaminhamento depacotes.

11O módulo que implementa esta funcionalidade está disponível em netfpga/lib/verilog/core/reference_router/cam_router.

12O programa que implementa o plano de controle do roteador de referência é chamado de SCONE e éarmazenado em netfpga/projects/scone/.



4.3.2.2. Estrutura de diretórios

Para facilitar a navegação do pacote de software da NetFPGA, mostramos abaixo a estru-tura de diretórios do pacote e uma breve descrição do conteúdo de cada diretório.

netfpga {Diretório raiz}bin {Scripts para simulação, síntese e geração de registradores}bitfiles {Diretório dos arquivos .bit dos projetos}lib {Bibliotecas de módulos e funções de simulação}C {Bibliotecas C}java {Biliotecas Java}Makefiles {Arquivos makefile pré-definidos para simulação/síntese}Perl5 {Bibliotecas Perl}python {Bibliotecas Python}release {Arquivos XML de configuração global}scripts {Scripts para configutação e testes da plataforma}verilog {Módulos em Verilog para síntese}contributed {Módulos Verilog de contribuidores}core {Módulos Verilog oficiais}

xml {Arquivos XML de módulos}projects {Diretório de projetos}

O diretório bin possui alguns programas de configuração do ambiente de progra-mação, sintetização de projetos bem como execução de simulações e testes. O diretóriobitfiles contém imagens de projetos depois de sintetizados, pontos para gravação naNetFPGA. Como exemplo, podemos configurar a NetFPGA com a placa de rede de refe-rência executando:

bin/nf_download bitfiles/reference_nic.bit

O diretório lib contém o código fonte do software. Por exemplo, o fonte doprograma nf_download é armazenado em netfpga/lib/C/download. Dentro do diretó-rio lib, o subdiretório lib/verilog/core armazena os módulos do núcleo da arquite-tura da NetFPGA. Os módulos do núcleo incluem módulos como rx_queue, tx_queue,input_arbiter, output_port_lookup, output_queues e vários outros.

A pasta projects contém os projetos montados pela NetFPGA. Cada projeto,inclusive os projetos de referência, seguem a seguinte árvore de diretórios.

projects<project> {Seu projeto}doc {Documentação}include {project.xml, XML de módulos criados}lib {Arquivos de cabeçalho Python, Perl e C}src {Módulos Verilog criados}sw {Programas para teste do projeto}synth {Diretório de arquivos de síntese}test {Programas para testes do hardware e software em Python}

O diretório doc é utilizado para armazenar documentação do projeto. A pastainclude é utilizada para armazenar os arquivos XML de configuração; por exemplo, estes



arquivos são lidos pelo programa nf_register_gen para alocação e mapeamento dos re-gistradores.13 A pasta lib contém os cabeçalhos C, Perl e Python necessários para utilizaros demais programas do software da NetFPGA com este projeto.14 A pasta src contémos módulos em Verilog implementados pelo usuário. Os módulos nesse diretório podemestender e ter o mesmo nome dos módulos disponíveis em netfpga/lib/verilog/core;neste caso, os módulos estendidos tem prioridade sobre as versões originais. As pastas swe test possuem programas e especificações de testes de regressão do projeto. Por último,a pasta synth contém arquivos de síntese do projeto. Iremos entrar em maiores detalhesdas informações relativas a um projeto e novos módulos Verilog na seção 4.4.

4.3.3. Interação hardware–software

Para facilitar a interação entre os componentes de hardware e software, o projeto daNetFPGA possui algumas interfaces. Aqui descrevemos a interface de registradores ede memória que servem para ler e escrever dos registradores e componentes de memória,respectivamente.

4.3.3.1. Interface de registradores

O software da NetFPGA define três tipos de registradores: contadores, registradores desoftware e registradores de hardware. Registradores armazenam valores arbitrários. Con-tadores suportam as operações de incremento, decremento, e zerar-ao-ler (reset-on-read).Contadores podem ser escritos pela NetFPGA e lidos por um programa de usuário. Regis-tradores de software podem ser escritos por programas de usuário e lidos pela NetFPGAe registradores de hardware são escritos pela NetFPGA e lidos por programas de usuário.

Registradores de um módulo são definidos dentro do arquivo XML de configu-ração do modulo. O arquivo XML define as propriedades (tipo, nome e descrição) decada registrador do módulo. Há nove tipos de registradores pré-definidos no software daNetFPGA, mais um tipo vetor de tamanho variável, como mostrado na tabela 4.1.

TIPO BITS

ethernet_addr 48ip_addr 32counter32 32software32 32generic_counter32 32generic_hardware32 32generic_sofware32 32dataword 64ctrlword 8vetor variável

Tabela 4.1. Tipos de registradores e exemplos de definição.

13O arquivo include/project.xml define todos os módulos que serão instanciados no projeto, os demaisarquivos XML contém informações dos módulos implementados pelo usuário.

14Um exemplo de informação nos cabeçalhos C, Perl e Python são os identificadores de registradores.



O software da NetFPGA provê um programa que processa os arquivos XML detodos os módulos de um projeto, identifica os requisitos de memória para armazenamentodos registradores de cada módulo e gera endereços para todos os registradores do projeto.Este programa também gera arquivos de cabeçalho para as linguagens Verilog, C, Perl ePython para permitir referências aos registradores do projeto bem como em programas deusuário, simulações e testes.

4.3.3.2. Interface de memória

A NetFPGA possui dois tipos de memória: SRAM e DRAM. A memória SRAM executano mesmo ciclo de relógio do FPGA e leva três ciclos para completar acessos, mas to-taliza 4.5 MiB. A DRAM funciona de forma assíncrona ao FPGA e leva mais ciclos derelógio para completar acessos, mas totaliza 64 MiB. Apesar da maior latência no acesso àDRAM, ela tem vazão suficiente para funcionar como área de armazenamento temporáriode pacotes, por exemplo nos módulos rx_queue e tx_queue.

O controle do acesso à memória SRAM é realizado por um submódulo chamadosram_arbiter. A tarefa principal do sram_arbiter é intermediar requisições de acessoà memória recebida de vários módulos e da interface de registradores. O sram_arbiterpode ser modificado para arbitrar o acesso à memória de diferentes formas, dando prio-ridades distintas a módulos de um projeto ou para otimizar o acesso à memória caso aaplicação tenha padrões de acessos bem definidos. Apesar da SRAM ter tempo de acessode três ciclos de relógio, o tempo de acesso total através do sram_arbiter depende domecanismo de arbitragem utilizado. Para permitir acesso concorrente à SRAM por di-ferentes módulos, o sram_arbiter armazena as requisições de acesso numa fila interna.Detalharemos o funcionamento do sram_arbiter na seção 4.4.3.



4.4. Implementação de um firewall na NetFPGANesta seção apresentamos o firewall que implementamos na NetFPGA. Apresentamos osdetalhes de implementação e explicamos os fundamentos para que o leitor possa imple-mentar seu próprios projetos. Nosso firewall tem várias simplificações para torná-lo maisdidático. Em particular, o firewall filtra apenas pacotes TCP e o único tipo de regra quesuporta é filtragem por porta de destino. Outra simplificação é que o firewall suportafiltragem de até quatro portas. As razões destas simplificações ficarão claras durante asdiscussões nesta seção. Apesar das simplificações, esperamos que leitores sejam capazesde estender o firewall apresentado utilizando o conteúdo do tutorial.

Esta seção é dividida em cinco partes complementares. Na seção 4.4.1 nós discu-timos o processamento de pacotes na NetFPGA, na seção 4.4.2 discutimos como pacotespodem ser modificados em trânsito, na seção 4.4.3 mostramos como um módulo pode uti-lizar a memória SRAM e na seção 4.4.4 mostramos como definir registradores e acessá-los através de programas de espaço de usuário. Por fim, na seção 4.4.5 apresentamos osistema de testes disponível no software da NetFPGA.

A maior parte do código apresentado neste material refere-se aos arquivos Veri-log (.v) usados para simulação e síntese do hardware. A sintaxe para comentários emVerilog é idêntica à de C.15 O software da NetFPGA possui também scripts Bash (.sh),Perl (.pl) e Python (.py), que adotam o caractere (#) para comentários de linha. Salvoquando indicado, iremos mostrar código retirado do módulo principal do nosso firewall,em netfpga/projects/firewall/src/firewall.v.

4.4.1. Processamento de pacotes

Nesta seção iremos mostrar como pacotes são repassados entre módulos bem como seuconteúdo pode ser acessado para uso em tomada de decisão ou coleta de dados.

4.4.1.1. Barramento de encaminhamento

Nosso firewall é construído como uma extensão do projeto de placa de rede de referência.O processamento de pacotes é realizado por uma sequência de módulos. O firewall éinstanciado no módulo user_data_path, que define o pipeline de processamento, entreos módulos output_port_lookup e output_queues (ver figura 4.2).

Dados dos pacotes são transmitidos entre módulos através do barramento de en-caminhamento. Como descrito na seção 4.3.2 e ilustrado na figura 4.3, o barramento deencaminhamento é composto de 64 bits de dados (data), 8 bits de controle (ctrl), umbit para informar que o módulo anterior tem dado disponível para enviar (wr) e um bitpara informar que o módulo está pronto para receber (rdy). A definição das linhas decomunicação do barramento de encaminhamento em nosso firewall é mostrada abaixo:

1 module firewall2 #(3 parameter DATA_WIDTH = 64,4 parameter CTRL_WIDTH = DATA_WIDTH/8,

15Algumas dicas para programação em Verilog são apresentadas no apêndice A.



5 ...6 )7 (8 input [DATA_WIDTH-1:0] in_data,9 input [CTRL_WIDTH-1:0] in_ctrl,

10 input in_wr,11 output in_rdy,12 output reg [DATA_WIDTH-1:0] out_data,13 output reg [CTRL_WIDTH-1:0] out_ctrl,14 output reg out_wr,15 input out_rdy,16 ...

Todos os módulos do pipeline de processamento da NetFPGA, como os módulosoutput_port_lookup e output_queues, possuem uma fila que armazena dados de paco-tes recebidos do módulo antecessor. A transferência entre módulos só é realizada quandoambos sinais wr e rdy estão ligados. Quando o bit wr não está ligado, o módulo ante-rior não tem dados para transferir, por exemplo, por que a placa não recebeu nenhumpacote. Quando o bit rdy não está ligado, a fila de recepção do módulo está cheia eele não pode receber mais dados, por exemplo, porque o processamento de um pacoteestá demorando mais do que o esperado. Note que quando um módulo não pode rece-ber dados, ele pode travar todo o pipeline de processamento. Em nosso firewall, a filaque armazena os dados de pacotes transmitidas pelo módulo anterior é uma instância defallthrough_small_fifo chamada input_fifo:

1 fallthrough_small_fifo #(2 ...3 ) input_fifo (4 .din ({in_ctrl, in_data}), // Data in5 .wr_en (in_wr), // Write enable6 .dout ({in_fifo_ctrl, in_fifo_data}),7 .rd_en (in_fifo_rd_en), // Next word8 .nearly_full (in_fifo_nearly_full),9 .empty (in_fifo_empty),

10 ...

A entrada da fila, din, é ligada diretamente às linhas de entrada in_data e in_ctrl.O controle do recebimento de dados no barramento de processamento é realizado em duaspartes. Primeiro, ligamos o sinal que informa se o módulo anterior tem dados para escre-ver, in_wr, diretamente no controle de escrita da fila, wr_en (linha 5). Segundo, ligamos osinal que informa se nosso módulo pode receber dados, in_rdy, diretamente no sinal queinforma se a fila está quase cheia (apenas uma posição livre):

1 assign in_rdy = !in_fifo_nearly_full;



in_data

Palavra 63:48 47:32 31:16 15:0

1 Eth source addr Eth dest addr2 Eth dest addr EtherType IPver, HL, ToS3 packet size IP ID flags, frag TTL, proto4 checksum source IP destination IP5 destination IP source port destination port seq. no.6 seq. no. acknowledgement flags7 adv. window checksum urgent ptr. payload· · · payload

Tabela 4.2. Pacotes são encaminhados em palavras de 64 bits ao longo de váriosciclos de relógio. Na tabela um exemplo de pacote TCP.

Se o módulo anterior não tiver dados para enviar ou se a fila estiver cheia, nadaé escrito na fila. Mais precisamente, se a fila estiver cheia, nada será escrito na fila e omódulo anterior irá armazenar o dado até a fila poder recebê-lo.

Como veremos na subseção seguinte, nosso firewall retira dados da fila lendo osdados em in_fifo_data e in_fifo_ctrl, ligados à saída da fila (dout), e ligando o sinalin_fifo_rd_en para avançar a fila para a próximo dado.

Os bits de controle, in_fifo_ctrl, especificam como os bits de dados devem serprocessados. Os bits de controle possuem valor zero enquanto o pacote está sendo trans-mitido. Bits de controle diferentes de zero denotam metadados que precedem ou sucedemos dados do pacote. O valor dos bits de controle define a semântica dos bits de dados,in_fifo_data. Por exemplo, quando os bits de controle valem IO_QUEUES_STAGE_NUM(0xff), os bits de dados contém informações sobre o recebimento do pacote, por exemplo,em qual porta Ethernet ele chegou. Estes metadados podem ser utilizados no processa-mento do pacote.

4.4.1.2. Máquina de estados

Nosso firewall implementa uma máquina de estados para verificar se o pacote é IP e TCP.Em caso positivo, a máquina de estados verifica se a porta de destino deve ser filtrada edecide entre encaminhar ou descartar o pacote.

Como todo o pacote é transmitido no barramento de encaminhamento com os bitsde controle zerados, nossa máquina de estado precisa manter informação de qual palavrade 64 bits está sendo recebida. Por exemplo, como o cabeçalho IP e TCP somam pelomenos 40 bytes (56 bytes contabilizando o cabeçalho Ethernet), o cabeçalho do pacoteé recebido ao longo de pelo menos cinco ciclos de relógio. A tabela 4.2 mostra quaisdados são transferidos no barramento de encaminhamento a cada ciclo de relógio quandoas linhas de controle estão zeradas.

Visão geral e atribuições padrão

A figura 4.4 mostra a máquina de estados do nosso firewall. A ideia básica é receber ocabeçalho do pacote para verificar se ele precisa ser descartado antes de transmiti-lo ao



Figura 4.4. Máquina de estados do firewall.

próximo módulo. Para receber e armazenar o cabeçalho do pacote precisamos de uma filade saída auxiliar, onde colocamos as palavras de dados que já recebemos até decidir sedevemos enviar o pacote para o módulo seguinte ou descartá-lo. A definição da fila desaída, mostrada a seguir, é similar à definição da fila de entrada.

1 fallthrough_small_fifo #(2 ...3 ) output_fifo (4 .din (out_fifo_din), // Data in5 .wr_en (out_fifo_wr), // Write enable6 .rd_en (out_fifo_rd_en), // Read the next word7 .dout (out_fifo_dout),8 .full (),9 .nearly_full (out_fifo_nearly_full),

10 .empty (out_fifo_empty),11 .reset (reset),12 .clk (clk)13 );

A cada ciclo de relógio fazemos atribuições padrão que podem ser sobrescritasdependendo do estado. Em particular, deixamos a fila de entrada travada, não escrevemosna fila de saída, e não repassamos dados para o próximo módulo do pipeline. Tambématribuímos os dados de entrada da fila de saída aos dados retirados da fila de entrada. Porúltimo, repassados ao próximo módulo no pipeline os dados retirados da fila de saída.

1 in_fifo_rd_en = 0;2 out_fifo_wr = 0;3 out_fifo_rd_en = 0;4 out_wr = 0;5 out_fifo_din = {in_fifo_ctrl, in_fifo_data};6 {out_ctrl, out_data} = out_fifo_dout;

Nossa máquina de estados atualiza todos os registradores a cada ciclo do relógio.Para cada registrador, temos um conjunto de linhas com o mesmo nome e o sufixo next.



As linhas com sufixo next são atribuídas aos respectivos registradores a cada ciclo dorelógio. Para manter os valores nos registradores, inicializamos as linhas next com ovalor atual dos registradores e modificamos o valor das linhas next em estados específicosquando necessário.

Primeiro estado: esperando o início de pacotes

O primeiro estado da nossa máquina de estados, WAIT_PACKET, simplesmente espera oinício do recebimento de um pacote, isto é, espera as linhas de controle serem zeradas.A implementação do primeiro estado, mostrada abaixo, primeiro verifica se existe pa-cote a processar e se o próximo módulo está pronto para receber pacotes verificandoin_fifo_empty e out_rdy, respectivamente. Se não há dado a processar ou se o próximomódulo não está pronto para receber, continuamos neste estado sem avançar as filas deentrada e saída (linha 12). Se há dado a processar e o próximo módulo está pronto pararecebê-lo, nossa máquina de estados avança a fila ligando o sinal in_fifo_rd_en e gravaos dados na fila de saída ligando out_fifo_wr. Se os bits de controle in_fifo_ctrl nãoestiverem zerados, significa que ainda estamos recebendo metadados e o início do pacoteainda não chegou. Quando os bits de controle estiverem zerados significa que acaba-mos de receber a primeira palavra de dados do pacote (que contém o endereço MAC daorigem, tabela 4.2) e passamos para o segundo estado.

1 WAIT_PACKET: begin2 if (!in_fifo_empty && out_rdy) begin3 in_fifo_rd_en = 1;4 out_fifo_wr = 1;5 if(in_fifo_ctrl == ’h0) begin6 state_next = WORD2_CHECK_IPV4;7 end else begin8 state_next = WAIT_PACKET;9 end

10 end11 else12 state_next = WAIT_PACKET;13 end

Segundo estado: verificação do protocolo de rede

O segundo estado nosso firewall processa a segunda palavra do pacote e verifica se o pa-cote é um pacote IPv4. Para isso verificamos se o tipo do cabeçalho Ethernet (EtherType)é 0x0800, que indica um pacote IP, e se a versão do protocolo IP é 4.16 Em caso positivo,prosseguimos para o próximo estado para verificar se o pacote é um pacote TCP. Caso opacote não seja um pacote IPv4 ele deverá ser encaminhado pela rede sem ser filtrado.Para encaminharmos o pacote pulamos para o oitavo estado, EMPTY_OUT_FIFO, descritoabaixo.

16Note que nosso firewall não suporta VLANs (802.1Q). Para tal seria necessário considerar o caso ondeo EtherType é 0x8100.



1 WORD2_CHECK_IPV4: begin2 if (!in_fifo_empty && out_rdy) begin3 if(in_fifo_data[31:16] != 16’h0800 ||4 in_fifo_data[15:12] != 4’h4) begin5 state_next = EMPTY_OUT_FIFO;6 end7 else begin8 in_fifo_rd_en = 1;9 out_fifo_wr = 1;

10 state_next = WORD3_CHECK_TCP_TTL;11 end12 end13 else14 state_next = WORD2_CHECK_IPV4;15 end

Terceiro estado: verificação do protocolo de transporte

No terceiro estado inspecionamos o cabeçalho IP para ver se o valor do campo protocoloé 0x06, que indica TCP. Em caso negativo o pacote é aceito: pulamos para o estadoEMPTY_OUT_FIFO para enviarmos as duas primeiras palavras mais metadados que foramarmazenadas na fila de saída (linha 9). Note que, em caso negativo, a fila de entrada ficabloqueada com a terceira palavra, que será transmitida após esvaziarmos a fila de saída noestado EMPTY_OUT_FIFO. Em caso positivo, encaminhamos a terceira palavra para a fila desaída e passamos para o próximo estado.

1 WORD3_CHECK_TCP_TTL: begin2 if (!in_fifo_empty && out_rdy) begin3 if(in_fifo_data[7:0] == 8’h06) begin4 in_fifo_rd_en = 1;5 out_fifo_wr = 1;6 state_next = WORD4_ADDR_CHKSUM;7 end8 else9 state_next = EMPTY_OUT_FIFO;

10 end11 else12 state_next = WORD3_CHECK_TCP_TTL;13 end

Quarto estado: armazenamento dos endereços IP

O quarto estado do firewall armazena os dados da quarta palavra do pacote temporari-amente até verificarmos o número da porta de destino no protocolo TCP no próximoestado.

1 WORD4_ADDR_CHKSUM: begin2 if (!in_fifo_empty && out_rdy) begin



3 in_fifo_rd_en = 1;4 out_fifo_wr = 1;5 state_next = WORD5_TCP_PORT;6 end7 else8 state_next = WORD4_ADDR_CHKSUM;9 end

Quinto, sexto e sétimo estágios: verificando porta de destino

No quinto estado a fila de entrada contém a quinta palavra do pacote, que possui o númeroda porta de destino do protocolo TCP. Nós mantemos as filas de entrada e saída travadas,armazenamos a porta de destino no registrador dst_port e avançamos para o próximoestágio.

1 WORD5_TCP_PORT: begin2 if (!in_fifo_empty && out_rdy) begin3 // in_fifo_rd_en and out_fifo_wr are zero by default4 dst_port_next = in_fifo_data[31:16];5 state_next = CHECK_RULES;6 end7 else8 state_next = WORD5_TCP_PORT;9 end

No sexto estágio mantemos as filas de entrada e saída travadas e enviamos umarequisição de leitura da memória. O endereço lido é SRAM_PORTS_ADDR, que é definidoigual a zero (primeira linha da memória) e contém as portas de destino que estão blo-queadas. Nós lemos as portas bloqueadas da memória para ilustrar o acesso à memóriaSRAM e porque as portas bloqueadas podem ser alteradas assincronamente pelo usuário.Na seção 4.4.3 iremos detalhar o acesso à memória.

1 CHECK_RULES: begin2 sram_rd_req_next = 1;3 sram_rd_addr_next = SRAM_PORTS_ADDR;4 state_next = CHECK_PORTS;5 end

Por último, o sétimo estágio espera a memória SRAM retornar os dados verifi-cando o valor de rd_vld. Esta espera é necessária pois a SRAM demora alguns ciclos derelógio para retornar o dado requisitado. Uma versão otimizada do nosso firewall pode-ria realizar a requisição de memória antes para evitar esta espera. Se a porta de destinofor uma das portas bloqueadas, ligamos o registrador drop. Independente da porta dedestino passamos para o próximo estágio, onde a fila de saída será esvaziada e os dadostransmitidos para o próximo módulo dependendo do valor do registrador drop.



1 CHECK_PORTS: begin2 if (rd_0_vld) begin3 if(sram_rd_data[15:0] == dst_port ||4 sram_rd_data[31:16] == dst_port ||5 sram_rd_data[47:32] == dst_port ||6 sram_rd_data[63:48] == dst_port)7 drop_next = 1;8 else9 drop_next = 0;

10 state_next = EMPTY_OUT_FIFO;11 end12 else13 state_next = CHECK_PORTS;14 end

Oitavo estágio: processando palavras armazenadas temporariamente

O oitavo estágio é responsável por processar os metadados e dados do pacote armazena-dos temporariamente na fila de saída para o módulo seguinte do pipeline. A cada ciclo derelógio processamos uma palavra da fila de espera (linha 6). Se o registrador drop estiverdesligado, enviamos uma palavra da fila de espera para o próximo módulo (linha 7). Se oregistrador drop estiver ligado, retiramos os dados da fila sem repassá-los ao módulo se-guinte, efetivamente descartando o pacote. Quando a fila de espera estiver vazia pulamospara o último estado onde enviamos o restante do pacote (a partir da quinta palavra) parao próximo módulo diretamente da fila de entrada.

1 EMPTY_OUT_FIFO: begin2 if(!out_rdy)3 state_next = EMPTY_OUT_FIFO;4 else if(!out_fifo_empty) begin5 state_next = EMPTY_OUT_FIFO;6 out_fifo_rd_en = 1;7 out_wr = ~drop;8 end9 else

10 state_next = PAYLOAD;11 end

Nono estágio: processando o conteúdo do pacote

O nono e último estágio processa o resto do pacote a partir da fila de entrada. Os da-dos retirados da fila de entrada são repassados para o próximo módulo dependendo dovalor de drop. Voltamos para o primeiro estado quando detectamos o início do próximopacote. Detectamos o início do próximo pacote quando os bits de controle têm o valorIO_QUEUE_STAGE_NUM, do metadado adicionado pelas filas de entrada quando o pacote érecebido na NetFPGA. Note que assim que detectamos o início do próximo pacote trava-mos a fila de entrada para que a primeira palavra do pacote seja processada pelo primeiroestado do firewall.



1 PAYLOAD: begin2 if (!in_fifo_empty && out_rdy) begin3 {out_ctrl, out_data} = {in_fifo_ctrl, in_fifo_data};4 if(in_fifo_ctrl != ‘IO_QUEUE_STAGE_NUM)5 in_fifo_rd_en = 1;6 out_wr = ~drop;7 state_next = PAYLOAD;8 else begin9 in_fifo_rd_en = 0;

10 out_wr = 0;11 drop_next = 0; // reset drop register12 state_next = WAIT_PACKET;13 end14 end15 else16 state_next = PAYLOAD;17 end

4.4.2. Modificação de pacotes em trânsito

Uma das funcionalidades da NetFPGA é a capacidade de modificar pacotes em trânsito.Iremos ilustrar essa funcionalidade decrementando o tempo de vida (time to live, TTL)do pacote. Iremos também recalcular o checksum do pacote. Para tanto vamos estender ocódigo apresentado na subseção anterior.

O tempo de vida do pacote é transmitido na terceira palavra (figura 4.2). Nossofirewall processa a terceira palavra do pacote no quarto estado (WORD4_ADDR_TTL). Paradecrementar o tempo de vida, iremos modificar o dado do pacote antes de inseri-lo na filade saída, como segue:

1 WORD3_CHECK_TCP_TTL: begin2 if (!in_fifo_empty && out_rdy) begin3 if(in_fifo_data[7:0] == 8’h06) begin4 in_fifo_rd_en = 1;5 out_fifo_wr = 1;6 out_fifo_din = {in_fifo_ctrl, in_fifo_data[63:16],7 in_fifo_data[15:8] - 8’h1,8 in_fifo_data[7:0]};9 state_next = WORD4_ADDR_CHKSUM;

10 end11 else12 state_next = EMPTY_OUT_FIFO;13 end14 else15 state_next = WORD3_CHECK_TCP_TTL;16 end



De forma similar, precisamos atualizar o checksum do pacote devido ao decre-mento do tempo de vida. Como o checksum do protocolo IP é simplesmente uma soma,podemos atualizá-lo simplesmente somando o que foi subtraído devido ao decremento dotempo de vida.17 No código abaixo, chksum possui 17 bits para conseguirmos somar ocarry out em chksum_cout, que possui 16 bits.

1 assign chksum = {0, in_fifo_data[63:48]} + 16’h0100;2 assign chksum_cout = chksum[15:0] + {15’h0, chksum[16]};3 ...4 WORD4_ADDR_CHKSUM: begin5 if (!in_fifo_empty && out_rdy) begin6 in_fifo_rd_en = 1;7 out_fifo_wr = 1;8 in_out_fifo_dout = {in_fifo_ctrl, chksum_cout,9 in_fifo_data[47:0]};

10 state_next = WORD5_TCP_PORT;11 end12 else13 state_next = WORD4_ADDR_CHKSUM;14 end

4.4.3. Acesso à memória SRAM

Nosso módulo utiliza a memória SRAM para armazenar as portas bloqueadas e decidirquais pacotes filtrar. No sexto estado do processamento de um pacote emitimos umarequisição de leitura para o endereço SRAM_PORTS_ADDR, que contem as portas TCP blo-queadas. No sétimo estado esperamos a leitura completar e então utilizamos o dado lidopara verificar se o pacote precisa ser descartado ou não.

Nosso firewall emite operações de leitura da memória para o módulo sram_arbiter,que intermedia o acesso à memória SRAM. As linhas de comunicação do nosso firewallcom o sram_arbiter ilustram a interface de acesso à memória.

1 output reg sram_rd_req,2 output reg [SRAM_ADDR_WIDTH-1:0] sram_rd_addr,3 input [DATA_WIDTH-1:0] sram_rd_data,4 input sram_rd_ack,5 input sram_rd_vld,6 output reg sram_wr_req,7 output reg [SRAM_ADDR_WIDTH-1:0] sram_wr_addr,8 output reg [DATA_WIDTH-1:0] sram_wr_data,9 input sram_wr_ack,

17O cálculo do checksum do protocolo IP é detalhado no RFC1071. Ele depende do valor da somadas palavras de 2 bytes dos campos do cabeçalho usando complemento de um. Como o tempo de vidatem apenas 1 byte e está alinhado com o byte mais significativo da palavra de 2 bytes que o contém, nósincrementamos o byte mais significativo do checksum, somando 0x0100, para compensar.



O sram_arbiter pode receber uma requisição de leitura ou escrita por ciclo derelógio. Requisições de leitura são indicadas ligando sram_rd_req e informando o ende-reço a ser lido em sram_rd_addr. No próximo ciclo de relógio o sram_arbiter indicase a requisição foi recebida com sucesso ligando o sinal sram_rd_ack. Como leituras de-moram alguns ciclos para serem atendidas, o módulo que pediu a leitura deve esperar osdados serem retornados e disponibilizados pelo sram_arbiter. O sram_arbiter informaque os dados estão disponíveis em sram_rd_data ligando sram_rd_vld.

Requisições de escrita são indicadas ligando sram_wr_req, informando o endereçoa ser escrito em sram_wr_addr e informando o dado a ser escrito em sram_wr_data. Osram_arbiter indica se a requisição foi recebida com sucesso ligando o sinal sram_wr_ack.Como o dado a ser escrito é armazenado pelo sram_arbiter, o módulo que fez a requi-sição de escrita não precisa esperar mais nenhuma confirmação do sram_arbiter. Seambos os sinais sram_rd_req e sram_wr_req estiverem ligados, nosso sram_arbiter pri-oriza a requisição de escrita. A SRAM usada na NetFPGA garante que leituras realizadasapós escritas lerão o dado atualizado.

A interface que exportamos em nosso sram_arbiter é simplificada. Como des-crito na seção 4.3.1, a NetFPGA possui dois bancos de memórias SRAM, cada um com219 linhas de 36 bits. Nosso sram_arbiter combina os dois bancos para apresentar umaabstração de memória de 219 linhas de 64 bits. Usamos 8 bits de cada linha como bits deparidade, calculados e verificados automaticamente pelo sram_arbiter.

1 // sram_arbiter.v2 generate3 genvar m;4 for(m = 0; m < 8; m = m+1) begin: calc_par_bits5 assign parbit[m] = wr_data[m*8] ^ wr_data[m*8+1] ^6 wr_data[m*8+2] ^ wr_data[m*8+3] ^ wr_data[m*8+4] ^7 wr_data[m*8+5] ^ wr_data[m*8+6] ^ wr_data[m*8+7];8 end // wr_data is 64 bits wide9 endgenerate

10 generate11 genvar l;12 for(l = 0; l < 8; l = l+1) begin: expand_wr_data13 assign wr_data_exp[(l+1)*9-1 : l*9] =14 {wr_data[(l+1)*8-1:l*8], parbit[l]};15 end // wr_data_exp is 72 bits wide (36*2)16 endgenerate

Para acessar as duas memórias simultaneamente duplicamos os sinais de requisi-ção de escrita ou leitura e os endereços para os dois bancos de memória. Para requisiçõesde escrita escrevemos metade dos dados em cada banco e para requisições de leitura con-catenamos os dados dos dois bancos. Abaixo mostramos o código para realizar estasoperações. Este código fica dentro do módulo nf2_core. O módulo nf2_core é o mó-dulo raiz do software da NetFPGA e comunica diretamente com os pinos do FPGA. O



nf2_core conecta os pinos do FPGA conectados às memórias SRAM ao sram_arbiterda seguinte forma.

1 // nf2_core.v2 // hardware pins sram_arbiter3 assign sram1_wr_data = wr_data_exp[‘SRAM_DATA_WIDTH-1:0];4 assign sram2_wr_data = wr_data_exp[2*‘SRAM_DATA_WIDTH-1:‘SRAM_DATA_WIDTH];5 assign sram1_we = sram_we; // 0 for write, 1 for read6 assign sram2_we = sram_we;7 assign sram1_addr = sram_addr;8 assign sram2_addr = sram_addr;9 // sram_arbiter hardware pins

10 assign sram_rd_data = {sram2_rd_data, sram1_rd_data};

O sram_arbiter pode ser modificado para permitir acesso mais eficiente à memó-ria caso a aplicação tenha um padrão específico de acessos. Por exemplo, é possível modi-ficar as atribuições acima para permitir ler endereços distintos em cada banco de SRAM.A SRAM também provê um mecanismo para permitir escritas parciais, escolhendo quaisbytes devem ser escritos em uma requisição de escrita.18

Para exemplificar o controle de acesso à SRAM num nível mais baixo, iremosexplicar o tratamento de uma requisição de leitura (requisições de escrita são mais sim-ples). Quando o sram_arbiter recebe uma requisição de leitura, ele desabilita escritaligando o sinal sram_we (este sinal possui lógica negativa), repassa o endereço a ser lidoao hardware e confirma a requisição de leitura.

1 // sram_arbiter.v2 else if(sram_rd_req) begin3 hw_we <= 1’b1; // read4 hw_addr <= sram_rd_addr;5 sram_rd_ack <= sram_rd_req; // acknowledge read request6 sram_wr_ack <= 0; // do not acknowledge write7 rd_vld_early3 <= sram_rd_req; // data back in three cycles8 ...9 end

Como o dado demora dois ciclos para ser retornado da SRAM após a requisi-ção, o sram_arbiter possui um pipeline interno para esperar os dados serem retorna-dos pela SRAM. Após dois ciclos o sram_arbiter armazena o dado lido no registradorsram_rd_data e encaminha este registrador para o firewall no terceiro ciclo de relógioapós a requisição.

1 // sram_arbiter.v2 rd_vld_early2 <= rd_vld_early3; // waited 1

18Não mostramos esta funcionalidade no texto. Nossa implementação não suporta escritas parciais. Es-critas parciais poderiam ser controladas configurando o valor das linhas sram_bw no sram_arbiter.



3 rd_vld_early1 <= rd_vld_early2; // waited 24 if(rd_vld_early1) begin // memory sending data this cycle, storing5 if(parity_check)6 sram_rd_data <= rd_data_exp_parsed; // no parity bits7 else8 sram_rd_data <= 64’hdeadfeeddeadfeed;9 end

10 sram_rd_vld <= rd_vld_early1; // data is here, set valid bit

4.4.4. Registradores e interface PCI

Nosso projeto define quatro registradores de software, um para cada porta de destino quedeve ser bloqueada. Estes registradores de software podem ser configurados dinamica-mente a partir do espaço de usuário. Nós definimos os registradores no arquivo XML deconfiguração do nosso projeto como abaixo.

<nf:name>firewall</nf:name><nf:prefix>firewall</nf:prefix><nf:location>udp</nf:location><nf:description>Registers for minifirewall</nf:description><nf:blocksize>128</nf:blocksize><nf:registers><nf:register><nf:name>dport1</nf:name><nf:description>Blocked port 1</nf:description><nf:type>generic_software32</nf:type>

</nf:register>...

</nf:registers>

O programa nf_register_gen processa os arquivos XML de configuração de to-dos os módulos de um projeto, gera um identificador para cada módulo, calcula requisitosde armazenamento para os registradores de cada módulo e gera endereços virtuais paracada registrador.19 O endereço virtual de um registrador é composto do identificador domódulo onde foi declarado e de seu deslocamento dentro do bloco de memória reservadoaos registradores do módulo. Como nosso firewall possui quatro registradores de 32 bitspara armazenar as portas TCP que estão bloqueadas, definimos um bloco de registradoresde 128 bits (blocksize na configuração acima). O tamanho do bloco de registradoresdefine a quantidade de bits necessárias para a parte de deslocamento do endereço dosregistradores.

O nf_register_gen gera cabeçalhos Verilog, C, Python e Perl contendo constan-tes que permitem endereçar os registradores em cada uma destas linguagens. Os arquivos

19O arquivo XML com a configuração global do firewall está em netfpfa/projects/firewall/include/project.xml. Arquivos com a configuração dos módulos estão no mesmo diretório.

de cabeçalho são necessários para compilação de programas de usuário e sintetização doprojeto em hardware. O nf_register_gen pode ser executado com o comando seguinte(os cabeçalhos são criados dentro da pasta netfpga/projects/firewall/lib/):

netfpga/bin/nf_register_gen.pl --project firewall

Os endereços virtuais de registradores em programas do usuário possuem 28 bits eindependem do tipo do registrador (contador, software, ou hardware). Como a NetFPGAinterage com sistemas operacionais de 32 bits, registradores maiores que 32 bits são par-ticionados em múltiplas palavras de 32 bits segundo o esquema mostrado nas colunas“64 bits” e “128 bits” na tabela 4.3.

32 bits 64 bits 128 bitsMacro Endereço Macro Endereço Macro EndereçoEX_REG 0x2000004 EX_REG_LO 0x2000004 EX_REG_1_LO 0x2000004

EX_REG_HI 0x2000008 EX_REG_1_HI 0x2000008EX_REG_2_LO 0x200000cEX_REG_2_HI 0x2000010

Tabela 4.3. Exemplo do esquema de geração de nomes para registradores maio-res que 32 bits.

Registradores de software podem ser escritos lidos e escritos utilizando as funçõesreadReg e writeReg definidas na biblioteca de funções da NetFPGA (em netfpga/lib).Por exemplo, no nosso programa de configuração dinâmica das portas bloqueadas, nffw,temos:

// netfpga/projects/firewall/sw/nffw.cwriteReg(&nf2, FIREWALL_DPORT0_REG, dropped[0]);...readReg(&nf2, FIREWALL_DPORT0_REG, &check[0]);

A memória SRAM também pode ser acessada pela interface de registradores. Aprimeira palavra da memória SRAM é mapeada no endereço virtual SRAM_BASE_ADDR,e outras palavras podem ser acessadas indiretamente a partir de SRAM_BASE_ADDR. O se-guinte exemplo zera as dez primeiras palavras da memória:

for(i = 0; i < 10; i++)unsigned offset = i*4; // 4 bytes per wordwriteReg(&nf2, SRAM_BASE_ADDR + offset, 0);

Chamadas de função como writeReg enviam uma requisição de escrita em re-gistrador para a NetFPGA. Essa requisição é recebida pelo barramento PCI. Para facili-tar o processamento de requisições de escrita e leitura dos registradores, podemos usaro módulo generic_regs. O módulo generic_regs é padrão no pacote de software daNetFPGA e é instanciado dentro dos módulos que compõem o pipeline de processamento.



Quando instanciamos o generic_regs, definimos o número de registradores e aslinhas conectadas a cada registrador. Definimos também em qual módulo ele está sendoinstanciado (parâmetro TAG). Esta informação permite à instância do generic_regs iden-tificar os endereços dos registradores do módulo e quais requisições de escrita e leituraem registradores deve tratar.

1 generic_regs2 #(3 .TAG (‘FIREWALL_BLOCK_ADDR), // module ID4 .NUM_SOFTWARE_REGS (4), // number of sw regs5 ...6 ) module_regs (7 .reg_req_in (reg_req_in), // register bus input lines8 .reg_ack_in (reg_ack_in),9 .reg_rd_wr_L_in (reg_rd_wr_L_in),

10 .reg_addr_in (reg_addr_in),11 .reg_data_in (reg_data_in),12 .reg_src_in (reg_src_in),13 .reg_req_out (reg_req_out), // register bus output lines14 .reg_ack_out (reg_ack_out),15 .reg_rd_wr_L_out (reg_rd_wr_L_out),16 .reg_addr_out (reg_addr_out),17 .reg_data_out (reg_data_out),18 .reg_src_out (reg_src_out),19 .counter_updates (), // register definitions20 .counter_decrement(),21 .software_regs ({dport1, dport2, dport3, dport4}),22 .hardware_regs (),23 ...24 );

As requisições de leitura e escrita em registradores recebidas pelo barramento PCIsão inseridas no barramento de registradores. O barramento de registradores é paralelo aobarramento de encaminhamento. Como no barramento de encaminhamento, cada instân-cia do módulo generic_regs tem sinais de entrada (sufixo _in), para receber requisiçõesdo módulo anterior, e de saída (sufixo _out), para repassar as requisições ao próximomódulo. Ilustramos o barramento de registradores na figura 4.5. A linha req indica seas outras linhas carregam uma requisição válida. As linhas addr especificam o endereçovirtual do registrador. A linha rd_wr_L indica se a requisição é de leitura ou escrita (comlógica negativa, leitura quando ligado e escrita quando desligado) e as linhas data contémo dado a ser escrito ou o dado lido. A linha ack indica se a requisição já foi tratada e aslinhas src indicam qual módulo tratou a requisição.

O nf_register_gen gera blocos para armazenamento de registradores automati-camente. Para projetos com requisitos específicos, é possível controlar o endereço basedos registradores de cada módulo no arquivo XML de configuração do projeto. Por exem-



Figura 4.5. Módulo generic_regs e barramento de registradores.

plo, para posicionar os registradores do nosso firewall no endereço 0x02000400 basta uti-lizar a configuração a seguir.

<nf:memalloc layout="reference">

<nf:group name="udp"><nf:instance name="firewall" base="0x02000400"/>...

</nf:group>...

</nf:memalloc>

Nosso firewall lê as portas que devem ser filtradas da memória SRAM (sextoestágio). Esta decisão de projeto é didática, para exemplificar a utilização da memó-ria SRAM. Num projeto real, as portas poderiam ser lidas diretamente dos registradoresdport0, dport1, dport2, dport3. Para que possa ler as portas TCP bloqueadas da me-mória SRAM, nosso firewall precisa também gravar esta informação na memória. Isto érealizado gravando os registradores na memória usando o módulo sram_arbiter. Paradetectar se as portas bloqueadas foram modificadas, verificamos se o uma requisição deregistrador foi atendida (reg_ack_out) e se o endereço da requisição pertence ao nossomódulo (tag_hit e addr_good). Para verificar se o endereço da requisição pertence aonosso módulo, utilizamos as constantes geradas pelo nf_register_gen.

1 always @(*) begin2 wr_data_next <= {dport3[15:0], dport2[15:0],

3 dport1[15:0], dport0[15:0]};4 wr_addr_next <= SRAM_PORTS_ADDR;5 if(tag_hit && addr_good && reg_ack_out)6 wr_req_next <= 1;7 else8 wr_req_next <= 0;9 end

10 assign addr_block = reg_addr_out[‘UDP_REG_ADDR_WIDTH-1:11 ‘FIREWALL_REG_ADDR_WIDTH];12 assign tag_hit = ‘FIREWALL_BLOCK_ADDR == addr_block;13 assign addr_good = reg_addr_out[‘FIREWALL_REG_ADDR_WIDTH-1:0] >=14 ‘FIREWALL_DPORT0 && reg_addr_out[‘FIREWALL_REG_ADDR_WIDTH] <=15 ‘FIREWALL_DPORT3;

As linhas addr_block são construídas a partir do endereço da requisição e contémo identificador do bloco de registradores (linha 10). O identificador do bloco de registra-dores pode ser utilizado para verificar se o registrador pertence ao nosso módulo (linha12). Por último, a linha addr_good indica se o registrador escrito é um dos registradoresque armazena as portas TCP bloqueadas (linha 13).

4.4.5. Sistema de testes

O software da NetFPGA tem um framework que projetos podem utilizar para facilitar eautomatizar o desenvolvimento e execução de testes.

O programa nf_test.py executa testes armazenados dentro do subdiretório testno diretório do projeto apontado pela variável de ambiente NF_DESIGN_DIR. O nome decada teste deve seguir um formato específico, indicando se é um teste de simulação (sim),um teste do hardware sintetizado (hw) ou ambos (both); o componente sendo testado(major); e o teste específico (minor). Por exemplo, o comando abaixo irá executar o testeem projects/firewall/test/sim_firewall_tcp.

# inside the NetFPGA root directoryexport NF_DESIGN_DIR=$(pwd)/projects/firewallbin/nf_test.py --isim --major firewall --minor tcp sim

O nf_test.py chama o script run.py dentro do diretório do teste. Os scriptsrun.py podem utilizar funções da biblioteca de testes da NetFPGA.20 A biblioteca possuifunções que permitem construir pacotes de rede usando a biblioteca Scapy21 disponível noPython. A biblioteca injeta os pacotes gerados interfaceando com o simulador ou com ohardware dependendo do tipo de teste sendo realizado. A biblioteca também permite ve-rificar se pacotes foram transmitidos ou não. No teste sim_firewall_tcp criamos pacotesTCP com diferentes portas de destino e depois verificamos se os pacotes cujas portas não

20As bibliotecas do framework de testes ficam no diretório lib/python/NFTest. As funções relativas amanipulação de pacotes estão em PacketLib.py e as funções relativas à comunicação via interface PCI estãoem NFTestLib.py.

21Scapy, disponível em www.secdev.org/projects/scapy/.



estão bloqueadas foram encaminhados. Caso pacotes sejam erroneamente encaminhadosou descartados, o teste resultará em erro.

# projects/firewall/test/sim_firewall_tcp/run.pyeth_hdr = scapy.Ether(dst=DA, src=SA)ip_hdr = scapy.IP(dst=DST, src=SRC)tcp_hdr = scapy.TCP(dport=random.choice(POSSIBLE_PORTS), sport=SPORT)...pkt = eth_hdr/ip_hdr/tcp_hdr/payloadnftest_send_phy(’nf2c0’, pkt)if(pkt.dport not in BLOCKED_PORTS):...nftest_expect_dma(’nf2c0’, pkt)

A biblioteca também possui funções que permitem escrever e ler valores de re-gistradores e da memória SRAM. Para tornar o teste sim_firewall_tcp interessante, uti-lizamos as funções da biblioteca para configurar as portas que devem ser filtradas, bemcomo verificar se a configuração foi escrita no registrador. Note que o módulo Pythonreg_defines é gerado pelo nf_register_gen.

# projects/firewall/test/sim_firewall_tcp/run.pynftest_regwrite(reg_defines.FIREWALL_DPORT0_REG(),

BLOCKED_PORTS[0])nftest_regread_expect(reg_defines.FIREWALL_DPORT0_REG(),

BLOCKED_PORTS[0])

Podemos também verificar se as portas foram escritas na primeira linha de memó-ria de onde nossa máquina de estados lê as portas que devem ser bloqueadas. Adiciona-mos um pequeno atraso no script de teste para dar tempo para os dados serem gravadosna memória. A manipulação dos bits é necessária devido ao formato no qual as portas sãogravadas na memória SRAM.

simReg.regDelay(1000)nftest_regread_expect(reg_defines.SRAM_BASE_ADDR(),

BLOCKED_PORTS[2]<<16 | BLOCKED_PORTS[3])

A saída do nf_test.py contém o tempo de simulação e as mensagens escritas.Estas mensagens podem ser geradas de dentro do código Verilog usando as diretivas$display. As funções disponibilizadas pelo sistema de testes em Python geram mensa-gens indicando qual operação será realizada e o seu resultado. Por exemplo, as asserçõesde leitura sobre endereços definidos nos arquivos de cabeçalho normalmente produzem amensagem “Good: PCI read of addr X returned data Y as expected” quando o resultadoestá correto. O final da saída indica se todas as verificações do teste passaram através damensagem “Test X passed!” e vice-versa.



4.5. Trabalhos relacionadosApresentaremos nesta seção, uma revisão de trabalhos relacionados com a NetFPGA.Destaca-se que desde 2006, quando o projeto ganhou maior popularidade, já foram pu-blicados mais de 226 artigos acadêmicos envolvendo a NetFPGA como parte de pesquisacientifica em redes de computadores ou sistemas distribuídos, e existe uma extensa lis-tagem de mais de 40 projetos com código aberto, tanto nas versões de NetFPGA 1Gquanto nas versões mais recentes da NetFPGA 10G, CML e SUME. Nesta breve revisãodestacaremos as contribuições mais importantes.

4.5.1. Artigos Acadêmicos

A plataforma NetFPGA teve sua origem em um curso de pós-graduação CS344 de Stan-ford [Gibb et al. 2008], onde os alunos trabalhavam em um projeto para criar um roteadortanto com componentes em hardware e em software em oito semanas. Parte da motiva-ção deste curso, veio da experiencia na indústria de alguns dos professores como NickMcKweon (um dos arquitetos do roteador Cisco GSR 12000). Na indústria, destacava-seque os estagiários e recém-contratados, ou entendiam bem de hardware ou entendiam bemde software, mas não os dois ou sua integração. Adicionalmente ao ensino, a construçãode um sistema aberto como a NetFPGA também propiciou um ambiente para pesquisa dealta qualidade em redes [Naous et al. 2008b].

Dentre os primeiros projetos, os alunos do curso contribuíram com roteadores ecomutadores de referência, bem como sistemas de monitoração de buffers e geradores depacotes altamente precisos [Covington et al. 2009]. Em 2008, auxiliado pela populari-dade da tecnologia OpenFlow, foi desenvolvido uma implementação de um comutadorOpenFlow em NetFPGA [Naous et al. 2008a]. Esta foi uma das primeiras soluções decomutador OpenFlow flexíveis, de alta velocidade e baratas para pesquisa em SDN. Eposteriormente, tornou a NetFPGA um elemento presente em ambientes de produção dediversas plataformas de experimentação OpenFlow internacionais como GENI, KORENe o FIBRE [Abelém et al. 2012].

Os projetos de desenvolvimento foram ganhando mais sofisticação dentro de vá-rios Workshops de Desenvolvimento específicos em NetFPGA, tanto em Stanford quantoem Cambridge-UK, e em outras partes do mundo. Esses Workshops popularizaram traba-lhos técnicos em várias áreas, que faziam uso da plataforma. Adicionando, por exemplo,projetos em suporte a drivers para Windows ou a implementação de protótipo de envio desinal de rádio GNURadio empacotado em pacotes IP [Zeng et al. 2009].

Outros trabalhos oriundos dos Workshops concentram as publicações de trabalhosrelacionados nos anos de 2009 e 2010. A partir de 2011, a quantidade de trabalhos queusa ou avança o progresso da NetFPGA aumenta consideravelmente, diversificando suaatuação em diversas publicações especializadas em redes ou FPGAs em congressos daACM e IEEE, e portanto não mais restrito aos Workshops. Um pequeno resumo de algunsdesses projetos segue, ordenados cronologicamente:

• Fast Reroute and Multipath [Flajslik et al. 2009]: trata-se de um projeto onde apartir do roteador de referência foi adicionado a possibilidade de recuperação derotas por hardware, em caso de falha. E uma implementação do protocolo ECMP



(Equal Cost Multipath) para realizar o balanceamento de carga de fluxos entre asinterfaces da NetFPGA.

• NetThreads – Programming NetFPGA with Threaded Software [Byma et al. 2013]:A ideia consiste na implementação de uma arquitetura soft-core baseada em NetFPGAmultiprocessada e multithreaded, para que aplicações de rede que têm paralelismoinerente possam se beneficiar e acelerar aplicações paralelas, com melhoria no com-partilhamento dos dados e na sincronização no nível físico.

• DFA-based Regular Expression Matching [Luo et al. 2009]: Esse projeto tratade capturar através de regras do aplicativo Snort e usando expressões regularestransformadas em autômatos determinísticos finitos (DFA) em hardware. Dessemodo, determinados fluxos são capturados baseados em classificação de cabeçalhosde pacotes. Os estados são manipulados na memória da placa e também fora damesma e existe um rastreamento da transição de estados no chip para verificar sedeterminado pacote casa com uma regra complexa.

• OpenPipes – Prototyping High-speed Networking Systems [Gibb et al. 2009]: Trata-se de uma plataforma de criação de “sistemas distribuídos” em hardware, onde cadacomponente pode ficar em um computador separado, interligado em rede. Essescomponentes se comportam como tubos (pipes), tornando a criação modular e sim-ples, de sistemas baseados em hardware escaláveis. Na demonstração, os autoresusam módulos de processamento de vídeo embarcados na placa, como suaviza-ção de imagem, conversão para tons de cinza e inversão de cores, e separados emdiferentes máquinas em rede, onde a execução distribuída é feita com a ajuda daNetFPGA integrando os dados.

• PortLand – A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric [My-sore et al. 2009]: Este trabalho apresenta a concepção de uma rede de centro deprocessamento de dados totalmente baseada em camada de enlace, com tolerân-cia a falhas e alto desempenho. Isso é obtido pelo reuso do endereçamento MACde maneira a permitir a migração de máquinas virtuais intra-rack e inter-rack, e amanutenção de sua conectividade IP. A avaliação do projeto, em alta velocidade,contou com um conjunto de cerca de 40 NetFPGAs. Esse foi um dos primeirostrabalhos a usarem a NetFPGA como apoio à validação experimental em pesquisaem redes de alta velocidade.

• BCube: A High Performance, Server-centric Network Architecture for ModularData Centers [Guo et al. 2009]: Outro artigo na mesma linha do Portland, fo-cado em uma nova arquitetura de rede para centros de processamento de dados.A ideia é um tipo de rede centrada em interligação de servidores, sem apresentarequipamentos de rede como comutadores ou roteadores. Os servidores agem comoencaminhadores de tráfego, além de pontos finais de comunicação. Outras carac-terísticas importantes são tolerância a falhas e balanceamento de carga. Destaca-seque a implementação da prova de conceito foi toda feita em NetFPGA.

• Using NetFPGA to Offload Linux Netfilter Firewall [Chen et al. 2010]: O fra-mework Netfilter está localizado na camada IP do Linux e é caracterizado por uma



série de ganchos (pontos de entrada) que permitem interceptar e manipular pacotesque atravessam a camada IP. Normalmente, ferramentas como o iptables permi-tem a comunicação direta com o Netfilter por meio de soquetes Netlink, de modo arealizar chamadas de sistema nos pontos dentro do kernel e manipular ou descartarpacotes. O projeto modifica o iptables e descarrega algumas regras Netfilter diretopara o hardware por meio da NetFPGA, liberando a CPU para outras atividades.

• A Randomized Scheme for IP Lookup at Wire Speed on NetFPGA [Antichi et al.2010]: Os tempos de busca em uma tabela de encaminhamento (chamados de loo-kups) precisam ser em geral muito baixos, embora o tamanho das tabelas na Internetsó cresça. Nesse sentido, os autores deste trabalho apresentam um novo esquemade busca de endereços usando a NetFPGA, que faz uso de buscas em paralelo fei-tas com funções de hash perfeitas. Essas funções trabalham com uma estrutura dedados de rápido acesso e bastante compactas chamadas de Blooming Trees.

• BORPH: An Operating System for the NetFPGA Platform [Hamilton and So 2010]:O artigo BORPH apresenta o conceito de um sistema operacional projetado para tra-balhar com computadores reconfiguráveis baseados em FPGA. A prova de conceitoé feita por um conjunto de extensões do Linux. Dado a facilidade de reconfiguraçãopelo barramento PCI que a NetFPGA habilita, o sistema foca em prover abstraçõesUNIX como arquivos, de modo a ter acesso direto a recursos de registradores e pro-cessamento da NetFPGA bem como reconfigurar partes do hardware sob demanda.

• The Click2NetFPGA Toolchain [Rinta-aho et al. 2012]: Nesse trabalho, a ideia éfacilitar a aceleração promovida pela NetFPGA na área de aplicações em rede, atra-vés do uso de um sintetizador de alto nível. Em resumo, a partir de uma descriçãode um roteador com linguagem de domínio e componentes básicos em C++ usa-dos no Click Modular Router. O artigo se propõe a transformar automaticamentecódigo existente dentro desse domínio específico em um projeto de hardware fun-cional. A cadeia de ferramentas faz uso de LLVM, como linguagem de abstraçãointermediária, depois uma optimização usando uma técnica chamada AHIR quepermite, a partir de uma estrutura bem definida LLVM, produzir o código VHDLpara a NetFPGA.

Com essa revisão de trabalhos relacionados podemos verificar a ampla coberturae exuberante quantidade de desenvolvimento que a plataforma NetFPGA tem atraído.No que segue nesta seção, daremos destaque em maior profundidade a dois projetos dealto impacto para a realização de pesquisas em redes: a implementação do comutadorOpenFlow na NetFPGA e o Software Testador de Redes OSNT, que permite geração detráfego para testes de desempenho de alta precisão.

4.5.2. Implementação de OpenFlow na NetFPGA

Nesta seção, descreveremos a implementação do OpenFlow em uma placa NetFPGA [Na-ous et al. 2008a]. A princípio é preciso observar que boa parte da complexidade do comu-tador OpenFlow é oriunda de outros elementos NetFPGA de referência como partes daplaca de rede de quatro portas, comutador e roteador IPv4. A implementação possui duas



partes relevantes: o software de gerenciamento, lado que trata as mensagens do protocoloOpenFlow 1.0, e a aceleração da tabela de fluxos (flow table) em hardware.

O software de gerenciamento do comutador OpenFlow é baseado na implementa-ção de referência de comutadores OpenFlow de Stanford. Trata-se de um software abertopara Linux que implementa todo o comportamento de um comutador OpenFlow. Estesoftware de referência pode ser dividido em duas seções: o programa que executa emespaço de usuário e o módulo do kernel.

O processo que executa em espaço de usuário se comunica por soquete com o con-trolador OpenFlow usando SSL para criptografar a comunicação. O processo coordenao envio das mensagens do comutador para o controlador e vice-versa, tratando chegadasde novos fluxos ou atualizações do estado dos enlaces do comutador. As mensagens decontrole permitem adicionar ou remover entradas da tabela de fluxos e são implementa-das através de chamadas de sistema ioctl entre o programa que executa em espaço deusuário e o módulo do kernel.

O módulo do kernel é responsável por manter as tabelas de fluxo, processar pa-cotes, encaminhar, reescrever cabeçalhos e atualizar estatísticas. Por definição, o módulodo kernel do comutador OpenFlow de referência cria a tabela de fluxo em software, e vaitestando as cadeias de regras por um casamento sequencialmente. A prioridade é dadapara a primeira regra que casar dentro da cadeia.

Ainda no módulo do kernel é possível estender a tabela de fluxos para fazer uso deprocessamento em hardware na NetFPGA. Os pacotes que chegam na NetFPGA fazemacesso rápido as entradas da tabela de fluxo armazenadas na NetFPGA e encaminha ospacotes com casamento na mesma taxa dos enlaces (por exemplo, 1 Gbps por porta).Por sua vez, pacotes que não casem com regras de fluxo existentes (por exemplo, fluxosnovos) são enviados para o módulo do kernel do OpenFlow, onde serão tratados. Pacotessem casamento podem chegar ao programa em espaço do usuário, que irá gerar um eventopkt_in e enviá-lo ao controlador.

Figura 4.6. Componentes do comutador OpenFlow NetFPGA.

Ilustramos o módulo output_port_lookup do comutador OpenFlow na figura 4.6.Primeiro ele concatena cerca de dez campos num cabeçalho de fluxo (flow header), eenvia esse cabeçalho para busca nas tabelas de roteamento. A busca é feita em paralelo



utilizando uma combinação de memórias ternárias (TCAMs) no FPGA e memória SRAMpara suportar tanto a possibilidade de “coringas” (prefixos) na TCAM quanto um grandenúmero de entradas exatas de fluxos na SRAM.

Essa busca de entradas exatas utiliza de uma função de hash do cabeçalho defluxo para indexar a SRAM, reduzindo a necessidades de memória e colisões. Após ocasamento de uma regra, o módulo possui uma fase de tomada de ações, através de umárbitro. O árbitro pode editar campos do pacote antes de encaminhá-lo para as filas desaída. Essa fase de ações está associada à sequência dos casamentos, com uma açãodefinida para cada regra com casamento.

4.5.3. OSNT: Open Source Network Tester

O segundo projeto que descreveremos em maior detalhe é a implementação de um testa-dor de rede usando a NetFPGA-10G [Shahbaz et al. 2013]. A solução é código abertoe de alto desempenho operando a 10Gbps, custa para um pesquisador pouco menos de2 mil dólares, sendo que equipamento equivalente em hardware na indústria especiali-zada custa 25 mil dólares. A placa usa um FPGA mais recente e tem a habilidade detrabalhar com múltiplos pipelines de processamento. Entre esses, destacamos somente osubsistema de geração de tráfego, na figura 4.7. Existem outros subsistemas, por exemplopara encapsulamento de pacotes para virtualização e de monitoração passiva e precisa detráfego.

Figura 4.7. Pipeline de Geração de Tráfego da OSNT.

O pipeline gerador de tráfego gera pacotes e analisa estatísticas. O gerador detráfego consiste de pequenos micro-engines, cada qual gera tráfego de acordo com ummodelo de tráfego (TM, traffic model) configurado, uma lista de valores para os cabeça-



lhos dos fluxos (FT) e certos padrões de como gerar o tamanho do pacote, sua taxa e osatrasos entre pacotes (DP). Adicionalmente é possível gerar tráfego a partir de um tracepcap (via tcpdump). Após essa fase de moldagem dos fluxos, existem cinco unidades fun-cionais para efetivar a transmissão: o árbitro seleciona os pacotes e os encaminha quandofor o tempo correto de envio. Depois, o módulo de atraso (DM) controla o atraso, o mó-dulo de limitação de taxa (RL) limita cada fluxo (implementando algoritmo equivalentea um token bucket), o módulo de marcação de tempo (TS) computa quando o pacote foitransmitido e por último o pacote é enviado.

4.5.4. Futuro da NetFPGA: Projetos NetFPGA-10G, 10G-CML e 10G-SUME

Redes de centros de processamento de dados vêm motivando a adoção de sistemas de redemais rápidos. As velocidades oferecidas pela NetFPGA 1 Gbps, embora interessantes doponto de vista de ensino, são bastante defasadas em termos de velocidade para pesquisana área de centros de processamento de dados.

Nesse sentido, o projeto NetFPGA, ao longo dos anos vem colocado a disposiçãoplacas de 10 Gbps, a mais recente com capacidade de I/O de 100 Gbps [Zilberman et al.2014]. Dessa forma, o projeto fica atualizado com relação a uma nova geração de dispo-sitivos de alta velocidade. Ou seja, permite testar novas ideias em escala compatível comambientes de centros de processamento de dados, em empresas como Localweb, UOL,ou Facebook. A NetFPGA 1G era uma placa de baixo custo projetada usando um FPGAXilinx Virtex-II Pro 50. Por sua vez, em 2010, foi lançada a placa NetFPGA 10G, que ex-pandia a plataforma original para trabalhar com transmissões até 40 Gbps sendo 10 Gbpspor interface, com interface PCIe Gen 1, e baseado no FPGA Xilinx Virtex-5 FPGA.

Posteriormente, a placa 10G-CML desenvolvida pela empresa especializada emsegurança cibernética CML (Computer Measurement Lab), atualizou o FPGA para o Xi-linx Kintex-7 325T, e o I/O é baseado no adaptador PCIe x4 Gen 2, com alto desempenho.A última linha de placa que surgiu em 2014 é a 10G-SUME [Zilberman et al. 2014] con-forme mostra a figura 4.8.

Figura 4.8. Foto e Arquitetura da Placa SUME.

A placa NetFPGA SUME é uma placa de custo mais elevado, porém o preço ésubsidiado para pesquisa acadêmica. Além disso ela possui capacidade de I/O aumentadacom operações de até 100 Gbps através do adaptador PCIe x8 Gen 3 e também incorporaum FPGA mais poderoso que é o Xilinx’s Virtex-7 690T. Para demonstrar as capacida-



des da placa SUME, os pesquisadores utilizaram três placas para montar um comutadorOpenFlow com 12 interfaces de 10 Gbps interligadas por um backplane não-blocante de300 Gbps.

Enfim, o futuro da NetFPGA parece bastante promissor em termos de avanços naárea de alto desempenho. O software de todos os projetos desenvolvido está disponívelno GitHub e é licenciado como software livre sob a licença LGPL 2.1, o que permite serutilizado em projetos comerciais.

4.6. Conclusões e perspectivasNeste trabalho apresentamos a plataforma NetFPGA através da demonstração passo-a-passo do desenvolvimento de uma aplicação real. A aplicação consiste de um firewallpara filtragem de pacotes em hardware. Os conceitos básicos da arquitetura da NetFPGAforam discutidos. Mostramos os principais componentes de hardware e software. Osaplicativos de referência como placa de rede, comutador e roteador foram discutidos,além dos módulos de interação hardware-software como a interface de registradores e ocontrolador de memória.

Dado o seu potencial no processamento de pacotes, consideramos que a NetFPGApossui um grande potencial no desenvolvimento de novos projetos de pesquisa, seja per-mitindo prover novas funcionalidades no plano de dados, seja como ferramenta para o de-senvolvimento de novos padrões e protocolos de comunicação, seja no desenvolvimentode novos protótipos de pesquisa. Certamente, a NetFPGA ajudará no desenvolvimento detrabalhos interessantes e com grande potencial na área de redes de computadores.

Apêndice A: Diretivas de programaçãoNeste material adotamos algumas convenções para facilitar o entendimento, listadas aseguir. Alguns dos exemplos citados são recomendações de boas técnicas comuns em lin-guagens de programação, enquanto outras são necessárias para que o hardware resultantealcance o comportamento desejado do projeto.22

• Use constantes e parâmetros para conferir legibilidade ao código. Defina constantesem letra MAIÚSCULA.

• Trechos do código que fazem asserções, monitoram ou imprimem valores de va-riáveis para teste do projeto devem estar posicionadas entre as diretivas synthesistranslate_off e synthesis translate_on. Estes trechos são executados na si-mulação, mas são ignorados pelo sintetizador na criação do bitfile do projeto.

• Em circuitos sequenciais utilize somente atribuições não-blocantes (<=) dessa formatodas as atribuições dentro do bloco (geralmente always) são avaliadas primeiro edepois realizadas na simulação e permitem ao sintetizador inferir o circuito sín-crono. No exemplo a seguir todas as atribuições são sincronizadas com o sinal derelógio e recebem os valores anteriores dos sinais, ou seja, a sequência não importa:

22As recomendações foram extraídas e adaptadas de http://www.xilinx.com/itp/xilinx10/books/docs/sim/sim.pdfe https://github.com/NetFPGA/netfpga/wiki/VerilogCodingGuidelines.



1 always @(posedge clk) begin2 B <= A;3 C <= B;4 D <= C;5 end

• Em circuitos combinacionais certifique-se de preencher a lista de sensibilidade comtodas as variáveis de interesse ou usar always @(*). Nesses circuitos qualquer al-teração em alguma das variáveis na lista forçam a reexecução do bloco (em ge-ral always ou assign) imediatamente. Certifique-se também de somente utilizaratribuições blocantes (=) para que o sintetizador infira um circuito assíncrono. Oparâmetro @(*) é um recurso do Verilog que preenche automaticamente a lista desensibilidade com todos os valores atribuídos dentro do bloco. No exemplo a seguir,as variáveis B, C e D recebem o valor de A:

1 always @(*) begin2 B = A;3 C = B;4 D = C;5 end

• Atribua todas as variáveis em todos os estados possíveis do seu projeto. Este erroocorre geralmente em expressões condicionais if sem a cláusula else ou blocoscase. No exemplo abaixo, cnt_nxt recebe o valor atual de cnt por padrão, paraevitar que ele deixe de ser atribuído se algum estado não requerer sua atualização,e state_nxt é atribuído em todos os estados.

• Em lógicas de controle é recomendado criar circuitos combinatoriais que recebamos valores do próximo estado. Os valores do próximo estado devem ser guardadosem registradores em circuitos síncronos com a borda do relógio:

1 always @(*) begin2 cnt_nxt = cnt;3 case(state)4 INCREMENTA: begin5 if(cnt == 99)6 state_nxt = RESETA;7 else begin8 cnt_nxt = cnt+’h1;9 state_nxt = INCREMENTA;

10 end11 RESETA: begin12 cnt_nxt = ’h0;13 state_nxt = INCREMENTA;14 end15 DEFAULT: begin16 state_nxt = RESETA;



17 end18 endcase19 end20

21 always @(posedge clk) begin22 if(reset) begin23 cnt <= 0;24 state <= INCREMENTA;25 end26 else begin27 cnt <= cnt_nxt;28 state <= state_nxt;29 end30 end

Nesse exemplo, o circuito combinacional calcula os valores de state e cnt queserão atualizados na próxima borda de subida do sinal do relógio pelo circuito se-quencial.

• Não utilize atribuições com atrasos pois são normalmente ignoradas pelas ferra-mentas de síntese, o que pode resultar num comportamento inesperado do projeto.

1 assign #10 Q = 0; // do not use

• Utilize blocos generate para gerar várias instâncias de módulos ou blocos de có-digo. Na seção 4.4.3 utilizamos generate para criar o vetor com os bits de paridadedos dados a serem gravados na memória;

• Outras dicas podem ser encontradas nas páginas Web mencionadas e livros especi-alizados.



Referências[Abelém et al. 2012] Abelém, A., Fdida, S., Rezende, J., Simeonidou, D., Salvador, M.,

and Tassiulas, L. (2012). FIBRE project: Brazil and Europe Unite Forces and Test-beds for the Internet of the Future. In Testbeds and Research Infrastructures for theDevelopment of Networks and Communities (TRIDENTCOM).

[Antichi et al. 2012] Antichi, G., Callegari, C., and Giordano, S. (2012). An Open Hard-ware Implementation of CUSUM-Based Network Anomaly Detection. In Proc. GLO-BECOM.

[Antichi et al. 2010] Antichi, G., Di Pietro, A., Ficara, D., Giordano, S., Procissi, G., andVitucci, F. (2010). A Randomized Scheme for IP Lookup at Wire Speed on NetFPGA.In Proc. ICC.

[Byma et al. 2013] Byma, S., Steffan, J., and Chow, P. (2013). NetThreads-10G: Soft-ware Packet Processing on NetFPGA-10G in a Virtualized Networking EnvironmentDemonstration Abstract. In Proc. Intl. Conf. on Field Programmable Logic and Appli-cations (FPL).

[Casado et al. 2009] Casado, M., Freedman, M. J., Pettit, J., L., J., Gude, N., McKeown,N., and Shenker, S. (2009). Rethinking Enterprise Network Control. IEEE/ACM Trans.Netw., 17(4):1270–1283.

[Chen et al. 2010] Chen, M.-S., Liao, M.-Y., Tsai, P.-W., Luo, M.-Y., Yang, C.-S., andYeh, C. E. (2010). Using NetFPGA to Offload Linux Netfilter Firewall. In Proc.NetFPGA Developers Workshop.

[Covington et al. 2009] Covington, G., Gibb, G., Lockwood, J., and McKeown, N.(2009). A Packet Generator on the NetFPGA Platform. In Proc. 17th IEEE Symp.on Field Programmable Custom Computing Machines.

[Flajslik et al. 2009] Flajslik, M., Handigol, N., and Zeng, J. (2009). Fast Reroute andMultipath. In Proc. NetFPGA Developers Workshop.

[Ghani and Nikander 2010] Ghani, A. and Nikander, P. (2010). Secure In-Packet BloomFilter Forwarding on the NetFPGA. In Proc. NetFPGA Developers Workshop.

[Gibb et al. 2008] Gibb, G., Lockwood, J., Naous, J., Hartke, P., and McKeown, N.(2008). NetFPGA: An Open Platform for Teaching How to Build Gigabit-RateNetwork Switches and Routers. IEEE Transactions on Education, 51(3):364–369.

[Gibb et al. 2009] Gibb, G., Underhill, D., Covington, G. A., Yabe, T., and McKeown,N. (2009). OpenPipes: Prototyping High-speed Networking Systems. In ACM SIG-COMM Conference (Demo).

[Guo et al. 2009] Guo, C., Lu, G., Li, D., Wu, H., Zhang, X., Shi, Y., Tian, C., Zhang, Y.,and Lu, S. (2009). BCube: A High Performance, Server-centric Network Architecturefor Modular Data Centers. In Proc. SIGCOMM.



[Hamilton and So 2010] Hamilton, B. K. and So, H. K.-H. (2010). BORPH: An Opera-ting System for the NetFPGA Platform. In Proc. NetFPGA Developers Workshop.

[Han et al. 2012] Han, D., Anand, A., Dogar, F., Li, B., Lim, H., Machado, M., Mukun-dan, A., Wu, W., Akella, A., Andersen, D. G., Byers, J. W., Seshan, S., and Steenkiste,P. (2012). XIA: Efficient Support for Evolvable Internetworking. In Proc. USENIXNSDI.

[Jacobson et al. 2009] Jacobson, V., Smetters, D. K., Thornton, J. D., Plass, M. F.,Briggs, N. H., and Braynard, R. L. (2009). Networking Named Content. In Proc.ACM CoNEXT.

[Lombardo et al. 2012] Lombardo, A., Reforgiato, D., Riccobene, V., and Schembra, G.(2012). NetFPGA Hardware Modules for Input, Output and EWMA Bit-Rate Compu-tation. Intl. J. of Future Generation Communication and Networking, 5(2):121–134.

[Luo et al. 2009] Luo, Y., Li, S., and Liu, Y. (2009). DFA-based Regular ExpressionMatching Engine on NetFPGA. In Proc. NetFPGA Developers Workshop.

[Mysore et al. 2009] Mysore, R. N., Pamboris, A., Farrington, N., Huang, N., Miri, P.,Radhakrishnan, S., Subramanya, V., and Vahdat, A. (2009). PortLand: A ScalableFault-tolerant Layer 2 Data Center Network Fabric. In Proc. SIGCOMM.

[Naous et al. 2008a] Naous, J., Erickson, D., Covington, G. A., Appenzeller, G., and Mc-Keown, N. (2008a). Implementing an OpenFlow Switch on the NetFPGA Platform. InProc. of the ACM/IEEE Symposium on Architectures for Networking and Communica-tions Systems (ANCS).

[Naous et al. 2008b] Naous, J., Gibb, G., Bolouki, S., and McKeown, N. (2008b).NetFPGA: Reusable Router Architecture for Experimental Research. In Proc. ACMWorkshop on Programmable Routers for Extensible Services of Tomorrow (PRESTO).

[Ratnasamy et al. 2006] Ratnasamy, S., Ermolinskiy, A., and Shenker, S. (2006). Revisi-ting IP Multicast. In Proc. ACM SIGCOMM.

[Rinta-aho et al. 2012] Rinta-aho, T., Karlstedt, M., and Desai, M. P. (2012). TheClick2NetFPGA Toolchain. In Proc. USENIX ATC.

[Shahbaz et al. 2013] Shahbaz, M., Antichi, G., Geng, Y., Zilberman, N., Covington,A., Bruyere, M., Feamster, N., McKeown, N., Felderman, B., and Blott, M. (2013).Architecture for an Open Source Network Tester. In Proc. ACM/IEEE Symp. on Archi-tectures for Networking and Comm. Systems.

[Thinh et al. 2012] Thinh, T. N., Hieu, T. T., and Kittitornkun, S. (2012). A FPGA-basedDeep Packet Inspection Engine for Network Intrusion Detection System. In Proc. ofECTI-CON.

[Yu et al. 2013] Yu, M., Jose, L., and Miao, R. (2013). Software Defined Traffic Measu-rement with OpenSketch. In Proc. NSDI.



[Zeng et al. 2009] Zeng, J., Covington, A., Lockwood, J., and Tutor, A. (2009).AirFPGA: A Software Defined Radio Platform Based on NetFPGA. In Proc. NetFPGADevelopers Workshop.

[Zilberman et al. 2014] Zilberman, N., Audzevich, Y., Covington, G., and Moore, A.(2014). NetFPGA SUME: Toward 100 Gbps as Research Commodity. IEEE Micro,34(5):32–41.



Capítulo

5Introdução a Rádios Definidos por Software comaplicações em GNU Radio

Wendley S. Silva, Jefferson Rayneres S. Cordeiro, Daniel F. Macedo, Mar-cos A. M. Vieira, Luiz F. M. Vieira, José Marcos S. Nogueira

Abstract

Software-defined radios (SDR) allow reducing the amount of communication functionsimplemented in hardware. Thus, the communication devices become more flexible andeasy to be programmed. SDRs are used in experimental research in Computer Networks,as well as prototyping and fast deployment of new communication technologies. Thiscourse covers introductory concepts of SDR and GNU Radio platform. The course showsthe basic concepts of wireless communications and digital transmissions, focusing onthe data link layer. Practical applications of SDR, focused on experimental research onwireless networks, such as proposing new modules for GNU Radio, are demonstrated.

Resumo

Rádios definidos por software (SDR) permitem reduzir a quantidade de funções de comu-nicação implementadas em hardware. Desta forma, os dispositivos de comunicação setornam mais flexíveis e fáceis de serem programados. SDRs são empregados na pesquisaexperimental em Redes de Computadores, bem como na prototipagem e implementaçãorápida de novas tecnologias de comunicação. Este minicurso aborda os conceitos intro-dutórios de SDR e da plataforma GNU Radio. O curso apresenta os conceitos básicosde comunicações sem fio e transmissões digitais, focando nos aspectos relativos à ca-mada de enlace. São demonstradas aplicações práticas de SDR, focadas na pesquisaexperimental em redes sem fio, por exemplo como propor novos módulos no GNU Radio.

5.1. IntroduçãoDe acordo com [Wireless Innovation Forum ], os Rádios Definidos por Software (Software-Defined Radios – SDR) são um conjunto de tecnologias de hardware e software, onde al-gumas ou todas as funções operacionais do rádio são implementadas através de software

5: Introdução a Rádios Definidos por Software com aplicações em GNU Radio.


ou firmware modificável, que é executado em tecnologias de processamento programáveis(por exemplo, um FPGA, um CPU genérico). Por outro lado, em [Dillinger et al. 2003] oconceito SDR é um pouco diferente: SDR é um sistema de comunicação de rádio, ondeos componentes que eram tipicamente implementados em hardware (por exemplo, filtros,amplificadores, moduladores/demoduladores, detectores etc.) agora são implementadosem software utilizando um computador pessoal ou sistemas embarcados. O conceito uti-lizado neste trabalho é o apresentado em [Reis et al. 2012], em que SDR é um transceptorsem fio, onde módulos de software implementam as funcionalidades do transceptor. Estesmódulos são executados em tempo real em microprocessadores genéricos, processadoresde sinais digitais ou circuitos lógicos programáveis.

Os militares dos EUA foram os primeiros a empregar SDR, tentando fornecer rá-dios flexíveis para operações de grande escala [Dillinger et al. 2003]. O objetivo era ga-rantir a interoperabilidade dos rádios militares com o de outras agências governamentais(bombeiros, polícia, agências de inteligência). Tal necessidade vem de uma razão prática,pois cada órgão realiza as suas compras de forma independente, e assim as tecnologias decomunicação empregadas podem ser incompatíveis do ponto de vista da frequência uti-lizada, tecnologia de modulação de sinais, dentre outros. Assim, o termo “rádio digital”foi cunhado para definir rádios que se adaptam a diferentes padrões operacionais.

Nesse contexto, Joseph Mitola propôs em sua tese de doutorado o conceito de rá-dios cognitivos, que são rádios que adaptam a sua operação com base em condições doambiente, aprendendo com o comportamento passado e melhorando o seu funcionamentocom o tempo [III 2000]. O conceito de rádio cognitivo é mais amplo que os rádios di-gitais, pois envolve mecanismos de inteligência artificial e aprendizado para identificara condição do meio e propor uma configuração adequada a cada momento. Devido àsaltas demandas de processamento de rádio cognitivo, que eram impraticáveis na época, oconceito inicialmente não recebeu muita atenção.

Em 2002, o FCC (Federal Communications Commission), órgão regulador das te-lecomunicações nos EUA, reacendeu o interesse em rádios cognitivos. O FCC publicouum relatório sobre a utilização do espectro de rádio-frequência nos EUA [Force 2002],concluindo que o espectro eletromagnético é um recurso utilizado de forma ineficiente eescasso. O FCC descobriu que, apesar da maior parte do espectro já possuir um uso licen-ciado, os detentores da licença não usam o espectro todo o tempo e em todas as regiõesgeográficas onde a sua licença é válida. Assim, o FCC propôs a utilização oportunista doespectro, onde os usuários não licenciados poderiam explorar espectro vago sempre queo usuário licenciado não esteja a utilizando no momento.

Um aspecto fundamental para o sucesso dos rádios cognitivos são transceptoressem fio capazes de operar em múltiplas frequências, que ainda podem detectar a existênciade usuários licenciados. Para tanto, o rádio deve ser capaz de “falar” diversas tecnologiasde comunicação, seja para detectar os usuários licenciados, seja para comunicar de formaeficaz em frequências com características bem distintas. Além dos rádios cognitivos, oSDR permite ainda diversas aplicações.



5.1.1. Aplicações de SDR

Como veremos a seguir, os SDR são aplicáveis em diversos domínios, desde rádios uni-versais de baixo custo a sistemas flexíveis que permitem a pesquisa experimental emRedes de Computadores e Telecomunicações. Primeiramente iremos discutir os usos co-merciais da tecnologia.

5.1.1.1. Usos comerciais

Em 2011, o Wireless Innovation Forum encomendou um estudo para avaliar a taxa deadoção de SDR na indústria [Forum 2011]. Os resultados indicam que mais de 90% dainfra-estrutura móvel naquele ano empregava tecnologias SDR de algum tipo. Para osmercados em que a interoperabilidade é um requisito obrigatório, como em aplicaçõesmilitares e de segurança pública, eles descobriram que quase todos os transceptores e es-tações base empregam SDR. No entanto, dependendo da largura de banda do sinal, algumprocessamento ainda é realizado em hardware. Por exemplo, turbo códigos e correção deerro (Forward Error Correction) são freqüentemente implementados em hardware.

Rádios definidos por software também estão sendo utilizados para reduzir os cus-tos para os operadores de telecomunicações. A China Mobile está promovendo a adoçãode C-RAN [Chen and Duan 2011], que é uma torre de celular SDR onde todo o processa-mento de dados é feito em servidores em nuvem. Seu objetivo é a implementação de todasas funcionalidades via software executado em data centers, onde é mais fácil de atuali-zar as funções de rede. Ao mesmo tempo, esta arquitetura simplifica as torres celulares,reduzindo o consumo de energia.

Há também muitas empresas que exploram o mercado de SDRs para rádio ama-dores. Muitas plataformas são focadas em amadores ou geeks que querem desenvolverseus próprios receptores para aplicações como navegação marítima, rádio amador, dentreoutros. Mesmo produtos comerciais que não foram destinados como SDR são reprogra-mados para este meio, uma vez que os usuários descobrem que um certo hardware ouplaca realiza todo o processamento de sinais em software [Cass 2013]. Alguns grupos derádio amador disponibilizaram receptores SDR ligados à Internet, onde os entusiastas po-dem sintonizar a frequência desejada em diferentes partes do mundo, sem a necessidadede comprar seus próprios SDRs1.

Rádios definidos por software são agora uma realidade, como se vê pela quanti-dade de plataformas comerciais e gratuitas disponíveis no mercado 2. Há uma lista extensade módulos de software livre, e um bom suporte e integração com os ambientes de de-senvolvimento (IDEs) mais populares do mercado. No entanto, as plataformas existentesainda estão lutando para alcançar os requisitos de largura de banda e eficiência de energianecessários para padrões de alta velocidade, tais como LTE (Long Term Evolution, umdos protocolos de 4G) e o IEEE 802.11ac.

1Alguns exemplos são http://websdr.org/ e http://rsgb.org/main/operating/web-sdr-receiver/.

2Ver http://en.wikipedia.org/wiki/List_of_software-defined_radios parauma lista de algumas das plataformas existentes.



5.1.1.2. Usos acadêmicos

Dada a quantidade de plataformas comerciais e acadêmicas viáveis que são capazes deimplementar 3G e rádios IEEE 802.11a/b/g/n e outras tecnologias, diversos grupos depesquisa passaram a integrar SDRs na sua lista de equipamentos. Um aspecto positivo doSDR é que ele diminuiu o custo para a realização de pesquisas experimentais em tecno-logias da camada física e enlace. Assim, experimentos que antes eram possíveis somenteem laboratórios de grandes empresas, podem ser feitos em laboratórios de universidadesa um custo razoável. Para dar uma importância do SDR na área de redes sem fio, somentea plataforma WARP da universidade de Rice contabilizou 59 artigos científicos que em-pregaram o seu hardware em 20143, apesar do seu alto preço (a partir de USD5.000 aunidade). Seguem abaixo algumas propostas recentes que foram possíveis devido ao usode SDRs.

• Uso de codificação de rede (network coding) para aumentar a capacidade. Usandoo conceito de codificação de rede, é possível enviar um pacote que é a combinaçãode vários pacotes em enlaces sem fio, aumentando a vazão global da rede. Os ga-nhos dependem do padrão de tráfego, que vão desde uma pequena percentagem atéa ganhos de várias vezes [Katti et al. 2008]. O uso de múltiplas taxas de transmis-são pode apresentar ganhos ainda maiores [Vieira et al. 2013].

• Recuperação de quadros perdidos com o processamento de sinais. Os rádiosarmazenam os sinais recebidos a partir de uma colisão, e tentam subtrair qua-dros recebidos corretamente (após uma retransmissão), permitindo muitas vezesobter o quadro envolvido em uma colisão sem que esse precise ser retransmitido.[Lin et al. 2008].

• Códigos Rateless. Na comunicação tradicional sem fio, os dados são transmiti-dos empregando uma certa modulação. Cada modulação requer um certo limiarSignal to Interference plus Noise Ratio (SINR) para a decodificação correta dosseus dados e, de modo a lidar com as variações no SINR, os protocolos existentes(por exemplo os protocolos WiFi e WiMax) usam mecanismos de troca automá-tica de modulação. Códigos Rateless [Gudipati and Katti 2011, Perry et al. 2012,Shokrollahi 2006] utilizam uma quantidade variável de símbolos para codificar osdados. O transmissor envia os dados utilizando códigos diferentes, e o receptor usaesses códigos para identificar qual palavra é a mais provável que tenha sido empre-gada para gerar os sinais recebidos. Códigos Rateless exigem protocolos especiaisda camada de enlace [Iannucci et al. 2012], que também podem ser testados usandoSDR. O principal benefício de códigos rateless é que ele fornece uma largura debanda no enlace muito mais próxima da capacidade teórica de Shannon.

• Rádios full-duplex. Os rádios comerciais existentes são half-duplex, uma vez queuma antena de recepção seria saturada com os sinais transmitidos por outra an-tena adjacente. No entanto, pesquisas recentes empregando SDR e hardware dedi-cado conseguem obter níveis de cancelamento de ruído tais que permitem imple-

3http://warp.rice.edu/trac/wiki/about



mentar rádios full duplex compatíveis com as larguras de banda dos padrões IEEE802.11b[Hong et al. 2012] e IEEE 802.11ac[Bharadia et al. 2013].

• Separação de canais de controle e de dados. Quando é necessário separar osquadros de controle dos quadros de dados em redes sem fio, a maioria das im-plementações empregam vários rádios. Em Flashback[Cidon et al. 2012], o rádiogera pulsos OFDM que criam um canal de controle separado, na mesma frequênciautilizada pelo canal de dados. Este canal de controle permite que os nós enviemmensagens curtas de controle, sem comprometer a decodificação dos quadros dedados e sem reduzir a taxa de transferência do canal de dados.

• MIMO cooperativo para WLANs empresariais. OpenRF [Kumar et al. 2013]usa o conceito de vetores de codificação, a fim de executar a formação de feixesque permitem o alinhamento e o cancelamento de interferência em redes WLANcom múltiplos pontos de acesso. Com a ajuda de um controlador centralizado eum algoritmo de escalonamento local rodando em cada ponto de acesso, é possívelexplorar as capacidades de MIMO do padrão IEEE 802.11n para melhorar a SINRnas estações. Isto, por sua vez, reduz as variações em latência e aumenta a vazão darede.

5.1.2. Relação entre os conceitos de SDN e SDR

As redes definidas por software (Software-Defined Networks – SDN) são uma tecnologiamuito popular no mercado de redes atualmente, em que os algoritmos de controle sãoexecutados fora dos dispositivos de rede. Isto permite uma separação entre o plano dedados (que é responsável pelo encaminhamento e codificação dos dados na rede) e oplano de controle (que implementa as políticas que controlam o funcionamento do planode dados). No entanto, em SDN, somente é possível modificar o funcionamento do planode controle, enquanto o plano de dados permanece inalterado.

Assim, o SDR se apresenta como uma tecnologia complementar ao SDN, porpermitir modificar o plano de dados em redes sem fio. Em um sistema misto SDN-SDR,seria possível desenvolver redes que empregam diversos mecanismos de transmissão dedados, que seriam controlados utilizando protocolos SDN. Enquanto o SDR se preocupana adaptação da transmissão em cada enlace, os mecanismos de SDN garantiriam quetodos os enlaces, e assim a rede como um todo, operem de forma coordenada e otimizada.

Em Sistemas Operacionais e gerenciamento de redes existe um conceito muitoútil para explicar a interação entre SDN e SDR: o conceito de política e mecanismo. Osmecanismos definem algoritmos, procedimentos ou componentes que realizam uma de-terminada função, enquanto as políticas definem os parâmetros dos mecanismos, e comoeles se relacionam. Por exemplo, para autenticação de usuários temos mecanismos comoservidor LDAP e contas locais. Podemos construir políticas tais como: permitir autenti-cação de contas LDAP a qualquer momento, e contas locais somente em dias úteis e emhorário comercial. Desta forma, podemos pensar que SDR irá fornecer os mecanismospara a construção de uma rede, enquanto SDN irá cuidar das políticas da rede, orques-trando as interações entre os diversos dispositivos sem fio.



5.1.3. Vantagens e desvantagens de SDR

Apesar de trazer enormes vantagens em relação à metodologia tradicional de desenvolvi-mento de placas de rádio-frequência, o SDR também possui desvantagens. Assim, quandoutilizada em produtos comerciais, é importante avaliar a cada projeto se o uso de SDR émais vantajoso que uma alternativa de circuito integrado puro. A seguir listamos algumasvantagens e desvantagens do uso de SDR.

• Vantagem: dispositivos evolutivos. Como a maioria das funcionalidades em SDRé implementada em software, o equipamento pode receber novas funcionalidadesou correções de bugs mesmo após a sua comercialização e entrada em operação.Por exemplo, se encontramos um bug em um módulo de demodulação do sinal deum telefone celular, a única solução é mudar o componente. O uso de camadasPHY/MAC programáveis permitiria correções. Além disso, o mesmo dispositivopode ser atualizado sempre que novos padrões são liberados. Apesar dos dispo-sitivos atuais já possuírem parte desta flexibilidade por utilizarem o conceito defirmware, em geral a totalidade ou grande parte da camada física dos dispositivos éimplementada em hardware.

• Vantagem: reuso de hardware. Cada país tem suas próprias regras no que dizrespeito às comunicações, assim, grandes empresas são obrigadas a fabricar dife-rentes versões de um mesmo hardware a fim de obedecer a legislação de cada país(por exemplo, esquemas de modulação diferentes, formatos de mensagens, faixasde frequências etc.). Por exemplo, diferentes padrões de TV digital são adotados naEuropa, EUA, Ásia e Brasil. Isso aumenta o custo, uma vez que os componentessão fabricados em uma quantidade menor. Enquanto isso, com hardware progra-mável, as especificidades de cada região poderiam ser implementadas em software,criando uma única plataforma de hardware. Um “telefone mundial” exigiria menoschips e também seria menor: em vez de ter que possuir um chip por padrão, o chippoderia ser reprogramado sobre demanda.

• Vantagem: protocolos de comunicação cientes da aplicação. A comunicaçãoTCP/IP, padrão nas redes, opera em um sistema de caixa preta. O uso de abstra-ções como mensagens, circuitos ou pacotes limita o conjunto de ações possíveispara operações básicas, como a filtragem por endereço e porta, estabelecendo pa-râmetros de QoS etc. Como a implementação tem de suportar fluxos genéricos, oequipamento deve utilizar soluções muito abrangentes, e desta forma não é pos-sível empregar otimizações específicas de cada aplicação. Em muitas situações,redes sem fio são empregadas para um propósito específico, e são interligadas comredes tradicionais por um nó sorvedouro ou uma ponte. Assim, o trecho que é uti-lizado para um propósito específico poderia empregar protocolos otimizados paraa aplicação, por exemplo utilizando os conceitos de redes centradas em dados ouidentificadores geolocalizados.

• Vantagem: uso de níveis mais altos de abstração. A maioria das arquiteturas dehardware programável fornece um conjunto de interfaces de programação (APIs),uma linguagem de programação de domínio específico (DSL) ou abstrações base-adas em componentes. Isso aumenta a independência do hardware em relação ao



software. Maiores níveis de abstração permitem que os compiladores, sistemas ope-racionais e middlewares possam executar métodos de otimização e verificação maiscomplexos, gerando um código melhor, mais rápido e mais confiável, e reduzindoo tempo de desenvolvimento.

• Desvantagem: desempenho inferior. Sistemas implementados totalmente em cir-cuitos integrados tendem a superar os sistemas baseados em software em termos dedesempenho devido a muitas razões. Um sistema baseado em hardware é otimizadopara a tarefa em questão, entretanto um sistema baseado em software geralmenteemprega um hardware genérico (por exemplo, uma CPU ARM ou uma FPGA),requerendo assim mais ciclos para executar as mesmas tarefas. Outro aspecto éque a mesma unidade de processamento de um dispositivo programável pode sercompartilhada entre muitas tarefas, de comunicação ou não, reduzindo a capaci-dade de processamento efetiva para a comunicação e gerando atrasos. Finalmente,a execução de muitas camadas de software (por exemplo, do sistema operacional,bibliotecas, middlewares) acrescenta um custo adicional de processamento, o quereduz o desempenho final. Para ilustrar, switches implementados em software ro-dando em CPUs tendem a processar 1 ou 2 ordens de grandeza menos pacotes porsegundo que os switches baseados em hardware [Intel 2013].

• Desvantagem: uso de energia superior e maior área de circuito. Uma imple-mentação programável pode exigir mais portas lógicas do que uma implementaçãode hardware completo. Esta pode ser uma limitação significativa para as redesprogramáveis em situações onde o tamanho do chip e o consumo de energia sãorestrições de projeto fundamentais, como por exemplo em dispositivos móveis. En-tretanto, vale lembrar que a área de circuito depende muito das operações forneci-das pelo hardware e do seu desenho. A micro-programação, que nada mais é queuma forma de programação dos componentes de um micro-processador, permitiuuma redução da área das CPUs ao reduzir a complexidade dos seus componentesinternos.

• Desvantagem: problemas de interoperabilidade. A proliferação de diferen-tes implementações pode exacerbar a interoperabilidade das redes diferentes. Porexemplo, um ponto de acesso pode ter que lidar com os pacotes com formatos des-conhecidos, ou um ponto de acesso pode enfrentar uma rede com uma mistura deestações que implementam o 802.11 tradicional bem como outras implementaçõescustomizadas do mesmo.

• Desvantagem: segurança. Hoje em dia, uma parte ainda significativa da funciona-lidade dos transceptores é implementada em hardware, de modo que é impossívelmodificá-la sem o acesso físico ao hardware. No entanto, como mais funcionali-dades são movidas para software, as falhas de segurança podem ocorrer em níveismais baixos dos protocolos, com um custo menor, e estas podem ser exploradas re-motamente. Por exemplo, um hacker poderia inutilizar uma placa Wi-Fi, do outrolado do mundo, para transformá-la em um gerador de interferência.



5.2. Arquiteturas e plataformas de desenvolvimento5.2.1. Tipos de SDR

A Figura 5.1 mostra a arquitetura básica de um SDR que opera tanto como um transmissorou receptor. Nela, os ADCs (conversores analógico para digital), DACs (conversores dedigital para analógico) e filtros de frequência são componentes que devem ser implemen-tados em hardware (blocos em cor branca), enquanto todas as outras operações do trans-ceptor poderiam ser realizadas por unidades de processamento programáveis (bloco emcor cinza escuro). A unidade de processamento pode empregar CPUs de propósito geral,processadores de sinais (DSP), FPGAs, ou até mesmo lógica discreta [Nagurney 2009].Em muitas aplicações, o sinal de banda base (baseband) em si é digital, o que permite queos ADCs e DACs para a banda base, bem como os filtros associados, possam ser elimina-dos e os sinais digitais são alimentados diretamente para a unidade de processamento.

Processador) DAC)ADC) Filtro)Filtro)

Recepção) Transmissão)

Figura 5.1. Arquitetura simplificada de um Rádio Definido por Software.

Para implementar SDR, existem duas arquiteturas principais. A solução mais sim-ples é colocar vários chipsets que implementam diversos padrões de comunicação em ummesmo rádio e alternar entre eles conforme necessário, mas isso tem pouca flexibilidade.Outras técnicas atingem a flexibilidade usando configurações de hardware especializados,mas esses sistemas têm suas desvantagens. As duas principais arquiteturas utilizadas naprática são chamadas de SDR Modal e SDR Reconfigurável, e estão detalhadas abaixo.

5.2.1.1. SDR Modal

Arquiteturas de SDR Modal funcionam como um rádio com N implementações, que sãoalternadas sobre demanda. Esta arquitetura surgiu na década de 1990, quando as tecnolo-gias celulares analógicas foram gradualmente substituídas por redes digitais. Nesta situa-ção, eram necessários telefones que pudessem oferecer serviços digitais a maior parte dotempo, mas estes deveriam suportar o modo analógico em áreas onde a cobertura digitalainda não existia. A solução óbvia era combinar os chipsets analógicos e digitais no inte-rior do aparelho, com software realizando o chaveamento entre eles. A Figura 5.2 mostraum exemplo de rádio modal, tendo duas tecnologias implementadas: TDMA e AMPS. Nafigura, caixas cinzas indicam componentes baseados em software, enquanto que os com-ponentes em caixas brancas indicam componentes em hardware. A abordagem de SDRModal continua a ser uma alternativa para aplicações que necessitam de uma quantidade



limitada de flexibilidade, por exemplo, para redes celulares que fornecem conectividade3G e 4G.

Microcontrolador)

Chipset)digital)

Chipset)analógico)

Figura 5.2. Exemplo de um SDR modal.

5.2.1.2. SDR Reconfigurável

Existem aplicações em que o SDR modal é uma solução inadequada, por exemplo napesquisa experimental. Além disso, sistemas de SDR Modal não escalam bem com aquantidade de formas de onda a serem suportadas. Nestas situações, é mais interessanteempregar hardware programável para fazer o processamento dos sinais. Desta forma, ohardware pode suportar uma quantidade ilimitada de padrões e técnicas de transmissão.Esta abordagem é frequentemente denominada SDR reconfigurável, porque o hardwarepode ser configurado para qualquer aplicação. Como mostrado na Fig 5.3, o elementoprogramável pode ser composto por FPGAs, DSPs e/ou CPUs, que podem ser programa-dos para realizar operações de processamento de sinais em alta velocidade. Novamente,componentes na cor branca indicam blocos de hardware, enquanto que blocos na corcinza indicam software.

DSP,)FPGA)ou)processador)Chipset)genérico)

Figura 5.3. Exemplo de um SDR reconfigurável.

5.2.2. Plataformas de SDR

Nesta seção iremos apresentar algumas plataformas existentes de SDR. Esta lista não éexaustiva, e foi compilada tendo em vista apresentar o aspecto de possibilidades de projetoe capacidades das plataformas de SDR atual.



5.2.2.1. USRP

A Universal Software Radio Peripheral (USRP) é um framework para o desenvolvi-mento de rádios digitais, proporcionando uma infra-estrutura completa para o proces-samento de sinais. O sistema caracteriza-se por sua alta flexibilidade e custo-benefício[Ettus Research a]. No USRP, mais de uma antena pode ser ligada ao dispositivo, em fun-ção das exigências do usuário. É possível, por exemplo, ligar três antenas com o objetivode transmitir diferentes estações de rádio FM. Também é possível realizar o procedimentoinverso, ou seja, receber várias frequências ao mesmo tempo. Outra possibilidade é a li-gação simultânea de antenas para transmitir e receber sinais usando MIMO. USRPs sãonormalmente programados com o software GNU Radio, simplificando o desenvolvimentode novas soluções SDR através da reutilização de funcionalidades existentes.

As placas filhas (daughter-boards) implementam o front-end de rádio frequênciado USRP. Estas placas executam a conversão digital analógica, definindo assim a potên-cia e frequência dos sinais emitidos e recebidos. O USRP trabalha com potências de sinalentre 50 e 200 mW. Finalmente, o USRP permite a ligação de várias placas filhas simul-taneamente. Uma placa USRP popular é a Ettus Research N210 [Ettus Research b], queinclui conversores ADC e DAC, um FPGA, uma interface Ethernet Gigabit para se comu-nicar com o computador, e uma interface serial de alta velocidade para a integração comoutras placas, permitindo o desenvolvimento de sistemas MIMO. O FPGA pode realizara totalidade ou uma parte do processamento de sinal digital, permitindo, se for configu-rado, transferir o processamento para outros dispositivos de computação, tais como umcomputador, via Ethernet ou USB.

Visualizamos na Figura 5.4 a placa Ettus B210, que possui como principais carac-terísticas:

• É o primeiro dispositivo USRP totalmente integrado de dois canais com coberturade RF contínua de 70 MHz a 6 GHz, i.e., não há necessidade de instalação deplacas-filhas;

• Full-Duplex, operação MIMO (2 Tx e 2 Rx) com até 56 MHz de largura de bandaem tempo real (61.44MS/s quadratura);

• conectividade rápida com USB 3.0 através do controlador Cypress EZ-USB FX3;

• suporte ao GNU Radio e OpenBTS através de drivers de código-fonte aberto (UHD- USRP Hardware Driver);

• FPGA Xilinx Spartan 6 XC6SLX150;

• prototipagem utilizando o dispositivo interno AD9361 RFIC.

Este equipamento permite executar uma ampla gama de aplicações, incluindo:FM e transmissão de TV, celular, GPS, WiFi, ISM, ZigBee etc. A arquitetura do USRPB210 pode ser melhor compreendida observando a Figura 5.5. Temos como principaiselementos as interfaces USB 3.0 e RF Frontend, o FPGA Xilinx Sparta 6 e o sistema de



Figura 5.4. Placa USRP Ettus B210 [Research 2015]

clock. A placa é alimentada por uma fonte externa de energia DC de 6V [Research 2015].Opcionalmente, podemos inserir um módulo GPSDO (GPS-Disciplined Oscillator Kit),apresentado na Figura 5.5, para aplicações que necessitem de temporização com precisãode nanosegundos.

5.2.2.2. SORA

SORA [Tan et al. 2009] é um pseudônimo para Microsoft Research Software Radio, que éa plataforma SDR desenvolvida pela Microsoft Research (MSR) Asia em Beijng. SORAcombina o desempenho e a fidelidade da SDR baseada em hardware com a programaçãoe flexibilidade de um processador de propósito geral (Generic Purpose Processor – GPP).SORA é uma plataforma SDR que permite o desenvolvimento de novas tecnologias emredes sem fio sem a necessidade de hardware específico, ou seja, usando apenas um com-putador pessoal. Assim, o hardware SORA possui somente um decodificador de bandabase, e todo o processamento é feito por uma CPU x86. No entanto, o desenvolvimento deuma solução em PCs traz algumas dificuldades, tais como a necessidade de uma ligaçãode alta taxa de transferência para transferir o sinal digital para a memória principal.

Além disso, o processamento de sinal na camada física requer quantidades sig-nificativas de processamento, e a camada física e protocolos MAC exigem temporizaçãorigorosa e baixa latência. SORA usa técnicas tanto de hardware quanto de software parasuperar estes desafios. Como uma solução para a alta taxa de transferência de dados, aMSR emprega uma placa de controle de rádio (Radio Control Board – RCB) para a trans-missão e recepção de sinal, que é conectada ao PC por um barramento PCI Express debaixa latência. Com este barramento, o RCB pode suportar até 16.7Gbps (modo PCI-e8x) com latências inferiores a um microssegundo. Esta capacidade satisfaz os requisitosde tempo de padrões de alta velocidade, como o IEEE 802.11g.



Figura 5.5. Esquema da arquitetura do USRP Ettus B210 [Research 2015]

Os requisitos de processamento exigidos por uma SDR são possíveis no SORAatravés do uso de instruções SIMD (Single Instruction Multiple Data) existentes nasCPUs x86, que aceleram o processamento de sinais na camada física. Além disso, oSORA requer um novo serviço de kernel, a dedicação de núcleos, que aloca um núcleodo processador exclusivamente para tarefas de SDR. Outro truque curioso da plataformaé a implementação de mensagens de confirmação. Como estas mensagens devem ser en-viadas logo após a recepção do quadro de dados, elas são pré-computadas em paralelo àrecepção dos dados, independentemente do quadro de dados ter sido decodificado corre-tamente.

5.2.2.3. SODA

SODA é uma implementação SDR de baixo consumo [Lin et al. 2006]. Ela foi desen-volvida como um processador de propósito especial, projetado para as operações maiscomuns necessárias para a implementação de PHY e camadas MAC em software. Comoconseqüência, SODA emprega várias unidades de processamento paralelo, com pouca ouquase nenhuma inter-comunicação.

O projeto do SODA foi baseado em uma análise cuidadosa do fluxo de dados eoperações realizadas em um transceptor sem fio. Esta análise mostrou que as operaçõescomuns do transceptor não exigem interação com outras operações em execução. A únicacomunicação entre elas ocorre quando uma determinada operação for concluída, e a suasaída deve ser encaminhada para a próxima operação, formando um pipeline. Este pipe-line também influenciou o modelo de execução do SORA, pois cada tarefa é estaticamenteatribuída a uma unidade de processamento. O número de unidades de processamento,



bem como o tamanho das instruções SIMD foi definida de acordo com simulações, queidentificaram a quantidade de níveis de pipeline que minimizava o consumo de energiada arquitetura. Finalmente, a arquitetura também emprega um processador ARM para oprocessamento de protocolos da camada MAC, que requerem um conjunto de instruçõesmais genérico.

SODA foi empregada para implementar dois padrões importantes de redes semfio: W-CDMA e 802.11a. Em ambos os casos, SODA apresentou vazão (throughput) su-ficiente para a boa execução dos protocolos. Por fim, os autores avaliaram o consumo deenergia de SODA usando um sintetizador, mostrando que esta arquitetura poderia atenderàs restrições de energia de dispositivos móveis se produzido usando métodos de fabrica-ção baseados na tecnologia de 90 nm ou 65 nm.

5.2.2.4. FLAVIA e soft-MACs

Existem diversas plataformas para desenvolvimento de protocolos MAC em software, quesão conhecidas na literatura como soft MACs. Nestas plataformas, o programador possuiuma camada física fixa, e o mesmo implementa somente a sub-camada MAC da camadade enlace. Os soft MACs, apesar de mais limitados que um SDR completo, são mais fáceise amigáveis de programar. Um exemplo muito interessante de soft MAC é o FLAVIA, queserá descrito a seguir.

O FLAVIA executa aplicações SDR em placas sem fio de baixo custo, permitindoo fácil desenvolvimento de novos protocolos MAC [Tinnirello et al. 2012]. A plataformaemprega um firmware modificado, que é carregado em transceptores que empregam umchipset bem conhecido e popular no mercado. O firmware implementa uma máquina deestados finitos baseada em eventos, onde os eventos são situações comuns em protocolossem fio: início de um intervalo de contenção, colisão, recepção de um quadro de confir-mação etc. O projeto FLAVIA está limitado ao protocolo MAC em 2.4GHz, uma vez quenão é possível implementar novos módulos para processamento e modulação do sinal, oumudar a frequência de operação.

No FLAVIA, os usuários podem criar novos protocolos sem fio utilizando os even-tos pré-definidos. Assim, ele oferece uma linguagem de programação de propósito especí-fico e de nível de abstração superior ao das outras plataformas. Ele é de fácil programaçãoe possui uma interface gráfica básica, onde o usuário constrói o seu código rapidamente.A limitação da plataforma é a falta de extensibilidade, uma vez que apenas os estados eeventos fornecidos pelos autores são suportados. Além disso, não é possível criar progra-mas mais complexos, uma vez que a plataforma tem um número limitado de registros eoperações condicionais.

FLAVIA foi implementado em um chipset descontinuado, de forma que não é maispossível comprar placas para PCs. Entretanto, este chipset ainda pode ser encontradoem alguns roteadores IEEE 802.11g disponíveis no mercado por até R$300,00. Essesroteadores podem ser programados usando distribuições Linux baseadas em ARM, comoOpenWRT [Ope ]. O OpenFWWF (Open Firmware for Wi-Fi) [Gringoli and Nava ] éum projeto open source gerado a partir de FLAVIA, que divulgou as especificações damemória e registradores usados no firmware, bem como o seu código fonte. Entretanto,



os desenvolvedores estão pouco ativos, e poucas atualizações foram realizadas no códigodepois que o projeto se separou do FLAVIA.

5.2.2.5. Outras plataformas

Além das plataformas citadas acima, existem muitas outras plataformas de pesquisa ecomerciais de SDR. Uma lista mais completa pode ser encontrada na página Wikipe-dia de SDR4. Uma plataforma importante do ponto de vista da pesquisa é o WARP[Murphy et al. 2006][Amiri et al. 2007], pois é muito empregada nos EUA e em outrospaíses na pesquisa experimental em redes de computadores e telecomunicações. Entre-tanto, as placas são muito custosas, partindo de USD 5.000 a unidade. Outra plataformainteressante é o chip RTL2832U. Este chip é muito empregado por placas de TV digital,mas hobbistas descobriram que o mesmo pode ser utilizado como uma ótima plataformaSDR de baixo custo, custando apenas 40 dólares a unidade.

5.2.2.6. Comparativo e evolução das plataformas

Como vimos nas plataformas estudadas, existe uma gama muito grande de arquiteturase formas de programação. De um lado, possuímos plataformas em que todo o processa-mento é realizado em CPUs x86 ou ARM. Nestas, a curva de aprendizado é pequena, poisos programadores utilizam linguagens populares no mercado. Entretanto, a programaçãode protocolos com alta largura de banda requer diversos cuidados, como o uso de códigode montagem em partes críticas de código e otimizações para a arquitetura.

Uma forma de aliviar esta limitação é o uso de arquiteturas que empregam FPGAse DSPs para tarefas de baixa latência e alta vazão, e processadores genéricos para tarefasmais lentas, como protocolos MAC. Além disso, o uso de hardware para processamentoda banda base diminui a largura de banda necessária no barramento entre a CPU e asFPGAs/DSPs. Um exemplo é o USRP, onde o usuário pode executar parte ou todo o seucódigo em FPGAs.

Finalmente, da mesma forma que o mercado de PCs desenvolveu as GPUs parao processamento gráfico e mais recentemente estas foram adotadas para processamentocientífico, propostas como o SODA partiram para o uso de processadores de propósitoespecífico no SDR. O benefício de processadores de propósito específico é uma maiorvelocidade, menor área de chip e menor consumo de energia. Entretanto, a programaçãopara estas plataformas é mais complexa, pois pode requerer compiladores e linguagensapropriados.

A Figura 5.6 apresenta uma comparação entre as arquiteturas discutidas. Os valo-res do eixo das ordenadas não são mostrados pois não foi feita uma comparação quantita-tiva, mas qualitativa, baseada na vivência dos autores com algumas das arquiteturas e nasua descrição técnica.

4http://en.wikipedia.org/wiki/List_of_software-defined_radios



Aceleração*de*HW*

Facilidade* ISA*específico* Baixo*consumo* Expressividade*

GNU*Radio/USRP* FLAVIA* SORA* SODA*

Figura 5.6. Comparação entre as arquiteturas discutidas.

5.3. Fundamentos de transmissão digitalNesta seção será apresentada uma visão geral de vários conceitos-chave de transmissãodigital de dados, iniciando com uma compreensão de como os dados binários podemser usados para manipular as características físicas de uma onda eletromagnética, e emseguida discutimos as principais técnicas de modulação para rádios móveis.

5.3.1. Elementos fundamentais

Chama-se de transmissão de dados digitais a transferência física de dados (uma sequên-cia de bits ou um sinal analógico digitalizado) ao longo de um canal de comunicaçãoponto-a-ponto ou ponto-a-multiponto. Exemplos desses canais são os fios de cobre, fi-bras ópticas, canais de comunicação sem fios, meios de armazenamento e barramentos decomputadores [Clark 1983].

As transmissões modernas envolvem basicamente dois tipos básicos de comuni-cação, que podem ser sumarizados da seguinte forma: broadcasting, ou radiodifusão, queenvolve o uso de um único transmissor e diversos receptores; e comunicações ponto-a-ponto, nos quais as comunicações são realizadas por meio de enlaces diretos entre umtransmissor e um único receptor [Haykin and Moher 2006].

Enquanto a transmissão analógica é a transferência de um sinal analógico quevaria continuamente ao longo de um canal analógico, comunicações digitais são a trans-ferência de mensagens discretas ao longo de um canal digital ou analógico. As mensa-gens são representadas tanto por uma sequência de impulsos por meio de códigos de linha(transmissão de banda base), como por um conjunto limitado de diferentes formas de ondacontínua (banda passante de transmissão). Este processo é conhecido como modulaçãodigital. A modulação e a demodulação da banda passante correspondente é realizada porequipamento denominado modem (MOdulador-DEModulador). De acordo com a defini-ção mais comum de sinal digital, os dois sinais de banda base e de banda passante repre-sentando fluxos de bit são considerados como transmissão digital, enquanto uma definiçãoalternativa apenas considera como o sinal de banda base digital, e transmissão de bandapassante dos dados digitais como uma forma de conversão digital-analógica [Sklar 2001].

Um transceptor digital é essencialmente responsável pela tradução entre uma sequên-



cia de dados digitais, representados por bits, em ondas eletromagnéticas com caracterís-ticas físicas que representam unicamente esses bits. Algumas características físicas dasondas utilizadas para representar dados digitais incluem a amplitude, fase e frequênciada onda, de forma que diferentes combinações de bits representam diferentes níveis deamplitude ou valores de fase ou de frequência, ou ainda por um alterações simultâneas deduas ou mais destas características da onda [Wyglinski and Pu 2013].

Contudo, em uma transmissão digital há muito mais a ser feito do que apenasrealizar um mapeamento entre bits e formas de ondas, conforme ilustrado na Figura 5.7.Essa ilustração mostra uma representação genérica de um transceptor digital, visualizandoos vários blocos funcionais que constituem um sistema de comunicação digital, como porexemplo, os blocos de modulação e demodulação, que representam o mapeamento entrebits e características das ondas eletromagnéticas. Adicionalmente, observa-se os blocosde codificação de fonte e decodificação de fonte que lidam com a remoção de informaçõesredundantes dos dados binários; os blocos codificação do canal e decodificação do canal,que introduzem uma quantidade controlada de informação redundante para proteger atransmissão de erros potenciais; e os blocos RF Front-end, que trabalham na conversãodas ondas bases para as frequências da portadora.

Fonte digitalCodificação

de fonteCodificação

de canalModulação

digitalDigital-

analógicoRF Front-

End

Saída digitalDecodificação

de fonteDecodificação

de canalDemodulação

digitalAnalógico-

digitalRF Front-

End

Can

al

Transmissor

Receptor

Domínio digital Domínio analógico

Figura 5.7. Representação genérica de um transceptor de comunicação digital.

Uma das principais razões para que um sistema de comunicação digital precisede todos esse blocos é devido ao canal. Se este fosse um meio ideal onde as ondaseletromagnéticas do transmissor fossem claramente enviadas e recebidas pelo receptorsem qualquer tipo de distorção, interferência ou ruídos, então o projeto de um sistemade comunicação digital poderia ser trivial. O que acontece na realidade é que o sinalao chegar nos transmissores se encontra alterado, devido às distorções do meio e outrasfontes de interferência e ruído. Isto pode potencialmente afetar a correta recepção daonda interceptada pelo receptor. Para evitar tais problemas é que utilizamos sistemas decorreção e detecção de erros em diversos níveis da transmissão digital.



5.3.1.1. Codificação de fonte

Um dos principais objetivos de qualquer sistema de comunicação é realizar uma comuni-cação eficiente e confiável entre um transmissor e um receptor através de um meio. Dessaforma, o ideal seria remover toda a informação redundante de uma transmissão a fim deminimizar a quantidade de informação que necessita ser enviada através do canal, o quepode resultar em menor tempo para transmissão, menor uso de recursos computacionaisou de microprocessadores, e economia de energia elétrica. Em suma, diz-se que a codifi-cação de fonte é um mecanismo projetado para remover as informações redundantes parafacilitar comunicações mais eficientes [Wyglinski and Pu 2013].

O modo como esse mecanismo opera é tomando uma sequência de símbolos deorigem u e mapeando-os para uma sequência correspondente de símbolos codificados v,sendo vi ∈ v de forma mais aleatória possível, e os componentes de v não são correlacio-nados [Wyglinski and Pu 2013]. Estas duas regras de seleção de símbolo são empregadasdevido ao ruído e interferência: quanto mais diferentes forem os símbolos codificados,mais fácil é distingui-los um do outro, e assim mais fácil fica identificar um símbolomesmo na presença de ruído.

5.3.1.2. Codificação de canal

Para proteger uma transmissão digital da possibilidade de uma informação ser corrom-pida, é necessário introduzir alguns níveis de redundância controlada para reverter osefeitos dos dados corrompidos. Consequentemente, a codificação de canal é projetadapara corrigir os erros de transmissão em um canal introduzindo redundância controladanos dados de transmissão. Vale salientar que essa redundância é especificamente pro-jetada para combater os efeitos de erros de bit na transmissão (i.e., a redundância pos-sui uma estrutura específica que é conhecida tanto pelo emissor como pelo receptor)[Wyglinski and Pu 2013].

De modo geral, a codificação de canal opera da seguinte forma: cada vetor dasaída da codificação de fonte de tamanho K, chamado vl , onde l = 1,2, ...,2k, é associadoa uma única palavra-chave tal que o vetor vl = (101010...) esteja associado a uma únicapalavra-chave cl ∈ C de tamanho N, onde C é um livro-chave (i.e., a taxa de código éigual a k/N). O mapeamento do vetor para uma entrada no livro chave segue uma funçãobijetora, ou seja, existe um mapeamento um para um e reversível entre a entrada e a saídada codificação. Além disso, a quantidade de bits da palavra-chave em relação ao tamanhodo vetor, a razão k/N, indica a taxa de redundância da codificação de canal: quanto maispróxima de 1, menor será a quantidade de bits redundantes. Ou seja, para canais ondehaja pouca interferência e ruído, podemos empregar menos redundância.

5.3.2. Técnicas de modulação

Chama-se de modulação o processo de codificação das informações a partir de uma fontede mensagem de uma forma adequada para transmissão. O sinal da banda de passagemé chamado sinal modulado, e o sinal da mensagem na banda base é chamado sinal mo-dulante [Rappaport 2001]. Podemos ter modulação variando-se a amplitude, a fase e a



frequência de uma portadora de alta frequência. Além disso, podemos combinar duas oumais das características acima para modular a portadora, de forma a carregar ainda maisinformação. Ao processo de extrair a mensagem de banda base da portadora de modo queela possa ser processada e interpretada pelo receptor (também chamado de sink), dá-se onome de demodulação.

Nesta subseção serão discutidas brevemente algumas técnicas de modulação comoFM (Frequência modulada), AM (Amplitude modulada), PAM (Pulse-amplitude mo-dulation), QAM (Quadrature amplitude modulation) e OFDM (Orthogonal Frequency-Division Multiplexing), utilizadas em diversos sistemas de comunicação móvel. Aindaque os sistemas digitais ofereçam amplos benefícios e já estejam sendo utilizados parasubstituir os sistemas analógicos convencionais, os sistemas análogicos serão brevementediscutidos pois ainda estão em utilização e por terem sidos empregados nos principaissistemas de comunicação de primeira geração.

5.3.2.1. Amplitude modulada - AM

Na modulação por amplitude, a amplitude de um sinal de portadora de alta frequência évariada em conformidade com a amplitude instantânea do sinal da mensagem modulante.A frequência e a fase da portadora são mantidas constantes. Matematicamente, é umaaplicação direta da propriedade de deslocamentos em frequências da transformada deFourier, assim como da propriedade da convolução. Se c(t) = Ac cos(2π fct) é o sinal daportadora e m(t) é o sinal da mensagem modulante, o sinal de AM pode ser representadocomo

sAM(t) = Ac[1+m(t)]cos(2π fct) (1)

AM é formalmente definida como um processo no qual a amplitude da onda por-tadora c(t) é variada sobre um valor médio, de forma linear com o sinal de mensagemm(t) [Haykin and Moher 2006].

O índice de modulação k de um sinal AM é definido como a razão entre a ampli-tude de pico do sinal da mensagem e a amplitude de pico do sinal da portadora. Para umsinal modulante senoidal m(t) = (Am

Ac)cos(2π fmt), o índice de modulação é dado por

k =Am

Ac(2)

Este índice normalmente é expresso como uma porcentagem e é chamado de mo-dulação percentual.

5.3.2.2. Frequência modulada - FM

A técnica de modulação analógica mais popular utilizada nos sistemas de rádio móvel éa frequência modulada (FM) [Rappaport 2001]. A modulação FM transmite informaçõesatravés de uma portadora variando a sua frequência instantânea, de acordo com o sinal



modulante da mensagem. Salienta-se que a amplitude é mantida constante nesta técnica.Dessa forma, os sinais de FM tem toda a informação na fase ou na frequência da por-tadora, o que oferece uma melhoria não-linear e muito rápida na qualidade da recepçãoquando um certo nível mínimo do sinal recebido, chamado patamar FM, é alcançado.

FM oferece diversas vantagens em relação à amplitude modulada (AM), tornando-a uma melhor opção para muitas aplicações de rádio móvel, como uma melhor imunidadeao ruído em comparação com a amplitude modulada. Essa menor suscetibilidade ao ruídoatmosférico e de impulso se deve ao fato desses ruídos afetarem a amplitude, causando rá-pidas flutuações nestes níveis do sinal recebido, contudo, como as variações de amplitudenão transportam informações no sinal FM, o ruído intermitente não afeta o desempenhodo sistema FM (desde que o sinal recebido esteja acima do patamar de FM). Além disso,os receptores FM apresentam uma característica conhecida como efeito de captura, resul-tado direto da melhoria rápida e não-linear na qualidade da recepção para um aumentona potência recebida. Esse efeito ocorre da seguinte maneira: se existirem dois ou maissinais de FM emitidos na mesma frequência e ambos estiverem disponíveis ao receptorFM, este irá responder (demodular) ao sinal de maior potência e ignorar os menores (osrestantes).

Algumas desvantagens dos sistemas FM são que eles exigem uma ampla faixa defrequência no meio de transmissão (geralmente, várias vezes a necessária para AM); e osequipamentos transmissor e receptor são mais complexos do que aqueles utilizados porAM.

5.3.2.3. Pulse-amplitude modulation - PAM

Nas modulações de ondas contínuas estudadas anteriormente, um parâmetro de uma ondaportadora senoidal é variado continuamente de acordo com o sinal de mensagem. Issoestá em contraste direto com modulação por pulso. Neste esquema de modulação, algunsparâmetros de um trem de pulso são variados de acordo com o sinal de mensagem. Nestecontexto, pode-se distinguir duas famílias de modulação por pulso: modulação por pulsoanalógica e modulação por pulso digital, dependendo de como a modulação é realizada.Na modulação por pulso analógica, um trem de pulsos periódicos é usado como a ondaportadora, e uma característica de cada pulso (por exemplo, amplitude, duração ou posi-ção) é variada de maneira contínua, em conformidade com a amostragem correspondentedo sinal de mensagem [Haykin and Moher 2006].

Dessa forma, na modulação por pulso analógica, a informação é transmitida ba-sicamente em forma analógica, mas a transmissão é carregada em intervalos de tempodiscretos. Na modulação por pulsos digitais, por outro lado, o sinal de mensagem é re-presentado por uma forma de onda que é discreta tanto em tempo como em amplitude,permitindo assim a sua transmissão na forma digital como uma sequência de pulsos co-dificados. A utilização de pulsos codificados para a transmissão de sinais portadores deinformação para analógicos representa um ingrediente básico na aplicação das comuni-cações digitais. Esta seção pode ser vista, portanto, como a transição das comunica-ções analógicas para as digitais no nosso estudo dos fundamentos da transmissão digital[Wyglinski and Pu 2013].



5.3.2.4. Quadrature amplitude modulation - QAM

Visando aumentar a transmissão de bits por segundo, foi criada a técnica QAM, métodopara codificar dados digitais em um sinal analógico através de modulação em que duascomponentes diferentes são combinadas em um único sinal através de modulação orto-gonal destas duas componentes, evitando assim a interferência; daí o termo quadratura.A técnica empregada consiste na combinação da modulação por amplitude (AM) commodulação por fase (PSK, do inglês Phase-shift keying) para criar uma constelação depontos de sinal, cada qual representando uma combinação exclusiva de bits. É bastanteutilizada em TV digital e outros sistemas que necessitam de alta taxa de transferência deinformação.

A Figura 5.8 mostra o diagrama de constelação da QAM 16-ária, sendo Q e Irepresentações dos sinais modulantes (fase e amplitude). A constelação consiste em umatrama quadrada de pontos de sinal.

Q

I

Figura 5.8. Diagrama de constelação de um conjunto de sinais QAM M-ário (M=16)

A forma geral de um sinal QAM-M-ário pode ser definida como

Si(t) =

√2Emin

Tsaicos(2π fct)+

√2Emin

Tsbisen(2π fct) (3)

0≤ t ≤ T ; i = 1,2, ...,M

onde Emin é a energia do sinal com a amplitude mais baixa, e ai e bi são um parde inteiros independentes escolhidos de acordo com o local do ponto de sinal. Observa-seque a QAM M-ária não possui energia constante por símbolo nem a distância constanteentre os estados de símbolos possíveis.



5.3.2.5. Orthogonal Frequency-Division Multiplexing - OFDM

Proposto em 1968, a primeira aplicação da técnica OFDM foi apenas em 1985 [Cimini 1985]e surgiu como uma evolução da técnica convencional de Multiplexação por Divisão deFrequência - FDM (Frequency Division Multiplexing) onde, ao invés de utilizar-se bandasde guarda para a separação das subportadoras na recepção do sinal, trabalha-se com umaparticular sobreposição espectral de subportadoras [Pinto and de Albuquerque 2002].

A técnica OFDM consiste na transmissão paralela de dados em diversas sub-portadoras com modulação QAM ou PSK e taxas de transmissão por subportadora tãobaixas quanto maior o número destas empregadas. A redução na taxa de transmissãoaumenta tanto a duração dos símbolos presentes em cada subportadora, como a dimi-nuição na sensibilidade à seletividade em frequência. A geração direta e a demodula-ção do sinal OFDM, em princípio, requerem conjuntos de osciladores coerentes, resul-tando em uma implementação complexa e cara; entretanto, esses processos de modulaçãoe demodulação podem ser executados de forma mais simples utilizando-se, respectiva-mente, algoritmos IFFT (Inverse Fast Fourier Transform) e FFT (Fast Fourier Transform)[Pinto and de Albuquerque 2002].

Como principais vantagens do uso do OFDM tem-se a elevada eficiência espectral,imunidade contra multi-percursos e filtragem de ruído simples, resultando, por exemplo,em alta velocidade de transmissão de dados [Haykin and Moher 2006].

5.4. Introdução ao GNU RadioNesta seção serão apresentados exemplos práticos com o GNU Radio a fim de permitirque o participante desenvolva sua própria pesquisa. As principais aplicações demonstrati-vas, como demodulação de sinais FM, comunicação entre nós sensores e desenvolvimentode um novo módulo, serão descritas passo a passo, e possuem nível de complexidade in-cremental. Apresentamos um passo a passo para suas corretas execuções. O objetivodeste mini-curso é mostrar rapidamente as funcionalidades e capacidades do GNU Radio,assim leitores que tenham interesse de compreender a fundo as interfaces gráficas e a cri-ação de modificação de blocos devem procurar tutoriais na Internet. Existe uma grandecomunidade de tutoriais e guias na Web e no Youtube [Radio 2015a], [Radio 2015c][Balint 2015] .

Em todas as aplicações apresentadas a seguir são utilizados rádios USRP da Ettus,modelos B100 e B210, associados com o aplicativo GNU Radio. Finalmente, no términoda seção iremos apresentar dicas práticas no uso do GNU Radio e USRP, e discutir outrasplataformas de software compatíveis com o hardware USRP que tem sido empregadas napesquisa em redes de computadores.

5.4.1. GNU Radio

O GNU Radio é um conjunto de ferramentas de código aberto que fornece um ambientede desenvolvimento e blocos de processamento para implementar rádios definidos porsoftware. Ele se integra com placas USRP através de drivers [GNU Radio 2013]. Asaplicações GNU Radio são desenvolvidas utilizando Python, que é usado para conectaros blocos básicos de processamento. Esses blocos são desenvolvidos em C++ por mo-



tivos de desempenho. Há também Ambientes de Desenvolvimento Integrado, tais comoo GNU Radio Companion (GRC), que permite o desenvolvimento de aplicações usandouma interface gráfica de usuário.

Cada bloco no GNU Radio tem associadas entradas e saídas que podem ser liga-das a vários tipos de fluxos de dados. A ligação de diferentes blocos cria um fluxo queimplementa os passos de processamento de um dado sistema de comunicações. Além dasentradas e saídas, cada bloco tem um conjunto específico de parâmetros que definem oseu comportamento. O GNU Radio fornece centenas de blocos para os usos mais comuns,tais como operações matemáticas, conversão de tipo de dados, modulação e demodula-ção, entre outros. Além disso, novos blocos podem ser criados com base nas necessidadesdo usuário. Um ponto que deve ser destacado é o fato de que o GNU Radio é um pro-jeto open source, permitindo a alteração do código de blocos existentes se necessário.O GNU Radio tem uma comunidade de apoio muito ativa, tornando ainda mais fácil deaprender e desenvolver usando a plataforma. No entanto, o suporte para alguns proto-colos e técnicas mais avanças de modulação é ainda muito limitado, como é o caso deWiFi [Bloessl et al. 2013b], Bluetooth, e ZigBee, como veremos rapidamente nos estu-dos de caso apresentados a seguir.

O software de GNU Radio pode ser utilizado sem placas SDR, por exemplo paraprocessar sinais de um arquivo no computador, ou empregando uma plataforma SDRcompatível. Para tanto, a plataforma SDR deve fornecer um componente GNU Radiochamado UHD (USRP Hardware Driver), que é um driver para o hardware. Por exemplo,as placas USRP da Ettus, mencionadas anteriormente, possuem drivers UHD para todasas suas versões.

A instalação do GNU Radio pode ocorrer por pelo menos três formas. Descreve-mos brevemente cada uma delas:

• Script build-gnuradio. Caso haja interesse por uma instalação que utilize o código-fonte sempre atualizado e que solucione dependências automaticamente, é preferí-vel instalar o GNU Radio a partir dos arquivos fonte. Para isso, usuários do Fedorae Ubuntu contam com um script que realiza a instalação completamente, sendorecomendado para a maioria dos usuários. Trata-se de um script fornecido porMarcus Leech [Leech 2015] para sistemas Fedora e Ubuntu recentes. Com umajanela de terminal aberta, siga ao diretório que você deseja que os arquivos fontesejam armazenados e execute o comando:

$wget http://www.sbrac.org/files/build-gnuradiochmod a+x./build-gnuradio.

Esse procedimento baixa o instalador (build-gnuradio) e o torna executável, bai-xando e instalando também todas as dependências, o UHD e o sistema GNU Ra-dio via Git; assim, automaticamente será instalada a versão mais recente do masterbranch. O procedimento segue executando o make, e instalando o sistema. Salienta-se que muito disso é realizado de forma transparente ao usuário, logo, é provável



que nenhuma novidade surja na tela por alguns minutos. Em muitos casos, simples-mente executando o script, ele fará tudo o que for necessário para obter e deixar oGNU Radio executando a partir dos arquivos fonte, mantendo-os no seu disco dis-poníveis para futuras modificações. Dessa forma, ele combina a flexibilidade deinstalar a partir dos arquivos fonte com a facilidade de usar binários.

• Binários pré-compilados. Dessa forma a instalação é prática, mas nem sempre éinstalada a versão mais recente. Também é comum usuários terem problemas comdependências não resolvidas corretamente. O processo de instalação no Ubuntué simples, basta executar no terminal $ apt-get install gnuradio. Nadistribuição Fedora, execute $ yum install gnuradio.

• PyBOMBS (Python Build Overlay Managed Bundle System). Trata-se de umanova forma de instalar o sistema GNU Radio e outros módulos, inclusive aque-les out-of-tree, ou seja, aqueles que não fazem parte dos projetos nativos do GNURadio. No terminal basta executar:

git clone https://github.com/pybombs/pybombs.gitcd pybombs./app_store.py

Dessa forma, após a conclusão da instalação, será aberta uma interface gráfica ondeé possível escolher o que se deseja instalar. Com o PyBOMBS instalado na suamáquina, sua execução é possível a partir do comando ./app_store.py digitando apartir do diretório onde o mesmo está instalado.

Mais informações sobre esses processos de instalação, bem como outros modos,podem ser consultadas em [Radio 2015b].

5.4.2. GNU Radio Companion

GNU Radio Companion (GRC) é uma ferramenta gráfica livre para criar protótipos desistemas de comunicação rápidos e funcionais a partir de diagramas de fluxos de sinaiselétricos, permitindo gerar o respectivo código fonte desses fluxos. Programas no GNURadio não precisam necessariamente serem feitos no GRC, entretanto ele permite umaprototipagem rápida e facilita o entendimento dos programas sendo desenvolvidos. Elepossui facilidades como sistemas para o desenvolvimento rápido de interfaces gráficas eanálise estática do diagrama de módulos para encontrar erros simples de configuração.Nesta subseção vamos começar a explorar o GRC.

Para executar o ambiente GRC, após instalado o GNU Radio, abra um terminale execute o comando $ gnuradio-companion. Inicialmente, temos que entender aposição dos elementos na interface. Há quatro partes: biblioteca (library), barra de ta-refas (toolbar), terminal, e área de trabalho (workspace). Essas partes estão sinalizadasna Figura 5.9, respectivamente, com os números 1, 2, 3 e 4. A Biblioteca contém osdiferentes blocos instalados no GRC. Nela encontramos blocos que estão pré-instaladosno GNU Radio e blocos que estão instalados no sistema. No começo pode parecer difí-cil encontrar os blocos, mas há algumas praticidades: por exemplo, se quisermos gerar



uma forma de onda, em qual categoria devemos procurar? Vemos que há uma categoriaWaveform Generators. E se quisermos exibir os nossos dados? Devemos inserir um sink,no entanto, procurando através da lista não encontramos uma categoria sink. A soluçãoé usar o recurso de pesquisa clicando no ícone da lupa ou através do atalho Ctrl + F e,em seguida, começar a digitar uma palavra-chave para identificar o bloco. Vemos umacaixa branca aparecer no topo da Biblioteca com um cursor. Se digitamos sink, podemosencontrar todos os blocos que contêm as palavras sink e as categorias que vai encontrarem cada bloco.

O terminal é útil na compilação dos programas, pois apresenta os erros gerados.Além disso, podemos acompanhar a carga do programa na USRP e durante a execuçãopodemos ver as saídas textuais do mesmo.

Figura 5.9. Interface do ambiente GNU Radio Companion

Uma aplicação é feita no GRC arrastando blocos da biblioteca para a área detrabalho, e realizando as conexões e configurações necessárias. Podemos modificar aspropriedades de um bloco através de um duplo clique sobre o mesmo. As conexões en-tre blocos que permitem enlaces, como por exemplo os blocos A e B, são realizadas daseguinte forma: clicamos com o mouse na porta out do bloco A e em seguida na porta indo bloco B. Para remover uma conexão entre dois blocos, basta selecioná-lo e pressionarDelete.

Novos blocos podem ser adicionados por meio de importações de módulos, con-forme faremos nas aplicações adiante, ou podem ser criados. Na subseção 5.4.6 apresen-tamos detalhadamente como criar um novo bloco.

Os tipos de dados no GRC podem ser visualizados no menu Help > Types. Reali-zando essa sequência, serão exibidos os tipos de dados possíveis com as respectivas coresassociadas. Estas mesmas cores serão utilizadas nos fluxogramas e blocos à medida quese definem os tipos de dados. Para alterarmos o tipo de dados em um determinado bloco,



devemos ir nas propriedades do mesmo, normalmente em um campo identificado comType ou Output Type, e selecionar o tipo de dado. Devemos ficar atento, contudo, com ascompatibilidades de dados entre os blocos conectados, ou seja, o tipo de dados de saídade um bloco A deve ser do mesmo tipo de dados da entrada do bloco B, ao qual A se co-necta. Caso haja incompatibilidade de tipo entre blocos, a conexão entre os mesmos seráautomaticamente sinalizada com uma seta vermelha, facilitando ao usuário perceber quenaquela conexão está ocorrendo algum conflito entre os tipos de dados envolvidos. Pararesolver, deve-se alterar o tipo em um dos blocos adequadamente. As posições dos blo-cos, informações de parâmetros e variáveis são salvas em um arquivo XML (eXtensibleMarkup Language) com extensão .grc, contendo basicamente o nome do bloco, a funçãoa ser chamada para instanciar o bloco, parâmetros do bloco e seus tipos, e quantidade etipos das portas de entrada e de saída.

O GNU Radio possui diversos tipos de blocos, por exemplo operações lógicas ematemáticas, filtros, moderadores e demoduladores, blocos de entrada e saída (chamadosde sources e sinks), dentre outros. Entre eles, os blocos de sink e source são importan-tes. Todas as aplicações terão entradas e saídas, que são definidas pelos sinks e sources,respectivamente. Alguns exemplos de sinks e sources são arquivos binários, arquivos desom (por exemplo, WAV), ou placas USRP. Por exemplo, se queremos criar um receptorFM que grava a onda em um arquivo WAV, precisamos de um source que é uma placaUSRP, e um sink que é um bloco que grava um arquivo WAV no disco, tal como o WavFile sink. Outros exemplos são arquivos de captura do Wireshark, fontes de seniores comfrequência constante, ou Null Sinks e Null sources. Estes são interessantes em aplicaçõesem que não queremos salvar dados mas somente transmitir, por exemplo.

Podemos ter mais de um sink, como iremos mostrar no exemplo de demodulaçãode sinais FM. Além disso, podemos ter uma aplicação com dois fluxos separados de blo-cos, um para a transmissão e outro para a recepção. Um exemplo simples está apresentadona aplicação de walkie talkie representada na Figura 5.10:

USRP Source

NBFM Demodulator

Squelch Audio Sink

Audio Source

NBFM Modulator

USRP Sink

Figura 5.10. Exemplo de dois fluxos separados de blocos

Esta figura consiste de dois gráficos de fluxo separados, ambos rodando em pa-ralelo. Um deles está relacionado com o caminho de Tx, e o outro com o caminho deRx. Salienta-se que neste tipo de aplicação, é necessário um código extra (além dosgráficos de fluxo exibidos) para silenciar um caminho, enquanto o outro está ativo. Am-bos os gráficos de fluxo exigem ainda, pelo menos, um source e um sink, cada. Umaaplicação nativa ao GNU Radio que realiza algo semelhante pode ser encontrada no ca-



minho gr-uhd/examples/python/usrp_nbfm_ptt.py. É importante frisar que fluxogramasque são completamente simulação (i.e., sem blocos de áudio ou USRP) vão consumir100% da CPU quando executados, e os elementos da GUI ficarão sem resposta. Estesgráficos de fluxos devem incluir um bloco Misc > Throttle para aumentar a taxa de da-dos de streaming. Somente precisamos de um único bloco acelerador (Throttle) em todoo fluxograma, mesmo se tivermos múltiplas fontes e sorvedouros(sources/sinks). Pode-mos pensar o bloco Throttle como um limite de velocidade; por outro lado, utilizando umhardware (USRP) há a imposição física de uma restrição à transferência, portanto, não énecessário nenhum bloco Throttle.

As variáveis no GRC mapeiam nomes simbólicos para valores, podendo definiruma constante global ou uma variável que pode ser utilizada em conjunto com a interfacegráfica para controlar um sistema em execução. O bloco Variable é a forma mais básicade usar uma variável no GRC. O parâmetro ID do bloco é o nome simbólico. Este deve seralfa-numérico (permitidos underscores) e começar com uma letra. Para usar a variável,basta digitar o nome simbólico de uma variável em um parâmetro de qualquer outro bloco.

Podemos ainda verificar se há erros em algum trecho de todo o fluxo no ambi-ente através do menu View > Flowgraph Errors, ou através do botão circular vermelho,localizado na barra de tarefas, que exibe o texto View flow graph errors ao se posicio-nar o ponteiro do mouse acima. Uma vez acionada essa funcionalidade será exibida umamensagem descrevendo brevemente a quantidade de erros e o tipo de erro.

Além de blocos relativos ao processamento de sinais, temos também blocos quepermitem a construção de gráficos e interfaces. Eles são úteis para construirmos umainterface gráfica, onde podemos modificar parâmetros dos blocos ou visualizar os sinaisrecebidos e transmitidos em tempo real. Temos objetos que representam os elementosmais comuns de interface gráficas, como rótulos de texto, botões, abas etc. O GNU Radiousa a biblioteca PyQt para a construção das interfaces gráficas.

O GRC manuseia arquivos em Python, assim, os fluxos gráficos serão compiladospara essa linguagem e depois, se necessário, será transmitida uma imagem ao USRP. Acompilação pode ser realizada através do menu Run > Generate, ou pressionando a teclaF5, ou ainda através do botão localizado na barra de tarefas, ao lado do botão View flowgraph errors, representado por um ícone de uma pequena pirâmide, uma seta e um cír-culo, exibindo o texto Generate the flow graph ao posicionar o ponteiro sobre o mesmo.Se o fluxograma não estiver salvo, ao tentar compilar será solicitado que salve o fluxo emum arquivo com extensão .grc. Em seguida, podemos executar esse arquivo Python recémcompilado acessando o menu Run > Execute, ou pressionando a tecla F6, ou ainda pormeio do botão Execute the flow graph, identificado por um ícone triangular localizado aolado do botão Generate the flow graph. Se o fluxo a ser executado envolver uso de hard-ware externo (e.g. USRP), uma imagem será transmitida ao equipamento; caso contrário,a saída dependerá do fluxo compilado, podendo ser apenas uma saída gráfica, áudio ououtras opções de saída.

O exemplo a seguir possibilitará uma melhor compreensão sobre o funciona-mento do GRC. Mais informações sobre o GRC também podem ser encontradas em[Radio 2015a]. Existem diversos vídeos no Youtube e tutoriais, tanto no site do GNU Ra-dio quanto em outros sites, que explicam em mais detalhes as funcionalidades do GRC.



Neste tutorial iremos discutir uma aplicação simples, que é um receptor FM, e depoisiremos focar em aplicações mais relevantes para a pesquisa em redes de computadores.

5.4.3. Demodulação de Sinais FM com GNU Radio

Neste exemplo usamos o equipamento USRP B210 para construir um receptor de FMsimples. O objetivo é ensinar alguns conceitos básicos de DSP e RF, incluindo: filtragem,demodulação e conversão da taxa de amostragem; mostrar como criar aplicações gráficascom GNU Radio Companion (GRC); e ilustrar a simplicidade das ferramentas de softwareque podem ser utilizadas com a família de produtos USRP.

O primeiro passo para a construção de uma aplicação do GNU Radio é identificarse o hardware possui o suporte adequado, ou seja, se temos uma placa filha com suporteà largura de banda e frequência empregadas, e se temos antenas com tamanho e ganhoapropriados. Neste tutorial escolhemos a placa B210 porque ela suporta frequências de70MHz a 6GHz, bem como a largura de banda das rádios FM. Já a largura de bandapode ser crítica caso queiramos implementar padrões de alta taxa de transmissão. Porexemplo, não é possível implementar um receptor IEEE 802.11ac na B210, porque elasuporta canais de até 56MHz de largura, e o 802.11ac suporta canais com até 80MHz delargura.

Nesta aplicação FM, o fluxograma pode ser melhor compreendido através da Fi-gura esquemática 5.11.

USRP Source

Rational Resampler

WBFM Receiver

Audio Sink

Figura 5.11. Esquema do fluxograma de demodulação FM

Precisaremos dos seguintes blocos, todos acessíveis pela biblioteca do GRC:

• USRP Source

• Low Pass Filter

• WBFM Receive

• Multiply Constant

• Rational Resampler

• Audio Sink

E dos seguintes blocos auxiliares:

• WX GUI Slider



• WX GUI Text Box

• WX GUI FFT Sink

No ambiente do GRC, inserimos o bloco UHD:USRP Source e alteramos o seu pa-râmetro Samp Rate para o valor samp_rate, assim ele ficará associado à variável samp_ratejá definida em outro bloco de variável (criado por padrão no GRC). O bloco UHD:USRPSource permite o acesso às amostras do USRP. Em seguida associamos o parâmetro Ch0:Center Freq à variável freq para podermos controlar a frequência através da interface grá-fica. Por último, definimos o ganho com o valor 15 alterando o parâmetro Ch0: Gain. Oparâmetro Antenna vai depender do hardware que está sendo utilizado, neste caso utiliza-mos TX/RX.

No bloco da variável samp_rate (criado pelo GRC automaticamente) especifica-mos o valor de 5MHz (5e6). Em seguida, adicionamos um novo bloco WX GUI TextBox para especificarmos a variável da frequência. No parâmetro ID digitamos freq e nocampo Default value digitamos 105.7e6, representando a frequência da estação FM quequeremos sintonizar, neste caso, 105.7MHz. Incluimos o componente de interface gráficaWX GUI FFT Sink para visualizarmos o espectro da frequência, conectando-o à saída dobloco UHD: USRP Source. Mudamos o parâmetro Baseband Freq para receber o valorda variável freq. Por fim definimos o parâmetro Notebook para notebook_0,0. Dessaforma, especificamos em qual aba da interface gráfica, que será definida mais adiante,será exibido o espectro.

Certamente há muitos ruídos no sinal que será recebido, logo devemos inserirum filtro para eliminar as freqüências além dos limites do intervalo especificado. Vocêpode tentar ajustar os parâmetros nesse ponto para tentar melhorar a qualidade do áudioe eliminar outras interferências. Assim, adicionamos um filtro “passa-baixa” (bloco LowPass Filter). Definimos o parâmetro Cutoff Freq para e 100e3, o Transition Width para10e3 e o parâmetro Decimation para 20. Conectamos a saída do bloco UHD: USRPSource na entrada do filtro Low Pass.

Neste ponto, a configuração de nosso penúltimo bloco principal é bastante sim-ples. Precisamos adicionar o componente que decodifica o fluxo de entrada para o áudioreal que foi codificado na corrente e os bits adequados para o envio à sua placa de som.Dessa forma, adicionamos o componente WBFM Receive e definimos o parâmetro Qua-drature Rate para 250e3 e Audio Decimation para 1. Conectamos a saída do filtro LowPass à entrada do WBFM Receive. Como estamos recebendo, a partir do bloco WBFMReceive, a uma frequência de 250KHz, precisamos convertê-la para a nossa taxa de amos-tragem de áudio de saída. Para isso, inserimos o componente Rational Resampler e es-pecificamos ao parâmetro Interpolation o valor 250 e Decimation para 96. Conectamos asaída do WBFM Receive à entrada do Rational Resampler. Em seguida, inserimos o com-ponente Audio Sink que permite a escuta das amostras. Conectamos a saída do RationalResampler à entrada do Audio Sink. Mudamos o parâmetro Sample Rate para 96000.

Em seguida adicionamos o componente Wav File Sink para gravarmos as amostrasem um arquivo de áudio. Definimos o parâmetro File para fm_record e Sample ratepara 96000. Conectamos a saída do Rational Resampler à entrada do Wav File Sink.Inserimos mais um componente WX GUI FFT Sink para visualizarmos o espectro do



áudio demodulado. Definimos o parâmetro Sample Rate para 250e3 e Notebook paranotebook_0,1. Conectamos o WBFM Receive na entrada do WX GUI FFT Sink.

Por fim, adicionamos o componente WX Gui Notebook para criarmos uma in-terface gráfica com abas e definimos o parâmetro labels para [’RF Spectrum’, ’DemodSpectrum’].

Essas etapas devem acarretar em um fluxograma semelhante ao exibido na Figura5.12. Após a compilação e execução desse fluxograma em um USRP, será possível sin-tonizar a frequência especificada com saída de áudio em tempo real e o mesmo salvo emarquivo na pasta de execução. A qualidade sonora dependerá de condições diversas, comodo tipo da antena e da potência do sinal FM no ambiente.

Figura 5.12. Fluxograma de Demodulação FM.

5.4.4. Modulação QPSK

PSK (Phase shift keying) é uma forma de modulação em que o sinal é codificado utili-zando a fase da onda portadora. Uma das formas de fazer isso é deslocando a fase em180o quando houver uma transição de bit 1 para 0 ou de bit 0 para 1, esta forma é chamadaBPSK (Binary Phase shift keying), nesse sistema, quando não há transição, a portadoracontinua a transmitir com a mesma fase.

QPSK (Quadrature phase shift keying) é uma forma de PSK onde é utilizadauma quantidade maior de deslocamentos da fase da onda portadora para codificaçãodo sinal. Neste caso, são utilizados 4 deslocamentos, assim, é possível transmitir 2bits por símbolo. A fase da onda portadora terá 4 valores distintos e cada valor re-presentará um dibit, por exemplo, (45o = 00), (135o = 01), (225o = 11) e (315o = 10)[Tenenbaum and Wetherall 2011].

No GNU Radio, para apresentar o exemplo de modulação QPSK, utilizamos osseguintes blocos:

• Options



• Random Source

• PSK Mod

• Noise Source

• Add

• Multiply Const

• Add

• UHD: USRP sink

• QT GUI Constellation sink

Inicialmente configuramos o bloco Options. Colocamos o valor do parâmetro Ge-nerate Options para QT GUI, em seguida precisaremos utilizar 3 blocos do tipo Variable,um para definir o valor do sample rate, outro para definir o valor da frequência e um outropara definir o valor do ganho. Assim, os parâmetros do primeiro bloco Variable terão osvalores ID: sample rate, value: 320e3; os parâmetros do primeiro bloco terão os valoresID:freq, value: 900e6; e para o último bloco, os valores serão ID:gain, value:30.

Feitas essas configurações iniciais, continuamos configurando o bloco RandomSource. No parâmetro Output Type escolhemos o valor byte, para os parâmetros Mini-mum e Maximum definimos os valores 0 e 255 respectivamente, no parâmetro Num Sam-ples escolhemos o valor 10e6 e para a opção Repeat setamos o valor yes. Este bloco seráresponsável por gerar o sinal que será modulado e transmitido. A fonte de sinal poderiaser outra, poderíamos escolher o bloco Signal Source e gerar sinais com com ondas espe-cíficas alterando o parâmetro waveform. Outra possibilidade seria a geração de sinais apartir de um arquivo utilizando os blocos File Source associado ao bloco Packet Encoder.

O dado de saída do bloco Random Source é do tipo Complex e deve ser ligada àentrada do bloco PSK Mod que é do mesmo tipo. O bloco PSK Mod é central neste exem-plo, pois é ele quem modula o sinal que será transmitido. Configuramos seus parâmetroscom os seguintes valores: Number of constellations: 4, Gray Code: yes, DifferencialEncoding: yes, Samples/Symbols: 2, Excess BW: 350e-3. O parâmetro Number of cons-tellations deve ser um valor que seja potência de 2.

O bloco Noise Source não é essencial neste exemplo, ele existe para que se possaperceber diferenças no sinal a fim de identificá-lo, já que nenhuma mensagem específicaserá transmitida. Neste bloco, setamos o valor do parâmetro Noise Type como Gaussian eAmplitude como 0.125.

Em seguida devemos adicionar este ruído ao sinal original, fazemos isso utili-zando o bloco Add. Neste bloco configuramos os parâmetros Num Inputs e Vec Lengthcomo 2 e 1 respectivamente. O parâmetro IO Type setamos como Complex. Após essasconfigurações, ligamos a saída do bloco PSK Mod a uma entrada do bloco Add e ligamosa saída do bloco Noise Source à outra entrada do bloco Add.



O bloco Multiply Const apenas multiplica o sinal por 0,5, isso é feito para evitarque o valor 1.0 chegue ao UHD Sink, o que saturaria o conversor analógico-digital. Qual-quer valor acima de 1.0 causaria clipping. Assim, configuramos os parâmetros do blococom só seguintes valores: IO Type: Complex, Constant: 0.5, Vec Length: 1. Em seguida,ligamos a saída do boclo Add à entrada do bloco Multiply Const.

O bloco seguinte a ser configurado é o UHD: Usrp Sink. Utilizamos as variáveisdefinidas com os blocos do tipo Variable para configurar este bloco. Os valores dosparâmetros devem ser: Samp Rate (Sps): samp rate, Ch0: Center Freq (Hz): freq, Ch0:Gain (dB): gain, Ch0: Antenna: TX/RX, Ch0: Bandwidth (Hz): samp rate. Ligamos entãoa saída do bloco Multiply Const na entrada do bloco UHD: Usrp Sink.

Por fim, ligamos também a saída do bloco Multiply Const na entrada do blocoQT GUI Constellation sink. Este bloco deve ter os parâmetros configurados da seguinteforma: Number of points: 1024, Y min e Xmin: -2, Y Max e X Max: 2, Update Period:0.10. Este bloco é responsável por exibir graficamente o sinal de saída do bloco MultiplyConst, já modulado e pronto para ser entregue ao UHD: Usrp Sink [GNU Radio 2015].

O gráfico final deve ter o aspecto mostrado na Figura 5.4.4. Quando conectado ao

Figura 5.13. Flowgraph do modulador e transmissor QPSK

Equipamento B100 e executado, o resultado gráfico é exibido nas Figuras 5.14 e 5.15:

5.4.5. Comunicação com o protocolo IEEE 802.15.4

O padrão IEEE 802.15.4 é mantido pelo Institute of Electrical and Electronics Engineers(IEEE) e ficou responsável pela especificação das duas camadas mais baixas da tecnologiaZigBee, enquanto que a ZigBee Alliance trabalhava nas camadas superiores. Dessa forma,o padrão é a base para as especificações ISA100.11a, WirelessHART, e MiWi, além daZigBee, cada uma das quais estende ainda mais o padrão através do desenvolvimento dascamadas de roteamento e transporte, que não são definidas no padrão IEEE 802.15.4.

O ZigBee é projetado para oferecer conectividade com baixo custo de energiaaos equipamentos que precisam extrair uma longa vida útil de uma bateria limitada, ge-ralmente por vários meses ou anos, mas sem necessitar de taxas de dados tão elevadasquanto as proporcionadas pelo Bluetooth. Além disso, ZigBee pode ser implementadaem redes de malha maiores do que é possível com a tecnologia Bluetooth [Ergen 2004].



Figura 5.14. Sinal com ruído Figura 5.15. Sinal sem ruído

A pilha do protocolo pode ser melhor compreendida visualizando a Tabela 5.1 aseguir:

Usuário AplicaçãoSuporte à aplicaçãoZigBee Alliance

Rede (NWK) / Segurança (SSP)MACIEEE 802.15.4PHY

Tabela 5.1. Representação esquemática da pilha de protocolo

A camada física (PHY) do ZigBee segue o protocolo 802.15.4 e é responsável porpermitir a transmissão das PDUs (Protocol Data Units), unidades de dados, através deondas de rádio. A PHY utiliza a modulação DSSS (Direct Sequence Spread Spectrum)que incorpora em cada bit de dado um padrão de redundância e os espalha pela largurade banda utilizada. Essa redundância permite não só que o dado seja identificado comopertencente a um determinado nó, como é claro, facilita a detecção de erros. Ao espalharos dados em todas as frequências da banda, o sinal resultante se assemelha cada vez maisa um ruído, tornando-se mais robusto a interferências. Após o processamento da DSSS, osinal é modulado em uma portadora para transmissão. As faixas de frequência utilizadassão as frequências livres de 2.4 GHz (global), 915 MHz (Américas) e 868 MHz (Europa).Cada uma das faixas implica em uma taxa de transmissão, número de canais e espectrosdiferentes. Outras funções da camada física são indicar qualidade de conexão, detectarpotência dos canais, e reportar canais livres. A Tabela 5.2 apresenta características comomodulação, taxa de bits e símbolos, de acordo com a banda de frequência em uso dopadrão IEEE 802.15.4.

A camada MAC do padrão 802.15.4 é responsável pelo processo de encapsula-mento dos dados oriundos das camadas superiores, preparando-os para serem transmiti-dos. O método de acesso ao meio caracteriza a rede em dois modos de operação: modoBeaconing e Non-Beaconing. No primeiro modo os roteadores transmitem periodica-



PHY(MHz)

Banda de frequência(MHz)

Parâmetros de espalhamento Parâmetros dos dadosTaxa de espalha-mento (kchip/s) Modulação Taxa de bit

(kb/s)Taxa desímbolo Símbolos

868/915868-868.6 300 BPSK 20 20 Binário902-928 600 BPSK 40 40 Binário

2450 2400-2483.5 2000 O-QPSK 250 62.5 16 símbolos

Tabela 5.2. Bandas de frequência e taxas de dados

mente sinalizadores (beacon frames) para confirmar sua presença na rede. Após o bea-con, há os tempos de acesso CAP (Contension Access Period), onde todos os dispositivoscompetem entre si utilizando CSMA-CA (Carrier Sense Multiple Access with CollisionAvoidance) e o CFP (Contension Free Period) que garante reservas de tempo para cadadispositivo. Utilizando-se de boa sincronia, os nós da rede (exceto o coordenador) podempermanecer inativos entre os beacon frames e economizar energia. Nesse modo é utilizadaa estrutura de superframe. O modo Non-Beaconing se caracteriza por manter a maioriados nós ativos constantemente, ocasionando um maior consumo energético [Ergen 2004].

A aplicação que será analisada a seguir é do tipo out-of-tree, ou seja, é umacomponente GNU Radio que não foi desenvolvida nem é mantida dentro dos arquivosfontes do GNU Radio. A aplicação é baseada nas implementações de [Schmid 2006] ede [Bloessl et al. 2013a], tendo como principais modificações a segmentação do arquivotransceiver.grc que possuia função tanto de recepção como de transmissão, em dois ar-quivos denominados transceiver_onlyRx.grc e transceiver_onlyTx.grc, cada um com re-arranjos de blocos a fim de possibilitar o isolamento das funcionalidades.

Nesta aplicação, mostramos um transceptor IEEE 802.15.4 para GNU Radio v3.7que apresenta como principais características:

• Camada física empregando O-QPSK e encapsulada em um bloco hierárquico;

• Bloco RIME Stack, que implementa a pilha de comunicação Rime (Rime é umapilha de comunicação projetada para redes de sensores sem fio e faz parte do sistemaoperacional Contiki) [Leitner 2013];

• Exemplo de aplicativo que transmite e recebe mensagens no padrão IEEE 802.15.4;

• Exemplo de aplicativo que visualiza valores do nós sensores.

Algumas propriedades interessantes da implementação são que os pacotes podemser canalizados para Wireshark, que é um software de captura de pacotes [Foundation 2015].A modulação física completa é feita com simples blocos do GRC, e a implementação éinteroperável com sensores TelosB motes e com Contiki; e utiliza um bloco para marcarrajadas de pacotes com Tx e Rx. Estas marcas são compreendidas pelos blocos UHD epermitem a comutação rápida entre transmissão e recepção, necessária quando Tx e Rxestão sendo executados em um único equipamento. A aplicação discutida está configuradapara ser executada com o mínimo de dois equipamentos, mas é possível fazer rearranjosnos blocos do fluxograma para que Tx eRx executem em apenas um USRP, conformeapresentado em [Bloessl et al. 2013a].



Uma visão geral sobre a arquitetura do transceptor pode ser vista na Figura 5.16.A estrutura do transceptor SDR é modular, em camadas, como exposto no GRC. A ca-mada física é encapsulada em um bloco hierárquico e os pacotes entre o MAC e a camadafísica são capturados pelo conector Wireshark. Devido à estrutura modular deste fluxo,a forma como a mensagem trafega a partir do aplicativo de envio à USRP podem ser fa-cilmente rastreados: o bloco Socket PDU transforma a mensagem enviada pela aplicação(neste caso, enviada pelo bloco Message Strobe) em um formato de PDU, em seguida,ela é encapsulada pelo bloco Rime Stack na camada de rede e pelo bloco IEEE802.15.4MAC na subcamada MAC. Depois disso, a mensagem é transformada em um sinal físico,modulado e enviado pelo bloco IEEE802.15.4 PHY.

Várias conexões podem ser abertas pelo bloco Rime Stack, fornecendo vários nú-meros identificadores de canais para cada tipo de conexão desejada na janela de opçõesdo bloco. O GRC cria automaticamente um par de portas entrada/saída para cada conexãoaberta. Há dois pares de conexões de broadcast (rotuladas como bcinX e bcoutX), de uni-cast (rotuladas como ucinX e ucoutX) e um par de conexões unicast confiáveis (marcadacom rucin e rucout). Além disso, pode-se configurar o endereço Rime do transceptor.Se o bloco Rime é conectado à camada MAC pelas suas portas to/fromMAC, as mensa-gens podem ser enviadas por ligação a um bloco de emissão de PDU [Leitner 2013]. NaFigura 5.16, o bloco Socket PDU gera mensagens de dados no formato PDU que serãoenviadas para o socket UDP na porta 52001, podendo este valor ser alterado pelo usuárionas propriedades do bloco.

O bloco MAC está atualmente limitado à funcionalidade mais básica que permitea conectividade: encapsula os pacotes das camadas mais altas com um cabeçalho IEEE802.15.4 válido e acrescenta a soma de verificação CRC. No processo de recepção, elefaz o inverso, removendo o cabeçalho MAC e verificando se o CRC está correto. Emparticular, a camada MAC ainda não realiza detecção de portadora, enviando uma mensa-gem imediatamente, nem implementa o sistema de back-off ou a separação entre períodosCAP e CFP.

O processo de instalação desse módulo de comunicação com o protocolo IEEE802-15-4 (gr-ieee802-15-4) se dá através da aplicação Git. Para que seja possível realizara instalação e execução correta desse módulo, é necessário instalar, inicialmente, um mó-dulo complementar chamado gr-foo, desenvolvido por [Bloessl et al. 2013a]. Para isso,devemos executar a seguinte sequência de comandos:

git clone https://github.com/bastibl/gr-foo.gitcd gr-foomkdir buildcd buildcmake ..makesudo make installsudo ldconfig

Por fim, para baixar e instalar o módulo gr-ieee802-15-4 devemos executar oscomandos listados a seguir:



Figura 5.16. Arquitetura do transceptor



git clone git://github.com/wendley/gr-ieee802-15-4.gitcd gr-ieee802-15-4mkdir buildcd buildcmake ..makesudo make installsudo ldconfig

Concluídas essas etapas, o GRC de sua máquina já deve exibir o módulo gr-ieee802-15-4 na sua biblioteca. Precisamos instalar o bloco hierárquico; para isso, abri-mos o arquivo examples/ieee802_15_4_PHY.grc no GRC e o compilamos (tecla F5). Issoinstala o bloco hierárquico no diretório onde o GRC possa encontrá-lo, normalmente em/.grc_gnuradio. Pode ser necessário reiniciar o GRC ou todo o sistema do GNU Radiopara que o bloco seja corretamente detectado. Podemos conferir se a instalação foi cor-retamente concluída procurando pelo arquivo examples/transceiver.grc e verificando noGRC se todos os blocos estão conectados com sucesso.

Em seguida, podemos iniciar as comunicações entre os USRPs através da execu-ção dos arquivos transceiver_onlyRx e transceiver_onlyTx. Vale salientar que cada umdestes deverão ser executados em microcomputadores distintos. Dessa forma, se qui-sermos a configuração de um equipamento transmitindo e três na recepção, teremos quedispor de quatro máquinas, cada uma com o GNU Radio instalado e um USRP associado.Os fluxogramas dos arquivos transceiver_onlyRx e transceiver_onlyTx diferem entre sibasicamente pela forma de conexão dos blocos: enquanto o Rx dispõe de um bloco Mes-sage Strobe e não possui um USRP Sink, o Tx não possui um bloco Message Strobe epossui um USRP Sink. Essa diferença fica mais evidente comparando-se a Figura 5.16,que representa um transceptor Rx, e a Figura 5.17, que representa um transceptor Tx.

A aplicação transceiver_onlyTx pode ser iniciada através da compilação (F5) eexecução (F6) do arquivo transceiver_onlyTx. Podemos editar a mensagem a ser envi-ada (no nosso exemplo, o texto Msg Tx SBRC 2015) nas propriedades do bloco PeriodicMessage Strobe. Além do conteúdo da mensagem, podemos alterar o período (em milisse-gundo) e a quantidade de mensagens que serão transmitidas a cada execução. Observa-seda Figura 5.17 que os blocos Wireshark Connector e File Sink estão desativados (identifi-cáveis através do preenchimento em cor cinza), visto que, embora possível, não é neces-sário salvar as mensagens em um arquivo. A desativação ou ativação de blocos é possívelclicando-se com o botão direito do mouse sobre o bloco e escolhendo, respectivamente,Disable ou Enable. Uma funcionalidade que pode ser adicionada no futuro é obter amensagem através de um arquivo.

Para a recepção, devemos iniciar a aplicação transceiver_onlyRx compilando (F5)e executando (F6) o arquivo transceiver_onlyRx. O USRP então coletará as mensagensque estão sendo transmitidas na frequência especificada e o bloco RIME Stack fará adecodificação, salvando-as em um arquivo .pcap através do bloco Wireshark Connector.Dessa forma, pode-se verificar no arquivo recém gerado .pcap se a mensagem enviadapelo transmissor foi recebida corretamente pelo USRP e devidamente demodulada.



Figura 5.17. Arquitetura do transceptor Tx



Configuramos o transmissor para enviar a mensagem de texto Msg Tx SBRC 2015a cada 2 segundos, no canal 15, selecionado na janela gráfica logo após o início da trans-missão. O receptor foi configurado para receber no mesmo canal e salvar as capturas noarquivo msgBee.pcap . Com o Wireshark, abrimos esse arquivo e podemos visualizar asmensagens transmitidas, incluindo seu conteúdo de texto. A Figura 5.17 exibe a tela decaptura do Wireshark, onde se observa na porção superior da imagem todos os pacotesrecebidos e na base da imagem temos a mensagem textual que foi enviada. A Figura 5.19exibe um resumo, realizado pelo próprio Wireshark, avaliando quais as proporções de pro-tocolos presentes no arquivo. Neste caso, todos os 42 pacotes recebidos correspondiamao protocolo IEEE 802.15.4.

Figura 5.18. Tela do Wireshark exibindo o conteúdo do arquivo msgBee.pcap

5.4.6. Criando novos blocos

Como o principal objetivo do uso de SDR em pesquisa em redes de computadores é odesenvolvimento de novas técnicas e protocolos, nesta subseção apresentamos uma brevedescrição de como construir um novo bloco para o GNU Radio. Iremos apresentar umexemplo de um bloco simples, que realiza a contagem de mensagens recebidas pela apli-cação transceptor Rx. O bloco realiza incrementos sucessivos em um contador a cadavez que o mesmo é instanciado, e imprime no console o valor desse contador. Salienta-seque essa saída pode ser exibida também em uma interface gráfica, em livre escolha nabiblioteca do GRC.



Figura 5.19. Resumo de protocolos do arquivo msgBee.pcap

Inicialmente, precisamos mencionar que grande parte do esforço é realizado pelaferramenta gr_modtool, que já compõe o sistema GNU Radio. Informações detalhadas so-bre as opções dessa ferramenta podem ser obtidas com o comando $ gr_modtool help.Vamos criar um bloco chamado Multiply dentro da categoria Tutorial. Para isso, fazemos$ gr_modtool newmod tutorial . Como saída, teremos:

Creating out-of-tree module in ./gr-tutorial... Done.Use ’gr_modtool add’ to add a new block to this currently emptymodule.

Foi criada uma pasta chamada gr-tutorial. Devemos entrar nessa nova pasta eexecutar o comando especificado na primeira linha da sequência abaixo, e entrar com asrespostas para as solicitações abaixo descritas:

gr-tutorial$ gr_modtool add -t sync -l pythonGNU Radio module name identified: tutorialLanguage: PythonEnter name of block/code (without module name prefix): counter_py_ffBlock/code identifier: counter_py_ffEnter valid argument list, including default arguments: counterAdd Python QA code? [Y/n] nAdding file ’Python/counter_py_ff.py’...Adding file ’grc/tutorial_counter_py_ff.xml’...Editing grc/CMakeLists.txt...

Em seguida devemos abrir o arquivo counter_py_ff.py (o nome do arquivo é cons-tituído por nomedomodulo.extensão, sendo que a extensão é .py porque selecionamos alinguagem do bloco como Python), que está na pasta python recém criada e alterá-lo deforma que tenhamos a configuração abaixo. As inserções ou alterações ocorreram naslinhas 8, 13, 14, 21, 22 e 23. Na linha 8 instanciamos uma variável global, que será o con-tador. Nas linhas 13 e 14 definimos o tipo de dados como float, e finalmente nas linhas 21a 23 realizamos o incremento da variável contador e imprimimos a saída.



1 import numpy2 from g n u r a d i o import gr3

4 c l a s s c o u n t e r _ p y _ f f ( g r . s y n c _ b l o c k ) :5 " " "6 d o c s t r i n g f o r b l o c k c o u n t e r _ p y _ f f7 " " "8 c o n t a d o r = 09

10 def _ _ i n i t _ _ ( s e l f , c o u n t e r ) :11 gr . s y n c _ b l o c k . _ _ i n i t _ _ ( s e l f ,12 name=" c o u n t e r _ p y _ f f " ,13 i n _ s i g =[ numpy . f l o a t 3 2 ] ,14 o u t _ s i g =[ numpy . f l o a t 3 2 ] )15

16

17 def work ( s e l f , i n p u t _ i t e m s , o u t p u t _ i t e m s ) :18 i n 0 = i n p u t _ i t e m s [ 0 ]19 o u t = o u t p u t _ i t e m s [ 0 ]20 # <+ s i g n a l p r o c e s s i n g here+>21 s e l f . c o n t a d o r = s e l f . c o n t a d o r + 122 o u t [ : ] = o u t [ : ] = i n 0 ∗ s e l f . c o n t a d o r23 p r i n t s e l f . c o n t a d o r24 re turn l e n ( o u t p u t _ i t e m s [ 0 ] )

Por fim, devemos alterar o arquivo XML tutorial_counter_py_ff.xml, acessível napasta recém criada grc, para inserir o novo bloco na biblioteca do GRC. Poucas alteraçõessão necessárias no arquivo, mais especificamente nas linhas 14, 22, 23, 32 e 33. Estasalterações são necessárias para registrar as entradas e saídas do bloco no GRC, indicandoos seus respectivos tipos e nomes. Ao final da edição, o arquivo deve conter o textoabaixo:

1 <? xml v e r s i o n =" 1 . 0 " ?>2 <block >3 <name> c o u n t e r _ p y _ f f < / name>4 <key> t u t o r i a l _ c o u n t e r _ p y _ f f < / key>5 < c a t e g o r y > t u t o r i a l < / c a t e g o r y >6 < import> i m p o r t t u t o r i a l < / import>7 <make> t u t o r i a l . c o u n t e r _ p y _ f f ($ c o u n t e r ) < / make>8 <!−− Make one ’ param ’ f o r e v e r y Parameter you want on t h e GUI .9 Sub−n o d e s :

10 ∗ name11 ∗ key ( makes t h e v a l u e a c c e s s i b l e as $ keyname . . .12 ∗ t y p e −−>13

14 <!−− No p a r a m e t e r s i n t h i s b l o c k c o u n t e r−−>15

16 <!−− Make one ’ s i n k ’ node per i n p u t . Sub−n o d e s :17 ∗ name ( an i d e n t i f i e r f o r t h e GUI )



18 ∗ t y p e19 ∗ v l e n20 ∗ o p t i o n a l ( s e t t o 1 f o r o p t i o n a l i n p u t s ) −−>21 < s ink >22 <name> i n < / name>23 < type > f l o a t < / type >24 < / s ink >25

26 <!−− Make one ’ source ’ node per o u t p u t . Sub−n o d e s :27 ∗ name ( an i d e n t i f i e r f o r t h e GUI )28 ∗ t y p e29 ∗ v l e n30 ∗ o p t i o n a l ( s e t t o 1 f o r o p t i o n a l i n p u t s ) −−>31 < source >32 <name> o u t < / name>33 < type > f l o a t < / type >34 < / source >35 < / block >

Uma vez criado o arquivo XML de definições do bloco, devemos indicar ao GRCque existe um novo bloco. Para instalar o bloco no GRC, devemos sair do diretório .../grce criar uma pasta denominada build. A partir dela, devemos executar os comandos aseguir:

cmake ../makesudo make installsudo ldconfig

Abrindo o GRC, o novo bloco counter_py_ff deve aparecer no final da listagemda biblioteca, na categoria tutorial. Este bloco pode ser adicionado ao final do fluxo daaplicação transceptor Rx para que possa realizar uma contagem da quantidade de pacotesrecebidos; contudo precisamos inserir o bloco conversor IChar to Complex e outro blococonversor Complex to Float antes do bloco Counter. O bloco Counter pode ficar posi-cionado entre os blocos Wireshark Connector e File Sink. Informações complementaressobre construção de novos blocos e como adicioná-los à biblioteca podem ser encontradasem [Radio 2015c].

5.4.7. Dicas Práticas

Nesta seção iremos dar algumas dicas práticas de uso e instalação do GNU Radio, queidentificamos com o uso da plataforma em diversas aplicações. Elas são:

• Escolha da versão do GNU Radio e SO a ser empregada. Muitos dos padrões decomunicação modernos possuem implementações em GNU Radio (por exemplo,IEEE 802.11, IEEE 802.15.4, RFID), entretanto elas não fazem parte dos módulossuportados pela release oficial do GNU Radio. Estes módulos são conhecidos no



Gnu Radio como out-of-tree, ou OOT. Nestes casos, muitas vezes os módulos fazemreferências a funcionalidades e métodos de versões específicas do código. Alémdisso, os códigos podem requerer bibliotecas específicas do sistema em uma dadaversão. Uma dica importante, nestes casos, é sempre perguntar ao autor do móduloqual foi a versão do GNU Radio empregada, bem como o SO.

• Evite máquinas virtuais para aplicações de alta largura de banda. O GNURadio requer muito processamento quando toda a aplicação é executada no CPU.Assim, para usos de alta largura de banda, evite máquinas virtuais. Elas adicionamatrasos importantes no processamento, devido à virtualização da rede e USB.

5.4.8. Alternativas ao GNU Radio

Apresentaremos a seguir três principais alternativas ao uso do GNU Radio e, ao final,realizamos uma comparação entre as plataformas discutidas.

5.4.8.1. ASGARD

Desenvolvido pela Aalborg University, da Dinamarca, o ASGARD (Application-orientedSoftware on General purpose processors for Advanced Radio Development)[AsgardAAU 2015a] é um framework para desenvolvimento de aplicações para SDR erádios cognitivos. Escrito em linguagem C++, é executado como uma aplicação no es-paço de usuário do sistema operacional Linux, tem como principal objetivo fornecer ograu de flexibilidade necessário para a implementação de sistemas de comunicação multi-camadas reconfiguráveis [Tavares et al. 2012]. Diferentemente do GNU Radio, o AS-GARD não dispõe de um fluxo gráfico dos dados para edição ou visualização. A arquite-tura do software é baseada em APIs (Application Programmable Interfaces), utilizando-sede componentes, módulos, aplicativos e objetos de comunicação. A seguir encontramosuma breve descrição de cada um desses elementos [AsgardAAU 2015b]:

• Componente é a função atômica básica do ASGARD, não havendo restrições detipos de dados de entrada;

• Módulo é um processo que contém uma lista de componentes, executando-os deacordo com uma sequência definida;

• Aplicativos são responsáveis por especificar as relações entre os componentes, pos-suindo o mais alto nível de abstração, aceitando, inclusive, configuração por XML;

• Objetos de comunicação permitem a troca de dados entre diversos componentes eos módulos.

5.4.8.2. IRIS

IRIS (Implementing Radio in Software) é uma arquitetura de software para rádios cog-nitivos desenvolvida para processadores de propósito geral, compatível com Windows eLinux, que permite a criação de redes altamente reconfiguráveis.



Assim como GNU Radio, esta plataforma é orientada a componentes. Processado-res de sinais como filtros e moduladores são implementados como componentes genéricospassíveis de reconfiguração. Esses componentes são conectados entre si para produzir oscanais de transmissão e recepção, que por sua vez, são conectados às camadas superioresda rede.

O IRIS possui um foco muito grande em flexibilidade, e sua arquitetura possuigrande suporte para reconfiguração do rádio em tempo real. Além disso, possui suportenão só para camada física, mas para todas as camadas da rede, e provê ainda uma interfacebem definida para que os controladores possam tomar decisões baseadas nas observaçõesdo ambiente e do próprio rádio. IRIS suporta plataformas avançadas de processamentoque incluem FPGA e CellBE e, além disso, é baseada em C++, portável para diversossistemas operacionais e arquiteturas de CPU. A representação de seus componentes é feitautilizando XML, que permite até mesmo a reconfiguração de rádios em funcionamento.

Em comparação com GNU Radio, IRIS possui um suporte maior em relação àcapacidade de reconfiguração em tempo real e também quanto à pilha de protocolos darede, já em relação à linguagem de desenvolvimento, suporta apenas C++, enquanto oGNU Radio permite também o uso de Python [Sutton et al. 2010].

5.4.8.3. OSSIE

OSSIE (Open-Source Software Communication Architecture Implementation - Embed-ded) [NSF 2015] é um projeto aberto de SDR desenvolvido e mantido pela Virginia Tech,EUA. Ele foi criado para ser utilizado para prototipagem rápida e em provas de con-ceito. É patrocinado pela Fundação Nacional de Ciência dos EUA (U.S. National ScienceFoundation) e implementa uma versão aberta do software de comunicação SCA (SoftwareCommunication Architecture) desenvolvido pelo departamento de defesa norte-americano(U.S. Department of Defense). De acordo com [Snyder et al. 2011], OSSIE consiste dequatro partes principais:

• Núcleo do framework;

• uma “biblioteca” (workshop) de formas de ondas;

• uma biblioteca de componentes pré-fabricados e ondas; e

• um conjunto de ferramentas para desenvolvimento rápido de componentes e apli-cações SDR.

O sistema OSSIE é escrito em C++, utilizando omniORB CORBA ORB, e é pro-jetado para sistemas operacionais Linux. Por sua vez, ele é distribuído sob a licençaGNU GPL (General Public License) 2.0 ou posterior (para ferramentas e componentes deprocessamento de sinal), e GNU Lesser GPL 2.1 (para o núcleo do framework). Em con-traposição ao GNU Radio, OSSIE permite a integração com diversos outros ambientes dedesenvolvimento, como o Eclipse [Eclipse Foundation 2015] e o próprio GNU Radio.



5.4.8.4. Comparação

A Tabela 5.3 apresenta uma comparação das principais características das plataformas dedesenvolvimento SDR, incluindo o GNU Radio.

Linguagem Fluxográfico Custo Observações

GNU Radio C++ e Python SimGrátis, comlicença GPL

Código aberto; amplacomunidade de usuários

ASGARD C++ NãoGrátis, com umtermo de acordo

Desenvolvido pelaUniversidade de Aalborg

IRIS C++ SimGrátis apenaspara membros

Desenvolvido pelaUniversidade de Dublin

OSSIE C++ SimGrátis, comlicença GPL

Suporte do governonorte-americano

Tabela 5.3. Tabela comparativa com as principais plataformas SDR

5.5. Conclusões e desafiosNesta seção apresentamos os desafios do SDR hoje e suas limitações, bem como a nossavisão para o futuro da área e as conclusões.

5.5.1. Desafios

A seguir apresentamos os principais desafios para a evolução do SDR e das suas platafor-mas no meio científico.

• Maior largura de banda (bandwidth) dos transceptores. Os padrões mais recentesde telecomunicação tem empregado canais cada vez mais largos. O 802.11ac, porexemplo, poderá empregar canais de até 160MHz. Isso implica no desenvolvimentode novas plataformas de SDR com filtros suportando canais tão largos. Além disso,a quantidade de informação a ser processada irá aumentar, requerendo novos meca-nismos como barramentos com maior capacidade de transmissão de dados, sistemasoperacionais com baixa latência e alto throughput.

• Linguagens de alto nível e depuração. Da mesma forma que os bancos de dadospossuem linguagens específicas, facilitando a programação e depuração de consul-tas, os SDR deveriam empregar linguagens para a escrita de módulos de comuni-cação e protocolos de controle do meio que possuam alto nível de abstração. Amáquina de estados de FLAVIA é um exemplo, pois utiliza instruções ligadas aoproblema a ser tratado, que é a escrita de protocolos MAC. As linguagens de pro-pósito específico, quando aliadas a ambientes de programação e depuração adequa-dos, permitiriam o desenvolvimento e a verificação dos protocolos desenvolvidosde forma mais fácil.

• Suporte ao software. As bibliotecas de módulos e componentes são muitas vezessuportadas por grupos acadêmicos ou comunidades que não possuem financiamento



perene para as suas tarefas. O resultado é que os esforços de desenvolvimentosão perdidos, pois se tornam incompatíveis com o lançamento de novas versões daplataforma de hardware ou do software, e existe pouca documentação ou correçãode erros. A comunidade de SDR deve sensibilizar as agências de fomento parainiciativas de manutenção de software para a pesquisa, da mesma forma que hoje asplataformas experimentais possuem chamadas específicas para projetos. Um bomcomeço é o suporte da plataforma OSSIE pelo Departamento de Defesa dos EUA.

• Plataformas experimentais de menor custo, consumo de energia e tamanho. Apesarde SDR ter democratizado a pesquisa experimental em redes sem fio, o seu usoem experimentos de larga escala ainda é proibitivo devido ao seu custo, tamanhoe consumo de energia. Apesar de pesquisas indicarem que é possível desenvolverSDRs capazes de serem empregados em telefones e outros dispositivos móveis queexecutam padrões de comunicação de alto throughput [Lin et al. 2006], atualmentenão existem plataformas de SDR para pesquisa realmente portáteis. Isto impedeque experimentos de longa duração e escala, em ambientes móveis e utilizandovoluntários, possam ser realizados.

5.5.2. Visão do futuro

É inegável a importância de SDR, pois estas plataformas acelerarão o processo de pro-totipagem e o desenvolvimento de novas tecnologias de comunicação sem fio. O temponecessário no processo de desenvolvimento de novos padrões e protocolos de comunica-ção sem fio pode diminuir quando utilizamos componentes de software.

SDR podem e devem ser utilizados para tornar rádios cognitivos uma realidade.Com isso, teremos uma melhor eficiência do espectro de radiofrequência. Além disso, ouso de SDR em produtos comerciais permitirá que a atualizações de novas tecnologias decomunicação sem fio sejam implementadas por software e irá acelerar a adoção de novosprotocolos. Como vimos durante o texto, o conceito de SDR já é aplicado parcialmentena infra-estrutura celular.

Finalmente, o SDR pode ser uma ferramenta importante para a evolução rápidados padrões de comunicação e a diminuição do problema de compatibilidade entre pa-drões novos e de legado. Quando os padrões 802.11g,n e ac foram especificados, elesprecisaram ser compatíveis com todos os padrões anteriores, até mesmo com o primeiropadrão, o IEEE 802.11b. Isso acarreta em limitações no que pode ser melhorado no proto-colo, gerando restrições no que pode ser modificado e diversas “gambiarras”, que acabamcomplicando os protocolos e limitando a vazão da rede. Por exemplo, os novos padrões802.11 tiveram que adotar a confirmação de mensagens por rajadas para poder manter acompatibilidade. Caso os rádios empregassem SDR, não haveria problemas de compa-tibilidade, pois poderíamos atualizar os rádios já existentes mais rapidamente, e haveriauma melhor utilização do espectro de radiofrequência.

5.5.3. Considerações finais

O potencial do paradigma de Rádios Definidos por Software está apenas começando a serexplorado, mas já há grande interesse entre pesquisadores e empresas da área, tanto que



algumas plataformas comerciais já foram desenvolvidas, e diversos produtos incorporamSDR mesmo que parcialmente.

Neste trabalho apresentamos uma visão dos aspectos teóricos e práticos no desen-volvimento de pesquisa em SDR. Na parte teórica, apresentamos os usos de SDR, algumasplataformas populares na pesquisa em redes e telecomunicações, resultados de pesquisarecente que só foram possíveis devido ao uso de SDR, e os fundamentos de transmissãodigital. Na parte prática, focamos na plataforma GNU Radio. Mostramos como utilizar oGNU Radio, seus módulos e ferramentas.

Dado o seu potencial, consideramos que existe um campo amplo para o desen-volvimento de novos projetos de pesquisa em Rádios Definidos por Software, seja comoferramenta para o desenvolvimento de novos padrões e protocolos de comunicação, sejacomo alvo de estudos sobre novas soluções de implementação. Certamente, os trabalhosmais interessantes na área ainda virão.

Referências[Ope ] Open WRT. http://openwrt.org/. Acessado em Maio de 2013.

[Amiri et al. 2007] Amiri, K., Sun, Y., Murphy, P., Hunter, C., Cavallaro, J., andSabharwal, A. (2007). WARP, a unified wireless network testbed for education andresearch. In Microelectronic Systems Education, 2007. MSE ’07. IEEE InternationalConference on, pages 53–54.

[AsgardAAU 2015a] AsgardAAU (2015a). Asgard - platform for cognitive radio.http://blog.asgard.lab.es.aau.dk. Acessado em Março de 2015.

[AsgardAAU 2015b] AsgardAAU (2015b). Asgardaau. http://blog.asgard.lab.es.aau.dk/sites/default/files/material/other/asgard_commercial.pdf. Acessado em Março de 2015.

[Balint 2015] Balint (2015). Gnu radio tutorial series. https://www.youtube.com/watch?v=N9SLAnGlGQs&list=PL618122BD66C8B3C4. Acessado emMarço de 2015.

[Bharadia et al. 2013] Bharadia, D., McMilin, E., and Katti, S. (2013). Full duplex ra-dios. In Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, SIG-COMM ’13, pages 375–386, New York, NY, USA. ACM.

[Bloessl et al. 2013a] Bloessl, B., Leitner, C., Dressler, F., and Sommer, C. (2013a). AGNU Radio-based IEEE 802.15.4 Testbed. In 12. GI/ITG KuVS Fachgespräch Drah-tlose Sensornetze (FGSN 2013), pages 37–40, Cottbus, Germany.

[Bloessl et al. 2013b] Bloessl, B., Segata, M., Sommer, C., and Dressler, F. (2013b).An IEEE 802.11a/g/p OFDM receiver for GNU radio. In Proceedings of the SecondWorkshop on Software Radio Implementation Forum, Software Radio ImplementationForum (SRIF), pages 9–16.

[Cass 2013] Cass, S. (2013). A $40 software-defined radio. IEEE Spectrum, 50(7):22–23.



[Chen and Duan 2011] Chen, K. and Duan, R. (2011). C-RAN –the road towards greenRAN. Technical report, China Mobile. http://labs.chinamobile.com/cran/wp-content/uploads/CRAN_white_paper_v2_5_EN.pdf.

[Cidon et al. 2012] Cidon, A., Nagaraj, K., Katti, S., and Viswanath, P. (2012). Flash-back: decoupled lightweight wireless control. SIGCOMM Comput. Commun. Rev.,42(4):223–234.

[Cimini 1985] Cimini, L. J. (1985). Analysis and simulation of a digital mobile channelusing orthogonal frequency division multiplexing. Communications, IEEE Transacti-ons on, 33(7):665–675.

[Clark 1983] Clark, A. (1983). Principles of digital data transmision. London, PentechPress, 1983, 312 p., 1.

[Dillinger et al. 2003] Dillinger, M., Madani, K., and Alonistioti, N. (2003). SoftwareDefined Radio: Architectures, Systems and Functions. Wiley & Sons.

[Eclipse Foundation 2015] Eclipse Foundation (2015). Eclipse - The Eclipse Foundationopen source community.

[Ergen 2004] Ergen, S. C. (2004). Zigbee/ieee 802.15. 4 summary. UC Berkeley, Sep-tember, 10:17.

[Ettus Research a] Ettus Research, I. Ettus research. http://www.ettus.com.

[Ettus Research b] Ettus Research, I. Ettus research N210 product details. https://www.ettus.com/product/details/UN210-KIT.

[Force 2002] Force, S. P. T. (2002). Spectrum policy task force report et docket no. 02-155. Technical report, FCC.

[Forum 2011] Forum, W. I. (2011). Software defined radio - rate of adoption. http://www.wirelessinnovation.org/sdr_rate_of_adoption.

[Foundation 2015] Foundation, W. (2015). Wireshark - go deep. https://www.wireshark.org/. Acessado em Março de 2015.

[GNU Radio 2013] GNU Radio (2013). Welcome to GNU Radio! http://gnuradio.org/. Acessado em Maio de 2013.

[GNU Radio 2015] GNU Radio (2015). Tutorial: PSK Symbol Recovery.

[Gringoli and Nava ] Gringoli, F. and Nava, L. OpenFWWF – open firmware for WiFinetworks. http://www.ing.unibs.it/~openfwwf/.

[Gudipati and Katti 2011] Gudipati, A. and Katti, S. (2011). Strider: automatic rate adap-tation and collision handling. In Proceedings of the ACM SIGCOMM 2011 conference,SIGCOMM ’11, pages 158–169, New York, NY, USA. ACM.

[Haykin and Moher 2006] Haykin, S. S. and Moher, M. (2006). Introduction to analogand digital communications, volume 1. Wiley New York.



[Hong et al. 2012] Hong, S. S., Mehlman, J., and Katti, S. (2012). Picasso: flexible RFand spectrum slicing. SIGCOMM Comput. Commun. Rev., 42(4):37–48.

[Iannucci et al. 2012] Iannucci, P. A., Perry, J., Balakrishnan, H., and Shah, D. (2012).No symbol left behind: a link-layer protocol for rateless codes. In Proceedings of the18th annual international conference on Mobile computing and networking, Mobicom’12, pages 17–28, New York, NY, USA. ACM.

[III 2000] III, J. M. (2000). Cognitive Radio – An Integrated Agent Architecture forSoftware Defined Radio. PhD thesis, Royal Institute of Technology (KTH).

[Intel 2013] Intel, I. (2013). Packet processing on intel architecture. http://www.intel.com/go/dpdk.

[Katti et al. 2008] Katti, S., Rahul, H., Hu, W., Katabi, D., Médard, M., and Crowcroft, J.(2008). XORs in the air: practical wireless network coding. IEEE/ACM Trans. Netw.,16(3):497–510.

[Kumar et al. 2013] Kumar, S., Cifuentes, D., Gollakota, S., and Katabi, D. (2013).Bringing cross-layer MIMO to today’s wireless LANs. In Proceedings of the ACMSIGCOMM 2013 conference, SIGCOMM ’13, pages 387–398, New York, NY, USA.ACM.

[Leech 2015] Leech, M. (2015). Build-Gnuradio. http://www.sbrac.org/files/build-gnuradio. Acessado em Março de 2015.

[Leitner 2013] Leitner, C. (2013). Integration of the Rime Network Stack into GNU Ra-dio. Bachelor thesis, University of Innsbruck.

[Lin et al. 2008] Lin, K. C.-J., Kushman, N., and Katabi, D. (2008). ZipTx: Harnessingpartial packets in 802.11 networks. In Proceedings of the 14th ACM internationalconference on Mobile computing and networking, MobiCom ’08, pages 351–362, NewYork, NY, USA. ACM.

[Lin et al. 2006] Lin, Y., Lee, H., Woh, M., Harel, Y., Mahlke, S., Mudge, T., Chakra-barti, C., and Flautner, K. (2006). SODA: a low-power architecture for software radio.In Computer Architecture, 2006. ISCA ’06. 33rd International Symposium on, pages89–101.

[Murphy et al. 2006] Murphy, P., Sabharwal, A., and Aazhang, B. (2006). Design ofwarp: A wireless open-access research platform. In European Signal Processing Con-ference.

[Nagurney 2009] Nagurney, L. S. (2009). Software defined radio in the electrical andcomputer engineering curriculum. In Proceedings of the 39th IEEE international con-ference on Frontiers in education conference, FIE’09, pages 1489–1494.

[NSF 2015] NSF (2015). OSSIE - SCA-Based Open Source Software Defined Radio.



[Perry et al. 2012] Perry, J., Iannucci, P. A., Fleming, K. E., Balakrishnan, H., and Shah,D. (2012). Spinal codes. In Proceedings of the ACM SIGCOMM 2012 conference onApplications, technologies, architectures, and protocols for computer communication,SIGCOMM ’12, pages 49–60, New York, NY, USA. ACM.

[Pinto and de Albuquerque 2002] Pinto, E. L. and de Albuquerque, C. P. (2002). A téc-nica de transmissão ofdm. Revista Científica, 1516:2338.

[Radio 2015a] Radio, G. (2015a). Guided tutorial grc. http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC. Acessadoem Fevereiro de 2015.

[Radio 2015b] Radio, G. (2015b). Instalando o gnu radio. http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR_PTBR. Aces-sado em Março de 2015.

[Radio 2015c] Radio, G. (2015c). Out-of-tree modules. http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules. Acessado emMarço de 2015.

[Rappaport 2001] Rappaport, T. (2001). Wireless Communications: Principles and Prac-tice. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2nd edition.

[Reis et al. 2012] Reis, A. L. G., Barros, A. F., Lenzi, K. G., Meloni, L. P., and Barbin,S. (2012). Introduction to the software-defined radio approach. IEEE Latin AmericaTransactions, 10(1):1156–1161.

[Research 2015] Research, E. (2015). Ettus research product detail - b210. http://www.ettus.com/product/details/UB210-KIT. Acessado em Março de2015.

[Schmid 2006] Schmid, T. (2006). Gnu radio 802.15. 4 en-and decoding. unpublisheddocument and source.

[Shokrollahi 2006] Shokrollahi, A. (2006). Raptor codes. IEEE/ACM Trans. Netw.,14(SI):2551–2567.

[Sklar 2001] Sklar, B. (2001). Digital communications, volume 2. Prentice Hall NJ.

[Snyder et al. 2011] Snyder, J., McNair, B., Edwards, S., and Dietrich, C. (2011). Os-sie: An open source software defined radio platform for education and research. InInternational conference on frontiers in education: computer science and computerengineering (FECS’11). World congress in computer science, Computer engineeringand applied computing. Las Vegas, NV.

[Sutton et al. 2010] Sutton, P., Lotze, J., Lahlou, H., Fahmy, S., Nolan, K., Ozgul, B.,Rondeau, T., Noguera, J., and Doyle, L. (2010). Iris: an architecture for cognitiveradio networking testbeds. Communications Magazine, IEEE, 48(9):114–122.



[Tan et al. 2009] Tan, K., Zhang, J., Fang, J., Liu, H., Ye, Y., Wang, S., Zhang, Y., Wu,H., Wang, W., and Voelker, G. M. (2009). Sora: High performance software radiousing general purpose multi-core processors. In USENIX International Symposium onNetworked Systems: Design and Implementation (NSDI), pages 75–90.

[Tavares et al. 2012] Tavares, F. M. L., Tonelli, O., Berardinelli, G., Cattoni, A. F., andMogensen, P. (2012). Asgard: the aalborg university cognitive radio software platformfor dsa experimentation.

[Tenenbaum and Wetherall 2011] Tenenbaum, A. S. and Wetherall, D. (2011). Redes decomputadores. Pearson, São Paulo, SP.

[Tinnirello et al. 2012] Tinnirello, I., Bianchi, G., Gallo, P., Garlisi, D., Giuliano, F., andGringoli, F. (2012). Wireless MAC processors: Programming MAC protocols on com-modity hardware. In IEEE INFOCOM, pages 1269 –1277.

[Vieira et al. 2013] Vieira, L. F. M., Gerla, M., and Misra, A. (2013). Fundamental li-mits on end-to-end throughput of network coding in multi-rate and multicast wirelessnetworks. Computer Networks, 57(17):3267–3275.

[Wireless Innovation Forum ] Wireless Innovation Forum. Wireless innovation forum.http://www.wirelessinnovation.org.

[Wyglinski and Pu 2013] Wyglinski, A. M. and Pu, D. (2013). Digital CommunicationSystems Engineering with Software-Defined Radio. Artech House.



Capítulo

6Redes de Sensoriamento Participativo:Desafios e Oportunidades

Thiago H. Silva, Pedro O. S. Vaz de Melo, João B. B. Neto, Anna I. J. T.Ribeiro, Clayson S. F. de S. Celes, Vinícius F. S. Mota, Felipe D. da Cunha,Ana P. G. Ferreira, Kássio L. da S. Machado, Raquel A. de F. Mini, JussaraM. Almeida e Antonio A. F. Loureiro

Abstract

The popularization of portable devices such as smartphones and tablets, as well as theworldwide adoption of social media sites makes it increasingly possible to be connectedand share data from anywhere, anytime, enabling the participatory sensing. Systems thatenable this new source of sensing are called participatory sensor networks (PSNs). Inthis scenario, people participate as social sensors voluntarily providing data that capturetheir experiences of daily life. This large amount of social data can provide new valuableforms to obtain information that are currently not available with the same global reach,which can be used to improve decision-making processes of different entities (eg, people,groups, services, applications). The objective of this short course is to discuss the mainelements of participatory sensor networks, presenting an overview of the area, challengesand opportunities. We aim to show that PSNs (e.g., Instagram, Foursquare and Waze)can act as valuable sources for large scale sensing, providing access to important charac-teristics of city dynamics and urban social behavior, more quickly and comprehensively.This short course will discuss how to work with PSNs, analysing its properties and itsusefulness in the development of more sophisticated applications in several areas. In ad-dition, we will discuss research challenges and opportunities in the particular domain ofnetworks and distributed systems.

Resumo

A popularização de dispositivos portáteis, como smartphones e tablets, assim como aadoção mundial de sites de mídia social permitem cada vez mais a um usuário estar co-nectado e compartilhar dados de qualquer lugar, a qualquer momento, possibilitando osensoriamento participativo. Sistemas que permitem essa nova fonte de sensoriamento

6: Redes de Sensoriamento Participativo: Desafios e Oportunidades.


são chamados de redes de sensoriamento participativo (RSPs). Nesse cenário, as pes-soas participam como sensores sociais, fornecendo dados voluntariamente que capturamas suas experiências de vida diária. Essa grande quantidade de dados sociais facilita aobtenção de informações que não estão disponíveis prontamente com a mesma abrangên-cia praticamente global, podendo ser usadas para melhorar os processos de tomada dedecisão de diferentes entidades (e.g., pessoas, grupos, serviços, aplicações). O objetivodeste minicurso é discutir os principais elementos das redes de sensoriamento participa-tivo, apresentando uma visão geral da área, desafios e oportunidades. Visamos mostrarque as RSPs (e.g., Instagram, Foursquare, e Waze) podem atuar como valiosas fontes desensoriamento em larga escala, proporcionando acesso a características importantes dadinâmica de cidades e do comportamento social urbano, de forma rápida e abrangente.Este minicurso discutirá como trabalhar com RSPs, analisando as suas propriedades ea sua utilidade no desenvolvimento de aplicações mais sofisticadas em diversas áreas.Além disso, discutiremos os desafios e as oportunidades de pesquisa no domínio de redesde computadores e sistemas distribuídos.

6.1. IntroduçãoO estudo de redes de sensoriamento participativo (RSPs) é um tema recente de pesquisaque tem se mostrado bastante útil para o entendimento da dinâmica de cidades e do com-portamento social urbano [Silva et al. 2014a]. Redes de sensoriamento participativo per-mitem a observação das ações de pessoas em larga escala e em (quase) tempo real durantelongos períodos de tempo. As RSPs têm o potencial de se tornar uma ferramenta funda-mental para compreender melhor a interação entre as pessoas e os ambientes populadospor elas. A mineração de dados de RSPs pode aumentar significativamente o nosso co-nhecimento sobre diferentes aspectos de nossas vidas, o que pode ser bastante útil nodesenvolvimento de aplicações mais sofisticadas em diversos segmentos como, por exem-plo, na área de sistemas distribuídos.

Além disso, as RSPs têm o potencial para complementar as tradicionais redes desensores sem fio (RSSFs) [Loureiro et al. 2003] em diversos aspectos. Enquanto as RS-SFs foram projetadas para sensoriar áreas de tamanho limitado, como florestas e vulcões,as RSPs podem alcançar áreas de tamanhos variados e de larga escala, como grandesmetrópoles, países ou até mesmo todo o planeta [Silva et al. 2014a]. Além disso, umaRSSF está sujeita a falhas, uma vez que o seu funcionamento depende da correta co-ordenação das ações dos seus nós sensores, que possuem severas restrições de energia,processamento e memória. Por outro lado, RSPs são formadas por entidades autônomase independentes, ou seja, os seres humanos com seus dispositivos móveis. Isso torna atarefa de sensoriamento altamente resiliente a falhas individuais.

Assim, o objetivo deste minicurso é discutir as redes de sensoriamento participa-tivo, apresentando uma visão geral da área, desafios e oportunidades. Visamos mostrarque as RSPs (e.g., Instagram1, Foursquare2, e Waze3) podem atuar como valiosas fontespara sensoriamento em larga escala, proporcionando acesso a características importantes

1http://www.instagram.com2http://www.foursquare.com3http://www.waze.com



da dinâmica de cidades e do comportamento social urbano, de forma rápida e abrangente.Este trabalho discute como trabalhar com RSPs, analisando as suas propriedades e a suautilidade no desenvolvimento de aplicações mais sofisticadas em diversas áreas como, porexemplo, em sistemas distribuídos. Além disso, discutimos os desafios e as oportunida-des de pesquisa nas grandes áreas do Simpósio Brasileiro de Redes de Computadores eSistemas Distribuídos (SBRC).

O restante deste trabalho está organizado da seguinte forma. A Seção 6.2 discuteo emergente conceito de redes de sensoriamento participativo. A Seção 6.3 apresentaas propriedades de RSPs estudadas sobre diversos sistemas. A Seção 6.4 discute comotrabalhar com RSPs, incluindo a obtenção de dados. Ela também apresenta exemplos deabordagens já realizadas para extrair e gerar informações contextuais a partir de dadosde redes de sensoriamento participativo. A Seção 6.5 apresenta os desafios e as oportuni-dades para diversos tópicos de pesquisa atuais relacionados com redes de sensoriamentoparticipativo. Finalmente, a Seção 6.6 apresenta as conclusões e os trabalhos futuros.

6.2. Redes de Sensoriamento ParticipativoEsta seção descreve as redes de sensoriamento participativo (RSPs) [Silva et al. 2014a,Burke et al. 2006]. A Seção 6.2.1 apresenta a definição de uma RSP. A Seção 6.2.2 dis-cute o funcionamento de uma RSP, enquanto a Seção 6.2.3 ilustra exemplos de RSPs.

6.2.1. O que é uma rede de sensoriamento participativo?

O sensoriamento participativo pode ser definido como um processo distribuído de coletade dados pessoais. Tal processo requer a participação ativa das pessoas para comparti-lhar voluntariamente informação contextual e/ou tornar seus dados sensoriados disponí-veis [Burke et al. 2006]. Ou seja, o usuário determina manualmente como, quando, oquê e aonde amostrar. Assim, através das RSPs, é possível monitorar o comportamentocoletivo de pessoas conectadas à Internet em tempo (quase) real.

As RSPs têm se tornado populares graças ao aumento do uso de dispositivosportáteis, como smartphones e tablets, assim como a adoção mundial de sites de mí-dia social. Com isso, um elemento central de uma rede de sensoriamento participativoé um usuário capaz de sensoriar a cidade com um dispositivo computacional portátil.Nesse cenário, as pessoas participam como sensores sociais, fornecendo dados volun-tariamente sobre um determinado aspecto de um local, que implicitamente capturam assuas experiências de vida diária. Esses dados podem ser obtidos com a ajuda de dis-positivos de sensoriamento, por exemplo, sensores incorporados em smartphones (GPS,acelerômetro, microfone, e outros) ou por meio de sensores humanos (por exemplo, vi-são). Neste último caso os dados são observações subjetivas produzidas pelos usuá-rios [Silva et al. 2014a, Burke et al. 2006].

As RSPs oferecem oportunidades sem precedentes de acesso a dados de senso-riamento em escala planetária. Essa grande quantidade de dados facilita a obtenção deinformações que não estão disponíveis prontamente com a mesma abrangência pratica-mente global, podendo ser usadas para melhorar os processos de tomada de decisão dediferentes entidades (e.g., pessoas, grupos, serviços, aplicações).



Vale ressaltar que vários termos definidos recentemente, por exemplo, Humans asData Sources e Ubiquitous Crowdsourcing, refletem basicamente a definição de redes desensoriamento participativo [Srivastava et al. 2012, Mashhadi and Capra 2011, Ganti et al. 2011].É importante também mencionar que o termo sensoriamento oportunista [Lane et al. 2010],que denomina uma forma de sensoriamento que também utiliza dispositivos móveis dosusuários no processo de sensoriamento, pode gerar confusão com o termo sensoriamentoparticipativo. O sensoriamento participativo difere de sensoriamento oportunista, princi-palmente, pela participação do usuário, onde, neste último tipo, a etapa de coleta de dadosé automatizada, sem a participação do usuário [Lane et al. 2010].

6.2.2. O funcionamento de uma RSP

De forma similar às tradicionais redes de sensores sem fio (RSSFs) [Loureiro et al. 2003],o dado sensoriado em uma RSP é enviado para o servidor, ou “nó sorvedouro”, onde osdados podem ser acessados (usando, por exemplo, APIs, como a API do Instagram4). Mas,diferentemente das RSSFs, RSPs têm as seguintes características: (a) nós são entidadesmóveis autônomas, ou seja, uma pessoa com um dispositivo móvel; (b) o custo da rede édistribuído entre os nós, proporcionando uma escalabilidade global; (c) o sensoriamentodepende da vontade das pessoas participarem no processo de sensoriamento; (d) nós nãosofrem de severas limitações de energia.

Assim, as RSPs têm o potencial para complementar as RSSFs em diversos aspec-tos. As tradicionais redes de sensores sem fio foram projetadas para sensoriar áreas detamanho limitado, como florestas e vulcões. Em contrapartida, as RSPs podem alcançaráreas de tamanhos variados e de larga escala, como grandes metrópoles, países ou atémesmo todo o planeta [Silva et al. 2014a]. Além disso, uma RSSF está sujeita a falhas,uma vez que o seu funcionamento depende da correta coordenação das ações dos seusnós sensores, que possuem severas restrições de energia, processamento e memória. Já asRSPs são formadas por entidades autônomas e independentes, os seres humanos, o quetorna a tarefa de sensoriamento mais resiliente a falhas individuais. Obviamente, RSPstrazem também vários novos desafios, por exemplo, o seu sucesso está diretamente ligadoà popularização dos smartphones e serviços de mídia social.

A Figura 6.1 ilustra uma RSP constituída de usuários com seus dispositivos mó-veis enviando dados sensoriados sobre suas localizações para sistemas Web. A figuramostra as atividades de compartilhamento (representados por pontos vermelhos) de qua-tro usuários em três instantes diferentes no tempo, rotulados como “Tempo 1”, “Tempo2” e “Tempo 3”. Note que um usuário não participa necessariamente no sistema em todosos instantes. Após um certo tempo, podemos analisar estes dados de diferentes manei-ras. Por exemplo, a parte inferior mais à direita da figura mostra, por meio de uma visãoagregada, um grafo dirigido em que os nós representam os locais onde os dados foramcompartilhados e com arestas que conectam localidades que foram compartilhadas pelomesmo usuário. Usando este grafo podemos extrair, por exemplo, padrões de mobilidadedos usuários, que podem ser utilizados para efetuar um gerenciamento de carga de formamais eficiente na infraestrutura urbana de redes sem fio. Na verdade, a descoberta de co-nhecimento em RSPs caminha junto com uma vasta gama de estudos que utilizam a teoria

4http://instagram.com/developer.



Figura 6.1. Ilustração de uma rede de sensoriamento participativo [Silva et al. 2014a].

dos grafos para análise de redes sociais [Scott and Carrington 2011].

Os principais componentes deste tipo emergente de rede são ilustrados na Fi-gura 6.2. Esta figura destaca os três componentes mais importantes: (i) sensoriamentoparticipativo; (ii) gerenciamento de grandes amostras de dados; e (iii) análise de informa-ção contextual. O componente “sensoriamento participativo” representa, como o próprionome sugere, o processo de coleta de dados das pessoas por participação voluntária. Ocomponente “gerenciamento de grandes amostras de dados” é responsável pelo gerenci-amento de dados. Como podemos ver, o processo de coleta de dados pode ser repetido,por exemplo, para obter dados redundantes ou complementares do mesmo ou de outrossistemas. Depois disso, os dados coletados precisam ser processados para serem armaze-nados. Como a quantidade de dados provenientes de RSPs pode ser muito grande, todosos componentes precisam ser cuidadosamente projetados, principalmente se o objetivo éobter informações em tempo (quase) real sobre a cidade. Uma discussão mais detalhadade alguns dos desafios é apresentada na Seção 6.5.

Após a etapa de gerenciamento de dados, os dados estão prontos para serem ana-lisados. O componente “análise de informação contextual” ilustra cinco tipos de análisesque podem ser realizadas: (1) padrões sociais; (2) mobilidade; (3) entendendo cidades;(4) comportamento humano; e (5) detecção de eventos. Todos esses exemplos de análisessão discutidos na Seção 6.4.

6.2.3. Exemplos de RSPs

As redes sociais baseadas em localização, que são um tipo especial de mídia social quecombinam características de rede social online5 e serviços baseados em localização, sãoos exemplos mais populares de sistemas que podem fornecer dados às RSPs. É possívelencontrar vários exemplos de tais sistemas em funcionamento, tais como o Waze, queserve para relatar condições de tráfego em tempo real, o Foursquare, para compartilhar olocal onde o usuário está visitando, ou o Instagram, para enviar imagens em tempo real

5Plataforma virtual que constroe e reflete as relações sociais da vida real entre as pessoas.



Figura 6.2. Visão geral dos componentes de uma rede de sensoriamento partici-pativo [Silva et al. 2013a].

para o sistema. Em particular, o Instagram pode ser visto como uma das mais popula-res RSPs atualmente, com 200 milhões de usuários [Instagram 2014]. Considerando, porexemplo, o Instagram, o dado sensoriado é uma foto de um lugar específico. Podemosextrair informação desse tipo de dado de diversas maneiras. Uma das possibilidades évisualizar em tempo real como está a situação de uma certa área da cidade. Outras possi-bilidades são discutidas na Seção 6.4.

Note que todos os sistemas descritos anteriormente são compostos de uma redesocial online. No entanto, existem vários exemplos de RSPs que não contêm redes so-ciais. Por exemplo, o Weddar6, para relatar condições meteorológicas ou o NoiseTube7,para o compartilhamento de nível de barulho em determinada região da cidade. Alémdesses exemplos, podemos também citar o GarbageWatch [CENS/UCLA ], para monito-rar aspectos do lixo de uma cidade, e o DietSense [Reddy et al. 2007], para monitoraralimentos ingeridos pelos usuários através de fotografias dos alimentos tiradas durante asrefeições. Repare ainda que a utilização da Web também não é mandatória em uma RSP.Os dados sensoriados podem ser enviados para uma aplicação específica que esteja forada Web.

6.3. Propriedades de RSPsMuitas perguntas surgem a partir do conceito emergente de redes de sensoriamento par-ticipativo. Quais são as propriedades de RSPs? Quais os tipos de aplicações em quepodemos utilizar dados de RSPs? Quais são as limitações de RSPs?

Como os dados fornecidos por RSPs podem ser muito complexos, um passo fun-damental em qualquer investigação é caracterizar os dados coletados, a fim de entendersuas limitações e utilidade. Com isso, nesta seção vamos estudar as propriedades de trêsRSPs para compartilhamento de localização, a saber, Foursquare, Gowalla e Brightkite8,uma RSP para compartilhamento de fotos, particularmente o Instagram, bem como umaRSP para compartilhamento de alerta de trânsito (Waze).

6http://www.weddar.com7http://noisetube.net8As RSPs para compartilhamento de localização Gowalla e Brightkite não estão mais em funciona-

mento.



Tabela 6.1. Descrição dos datasets utilizados.

Serviços de compartilhamento de localizaçãoSistema # check-ins Intervalo

Foursquare1 ≈5 milhões abril de 2012 (1 semana)Foursquare2 ≈12 milhões fev2010-jan2011Foursquare3 ≈4 milhões maio de 2013 (2 semanas)

Gowalla ≈6 milhões fev2009-out2010Brightkite ≈4 milhões abr2008-out2010

Serviços de compartilhamento de fotosSistema # fotos Intervalo

Instagram1 ≈2 milhões jun2012-jul2012Instagram2 ≈2 milhões maio 2013 (2 semanas)

Serviços de alertas de trânsitoSistema # alertas IntervaloWaze +212 mil dez2012-jun2013

Primeiramente, a Seção 6.3.1 descreve os datasets das RSPs usados neste mini-curso. Em seguida, a Seção 6.3.2 analisa a cobertura dessas RSPs em diferentes granu-laridades espaciais. A Seção 6.3.3 discute a frequência de sensoriamento em que os nóscompartilham dados em regiões individuais do nosso dataset. A Seção 6.3.4 discute asazonalidade no processo de sensoriamento. Finalmente a Seção 6.3.5 estuda o compor-tamento dos nós das RSPs.

6.3.1. Descrição dos Dados

A Tabela 6.1 apresenta todos os datasets aqui considerados. Todos os dados foram cole-tados através do Twitter9, que é um serviço de microblogging, ou seja, ele permite queos seus usuários enviem e recebam atualizações pessoais de outros contatos em textosde até 140 caracteres, conhecidos como “tweets”. Além de tweets de texto simples, osusuários também podem compartilhar fotos a partir de uma integração com o Instagram,Foursquare ou Waze. Neste caso, fotos do Instagram, check-ins do Foursquare ou alertasdo Waze anunciadas no Twitter passam a ficar disponíveis publicamente, o que por pa-drão não acontece quando o dado é publicado unicamente nos sistemas analisados. Comopodemos ver na Tabela 6.1, os dados refletem diferentes períodos. Além disso, os data-sets incluem uma quantia bastante significativa de dados: mais de 25 milhões de registrosconsiderando todas as fontes.

Cada dado sensoriado (foto, check-in ou alerta) é composto de coordenadas GPS(latitude e longitude), o horário do compartilhamento do dado e o id do usuário comparti-lhador. O dataset Foursquare1 possui informações extras sobre o tipo de local: categoria(por exemplo, comida) e um identificador do local. Mais informações sobre os datasets ecomo eles foram obtidos podem ser encontradas em [Cheng et al. 2011, Silva et al. 2012,Silva et al. 2013c, Silva et al. 2013d, Silva et al. 2013e].

6.3.2. Cobertura da Rede

Nesta seção, analisamos a cobertura das RSPs analisadas em diferentes granularidadesespaciais, começando por todo o planeta, depois cidades e, por fim, áreas específicas deuma cidade. A Figura 6.3 mostra a cobertura no planeta de RSPs distintas: Foursquare

9http://www.twitter.com



Longitude

Latit

ude

−100 0 100

−50

0

50

0

5

10

φ

(a) Foursquare1

Longitude

Latit

ude

−100 0 100

−50

0

50

0

5

10

φ

(b) Gowalla

Longitude

Latit

ude

−100 0 100

−50

0

50

0

5

10

φ

(c) Brightkite

Longitude

La

titu

de

−100 0 100

−50

0

50

0

5

10

φ

(d) Instagram1

Longitude

Latit

ude

−100 0 100

−50

0

50

0

2

4

6

8

10

φ

(e) Waze

Figura 6.3. Cobertura de RSPs. Número de dados n por pixel indicado pelo valorde φ mostrado na figura, em que n = 2φ − 1 [Silva et al. 2013b, Silva et al. 2013e].

(dataset Foursquare1, Figura 6.3a), Gowalla (Figura 6.3b), Brightkite (Figura 6.3c); Ins-tagram (dataset Instagram1, Figura 6.3d); e Waze (Figura 6.3e). Os dados dessas figurasrepresentam dados na forma de um mapa de calor da participação dos usuários: coresmais escuras representam um maior número de dados compartilhados em determinadaárea. Como podemos ver, a cobertura é bastante abrangente e tem escala planetária.

Avaliamos agora a participação dos usuários em diversas cidades grandes locali-zadas em regiões distintas, mas mostramos os resultados para algumas delas: Nova York,Rio de Janeiro e Cairo. A figura 6.4 mostra o mapa de calor da atividade de sensori-amento para cada uma dessas cidades. Mais uma vez, cores mais escuras representamum maior número de fotos em determinada área. Observamos uma alta cobertura paraalgumas cidades, como mostrado nas Figuras 6.4a e 6.4d (Nova York). No entanto, comopodemos observar nas Figuras 6.4b e 6.4e, o sensoriamento no Cairo, que também possuium número elevado de habitantes, é significativamente mais baixo. Tamanha diferençana cobertura pode ser explicada por diversos fatores. Além dos aspectos econômicos,diferenças na cultura dos habitantes desta cidade quando comparadas com as culturas pre-sentes nas outras cidades estudadas podem ter um impacto significativo na adoção e usodesses sistemas considerados [Barth 1969].

Além disso, pode-se observar que a cobertura em algumas cidades, como no Riode Janeiro (Figuras 6.4c e 6.4f), é bem mais heterogênea quando comparada com a co-bertura de Nova York. Isto ocorre provavelmente por causa dos aspectos geográficos par-ticulares dessas cidades, ou seja, grandes áreas verdes e grandes porções d’água. O Riode Janeiro tem a maior floresta urbana do mundo, localizada no meio da cidade, além demuitas colinas de difícil acesso humano. Estes aspectos geográficos limitam a coberturado sensoriamento. Além disso, os pontos de interesse público, tais como pontos turísticos



(a) Nova Iorque - Foursquare (b) Cairo - Foursquare (c) Rio de Janeiro - Foursquare

(d) Nova Iorque - Instagram (e) Cairo - Instagram (f) Rio de Janeiro - Instagram

Figura 6.4. Cobertura espacial da RSP do Foursquare e Instagram em 3 cidadespopulosas ao redor do mundo [Silva et al. 2013b, Silva et al. 2013c].

Figura 6.5. Cobertura espacial da RSP para compartilhamento de alerta de trân-sito no Rio de Janeiro [Silva et al. 2013e].

e centros comerciais, são distribuídos de forma desigual pela cidade. Há grandes áreas re-sidenciais com poucos pontos desse tipo, enquanto outras áreas têm grande concentraçãodesses pontos.

A cobertura espacial dos dados da RSP para alertas de trânsito não é tão abran-gente como das RSPs para compartilhamento de localização e de foto. Isso pode serobservado na Figura 6.5, que mostra o número de alertas em diferentes regiões do Rio deJaneiro por um mapa de calor. Um fator que pode ajudar a explicar isso é a populaçãode usuários do dataset de alertas de trânsito, que é menor do que os outros estudados.Outro fator é que os usuários podem ter menos oportunidades para compartilhar alertasde trânsito em comparação com oportunidades para compartilhar fotos ou check-ins.

Como a atividade de participação pode ser bastante heterogênea dentro de uma ci-dade, analisamos a cobertura de RSPs em áreas específicas de uma cidade. Para ter um idde uma área específica da cidade para os datasets do Instagram e Waze, propomos dividir



(a) Foursquare (b) Instagram (c) Waze

Figura 6.6. Distribuição do número de dados em áreas específicas (escala log-log) [Silva et al. 2013b, Silva et al. 2013b, Silva et al. 2013e].

a área das cidades em espaços retangulares menores, como em uma grade10. Chamare-mos cada área retangular de uma área específica dentro de uma cidade. Consideramosque uma área específica possui a seguinte delimitação: 1·10−4◦ (latitude) × 1·10−4◦ (lon-gitude). Isso representa uma área de aproximadamente 8×11 metros em Nova Iorque e10×11 metros no Rio de Janeiro. Para outras cidades, as áreas também podem variar umpouco, mas não a ponto de afetar significativamente as análises realizadas.

A Figura 6.6 apresenta a função de distribuição acumulada complementar (com-plementary cumulative distribution function - CCDF) do número de dados compartilha-dos (check-ins, fotos ou alertas) por área específica de todas as localidades em nossosdatasets. Primeiramente, observe que, em ambos os casos, uma lei de potência11 des-creve bem esta distribuição. Isso implica que, na maioria das áreas específicas, há pou-cos dados compartilhados, enquanto existem algumas poucas áreas com centenas de da-dos compartilhados. Estes resultados estão consistentes com os resultados apresentadosem [Noulas et al. 2011], trabalho que estudou a participação de usuários em sistemas decompartilhamento de localização. Nos sistemas analisados, é natural que algumas áreaspossuam mais atividade que outras. Por exemplo, em áreas turísticas o número de fotoscompartilhadas tende a ser maior do que em um supermercado, apesar de um supermer-cado ser geralmente um local bastante popular. Se uma determinada aplicação requer umacobertura mais abrangente, é necessário incentivar os usuários a participarem em locaisque eles usualmente não o fariam. Micro-pagamentos ou sistemas de pontuação são exem-plos de alternativas que poderiam funcionar nesse caso. Discutimos essas oportunidadesna Seção 6.5.3.

Mostramos que uma RSP pode ter uma cobertura em escala planetária. No entanto,essa cobertura pode ser bastante desigual, em que grandes áreas ficam praticamente des-cobertas. Com isso em mente, a Figura 6.7 mostra a percentagem de locais distintos ondeos usuários compartilharam dados em um determinado intervalo de tempo no Instagram eFoursquare12, que possuem 598.397 e 725.419 locais, respectivamente. O percentual má-ximo de locais distintos compartilhados por hora é inferior a 3% para todos os sistemas.

10Note que nas áreas selecionadas não são consideradas fronteiras.11Matematicamente, uma quantidade x segue uma lei de potência se ela pode ser obtida de uma distribui-

ção de probabilidade p(x)∝ x−α , onde α é um parâmetro constante conhecido como expoente ou parâmetroescalar, e é um valor tipicamente entre 2 < α < 3 [Clauset et al. 2009].

12Consideramos os datasets Instagram2 e Foursquare3, pois representam o mesmo intervalo de tempo.



0 100 200 3000

1

2

3

4

Tempo (horas)

% d

e lo

calid

. sen

so.

FoursquareInstagram

Figura 6.7. Porcentagem de áreas específicas sensoriadas ao longo dotempo [Silva et al. 2014a].

100

1050

0.5

1

Dt (min)

P [

x >

X]

(a) Instagram

Figura 6.8. Distribuição acumulada do intervalo de tempo entre compartilhamen-tos de fotos em uma área específica popular [Silva et al. 2013c].

Isto indica que a cobertura instantânea destas RSPs é muito limitada quando considera-mos todas as localidades que poderiam ser sensoriadas no planeta (considerando todas aslocalidades já sensoriadas pelo menos uma vez). Em outras palavras, a probabilidade deuma área específica aleatória ser sensoriada em um horário aleatório é bem baixa.

6.3.3. Intervalo de Sensoriamento

As RSPs são bastante escaláveis porque seus nós são autônomos, ou seja, os usuários sãoresponsáveis pela sua própria operação e funcionamento. Como o custo da infraestrutura édistribuído entre os participantes, esta enorme escalabilidade e cobertura é alcançada maisfacilmente. O sucesso desse tipo de rede consiste em ter participação sustentável e de altaqualidade. Em outras palavras, o sensoriamento é eficiente desde que os usuários sejammantidos motivados a compartilharem seus recursos e dados sensoriados frequentemente.

Isso motiva o estudo da frequência com que usuários realizam o compartilhamentode dados em RSPs. Em [Silva et al. 2013c, Silva et al. 2013e, Silva et al. 2013b] mostra-mos que há momentos em que muitos dados são compartilhados em intervalos de poucosminutos e momentos em que não há compartilhamento por horas. Isso pode indicar quea maioria do compartilhamento de dados acontece em intervalos específicos, provavel-mente relacionados ao ciclo circadiano (ou rotina) das pessoas . Por exemplo, o comparti-lhamento de fotos em restaurantes tende a acontecer mais nos horários de almoço e jantar.Aplicações baseadas nesse tipo de sensoriamento devem considerar que a participação dousuário pode variar significativamente ao longo do tempo.

A Figura 6.8 mostra a função de distribuição acumulada (cumulative distribution



function - CDF) do intervalo entre fotos compartilhadas pelo mesmo usuário em um qua-drante popular. Podemos observar que uma fatia significativa dos usuários realiza com-partilhamento consecutivo de fotos em um curto intervalo de tempo. Por exemplo, cercade 20% de todo o compartilhamento de fotos observado acontece em até 10 minutos. Issosugere que os usuários tendem a compartilhar mais de uma foto na mesma área. Noulas etal. [Noulas et al. 2011] também observaram que uma parcela significativa dos check-insno Foursquare são realizados dentro de um curto intervalo de tempo. Por exemplo, maisdo que 10% de check-ins ocorrem dentro de 10 minutos.

6.3.4. Rotinas e o Compartilhamento de Dados

Analisamos agora como a rotina dos humanos afeta o compartilhamento dos dados. AFigura 6.9 mostra o padrão semanal de compartilhamento de dados em todos os tipos deRSPs analisadas13. Como esperado, os dados compartilhados nas RSPs apresentam umpadrão diurno, o que implica que durante a madrugada a atividade de sensoriamento ébastante baixa.

Considerando dias de semana, é possível observar um ligeiro aumento da atividadeao longo da semana, com poucas exceções quando há um pico de atividade. O trabalhode Cheng et al. [Cheng et al. 2011], que analisou sistemas para compartilhamento de lo-calização, foi observado esse mesmo comportamento, sem nenhum dia como exceção.

Podemos ainda observar que alguns picos de atividade variam ao longo do dia deacordo com o propósito da RSP. Como podemos ver na Figura 6.9, na RSP para com-partilhamento de localizações (Figuras 6.9a–c) existem três picos evidentes por voltada hora do café da manhã, almoço e jantar. Isso também foi observado por Cheng etal. [Cheng et al. 2011]. Já na RSP para compartilhamento de fotos (Figura 6.9d) existemapenas dois picos evidentes, que ocorrem por volta da hora do almoço e jantar. E no casoda RSP para compartilhamento de alertas de trânsito (Figura 6.9e) também existem doispicos evidentes, um por volta de 7:00 e 8:00 da manhã e outro por volta de 6:00 da tarde,coincidindo com horários típicos de maior intensidade no trânsito.

Analisando os diferentes padrões de comportamento para dias de semana e finalde semana podemos observar que o padrão é significativamente diferente. Note que ospicos observados nos dias de semana não são evidentes nos finais de semana. A falta derotina bem definida nos fins de semana é uma das possíveis explicações para esse fato.Além disso, as diferenças entre dias de semana e final de semana possuem relação como tipo de sistema analisado. Por exemplo, como nos fins de semana muitas pessoas nãoprecisam dirigir, é natural esperar um volume menor de dados no Waze.

A Figura 6.10 mostra o padrão temporal de compartilhamento para o Instagram eo Foursquare considerando todos os datasets. Essa figura apresenta o número médio dedados compartilhados por hora durante, durante os dias de semana (de segunda a sexta-feira) e também durante o fim de semana (sábado e domingo). Surpreendentemente, ve-mos o mesmo padrão de compartilhamento para cada curva cé muito semelhante, apesardo enorme intervalo entre as coletas (aproximadamente um ano). Isso acontece para osdias de semana e fins de semana, sugerindo que o comportamento do usuário em ambos

13O horário do compartilhamento foi normalizado de acordo com o local onde o dado foi compartilhado,utilizando para isso a informação geográfica do local.



Seg Ter Qua Qui Sex Sab Dom0

5

10

15x 104

Tempo (dias)

Freq

. de

sens

oria

men

to

(a) Foursquare


2

4

6

8

10x 104

Tempo (dias)

Freq

. de

sens

oria

men

to

(b) Gowalla


1

2

3

4

5x 104

Tempo (dias)

Freq

. de

sens

oria

men

to

(c) Brightkite

seg ter qua qui sex sab dom0

1

2

3x 104

Tempo (dias)

Fre

q.

de

se

nso

ria

me

nto

(d) Instagram


500

1000

1500

2000

2500

3000

3500

Tempo (dias)

Fre

q. d

e se

nsor

iam

ento

(e) Waze

Figura 6.9. Padrão do compartilhamento de fotos durante os dias da se-mana [Silva et al. 2013b, Silva et al. 2013c, Silva et al. 2013e].

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (horas)

# de

foto

s

Instagram 2Instagram 1

(a) Instagram – dia desemana

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (hours)

# de

foto

s

Instagram 3Instagram 1

(b) Instagram – fim desemana

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (hours)

# de

che

ck−

ins

Foursquare 3Foursquare 1

(c) Foursquare – dia desemana

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (hours)

# de

che

ck−

ins

Foursquare 3Foursquare 1

(d) Foursquare – fim desemana

Figura 6.10. Padrão de compartilhamento temporal no Instagram e Fours-quare [Silva et al. 2013d].

os sistemas tende a se manter consistente ao longo do tempo. Esse é um resultado inte-ressante e importante, pois mostra que podemos usar diferentes datasets para propósitossimilares.

Mostramos agora como as rotinas impactam no comportamento de compartilha-mento durante a semana. Para essa análise, consideramos os datasets do Instagram eFoursquare para Nova York, São Paulo e Tóquio. Os resultados são mostrados na Fi-gura 6.1114. Em todas as figuras nós exibimos dados dos datasets do mesmo período(Instagram2 e Foursquare3) para duas cidades do mesmo país, e dados de um datasetcom período anterior (Instagram1 e Foursquare1) para uma dessas cidades, como umareferência de comparação.

Primeiramente, observe a distinção entre as curvas de cada cidade no mesmo sis-

14Cada curva é normalizada pelo número máximo de conteúdo compartilhado em uma região específicarepresentando a cidade.



tema (por exemplo, Instagram, Figuras 6.11a, c, e) e também em diferentes sistemas (porexemplo, as Figuras 6.11a e 6.11b para Nova Iorque). Em seguida, observe que o padrãode compartilhamento para cada cidade no mesmo país é bastante semelhante, o que podeser consequência dos padrões culturais dos habitantes desses países. Isso representa, decerta maneira, uma assinatura de aspectos culturais, o que ilustra, mais uma vez, o poten-cial desse tipo de dado para o estudo de dinâmica de cidades e do comportamento socialurbano.

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (horas)

# de

foto

s

NY instagram 2Chicago inst. 2NY instagram 1

(a) Nova Iorque – Instagram

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (horas)

# de

che

ck−

ins

NY 4sq 3Chicago 4sq 3NY 4sq 1

(b) Nova Iorque – Foursquare

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (horas)

# de

foto

s

SP instagram 2Rio instagram 2SP instagram 1

(c) São Paulo – Instagram

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (horas)

# de

che

ck−

ins

SP 4sq 3Rio 4sq 3SP 4sq 1

(d) São Paulo – Foursquare

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (horas)

# de

foto

s

Toquio inst. 2Osaka inst. 2Tokyo inst. 1

(e) Tóquio – Instagram

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Tempo (horas)

# de

che

ck−

ins

Toquio 4sq 3Osaka 4sq 3Tokyo 4sq 1

(f) Tóquio – Foursquare

Figura 6.11. Padrão de compartilhamento temporal do Instagram eFoursquare para Nova Iorque, São Paulo e Tóquio durante dias de se-mana [Silva et al. 2013d].

6.3.5. Comportamento dos Nós

Nesta seção é analisado o desempenho dos nós da RSP (i.e., dos usuários) quanto ao com-partilhamento de dados. A Figura 6.12 mostra a distribuição do número de dados (fotose alertas) compartilhados por cada usuário da nossa base de dados. Como podemos ob-servar, a distribuição possui cauda pesada, o que significa que a participação dos usuáriospode ser muito desigual. Por exemplo, aproximadamente 40% dos usuários contribuíramcom apenas uma foto no período considerado, enquanto que somente 17% e 0,1% dosusuários contribuíram com mais que 10 e 100 fotos, respectivamente. É natural que essavariabilidade aconteça por diversos motivos. Por exemplo, alguns usuários podem darmais importância para quesitos de privacidade do que outros. Uma cauda pesada tambémé observada na distribuição do número de check-ins, como foi mostrado por Noulas etal. [Noulas et al. 2011]. Cerca de 20% dos usuários realizaram apenas um check-in, 40 %acima de 10, ao passo que cerca de 10 % realizaram mais de 100 check-ins.



(a) Instagram (b) Waze

Figura 6.12. Distribuição do número de dados compartilhadas pelos usuá-rios [Silva et al. 2013c, Silva et al. 2013e].

6.3.6. Considerações Finais

Nessa seção estudamos as propriedades de RSPs derivadas de serviços de compartilha-mento de localização, de serviços de compartilhamento de fotos e de serviços de alertade trânsito. Essas RSPs possuem várias propriedades em comum: (i) possuem escalaplanetária; (ii) possuem uma frequência altamente desigual de compartilhamento de da-dos, tanto espacialmente quanto temporalmente, o que é altamente correlacionado com arotina típica das pessoas; (iii) a participação do usuário em relação ao número de dadoscompartilhados e onde esses dados são compartilhados pode variar significativamente;(iv) o padrão de temporal de compartilhamento parece não variar consideravelmente aolongo do tempo para o mesmo tipo de sistema.

As propriedades identificadas aqui revelam o potencial de RSPs para conduzirvários estudos sobre a dinâmica da cidade e do comportamento social urbano, como édiscutido na próxima seção (Seção 6.4).Além disso, o entendimento do comportamentodo usuário é o primeiro passo para modelá-lo. Com modelos que explicam o comporta-mento do usuário podemos fazer previsões de ações e desenvolver melhores sistemas paraplanejamento de capacidade de carga do sistema.

É importante salientar algumas possíveis limitações dos nossos datasets. Em pri-meiro lugar, eles refletem o comportamento de uma fração dos cidadãos da cidade. Nossosdatasets são baseados em dados compartilhados pelos usuários do Foursquare, Instagrame Waze no Twitter. Portanto, os dados são enviesados para os cidadãos que utilizam essessistemas. Em segundo lugar, nossos datasets são baseados em uma amostra limitada dedados. Isso significa que temos apenas uma amostra das atividades realizadas. Fatoresexternos, tais como condições meteorológicas desfavoráveis, podem ter afetado o númerototal de dados que coletamos para alguns lugares, especialmente em locais ao ar livre. Poresse motivo, antes de tirar conclusões com dados de RSPs, é altamente recomendado acomparação dos resultados com dados obtidos de uma maneira tradicional (offline), comofeito, por exemplo, em [Silva et al. 2014c].

6.4. Trabalhando com RSPsNesta seção discutimos como trabalhar com RSPs. O primeiro passo, discutido na Se-ção 6.4.1, é a obtenção de dados. Em seguida discutimos algumas abordagens já reali-zadas para extrair e gerar informações contextuais a partir de dados de redes de senso-



riamento participativo. Esses estudos foram agrupados em quatro classes: Entendendocidades (Seção 6.4.2); Mobilidade (Seção 6.4.3); Padrões Sociais, Econômicos e Cultu-rais (Seção 6.4.4); e Detecção de Eventos e Interesses (Seção 6.4.5).

6.4.1. Obtenção de dados

Nesta seção apresentamos três das principais formas de obtenção de dados de RSPs: APIs(Seção 6.4.1.1); crawler (Seção 6.4.1.2); e aplicações (Seção 6.4.1.3).

6.4.1.1. APIs

A Web está repleta de fontes de informação, dentre elas as RSPs, o que representa umagrande oportunidade para pesquisadores de diversas áreas coletarem dados em larga es-cala e extrair conhecimentos a partir deles [Benevenuto et al. 2011].

Algumas RSPs disponibilizam APIs (access programming interfaces) que podemser utilizadas para a extração de dados. Através desse processo é possível obter dados deRSPs que podem ser utilizados em outras aplicações ou em análises específicas. VáriasRSPs populares, como Twitter, Flickr e Foursquare, possuem APIs de acesso aos dadoscompartilhados pelos usuários. Entretanto, é comum existirem regras diferentes para asua utilização.

Existem basicamente duas formas principais de funcionamento das APIs: (1) base-adas em streaming; (2) baseadas em requisições. Uma API baseada em streaming permitecoletar em tempo real os dados que são publicados em uma determinada RSP. No entanto,é comum existir um limite no número de informações disponibilizadas. A API de strea-ming do Twitter, por exemplo, permite coletar em (quase) tempo real aproximadamente1% da base total de tweets públicos publicados. Já uma API baseada em requisiçõesdisponibilizam dados a medida que são solicitados. É comum as solicitações serem perso-nalizadas, por exemplo delimitando uma área específica para a obtenção de dados, assim apossibilidade de coletar dados pode ser maior do que uma API baseada em streaming. Noentanto é bastante comum existir uma limitação do número de requisições. Por exemplo,o Flickr permite 3600 requisições por hora em sua API. Isso pode inviabilizar alguns tiposde análises que necessitam de um número maior de amostras no período de uma hora, porexemplo.

De fato, talvez pela simplicidade de utilização, o uso de APIs é uma forma bastantepopular para a obtenção de dados. Dados obtidos através da API do Twitter, por exemplo,foram utilizados das mais variadas formas. Desde medir a influência de usuários na rede[Cha et al. 2010], até a previsão de terremotos [Sakaki et al. 2010a].

Existem RSPs que possuem APIs mas com acesso bastante restrito aos dados.Esse é o caso do Foursquare, pois poucos dados são possíveis de serem coletados sema autorização do usuário. A maioria dos dados disponíveis nessa API são referentes aoslocais, como dicas, listas, localização e fotos. Essas limitações estimulam a obtenção dedados de forma indireta ou alternativas. Por exemplo, em [Ferreira et al. 2014] os dadosdo Foursquare foram obtidos através de mensagens compartilhadas no Twitter contendocheck-ins do Foursquare. Dessa forma dados sobre o check-in do usuário podem ser



obtidos, já que foram publicamente disponibilizados pelos usuários. Esse tipo de dadoespecífico não é acessível pela API do Foursquare. De posse dos dados dos check-ins, osautores complementaram esses dados utilizando a API do Foursquare para obter dadossobre os locais, que não disponíveis nas mensagens do Twitter. No final desse processo, adiversidade de dados obtidos é maior e mais rica.

Um exemplo de uso da API de streaming do Twitter, escrito em (pseudo) Pythone utilizando a biblioteca TwitterAPI15, é mostrado no Algoritmo 1. Nesse algoritmo fa-zemos acesso aos tweets buscando pela palavra-chave "sbrc". Como podemos ver, empoucas linhas de código é possível coletar facilmente dados do Twitter.

Algoritmo 1: Exemplo de obtenção de dados do Twitter.1 from TwitterAPI import TwitterAPI // Biblioteca que facilita a

interação com a API do Twitter2 twitter_api = TwitterAPI(consumer_key=’XXXX’,3 consumer_secret=’XXXX’,4 access_token_key=’XXXX’,5 access_token_secret=’XXXX’)// Um registro no website da API fornece

as credenciais indicadas aqui.6 filters = "track": ["sbrc"] // Procurando tweets com a palavra SBRC7 stream = twitter_api.request(’statuses/filter’, filters)8 foreach item in stream.get_iterator() do9 print item[’text’] // exibe texto do tweet

10 end

6.4.1.2. Crawler

Nem todas as fontes de dados disponíveis na Internet fornecem acesso direto a esses dadosatravés de APIs. Por isso é necessário utilizar outras formas de obtenção de dados. Umadessas alternativas é a chamada Web crawler, que são programas que analisam páginasWeb em busca de dados relevantes [Anbukodi and Manickam 2011]. Um Web crawlerfunciona como um robô que acessa páginas Web predeterminadas e recupera dados apartir dessas páginas.

A coleta através de Web crawler depende da estrutura da fonte que desejamosobter dados, bem como da abordagem utilizada. A estrutura da fonte é onde os dados quequeremos extrair estão disponibilizadas nas páginas Web, por exemplo, são tags HTMLque apresentam os dados ao usuário. Com isso a construção de um Web crawler demandatipicamente a mineração de texto para a extração dos dados necessários na página Webestudada. No entanto, outras formas não convencionais de extração de dados é possívelde páginas Web. Por exemplo, em [Tostes et al. 2014] os autores construíram um Webcrawler para coletar informações de tráfego tirando fotos (screenshots) de mapas comessas informações, como as disponíveis no Bing Maps16. Mais informações sobre esseprocedimento são fornecidas na Seção 6.5.5.4.

15https://github.com/geduldig/TwitterAPI.16http://www.bing.com/maps.



Na construção de um Web crawler podemos utilizar diferentes estratégias para aescolha dos dados que serão coletados. Duas importantes estratégias para buscar sitesinteiros (ou uma amostra deles) é a busca em largura e a técnica Snowball. A busca emlargura varre todas as URLs de maneira sistemática, onde captura todas as URLs a partirde uma URL inicial e realiza novamente a busca nas URLs encontradas, até que nãoexista mais nenhuma URL disponível. Ao realizar coletas baseadas na busca em largura,conseguimos captar todas as páginas de uma fonte. Entretanto, nem sempre é possível ouviável coletar todas as páginas [Benevenuto et al. 2011]..

Com isso, a estratégia de Snowball é uma alternativa para coletar uma amostrados dados. Ao invés de buscar todas as URLs até que tenham-se esgotado, selecionamosum grupo chamado de seeds. A busca em largura será usada neste grupo até que sejainterrompida, de acordo com um critério preestabelecido de acordo com os objetivos daamostra. Estes critérios podem ser o tempo de execução da busca ou ter encontrado umcomponente conectado [Benevenuto et al. 2011].

6.4.1.3. Aplicações

Uma outra alternativa para a coleta de dados é a criação de aplicações em plataformas jáexistentes. Algumas mídias sociais populares, como Facebook, Instagram e Runkeeper,permitem a criação de aplicativos dentro de suas plataformas. Com isso, desenvolvedorespodem oferecer serviços utilizando dados que são compartilhados nesses aplicativos porusuários dessas mídias sociais.

O Facebook, por exemplo, não permite a coleta de informações direta de seususuários por APIs ou Web crawlers. No entanto, como permitem a criação de aplicaçõesé possível obter dados compartilhados por seus usuários. Quando o usuário do Facebookinstala um aplicativo e autoriza a leitura de seus dados, o desenvolvedor da aplicação podeler e armazenar diversos dados, como dados disponibilizados pelos usuários, por exemplo,o conteúdo compartilhado com seus amigos.

Em [Nazir et al. 2008] os autores utilizaram essa abordagem de coleta de dados.Eles criaram aplicações do Facebook especificamente coletar dados que possibilitassemo estudo do comportamento das pessoas que fazem uso dessas aplicações no Facebook.Outro exemplo foi o aplicativo utilizado em [Youyou et al. 2015]. Os autores criaram umaaplicação no Facebook que captura os últimos likes17 do usuário para traçar um perfil depersonalidade.

De posse de dados de RSPs, que podem ser obtidos por alguma dessas formascitadas, podemos extrair conhecimento. Como discutido nas próximas seções.

6.4.2. Entendendo o Funcionamento de Cidades

As informações obtidas a partir de RSPs têm o poder de mudar os nossos limites físicospercebidos, bem como ajudar a compreender melhor a dinâmica de cidades. Esta seçãoconcentra na apresentação de estudos nessas direções.

17Um like é uma interação do usuário com o Facebook em que ele demonstra que gostou de um itemcompartilhado.



Usando dados do Foursquare, Cranshaw et al. [Cranshaw et al. 2012] propuseramum modelo para identificar regiões distintas de uma cidade que refletem padrões atuais deatividades coletivas, apresentando novos limites para os bairros. Long et al. [Long et al. 2012]classificaram lugares em uma cidade com base nas trajetórias dos usuários, capturadascom o auxílio de check-ins do Foursquare. O trabalho desses autores se baseia no pres-suposto de que os locais que aparecem juntos nas trajetórias de muitos usuários, pro-vavelmente, são considerados como “tópicos geográficos”, representando, por exemplo,restaurantes que as pessoas costumam ir após fazer compras em um shopping.

Em [Silva et al. 2014d] propusemos uma técnica chamada City Image, que for-nece um resumo visual da dinâmica da cidade com base nos movimentos das pessoas.Esta técnica explora grafos de transição urbana para mapear os movimentos dos usuá-rios entre locais da cidade. Um grafo de transição urbana é um grafo dirigido ponderadoG(V,E), em que um nó vi ∈ V é a categoria de um local específico (por exemplo, f ood)e uma aresta direcionada (i, j) ∈ E marca uma transição entre duas categorias. Ou seja,uma aresta existe a partir do nó vi para o nó v j se pelo menos um usuário compartilhou umdado em um local categorizado por v j logo após compartilhar um dado em um local cate-gorizado por vi. O peso w(i, j) de uma aresta é o número total de transições que ocorrerama partir de vi para v j. Somente dados consecutivos compartilhados pelo mesmo usuáriodentro de 24 horas, com início às 5:00, são considerados no cálculo de uma transição.

A City Image é uma técnica promissora que permite uma melhor compreensão dadinâmica de cidades, ajudando na visualização das rotinas comuns de seus cidadãos. Cadacélula da City Image representa o quão favorável é uma transição de uma determinadacategoria em um determinado lugar (eixo vertical) para outra categoria (eixo horizontal).As cores vermelhas representam rejeição, as cores azuis representam favorabilidade e acor branca representa indiferença. Nós exemplificamos a técnica City Image para duascidades18: São Paulo (Figures 6.13a and 6.13b); e Kuwait (Figures 6.13c e 6.13d). Paraambos os casos, consideramos dias de semana durante o dia, que é o período típico derotinas, e fim de semana durante a noite, que é um período representativo de atividades delazer (fora da rotina).

Destination

Food

Shop

EduOut

d

Home

A&E NLTrv

lOffi

So

urc

e

Food

Shop

Edu

Outd

Home

A&E

NL

Trvl

Offi

0 200 400 600 800

(a) SP (Dia - Dia de se-mana)

Destination

Food

Shop

EduOut

d

Home

A&E NLTrv

lOffi

So

urc

e

Food

Shop

Edu

Outd

Home

A&E

NL

Trvl

Offi

0 50 100 150 200 250 300

(b) SP (Noite - Fim desemana)

Destination

Food

Shop

EduOut

d

Home

A&E NLTrv

lOffi

So

urc

e

Food

Shop

Edu

Outd

Home

A&E

NL

Trvl

Offi

0 50 100 150 200

(c) KU (Dia - Dia de se-mana)

Destination

Food

Shop

EduOut

d

Home

A&E NLTrv

lOffi

So

urc

e

Food

Shop

Edu

Outd

Home

A&E

NL

Trvl

Offi

0 20 40 60 80 100 120 140

(d) KU (Noite - Fim desemana)

Figura 6.13. Images produzidas com a técnica City Image para São Paulo (SP) eKuwait (KU) em diferentes períodos. Abreviaturas das categorias de locais (No-mes usados pelo Foursquare): Arts & Entertainment (A&E); College & Education(Edu); Great Outdoors (Outd); Nightlife Spot (NL); Shop & Service (Shop); andTravel Spot (Trvl) [Silva et al. 2014a].

Primeiramente, observe que transições para office (locais de trabalho) são mais18Utilizando dados do dataset Foursquare1.



prováveis de acontecer nos dias de semana e durante o dia para ambas as cidades, comoesperado. No entanto, note que as imagens da cidade de São Paulo e Kuwait tambémtêm diferenças significativas que refletem diversidades culturais entre ambas as cidades.Note, por exemplo, que a imagem que representa transições nas noites do fim de semana(Figure 6.13d) mostra a falta de transições favoráveis para a categoria nightlife no Kuwait.Este não é o caso de São Paulo (Figure 6.13b), em que a transição food → nightlife éaltamente favorável de acontecer. Isso sugere que em São Paulo as pessoas gostam de fre-quentar locais relacionados com comida (food) antes de ir para casas noturnas (nightlife).No Kuwait, em vez disso, as pessoas são provavelmente mais favoráveis a realizarem astransições shop → food e food → home nas noites do fim de semana.

Técnicas para fornecer visualizações de fácil interpretação das rotinas de habitan-tes de uma cidade, tais como as mencionadas aqui, são ferramentas valiosas para ajudaros urbanistas a entender melhor a dinâmica de cidades e, por conseguinte, tomar decisõesmais eficazes.

6.4.3. Mobilidade

Nesta seção apresentaremos trabalhos que se concentram em estudar padrões de mo-bilidade dos usuários com dados de RSPs. Esses dados incluem informações espaço-temporal, por exemplo, check-ins e fotos geolocalizadas. O estudo da mobilidade é útilpara muitas finalidades. Com dados de RSPs é possível entender, por exemplo, como osusuários alocam tempo para diferentes atividades, sendo, portanto, uma questão funda-mental nas ciências sociais. Além disso, é possível projetar novas ferramentas para ajudaros engenheiros de tráfego a entender o fluxo de pessoas na cidade.

A modelagem dos padrões de mobilidade vem atraindo a atenção de pesquisadoresem diferentes áreas, como física e computação [Brockmann et al. 2006, Zheng et al. 2009,Gonzalez et al. 2008]. É importante ressaltar que os dados derivados das RSPs são dife-rentes de dados provenientes de traces de GPS ou de dados tradicionais do uso do telefonecelular, como ligações telefônicas, e apresentam características especiais e variados con-textos. Por exemplo, os check-ins em serviços de compartilhamento de localização oufotos em um serviço de compartilhamento de fotos trazem informações extras sobre umlugar particular. Por exemplo, um check-in está associado com um tipo de local, e.g. bar,e uma foto pode trazer informações sobre a situação atual dentro deste local. Com isso,nosso foco aqui são estudos que analisam dados de RSPs.

Cheng et al. [Cheng et al. 2011] analisaram check-ins compartilhados em váriosserviços de compartilhamento de localização. Eles descobriram que os usuários pos-suem padrões simples e reproduzíveis, e também que o status social, além de fatoresgeográficos e econômicos, colaboram com a mobilidade. Da mesma forma, Cho etal. [Cho et al. 2011] investigaram padrões de movimentos e como os laços sociais po-dem impactar esses movimentos. Os autores observaram que viagens de curta distânciasão espacialmente e temporalmente periódicas e não são afetadas pela estrutura de redesocial, enquanto as viagens de longa distância são mais influenciadas por laços da redesocial.

Esses esforços ilustram o crescente interesse e o potencial de utilização de dadoscompartilhados em RSPs para estudar padrões de mobilidade de humanos em larga escala.



6.4.4. Padrões Sociais, Econômicos e Culturais

Os dados de RSPs também podem ser usados para estudar aspectos sociais, econômicose culturais dos habitantes de cidades. Por exemplo, pode-se argumentar que uma pequenaquantidade de dados compartilhados em uma área da cidade pode indicar uma falta deacesso à tecnologia por parte da população local, pois o uso de serviços de compartilha-mento de localização muitas vezes dependem de smartphones e planos de dados 3G ou4G que, geralmente, são caros. Nessa direção, em [Silva et al. 2013b] nós mostramos quea análise de dados de RSPs permitem a visualização de fatos interessantes relacionadoscom questões socioeconômicas de uma cidade. Por exemplo, dados de uma RSP paracompartilhamento de localização para a cidade do Rio de Janeiro são escassos em áreaspobres, incluindo as que são localizadas muito perto de áreas ricas. Essa informação podeser útil para gerar melhores políticas públicas nessas áreas. Note que a mesma informa-ção pode ser obtida utilizando métodos tradicionais, tais como questionários, mas esseprocesso é muito mais lento e caro.

Com o intuito de melhor entender padrões sociais a partir da análise de dados deRSPs, Quercia et al. [Quercia et al. 2012] estudaram como comunidades virtuais, obser-vadas nos sistemas analisados, se assemelham às comunidades da vida real. Os autorestestaram se teorias sociológicas estabelecidas de redes sociais da vida real são válidas nonessas comunidades virtuais.

Ao estudar o comportamento social de áreas específicas, uma das primeiras per-guntas que surgem é: o quão diferente uma da cultura é de outra? Sabemos que os hábitosalimentares e de bebidas são capazes de descrever fortes diferenças culturais. Com basenisso, em [Silva et al. 2014c] propomos uma nova metodologia para a identificação defronteiras culturais e semelhanças entre sociedades, considerando hábitos alimentares ede bebida. Para isso, foram usados check-ins do Foursquare para representar as prefe-rências do usuário em relação ao que se come e bebe localmente, por exemplo, em umadeterminada cidade. Estudamos como essas preferências mudam de acordo com a horado dia e localizações geográficas.

Essa análise surpreendentemente diz muito sobre as diferenças e semelhançasentre as culturas. A Figura 6.14 mostra o coeficiente de correlação de Pearson entreos check-ins dados em diferentes tipos de restaurantes para várias cidades ao redor domundo. Como podemos ver, as cidades de um mesmo país, onde os habitantes normal-mente possuem cultura e hábitos alimentares semelhantes, têm as correlações mais fortescom relação às preferências de restaurante. Além de preferências para as categorias dealimentos, também podemos ver diferenças nos horários em que as pessoas vão a restau-rantes e compartilham dados. As Figuras 6.15a e 6.15b19 mostram o número de check-insrealizados em restaurantes ao longo das horas do dia, durante os dias de semana, em di-ferentes cidades do Brasil e dos Estados Unidos. Estes resultados capturaram diferençasimportantes entre as culturas dos dois países: enquanto o jantar é a refeição principal paraos americanos, o almoço desempenha um papel mais importante nos hábitos alimentaresdos brasileiros. Isso mostra que aspectos temporais também podem fornecer informaçõesvaliosas sobre as diferenças culturais entre as cidades. Essas análises permitiram a pro-posição de uma metodologia para a identificação de culturas semelhantes, que pode ser

19Os valores são normalizados pelo valor máximo encontrado em qualquer hora para a cidade específica.



Nat

alR

ecife

Bel

o H

oriz

onte

Rio

Sao

Pau

loP

orto

Ale

gre

Man

aus

Mia

mi

New

Yor

kC

hica

goD

alla

sD

enve

rLa

s V

egas

San

Fra

ncis

coP

aris

Lond

onIs

tanb

ulM

osco

wB

angk

okK

uala

Lum

pur

Sin

gapo

reJa

kart

aB

andu

ngS

urab

aya

Man

ilaO

saka

Tok

yo

NatalRecife

Belo HorizonteRio

Sao PauloPorto Alegre

ManausMiami

New YorkChicago

DallasDenver

Las VegasSan Francisco

ParisLondonIstanbulMoscowBangkok

Kuala LumpurSingapore

JakartaBandungSurabaya

ManilaOsakaTokyo −1

−0.8

−0.6

−0.4

−0.2

0

0.2

0.4

0.6

0.8

1

Figura 6.14. Correlação entre preferências de restaurante em cidades distintasao redor do mundo [Silva et al. 2014a].

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Hora

# de

che

ck−

ins

Belo HorizontePorto AlegreSao Paulo

(a) Cidades brasileiras

2 4 6 8 10 12 14 16 18 20 220

0.2

0.4

0.6

0.8

1

Hora

# de

che

ck−

ins

DenverNova IorqueSao Francisco

(b) Cidades dos EUA

Figura 6.15. Número médio de check-ins em restaurantes durante dias de se-mana ao longo das horas do dia [Silva et al. 2014a].

aplicada em regiões de tamanhos variados, como países, cidades ou até mesmo bairross [Silva et al. 2014c].

As diferenças culturais utilizando dados de RSPs também foram estudadas porHochman et al. [Hochman and Schwartz 2012], que investigaram as preferências de co-res em fotos compartilhadas no Instagram. Os autores encontraram diferenças conside-ráveis entre imagens de países com culturas distintas. Na mesma direção, Poblete etal. [Poblete et al. 2011] investigou como o comportamento de divulgação de conteúdo noTwitter varia entre alguns países, bem como as possíveis explicações para essas diferen-ças. A investigação das diferenças culturais entre diferentes cidades e países é valiosa emmuitas áreas e pode auxiliar várias aplicações. Por exemplo, como cultura é um aspectoimportante por razões econômicas, a identificação de semelhanças entre os lugares que es-tão geograficamente separados pode ser necessária para empresas que possuem negóciosem um país e querem avaliar a compatibilidade de preferências entre diferentes mercados.

6.4.5. Detecção de Eventos e Interesses

A identificação de eventos e pontos de interesse através de dados de RSPs é beneficiadapela natureza de (quase) tempo real das RSPs. Eventos podem ser naturais, tais comoterremotos, ou não naturais, tais como a identificação/previsão de mudanças no mercadode ações. Por sua vez, um ponto de interesse é uma localização específica que alguémpode achar útil ou interessante, como um restaurante ou um estádio de futebol.

Em relação à detecção de eventos, Bollen et al. [Bollen et al. 2011] estudaram seos estados coletivos de humor derivados de mensagens do Twitter são correlacionadoscom o valor da bolsa Dow Jones ao longo do tempo. Seus resultados indicam que é possí-



vel obter uma boa precisão na previsão das mudanças diárias de alta e queda dos valores defechamento da dessa bolsa de valores. Gomide et al. [Gomide et al. 2011] analisou comoa epidemia de Dengue é refletida no Twitter e em que medida essa informação pode serusada na vigilância dessa doença. Os autores mostraram que o Twitter pode ser usado paraprever, espacial e temporalmente, epidemias de dengue. Sakaki et al.[Sakaki et al. 2010b]estudaram a interação em tempo real de acontecimentos no Twitter, por exemplo, terre-motos, e propuseram um algoritmo para monitorar mensagens no Twitter para detectar aocorrência de eventos.

Além de eventos que tendem a acontecer esporadicamente, toda cidade possuium conjunto de áreas que desperta um maior interesse dos residentes ou visitantes, asaqui denominadas pontos de interesse (PDI). Dentre os PDIs mais visitados, podemosmencionar os pontos turísticos da cidade. No entanto, nem todos os PDIs de uma cidadesão pontos turísticos. Por exemplo, uma área de bares pode ser bastante popular entre osresidentes da cidade, mas sem atrativos para turistas. Além disso, PDIs são dinâmicos, ouseja, áreas que são populares hoje podem não ser mais amanhã. Assim, uma aplicaçãoque emerge naturalmente a partir da análise de dados de algumas RSPs, por exemplopara compartilhamento de fotos ou localização, é a identificação de PDIs. Isso é possívelporque cada foto ou check-in representa, implicitamente, um interesse de um indivíduoem um determinado instante. Com isso, quando muitas fotos de um determinado localsão compartilhadas dentro de um certo intervalo de tempo, esse local pode ser um PDI.

Uma vantagem de usar RSPs para identificar pontos de interesse na cidade é quepodemos obter resultados robustos a mudanças dinâmicas. Ou seja, pelo fato das RSPsfornecerem dados dinâmicos, elas podem capturar automaticamente as alterações nos in-teresses das pessoas ao longo do tempo, ajudando a identificar rapidamente as áreas quepor ventura se tornem um PDI (por exemplo, devido à abertura de um novo restaurante)ou que deixem de ser popular.

A identificação de pontos de interesse em uma cidade foi investigada por Crandallet al. [Crandall et al. 2009], que mostraram como inferir a localização de uma foto semusar os dados geoespaciais. Na mesma direção, Kisilevich et al. [Kisilevich et al. 2010]usaram fotos georeferenciadas para analisar e comparar eventos temporais que acontece-ram em uma cidade, e também para classificar locais turísticos.

Além disso, em [Silva et al. 2013c] nós também apresentamos uma técnica paraidentificar PDIs e, a partir deles, identificar pontos turísticos. A técnica considera quecada par i de coordenadas (longitude, latitude) (x,y)i está associada a um ponto pi, querepresenta um dado compartilhado, e.g. uma foto. Nós começamos calculando distânciageográfica entre cada par de pontos (pi, p j) e agrupamos todos os pontos pi que estãopróximos uns dos outros. Para capturar os PDIs, usamos um modelo aleatório para ex-cluir grupos que possam ter sido gerados por situações aleatórias (ou seja, movimentosde pessoas aleatórias), e, portanto, não refletem a dinâmica da cidade. Para identificaros grupos, analisamos o número de compartilhamento de dados em cada grupo e usamossimples métodos estatísticos, como descrito em [Silva et al. 2013c]. Em seguida, separa-mos os pontos turísticos dos PDIs assumindo que turistas possuem rotas conhecidas nacidade (mais detalhes em [Silva et al. 2013c]).

Quando aplicada para a cidade de Belo Horizonte considerando dados do Fours-



quare e Instagram, essa técnica foi capaz de encontrar a maioria dos seus PDIs e pontosturísticos. Os resultados também mostram que diferentes RSPs podem fornecer dadoscomplementares, pois nenhuma RSP encontrou todos os pontos turísticos. Tais diferen-ças podem refletir mudanças na cidade durante o intervalo de tempo em que um datasetespecífico foi coletado. Por exemplo, durante a coleta do dataset Instagram1, Belo Ho-rizonte não estava recebendo jogos de futebol. Isso explica por que o estádio de futebolnão foi identificado como um PDI utilizando esse dataset. Por outro lado, a análise de umdataset do mesmo sistema coletado mais recentemente (Instagram2), identificou correta-mente o estádio como um ponto turístico importante da cidade. Isso ilustra como os dadosde RSPs podem capturar automaticamente alterações da dinâmica da cidade, sendo úteispara detectar locais incomuns e populares, bem como descobrir possivelmente padrõesinesperados.

6.4.6. Discussão

As RSPs oferecem informações atualizadas sobre locais, bem como opiniões e preferên-cias de seus usuários. Além disso, elas têm o potencial de tratar as questões acima menci-onadas em (quase) tempo real, atingindo um elevado número de regiões do globo. Nestaseção mostramos vários estudos que servem como exemplos de como trabalhar com dadosde RSPs. As informações obtidas por esses estudos podem ser úteis para o desenvolvi-mento de serviços e aplicações mais inteligentes nas áreas de interesse da comunidade doSBRC.

Por exemplo, entender o padrão de comportamento em determinados locais nacidade, bem como a identificação de comportamentos fora do padrão esperado, pode sermuito útil para o planejamento de carga de uma rede celular urbana. Estudos que visamoferecer soluções para desafogar a transmissão de dados móveis (mobile data offloading)podem ter grandes benefícios ao utilizar essas informações como uma ferramenta paradiminuir surpresas em demandas atuais, bem como novas demandas que podem surgir,já que a cidade está em constante mudanças. Várias outras oportunidades, bem como osdesafios associados a elas são discutidas na próxima seção (Seção 6.5).

6.5. Desafios e OportunidadesEsta seção apresenta diversos tópicos de pesquisa atuais relacionados com redes de sen-soriamento participativo. Para cada um deles serão também discutidos os desafios e asoportunidades de pesquisa.

6.5.1. Camadas de Sensoriamento

6.5.1.1. Definição

Uma camada de sensoriamento consiste de dados descrevendo aspectos específicos deuma localização geográfica. O conceito de camada de sensoriamento é bastante amplo:ele representa dados, com seus atributos, provenientes de uma determinada fonte de dados,por exemplo uma RSP particular. Cada RSP fornece acesso aos dados relacionados a certoaspecto de uma região geográfica predefinida (por exemplo, condições de tráfego, fotosde locais, etc.), e, com isso, cada RSP distinta pode ser representada como uma camada



Figura 6.16. Ilustração do compartilhamento de dados em três RSPs ao longo dotempo, resultando em camadas de sensoriamento [Silva et al. 2014b].

de sensoriamento [Silva et al. 2014b].

Além de RSPs, outras fontes de dados podem ser: dados disponíveis na Web nãogerados por usuários, por exemplo a condição climática fornecida pela empresa ClimaTempo20; ou dados de redes de sensores sem fio tradicionais. Discutimos aqui o conceitode camadas de sensoriamento para RSPs. No entanto todos os conceitos discutidos podemser utilizados para outras fontes de dados associadas a regiões geográficas predefinidas,com as adaptações necessárias.

A Figura 6.16 ilustra o conceito de camadas de sensoriamento. Essa figura mostradados compartilhados em três RSPs diferentes (p1, p2 e p3), por três usuários distintosem diferentes instantes de tempo. Como discutimos na Seção 6.2, esses dados devem sercoletados (por exemplo, usando uma API) e processados, passo que inclui as tarefas deanálise e padronização dos dados. Cada plano na figura representa uma camada de senso-riamento para uma região específica, por exemplo o centro de Belo Horizonte, com dadosprovenientes de três fontes distintas. Com isso, as camadas de sensoriamento ilustradassão: check-ins (r1), proveniente, por exemplo, do Foursquare; alertas de tráfego (r2), pro-veniente, por exemplo, do Waze; e fotos de lugares (r3), proveniente do Instagram, porexemplo.

Em uma camada cada dado possui os seguintes atributos: instante t em que odado foi compartilhado; localização a onde o dado foi compartilhado; especialidade s dacamada (e.g., uma foto ou um alerta sobre trânsito); e o id u do usuário que compartilhouo dado.

O uso de camadas de sensoriamento de forma independente pode ser muito útil.Por exemplo, uma camada contendo informações de trânsito pode possibilitar a identifi-cação em tempo real de rodovias com acidentes e buracos, cuja detecção é difícil comsensores tradicionais, mas torna-se mais factível quando os usuários participam do pro-cesso de sensoriamento. Os exemplos mencionados na Seção 6.4 também contribuempara esse ponto. No entanto, a grande motivação é realizar uma análise conjunta de múl-tiplas camadas para a construção de aplicações mais sofisticadas.

Sabemos que uma queixa comum dos habitantes das grandes cidades é o congesti-onamento. Com isso, uma aplicação que emerge naturalmente é uma que possui o objetivode inferir as causas de congestionamento, passo fundamental para tratar o problema. Esta

20http://www.climatempo.com.br.



Tabela 6.2. Fluxo de dados descrevendo a atividade de usuários em três RSPdiferentes: Foursquare, Waze e Instagram.

Fluxo de dados do FoursquareAtributos (m)

Tempo (t) Área (a) Usuário (u) Especialidade (s)T1 a1 1 “Times Square”T1 a1 2 “Times Square”T2 a2 1 “Fifth Av.”T3 a4 1 “Statue of Liberty”

Fluxo de dados do WazeAtributos (m)

Tempo (t) Área (a) Usuário (u) Especialidade (s)T1 a1 3 “Congestionamento”T2 a3 2 “Acidente”T2 a3 3 “Controle policial”

Fluxo de dados do InstagramAtributos (m)

Tempo (t) Área (a) Usuário (u) Especialidade (s)T1 a1 3 “dados da foto”T3 a4 1 “dados da foto”

não é uma tarefa fácil de realizar, e o resultado pode variar entre diferentes cidades, umavez que dependem de aspectos geográficos, culturais, econômicos, dentre outros. No en-tanto, a análise conjunta de diferentes camadas de sensoriamento na cidade poderia con-tribuir para essa aplicação. Por exemplo, poderíamos cruzar as informações fornecidaspelas camadas alertas de tráfego, check-ins e foto de lugares. A primeira camada fornecedados em (quase) tempo real sobre onde estão acontecendo congestionamentos, a segundafornece dados sobre os tipos de lugares localizados nas áreas dos congestionamentos, comisso é possível entender melhor as áreas de interesse, por exemplo, identificando o tipoda área. Finalmente, através da análise da camada fotos de lugares nós podemos obterevidência visual do que acontece em tempo real próximo das áreas durante os congestio-namentos. Ao analisar conjuntamente dados destas três camadas podemos detectar, porexemplo, carros bloqueando cruzamentos, e inferir as possíveis causas disso. Obviamente,outras camadas podem também ser utilizadas, tal como a condição do clima.

6.5.1.2. Arcabouço para a Integração de Múltiplas Camadas

Nesta seção apresentamos a ideia geral de um arcabouço para trabalhar com múltiplascamadas de sensoriamento definido por Silva et al. [Silva et al. 2014b]. Cada usuário upode compartilhar dados ilimitados em qualquer RSP p. Cada j-ésimo dado d j comparti-lhado na RSP pk possui o formato d pk

j =< t,m >, em que t refere-se ao instante em queo usuário u compartilhou o dado em pk e m é uma tupla contendo os atributos deste dado,ou seja, m = (a,u,s), como descrito anteriormente.

Os dados compartilhados em uma RSP podem ser vistos como um fluxo de dadosB. Definimos que um fluxo de dados Bpk é composto por todos os dados compartilhadospelos usuários em uma RSP pk em um determinado intervalo de tempo. Desta forma, Bpk

é utilizado para representar uma camada de sensoriamento rpk . A Tabela 6.2 mostra osdados das camadas de sensoriamento que foram compartilhados nas três RSPs considera-das na Figura 6.16. Observe que dados no mesmo fluxo podem ter a mesma informaçãode tempo, pois podem ter sido compartilhados por diferentes usuários simultaneamente.



Para trabalhar com camadas precisamos representá-las em um plano de trabalho,que contém uma ou mais camadas. Esse plano de trabalho representa uma combinaçãodos dados das camadas que desejamos trabalhar. Como efetuar essa combinação dosdados depende da funcionalidade da camada, do que ela captura. A abstração usadaaqui para representar uma combinação é um dicionário de dados M, que representa umacoleção de pares chave : valor. Esta estrutura foi escolhida por causa da sua simplicidade,o que facilita a compreensão dos conceitos. Mantenha em mente que outras estruturaspoderiam ser usadas.

Definimos que a função responsável para realizar esse passo chama-seCOMBINATION(F ,relation()), em que F = {Bp1, ...,Bpn} é um conjunto de fluxo dedados, e relation() é uma função que define a relação entre os dados dos fluxos de dadoscontidos em F . A função relation() define as chaves do dicionário M, bem como osdados que essas chaves irão referenciar, que são as demais observações do dado d pk

i nãoutilizadas como chave. A operação COMBINATION resulta em um dicionário M. Noteque algumas ferramentas da área de SIG (sistema de informação geográfica) poderiam serutilizados para apoiar o arcabouço discutido, por exemplo, no processo de combinação.

Nós ilustramos aqui um tipo de relação utilizada para agregar os dados por locais.Para exemplificar um plano de trabalho contendo os dados combinados por localidade,vamos considerar a atividade representada na Figura 6.16. O plano de trabalho M repre-senta essa atividade, onde M = {a1 : {dr1′

1 ,dr1′2 ,dr2′

1 ,dr3′1 },a2 : {dr1′

3 ,dr2′2 },a3 : {dr2′

3 },a4 :{dr1′

4 ,dr3′2 }}. Nesse plano de trabalho uma chave é representada por ai, que é uma área

única dentre todas as áreas de todos os dados compartilhados nas camadas consideradas:r1, r2 e r3. Já dr j′

j refere-se às observações não utilizadas como chave do dado d j da ca-mada r, ou seja < t,u,s >. Assim, todas as áreas únicas tornaram-se uma chave no planode trabalho M. Os dados compartilhados em um mesmo local foram agrupados e sãoindexados pela chave que representa o local. O plano de trabalho M, como descrito, estárepresentado na Figura 6.17. Veja que o plano de trabalho representa dados que foramcompartilhados em todas as camadas consideradas. A cor do símbolo que representa umdado d′

j indica de qual camada ele foi extraído, por exemplo, a cor vermelha é referente àcamada r1.

Figura 6.17. Combinação por localidade.

De posse de um plano de trabalho podemos aplicar operações para derivar ou-tras estruturas e também extrair conhecimento. Por exemplo, operações para habilitarou desabilitar uma camada, operações para a criação de grafo direcionado, entre ou-tras [Silva et al. 2014b].



6.5.1.3. Desafios e Oportunidades

Há vários desafios, bem como oportunidades, ao lidar com dados de várias camadas si-multaneamente, como os descritos a seguir.

1. Combinação de dados: A fim de realizar a combinação de dados, tal como menci-onado na seção anterior (Seção 6.5.1.2), nós temos que certificar que os dados sãoconsistentes em todas as camadas. Esta é uma condição obrigatória para a corretaextração de informações. Considere que queremos combinar duas camadas A e Bpor locais (todas as áreas únicas como chaves no plano de trabalho). O formato delocalização de dados na camada A é expresso em latitude e longitude, enquanto nacamada B a localização é fornecida como nome de rua ou avenida. Uma maneirade resolver essa inconsistência é realizando um processo de geocodificação, utili-zando, por exemplo, uma API própria para essa finalidade, como a disponibilizadapela Yahoo!21. Desta forma, os endereços oriundos da camada B serão transforma-dos em uma coordenada geográfica.

Outra questão que pode acontecer ao combinar dados por localização é com relaçãoàs áreas que se sobrepõem parcialmente. Como definir uma chave neste caso? Umapossibilidade é considerar várias chaves, uma para a intersecção entre essas áreas,e uma ou duas22 para as áreas não sobrepostas.

A combinação por usuários, ou seja, todos os usuários únicos são uma chave noplano de trabalho, pode ser um problema em RSPs, porque o mesmo usuário podeparticipar em diferentes camadas com diferentes identificadores. Vamos supor quequeremos combinar dados dos usuários compartilhados na camada de check-ins ena camada foto de lugares. Como estamos lidando com sistemas independentes, osusuários podem possuir identificações diferentes. Uma forma de tentar contornaresse problema é verificar outras redes com o intuito de mapear o ID do usuário deuma camada em outra. Por exemplo, os usuários do Foursquare e Instagram tendema ser também usuários do Twitter. Desta forma, a chave do processo de combinaçãopoderia ser a identificação usada no Twitter.

2. Validade dos dados: Diferentes camadas podem se referir a dados válidos paradiferentes intervalos de tempo. Isso é natural porque algumas fontes de dados for-necem dados em (quase) tempo real, outras não. Por exemplo, um alerta no Wazerefere-se a uma situação de trânsito que pode não existir cinco minutos mais tarde.No entanto, dados do censo geralmente são válidos por um grande intervalo detempo, meses ou anos, até o próximo censo ser publicado. Temos de estar cientesde todas essas questões ao projetar novas aplicações.

3. Volume de dados: Se não temos dados significativos para uma determinada ca-mada, a sua utilização pode não levar à extração de informações corretas. Diferen-tes fontes de dados podem apresentar características diferentes para esse problema.Por exemplo, em uma RSP muitos fatores influenciam o volume de dados, dentre

21https://developer.yahoo.com/boss/geo.22Se uma área não está completamente dentro de outra.



eles, aspectos geográficos, culturais e econômicos, como discutido na Seção 6.3. Agranularidade de áreas também pode influenciar algumas fontes de dados. Se consi-derarmos, por exemplo, dados das tradicionais redes de sensores sem fio podemosnão ter dados para uma metrópole inteira, por limitações de escalabilidade.

4. Modelagem: Temos ainda oportunidades com relação à modelagem das camadasde sensoriamento, pois numa mesma camada as entidades podem possuir relaçõesdistintas entre elas. Para ilustrar essa oportunidade considere a camada de check-ins. Como ilustramos anteriormente, essa camada pode representar a mobilidadeurbana considerando a relação entre lugares e pessoas, sendo útil para entender,por exemplo, a frequência de transição entre diferentes lugares (entidades). Outrapossibilidade é modificar a modelagem do problema, para, por exemplo, estudar aspreferências de pessoas. Nesse caso, a entidade a ser analisada passa a ser o usuário.Note que dados de uma mesma camada podem ser modelados de formas distintaspara responder perguntas diferentes. O arcabouço que discutimos nesta seção ofe-rece suporte básico para essa questão. No entanto, existem várias oportunidadespara extensão desse arcabouço para oferecer serviços mais sofisticados.

Em resumo, observe a importância de um processo de caracterização, como mos-trado na Seção 6.3. Temos de conhecer as propriedades das camadas que queremos utili-zar, a fim de verificar se a sua utilização simultânea com outras pode levar à extração deinformação que desejamos. A função relation() informada como parâmetro para a funçãoCOMBINATION encapsula a solução escolhida para lidar com dados heterogêneos, queé dependente da aplicação. Se nenhuma solução for encontrada para eliminar a inconsis-tência entre os dados de duas camadas, então elas não podem ser usadas conjuntamente.

6.5.2. Análise da Dinâmica Temporal das Redes de Sensoriamento Participativo

6.5.2.1. Definição e Iniciativas

Como foi mostrado anteriormente, os dados compartilhados em RSPs podem ser apro-veitados para diferentes finalidades, sendo útil para diversas aplicações, por exemplo,para recomendação de pontos de interesses. No entanto um aspecto pouco exploradona análises dos dados de RSPs é o temporal. Nesse contexto, a análise de característi-cas temporais permite aprimorar tais aplicações, bem como gerar novas oportunidades depesquisa [Gao et al. 2013, Yuan et al. 2013].

A maioria dos estudos encontrados na literatura consideram que os dados compar-tilhados por usuários formam RSPs estáticas, sendo a dinâmica temporal negligenciada.Isso pode acarretar em perda de informações importantes. Por exemplo, enquanto duasregiões de uma cidade podem apresentar comportamento similar nos dados agregados du-rante um dia, elas podem ter diferenças quando uma perspectiva temporal é consideradana análise das atividades mais populares em cada turno. Nesse sentido, a seguir são apre-sentados alguns esforços que tentam explorar a dimensão temporal na análise de dados deRSPs.

Bannur e Alonso [Bannur and Alonso 2014] analisaram dados de check-in do Fa-cebook para compreender a participação temporal dos usuários em diversas categorias de



locais (e.g., restaurantes, cinemas, get-away23). Os autores definiram uma métrica, cha-mada polaridade, que é uma relação entre o número de check-ins de uma categoria emuma dada região em uma estação do ano e o número total de check-ins nessa mesma re-gião o ano inteiro. A Figura 6.18 mostra a variação da polaridade da categoria get-awayentre os estados dos Estados Unidos ao longo das quatro estações do ano. A polaridadeé representada por um mapa de calor. A intensidade da polaridade varia da mais baixa,cor clara, para a mais alta, cor escura. Como podemos observar, no inverno e primavera,estados com temperaturas elevadas ao longo da costa oeste, regiões da Flórida e Havaítêm uma polaridade muito maior em comparação com os estados da costa leste. Por outrolado, no verão, estados com temperatura baixa como Alaska e Montana aparecem comoestados com alta polaridade. Este tipo de análise é interessante para explicar determinadoscomportamentos humanos baseados em fenômenos sazonais. Por exemplo, no outono, oestado de Nebraska possui polaridade alta. Nebraska é sujeito a tornados e trovoadas du-rante o verão e primavera, enquanto no inverno sofre com tempestades de gelo, de formaa influenciar no comportamento humano para a categoria get-away.

Figura 6.18. Visualização de checkins para a categoria get-away emcada estado dos Estados Unidos ao longo das quatro estações do ano[Bannur and Alonso 2014].

Zhang et al. [Zhang et al. 2013] analisaram atividades urbanas a partir de dadosdo Foursquare considerando a dinâmica temporal. Para isso, eles adotaram um algoritmopara detecção de grupos de atividades com características similares, considerando as ca-tegorias de locais do Foursquare. A Figura 6.19 mostra o resultado da aplicação do al-goritmo com os dados agregados (Figura 6.19a) e com dados particionados em períodosdo dia (manhã, tarde e noite, Figuras 6.19b, 6.19c 6.19d, respectivamente). Na Figura6.19a, o grupo C2 possui a categoria Food como atividade predominante, enquanto nasFiguras 6.19b, 6.19c 6.19d, observa-se uma separabilidade maior na detecção de grupos,de forma que algumas células24 no desagregado possuem rótulos de grupos diferentes aolongo do dia que podem possuir outras atividades predominantes. Por exemplo, a ativi-dade Food pode não ser tão ativa no período da tarde, mas sim, nos períodos da manhãe noite, de forma que na visão agregada não se perceba essa diferença. Essa abordagemé interessante para mostrar que determinadas atividades são pertinentes em um determi-nado período do dia, mas quando analisadas de forma agregada podem não ser relevantesou podem não capturar o real comportamento dos usuários.

Outro exemplo é a técnica City Image que apresentamos na Seção 6.4.2. No exem-plo da Figura 6.13, a perspectiva temporal utilizada é o particionamento dos dados em dias

23Categoria que representa locais como praias, montanhas e parques.24Os autores dividiram a região em células.



Figura 6.19. Visualização dos grupos comparando dados agregados e por turnosda cidade de Nova Iorque[Zhang et al. 2013].

de semana/final de semana durante o dia e a noite, a partir disso foi feita uma análise dosdados por partições. Podemos perceber com o auxílio dessas imagens que existe variaçãosignificativa entre dia e noite nas duas cidades analisadas. Além disso, a imagem agregada(sem considerar partições) é bastante diferente das desagregadas, como foi mostrado porSilva et al. [Silva et al. 2012].


Os trabalhos descritos anteriormente fornecem indícios das vantagens da utilização deinformação temporal dos dados obtidos de RSPs. No entanto, se por um lado investigar adinâmica temporal de uma RSP é uma oportunidade para obtenção de informações maispróximas da realidade do comportamento da rede, por outro, surgem novos desafios aoadicionarmos uma dimensão temporal ao estudo, como os descritos a seguir:

1. Informação temporal: Uma dificuldade inicial é como representar e armazenara informação temporal. Como os dados podem ser oriundos de várias fontes, nosdeparamos com problemas relacionados à inconsistência, redundância e granulari-dade para extrair a informação temporal relevante. Além disso, há questões abertasquanto a validade da informação obtida, ou seja, por quanto tempo essa informaçãopoderá ser útil e a que frequência deve ser atualizada;

2. Janelas de tempo: Trabalhos que analisam a questão temporal geralmente frag-mentam os dados em intervalos de tempo (e.g., manhã, tarde e noite) denominadosjanelas. No entanto, a definição adequada do tamanho da janela é um problema,pois é necessário definir um tamanho de janela que capture dinâmicas relevantes.Nesse caso, existem inúmeras oportunidades para novas abordagens que conside-ram janelas com tamanhos flexíveis;

3. Participação dinâmica: Como a estrutura de uma RSP é composta por nós autô-nomos (seres humanos), ela é sensível à participação desses nós ao longo do tempo.Isso traz uma gama de desafios relacionados com a evolução da participação dosusuários nessas redes. Exemplos são: identificação de comportamentos periódicos,detecção de outliers e rastreamento de atividades. Nessa direção existem váriasoportunidades para o desenvolvimento de novas técnicas/abordagens;



4. Modelagem: Geralmente, dados de uma RSP são representados como um conjuntode entidades, por exemplo, usuários ou PDIs (pontos de interesses), e suas relações(e.g., transições ou comunicação). Como a contribuição desses dados pode variarmuito ao longo do tempo um modelo baseado em grafos estáticos pode não ser su-ficiente para capturar essa dinamicidade. Por exemplo, dados obtidos a partir doFoursquare possuem informações espaço-temporais, tais como posicionamento dosusuários e os momentos de interação. Portanto, um desafio é modelar a dinâmicaespaço-temporal a fim de entender melhor, por exemplo, diversos aspectos dessaparticipação dos usuários. Nesse sentido, Grafos Temporais [Kostakos 2009] surgecomo alternativa promissora que pode ser utilizada para entendimento da dinâmicaespaço-temporal. Em um Grafo Temporal, as relações entre as entidades podemser modeladas como arestas que podem ser criadas e destruídas ao longo do tempo.Por exemplo, entender aspectos temporais de interações entre usuários com cer-tos locais na cidade. Dessa forma, utilizando grafos temporais para modelar umaRSP, podemos aplicar tanto conceitos de grafos (e.g., componentes conectados ecaminhamento) como medidas de centralidade (e.g., betweenness, closeness) paraauxiliar no entendimento da dinâmica das RSPs [Nicosia et al. 2013].

5. Técnicas de visualização: A adoção de técnicas de visualização que forneçam oentendimento correto do comportamento da rede é fundamental para auxiliar nastomadas de decisões. Dessa forma, visualizações que exploram a dinâmica tempo-ral de dados de RSPs são de suma importância. Por exemplo, uma visualizaçãoadequada das transições dos usuários na cidade ao longo do tempo é bastante útilpara urbanistas e outros profissionais que precisam tomar decisões relacionadas aoplanejamento urbano.

A dinâmica espacial em RSPs tem sido alvo de estudo em diversos trabalhos pre-sentes na literatura. No entanto, a dinâmica temporal é pouco explorada. Nessa seção,mostramos alguns dos principais desafios e oportunidades de pesquisas que considerama dinâmica temporal em estudos de dados de RSPs. Acreditamos que entender a dinâ-mica temporal dos usuários é essencial para a construção de novas aplicações, bem comomelhorar os serviços fornecidos atualmente.

6.5.3. Mecanismos de Incentivo nas RSPs

6.5.3.1. Definições e Iniciativas

O comportamento social do ser humano, como egoísmo, altruísmo e cooperação / colabo-ração25, têm sido extensivamente estudados na filosofia, biologia, psicologia, economia eno contexto da ciência da computação. O egoísmo pode ser definido como o ato de benefi-ciar somente a si próprio, ao invés do outro. Por outro lado, o comportamento altruísta ougeneroso leva a pessoa a favorecer aos outros em detrimento de si próprio [Levine 1998].A colaboração ocorre quando um indivíduo dedica um esforço, que implica em um custo,em alguma atividade coletiva de forma que o benefício obtido seja maior que o custo para

25Mesmo sabendo que o conceito de cooperação vai além do significado de colaboração, neste minicursoesses dois termos são tratados como sinônimos.



todos os participantes da atividade [Bowles and Gintis 2003]. A diferença da colabora-ção para o altruísmo é que na colaboração o indivíduo espera algum benefício por tercolaborado.

Um ponto fundamental para as RSPs é a colaboração dos usuários, pois as apli-cações em uma RSP dependem de que os usuários estejam dispostos a coletarem, pro-cessarem e transmitirem os dados sensoriados [Lee and Hoh 2010]. A colaboração entreos participantes de uma RSP reflete diretamente na qualidade e quantidade dos dadossensoriados e, consequentemente, na melhoria dos serviços oferecidos pelas RSPs.

No entanto, como estas aplicações consomem recursos do dispositivo do usuá-rio, o mesmo pode ser relutante em contribuir com a rede. Diversos são os motivos quepodem fazer um usuário usufruir, porém não colaborar com a RSP, tais como pouparbateria, evitar gastos com a transmissão de dados, ou mesmo por questões de privaci-dade [Lee and Hoh 2010].

Deste modo, mecanismos de incentivo visam aumentar a motivação dos usuáriospara colaborarem com a RSP. A motivação para a colaboração pode ser extrínseca, naqual os participantes recebem uma recompensa direta pela participação, ou intrínseca, naqual os participantes devem ser satisfeitos psicologicamente [Kaufmann et al. 2011].

Nos últimos anos, foram propostos dezenas de mecanismos de incentivo e reali-zados diversos experimentos para entender o comportamento cooperativo. Estes mecanis-mos podem ser propostas de pagamento ao usuário por contribuir na rede ou a utilizaçãode técnicas de jogos para engajar o usuário.

Gao et al. [Gao et al. 2015] fizeram uma análise de trinta mecanismos de incentivoteóricos, de oito estudos experimentais e nove implementações de mecanismos de incen-tivo aplicados as RSPs nos últimos dez anos . Os autores classificaram os mecanismos deincentivo como monetários (extrínseco) e não-monetários (intrínseco). Os estudos experi-mentais mostraram que pagar um valor de acordo com o esforço da tarefa, a combinaçãode estratégias e adição de um ambiente de disputa apresentaram melhores resultados.

Como os mecanismos extrínsecos podem recompensar o participante por meio depagamentos reais, virtuais ou outros prêmios, neste minicurso iremos nos referir a estesmecanismos como baseados em recompensas. Os mecanismos intrínsecos baseiam-se emtransformar a tarefa de sensoriamento em uma tarefa mais prazerosa e estimulante parao usuário, adicionando elementos comuns em jogos, como elementos de disputa entreos usuários. Por isto, abordaremos estes mecanismos como baseados em gamificação26

[Deterding et al. 2011].

6.5.3.2. Colaboração do Usuário nas RSPs

A colaboração no contexto das RSPs depende de uma relação entre o custo e o benefíciopara participar da mesma [Fitzek et al. 2013]. Para Fitzek et al., a colaboração ocorrerásempre que o usuário tiver a sensação que o benefício é superior ao custo de colaborar.

26A utilização destes elementos característicos de jogos para tornar a realização de tarefas mais prazero-sas é conhecido na literatura como gamificação.



Este benefício pode ser desde a qualidade das informações obtidas até ao sentimentoaltruísta de contribuir com a RSP.

A Figura 6.20 ilustra um cenário de utilização de um usuário colaborativo em umaRSP. O usuário acessa as informações de uma RSP por meio da rede móvel (3G por exem-plo), enquanto obtém sua localização utilizando a rede GPS e coleta novas informações,as quais serão transmitidas para a RSP. Para realizar esta tarefa, podemos listar comocustos: o consumo de energia, a transmissão de dados pela rede móvel e o esforço pararealizar a tarefa de sensoriamento durante um tempo. Podemos listar como benefíciospara o participante: obter informações atualizadas em tempo real e o sentimento de estarajudando outros participantes da rede (em caso de usuário altruísta). Por outro lado, umusuário egoísta ou que tenha restrições de recursos poderia obter as informações da RSPsem colaborar com novas informações para a mesma.

Figura 6.20. Etapas envolvidas para a coleta de informações e transmissão dosdados sensoriados para as RSPs.

Existem ainda as situações nas quais o benefício recebido por colaborar com aRSP não é claro para o participante. Em Burke et al. [Burke et al. 2006], os autores citamcomo exemplos de RSPs para a coleta massiva de informações sobre poluição e sobrea saúde do indivíduo. Nestes exemplos, o participante não tem acesso em tempo realsobre as informações agregadas e os beneficiários das informações coletadas seriam osagentes públicos e centros de saúde, respectivamente. Nestas situações, os mecanismosde incentivo funcionam como "motivadores"para os usuários participarem do sistema.

6.5.3.3. Mecanismos de Incentivo Baseados em Recompensa

Os mecanismos de incentivo baseados em recompensa partem do pressuposto de que osparticipantes não contribuirão ou deixarão de contribuir com a RSP se os benefícios foremmenores que suas expectativas [Lee and Hoh 2010].

Existem mecanismos que visam permitir que o usuário participe da decisão sobrea tarefa que irá realizar e sobre o pagamento que irá receber da RSP. Outros visam me-lhorar a qualidade dos dados obtidos e minimizar os custos com sensoriamento. Podemosmencionar também mecanismos em que o usuário negocia com a plataforma o valor da re-compensa pelos dados sensoriados antes de enviá-los e, ainda, os que a plataforma decidequanto irá pagar pelos dados já enviados pelo usuário.

Yang et al. [Yang et al. 2012] propuseram dois incentivos de mecanismo: MSen-sing Platform-Centric e MSensing Auction. No MSensing Platform-Centric, a RSP anun-cia uma certa recompensa para uma determinada tarefa que será dividida entre os partici-



pantes da rede, proporcionalmente ao tempo em que cada participante se dedicou à tarefa.Um problema deste modelo é que com o aumento no número de participantes ativos, arecompensa recebida por cada um diminuirá.

No MSensing Auction, a plataforma anuncia um conjunto de tarefas e o usuárioescolhe um subconjunto de sua preferência. Para cada tarefa que o usuário selecionou,ele submete uma tupla (tarefa-lance) para a plataforma, em que o “lance” é o valor darecompensa que ele deseja para executar a tarefa. Após receber as ofertas dos usuários, aplataforma decide um conjunto de usuários como os vencedores de um leilão para executaras tarefas. Um problema encontrado neste tipo de mecanismo é a explosão dos custos deincentivo [Lee and Hoh 2010]. Os custos que o provedor terá com sensoriamento podeminviabilizar o mecanismo. Além disto, mesmo que um usuário receba um pagamento pelavenda dos dados, o mesmo pode ficar desmotivado ao longo do tempo e abandonar a RSP.

Para tentar contornar este problema, diversos trabalhos modelam os mecanismosde incentivo baseados em teoria dos jogos [Xie et al. 2009, Lee and Hoh 2010, Yang et al. 2012].Todos esses trabalhos visam atingir o equilíbrio do sistema, ou seja, maximizar o ganhodo usuário, enquanto minimizam os custos para a plataforma.

Reddy et al. [Reddy et al. 2010] realizaram uma série de experimentos em pe-quena escala para avaliar o efeito de pagamentos para realização de sensoriamento par-ticipativo. Os autores concluem que os incentivos funcionaram melhor quando os micropagamentos foram combinados com outros fatores, como altruísmo do usuário e quandohavia competição entre os participantes. Além disto, mostraram que um pagamento justopara todos os participantes os mantinham mais motivados do que micro pagamentos.

De fato, pagamentos podem ser até contra produtivos em certos casos como de-monstrou Kamenica [Kamenica 2012]. Esse autor revisou diversos estudos realizadosno campo da psicologia e economia sobre o efeito de pagamentos como mecanismos deincentivos. Em muitos casos, pagar um valor alto ou pagar um valor muito baixo, oumesmo oferecer muitas formas de pagamento a um participante, mostrou-se contraprodu-cente para induzi-lo a um comportamento colaborativo.

6.5.3.4. Mecanismos de Incentivo Baseados em Gamificação

Gamificação, ou gamification, pode ser definido como o uso de elementos e design dejogos em contextos não relacionados a jogos [Deterding et al. 2011]. Elementos e de-sign de jogos são o uso dos elementos comuns aos jogos tradicionais. Exemplos desteselementos são: tabelas de pontuação e classificação; troféus ou medalhas para premiaros usuários que alcançam determinado objetivo; desafios; avatares; níveis de dificuldade;progressão; e grafos sociais, ver o que os “amigos” estão fazendo ou como evoluem natarefa, de forma que quem executou mais tarefas ou tenha coletado mais dados tenhamuma visibilidade maior no ranking.

O que difere a gamificação de um jogo tradicional é o seu objetivo. A gamificaçãousa elementos de jogos para tarefas não relacionadas ao jogo, mas sim para um outro obje-tivo [Werbach and Hunter 2012]. Essas tarefas podem ser, por exemplo, com o propósitode melhorar uma habilidade, incentivar a prática de exercícios, ou no contexto de uma



RSP, participar ativamente da rede durante mais tempo.

Como exemplos de redes de sensoriamento participativo que utilizam gamificaçãopara incentivarem a participação dos usuários, podemos citar o Waze. O Waze apresentadiversas informações de interesse para o usuário como alertas de trânsito, o preço docombustível nos postos próximos, além do tradicional cálculo de rotas. Para que estasinformações estejam atualizadas, ele requer a participação ativa do usuário, ou seja, oparticipante do Waze deve informar manualmente a situação que ele observa (e.g., umacidente). Com isso, no Waze, os elementos de jogos são representados pelo uso de avata-res e do sistema de pontuação. O objetivo é melhorar o volume de dados compartilhados,bem como a qualidade da informação de trânsito para todos os usuários.

Os motivos que levam um usuário a colaborar ativamente com o Waze, comoavisar um acidente de trânsito para outros condutores, podem variar do simples altruísmoà motivação gerada pela gamificação do mesmo. Visto que colaborar com o Waze gerauma pontuação que serve para melhorar o status do participante na RSPs.


Além dos desafios técnicos inerentes às RSPs, engajar os usuários a se tornarem partici-pantes ativos nas RSPs trazem também desafios sociais e psicológicos. Um mecanismode incentivo é eficiente se ele recruta mais participantes para RSP e mantém esses osparticipantes ativos no sistema. Nesta seção, resumimos os desafios nas propostas demecanismos de incentivos para as RSPs:

1. Custos nos mecanismos baseados em recompensa: Para que o desenvolvimentode mecanismos de incentivo monetários sejam eficientes, deve-se considerar os cus-tos para a plataforma da RSP e os ganhos para o participante da rede. Estes meca-nismos utilizam um custo máximo para a plataforma RSP que será pago aos parti-cipantes ativos da rede. No entanto, encontrar e decidir um valor que minimize ocusto para plataforma e, ao mesmo tempo, motive o usuário requer investigaçõesfuturas [Gao et al. 2015].

2. Uso de múltiplas estratégias: A maioria das propostas para incentivar a colabora-ção nas RSPs focam em apenas uma estratégia. Porém, como Reddy et al.[Reddy et al. 2010] observaram em seus experimentos, a utilização de mais de umaestratégia simultaneamente pode apresentar melhores resultados.

3. Validação das propostas: A maioria das propostas de mecanismos de incentivoutilizam uma validação teórica ou pequenos experimentos controlados. No entanto,estes experimentos podem não predizer com alta precisão a participação dos usuá-rios ao longo do tempo na plataforma. No caso de mecanismos baseados em gamifi-cação, embora diversas RSPs de sucesso no mercado utilizem este conceito, aplicaruma estratégia com sucesso prévio em uma nova RSP não é garantia que funcionará.Talvez exista alguns elementos que funcionem para determinados tipos de RSPs eoutros não.



6.5.4. Qualidade de Dados

6.5.4.1. Definição e Iniciativas

A qualidade de dados é um tópico amplamente estudado pela comunidade científica, desdea definição de métricas para avaliar qualitativamente um determinado dado até soluçõespara garantir a geração e recuperação de um dado com qualidade. A qualidade diz respeitoao atendimento dos requisitos estabelecidos para um sistema e, com isso, são definidasmétricas que sumarizam características dos dados, com o intuito de avaliar se os requisitosdefinidos foram contemplados.

Em geral, como ilustrado na Figura 6.2, os dados coletados de RSPs são, apósprocessados, utilizados para a extração de informações contextuais, que são fundamen-tais para os sistemas sensíveis ao contexto [Dey and Abowd 2000]. A qualidade destesdados é avaliada conforme a qualidade esperada para a informação contextual que elesproporcionam, definida pelo conceito de Quality of Context (QoC).

Buchholz e Schiffers [Buchholz and Schiffers 2003] definem QoC como qualquerinformação que descreva a qualidade do contexto inferido. Os autores também discutema diferença entre QoC com os termos Quality of Service (QoS) e Quality of Device (QoD).QoS se refere a qualquer informação que descreva o quão bem um serviço opera. JáQoD significa qualquer informação sobre as propriedades técnicas e as capacidades deum determinado dispositivo. De acordo com esta diferenciação, são propostas as seguin-tes métricas de QoC: precisão, probabilidade de corretude, confiabilidade, resolução eatualização.

Em um cenário de RSP, a precisão de um dado está relacionada a o quão bemele reflete o estado atual de um determinado fenômeno ou localidade. A probabilidadede corretude denota a probabilidade de um determinado dado estar correto. Esta métricapode ser vista como uma estatística que reflete um conhecimento a priori do dado oudo usuário que o gerou. A Confiabilidade é similar à probabilidade de corretude, mas éutilizada para classificar a qualidade do usuário que gerou o dado. A Resolução denota agranularidade da informação, que, como discutido na Seção 6.3, pode representar os deta-lhes de cobertura de uma determinada região. Por fim, a atualização descreve a idade deum dado, sendo essencial para se verificar a validade de um dado quando existe requisitosde tempo real.

Na mesma direção, Li et al. [Li et al. 2012] estenderam as definições de QoC paraavaliar a qualidade de dados oriundos de ambientes pervasivos. Ao investigarem os de-safios de se prover dados com qualidade nestes ambientes, foram propostas três métricaspara avaliar os dados e suas fontes geradoras: circulação, disponibilidade e validade. Acirculação está relacionada com a métrica de atualização, previamente discutida. Ela re-presenta a utilidade temporal do dado, desde o momento que ele é criado até que torne-seinútil. A disponibilidade mede a capacidade de uma entidade gerar um dado que, no con-texto de RSPs, por exemplo, pode ser encarado como a esperança de que um determinadodado tenha sido gerado por um usuário, quando se precisa de uma informação atualizadasobre uma determinada região. A validade é definida como um conjunto de regras quepodem ser usadas para validar o dado compartilhado, de acordo com um conhecimentoprévio do tipo de dado e do padrão comportamental de seus usuários.




Podemos resumir os principais requisitos esperados para os dados gerados nas RSPs emdois aspectos: (i) a confiabilidade que se tem no dado; e (ii) a credibilidade de seususuários. Desta forma, alguns dos principais desafios que podem afetar a qualidade dosdados em uma RSP são:

1. Representatividade da amostra: Este desafio é relacionado ao quão representativouma amostra é sobre um determinado fenômeno, baseado na quantidade dos dadoscoletados. Por causa da sua alta relevância, esse é um ponto bastante discutidoem vários trabalhos que lidam com amostragem de dados. Do ponto de vista dasRSPs, como discutido na Seção 6.3, os dados coletados representam uma parcela dapopulação de uma determinada cidade, por exemplo. As informações extraídas sãobaseadas nesta amostra. Dependendo da amostragem, é possível que as informaçõesinferidas não representem bem o fenômeno analisado. Por isso, como mencionamosanteriormente, antes de tirar algumas conclusões com amostras de dados de RSPsé preciso contrastá-las com resultados obtidos utilizando outras fontes (e.g., dadoscoletados de forma offline).

2. Erros de leitura: Outro desafio que pode afetar a precisão dos dados das RSPs sãopossíveis erros de leitura de equipamentos. Por exemplo, um GPS pode estar malcalibrado e gerar dados cuja imprecisão está além do limite aceitável para este tipode dado. Embora alguns erros possam parecer totalmente toleráveis, dependendodos requisitos de uma aplicação, é possível que os limites mais restritos de precisãosejam fundamentais para sua correta operação.

3. Subjetividade de interpretação: Este desafio é relacionado com diferentes signifi-cados que podem existir sobre um dado para o usuário que o gerou e para aquele queo utilizará. Por exemplo, é possível encontrar dados que foram mal classificados ecompartilhados em uma RSP. O Foursquare, por exemplo, permite a definição dacategoria de um novo local adicionado e essa definição pode não ser a mais apropri-ada, devendo ser corrigida pelo sistema posteriormente. Outro exemplo é o caso doWeddar, sistema que permite aos usuários compartilharem suas interpretações doclima atual. Enquanto um usuário pode interpretar uma determinada temperaturado interior de sua casa, outro usuário pode interpretar uma temperatura em um par-que da mesma região. Nesse caso, o relato desses dois usuários pode ser bastantediferente.

4. Ausência de estrutura: Os dados compartilhados em RSPs, em alguns casos, sãode texto livre, não apresentando uma estrutura semântica nem codificadas. Essaliberdade dada aos usuários permite que eles postem o que querem, mesmo infor-mações incorretas, e em diferentes formatos. Por exemplo, um usuário poderiadescrever um acidente em outra língua ou utilizando gírias através de algum micro-blogging como o Twitter. Com isso, o processamento dos dados se torna complexoe suscetível a erros, uma vez que há a possibilidade de dados distintos serem con-fundidos como um mesmo dado, ou ainda a duplicidade de dados, isto é, dados



idênticos serem identificados como distintos devido a diferenças no preenchimentodos campos.

5. Poluição dos dados: A poluição dos dados diz respeito à possibilidade dos dadosestarem incorretos devido a um comportamento malicioso dos usuários[Coen-Porisini and Sicari 2012, Mashhadi and Capra 2011]. Podemos encontrar com-portamentos maliciosos em várias esferas sociais, e o mesmo também pode ocorrernas RSPs. Por exemplo, usuários de sistemas para compartilhamento de alertas detrânsito, como o Waze, podem gerar falsos alertas de congestionamento ou aciden-tes, com o intuito de incentivar os demais usuários a não utilizar determinadas viasde seu trajeto. Este comportamento malicioso poderá ocasionar em falsos positivosna detecção de um dado comportamento social ou eventos.

Um importante tópico de pesquisa que é afetado pela qualidade dos dados emRSPs diz respeito às técnicas de processamento e extração de conhecimento destes dados.Uma possível abordagem para lidar com este problema é modelar os dados como umasérie temporal e extrair conhecimento por meio de técnicas de processamento de sinais[Lathi and Green 2014]. Contudo, em alguns casos, os dados gerados pelas RSPs po-dem não seguir um padrão constante que facilite tal processamento. Como mencionamosanteriormente, os dados das RSPs estão sujeitos aos problemas de subjetividade de inter-pretação e da ausência de estrutura, podendo acarretar em erros durante a aprendizagemde padrões e demais propriedades de um determinado fenômeno.

Uma interessante abordagem na direção da resolução destes conflitos de interpreta-ção é apresentada em [Georgescu et al. 2014]. Os autores melhoraram alguns algoritmosde classificação de dados utilizando o serviço Mechanical Turk (MTurk)27, da Amazon.Nesse serviço os usuários são recompensados financeiramente para as tarefas cumpridas.A agregação do processamento computacional com estas unidades de trabalho humanas(Human Intelligence Task) oferecem importantes oportunidades de pesquisa para o cená-rio de sensoriamento participativo, principalmente nesse desafio discutido.

Outra oportunidade é avaliar a confiabilidade de um determinado usuário em umaRSP. Dados gerados por usuários mais confiáveis provavelmente terão maior qualidade.Uma possível direção nesse sentido está relacionada com a identificação de padrões com-portamentais dos usuários das RSPs. Como apresentado na Figura 6.9, quando agregadasgrandes quantidades de dados, é possível, claramente, identificar padrões de comporta-mento no compartilhamento de dados durante diferentes dias da semana. Assumindo queeste conhecimento prévio seria uma referência do comportamento esperado dos usuáriosde uma dada RSP, uma possibilidade seria comparar o comportamento de um determinadousuário com este padrão de referência. Por exemplo, usuários que possuem um padrão decompartilhamento muito distinto dos demais poderia representar um usuário não confiável(e.g., um robô malicioso).

Essa abordagem discutida acima, pode ser caracterizada como uma espécie defiltragem colaborativa [Adomavicius and Tuzhilin 2005]. Esta é uma estratégia utilizadapor sistemas de recomendação quando não se possui um conhecimento prévio do usuário

27http://www.mturk.com



ao qual deverá se recomendar um item. Por exemplo, utilizando as preferências de outrosusuários similares a este, assumindo de que suas preferências também sejam similares.

Outras alternativas clássicas para lidar com a questão da qualidade dos dados sãoos mecanismos de reputação, que visam aumentar a credibilidade com o bom comporta-mento dos usuários. Mashhadi e Capra [Mashhadi and Capra 2011] propõem uma técnicaque estima a qualidade das contribuições de um usuário considerando sua credibilidade.Nesse trabalho, eles consideram a contribuição de pontos de interesse pelos usuários e de-finem funções de regularidade, que diz respeito ao padrão de mobilidade destes usuários,e de reputação, que considera a sua confiabilidade baseada nas suas contribuições anteri-ores com o sistema. A viabilidade desta proposta é baseada em estudos que demonstramque usuários urbanos exibem um alto nível de regularidade em suas atividades diárias.Essa regularidade, baseada na frequência de repetições de localidades, é justamente opadrão que auxiliará na identificação da credibilidade de um usuário.

Várias estratégias aqui discutidas apontam para direcionamentos relacionados àsolucionar os dois principais requisitos para as RSPs, isto é, a confiabilidade dos da-dos e a credibilidade de seus usuários. Contudo, um ponto importante destacado por[Mashhadi and Capra 2011] é que tais aspectos estão menos relacionados com a precisãode um dado em si e mais sobre qual informação, ou perspectiva, os seus usuários possuemsobre tais dados. Em outras palavras, ainda há muita subjetividade sobre a noção de qua-lidade de um dado compartilhado nas RSPs. Assim, uma estratégia que tenha como focolidar com a qualidade destes dados deve considerar as necessidades de cada aplicação eprocurar atender aos seus requisitos de forma específica.

6.5.5. RSPs e Redes Veiculares

6.5.5.1. Definições

Uma rede veicular (Vehicular Network - VANET) oferece uma gama de oportunidadespara monitoramento urbano e compartilhamento de dados sobre diversos aspectos do trân-sito. As redes veiculares não possuem as restrições comuns das redes de sensores sem fio,como por exemplo: energia, limitações de banda e memória, o que permite um senso-riamento mais preciso e uma maior quantidade de dados coletados do ambiente. Alémdisso, um veículo pode conter sensores que não estão disponíveis comumente em dispo-sitivos portáveis utilizados em RSPs, alguns exemplos são sensores químicos, acústicos,temperatura e umidade.

Outro ponto importante das redes veiculares é a cobertura da área de monitora-mento. Veículos circulam por toda cidade, permeando ruas e avenidas. Devido a essa altamobilidade, as redes veiculares conseguem capturar uma maior riqueza de detalhes dacidade. Todas essas características tornam uma rede veicular uma importante fonte de da-dos, que pode complementar dados provenientes de RSPs para um melhor entendimentodos fenômenos urbanos.

O campo de redes veiculares é bastante extenso. Por exemplo, em uma rede vei-cular os eventos (ou problemas) a serem monitorados são diversos, variam desde o acon-tecimento de uma queda de barreira em uma estrada até congestionamento no centro dacidade, acidentes, presença de animais na pista, etc. Não é objetivo deste minicurso dis-



cutir em detalhes as redes veiculares e sim como as redes veiculares podem contribuircom RSPs e vice-versa. Com isso, nesta seção apresentamos trabalhos que focam em trêsprincipais questões: monitoramento geral de eventos no trânsito; o uso de dados em redesveiculares para o estudo de rotinas; e o estudo de congestionamento. Discutimos tambémdiversos desafios associados com essas questões.

6.5.5.2. Monitorando Eventos

Em VANETs os veículos podem cooperar entre si para coletar dados do ambiente, que pos-sibilitam a identificação de eventos, e os propagar para as entidades interessadas. Destaforma, esses dados podem influenciar diretamente na rota dos veículos, fazendo com queem muitos casos, os condutores redefinam as trajetórias. Cunha et al. [da Cunha et al. 2014a]apresentaram um serviço para monitoramento e disseminação de dados de um evento, queconsidera os padrões de deslocamento dos veículos. Com isso, ao sensoriar um eventoem uma região, o veículo propaga essa informação aos demais veículos, avisando sobreperigos à frente. Além disso, essa propagação considera as interações entre os veículos,selecionando aqueles que garantem uma cobertura maior na disseminação dos dados.

Outra possível solução usada para sensoriar eventos com as redes veiculares éapresentada por Lee et al. [Lee et al. 2006b], conhecida por MobEyes. O objetivo destasolução é fazer uso dos veículos equipados com sensores, para que, de forma proativa,os veículos coletem dados das vias públicas e de veículos na região. Entretanto, devidoà quantidade de dados gerada, alguns filtros podem ser associados e apenas dados maisrelevantes serão armazenados e encaminhados para o sorvedouro. Nesse cenário, os al-goritmos que controlarão a coleta e entrega de dados para o sorvedouro devem ser todoscientes das peculiaridades e restrições das VANETs.

Com objetivos diferentes, Lee et al. [Lee et al. 2006a] apresentaram o FleaNet,uma plataforma para a submissão de consultas em redes veiculares. Nela os veículosrecebem e submetem consultas sobre diversas questões do trânsito. Por exemplo, umusuário móvel detecta um acidente e compartilha fotos do mesmo para os veículos próxi-mos, publicando a informação. De forma diferente, mas respeitando o mesmo princípio,um estabelecimento comercial pode divulgar avisos sobre ofertas e promoções para osveículos que passam nas proximidades. Além disso, o usuário pode submeter consultasna rede em busca de locais e atrações nas proximidades.

6.5.5.3. Entendendo Comportamentos e Rotinas

Considerando os aspectos de mobilidade dos veículos e as suas trajetórias diárias, é pos-sível extrair desse cenário diversas características culturais sobre as rotinas dos usuários,seus interesses e os pontos de maior visitação em uma cidade. Baseado nisso, o traba-lho proposto por Cunha et al. [da Cunha et al. 2014b] apresenta uma análise de traces deGPS que descrevem a mobilidade de veículos em uma cidade e a partir deles extrair com-portamentos semelhantes na rede e entender melhor as rotinas das cidades. Entretanto,esses traces são obtidos através da adesão de pessoas que permitem o monitoramento damovimentação de seus veículos. Assim, quanto maior for a quantidade de registros de



veículos, maior também será a qualidade dos dados caracterizados.

De forma semelhante, Fiore et al. [Fiore et al. 2014] apresentam uma análise damobilidade de veículos com o intuito de caracterizar o tráfego em uma cidade por meiodo entendimento dos fluxos e dos locais visitados. Baseados na análise de um trace demobilidade os autores demonstram como o uso de uma informação de mobilidade realdos veículos pode ajudar na avaliação do desempenho de protocolos para VANETs. Nestetrabalho os autores usam o trace da cidade de Colônia (Alemanha) e a partir da análiseconseguem melhorar o desempenho de protocolos e entender a distribuição de tráfego nacidade.

6.5.5.4. Monitorando Tráfego

Na literatura existem diversos modelos que lidam com o congestionamento de trânsito.Dentre eles podemos citar os que fazem apenas a detecção do congestionamento [Jain and Sethi 2012,Wisitpongphan et al. 2012], outros que fazem a sua previsão [Kong et al. 2013, Kurihara 2013],ou então fazem ambos [Horvitz 2015, Marfia and Roccetti 2011]. Eles se diferenciamprincipalmente quanto à: (i) janela de tempo futuro para o congestionamento; (ii) técni-cas utilizadas no modelo; (iii) fontes de dados utilizadas.

Quanto à janela de tempo futuro para o congestionamento, existem duas classifi-cações: (i) os modelos Short-term traffic flow forecasting (STFF), que fazem previsão dodesempenho do trânsito nos próximos 5 min até 1 hora [Sun et al. 2004]; (ii) os demais(previsão para mais de 1 hora, no mínimo), chamamos de Long-term traffic flow forecas-ting (LTFF). Os modelos que fazem a previsão do trânsito para 15 min ou 30 min futurosse mostram mais interessante e úteis, pois esse é um intervalo de tempo razoável paratomar uma decisão. Apesar de existirem diversos modelos de previsões STFF e LTFF, autilização de RSPs pode melhorar a acurácia do modelo, dependendo de como variáveissociais forem utilizadas. Como os dados sensoriados em RSPs estão associados com oshábitos e as rotinas dos usuários, o desafio está em como obter e como utilizar esses dadosem tempo real, principalmente para STFF.

As técnicas mais utilizadas para fazer previsão de congestionamento são: Seaso-nal AutoRegressive Integrated Moving Average (SARIMA), multi–variate AutoRegressiveIntegrated Moving Average (ARIMA), redes Bayesianas, agrupamento fuzzy, identifica-ção de padrões de trânsito, algoritmo genético, redes neurais, Support Vector Machines(SVM), média histórica, regressão não-paramétrica, filtro de Kalman e colônia de formi-gas.

As abordagens se diferenciam quanto à fonte de dados utilizada para fazer a de-tecção e/ou previsão, em termos de: traces de GPS, monitoramento de movimentaçõesde celulares / smartphones, mapas online, dados de sensores nas vias, clima, estaçõesdo ano, eventos, informações de construções nas vias, incidentes de trânsito e sensoria-mento social (social sensing). Dados de sensores nas vias são informações mais utilizadaspelos modelos, seguidos de traces de GPS, clima e estações do ano. Por exemplo, o pro-jeto Clearflow da Microsoft Research, descrito em [Horvitz 2015], utiliza praticamente



todas as fontes citadas. No produto oferecido pela empresa Intellione28, apenas dados damovimentação dos usuários nas redes de celular são utilizados para detectar o congestio-namento (nenhuma predição é realizada). Para fazer previsão de congestionamento, Songet al. [Yuecong et al. 2007] utilizaram a combinação de vários preditores simples atravésde um algoritmo genético, obtendo uma previsão com maior precisão.


As redes veiculares e as RSPs possuem várias possibilidades de integração. Isso trazvários desafios e oportunidades, como os descritos a seguir.

1. Monitoramento de eventos: Na Seção 6.4.5 discutimos várias iniciativas que uti-lizam dados de RSPs exclusivamente para a detecção de eventos. A área de mo-nitoramento de eventos em redes veiculares pode se beneficiar de algumas dessasiniciativas, bem como utilizar dados de RSPs para o desenvolvimento de técnicaspara a identificação de eventos específicos ou aprimorar técnicas existentes. Alémdisso, problemas difíceis de serem identificados por uma rede veicular podem serreportados em RSPs, como discutido na Seção 6.5.1. Repare ainda que rotas pode-riam ser sugeridas para evitar pontos de interesse e eventos na cidade, ou mesmopara favorecer o encontro de pontos mais visitados.

2. Disponibilidade de dados: Como discutimos anteriormente, principalmente naSeção 6.4, dados de RSPs podem ser bastante úteis para o estudo de hábitos e rotinasde habitantes das cidades. Essas informações são importantes em redes veiculares,como mencionamos na Seção 6.5.5.3. No entanto, usuários em redes veicularespodem não fornecer a informação de locais visitados, problema que também podeocorrer em RSPs. Podemos minimizar esse problema estimulando a contribuiçãodos usuários. Isso é possível com incentivos adequados, bem como o aumento daprivacidade dos usuários em VANETs e RSPs para que os usuários permitam oestudo de suas rotinas. Outra forma de minimizar esse problema é utilizar dadosdisponíveis através de RSPs e redes veiculares conjuntamente. Isso serve para obterinformações complementares sobre a movimentação dos usuários, bem como terredundância de dados.

Em relação ao problema de congestionamento, geralmente, quanto mais fontes dedados um modelo utiliza melhor é o seu desempenho, pois mais informações sãoutilizadas para melhorar suas inferências. O problema é que nem sempre as fontesde dados estão correlacionadas e são relevantes para a previsão do congestiona-mento. Assim, a inclusão de uma nova fonte de dados requer uma caracterizaçãocom relação ao desempenho do trânsito.

Além disso, como vimos na Seção 6.3, a contribuição de dados pode ser bastantedesigual em regiões distintas de uma cidade. Se não tivermos dados suficientes emtodas as regiões, quais delas vão se beneficiar dessa informação? Outra questão é:como utilizar essa ou outras metodologias perante eventos atípicos que impactamno trânsito?

28http://www.intellione.com.



3. Detecção/previsão de trânsito: De forma geral, dados de RSPs são pouco explo-rados em modelos de detecção/previsão de trânsito. Alguns dos trabalhos maispróximos dessa direção são: [Silva et al. 2013e, Tostes et al. 2014]. Tostes et al.analisaram condições de trânsito em relação aos dados sensoriados por duas RSPs,Foursquare e Instagram. Como vimos na Seção 6.3 os sensores de RSPs forneceminformações importantes para o melhor entendimento da dinâmica das cidades. Porexemplo, uma mensagem geolocalizada, seja no Foursquare, Instagram ou Twit-ter, pode ser utilizada para melhor entendermos as condições de trânsito. De fato,Tostes et al. [Tostes et al. 2014] observaram que check-ins são correlacionados comtrânsito intenso e que podem ser utilizados para desenvolver modelos de previsãode congestionamento mais eficientes. Além disso, imagine que um usuário façaum check-in em casa e depois vá para o trabalho. Quando chegar no trabalho, poralgum motivo, ele faz outro check-in. Independente se for na mesma rede social ounão, existe uma informação intrínseca no intervalo de tempo entre esses check-insque consiste no desempenho do trânsito. Se o trânsito estiver mais congestionado,esse intervalo entre check-ins será maior do que o tempo de viagem sem congesti-onamento, que é facilmente calculado pela distância e velocidade máxima das vias.Além disso, os autores também levantaram várias questões nessa direção: (i) comocoletar dados de mapas online em tempo real?; (ii) é possível utilizar dados de RSPscomo uma característica preditora de trânsito intenso?

Para tratar a questão (i), os autores desenvolveram uma nova metodologia de coletadescrita em [Tostes et al. 2013]. Basicamente, eles tiram um screenshot do mapacom a camada de trânsito habilitada a cada intervalo de tempo (1 min). Cada ruapossui uma máscara em relação à imagem do mapa. Cada novo screenshot passaem um algoritmo de processamento de imagens, que extrai a cor da rua, que corres-ponde à intensidade do trânsito (verde – livre, amarelo – congestionado, vermelho– engarrafado). O problema dessa abordagem é que as máscaras das ruas devem sercriadas manualmente, e isso é um gargalo do processo. Para a questão (ii), os au-tores analisaram a cidade de New York, mais especificamente a área de Manhattan.Conforme o estudo demonstra, os check-ins são bastante correlacionados com trân-sito intenso. A Figura 6.21 mostra os resultados de [Tostes et al. 2014]. Ao compa-rar as Figuras 6.21(a) e 6.21(b), podemos ver que a distribuição de trânsito intensoe a distribuição de check-ins durante os dias de semana são bastante semelhantes,no entanto as curvas são deslocadas no eixo X. Esta descoberta é surpreendente esugere que dados de RSPs podem refletir as condições reais de tráfego.

6.5.6. Outros Desafios Relacionados às RSPs

Outra questão importante é lidar com um grande volume de dados que as RSPs podemoferecer, impondo desafios para armazenamento, processamento e indexação em temporeal usando ferramentas de gerenciamento de banco de dados tradicionais ou aplicações deprocessamento de dados. Isso faz com que a oferta de serviços em tempo real usando umarede de sensoriamento participativo seja um desafio. Para resolver esta questão, precisa-mos de métodos para armazenar, mover e processar de forma eficaz grandes quantidadesde dados. Novos paradigmas algorítmicos devem ser projetados, bem como técnicas demineração de dados específicas devem ser criadas de acordo com esses novos paradigmas.



(a) Intervalo de 5 minutos (b) Intervalo de 5 minutos com shift (c) Intervalo de 30 minutos

Figura 6.21. Frequência de trânsito intenso em diferentes intervalos de tempoem um dia típico (segunda–sexta) [Tostes et al. 2014].

Outros métodos devem contemplar abordagens de engenharia de dados para grandes redescom milhões ou bilhões de nós/arestas, incluindo compressão eficaz, pesquisa e métodospara casamento de padrões [Giannotti et al. 2012]. Felizmente, a pesquisa sobre os desa-fios de grandes dados é muito ativa, e recentemente fez grandes avanços, por exemplo,com base em plataformas paralelas (por exemplo, Hadoop29), para o processamento deum grande volume de dados.

Além disso, as RSPs são muito dinâmicas. Para ilustrar os desafios que surgemcom esta característica, observe o fluxo de informações em RSPs, que é mostrado naFigura 6.2, particularmente os dois fluxos simbolizados por setas rotuladas com a pala-vra “usa”. Usuários contam com RSPs, como o Twitter ou Waze, para transmitir seusdados sensoriados. Esses dados são transmitidos para o servidor, ou “sorvedouro”. Ocomponente de análise de informação contextual, ilustrado na Figura 6.2, é responsá-vel pelo tratamento dos dados compartilhados gerando informações úteis, ou contextos[Dey and Abowd 2000]. Sistemas, como o Waze, por sua vez, podem ser realimentadoscom os contextos gerados e, a partir disso, eles podem fornecer informações úteis para osusuários. Contextos também podem ser gerados por aplicativos de terceiros. Por exemplo,na Seção 6.4 é descrito um exemplo de aplicação que permite a identificação de regiõesde interesse de uma cidade, que exemplifica um tipo de contexto. Após usar este aplica-tivo, os usuários podem optar por mudar o seu comportamento, por exemplo, para visitarpreferencialmente áreas populares, o que pode vir a afetar o número de dados compar-tilhados nesses locais. Isto dá uma ideia do dinamismo de uma rede de sensoriamentoparticipativo e os desafios que surgem nessas condições.

Além desses desafios, existe ainda a questão da privacidade do usuário. Este de-safio é bastante amplo e está presente em muitas camadas do sistema. Privacidade de da-dos em sistemas de mídia social atualmente tem sido discutida em vários estudos, comoem [Pontes et al. 2012, Toch et al. 2010, Brush et al. 2010].

6.6. ConclusãoNeste minicurso, mostramos que as RSPs oferecem oportunidades sem precedentes deacesso a dados de sensoriamento em escala planetária, dados que nos ajudam a entender

29http://hadoop.apache.org



melhor a dinâmica das cidades e o comportamento social urbano. Nessa direção, apresen-tamos uma visão detalhada das propriedades desses dados, bem como a sua utilidade nodesenvolvimento de serviços mais inteligentes para atender às necessidades das pessoasem diversas áreas.

Além disso, discutimos alguns dos principais desafios relacionados à RSPs, quevão deste mecanismos de incentivos para os usuários das RSPs, até o uso desses dadospara a geração de aplicações mais sofisticadas. Ressaltamos também várias oportunidadesrelacionadas ao uso de dados de RSPs, por exemplo ao considerar a dinâmica temporaldos dados.

É importante frisar que discutimos apenas alguns dos principais desafios e opor-tunidades relacionados ao emergente conceito de RSPs e que, certamente, outros existem.Além disso, novos desafios e oportunidades podem surgir com a criação de novas RSPs eo aumento do número de usuários utilizando essas redes.

Referências[Adomavicius and Tuzhilin 2005] Adomavicius, G. and Tuzhilin, A. (2005). Toward the next generation

of recommender systems: a survey of the state-of-the-art and possible extensions. Knowledge and DataEngineering, IEEE Transactions on, 17(6):734–749.

[Anbukodi and Manickam 2011] Anbukodi, S. and Manickam, K. (2011). Reducing web crawler overheadusing mobile crawler. In Proc. of ICETECT’11, pages 926–932, Nagercoil, India.

[Bannur and Alonso 2014] Bannur, S. and Alonso, O. (2014). Analyzing temporal characteristics of check-in data. In Proc. of WWW Companion ’14, pages 827–832, Seoul, Korea.

[Barth 1969] Barth, F. (1969). Ethnic groups and boundaries: the social organization of culture difference.Scandinavian university books. Little, Brown.

[Benevenuto et al. 2011] Benevenuto, F., Almeida, J. M., and Silva, A. S. (2011). Explorando redes sociaisonline: Da coleta e análise de grandes bases de dados às aplicações. Proc. of SBRC’11, pages 63–94.

[Bollen et al. 2011] Bollen, J., Mao, H., and Zeng, X. (2011). Twitter mood predicts the stock market.Journal of Computational Science, 2(1):1–8.

[Bowles and Gintis 2003] Bowles, S. and Gintis, H. (2003). Origins of human cooperation. In: Geneticand cultural evolution of cooperation. MIT Press Cambridge, MA.

[Brockmann et al. 2006] Brockmann, D., Hufnagel, L., and Geisel, T. (2006). The scaling laws of humantravel. Nature, 439(7075):462–465.

[Brush et al. 2010] Brush, A. B., Krumm, J., and Scott, J. (2010). Exploring end user preferences forlocation obfuscation, location-based services, and the value of location. In Proc. of Ubicomp ’10, pages95–104, Copenhagen, Denmark. ACM.

[Buchholz and Schiffers 2003] Buchholz, T. and Schiffers, M. (2003). Quality of context: What it is andwhy we need it. In Proc. of OVUA’03, Geneve, Switzerland.

[Burke et al. 2006] Burke, J., Estrin, D., Hansen, M., Parker, A., Ramanathan, N., Reddy, S., and Srivas-tava, M. B. (2006). Participatory sensing. In Proc. of Workshop on World-Sensor-Web (WSW’06), pages117–134, Boulder, USA.

[CENS/UCLA ] CENS/UCLA. Participatory Sensing / Urban Sensing Projects.http://research.cens.ucla.edu/.

[Cha et al. 2010] Cha, M., Haddadi, H., Benevenuto, F., and Gummadi, K. (2010). Measuring user influ-ence in twitter: The million follower fallacy. In Proc. of ICWSM’10, Washington, USA.



[Cheng et al. 2011] Cheng, Z., Caverlee, J., Lee, K., and Sui, D. Z. (2011). Exploring Millions of Foot-prints in Location Sharing Services. In Proc. of ICWSM’11, Barcelona, Spain.

[Cho et al. 2011] Cho, E., Myers, S. A., and Leskovec, J. (2011). Friendship and mobility: user movementin location-based social networks. In Proc. KDD ’11, pages 1082–1090, San Diego, USA. ACM.

[Clauset et al. 2009] Clauset, A., Shalizi, C. R., and Newman, M. E. J. (2009). Power-law distributions inempirical data. SIAM Rev., 51(4):661–703.

[Coen-Porisini and Sicari 2012] Coen-Porisini, A. and Sicari, S. (2012). Improving data quality using across layer protocol in wireless sensor networks. Comput. Netw., 56(17):3655–3665.

[Crandall et al. 2009] Crandall, D. J., Backstrom, L., Huttenlocher, D., and Kleinberg, J. (2009). Mappingthe world’s photos. In Proc. of WWW ’09, pages 761–770, Madrid, Spain. ACM.

[Cranshaw et al. 2012] Cranshaw, J., Schwartz, R., Hong, J. I., and Sadeh, N. (2012). The LivehoodsProject: Utilizing Social Media to Understand the Dynamics of a City. In Proc. of ICWSM’12, Dublin,Ireland.

[da Cunha et al. 2014a] da Cunha, F. D., Maia, G., Viana, A. C., Mini, R. A. F., Villas, L. A., and Loureiro,A. A. F. (2014a). Socially inspired data dissemination for vehicular ad hoc networks. In Proc. ofMSWiM’14, pages 81–85, Montreal, Canada.

[da Cunha et al. 2014b] da Cunha, F. D., Viana, A., de Oliveira Rodrigues, T. A., Mini, R., and Loureiro, A.A. F. (2014b). Extração de propriedades sociais em redes veiculares. In Proc. of SBRC 2014 - WP2P+,Florianópolis, Brasil.

[Deterding et al. 2011] Deterding, S., Dixon, D., Khaled, R., and Nacke, L. (2011). From game designelements to gamefulness: defining gamification. In International Academic MindTrek Conference: En-visioning Future Media Environments, pages 9–15. ACM.

[Dey and Abowd 2000] Dey, A. K. and Abowd, G. D. (2000). Towards a Better Understanding of Contextand Context-Awareness. In Proc. of CHI 2000 Workshops, The Hague, The Netherlands.

[Ferreira et al. 2014] Ferreira, A. P. G., Silva, T. H., and Loureiro, A. A. F. (2014). You are your check-in:Understanding the behavior of tourists and residents using data from foursquare. In Proc. of WebMe-dia’14, Joao Pessoa, Brasil.

[Fiore et al. 2014] Fiore, M., Barcelo-Ordinas, J. M., Trullols-Cruces, O., and Uppoor, S. (2014). Ge-neration and analysis of a large-scale urban vehicular mobility dataset. IEEE Transactions on MobileComputing, 13(5):1–1.

[Fitzek et al. 2013] Fitzek, F. H., Heide, J., Pedersen, M. V., and Katz, M. (2013). Implementation ofnetwork coding for social mobile clouds [applications corner]. Signal Processing Magazine, IEEE,30(1):159–164.

[Ganti et al. 2011] Ganti, R., Ye, F., and Lei, H. (2011). Mobile crowdsensing: current state and futurechallenges. Communications Magazine, IEEE, 49(11):32 –39.

[Gao et al. 2015] Gao, H., Liu, C., Wang, W., Zhao, J., Song, Z., Su, X., Crowcroft, J., and Leung, K.(2015). A survey of incentive mechanisms for participatory sensing. Communications Surveys Tutorials,IEEE, PP(99):1–1.

[Gao et al. 2013] Gao, H., Tang, J., Hu, X., and Liu, H. (2013). Exploring temporal effects for locationrecommendation on location-based social networks. In Proc. of RecSys ’13, pages 93–100, Hong Kong,China.

[Georgescu et al. 2014] Georgescu, M., Pham, D. D., Firan, C. S., Gadiraju, U., and Nejdl, W. (2014).When in doubt ask the crowd: Employing crowdsourcing for active learning. In Proc. of WIMS’14,pages 12:1–12:12, Thessaloniki, Greece. ACM.

[Giannotti et al. 2012] Giannotti, F., Pedreschi, D., Pentland, A., Lukowicz, P., Kossmann, D., Crowley, J.,and Helbing, D. (2012). A planetary nervous system for social mining and collective awareness. TheEur. Phy. Jour. Special Topics, 214(1):49–75.



[Gomide et al. 2011] Gomide, J., Veloso, A., Jr., W. M., Almeida, V., Benevenuto, F., Ferraz, F., andTeixeira, M. (2011). Dengue surveillance based on a computational model of spatio-temporal locality oftwitter. In Proc. of WebSci’11, Evanston, USA.

[Gonzalez et al. 2008] Gonzalez, M. C., Hidalgo, C. A., and Barabasi, A.-L. (2008). Understanding indi-vidual human mobility patterns. Nature, 453(7196):779–782.

[Hochman and Schwartz 2012] Hochman, N. and Schwartz, R. (2012). Visualizing instagram: Tracingcultural visual rhythms. In Proc. of ICWSM’12, pages 6–9, Dublin, Ireland. AAAI.

[Horvitz 2015] Horvitz, E. (2015). Predictive analytics for traffic. http://research.microsoft.com/en-us/projects/clearflow/.

[Instagram 2014] Instagram (2014). Instagram today: 200 million strong.http://blog.instagram.com/post/80721172292/200m.

[Jain and Sethi 2012] Jain, P. and Sethi, M. (2012). Fuzzy based real time traffic signal controller to opti-mize congestion delays. In Proc. of ACCT’12, pages 204–207.

[Kamenica 2012] Kamenica, E. (2012). Behavioral economics and psychology of incentives. Annu. Rev.Econ., 4(1):427–452.

[Kaufmann et al. 2011] Kaufmann, N., Schulze, T., and Veit, D. (2011). More than fun and money. workermotivation in crowdsourcing–a study on mechanical turk. In Proc. of Amer. Conf. on Inf. Sys.

[Kisilevich et al. 2010] Kisilevich, S., Krstajic, M., Keim, D., Andrienko, N., and Andrienko, G. (2010).Event-based analysis of people’s activities and behavior using flickr and panoramio geotagged photocollections. In Proc. of Conf. on Inf. Vis., pages 289–296, London, UK. IEEE.

[Kong et al. 2013] Kong, Q.-J., Xu, Y., Lin, S., Wen, D., Zhu, F., and Liu, Y. (2013). Utn-model-based traf-fic flow prediction for parallel-transportation management systems. Intelligent Transportation Systems,IEEE Transactions on, 14(3):1541–1547.

[Kostakos 2009] Kostakos, V. (2009). Temporal graphs. Physica A: Statistical Mechanics and its Applica-tions, 388(6):1007–1023.

[Kurihara 2013] Kurihara, S. (2013). Traffic-congestion forecasting algorithm based on pheromone com-munication model. Ant Colony Optimization - Techniques and Applications.

[Lane et al. 2010] Lane, N., Miluzzo, E., Lu, H., Peebles, D., Choudhury, T., and Campbell, A. (2010). Asurvey of mobile phone sensing. Comm. Mag., IEEE, 48(9):140 –150.

[Lathi and Green 2014] Lathi, B. P. and Green, R. (2014). Essentials of digital signal processing. Cam-bridge University Press, Cambridge, UK.

[Lee and Hoh 2010] Lee, J.-S. and Hoh, B. (2010). Dynamic pricing incentive for participatory sensing.Pervasive and Mobile Computing, 6(6):693–708.

[Lee et al. 2006a] Lee, U., Park, J.-S., Amir, E., and Gerla, M. (2006a). Fleanet: A virtual market place onvehicular networks. In Proc. of Mobiquitous’06 - Workshops, pages 1–8, San Jose, USA.

[Lee et al. 2006b] Lee, U., Zhou, B., Gerla, M., Magistretti, E., Bellavista, P., and Corradi, A. (2006b). Mo-beyes: Smart mobs for urban monitoring with a vehicular sensor network. Wireless Commun., 13(5):52–57.

[Levine 1998] Levine, D. K. (1998). Modeling altruism and spitefulness in experiments. Review of econo-mic dynamics, 1(3):593–622.

[Li et al. 2012] Li, F., Nastic, S., and Dustdar, S. (2012). Data quality observation in pervasive environ-ments. In Proc. of IEEE CSE’12, pages 602–609, Nicosia, Cyprus.

[Long et al. 2012] Long, X., Jin, L., and Joshi, J. (2012). Exploring trajectory-driven local geographictopics in foursquare. In Proc. of UbiComp ’12, pages 927–934, Pittsburgh, Pennsylvania. ACM.

[Loureiro et al. 2003] Loureiro, A. A. F., Nogueira, J. M. S., Ruiz, L. B., Mini, R. A., Nakamura, E. F., andFigueiredo, C. M. S. (2003). Redes de sensores sem fio. Proc. of SBRC’03, pages 179–226.



[Marfia and Roccetti 2011] Marfia, G. and Roccetti, M. (2011). Vehicular congestion detection and short-term forecasting: A new model with results. Vehicular Technology, IEEE Tran. on, 60(7):2936–2948.

[Mashhadi and Capra 2011] Mashhadi, A. J. and Capra, L. (2011). Quality Control for Real-time Ubiqui-tous Crowdsourcing. In Proc. of UbiCrowd’11, pages 5–8, Beijing, China.

[Nazir et al. 2008] Nazir, A., Raza, S., and Chuah, C.-N. (2008). Unveiling facebook: A measurementstudy of social network based applications. In Proc. of IMC ’08, pages 43–56, Vouliagmeni, Greece.

[Nicosia et al. 2013] Nicosia, V., Tang, J., Mascolo, C., Musolesi, M., Russo, G., and Latora, V. (2013).Graph metrics for temporal networks. In Temporal Networks, pages 15–40. Springer.

[Noulas et al. 2011] Noulas, A., Scellato, S., Mascolo, C., and Pontil, M. (2011). An Empirical Study ofGeographic User Activity Patterns in Foursquare. In Proc. of ICWSM’11, Barcelona, Spain.

[Poblete et al. 2011] Poblete, B., Garcia, R., Mendoza, M., and Jaimes, A. (2011). Do all birds tweet thesame?: characterizing twitter around the world. In Proc. of CIKM, pages 1025–1030, Glasgow, UK.ACM.

[Pontes et al. 2012] Pontes, T., Magno, G., Vasconcelos, M., Gupta, A., Almeida, J., Kumaraguru, P., andAlmeida, V. (2012). Beware of what you share: Inferring home location in social networks. In Proc. ofICDMW, pages 571–578, Brussels, Belgium.

[Quercia et al. 2012] Quercia, D., Capra, L., and Crowcroft, J. (2012). The social world of twitter: Topics,geography, and emotions. In Proc. of ICWSM’12, Dublin, Ireland.

[Reddy et al. 2010] Reddy, S., Estrin, D., Hansen, M., and Srivastava, M. (2010). Examining micro-payments for participatory sensing data collections. In Proc. of Ubicomp ’10, pages 33–36, Copenhagen,Denmark. ACM.

[Reddy et al. 2007] Reddy, S., Parker, A., Hyman, J., Burke, J., Estrin, D., and Hansen, M. (2007). Imagebrowsing, processing, and clustering for participatory sensing: Lessons from a dietsense prototype. InProc. of EmNets’07, pages 13–17, Cork, Ireland. ACM.

[Sakaki et al. 2010a] Sakaki, T., Okazaki, M., and Matsuo, Y. (2010a). Earthquake shakes twitter users:real-time event detection by social sensors. In Proc. of WWW’10, pages 851–860, Raleigh, USA.

[Sakaki et al. 2010b] Sakaki, T., Okazaki, M., and Matsuo, Y. (2010b). Earthquake shakes twitter users:real-time event detection by social sensors. In Proc. of WWW’10, pages 851–860, Raleigh, USA. IW3C2.

[Scott and Carrington 2011] Scott, J. P. and Carrington, P. J. (2011). The SAGE Handbook of SocialNetwork Analysis. Sage Publications Ltd.

[Silva et al. 2014a] Silva, T., Vaz De Melo, P., Almeida, J., and Loureiro, A. (2014a). Large-scale study ofcity dynamics and urban social behavior using participatory sensing. Wireless Communications, IEEE,21(1):42–51.

[Silva et al. 2014b] Silva, T. H., Vaz de Melo, P., Almeida, J., Viana, A., Salles, J., and Loureiro, A.(2014b). Participatory Sensor Networks as Sensing Layers. In Proc. of SocialCom’14, Sydney, Aus-tralia.

[Silva et al. 2013a] Silva, T. H., Vaz de Melo, P. O. S., Almeida, J. M., and Loureiro, A. A. (2013a). Socialmedia as a source of sensing to study city dynamics and urban social behavior: Approaches, models, andopportunities. In Ubiquitous Social Media Analysis, volume 8329, pages 63–87. Springer.

[Silva et al. 2012] Silva, T. H., Vaz de Melo, P. O. S., Almeida, J. M., and Loureiro, A. A. F. (2012).Visualizing the invisible image of cities. In Proc. IEEE CPScom’12, pages 382–389, Besancon, France.

[Silva et al. 2013b] Silva, T. H., Vaz de Melo, P. O. S., Almeida, J. M., and Loureiro, A. A. F. (2013b).Challenges and opportunities on the large scale study of city dynamics using participatory sensing. InProc. of IEEE ISCC’13, pages 528–534, Split, Croatia.

[Silva et al. 2013c] Silva, T. H., Vaz de Melo, P. O. S., Almeida, J. M., and Loureiro, A. A. F. (2013c).Uma Fotografia do Instagram: Caracterização e Aplicação. In Proc. of SBRC’13, Brasília, Brazil.



[Silva et al. 2014c] Silva, T. H., Vaz de Melo, P. O. S., Almeida, J. M., Musolesi, M., and Loureiro, A.A. F. (2014c). You are What you Eat (and Drink): Identifying Cultural Boundaries by Analyzing Food& Drink Habits in Foursquare. In Proc. of ICWSM’14, Ann Arbor, USA.

[Silva et al. 2013d] Silva, T. H., Vaz de Melo, P. O. S., Almeida, J. M., Salles, J., and Loureiro, A. A. F.(2013d). A comparison of foursquare and instagram to the study of city dynamics and urban socialbehavior. In Proc. of UrbComp’13, pages 1–8, Chicago, USA.

[Silva et al. 2014d] Silva, T. H., Vaz de Melo, P. O. S., Almeida, J. M., Salles, J., and Loureiro, A. A. F.(2014d). Revealing the city that we cannot see. ACM Trans. Internet Technol., 14(4):26:1–26:23.

[Silva et al. 2013e] Silva, T. H., Vaz de Melo, P. O. S., Viana, A., Almeida, J. M., Salles, J., and Loureiro,A. A. F. (2013e). Traffic Condition is more than Colored Lines on a Map: Characterization of WazeAlerts. In Proc. of SocInfo’13, pages 309–318, Kyoto, Japan.

[Srivastava et al. 2012] Srivastava, M., Abdelzaher, T., and Szymanski, B. (2012). Human-centric sensing.Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences,370(1958):176–197.

[Sun et al. 2004] Sun, S., Yu, G., and Zhang, C. (2004). Short-term traffic flow forecasting using samplingmarkov chain method with incomplete data. In Proc. of Intelligent Vehicles Symposium, pages 437–441.

[Toch et al. 2010] Toch, E., Cranshaw, J., Drielsma, P. H., Tsai, J. Y., Kelley, P. G., Springfield, J., Cranor,L., Hong, J., and Sadeh, N. (2010). Empirical models of privacy in location sharing. In Proc. ofUbicomp’10, pages 129–138, Copenhagen, Denmark. ACM.

[Tostes et al. 2013] Tostes, A. I. J., Duarte-FIgueiredo, F., Assunção, R., Salles, J., and Loureiro, A. A. F.(2013). From data to knowledge: City-wide traffic flows analysis and prediction using bing maps. InProc. of ACM UrbComp’13, Chicago, USA.

[Tostes et al. 2014] Tostes, A. I. J., Silva, T. H., Duarte-FIgueiredo, F., and Loureiro, A. A. F. (2014).Studying traffic conditions by analyzing foursquare and instagram data. In Proc. of ACM PE-WASUN’14,Montreal, Canada.

[Werbach and Hunter 2012] Werbach, K. and Hunter, D. (2012). For the win: How game thinking canrevolutionize your business. Wharton Digital Press.

[Wisitpongphan et al. 2012] Wisitpongphan, N., Jitsakul, W., and Jieamumporn, D. (2012). Travel timeprediction using multi-layer feed forward artificial neural network. In Proc. of CICSyN’12, pages 326–330, Phuket, Thailand.

[Xie et al. 2009] Xie, X., Chen, H., and Wu, H. (2009). Bargain-based Stimulation Mechanism for SelfishMobile Nodes in Participatory Sensing Network. Proc. of IEEE SECON’09, pages 1–9.

[Yang et al. 2012] Yang, D., Xue, G., Fang, X., and Tang, J. (2012). Crowdsourcing to smartphones: in-centive mechanism design for mobile phone sensing. In Proc. of Mobicom’12, pages 173–184, Istanbul,Turkey.

[Youyou et al. 2015] Youyou, W., Kosinski, M., and Stillwell, D. (2015). Computer-based personalityjudgments are more accurate than those made by humans. Nat. Acad. of Sci., 112(4):1036–1040.

[Yuan et al. 2013] Yuan, Q., Cong, G., Ma, Z., Sun, A., and Thalmann, N. M. (2013). Time-aware point-of-interest recommendation. In Proc. of SIGIR ’13, pages 363–372, Dublin, Ireland. ACM.

[Yuecong et al. 2007] Yuecong, S., Wei, H., and Guotang, B. (2007). Combined prediction research of citytraffic flow based on genetic algorithm. In Proc. of ICEMI’07, pages 3–862–3–865.

[Zhang et al. 2013] Zhang, K., Jin, Q., Pelechrinis, K., and Lappas, T. (2013). On the importance of tem-poral dynamics in modeling urban activity. In Proc. of UrbComp’13, pages 7:1–7:8, Chicago, Illinois.

[Zheng et al. 2009] Zheng, Y., Zhang, L., Xie, X., and Ma, W.-Y. (2009). Mining interesting locations andtravel sequences from gps trajectories. In Proc. of WWW’09, pages 791–800, Madrid, Spain. ACM.



Livro de Minicursos

Documents

Transcript of Livro de Minicursos