Monografia Computação na Névoa

BRUNO SILVA DE OLIVEIRA
COMPUTAÇÃO EM NÉVOA: UM SURVEY SOBRE O ESTADO DA
ARTE E APLICAÇÕES

BRUNO SILVA DE OLIVEIRA
COMPUTAÇÃO EM NÉVOA: UM SURVEY SOBRE O ESTADO DA
ARTE E APLICAÇÕES
Monografia apresentada à Escola
Politécnica da Universidade de São Paulo,
para obter o título de Especialista, pelo
Programa de Pós-Graduação em MBA em
Internet das Coisas
Área de Concentração:
Internet das Coisas
Orientador:
Prof. Dr. Marcos A. Simplício Junior
São Paulo
2018

Autorizo a reprodução e divulgação total ou parcial deste trabalho, por qualquer meio
convencional ou eletrônico, para fins de estudo e pesquisa, desde que citada a fonte.
FICHA CATALOGRÁFICA
Computação em névoa: Um survey sobre o estado da arte e aplicações / Oliveira, Bruno Silva de
– São Paulo, 2018.
Monografia (MBA em Internet das Coisas) – Escola Politécnica da Universidade de São Paulo.
PECE – Programa de Educação Continuada em Engenharia.

DEDICATÓRIA
Dedico este trabalho àqueles que
colaboram com a difusão do
conhecimento e nunca desistem de
tornar o mundo melhor – com ou sem
Internet das Coisas.

AGRADECIMENTOS
À Escola Politécnica da Universidade de São Paulo – EPUSP e, principalmente, ao
prof. Marcos Simplício, cuja paciência, prontidão e suporte, tanto nas aulas quanto na
orientação, foi essencial para o melhor desenvolvimento possível deste trabalho.
A todos os colegas do MBA de Internet das Coisas, cujas interações, networking e
força de vontade tornaram este curso algo realmente valioso e de muito aprendizado.
Ao meu grande amigo Giovane cuja dedicação e cobrança não me deixaram desistir
e me ajudou a entregar o melhor de mim, estando presente na melhor hora possível.
E aos companheiros de sonhos e desafios, Carlos, Lucas e Thais, que me aguentaram
nos melhores e piores momentos (e vice-versa!).
À minha mãe, cuja paciência e perseverança, conseguiu entender a situação e é
responsável, de longa data, para eu ter chegado até aqui.
Ao tempo, por saber passar, não saber ficar, por não amadurecer e por não poder
esquecer – e por isso, o melhor professor de todos!

RESUMO
Com o crescente desenvolvimento de aplicações em Internet das Coisas (IdC), novas
soluções baseadas em Computação em Nuvem vêm surgindo em complemento a
essas aplicações. Essa tendência visa prover uma maior capacidade computacional
e comunicação entre os elementos que compõem as soluções de IdC. Por outro lado,
a combinação das duas abordagens cria grandes mudanças do modelo centralizado
tradicionalmente utilizado na área de Internet das Coisas. Esse novo modelo
descentralizado, no qual cada vez mais o processamento de dados concentra-se nas
bordas da rede, leva ao surgimento de um novo modelo computacional: a chamada
Computação em névoa (fog computing). Este trabalho explora os novos conceitos que
surgem com a computação em névoa, o estado da arte das aplicações, a comparação
com os modelos de computação em nuvem e os demais modelos de computação na
borda da rede e os desafios e sugestões de pesquisas futuras relacionadas ao tema.

7
ABSTRACT
The development of Internet of Things (IoT) applications are requesting innovative
solutions in Cloud Computing. These cloud solutions offer a greater computational
resources and communication between the elements that compose IoT solutions. On
another hand, the combination of these two models changes centralized traditional
models in the Internet of Things. This new decentralized model, which more and more
data processing are concentrated at the edges of the network, leads to the creation of
a new computational model: fog computing. This work explores the new concepts that
emerge with fog computing, as well as the state of the art of the applications, the
comparison with the cloud computing models and the other models of computing at
the edge networks, and the challenges and suggestions of future research related to
the topic.

8
LISTA DE ILUSTRAÇÕES
Figura 1 Ciclo de Interesse (Hype Cycle) da Gartner para Internet das Coisas, com
as principais tecnologias emergentes na área. Adaptado de [Gartner, 2016] ...........17
Figura 2 – Paradigmas de computação na borda (termos em inglês): busca de
termos de acordo com o Google Trends. Extraído de [Google Trends, 2018]...........19
Figura 3 - Resumo da interação entre cloudlets e dispositivos. Adaptado de [Ai et al,
2017] .........................................................................................................................23
Figura 4 - Modelo de arquitetura Névoa para Nuvem. Adaptado de [Tordera et al,
2018] .........................................................................................................................25
Figura 5 Exemplos de arranjo de computação em névoa: diferentes arquiteturas e
nós de computação em névoa em um mesmo sistema. Adaptado de [Buyya et al,
2016] .........................................................................................................................26
Figura 6 – Arquitetura de referência baseada em perspectivas e recursos/serviços.
Adaptado de [OpenFog Consortium, 2017]...............................................................28
Figura 7 – Exemplos de ataques contra a nuvem e a utilizando como agente
malicioso. Adaptado de [Hu et al, 2017] ....................................................................33
Figura 8 – Diferentes provisionamentos de rede SDN de acordo com a variação da
demanda, usando técnica de slicing. Adaptado de [Gomez et al, 2018] ...................35
Figura 9 – Exemplo de hangover com SDN com a movimentação entre campi de
uma universidade – suporte à mobilidade. Adaptado de [Baktir et al, 2017].............36
Figura 10 – Exemplo de fluxo de informações em modelo de computação em névoa.
Adaptado de [Tang et al, 2017]..................................................................................37
Figura 11 – Computação em névoa com procedimento de agregação de dados para
poupar banda de rede com a nuvem. Adaptado de [Lu et al, 2017]..........................38
Figura 12 – Esquema com diferentes etapas da análise de dados na computação em
névoa. Adaptado de [Bonomi et al, 2014]..................................................................39
Figura 13 - Espectro para tomada de decisão de implementação baseados na
relação entre complexidade e proximidade do sistema. Adaptado de [Baktir et al,
2017]. ........................................................................................................................41
Figura 14 – Espectro para tomada de decisão de implementação de sistemas
baseados na relação entre volume de dados enviados e requisitos de tempo real.
Adaptado de [Bilal et al, 2018]...................................................................................42
Figura 15 – Árvore de decisão para implementações de computação na borda da
rede. Adaptado de [Dolui et al, 2017] ........................................................................46
Figura 16 – VANET em arquitetura de névoa (F2C) utilizando controlador SDN.
Adaptado de [Kai et al, 2016]. ...................................................................................48

9
Figura 17 – Arquitetura em névoa para o ecossistema de aplicações eHealth.
Adaptado de [Farahani et al, 2018] ...........................................................................50

10
LISTA DE TABELAS
Tabela 1 – Diferentes definições para o conceito de computação em névoa............15
Tabela 2 – Comparação entre modelos de computação móvel. Adaptado de [Mao et
al, 2017] ....................................................................................................................24
Tabela 3 – Descrição de camadas F2C. Baseado em [Buyya et al, 2016]................27
Tabela 4 – Resumo das principais vulnerabilidades em ambiente de computação em
névoa. Adaptado de [Roman et al, 2018] ..................................................................31
Tabela 5 – Exemplos de ataques a infraestrutura de segurança de um sistema de
computação em névoa. Adaptado de [OpenFog Consortium, 2017].........................33
Tabela 6 – Efeitos da distância no RTT, perda de pacotes, vazão e tempo de
download. Adaptado de [Bilal et al, 2018] .................................................................41
Tabela 7 – Comparação entre o modelo de computação em nuvem e os modelos de
computação na borda. Fonte: Autor. .........................................................................43
Tabela 8 – Comparação entre os modelos de computação na borda. Fonte: Autor..44
Tabela 9 – Levantamento de requisitos de aplicações para VANETs........................47
Tabela 10 – Levantamento de requisitos de aplicações de eHealth com IdC ...........49
Tabela 11 – Propostas de computação em névoa e áreas de aplicação. Adaptado de
[Baktir et al, 2017] .....................................................................................................51

11
LISTA DE ABREVIATURAS E SIGLAS
CDN Content Delivery Networks (Rede de Distribuição de Conteúdo)
CPE Customer Permises Equipment (Equipamentos alocados no cliente)
DDoS Distributed Denial of Service (ataques de negação de serviço)
DNS Domain Name Server (servidor de domínio de nomes)
ETSI European Telecommunications Standards (organização)
F2C Fog to Cloud (Névoa para Nuvem)
GPRD General Data Protection Regulation (Regulação geral da proteção de
dados na União Europeia)
HIPAA Health Insurance Portability and Accountability Act (Lei de portabilidade
e responsabilidade de seguros de saúde)
HMI Human-machine interface (comunicação entre homem e máquina)
IdC Internet das Coisas
IoT Internet of Things
ITS Inteligent transportation system (Sistema de transporte inteligente)
M2M Machine to Machine (comunicação entre máquinas)
MEC Mobile Edge Computing (Computação móvel de borda)
OBU On-Board Unit (unidades de comunicação a bordo dos veículos)
OEC Open Edge Computing (organização)
RAR Redes de acesso por rádio (do inglês RAN – Radio Access Networks)
RSU Road-side Units (unidades de comunicação em vias de transporte)
SOA Service-Oriented Architecture (arquitetura orientada a serviços)
VANET Vehicular Ad-Hoc Networks (Redes móveis veiculares Ad-hoc)
XaaS Everything-as-a-Service (Qualquer coisa como serviço)

12
SUMÁRIO
1 INTRODUÇÃO....................................................................................................14
1.1 Motivações................................................................................................16
1.2 Objetivo.....................................................................................................18
1.3 Justificativas..............................................................................................18
1.4 Estrutura do Trabalho ...............................................................................20
2 FUNDAMENTAÇÃO TEÓRICA...........................................................................21
2.1 Modelos de computação na borda de rede...............................................21
2.1.1 Cloudlets...................................................................................................21
2.1.2 Computação móvel na borda....................................................................23
2.1.3 Nós na computação em névoa .................................................................24
2.2 Arquiteturas de computação em névoa ....................................................25
2.2.1 Conceito de arquitetura F2C e arquitetura de referência ..........................27
2.2.2 Arquitetura integrada aos equipamentos dos usuários finais (Indie Fog) .28
2.3 Segurança da Informação.........................................................................29
2.3.1 Proteção de dados e privacidade contra os ataques internos e externos.30
2.4 Fluxo de informação na névoa..................................................................34
2.4.1 Gestão de rede .........................................................................................34
2.4.2 Fluxo de dados .........................................................................................36
2.4.3 Análise das informações...........................................................................38
2.5 Considerações sobre o capítulo................................................................39
3 COMPARAÇÃO ENTRE MODELOS COMPUTACIONAIS ................................40
3.1 Fatores para adoção de diferentes modelos de computação: nuvem vs.
borda 40
3.2 Comparação de fatores entre a nuvem e a computação na borda ...........42

13
3.3 Escolha entre modelos de computação na borda .....................................43
3.4 Considerações sobre o capítulo................................................................46
4 APLICAÇÕES DA COMPUTAÇÃO EM NÉVOA.................................................47
4.1 Computação em névoa com redes veiculares (VANET) ...........................47
4.2 Computação em névoa em aplicações da medicina e saúde (eHealth) ...48
4.3 Outras aplicações .....................................................................................51
5 CONSIDERAÇÕES FINAIS................................................................................52
5.1 Contribuições do Trabalho ........................................................................52
5.2 Trabalhos Futuros.....................................................................................52

14
1 INTRODUÇÃO
Considerando o crescente número de soluções e dispositivos surgindo no contexto de
Internet das Coisas (IdC), ou Internet of Things, a quantidade de dados coletados,
armazenados e processados também tende a apresentar um crescimento acelerado.
A Cisco estima mais de 20 bilhões de dispositivos conectados até 2020 [Gartner,
2017]. Este cenário traz consigo a necessidade de troca de dados sob demanda e a
capacidade de manter uma rede confiável e íntegra mesmo sob condições adversas
[Gubbi et al, 2013], como restrições de recursos computacionais e energia dos
dispositivos. Novos sistemas que utilizam a Internet das Coisas vêm agregando
diferentes tecnologias para possibilitar a composição de cenários de computação
ubíqua (isto é, recursos computacionais e dados acessíveis a partir de qualquer lugar)
baseados em elementos autoconfiguráveis sobre uma infraestrutura de rede dinâmica
e global [Botta et al, 2016].
Quando soluções de Internet das Coisas precisam atingir escala global, com
dispositivos presentes em diferentes localidades se comunicando de forma contínua,
é comum adotar uma visão de IdC centrada na nuvem [Gubbi et al, 2013]. Mais
precisamente, o modelo de computação em nuvem pode auxiliar as soluções de IdC
especialmente em relação à limitação de recursos computacionais. Afinal, os dados
coletados pelos sensores podem ser processados e armazenados na nuvem, o que
compensa as restrições dos dispositivos. Além disso, a nuvem pode ser utilizada como
uma plataforma de IdC quando os sensores e as coisas estão concentrados de forma
densa e/ou geodistribuídos [Coutinho et al, 2016]. Nesse cenário, as soluções em
Nuvem para IdC costumam operar no modelo Everything-as-a-Service (XaaS) [Khalid
apud Coutinho et al, 2016], no qual o usuário pode acessar os dados a partir de
qualquer dispositivo, em qualquer lugar, a qualquer momento.
Com esse elevado volume de tráfego, entretanto, os centros de processamento e as
redes que conectam esses centros aos dispositivos podem se tornar gargalos caso
esses elementos não sejam projetados com capacidade adequada. Isso pode levar a
aumentos significativos nos níveis de congestionamento na rede de backbone, com
consequentes atrasos e perda de pacotes, prejudicando a experiência do usuário

15
[Gupta et al, 2017]. Assim, esse cenário pode tornar-se incompatível com as
necessidades de aplicações em Internet das Coisas, principalmente aquelas utilizadas
em ambientes industriais e em ambientes de missões críticas: como elas exigem
respostas mais rápidas aos estímulos do ambiente, a baixa latência se torna um
requisito fundamental para esses sistemas. Nesses casos, o uso da nuvem para
aplicações de IdC pode ser prejudicial devido à resultante dependência da
estabilidade de rede e ao relativo alto número de saltos necessários para se alcançar
esses datacenters.
Uma das alternativas que vêm sendo utilizadas para resolver essas questões de
integração entre Nuvem e Internet das Coisas é o modelo de computação de névoa
(fog computing). A visão da Cisco [2014] sobre de computação em névoa, por
exemplo, consiste em transformar as bordas da rede em uma infraestrutura de
computação distribuída, levando vantagens a bilhões de dispositivos já conectados na
IdC. Entretanto, por ainda não ser um termo largamente difundido, não há ainda um
consenso sobre qual a melhor definição para Computação em Névoa Alguns das
definições mais utilizadas por acadêmicos podem ser observadas na Tabela 1:
Tabela 1 – Diferentes definições para o conceito de computação em névoa
Referência Definição Proposta
[YI et al,
2015]
“Computação em névoa é uma proposta para habilitar computação diretamente na
borda da rede, sendo capaz de entregar novas aplicações e serviços especialmente
para a Internet das Coisas”
[Vaquero
apud YI et
al, 2015]
“Um cenário em que um elevado número de dispositivos, descentralizados e ubíquos,
se comunicam e potencialmente cooperam entre si e com a rede para realizar tarefas
de armazenamento e processamento sem a intervenção de terceiros. Estas tarefas
podem ter como objetivo dar suporte a funções básicas de rede ou a novos serviços e
aplicações que executam em ambientes isolados”
[Bonomi et
al, 2012]
“É uma plataforma altamente virtualizada que provê computação, armazenamento e
serviços de rede entre dispositivos finais e servidores tradicionais na nuvem,
tipicamente, mas não exclusivamente, localizados na borda da rede.”
[Gupta et al,
2017]
“Computação em névoa é uma extensão não trivial da Computação em Nuvem – ao
prover serviços computacionais, de armazenamento e de rede próximos à borda de
uma rede empresarial. As características peculiares da névoa são a proximidade aos
usuários finais, sua distribuição geográfica densa, e seu suporte à mobilidade”
Este trabalho assume que o conceito de computação em névoa consiste em uma
abordagem que combina a computação e armazenamento de dados na nuvem e na
borda da rede, fornecimento de serviços que garantam maior distribuição geográfica

16
do sistema/aplicação, menor latência para os dispositivos e/ou seja capaz de buscar
recursos computacionais adicionais na nuvem quando necessário.
1.1 Motivações
Aplicações em Internet das Coisas possui como característica principal a coleta de
informações do mundo físico de forma que elas possam ser processadas e
armazenadas por sistemas computacionais. Por exemplo, considerando uma loja
física de departamentos que utiliza sistema de IdC para coletar dados de compras e
interesses de clientes (e.g., utilização de beacons para localização geográfica de
clientes nas lojas, para verificar as prateleiras e departamentos mais visitados,
identificar os produtos mais comprados, etc...), há interesse em representar esses
objetos de forma que as interações e mudanças de estado que eles possam sofrer
(como ser visualizado e/ou manipulado por um cliente) sejam representados de uma
forma digital. Assim, o processamento de informações passa a depender de uma
versão digital do ativo – também conhecido como gêmeos digitais (digital twins) - para
simulação, análise e processamento de informações das operações presentes e
futuras (em caso de técnicas preditivas estatísticas e de data analytics).
A Gartner [2016] define o conceito de gêmeos digitais como um modelo de software
dinâmico de uma coisa ou sistema físico que confia em dados de sensores para
entender seu próprio estado, responder às mudanças, melhorar operações e adicionar
valor. O conceito de gêmeos digitais está presente indiretamente na fase de gatilho
de inovação (innovation trigger) do gráfico de ciclo de interesse de Internet das Coisas
do Gartner [2016], mostrado na Figura 1. Esse conceito também é parte essencial de
diversas tecnologias, como a convergência entre tecnologia da informação e
tecnologia da operação (“IT/OT Convergence Alignment”), casas conectadas
(“Connected Home”) e, principalmente para a arquitetura de IdC na borda (“IoT Edge
Architecture”).

17
Figura 1 Ciclo de Interesse (Hype Cycle) da Gartner para Internet das Coisas, com as
principais tecnologias emergentes na área. Adaptado de [Gartner, 2016]
Entretanto, o surgimento dessas novas tecnologias também pressupõe o surgimento
de novos riscos, que em médio/longo prazo precisarão ser endereçados. Por exemplo,
a utilização de computação em borda aumenta a superfície de ataque. Assim, os
equipamentos de fornecedores que não estiverem preparados para lidar com esse
novo modelo podem apresentar vulnerabilidades, por exemplo, a ataques de negação
de serviço, ou mesmo servir como portas de entradas para o core da rede [Gartner,
2017]. Por isso, um novo arcabouço de soluções é necessário para enfrentar os
possíveis novos desafios desse cenário de computação mais próxima à borda de rede.
De fato, é possível notar um crescimento significativo de investimentos da indústria e
de interesses em pesquisa em relação ao tema [Ai et al, 2017].
Outro desafio nesse cenário é que o processamento de gêmeos digitais pode ser
complexo [Gartner, 2017], dependendo das informações processadas e das
transações que se deseja realizar. Por exemplo, as diferentes necessidades de
negócio podem exigir que o poder computacional fique mais próximo das coisas ou
das pessoas que geram as informações, por requisitos de latência, segurança e/ou
contexto dos dados. Um pouco por essa razão, atualmente cerca de 10% de todos os
dados gerados nas empresas são criados e processados fora de datacenters
tradicionais, e até 2022 a previsão é de que este cenário possa alcançar os 50%
[Gartner, 2017]. Na perspectiva de um arquiteto de redes e sistemas, essa mudança

18
de paradigma (de 10% para 50%) em relação à localidade de processamento e
armazenamento de dados reside principalmente na infraestrutura de gateways e
backhaul. Afinal, a conexão entre os dispositivos em campo e os datacenters
(normalmente na nuvem) passa a se tornar importante e altamente suscetível a
intermitência e sobrecarga de informações.
1.2 Objetivo
O objetivo do presente trabalho é fornecer uma visão ampla tanto dos diversos
conceitos que fundamentam o modelo de computação em névoa como dos principais
desafios e tecnologias na área. Isso é feito por meio de uma revisão da literatura, a
partir da qual a computação em névoa é comparada com modelos correlatos como
computação em nuvem e computação na borda. Como resultado, busca-se explorar
as características únicas de computação em névoa, identificando-se aplicações que
podem se beneficiar dessa tecnologia.
1.3 Justificativas
Há diferentes paradigmas para propor a integração entre os modelos de nuvem e
Internet das coisas. Ainda que grande parte deles empregue terminologias distintas
para representar conceitos semelhantes, uma característica comum é o fato dos
recursos computacionais serem alocados próximos aos usuários para garantir
mobilidade, localidade e baixa latência [Coutinho, 2016]. Conforme pode ser verificado
na Figura 2, o termo de computação na borda está em tendência de crescimento de
interesse (hype) em buscas realizadas na rede mundial de computadores. Na Figura
2 também é possível identificar a popularidade de alguns dos principais paradigmas
de computação na borda, como computação em névoa, computação móvel de borda
e cloudlet, sendo a névoa o termo mais popular dentre eles.

19
Figura 2 – Paradigmas de computação na borda (termos em inglês): busca de termos de
acordo com o Google Trends. Extraído de [Google Trends1
, 2018]
Em suma, a computação em névoa expande o paradigma de computação em nuvem
para a borda da rede, buscando atingir requisitos que ainda não eram endereçados
apenas na nuvem. Enquanto computação em névoa e em nuvem usam os mesmos
recursos (rede, computação e armazenamento), e compartilham os mesmos
mecanismos e atributos (virtualização, multi-tenancy), há diferenças fundamentais
entre os modelos – e a visão de névoa foi concebida para endereçar aplicações que
não funcionam completamente bem exclusivamente na nuvem [Bonomi et al, 2014]:
• Aplicações que requerem latências muito baixas e previsíveis: a nuvem liberta
os usuários de maiores detalhes da implementação, incluindo o conhecimento
preciso de onde a computação e o armazenamento acontece;
• Aplicações geodistribuídas: como exemplos, podem ser citados monitoramento
de encanamento e redes de sensores para monitoramento do ambiente;
• Aplicações rápidas móveis: inclui exemplos como carros inteligentes e
conectados, bem como vias conectadas;
• Sistemas de controle distribuídos em larga escala: por exemplo, redes elétricas
inteligentes (smart grids), vias conectadas, sistemas inteligentes de iluminação
pública, entre outros.
1
Consulta em https://trends.google.com.br/trends/

20
1.4 Estrutura do Trabalho
O restante deste documento está organizado da seguinte maneira:
• Capítulo 2 apresenta a fundamentação teórica dos principais conceitos de
computação na borda de rede e do modelo de computação em névoa e seus
componentes, além da abordagem em diferentes aspectos do modelo, como
arquitetura, segurança da informação, estrutura das redes de comunicação,
fluxo e análise de dados;
• Capítulo 3 apresenta a comparação entre os diferentes modelos
computacionais abordados durante a etapa de fundamentação teórica e
apresentação das principais características da computação em névoa. A partir
dessa comparação, discute-se alguns dos principais fatores que podem ser
levados em consideração no momento de decidir qual o melhor modelo
computacional, e define uma técnica (árvore de decisão) para auxiliar na
escolha;
• Capítulo 4 utiliza alguns exemplos de aplicações que podem utilizar o modelo
de computação em névoa, utiliza os fatores definidos previamente no capítulo
3 e apresenta como a névoa pode gerar valor para o negócio (fogonomics);
• Capítulo 4 apresenta as conclusões e considerações finais do trabalho,
incluindo as contribuições dessa pesquisa e futuras oportunidades de trabalho;
• Glossário: apresenta descrição de termos técnicos e específicos utilizados
durante todo o trabalho.

21
2 FUNDAMENTAÇÃO TEÓRICA
O estado da arte da computação em névoa envolve a discussão de nomenclaturas,
aplicações e casos de uso, bem como diferentes técnicas e tecnologias aplicadas para
resolver situações específicas do modelo e novos desafios computacionais.
O objetivo desse capítulo é apresentar os principais conceitos envolvidos no cenário
de computação em névoa. Para isso, primeiramente são discutidos os principais
modelos de computação na borda da rede, em especial o modelo de computação em
névoa, incluindo a definição do conceito de nó na névoa. Em seguida, na seção 2.2,
serão discutidos aspectos de arquitetura da informação dos modelos de computação
em névoa e, posteriormente, na seção 2.3, são apresentados aspectos de segurança
da informação, incluindo proteção e privacidade de dados. Em sequência, na seção
2.4, há a definição de algumas formas de organização de nós em uma rede em névoa,
incluindo técnicas de gestão de redes e fluxos de dados.
2.1 Modelos de computação na borda de rede
Desde sua concepção, o modelo de computação em névoa tem sido percebido como
um modelo de computação na borda (edge computing). Tal conceito inclui também os
modelos de cloudlets, computação móvel na borda (mobile edge computing), entre
outros, como sistemas de transportes inteligentes em nuvem (ITS-Clouds), VANETs
(Redes Ad-Hoc de redes veiculares) e CDN (Content Delivery Networks) [Tordera et
al, 2018]. A computação na borda é um modelo de arquitetura de TI que é aberto e
distribuído, e possui como principais características o processamento descentralizado
e local (ao invés da transmissão frequente a um datacenter central). Um dispositivo
de borda seria qualquer coisa que forneça um ponto de entrada para uma rede, como
gateways e roteadores.
2.1.1 Cloudlets
Basicamente, os cloudlets são datacenters de nuvem em pequena escala que ficam
localizados próximo a borda da rede. Mais formalmente, de acordo com
Satyanarayanan et al [2009], um cloudlet é um computador confiável, com grandes
recursos computacionais ou um cluster de máquinas que são altamente conectadas

22
com a Internet e disponível para uso de dispositivos próximos. Acessos a recursos
computacionais normalmente fica a um salto (hop) de uma rede local sem fio.
Quando comparado com os modelos tradicionais de nuvem, há algumas
características exclusivas de cloudlets [Ai et al, 2017]: (i) necessidade de ser mais ágil
no provisionamento de recursos para ser tolerante à grande variação de densidade
de dispositivos durante sua operação; (ii) as informações e serviços que estão
concentrados em um determinado nó cloudlet precisam ser projetadas de forma que
elas possam ser transferidas para outro nó de acordo com a mobilidade dos usuários;
e (iii) os dispositivos móveis devem ser capazes de descobrir, selecionar e associar-
se com o nó cloudlet apropriado dentre as diversas opções que lhe forem fornecidas.
Conforme apresentado na Figura 3 [Ai et al, 2017], o modelo de cloudlet pressupõe o
uso de uma máquina virtual que deve ser pré-carregada na infraestrutura antes da
conexão de qualquer usuário. Ao se conectar, a aplicação do dispositivo envia um
pacote com informações personalizadas do cliente, de modo que esses dados são
utilizados para sobrescrever a VM base do cloudlet (VM overlay). Em seguida, a base
e as informações fornecidas pelo cliente serão sintetizadas e uma nova instância de
máquina virtual é criada para aquele dispositivo. Quando a conexão é desfeita, o
cloudlet descarta a máquina virtual criada e encaminha um pacote de informações
(VM residue) para o dispositivo, que pode utilizá-las, por exemplo, para iniciar a
instância em outro nó cloudlet.

23
Figura 3 - Resumo da interação entre cloudlets e dispositivos. Adaptado de [Ai et al, 2017]
2.1.2 Computação móvel na borda
De acordo com o Instituto de Padrões de Telecomunicação Europeu [ETSI, 2014], a
computação móvel na borda é capaz de prover serviços de tecnologia da informação
e capacidades de computação em nuvem na borda de redes móveis, com redes de
acesso por rádio (RAR) e próximo aos dispositivos móveis. Conforme explicado por Ai
et al [2017], a computação móvel na borda pode ser usada em conjunto com um
ambiente NFV (Network Functions Virtualization – Virtualização das Funções da Rede)
De forma simplificada, o NFV permite que, ao invés da utilização de hardwares
dedicados (para funções como NAT, firewall, DNS, etc), utilizem-se softwares
executados em máquinas virtuais. Nesse caso, a computação móvel na borda utiliza
todas as entidades e interfaces de gestão e orquestração do NFV.
A computação móvel na borda é um paradigma que pretende complementar as
necessidades do modelo de uso de computação móvel apenas na nuvem, com foco
especificamente nos requisitos de baixa latência, economia de energia, sensibilidade
ao contexto e melhoria da privacidade e segurança [Mao et al, 2017]. A Tabela 2
apresenta uma breve comparação entre os dois modelos:

24
Tabela 2 – Comparação entre modelos de computação móvel. Adaptado de [Mao et al,
2017]
Computação móvel na borda Computação móvel na nuvem
Hardware do servidor
Datacenters de pequena escala,
com recursos moderados
Datacenters de larga escala, com
servidores de alta capacidade
Localidade do
servidor
Alocado com gateways wireless,
roteadores wifi e bases de rádio
LTE
Instalado em construções
dedicadas, com tamanhos de
campo de futebol
Implementação
Implementado por operadores de
telecomunicações, fornecedores
diversos e usuários domésticos.
Implementado por empresas de TI
(Google, Amazon). Requer
configuração e planejamento
complicado
Distância dos
usuários
Pequena (algumas dezenas de
metros)
Alta (pode ultrapassar a fronteira de
países)
Uso do backhaul
Não frequente, ajuda a aliviar o
congestionamento
Uso frequente, normalmente causa
congestionamento
Gestão do sistema
Controle hierárquico
(centralizado e distribuído)
Controle centralizado
Suporte a latência Menor que 10ms Maior que 100ms
Aplicações
Sensíveis a latência e de
computação intensiva
Tolerante a latência e de
computação intensiva
2.1.3 Nós na computação em névoa
A grande diferença conceitual entre a computação em névoa e os demais modelos de
computação na borda refere-se às características específicas que um nó em uma rede
de névoa (Fog Node) pode assumir. Sobre isso, Tordera et al [2018] afirma que é
possível atribuí-lo ao conceito de Névoa para Nuvem (Fog to Cloud, F2C) onde a
gestão de todos os recursos acontece de forma coordenada e em camadas (desde a
nuvem até a borda), propiciando serviços colaborativos baseado em clusters de
recursos e compartilhamento de informações.
Na Figura 4, é possível verificar um modelo clássico de arquitetura Névoa para a
Nuvem, evidenciando duas definições distintas e características de um nó:
• A camada de névoa 1, que indica um nó intermediário entre o processamento
local e o da nuvem, quase sempre com características de servidor. Assim, essa
camada assemelha-se a uma pequena nuvem e/ou gateway, capaz de fornecer
serviços de IdC e processar dados coletados pelos dispositivos de borda.
• A camada de névoa 2, que se refere à camada mais próxima dos dispositivos
de borda – sensores, celulares, etc. Basicamente, essa camada trata o nó de
névoa como um conjunto de componentes (que incluem servidores e
dispositivos de borda) com mecanismos agregadores e controladores das

25
capacidades da borda, como armazenamento, computação, sensoriamento e
rede; e
Figura 4 - Modelo de arquitetura Névoa para Nuvem. Adaptado de [Tordera et al, 2018]
Nesse cenário, há diversos papéis que um nó pode assumir [Tordera et al, 2018]: (i)
mero produtor de dados (nó “burro”); (ii) dispositivos de borda que processam seu
próprio dado e os de sensores conectados (nós inteligentes), e; (iii) dispositivos de
borda oferecendo capacidade de TI para executar serviços externos (nós
verdadeiramente inteligentes). Além das definições de acordo com o papel dos
dispositivos de borda, pode haver outras classificações quanto às estratégias de
processamento, como, por exemplo: dispositivos de borda oferecendo suas
capacidades de TI uns para os outros (computação distribuída), o que exige
normalmente um gerenciador e/ou alocador de recursos e tarefas; e dispositivos de
borda com processamento distribuído e offline.
Uma definição de um nó na computação em névoa é fornecida por Tordera et al [2018],
que os classifica como entidades distribuídas de computação em nuvem, em um
cenário composto por ao menos um dispositivo físico com capacidades de
sensoriamento e/ou processamento, que possibilitam a implementação de serviços na
névoa.
2.2 Arquiteturas de computação em névoa

26
De acordo com o OpenFog Consortium [2017], a arquitetura de computação em
nuvem possui múltiplas camadas, utilizando-se o conceito de Fog-to-Cloud (F2C). No
geral, o servidor de névoa pode ser hospedado em dispositivos das camadas de
acesso (borda da rede) ou em camadas mais próximas ao dispositivo final. A
computação em névoa funciona como uma extensão aos serviços da nuvem e como
provedor de recursos para os dispositivos de IdC.
Um mesmo ecossistema de computação em névoa pode respeitar diferentes
arquiteturas, que podem coexistir em um mesmo arranjo. Isso é ilustrado na Figura 5,
que mostra diferentes possibilidades: (i) névoas privadas referem-se a estruturas
privadas de computação em névoa, normalmente utilizam arquiteturas F2C ou
proprietárias; (ii) névoas públicas consistem em estruturas públicas (e.g., smart cities)
em arquiteturas F2C, utilizando protocolos abertos e potencialmente também
computação distribuída (e.g., um blockchain); (iii) indie fogs são estruturas que
utilizam os dispositivos do próprio usuário final (como celular, roteador, carro,
sensores, etc.) como parte do nó de névoa, permitindo maior interoperabilidade de
serviços e também incluindo integração de redes privadas e públicas.
Figura 5 Exemplos de arranjo de computação em névoa: diferentes arquiteturas e nós de
computação em névoa em um mesmo sistema. Adaptado de [Buyya et al, 2016]

27
2.2.1 Conceito de arquitetura F2C e arquitetura de referência
O conceito de F2C pode ser explorado como base para a definição da arquitetura do
sistema, considerando a computação em névoa como um paradigma complementar à
computação em nuvem. O principal objetivo de uma arquitetura de névoa para nuvem
é prover a capacidade de executar serviços enquanto garante-se baixo tempo de
resposta, redução de carga na rede e melhor eficiência energética [Ramirez et al,
2017]. De acordo com Bruin et al [2016], o conceito de F2C baseia-se em uma
arquitetura de recursos hierárquicos, baseada em camadas de estrutura heterogênea
entre os recursos da nuvem e da névoa.
Uma arquitetura F2C é baseada em dois domínios de gestão [Ramirez et al, 2017]:
camadas e áreas. A camada é um conjunto de dispositivos com características e
recursos similares; já áreas são conjuntos de dispositivos conectados, próximos
fisicamente ou logicamente, em uma mesma camada. Os nós de névoa 0são os
componentes das áreas, enquanto as camadas são as representações verticais
distribuídas de acordo com suas funcionalidades (vide Tabela 3):
Tabela 3 – Descrição de camadas F2C. Baseado em [Buyya et al, 2016]
Camada Descrição da camada
1. Nuvem
Conjunto de servidores estáticos que se localizam em datacenters (próprios
e/ou em nuvem). Ela provê níveis mais altos de recursos computacionais
quando necessário
2. Centro (core) da
rede
Infraestrutura de rede/comunicação principal (backbone)
3. Borda de rede
Camada de comunicação entre os nós de névoa e demais redes (backhaul).
É responsável por garantir a transferência de informações entre a nuvem e os
dispositivos finais.
4. Gateway /
Infraestrutura do
cliente
Corresponde à conexão entre os dispositivos finais e as estruturas de
comunicação de dados, podendo ser compostas por gateways e outros
dispositivos de usuários finais (como roteadores)
5. Dispositivos
finais
Dispositivos finais (sensores, atuadores, etc) responsáveis pela coleta de
dados
O OpenFog Consortium [2017] propôs uma arquitetura abstrata de referência aberta
para computação em névoa baseada no conceito de F2C (vide Figura 6. A arquitetura
de referência propõe algumas perspectivas (segurança da informação, gerenciamento
de recursos, desempenho e escala, controle e análise de dados, negócios e
aplicações na névoa), além de recursos e serviços (redes, computação, virtualização,
etc) que são parcialmente explorados nas próximas seções deste trabalho.

28
Figura 6 – Arquitetura de referência baseada em perspectivas e recursos/serviços. Adaptado
de [OpenFog Consortium, 2017]
2.2.2 Arquitetura integrada aos equipamentos dos usuários finais (Indie Fog)
O F2C possui algumas limitações, especialmente no que diz respeito ao uso de
equipamentos que funcionam exclusivamente com serviços específicos dos
provedores, ou apenas em redes móveis. Uma proposta para tentar reduzir esse
problema é utilizar o conceito de Indie Fog [Buyya et al, 2016], que sugere a utilização
dos próprios dispositivos dos usuários, também conhecidos como customer premises
equpments (CPEs), em parte da arquitetura de computação em névoa. A
implementação desse modelo pode acontecer em dois modos (a) de forma integrada,
os serviços de névoa são fornecidos através de um nó gateway conectado aos
dispositivos finais; (b) de forma colaborativa, os serviços de névoa são providos por
alguma estação de trabalho na mesma rede dos dispositivos finais. Em ambos os
casos, a nuvem fornece um pacote de aplicação que habilita as funções do sistema
no nó de indie fog.
O modelo de Indie Fog pode ser implementado de diferentes formas, dependendo das
características do sistema alvo. Em [Buyya et al, 2016], são apresentadas quatro
formas ilustrativas:

29
1) Modelo clusterizado: aplicável sempre que há nós estacionários de indie fog
próximos (como nós em um mesmo edifício). A criação de clusters permite alto
desempenho de processamento dos dados coletados e reduz a necessidade
de envio de dados para a nuvem;
2) Modelo de infraestrutura: aplicável sempre que há nós estacionários de indie
fog em infraestrutura de áreas urbanas a céu aberto. Este tipo de modelo é útil
para situações onde um terceiro requer processamento e aquisição de dados
em curto período de um conjunto de dispositivos de infraestrutura urbana;
3) Modelo veicular: aplicável para nós dinâmicos (normalmente alocados em
veículos) de indie fog. Este modelo permite a coleta e processamento de dados
em movimento, possibilitando o streaming de dados com mobilidade;
4) Modelo de smartphones: aplicável para nós de indie fog que utilizam a
infraestrutura de smartphones.
Na concepção de uma arquitetura em modelo de indie fog, Buyya et al [2016] baseia-
se em uma arquitetura orientada a serviços (SOA) com três entidades principais:
registrador, provedor e consumidor dos serviços. A entidade registradora tem papel
fundamental na conexão do nó cliente com o servidor indie fog, de forma a garantir
segurança, catálogo de serviços e tratamento de requisições/dados. Os provedores
podem publicar seus serviços nas entidades registradoras em formatos padrão (Open
Data Protocol), de modo que os consumidores podem então consultar o serviço mais
recomendável e selecionar provedores de acordo com sua localização ou capacidade.
Após o estabelecimento da conexão, o cliente e o servidor podem interagir de ponta
a ponta.
2.3 Segurança da Informação
A segurança da informação é um dos grandes desafios para a computação em névoa,
e isso acontece porque [Roman et al, 2018]:
• Não basta apenas proteger os blocos/nós, mas também é necessário
orquestrar todas as diversidades de mecanismos de segurança do sistema – o
que exige integração e interoperabilidade das técnicas empregadas;

30
• O surgimento de novas aplicações e modelos de computação em névoa e IdC
traz consigo modificações na superfície de ataque, e novas ameaças surgem
de acordo com as peculiaridades do sistema;
• Considerando o nível de pervasividade que os dispositivos de IdC e
computação em névoa, a coleta de dados pessoais frequentes exige uma maior
preocupação com a proteção e privacidade dos dados.
O McAfee Labs indica que há uma quantidade significativa de ataques baseados em
dispositivos de Internet das Coisas, especialmente com botnets para ataques de
negação de serviço [McAfee, 2018]. Os ataques ocorrem devido, principalmente, ao
pouco cuidado com segurança nesses dispositivos e ao alto valor agregado dos dados
coletados.
2.3.1 Proteção de dados e privacidade contra os ataques internos e externos
Considerando a geodistribuição e heterogeneidade dos sistemas de computação em
névoa, a primeira conscientização que deve ser feita quanto à segurança da
informação refere-se à ausência de perímetros globais nas bordas da rede [Roman et
al, 2018]. Em resumo, uma mesma estrutura de computação em névoa dificilmente
será gerenciada exclusivamente por um único proprietário: é mais provável que haja
vários atores (incluindo os usuários finais), o que exigirá maior esforço na cooperação
entre eles. Segundo o OpenFog Consortium [2017], a segurança em sistemas de
computação em névoa deve ser de ponta a ponta, desde o dado na nuvem até os
dispositivos finais – de forma a criar mecanismos que garantam a confiabilidade em
cada um dos nós na rede.
Para identificação dos principais riscos atrelados a computação em névoa, Roman et
al [2018] define os principais ativos que a compõem (a saber, infraestrutura de rede,
dispositivo de borda, máquinas virtuais e dispositivos finais) e elenca as principais
vulnerabilidades de cada um, conforme mostrado na Tabela 4. Analisando essa tabela,
nota-se que a maioria das vulnerabilidades já são conhecidas dos paradigmas
tradicionais de computação, principalmente porque boa parte dos ativos relacionados
são compartilhados dos datacenters tradicionais. Entretanto, para cada uma dessas
vulnerabilidades, é preciso dar destaque para as especificidades das

31
descentralizações, localização, mobilidade, interoperabilidade, baixa latência, entre
outras características intrínsecas da computação em névoa.
Tabela 4 – Resumo das principais vulnerabilidades em ambiente de computação em névoa.
Adaptado de [Roman et al, 2018]
Ativo Vulnerabilidades
Infraestrutura de rede Negação de serviço (DoS), Homem no meio, Gateway intruso
Dispositivo de borda
Dano físico, perda de privacidade, escalação de privilégios,
manipulação de serviços, Datacenters intrusos
Máquinas virtuais
Negação de serviço (DoS), uso indevido de recursos, perda de
privacidade, manipulação de máquinas virtuais
Dispositivos finais Injeção de informação, manipulação de serviço
As vulnerabilidades citadas na Tabela 4 podem ser observadas na computação em
névoa da seguinte forma [Roman et al, 2018]:
• Vulnerabilidades na infraestrutura de rede: os ataques de negação de serviços
(DoS) têm como objetivo afetar a disponibilidade de nós específicos, já que a
característica distribuída da névoa dificulta indisponibilidade total.
Considerando toda a heterogeneidade que uma estrutura de computação em
névoa pode ter, equalizar a segurança em toda a superfície de ataque pode ser
um desafio. Entretanto, outra possibilidade é o atacante inserir seu próprio
dispositivo malicioso na rede, na função de um gateway, para controlar os
fluxos de comunicação e interceptar informações (ataque de “homem no
meio”).
• Vulnerabilidades nos dispositivos de borda: considerando que as informações
na computação em névoa são transmitidas (e, às vezes, armazenadas e
processadas) na borda da rede, esta passa a ser um dos ativos mais visados
por atacantes. Um possível ataque é comprometer os nós da borda da rede,
normalmente escalando privilégios e controlando serviços essenciais da rede
e da névoa. Outra possibilidade para o atacante é inserir datacenters
comprometidos na estrutura de névoa para controle total dos serviços e de
outros nós da borda.
• Vulnerabilidades nas máquinas virtuais (MV): o principal objetivo de ataques a
máquinas virtuais é explorar os recursos disponíveis, seja para indisponibilizar
algum serviço ou recurso ou conseguir escalação de privilégio. A manipulação
do hypervisor, por exemplo, permite a manipulação de todas as máquinas

32
virtuais por ele gerenciadas, bem como a instalação de malwares para explorar
vulnerabilidades da rede, da borda e de dispositivos finais.
• Vulnerabilidades nos dispositivos finais: os dispositivos finais não são apenas
consumidores, mas também provedores de toda a informação do sistema.
Portanto, são peças fundamentais para a segurança dessas informações. As
principais formas de ataques estão relacionadas à injeção de informação, isto
é, usar dispositivos maliciosos para fornecer dados incorretos ou difundir
malware pela rede.
Essa relação indica que uma tática de ataque bastante comum ao modelo de
computação em névoa é comprometer nós específicos da rede para obter alguns
privilégios dentro do sistema. Esses ataques podem ser não-autenticados (ataques
externos) e/ou ataques não autorizados (ataques internos). De acordo com o governo
norte-americano (PwC apud Sohal et al, 2017), 34% de todos os crimes cibernéticos
provêm de ataques internos e 31% de ataques externos (hardware, software e/ou
rede). A aplicação de mecanismos de segurança nesse cenário torna-se
especialmente relevante porque a névoa pode ser tanto alvo de ataques quanto o
agente causador deles. Por exemplo, um atacante pode tanto desferir ataques de
DDoS a uma aplicação em névoa, quanto usar os nós da névoa para realizar ataques
DDoS a outros sistemas e servidores, como ilustrado na Figura 7.

33
Figura 7 – Exemplos de ataques contra a nuvem e a utilizando como agente malicioso.
Adaptado de [Hu et al, 2017]
Para que os administradores dos sistemas de computação em névoa consigam criar
controles suficientes para proteção dos dados, é necessário criar um cenário de
ameaças e mapeamento do risco de segurança da informação (SI). Considerando
algumas das propriedades da SI (confidencialidade, integridade, autenticação,
disponibilidade e privacidade), o OpenFog Consortium [2017] construiu um
mapeamento das principais ameaças, conforme mostrado na Tabela 5. Foi realizado
um cruzamento das propriedades com os ataques internos e externos, e mapearam-
se os principais tipos de ataques que podem afetar a computação em névoa.
Tabela 5 – Exemplos de ataques a infraestrutura de segurança de um sistema de computação
em névoa. Adaptado de [OpenFog Consortium, 2017]
Ataques Confidencialidade Integridade Autenticação Disponibilidade Privacidade
a. Ataques
internos
Vazamento de
dados
Alteração de
dados
Vazamento de
identidade /
senha
Sabotagem de
equipamento
Vazamento
de dados
b. Ataques
ao hardware
Trojans, Ataques de
canais
Trojans Trojans
Radio jamming,
exaustão de
banda
Trojans,
Ataques de
canais
c. Ataques
software
Malware Malware Malware
Negação de
serviço (DDoS),
esgotamento de
recursos
Malware,
análise de
redes sociais

34
d. Ataques
de rede
Eavesdropping
Repetição de
transação /
mensagem
Spoofing,
Homem no
meio
Negação de
serviço (DDoS),
Flooding
Análise de
padrão de
tráfego
2.4 Fluxo de informação na névoa
Uma das premissas da computação em névoa é que trazer parte das capacidades da
computação em nuvem para a borda da rede (ou o mais próximo possível dos
dispositivos finais) aumenta o desempenho do sistema como um todo [OpenFog
Consortium, 2017]. Um sistema que utiliza computação em névoa deve ser capaz de
medir seu desempenho de forma a garantir a entrega de valor, otimizar o uso de
recursos, e garantir escalabilidade para a rede de acordo com seu crescimento.
Portanto, além da geração de indicadores, a gestão de desempenho e escala
dependem, entre outras coisas, da estrutura e organização da rede e da interação
entre as entidades de rede, conforme discutido a seguir.
2.4.1 Gestão de rede
A computação em névoa aproveita-se de novas técnicas de redes que estão surgindo
na indústria de telecomunicações, como [Coutinho et al, 2016]:
• Redes programáveis: tecnologias como Virtualização das Funções da Rede
(Network Functions Virtualization, NFV) e Redes Definidas por Software
(Software Defined Network, SDN) facilitam a implantação da computação em
névoa. Ambas permitem que se utilize a infraestrutura existente de rede e crie-
se, a partir dela, novas organizações e estruturas independentes da
organização do hardware subjacente. Com uma SDN é possível separar os
domínios de controle e comunicação de dados, criando-se um nó Controlador
que permite o controle centralizado da rede. O controlador SDN possibilita a
gestão estratégica, pois automatiza as configurações e provisionamento de
toda a malha de comunicação, provendo mobilidade e recursos de rede sob
demanda;
• Fatiamento (slicing) de rede: O slicing possibilita que uma mesma infraestrutura
física de rede se comporte de modo diferentes para fins específicos, atendendo
aos diferentes requisitos dos usuários finais. A Figura 8 apresenta um exemplo
de fatiamento de rede para duas aplicações que possuem demandas diferentes
durante o dia e à noite. O link Slice-1 exige mais da rede pela manhã, e por

35
isso ganha maior prioridade, inclusive com redução do número de hops para
diminuição de latência; já o link Slice-2 tem uma carga maior à noite.
Figura 8 – Diferentes provisionamentos de rede SDN de acordo com a variação da
demanda, usando técnica de slicing. Adaptado de [Gomez et al, 2018]
O uso do SDN é também útil para endereçar algumas das necessidades da
computação em névoa como o controle do fluxo de dados e orquestração de serviços,
considerando não só cenários de variação de demanda, mas também de mobilidade.
Por exemplo, considere o cenário mostrado na Figura 9, em que um usuário no
campus A de uma universidade precisa se deslocar ao campus B, distante
geograficamente. Tradicionalmente, seria necessário realizar o handover de
informações, i.e., a transição de uma aplicação de uma unidade móvel a outra de
forma transparente ao usuário para que ele continuasse a usar uma mesma aplicação
sem perda de dados. Essa técnica pode ser aplicada em sistemas de computação em
névoa através de controladores SDN, com o mínimo de perda de desempenho ou de
eficiência do sistema [Baktir et al, 2017].

36
Figura 9 – Exemplo de hangover com SDN com a movimentação entre campi de uma
universidade – suporte à mobilidade. Adaptado de [Baktir et al, 2017]
Essas tecnologias incrementam a escalabilidade e gestão de custos de redes de
computação em névoa, já que auxiliam na alocação de recursos, migração de
máquinas virtuais, monitoramento do tráfego e gestão dos serviços de rede.
2.4.2 Fluxo de dados
Com a coleta de grande quantidade de dados proveniente dos dispositivos de Internet
das Coisas, há a necessidade do desenvolvimento de estratégias de análise e
tratamento desses dados. Se por um lado a computação em névoa é muito útil para
garantir a localidade, baixa latência e proximidade do contexto com os dados, por
outro a computação em nuvem permite uma gestão mais centralizada e global dos
dados [Coutinho et al, 2016]. Para tirar proveito das diferentes capacidades de cada
modelo, é comum que o fluxo de informação em um sistema de computação em névoa
varie de acordo com a aplicação. A Figura 10 traz um exemplo. A estrutura pressupõe
um servidor mestre, alocado na nuvem (com algumas máquinas auxiliares, ou
escravas), que é o destino das informações que percorreram o sistema (normalmente
dados de negócio). Há alguns nós no sistema, entre os dispositivos e a nuvem, que

37
são responsáveis pela maior parte do processamento local na névoa, em conjunto
com os dispositivos de borda. Esses nós processadores podem ou não compor um
mesmo nó de névoa com os dispositivos de borda. Em ambos os casos, eles também
possuem a possibilidade de comunicar-se com a infraestrutura final com propósitos
de controle, como acionar atuadores, compartilhar dados e autoconfiguração, ou atuar
como controladores SDN.
Figura 10 – Exemplo de fluxo de informações em modelo de computação em névoa. Adaptado
de [Tang et al, 2017]
O grande volume de dados gerados pelos dispositivos de Internet das Coisas pode
causar congestionamento de rede, especialmente nas camadas hierarquicamente
superiores (i.e., na comunicação com a nuvem), onde há a convergência desses
dados. Existem duas estratégias principais para evitar congestionamentos no tráfego
de rede e poupar banda em modelos de computação em névoa: o processamento
local (offload) e a utilização de técnicas de agregação de dados [Lu et al, 2018]. O
offload utiliza a capacidade computacional dos dispositivos de borda da rede e/ou dos
dispositivos finais para processar localmente as informações coletadas, sem a
necessidade de utilizar a nuvem. A agregação de dados consiste no emprego de
técnicas (e.g., sumarização e anonimização) para combinação de dados, gerando
uma informação concisa, de maior valor agregado e não repetida. Dessa forma, a
agregação permite o envio com menor frequência e usando pacotes de dados mais
reduzidos para a nuvem. Esses pacotes contêm apenas informações essenciais e que
não podem ser processadas localmente, como apresentado na Figura 11.

38
Figura 11 – Computação em névoa com procedimento de agregação de dados para poupar
banda de rede com a nuvem. Adaptado de [Lu et al, 2017]
2.4.3 Análise das informações
De acordo com Bonami et al. [2014], a análise dos dados inicia-se principalmente a
partir das camadas de gateways, e os dados são processados de acordo com as
necessidades em cada uma das camadas superiores, da seguinte forma (vide Figura
12):
• O fluxo de informação envolve tanto as comunicações entre máquinas
(machine-to-machine, M2M), principalmente nas camadas mais próximas dos
dispositivos, quanto as interações de pessoas com o sistema (human-machine
interface, HMI);
• Nas camadas mais baixas que exigem menor latência, as análises precisam
ser feitas de forma mais rápida (milissegundos e segundos), focadas nos dados
operacionais ou dados brutos coletados dos dispositivos;
• Em camadas intermediárias (nós computacionais) são realizadas análises
próximas ao tempo real, com possibilidade de interação com as pessoas (e.g,
para visualização das transações). Também é possível fazer análise de dados
históricos, usada como fonte auxiliar para tomada de decisão, análise de
tendências e previsões;
• Em camadas superiores (na nuvem) é possível fazer análises mais complexas,
que necessitam de maior poder computacional. Nesse caso, pode-se utilizar

39
técnicas de big data e business intelligence (BI), gerando os dados de valor
mais agregado;
• A distribuição das análises de dados em camadas auxilia na maior
contextualização dos dados, possibilitando maior entendimento dos fenômenos
ambientais e/ou humanos que são coletados.
Figura 12 – Esquema com diferentes etapas da análise de dados na computação em névoa.
Adaptado de [Bonomi et al, 2014]
2.5 Considerações sobre o capítulo
Este capítulo abordou diferentes aspectos e características da computação em névoa,
principalmente em termos de arquitetura, segurança da informação, redes e controle
de dados. Tais informações são importantes não apenas para entender o
funcionamento do modelo de computação em névoa, mas para definir diretrizes para
definição de fatores de tomada de decisão quanto ao modelo de computação que será
escolhido ao se planejar um sistema, com será visto no capítulo a seguir.

40
3 COMPARAÇÃO ENTRE MODELOS COMPUTACIONAIS
A utilização cada vez mais frequente de computação em névoa leva a um grande
arcabouço de soluções e aplicações que buscam gerar valor aos negócios,
especialmente aqueles que utilizam sistemas de Internet das Coisas. Esse novo
cenário econômico envolvendo a névoa foi denominado por Weinman [2017] de
fogonomics, ou “nevoaeconomia” em tradução livre. Fogonomics refere-se ao quanto
os fatores econômicos afetam na definição das arquiteturas de névoa, às
consequências econômicas aos usuários e operadores, e às interações econômicas
entre os usuários finais e os provedores de serviços [Zheng et al, 2017]. Esse novo
cenário gera novas oportunidades para que usuários e demais atores envolvidos
nessas interações econômicas consigam otimizar custos no transporte e
processamento de dados.
3.1 Fatores para adoção de diferentes modelos de computação: nuvem vs.
borda
Weinman [2017] aborda diversos trade-offs entre diferentes modelos computacionais
de nuvem e computação na borda. Isso inclui, por exemplo, aumento de receita
diretamente relacionado com a diminuição do tempo de resposta, o que por outro lado
pode acarretar aumentos no custo do sistema. Diferentes autores definem alguns
critérios específicos de acordo com as necessidades. Por exemplo, Baktir et al [2017]
define a relação entre a complexidade e regularidade de determinado sistema em
função de sua proximidade necessária dos usuários finais; usando esses critérios, a
computação em névoa seria recomendável caso o ambiente seja complexo, irregular
e precise estar próximo à borda da rede (vide Figura 13).

41
Figura 13 - Espectro para tomada de decisão de implementação baseados na relação entre
complexidade e proximidade do sistema. Adaptado de [Baktir et al, 2017].
O principal requisito de negócio que estimula o uso de paradigmas de borda como a
computação em névoa é a latência. Logo, a questão da distância entre o servidor e os
usuários passa a ser um dos fatores importantes na escolha do modelo. Bilal et al
[2018] realizou um estudo do efeito das distâncias sobre variáveis de rede relevantes,
como RTT (Round Trip Time, i.e., tempo de um pacote ir e voltar de um ponto de
origem a um destino), perda de pacotes e vazão (dados transferidos por intervalo de
tempo), de acordo com a distância do servidor.
Tabela 6 – Efeitos da distância no RTT, perda de pacotes, vazão e tempo de download.
Adaptado de [Bilal et al, 2018]
Distâncias (servidor até usuário) RTT Perda de pacote Vazão
Local: < 100 milhas 1,6 ms 0.6% 44 Mbps
Regional: 500-100 milhas 16 ms 0.7% 4 Mbps
Continental: ~3.000 milhas 48 ms 1.0% 1 Mbps
Intercontinental: ~6.000 milhas 96 ms 1.4% 0.4 Mbps
Para Bilal et al [2018], o principal trade-off que precisa ser considerado é a relação
entre a frequência/volume de dados que precisam ser transferidos para o servidor e
os requisitos de tempo real do sistema. O autor também define quais os tipos de
operações mais recomendáveis para os modelos de computação em borda em
oposição a modelos tradicionais de nuvem (vide Figura 14).

42
Figura 14 – Espectro para tomada de decisão de implementação de sistemas baseados na
relação entre volume de dados enviados e requisitos de tempo real. Adaptado de [Bilal et al,
2018].
3.2 Comparação de fatores entre a nuvem e a computação na borda
Considerando os trabalhos de [Baktir et al, 2017], [Borcoci, 2016], [Dolui et al, 2017] e
[Roman et al, 2018], alguns dos principais fatores abordados são os apresentados na
Tabela 7. Além das questões de latência levantadas anteriormente, na comparação é
possível destacar três pontos relevantes: mobilidade, custo e uso de recursos
computacionais. Em termos de mobilidade, é possível verificar que a computação na
borda permite um número maior de dispositivos consumidores de conteúdo (alta
escalabilidade), além de disponibilidade variável e redundância. Em termos de custos,
o investimento na computação em nuvem normalmente é maior, já que o custo por
máquina é alto e exige grande quantidade de servidores, enquanto os dispositivos de
borda são mais simples e baratos. Entretanto, de acordo com o número de dispositivos
utilizados em um sistema IdC, pode aumentar o custo de implementação de um
sistema em névoa devido a escala – podendo ser mais caras que os datacenters
tradicionais. Em relação ao uso de recursos, os servidores da nuvem possuem maior

43
capacidade e desempenho, enquanto os servidores de borda normalmente lidam com
cenários de dispositivos com maior limitação de recursos computacionais e energia.
Tabela 7 – Comparação entre o modelo de computação em nuvem e os modelos de
computação na borda. Fonte: Autor.
Fatores Computação na nuvem Computação na borda
Consumidor de conteúdo Dispositivos finais Qualquer coisa
Contexto do local Não Sim
Disponibilidade Alta (99,99%) Alta (altamente volátil e redundante)
Distância dos usuários
Longe dos usuários e comunicação
através de redes IP
Próximo fisicamente e comunicação
através de conexões wireless de
poucos hops
Distribuição Centralizado. Controle hierarquizado. Descentralizado (denso e distribuído).
Escalabilidade Média Alta
Gerador de conteúdo Usuários humanos Dispositivos e sensores
Gestão
Provedor de serviços (Amazon,
Google, Microsoft...)
Negócios locais (shopping centers,
prédios comerciais, fornecedor local
de telecomunicações...)
Hardware Recursos amplos e escaláveis
Armazenamento, computação e redes
limitados
Latência Média Baixa
Localidade dos servidores Em qualquer lugar (na Internet) Na borda de rede
Mobilidade
Não. Foco em usuários gerais
Internet
Sim. Foco em usuários móveis
Número de servidores Alto Baixo
Preço médio por servidor
[Borcocci, 2016]
U$ 1.500 - U$ 3.000 U$ 50 - U$ 200
A computação em borda se torna mais eficiente quando os principais requisitos de
uma aplicação é a baixa latência, elevado uso de banda da rede (especialmente com
grande volume de dados) e de contextualizar os dados coletados. Em compensação,
a mudança dos paradigmas de cliente-servidor, muito presente nos tradicionais
modelos de nuvem, para os paradigmas de aplicações móveis e distribuídas, pode
acarretar em uma série de desafios técnicos [Baktir et al, 2017]. Dentre os desafios,
podem ser citadas questões relacionadas à necessidade de: (i) serviços de
orquestração e sincronização; (ii) resiliência a intermitência de aplicações móveis
(especialmente o handover); e (iii) capacidade de operar em soft-state (i.e., utilizar
protocolos dinâmicos que se adaptam à variação da rede), já que as aplicações em
nuvem tradicionalmente operam em hard-state (i.e., utilizam protocolos fixos e,
normalmente, mais estáveis).
3.3 Escolha entre modelos de computação na borda
Em cenários em que há vantagens na adoção de computação na borda, deve-se
também considerar as diferentes formas e implementação desse paradigma

44
discutidas na Seção 2.1: computação móvel, cloudlets e computação em névoa. Para
identificar os benefícios de cada abordagem, é importante considerar os fatores que
as distinguem. Isso é feito na Tabela 8, construída com base nos estudos de [Ai et al,
2017], [Baktir et al, 2017], [Dolui et al, 2017] e [Kumawat et al, 2018]:
• Organização: refere-se à instituição responsável por criar normas, padrões e
materiais técnicos diversos para difusão do conceito e práticas de determinado
modelo computacional. Nos três modelos, existe a forte presença de grandes
empresas da indústria e algumas universidades;
• Arquitetura de sistema: a computação móvel de borda funciona basicamente
em função de orquestradores, que são responsáveis por alocar recursos e
suportar a mobilidade. Já os cloudlets precisam de clientes cloudlets
(embutidos nas aplicações específicas) para que funcione. A computação em
névoa segue o conceito de Fog to Cloud (F2C), discutido na Seção 2.2.1.
• Custo (CAPEX): a computação móvel na borda é a que possui maior custo, já
que exige investimentos nas estações rádio base. Já a névoa pode utilizar
dispositivos dos próprios usuários (indie fog) e dispositivos mais simples (com
menor capacidade de processamento e consumo de energia) o que a torna
mais barata. Cloudlets possuem custo intermediário.
• Interação com a nuvem: a computação móvel na borda pode funcionar sem
qualquer interação com a nuvem. Já os modelos em cloudlet ou névoa
precisam em algum momento enviar as informações para a nuvem, ainda que
ambos possibilitem algumas transações offline se assim configurados.
• Interesses de negócios: do ponto de vista das empresas, a computação móvel
na borda está sendo pensada para extrair o máximo de valor das redes 5G,
enquanto que a computação em névoa está sendo voltada especificamente
para aplicações de IdC;
• Localidade: refere-se ao local principal (mas não exclusivo) onde ficam os
principais nós em cada modelo;
• Motivação: indica os principais benefícios trazidos pelos modelos.
Tabela 8 – Comparação entre os modelos de computação na borda. Fonte: Autor
Fatores Comp. móvel na borda Cloudlets Névoa
Organização
ETSI MEC - Suportado por
Huawei, IBM, Intel, Nokia,
NTT e Vodafone
OEC - suportado por
Vodafone, Intel, Huawei e
OpenFog Consortium -
fundado por ARM, Cisco,

45
Universidade Carnegie
Mellon
Dell, Intel, Microsoft e
Universidade de Princeton
Arquitetura de
sistema
Baseado em arquitetura
com orquestradores
Baseado em agentes
cloudlets
Fog to Cloud (F2C)
Custo / CAPEX Alto Médio Baixo
Interação com a
nuvem
Funciona apenas stand-
alone (não precisa
necessariamente interagir
com a nuvem)
Funciona tanto stand-alone
quanto conectado a nuvem
Funciona como uma
extensão da nuvem, mas
também permite aplicações
que funcionem offload para
algumas funções específicas
Interesses de
negócios
Requisitos de 5G na
indústria de
telecomunicações
Aplicações específicas
baseadas em computação
móvel
Internet das Coisas
Localidade
Estações de rádio base e
controladores de rede
Instalações locais e/ou ao ar
livre
Camadas entre os
dispositivos finais e a nuvem
Motivação
Habilitar uma RAN aberta
que pode hospedar
aplicações e conteúdo de
terceiros na borda da rede
Habilitar novas classes de
aplicações móveis que sejam
de computação intensiva e
sensível a latência
Habilitar alta performance,
interoperabilidade e
segurança em um ambiente
com diversas partes e
fornecedores
Dada essa grande miríade de fatores que distinguem os diferentes modelos de
computação na borda, uma forma para escolher a abordagem que melhor se adequa
às necessidades da aplicação é a criação de uma árvore de decisão. Um exemplo é
a proposta por Dolui et al [2017], que inclui os seguintes parâmetros (vide Figura 15):
• Proximidade física: é definida pela distância física entre o dispositivo final e a
camada computacional mais alta. Quanto maior a distância, menos
recomendável é a infraestrutura para suportar aplicações sensíveis a latência
e a tempo real;
• Proximidade lógica: é definida pela quantidade de saltos (hops) entre o
dispositivo final e a camada de borda. Quanto maior o número de saltos, maior
a latência do sistema;
• Consumo de energia: corresponde ao consumo realizado pelos dispositivos
finais, os quais normalmente têm restrição de recursos;
• Tempo de computação: refere-se ao tempo tomado pela camada de borda para
realizar tarefas e responder ao usuário final;
• Consciência de contexto: refere-se à necessidade de contextualizar os dados
que são coletados dos dispositivos finais. Quanto mais autonomia para tomada
de decisão um sistema precisa, e quanto maior o volume e ou precisão dos
dados que precisam ser coletados, maior a importância da contextualização
dos dados.

46
• Suporte a offload de transações: possibilidade de conexões entre a borda da
rede e os dispositivos finais por diferentes meios, que potencialmente não
exijam acesso à Internet.
Figura 15 – Mapa de fatores para implementações de computação na borda da rede.
Adaptado de [Dolui et al, 2017]
Os fatores apresentados na Figura 15 podem variar de acordo com a aplicação. Em
casos em que o nó de névoa se concentra na borda de rede, provavelmente o
consumo de energia pode deixar de ser relevante (já que as restrições são menores
na borda em si), e assim por diante.
3.4 Considerações sobre o capítulo
Este capítulo apresentou diferentes propostas de autores para definição de fatores
importantes para definição da escolha de um modelo de computação em névoa.
Dentre esses modelos, destacou-se o modelo proposto por Dolui et al [2017], que será
utilizado para analisar algumas das possíveis aplicações que podem ser utilizadas no
modelo de computação em névoa, e que são apresentadas no capítulo a seguir.

47
4 APLICAÇÕES DA COMPUTAÇÃO EM NÉVOA
O modelo de computação em borda, especialmente a computação em névoa,
possibilita o surgimento de diferentes aplicações capazes de mudar a forma como os
serviços podem ser prestados. Para o escopo deste trabalho, foram selecionadas
algumas áreas relevantes, discutidas a seguir. Em cada um dos cenários em questão,
são discutidos os fatores de escolha do modelo de computação na borda
apresentados na Seção 3.3, ilustrando sua aplicação.
4.1 Computação em névoa com redes veiculares (VANET)
A indústria de automóveis vem recebendo uma série de melhorias, não só no
hardware, mas também nas aplicações de bordo (embarcadas no veículo) e em
tecnologias de comunicação. Dentre essas melhorias, destaca-se a implementação
de VANETs, isto é, redes específicas (ad-hoc) móveis utilizadas em veículos para
comunicação entre veículos (V2V), com a infraestrutura de vias (V2I) ou com outros
elementos (V2X). De acordo com Kai et al [2016] a computação em nuvem é o modelo
atualmente mais utilizado em VANETs. Entretanto, a nuvem por si só não contempla
todos os requisitos necessários, como necessidade de respostas rápidas a eventos
(e.g., acidentes), análise de dados em tempo real e alta mobilidade. Considerando
essa situação, a Tabela 9 mostra as principais necessidades identificadas em VANETs
considerando os fatores propostos por Dolui et al [2017]:
Tabela 9 – Levantamento de requisitos de aplicações para VANETs
Fatores [Dolui et al, 2017] Necessidades da aplicação (VANET) Critério
Proximidade física A latência é um requisito importante da aplicação, e por
isso quanto menor a distância e a quantidade de hops
necessários para processar a informação melhor.
Alta
Proximidade lógica
Consumo de Energia
O consumo de energia da aplicação não deve competir
com o consumo de energia do restante do veículo, logo é
importante que o consumo seja baixo
Baixo
Tempo de computação
A aplicação exige que a camada de borda da rede seja ágil
em processar requisições e responder em tempo hábil
Baixo
Consciência do contexto
A aplicação precisa entender e reagir a diferentes
contextos de interesses (obstáculos na via, clima, etc.) e
precisa tomar decisões autônomas (quando se fala em
carros autônomos)
Alta
Suporte offload
A aplicação precisa ser tolerante a falhas de comunicação
e possuir poder de atuação em caso de incapacidade de
contato à Internet (especialmente em acidentes em
localidades adversas e distantes)
Sim

48
Considerando o mapa de fatores apresentado na Figura 15 e os critérios selecionados
na Tabela 9, verifica-se que há maioria dos critérios favoráveis ao desenvolvimento da
aplicação no modelo de computação em névoa (mais favoráveis do que aos demais
modelos). A computação em névoa pode ser implementada em VANETs em auxílio
de redes SDN, como mostrado na Figura 16. Nesse caso, um controlador poderia ser
usado para orquestrar e gerenciar as redes e interconexões entre (i) os nós de névoa
– que seriam compostos principalmente pela infraestrutura de comunicação da via
(RSU – Road-Site Unit); e (ii) os dispositivos finais – que incluiria a infraestrutura de
comunicação dos carros (OBU – On-Board Unit).
Figura 16 – VANET em arquitetura de névoa (F2C) utilizando controlador SDN. Adaptado de
[Kai et al, 2016].
A arquitetura da Figura 16 apresenta bem o porquê do uso de computação em névoa
com VANETs: a arquitetura permite a criação de hierarquias de RSU (como as de nível
nacional) e as demais que garantem a proximidade física e lógica (considerando 1 ou
2 hops). A comunicação de informações essenciais pode ser realizada entre os nós
da névoa e os veículos sem a necessidade de ficar enviando informações para as
nuvens – possibilitando comunicação offline. Também é possível a comunicação entre
veículos (nesse caso, as OBUs podem ser consideradas nós de névoa), o que
reduziria ainda mais a latência e aproximaria a borda dos dispositivos (aumentando,
por exemplo, a consciência do contexto).
4.2 Computação em névoa em aplicações da medicina e saúde (eHealth)

49
A medicina vem sofrendo algumas modificações nos últimos anos e questões como
envelhecimento da população, condições crônicas, mortalidade infantil, epidemias,
entre outros, vêm aumentando as demandas dos hospitais e instituições da saúde.
Apesar disso, o modelo hospitalar atual continua basicamente o mesmo: um modelo
fisicamente centralizado, onde o paciente sempre se desloca fisicamente ao
consultório [Farahani et al, 2018]. Nesse cenário, a tecnologia pode ajudar ao
atendimento da demanda crescente, facilitando, por exemplo, o monitoramento
contínuo à distância e a coleta de informações para diagnósticos. A Tabela 11 mostra
as principais necessidades identificadas em aplicações de IdC na área da medicina e
saúde (eHealth) em relação aos fatores propostos por Dolui et al [2017].
Tabela 10 – Levantamento de requisitos de aplicações de eHealth com IdC
Fatores [Dolui et al, 2017] Necessidades da aplicação (eHealth) Critério
Proximidade física Aplicações relacionadas a situações de alto risco aos
pacientes (ex: risco de infarto, queda de idosos...)
precisam de respostas rápidas, já que cada segundo conta
Alta
Proximidade lógica
Consumo de Energia
Os sensores utilizados precisam ser pervasivos ao
paciente, de modo que não atrapalhe as atividades do dia
a dia. Dispositivos pequenos suportam baterias também
pequenas, e por isso precisam ser projetados para baixo
consumo de energia.
Baixo
Tempo de computação
A aplicação não exige que a camada de borda retorne
rapidamente a uma requisição, já que boa parte das
informações normalmente são notificações
Exceção feita a aplicações de saúde que atuam com
atuadores, e precisam de informações rápidas da
nuvem/névoa para executar determinada ação crítica
Alto
Consciência do contexto
Aplicações de eHealth envolvem grande volume e troca de
informações, logo contextualizar os dados é fundamental
para análises em tempo real e/ou futuras, se necessário.
Alta
Suporte offload
Isso depende da aplicação. Em casos em que o
monitoramento é feito em ambientes controlados (ex:
dentro do hospital), o funcionamento offload pode ser
interessante. Entretanto, para aplicações mais remotas
(casa do paciente, enviando informações para o hospital)
o offloading não chega a ser um requisito.
Não
Considerando a árvore de decisão apresentada na Figura 15 e os critérios mostrados
na Tabela 10, verifica-se o interesse da aplicação no modelo de computação em névoa
nesse cenário. Considerando todo o ecossistema de aplicações eHealth, o modelo de
computação em névoa possibilita a divisão (slicing) da rede e maior controle da
variedade de dispositivos, velocidade e volume de dados gerados, conforme ilustrado
na Figura 17.

50
Figura 17 – Arquitetura em névoa para o ecossistema de aplicações eHealth. Adaptado de
[Farahani et al, 2018]
As interações entre as camadas podem acontecer tanto em comunicações entre
máquinas (M2M), quanto em comunicações entre humanos e máquinas (HMI), de
acordo com as características do sistema de Internet das Coisas. A implementação de
um modelo de computação em névoa para um ecossistema de eHealth auxilia na
gestão dos dados, mas ao mesmo tempo traz alguns desafios que devem ser
resolvidos:
• Necessita de avaliação e processamento de dados em tempo real, o que
permite avaliar se determinada informação de evento merece uma notificação
local (diretamente para os dispositivos e/ou outros nós) ou um alerta para
maiores análises e/ou ciência da nuvem. Isso possibilita que, caso o paciente
sofra de algum mal, haja algum tipo de ação M2M imediata no local, que os
stakeholders (parentes, médicos, etc) sejam avisados (HMI), que os dados
sejam armazenados historicamente, e que sejam realizadas análises mais
profundas. A computação em névoa ajuda nessa situação, pois possibilita a
análise de dados em partes, para cada uma de suas camadas;

51
• Necessita que os dados coletados dos pacientes sejam confidenciais, íntegros
e estejam disponíveis sempre que necessário, especialmente pensando em
atender questões de legislação (como o HIPAA e a GPRD). Como visto no
Capítulo 2, é possível realizar um mapeamento de riscos específico para o tipo
de aplicação alvo e tratar cada uma dessas ameaças de forma sistêmica.
4.3 Outras aplicações
Baseado nas aplicações analisadas, é possível verificar o alto nível de compatibilidade
da computação em névoa com diferentes áreas e necessidades das aplicações. Essa
ideia pode ser corroborada com a Tabela 11, que apresenta o nível de compatibilidade
dos modelos de computação na borda com os tipos de aplicações [Baktir et al, 2017].
É possível notar que o modelo de Cloudlet é menos recomendável quando mobilidade
é um requisito forte (como VANETS). Já o modelo de computação móvel de borda é
menos recomendável quando o cenário envolve grandes volumes de dados e precisão
de informação (ex: eHealth, ambientes militares e hostis).
Tabela 11 – Propostas de computação em névoa e áreas de aplicação. Adaptado de [Baktir
et al, 2017]
Áreas de aplicação Cloudlet
Computação
móvel de borda
Computação
em névoa
Saúde (eHealth)
Altamente
compatível Menos compatível
Altamente
compatível
Reconhecimento de face
Ambientes militares e hostis
Smart grid Menos
compatívelVeículos conectados (VANETs)
Altamente
compatível
Realidade aumentada
Altamente
compatível
Processamento de linguagem natural
Computação intensiva

52
5 CONSIDERAÇÕES FINAIS
Uma comparação entre os modelos tradicionais de computação centralizados
(especialmente a nuvem) com modelos descentralizados mostra que modelos de
computação na borda da rede podem habilitar diversas aplicações, em especial
aplicações geodistribuídas, sensíveis de latência e com limitações de banda e alto
volume de dados. Dentre os modelos de computação na borda da rede, têm destaque
a computação em névoa, cloudlets e computação móvel na borda. Ainda que utilizem
conceitos similares, cada modelo apresenta motivações e objetivos diferentes e,
portanto, sua aplicabilidade a cada cenário depende de alguns fatores. Em especial,
a computação em névoa se adapta melhor a ambientes de Internet das Coisas devido
a seu custo mais baixo, pelo fato de funcionar em ambientes com restrições de
recursos, e por garantir alta mobilidade e proximidade com os dispositivos. Além disso,
a tecnologia mostra-se interessante para endereçar algumas das limitações e desafios
que novas aplicações de Internet das Coisas apresentam, como restrições de latência,
alto volume de dados e uso da banda de rede.
5.1 Contribuições do Trabalho
A discussão sobre modelos computacionais centralizados e descentralizados, tal
como a diferenciação entre os diferentes modelos de computação na borda da rede e
as características da computação em névoa, exigiu a compilação de diversos
trabalhos da literatura. A comparação entre os diferentes conceitos apresentados nos
trabalhos de referência desta monografia e a apresentação de forma unificada permite
uma maior visualização de como se encontra o cenário de computação em névoa. A
utilização de diferentes critérios de tomada de decisão apresentado por esses autores,
e a aplicação deles em exemplos de aplicações reais, fornece insumo adicional para
ilustrar como realizar implementações, ao menos em nível conceitual e gerencial, da
computação em névoa.
5.2 Trabalhos Futuros
Esse trabalho apresentou uma visão gerencial de como implementar o modelo de
computação em névoa, quais características considerar e como compará-lo com
outros modelos. Assim, vislumbram-se dois principais caminhos para dar continuidade

53
a essa pesquisa: (i) abordar outros aspectos e características da computação em
névoa, para fazer comparações mais amplas e completas com os demais modelos,
tornando a tomada de decisão mais precisa; e (ii) abordar aspectos técnicos da
implementação de uma aplicação em modelo de computação em névoa, focando em
soluções específicas de computação em névoa e nas diferentes tecnologias que são
utilizadas e/ou propostas para esses fins.
Para trabalhos futuros voltados a levantar maiores detalhes gerenciais de
implementação, seria interessante abordar aspectos e características da computação
em névoa que não foram analisados a fundo neste trabalho, como gestão de recursos
(incluindo energia), gestão e federação de nós e qualidade de serviço. Uma
possibilidade nesse contexto é propor um modelo de cálculo do valor agregado que
um modelo de computação em névoa pode trazer a um sistema de Internet das Coisas
(explorando mais o conceito de fogonomics).
Já para trabalhos futuros voltados à implementação técnica, sugere-se a exploração
das principais técnicas e tecnologias que podem ser utilizadas para endereçar os
desafios da computação em névoa, como a segurança da informação, orquestração
da rede e análise dos dados.

54
REFERÊNCIAS
AI, Y; PENG, M.; ZHANG, K. Edge cloud computing technologies for internet of
things: A primer. Digital Communications and Networks (DCN). 2017. Disponível em
https://www.sciencedirect.com/science/article/pii/S2352864817301335
BAKTIR, A.; OZGOVDE, A.; ERSOY, C. How can edge computing benefit from
software-defined networking: a survey, use cases & future directions. IEEE
Communications surveys & tutorials. 2017. Disponível em
https://www.researchgate.net/publication/317701794_How_Can_Edge_Computing_Be
nefit_from_Software-
Defined_Networking_A_Survey_Use_Cases_Future_Directions?_sg=z_Ky2rFoev2IY7
HpaAGhUBnIuiIcA3QwXEvuv7ElqdYOTuUig6EPR2n0ivVesNx3lLuBIcGze91F7b8dTdJ
AzaW5iSfFETxLPw
BILAL, K.; KHALID, O.; ERBAD, A.; KHAN, S. Potentials, trends, and prospects in
edge Technologies: Fog, cloudlet, mobile edge, and micro data centers. Computer
Networks 130, págs. 94-120. 2018. Disponível em
BONOMI, F.; MILITO, R.; NATARAJAN, P.; ZHU, J. Fog Computing: A platform for
Internet of Things and Analytics. Big data and Internet of Things: A roadmap for Smart
Environments, págs. 169-186, Springer. 2014.
BONOMI, F.; MILITO, R.; ZHU, J.; ADDEPALLI, S. Fog Computing and its role in the
internet of things. MCC’12 Proceedings of the first edition of the MCC workshop on
Mobile cloud computing, pages 13-16. 2012. Disponível em
https://dl.acm.org/citation.cfm?id=2342513
BORCOCI, E. Fog Computing, Mobile edge computing, Cloudlets – whice one?
SoftNet Conference, 2016. Disponível em
https://www.iaria.org/conferences2016/filesICSNC16/Softnet2016_Tutorial_Fog-MEC-
Cloudlets-E.Borcoci-v1.1.pdf
BOTTA, A.; DONATO, W.; PERSICO, V.; PESCAPE, A. Integration of Cloud
computing and Internet of Things: A survey. Journal of Future Generation Computer
Systems 56, págs. 684-700. 2016. Disponível em
https://www.sciencedirect.com/science/article/pii/S0167739X15003015
BRUIN, X.; TORDERA, E.; TASHAKOR, G.; JUKAN, A. REN, G. Foggy clouds and
cloudy fogs: a real need for coordinated management of fog-to-cloud computing
systems. IEEE Wireless Commun. 23 – págs. 120–128, 2016. Disponível em:
<http://dx.doi.org/10.1109/MWC.2016.7721750>.
BUYYA, R.; CHANG, C.; SRIRAMA, S. Indie fog: An efficient fog-computing
infrastructure for the Internet of Things. Journal of Computer IEEE – Cloud Cover.
2016. Disponível em http://www.cloudbus.org/papers/IndieFog2017.pdf

55
CISCO. Cisco delivers vision of Fog Computing to Accelerate value from billions
of connected devices. Cisco Newsroom. 2014. Disponível em
https://newsroom.cisco.com/press-release-content?type=webcontent&articleId=1334100
COUTINHO, A.; CARNEIRO, E.; GREVE, F. Computação em Névoa: Conceitos,
Aplicações e Desafios. XXXIV Simpósio Brasileiro de Redes de Computadores e
Sistemas Distribuídos. SBRC – 2016. Disponível em
https://www.researchgate.net/profile/Antonio_Augusto_Coutinho/publication/309312665
_Computacao_em_Nevoa_Conceitos_Aplicacoes_e_Desafios/links/5809143f08ae040
813483c45/Computacao-em-Nevoa-Conceitos-Aplicacoes-e-Desafios.pdf. Acessado
em 06/02/2018.
DOGHMAN, F.; CHACZKO, Z.; JIANG, J. A review of aggregation algorithms for the
Internet of Things. 25th International Conference on Systems Engineering (ICSEng).
2017. Disponível em https://ieeexplore.ieee.org/document/8121713/
DOLUI, K.; DATTA, S. Comparison of edge computing implementations: fog
computing, cloudlet and mobile edge computing. Eurecom, 2017. Disponível em
http://www.eurecom.fr/en/publication/5193/download/comsys-publi-5193_1.pdf
ETSI. Mobile-Edge Computing. Introductory technical white paper. 2014. Disponível
em: https://portal.etsi.org/portals/0/tbpages/mec/docs/mobile-edge_computing_-
_introductory_technical_white_paper_v1%2018-09-14.pdf
FARAHANI, B.; FIROUZI, F.; CHANG, V.; BADAROGLU, M.; CONSTANT, N.;
MANKODIYA, K. Towards fog-driven IoT eHealth: Promises and challenges of Iot in
medicine and healthcare. Journal of Future Generation Computer Systems 78, págs.
659-676. 2018. Disponível em
FUGAHA, A.; GUIZANI, M., MOHAMMADI, M; ALEDHARI, M., AYYASH, M. Internet of
things: a survey on enabling technologies, protocols, and applications, IEEE
Commun. Surv. Tutor. 17 (4). 2015. Disponível em
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7123563
GAI, K.; QIU, M.; SUN, X. A survey on FinTech. Journal of Network and Computer
Applications 103, págs. 262-273. 2018. Disponível em
GARTNER. Technologies underpin the Hype Cycle for the Internet of Things. 2016.
Disponível em https://www.gartner.com/smarterwithgartner/7-technologies-underpin-the-
hype-cycle-for-the-internet-of-things-2016/
GARTNER. What edge computing means for infrastructure and operation leaders.
2017. Disponível em https://www.gartner.com/smarterwithgartner/what-edge-computing-
means-for-infrastructure-and-operations-leaders/

56
GARTNER. Gartner says 8.4 billion connected “things” will be in use in 2017, up
31 percent from 2016. Newsroom, 2017. Disponível em
https://www.gartner.com/newsroom/id/3598917
GOMES, R.; PONTE, F.; URBANO, A; BITTENCOURT, L.; MADEIRA, E. Fatiamento de
rede baseado em demanda elástica em provedores de Internet do Futuro. SBRC.
2018. Disponível em http://www.sbrc2018.ufscar.br/wp-
content/uploads/2018/04/179530.pdf
GUBBI, J.; BUYYA, R.; MARUSIC, S.; PALANISWAMI, M. Internet of Things (IoT): A
vision, architectural elements, and future directions. Future Generation Computer
Systems. Volume 29, Issue 7, pags. 1645-1660. 2013. Disponível em:
GUPTA, G.; CHAKRABORT, S.; GHOSH, S.; BUYYA, R. Fog Computing in 5G
Networks: An application perspective. Cloud and Fog Computing in 5G Mobile
Networks: Emerging advances and applications, chapter 1 – eISBN: 9781785610844.
2017. Disponível em http://digital-library.theiet.org/content/books/10.1049/pbte070e_ch2
KAI, K.; CONG, W.; TAO, L. Fog computing for vehicular Ad-hoc networks:
paradigms, scenarios and issues. The Journal of China Universities of Posts and
Telecommunications, págs. 56-65. 2016. Disponível em
KUMAWAT, D.; PAVATE, A.; PANSAMBAL, S. Fog Computing and Its comparative
study with other cloud-based technologies. IOSR Journal of Engineering, volume 7,
págs. 09-12. 2018. Disponível em http://www.iosrjen.org/Papers/Conf.ICIATE-
2018/Volume-7/3-09-12.pdf
LU, R.; HEUNG, K.; LASHKARI, A.; GHORBANI, A. A lightweight privacy-preserving
data aggregation scheme for Fog Computing-Enhanced IoT. IEEE Access. Volume
5, págs. 3302 – 3312. 2017. Disponível em
https://ieeexplore.ieee.org/document/7869305/
MAO, Y.; YOU, C.; ZHANG, J.; HUANG, K.; LETAIEF, K. A survey on mobile edge
computing: The communication perspective. Mobile edge computing: Survey and
Research outlook. 2017. Disponível em https://arxiv.org/abs/1701.01090
MCAFEE LABS. Threats Report: March 2018. Disponível em
https://www.mcafee.com/us/resources/reports/rp-quarterly-threats-mar-2018.pdf
OPEN-FOG CONSORTIUM. Open Fog Reference Architecture for Fog Computing.
2017. Disponível em https://www.openfogconsortium.org/wp-
content/uploads/OpenFog_Reference_Architecture_2_09_17-FINAL.pdf
RAMIREZ, W.; BRUIN, X.; TORDERA, E.; SOUZA, V.; JUKAN, A.; REN, G.; DIOS, O.
Evaluating the benefits of combined and contínuos Fog-to-Cloud architectures.

57
Journal of Computer Communications 113, págs. 43-52. 2017. Disponível em
ROMAN, R.; LOPEZ, J.; MAMBO, M. Mobile edge computing, Fog et al.: A survey
and analysis of security threats and challenges. Journal of Future Generation
Computer Systems 78, págs. 680-698. 2018. Disponível em
SATYANARAYANAN, M.; BAHL, P./ CACERES, R.; DAVIES, N. The case for VM-based
Cloudlets in Mobile Computing. Pervasive Computing, volume 8, págs. 14-23. 2009.
Disponível em https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/02/cloudlets09.pdf.
SOHAL, A.; SANDHU, R.; SOOD, S.; CHANG, V. A cybersecurity framework to
identify malicious edge device in fog computing and cloud-of-things
environments. Journal of Computers & Security. 2017. Disponível em
TANG, B.; CHEN, Z.; HEFFERMAN, G.; PEI, S.; WEI, T.; HE, H.; YANG, Q.
Incorporating Intelligence in Fog Computing for Big Data Analysis in Smart Cities.
IEEE Transactions on Industrial Informatics. Volume 13, Issue 15. 2017. Disponível em
https://ieeexplore.ieee.org/document/7874167/
TORDERA, E.; BRUIN, X.; ALMINANA, J.; JUKAN, A.; REN, G.; ZHU, J. Do we really
know what a fog node is? Current trends towards an open definition. Journal of
Computer Communications, págs. 117-130. 2017. Disponível em
WEINMAN, J. Fogonomics – The strategic, economic, and financial aspects of
the cloud. Computer Software and Application Conference. IEEE, 2017. Disponível
em http://ieeexplore.ieee.org/document/8029683/
YI, S.; LI. C.; LI, Q. A survey of fog computing: concepts, applications and issues.
Mobidata’15 – Proceedings of the Workshop on Mobile Big Data. Pages 37-42. 2015.
Disponível https://dl.acm.org/citation.cfm?doid=2757384.2757397
ZHENG, L.; JOE-WONG, C. Fogonomics: Pricing and incentivizing fog
computing. OpenFogConsortium – Resources/Insights. 2017. Disponível em
https://www.openfogconsortium.org/fogonomics-pricing-and-incentivizing-fog-
computing/

58
GLOSSÁRIO
Ad-hoc – aplicação/conexão com finalidade específica
Backbone – espinha dorsal da rede, isto é, rede principal por onde a maioria dos dados
devem trafegar de um ponto ao outro.
Backhaul – segmento de rede responsável por fazer ligação entre o núcleo da rede
(backbone) e sub-redes periféricas.
Beacon – dispositivos de geolocalização focado em ambientes fechados, utiliza
sensoriamento de proximidade para fornecer informações precisas sobre
determinados objetos em um determinado ambiente.
Botnets – define um grupo de computadores e/ou dispositivos conectados à Internet,
cada um deles executando um ou mais bots (robôs pré-programados) a fim de
executar determinada tarefa.
Blockchain – base global de registros e dados distribuídos e compartilhados. Funciona
como um livro-razão público que possibilita a realização de transações, com certo
nível de confiança, para uma determinada aplicação (por exemplo: mercado de
bitcoin)
Cluster – termo utilizado para denominar grupos/aglomerados computacionais
específicos. Normalmente consistem em recursos computacionais fortemente
acoplados que respondem e são considerados como um único sistema.
Computação na Nuvem / Cloud Computing – Paradigma que prevê o uso de recursos
computacionais (memória, armazenamento e processamento, entre outros) através
da internet, utilizando os princípios de computação utilitária (todas as transações
podem ser tratadas como serviços de consumo, pay as you go) e computação
distribuída (compartilhamento entre recursos computacionais entre diversas
máquinas, recursos computacionais são tratados como commodities).
Data Analytics – técnicas e metodologias de análise de dados de forma a identificar
padrões, adquirir insights valiosos e anteceder tendências, de forma a possibilitar
tomada de decisões e insumos para benchmarkings e otimização de processos,
serviços e produtos.
Eavesdropping – técnica computacional que foca na violação da confidencialidade (e
não necessariamente na integridade como a técnica de homem no meio), onde o
atacante explora as vulnerabilidades de comunicação das vítimas e coleta dados e
informações que são trafegadas no canal.

Monografia Computação na Névoa

Monografia Computação na Névoa

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Monografia Computação na Névoa

Semelhante a Monografia Computação na Névoa (20)

Mais de Bruno Oliveira

Mais de Bruno Oliveira (20)

Monografia Computação na Névoa