Embed Size (px)
Citation preview
Capítulo
9
Simulação em IoT: Uma abordagem para Seleção
de Rotas Ciente de Contexto
Harilton da Silva Araújo, Raimir Holanda Filho, Ricardo de Andrade L. Rabelo,
Joel J. P. C. Rodrigues, Natanael de Carvalho Sousa, José Carlos Correia Lima e
José Victor Vasconcelos Sobral
Abstract
Internet of Things (IoT) represents the interconnection of intelligent and addressable
devices, which must have autonomy and proactive behavior. Context-aware routing
protocols for the IoT should have autoconfiguration and routing metric reconfiguration
features. This work describes an approach for selecting routes in IoT to meet the
temporal requirements of specific applications. For this purpose, four OF (Objective
Function) were proposed for the Routing Protocol for Low-power and Lossy-networks.
The simulations carried out show that the implemented proposal, when compared to the
objective functions OF0 and MRHOF, is able to provide data delivery guarantee,
higher energy efficiency and lower delay, considering contexts of IoT applications.
Resumo
Internet das Coisas (Internet of Things - IoT) representa a interligação de dispositivos
inteligentes e endereçáveis, que devem possuir autonomia e comportamento pró-ativo.
Os protocolos de roteamento ciente de contexto, para o IoT, devem ter características
de autoconfiguração e de reconfiguração de métricas de roteamento. Este trabalho
descreve uma abordagem para seleção de rotas em IoT a fim de atender aos requisitos
temporais de aplicações específicas. Para tanto, foram propostas quatro OF (Objective
Function) para o protocolo RPL (Routing Protocol for Low-power and Lossy-
networks). As simulações realizadas ilustram que a proposta implementada, quando
comparada com as funções objetivo OF0 e MRHOF, é capaz de proporcionar garantia
na entrega dos dados, maior eficiência energética e menor delay, considerando
contextos de aplicações de IoT.
III Escola Regional de Informática do Piauí. Livro Anais - Artigos e Minicursos, v. 1, n. 1, p. 429-453, jun, 2017.www.eripi.com.br/2017 - ISBN: 978-85-7669-395-6
1.1. Introdução
A Internet das Coisas (Internet of Things - IoT) é a presença pervasiva de uma
variedade de dispositivos, tais como: sensores, etiquetas de RFID (Radio Frequency
Identification), atuadores, smartphones, dentre outros dispositivos ao nosso redor que
são capazes de interagir uns com os outros de forma a cooperar para um objetivo
comum [Atzori et al., 2010]. Para que a IoT possa realizar o seu propósito com
eficiência, é necessário que a estrutura de rede utilizada disponibilize recursos chaves,
tais como: heterogeneidade dos dispositivos, escalabilidade, troca de dados entre
tecnologias ubíquas sem fio, soluções otimizadas de energia, capacidade de
rastreamento e localização, capacidade de auto-organização, interoperabilidade
semântica e gerenciamento de dados e mecanismos de preservação da privacidade
[Miorandi et al., 2012].
Entre as tecnologias mais promissoras para o paradigma de IoT estão a RFID e
RSSF (Redes de Sensores sem Fio), segundo [Atzori et al., 2010] e [Sobral et al. 2015].
Essa é uma indicação de que a IoT, por meio da integração entre as tecnologias RFID e
RSSF, maximiza os seus benefícios criando novas perspectivas para diversas aplicações,
como exemplo as que possuem informações de contexto.
O contexto geralmente refere-se a localização, mas pode compreender diferentes
informações usadas para caracterizar entidades envolvidas na interação do usuário com
a aplicação. Um modelo de contexto é necessário para definir, manusear e armazenar as
correlações entre as entidades que identificam o contexto.
Segundo [Aldauf et al. 2007], sistemas sensíveis ao contexto são capazes de
adaptar seu comportamento às condições atuais, sem intervenção explícita do usuário
Em IoT, diversas informações como características do próprio dispositivo, do
ambiente que o cerca e de suas capacidades podem ser utilizadas como fonte de
informações contextuais. Muitos trabalhos disponíveis na literatura convergem esforços
para atender questões envolvendo sensibilidade ao contexto em IoT, especialmente
durante a fase de seleção de rotas. Nessa fase, os dispositivos (que possuem fortes
restrições de recursos) processam localmente as informações contextuais a fim de
selecionar o caminho que melhor atenda as necessidades de determinada aplicação.
Os protocolos de roteamento sensíveis ao contexto para IoT devem atender a
requisitos importantes, tais como: processar as alterações e o estado do ambiente onde
estão inseridos os dispositivos, prever a heterogeneidade dos equipamentos e considerar
a topologia dinâmica da rede a fim de atender aplicações específicas.
Neste sentido, protocolos de roteamento ciente de contexto, como o RPL
(Routing Protocol for Low-power and Lossy-networks) - (RFC 6550), são de grande
importância por selecionar os melhores caminhos na rede considerando o contexto das
aplicações. O RPL utiliza funções objetivo para classificar e selecionar rotas que possui
menor custo voltado para aplicações de IoT.
Este trabalho propõe uma adaptação no protocolo RPL, implementada a partir da
criação de quatro novas funções objetivo: a DQCA-OF1 (Delivery Quality and Context
Aware Type 1 Objective Function), a DQCA-OF2 (Delivery Quality and Context Aware
Type 2 Objective Function), a DQCA-OF3 (Delivery Quality and Context Aware Type 3
Objective Function) e a DQCA-OF4 (Delivery Quality and Context Aware Type 4
Objective Function).
A adaptação do roteamento ocorre de acordo com as informações de contexto
obtidas da aplicação, que seleciona da função objetivo que melhor se adequa ao
contexto da aplicação. Através do uso da função objetivo selecionada, novas rotas são
definidas utilizando o mecanismo de seleção de rotas também proposto neste trabalho.
O capítulo está organizado da seguinte forma: a Seção 1.2 apresenta os trabalhos
relacionados. A Seção 1.3. descreve a adaptação que foi feita no protocolo RPL. A
avaliação de desempenho da abordagem proposta é discutida na Seção 1.4. O item 1.5
trata aspectos relacionados à simulação, seguidos de conclusões na seção 1.6.
1.2. Trabalhos Relacionados
A tecnologia 6LoWPAN é uma solução adequada para lidar com o desafio de
prover escalabilidade (permitindo suporte a grande quantidade de dispositivos
conectados), padronização da rede além de possibilitar a adaptação do protocolo RPL.
Os dispositivos que utilizam a tecnologia 6LoWPAN possuem recursos limitados em
termos de capacidade computacional, memória, largura de banda de comunicação e de
energia da bateria [Winter et al., 2012].
Uma solução de roteamento baseada em IPv6, foi proposta pelo Internet
Engineering Task Force - IETF por meio do Grupo de Trabalho Routing Over Low
power and Lossy - ROLL (IETF Datatracker, 2013). Tal solução consiste na
especificação do protocolo de roteamento RPL, juntamente com as especificações sobre
as métricas de roteamento e função objetivo.
O roteamento utilizando o RPL possibilita a adaptação às exigências de áreas de
aplicações específicas, conhecidas como contexto. Para cada área de aplicação existe
um documento RFC com uma função objetivo que mapeia os requisitos de otimização,
sendo que estes requisitos são definidos na RFC 5548 [Dohler, M., et al., 2009] para
aplicações urbanas de baixa potência, RFC 5673 [Pister, K., et al, 2009] para aplicações
industriais, na RFC 5826 [Brandt e Porcu, 2010] para aplicações de automação
residencial e no RFC 5867 [Martocci, J., et al., 2010] para a construção de aplicações de
automação.
Segundo [Vasseur, J., et al., 2012], o RPL emprega métricas, especificadas na
RFC 6551, que são apropriadas para ambientes 6LoWPAN, tais como: número de
saltos, latência, taxa de entrega, energia do nó, throughput, nível de qualidade do link e
confiabilidade de transmissão.
[Makris et al. 2013] especifica diferentes modelos de contexto, como o orientado
a objetos e o modelo baseado em ontologia A abordagem orientada a objetos estende
esse paradigma para a modelagem de contexto. Modelagem baseada em ontologia
organiza a informação em ontologias, utilizando abordagens semânticas, como a Web
Ontology Language (OWL). A inferência (reasoning) do contexto refere-se à
informação ou ao conhecimento que pode ser inferido a partir da análise de dados e
combinado com informações diferentes.
[Jayaraman e Delirhaghighi 2013] propõe uma abordagem ciente de situações
que altera o funcionamento de um nó sensor baseado nos fenômenos coletados
(contexto) do ambiente, tais como: temperatura, umidade, pressão, etc. A contribuição
do autor intitulada como SA-A-WSN (Situation-Aware Adaptation Approach for
Energy Conservation in Wireless Sensor Network), busca encontrar um trade-off entre
tempo de vida e a corretude dos dados coletados no ambiente a fim de atender uma
aplicação específica. Para tanto, a proposta deste autor objetiva controlar a forma em
que o nó sensor atua no ambiente sensoreado baseado em informações contextuais a fim
de reduzir o consumo de energia da rede.
Em [Thubert 2012] foi proposta uma função objetivo padrão para o RPL
denominada OF0 (Objective Function Zero), projetada para possibilitar a
interoperabilidade entre diferentes implementações do RPL. A OF0 possui um
funcionamento simplista e não utiliza métricas de roteamento na definição do rank. Um
nó escolhe como pai preferido o vizinho alcançável que possuir o menor rank.
Em [Levis e Gnawali 2012] foi apresentada a função objetivo MRHOF
(Minimum Rank with Hysteresis Objective Function), baseada no conceito de container
de métricas que explicitam um conjunto de propriedades das métricas e/ou restrições a
serem consideradas no roteamento, difundidas por meio das mensagens DIO. A
MRHOF é compatível apenas com métricas especificadas na RFC 6719. A seleção dos
pais preferidos é feita com base no custo do caminho levando em consideração a
métrica adotada, onde as rotas que minimizam o custo associado a métrica são
preferíveis. Por padrão a MRHOF utiliza o ETX [Couto et. al 2003] que mede a
qualidade do link e objetiva maximizar a vazão de dados. O ETX é definido conforme a
expressão (1).
𝐸𝑇𝑋 = 1
𝐷𝑓. 𝐷𝑟𝑠𝑠 (1)
Onde: Df é a probabilidade do pacote ser recebido pelo vizinho; Dr é a probabilidade do
ACK ser recebido com sucesso.
Uma função objetivo sensível ao contexto denominada CAOF (Context Aware
Objective Function), proposta por [Sharkawy et al. 2014] e destinadas às redes de
sensores sem fio, se baseia nos recursos residuais e na mudança de estado do nó sensor
ao longo do tempo. A função proposta por [Sharkawy et al. 2014] realiza uma soma
ponderada das métricas: grau de conectividade do nó, nível energético da bateria e
posição do nó na árvore de roteamento em relação ao nó progenitor. O objetivo final da
função proposta por [Sharkawy et al. 2014] é encontrar uma probabilidade de entrega
para cada nó sensor.
A utilização de lógica fuzzy para cálculo da função objetivo para o protocolo
RPL é proposta por [Gaddour et al. 2014]. Neste trabalho a função objetivo é o
componente utilizado para selecionar os caminhos identificando um nó pai dentre
diversos nós existentes. A função objetivo denominada OF-FL (Fuzzy Logic) associa
parâmetros a variáveis linguísticas que são combinadas com regras fuzzy pré-definidas
a fim de identificar a rota a ser selecionada. Os parâmetros considerados na OF-FL são
números de saltos, tempo de atraso fim-a-fim, taxa de perda de pacotes e taxa de
mudança de rotas default.
Em [Chen et al 2015] foi proposta uma Objective Function SCAOF (A Scalable
Context-Aware Objective Function), que adapta o protocolo RPL ao monitoramento
ambiental na área da agricultura com contexto escalável. A SCAOF teve o seu
desempenho avaliado tanto na simulação como em testes de campo. Os resultados
experimentais obtidos confirmam que SCAOF pode prolongar a vida útil da rede e
melhorar a QoS nos diferentes cenários de simulação voltados para a agricultura.
Os trabalhos dos autores [Sharkawy et al. 2014] e [Gaddour et al. 2014],
motivaram para a elaboração da abordagem aqui proposta por duas características: por
empregar métricas que são apropriadas para ambientes 6LoWPAN e por realizar uma
soma ponderada de métricas a fim de proporcionar uma qualidade na entrega das
mensagens trafegadas em uma rede de sensores sem fio.
1.3. Proposta de Adaptação do RPL
Nós propomos, neste trabalho, uma adaptação no protocolo Routing Protocol for Low-
power and Lossy-networks – RPL (RFC 6550). O objetivo principal desta proposta é
otimizar o roteamento a fim de atender aos requisitos de contexto de aplicações
específicas.
A) O Protocolo RPL (Routing Protocol for Low-power and Lossy-networks)
O RPL é um protocolo implementado na camada de rede, projetado
especialmente para funcionar em conjunto com 6LoWPAN e operar sobre diversos
mecanismos de camada de enlace incluindo IEEE 802.15.4 camadas MAC e PHY
[Brandt et al. 2012]. O RPL organiza hierarquicamente a rede em uma topologia em
árvore e define os melhores caminhos na rede a partir de uma função objetivo,
considerando métricas de custo, como por exemplo: número de saltos, latência, taxa de
entrega, energia do nó, throughput, nível de qualidade do link e confiabilidade de
transmissão, conforme descrito na RFC 6551.
O RPL utiliza uma topologia em árvore construída a partir de nós raízes,
suportando três tipos de tráfego: Tráfego do gateway para múltiplos nós em
comunicações point-to-multipoint (P2MP), Tráfego de muitos nós para o gateway em
comunicações multipoint-to-point (MP2P) e Comunicação point-to-point (P2P). A
topologia em árvore é baseada no conceito de Direct Acyclic Graph (DAG).
Em cenários de IoT utilizando o RPL, os objetos são os dispositivos que
compõem uma rede cujas relações, entre eles, são as suas próprias ligações. Em um
DAG, os objetos não têm ligações/relações com eles próprios (nenhum caminho se
inicia e termina no mesmo objeto) mas mantêm sempre ligações com os objetos
vizinhos, sendo o grafo obrigado a possuir pelo menos um objeto fonte e um objeto raiz.
O protocolo RPL é implementado em 4 fases:
a) Fase de Configuração:
A construção da rede é iniciada pela fase de configuração. Nessa fase, o gateway
emite mensagem para formação da árvore de roteamento.
b) Fase de Estabelecimento de Rotas
Nessa fase, o protocolo RPL, em sua versão original, utiliza a OF0 (Type 0
Objective Function) para habilitar os nós a selecionarem os nós pai (rota default),
considerando informações do rank e o número de saltos de um determinado nó para o
sink, conforme descrita na expressão (2):
R(N)=R(P)+rank_increase (2)
Onde:
R(N),é o novo rank do nó; R(P),é o rank do pai preferido; rank_increase, é um
fator de variação (delta) entre o rank do pai e o do próprio nó, descrito na expressão (3):
rank_increase=(Rf*Sp+Sr)*MinHoprank_increase (3)
Onde:
Rf é o um fator configurável que é usado para multiplicar o valor da propriedade
do link. Por default, utiliza o valor 1; Sp,é o passo do rank; Sr,é o valor máximo
atribuído ao nível do rank a fim de permitir um sucessor viável. MinHoprank_increase,
é o incremento mínimo em rank entre um nó e qualquer de seus pais, cujo valor default
é 256;
c) Fase de Comunicação de Dados
Nessa fase, as mensagens trafegam pela rede com destino ao gateway,
obedecendo as rotas selecionadas na fase de estabelecimento de rotas. Durante a
comunicação, o tráfego de pacotes pode ocorrer de forma ascendente ou descendente.
d) Fase de Reconstrução de Caminhos
Em função das características inerentes as topologias de rede, as rotas com
destino aos nós progenitores podem ser atualizadas. As alterações nas rotas ascendentes
exigem a necessidade de atualizar as rotas de ligação descendente.
B) Abordagem Proposta
Como forma de adaptação do protocolo RPL, foram propostas e avaliadas quatro
funções objetivo a serem utilizadas na fase de estabelecimento de rotas, a DQCA-OF1,
DQCA-OF2, DQCA-OF3 e DQCA-OF4.
Cada uma das funções objetivo são baseadas na fusão de métricas para
ambientes 6LoWPAN empregadas pelo RPL e descritas na RFC 6551. As informações
contextuais de cada aplicação são utilizadas para permitir, de forma dinâmica, a
adaptação do roteamento, buscando atender cenários que priorizam simultaneamente as
métricas especificadas na RFC 6551.
As funções objetivo propostas na abordagem permitem os dispositivos elegerem
os nós progenitores (rota default) por meio das informações de contexto obtidas da
aplicação. Cada aplicação pode possuir requisitos que exijam, simultaneamente, até três
métricas (ETX - Estimativa de transmissão) e/ou (NS - Número de saltos) e/ou (EC –
Energia Consumida), permitindo classifica-las, quanto ao nível de prioridade (N) em
(Alta = 1; Média = 3; Baixa = 5). Cada uma das métricas é representada por uma
função F.
A figura 1 apresenta o funcionamento da abordagem proposta, que é baseada na
relação de três módulos. O módulo aplicações representa o contexto de cada aplicação.
O módulo base de dados contém as funções objetivo que serão utilizadas para a geração
de rotas que atendam às exigências de cada aplicação.
Figura 1. Modelo Funcional da Abordagem Proposta
A partir dessas informações um peso T(ni) é obtido por cada dispositivo da rede,
que representa a soma das funções de contexto.
1) DQCA-OF1 (Delivery Quality and Context Aware Type 1 Objective Function):
T(ni)= NETX . FETX(ni) + NNS . FNS(ni) (4)
A função DQCA-OF1 é composta pelas métricas estimativa de transmissão
(ETX) e número de saltos (NS) para o cálculo de seleção de rotas.
2) DQCA-OF2 (Delivery Quality and Context Aware Type 2 Objective
Function):
T(ni)= NETX . FETX(ni) + NEC . FEC(ni) (5)
A função DQCA-OF2 é composta pelas métricas estimativa de transmissão
(ETX) e a energia consumida (EC) para o cálculo de seleção de rotas.
3) DQCA-OF3 (Delivery Quality and Context Aware Type 2 Objective
Function): T(ni)= NNS . FNS(ni) + NEC . FEC(ni) (6)
A função DQCA-OF3 é composta pelas métricas número de saltos (NS) e
energia consumida (EC) para o cálculo de seleção de rotas.
4) DQCA-OF4 (Delivery Quality and Context Aware Type 2 Objective
Function):
T(ni)= NETX . FETX(ni) + NNS . FNS(ni) + NEC . FEC(ni) (7)
A função DQCA-OF4 é composta pelas métricas estimativa de transmissão
(ETX), número de saltos (NS) e energia consumida (EC) para o cálculo de seleção de
rotas.
A seleção das rotas é feita aplicando o valor de T(ni) no mecanismo de seleção
de rotas descrito na expressão (8), que permite os nós decidirem localmente por qual
rota encaminhar os dados sem incorrer em altos custos relacionados ao conhecimento de
toda a topologia da rede.
Seja 𝑇(𝑛𝑖) o peso que representa o custo de envio da mensagem de 𝑣𝑖, então, o
(∑ 𝑇(𝑛𝑖)) para 𝑖 = 1, … , 𝑘 − 1, representa a qualidade do caminho denotada por 𝑄𝐶,
onde:
𝑄𝐶 = ∑𝑖=1𝑘−1𝑇(𝑛𝑖)𝑣𝑖
(8)
A regra implementada no protocolo preconiza que quanto menor o peso de
𝑇(𝑛𝑖), melhor será a qualidade do caminho 𝑄𝐶. Assim, o melhor caminho a ser
escolhido é aquele que dentre todos os caminhos disponíveis da origem ao destino
obtiver o menor valor correspondente ao 𝑄𝐶.
1.4. Avaliação de Desempenho da Abordagem Proposta
Para avaliação do desempenho da abordagem proposta neste trabalho, utilizamos
o simulador COOJA [Osterlind, 2006], que faz parte do ambiente de simulação Contiki.
O Contiki ainda não possui funções objetivo que contemplem todas as métricas
especificadas na RFC 6551, se limitando apenas às métricas presentes na função
objetivo adotada pelo RPL em sua versão original.
Para tanto, as funções objetivo aqui propostas foram avaliadas e comparadas
com as funções OF0 e MRHOF, que são funções objetivo nativas do RPL. O modelo de
consumo de energia utilizado para avaliação de desempenho no quesito energia, foi o
módulo Energest do Contiki [Dunkels et al. 2007], que contabiliza a consumo de
energia em um dispositivo de IoT.
A. Cenário de Simulação e Métricas Utilizadas
O cenário de simulação foi construído para validar a abordagem proposta neste
trabalho. A topologia do cenário consiste em 11 nós sensores, 6 etiquetas (RFID), 2 nós
leitores (RFID) e 1 nó sink. Há 20 dispositivos em uma topologia de rede fixa, conforme
mostra a figura 2
Figura 2. Topologia do Cenário
Existe um fluxo de dados que consiste em ascendente e descendente. O nó sink
transmite mensagens DODAG Information Object (DIO) sempre que há mudança da
aplicação.
O tempo total de simulação foi de 35 minutos e repetimos a mesma cinco vezes
com intervalo de confiança de 95%, uma vez que a partir da quinta vez não foi
observada variação nos resultados. Entretanto, para a avaliação da mudança dinâmica
entre as funções objetivo, foi simulado o tempo de 140 minutos, em função de cada
aplicação perdurar o tempo de 35 minutos. As mensagens foram simuladas com pacotes
de 30 bytes (default do Contiki). A escolha do nó progenitor para o estabelecimento da
rota é feita utilizando a abordagem proposta neste trabalho. A energia inicial dos nós foi
ajustada para 200 joules sobre o modelo de consumo de energia Energest do Contiki
[Dunkls et al. 2007].
Cinco métricas empregadas pelo RPL (RFC 6551) e que são apropriadas para
ambientes 6LoWPAN, foram escolhidas a fim de avaliar a abordagem, tais como:
Energia Consumida (EC), Custo de Recebimento de Mensagens (CR), Número de Saltos
(NS), Taxa de Entrega (Tx) e Estimativa de Transmissão (ETX).
Para fins de validação da proposta, quatro aplicações foram consideradas neste
trabalho. A primeira aplicação exige prioridade em confiabilidade (representada pela
taxa de entrega). A segunda exige baixo delay (representado pelo número de saltos). A
terceira aplicação exige elevado tempo de vida (representado pela energia consumida) e
a quarta exige qualidade na entrega dos dados (representada pela estimativa de
transmissão).
B. Resultados Obtidos
Analisando os resultados apresentados nas figuras 3 e 4, observamos que
aplicações que exigem prioridade alta relacionada ao tempo de vida e ao delay,
utilizaram, para o processo de seleção de rotas, a função DQCA-OF4. Esta função
obteve, ao término da simulação, maior energia residual (na ordem de 170 joules)
quando comparada com as funções MRHOF e OF0 que obtiveram, respectivamente,
consumos de 100 joules e 80 joules. Isso ocorreu por esta função considerar as métricas
energia consumida e número de saltos, fazendo com que fossem selecionadas rotas que
possuem menor energia consumida e menor número de saltos.
Figure 3. Energia Consumida (Ec)
Ainda na figura 4, observamos que não houve variação nos resultados entre 0 e
525 segundos de simulação. Isso ocorreu em função da rede, nesse intervalo, está em
processo de estabilização, ocorrendo, assim, variação do delay somente a partir de 525
segundos de simulação.
Figure 4. Representação do Atraso (Delay)
Na figura 5, observamos o custo de recebimento de mensagens de todas as
funções objetivo avaliadas neste trabalho. Assim, foi identificado que todas as funções
propostas obtiveram menor custo quando comparadas com as funções OF0 e MRHOF.
Isso ocorreu em função da abordagem proposta utilizar funções objetivo específicas
para cada aplicação, o que não ocorre com as funções OF0 e MRHOF.
Observa-se ainda que a DQCA-OF3 obteve um custo de recebimento de
mensagens na ordem de 0,42, custo esse menor quando comparado com as demais
funções. Isso ocorreu em decorrência da função DQCA-OF3 ter contribuído para
selecionar rotas que possuem menor número de saltos, uma vez que recebeu prioridade
alta na métrica Número de Saltos (NS).
Além disso, a presença da métrica Energia Consumida (EC) nesta função, fez
que com o protocolo também levasse em consideração rotas com energia consumida
compatível com a aplicação desejada, possibilitando, assim, a obtenção reduzida do
custo de recebimento de mensagem.
Figure 5. Custo de Recebimento de Mensagens (CR)
Para aplicações que exigem confiabilidade na entrega dos dados, a figura 6
mostra que a função DQCA-OF1 obteve melhor desempenho com uma taxa de entrega
de 89% quando comparada com as funções MRHOF e OF0, que obtiveram,
respectivamente, taxa de entrega de 65% e 50,4%. Isso ocorreu em decorrência do
protocolo RPL ter utilizado, para a seleção de rotas, a função que prever as métricas
Estimativa de Transmissão (ETX) e Número de Saltos (NS), ambas, neste caso, com
prioridade alta.
Figure 6. Taxa de Entrega (Tx)
A figura 7 mostra que, para aplicações que exigem prioridade na qualidade da
entrega dos dados, a função DQCA-OF2 (Ec=Alta) obteve melhor desempenho no
número de transmissões/retransmissões com ETX=42 quando comparada com as funções
DQCA-OF2 (Ec=Baixa) que obteve ETX=88, MRHOF com ETX=140 e OF0 com
ETX=180. Essa diferença foi alcançada em função da aplicação ter exigido nível de
prioridade alta na métrica Energia Consumida (Ec).
Figure 7. Estimativa de Transmissão (ETX)
1.5. Simulação
No passado, Uzi Landman e seus colegas da Universidade da Georgia, Estados Unidos,
descobriram algumas das regras que explicam porque um metal não-reativo como o
ouro funciona como um catalisador quando ele se uni em agrupamentos de alguns
poucos átomos. Eles não se utilizaram de experimentos reais com porções do metal
precioso. Ao invés disso, eles simularam em computador e descobriram que o ouro é um
catalisador muito efetivo quando se encontra na forma de partículas que contenham
entre 8 e 24 átomos. Eles também descobriram que a absorção de cargas elétricas pelo
metal tem um papel crucial em seu funcionamento como catalisador [Zhang et al.,
2008].
Apenas seis anos mais tarde, a tecnologia disponibilizou o aparato técnico que
permitiu que a equipe realizasse testes de suas previsões experimentalmente. A
experiência mostrou que seus cálculos estavam corretos. Landman e seus colegas
utilizaram-se da metodologia científica para validar seu trabalho. Tal metodologia
orienta-se sobre os seguintes passos: observação, formulação de pergunta, formulação
de hipótese, experiência controlada e análise conclusiva dos dados.
Com base no trabalho de Landman e na realidade atual, percebe-se que a
simulação tornou-se uma ferramenta importante para a verificação de uma hipótese
formulada. Geralmente, o experimento valida uma hipótese. Entretanto, em cenários de
redes, uma hipótese pode ser validada utilizando-se de um ou mais dos seguintes
métodos: analítico, simulação e experimento controlado; como pode-se observar na
figura 8.
Figura 8. Etapas do método científico para cenários de rede.
Para a validação de uma hipótese, o método analítico se utiliza de modelos
matemáticos e equações, já o experimento, utiliza-se de uma situação real controlada.
Nas simulações, cria-se um modelo virtual próximo à realidade onde se pode, com o
auxílio de computador, testar e coletar resultados antes de conduzir algum experimento
real.
A simulação é utilizada para o desenvolvimento de aplicações bem como para a
validação de novas propostas., conforme mencionado por [Egea-Lopez et al. 2005].
Muitos trabalhos publicados contem resultados baseados apenas em simulações [Curren
2005]. Muitas vantagens são obtidas com o uso de simulações, tais como: menor custo,
praticidade em testar o comportamento da rede utilizando diferentes parâmetros,
possibilidade de realizar validação de código e avaliação de desempenho de redes em
larga escala. O crescente surgimento de dispositivos que integram a IoT, levou o
aumento do número de simuladores disponíveis, como por exemplo NS-2 [Downard
2004], OMNeT++ [Varga et al. 2001], Castalia [Boulis 2009], COOJA [Osterlind et al.
2006], TOSSIM [Levis et al. 2003], AVrora [Titzer et al. 2005], ATEMU [Polley et al.
2004] e OPNET [Chang 1999]. Alguns simuladores possuem funções específicas.
Outros, funções semelhantes e/ou complementares. Os simuladores existentes para IoT,
em função de suas limitações, podem não levar a podem não representar a realizada do
que se é verificado ou avaliado [Park et al. 2001]. Existem diversas limitações nos
simuladores, como modelos simplificados para simulações específicas, dificuldade para
fazer otimizações bem como encontrar a disponibilidade de protocolos relevantes já
existentes [Handziski et al. 2003].
Para validação do cenário de IoT avaliado neste capítulo, foi utilizado o
simulador Cooja. Esse simulador foi escolhido por possuir todas as características
pertinentes para se avaliar um cenário de IoT.
1.5.1. Simulação com Cooja
Abordaremos neste item, um simulador para validação de algoritmos de rede, o Cooja.
Diferentemente de outros simuladores, o Cooja é desenvolvido para aplicações de
Internet das Coisas do Contiki [Science 2005] presente no ambiente de desenvolvimento
Instant Contiki, que permite a emulação de diversos tipos de motes em nível de
hardware e/ou software. Cooja pode simular redes onde os nos sensores podem ser de
diferentes plataformas ao mesmo tempo.
A linguagem utilizada em seu arquivo de configuração é XML. Permite uma
prototipagem rápida de protocolos de rede, possibilitando a realização de simulações
com elevado número de nós em tempo aceitável, o que lhe confere um excelente
desempenho. Quanto ao tipo de simulação, pode-se realizar simulações síncronas, onde
todos os eventos têm seus inícios sincronizados com um clock, similar ao clock de um
processador de computador, por exemplo; ou assíncronas, onde os eventos dependem
uns dos outros para seus inícios e realizações.
Do ponto de vista da interação com o usuário, o Cooja oferece uma interface
gráfica que é muito útil para observar o funcionamento do algoritmo e interagir com o
mesmo em tempo de execução. Basicamente, para simular algo simples com o Cooja, é
necessário iniciar com a execução do Instant Contiki.
A) Executando o Instant Contiki
Primeiramente o Instant Contiki deverá ser descarregado. Trate-se de uma máquina
virtual Linux Ubuntu com um ambiente completo de desenvolvimento incluído o
sistema operacional Contiki, ferramentas e o simulador Cooja. O Instant Contiki está
disponível em http://sourceforge.net/projects/contiki/files/Instant%20Contiki/
Recomenda-se fazer o download da versão mais atual, que possui mais recursos
disponíveis e diversas correções a atualizações no sistema e protocolos de roteamento
presentes por padrão. O arquivo baixado deverá ser descompactado em alguma pasta no
computador.
Em seguida faz-se necessário o download do software de virtualização VMware
disponível em https://www.vmware.com/go/downloadplayer e posterior instalação.
Após instalado o VMware, inicie o Instant Contiki executando o arquivo
“Instant_Contiki_Ubuntu_12.04_32-bit.vmx” que se encontra na pasta descompactada
anteriormente como mostra a Figura 9.
Figura 9. Pasta Descompactada
Logo em seguida deve se iniciar a máquina virtual Ubuntu (Figura 10).
Figura 10. Máquina Virtual Ubuntu
Faça login no sistema (Figura 11). A senha é “user”. Logo após essa etapa, o
sistema será iniciado e estará pronto para executarmos o simulador Cooja.
Figura 11. Login no Sistema
A tela inicial do Instant Contiki será apresentada (Figura 12.).
Figura 12. Tela inicial Instant Contiki
B) Iniciando o Simulador Cooja
Execute o terminal do Ubuntu e navegue até o diretório do Cooja utilizando o seguinte
comando “cd contiki/tools/cooja” e logo em seguida o comando “ant run” para compilar
e executar o Cooja (Figura 13). Caso seja a primeira inicialização do Cooja, o comando
“git submodule update --init” anterior ao comando “ant run”.
Figura 13. Compilação e Execução do Cooja
O simulador será então compilado e inicializado (Figura 14).
Figura 14. Formulário inicial após compilado e executado
C) Criando uma Nova Simulação
Para criar uma simulação clique no menu “file” e submenu “new simulation” (Figura
15).
Figura 15. Nova Simulação
Uma nova janela irá aparecer, permitindo parametrizar inserindo um nome para a nova
simulação além de opções avançadas que incluem o modelo de rádio, a semente de
simulação a ser utilizada, dentre outros (Figura 16). Para o propósito de uma simulação
básica iremos apenas definir o nome, deixando as demais opções como se encontram.
Após definido o nome da simulação, clique no botão “create”.
Figura 16. Parametrização da Simulação
D) Ambiente de Simulação
Logo após ser criada uma simulação no Cooja é exibida a tela principal do ambiente de
simulação que consiste em 5 subjanelas (Figura 17):
1 – Network: Mostra todos os nós da simulação em uma área;
2 – Simulation control: Comandos para controle da simulação, como start, pause,
reload;
3 – Notes: Espaço para inserção de anotações;
4 – Mote output: Mostra todas as saídas (“prints”) das portas seriais de todos os nós da
simulação;
5 – Timeline: Mostra todos os eventos de simulação no tempo.
Figura
17. Ambiente de simulação
E) Adicionando Nós (Motes) à Simulação
Devemos adicionar os nós antes de iniciarmos a simulação. Isso é feito através do menu
“Motes” e em seguida “Add motes” e “Create new mote type” (Figura 18).
Figura 18. Menu adicionar nós na simulação
Escolhemos então um mote dentre os disponíveis, por exemplo, o “Sky mote” e em
seguida o firmware (funcionalidade) que melhor se adeque as necessidades do usuário.
O Instant Contiki disponibiliza uma lista de firmwares localizados em
“/home/user/contiki/examples”. Para nosso exemplo escolheremos a aplicação “rpl-
colect” disponível na pasta “ipv6” que utiliza o protocolo RPL juntamente com a função
objetivo MRHOF por padrão. Tal aplicação consiste de dois tipos de nós, sink e sender.
Os nós senders coletam e enviam informações sensoreadas para o sink durante
intervalos de tempo definidos.
Após escolhermos o mote uma janela será apresentada com as opções de escolha
do nome (descrição) do novo mote e especificação do firmware de acordo com as
Figuras 19 e 20.
Figura 19. Nome do novo mote
Figura 20. Especificação do firmware
Selecionamos então o arquivo do firmware para o sink: “udp-sink.c”. (Figura
21).
Figura 21. Seleção de arquivo firmware
Após definido o firmware a ser utilizado no mote, compilamos clicando no botão
“compile” (Figura 22).
Figura 22. Formulário de Compilação
O processo de compilação do firmware será iniciado e após completado com
sucesso o botão “create” ficará disponível (Figura 23).
Figura 23. Formulário do botão Create
Clicando no botão “create” poderemos adicionar o(s) mote(s) conforme a
necessidade. Para a nossa simulação, adicionaremos apenas um sink e as demais
configurações conforme a Figura 24.
Figura 24. Formulário adicionar motes
Após clicarmos no botão “Add motes”, os novos nós serão adicionados à área de
simulação. Repetimos o mesmo processo de adição de motes utilizado na inserção do
sink porém agora para os nós senders, definindo o firmware para o arquivo “udp-
sender.c” e adicionando 5 nós.
Finalizado o processo de inserção dos motes, a área de simulação deverá ser
ajustada conforme as Figuras 25 e 26.
Figura 25. Ajuste de Topologia Figura 26. Topologia Gerada
F) Executando uma Simulação
Para executarmos uma simulação após adicionados os nós, é necessário apenas clicar no
botão “start” da subjanela “Simulation control”. Os resultados podem ser visualizados
em tempo real através de um dos plugins do Cooja chamado “Collect View”. Para
acessarmos o referido plugin, clicamos com o botão auxiliar do mouse sobre o nó
principal da simulação (sink), “Mote tools for Sky 1” e em seguida “Collect View”
(Figura 27).
Figura 27. Menu Visualização dos Resultados
A janela do plugin será apresentada e consiste em diversas métricas organizadas
em seções (abas). A Figura 28 mostra um exemplo de resultado para a métrica Consumo
Médio de Potência.
Figura 28. Consumo Médio de Potência
A simulação criada poderá ser salva por meio do menu “File” conforme a Figura
29.
Figura 29. Formulário Save simulation
E posteriormente poderá ser carregada não sendo necessário a criação de uma
nova simulação que possua as mesmas características.
1.6. Conclusão
Neste trabalho, nós apresentamos uma abordagem para Seleção Dinâmica de Rotas em
IoT baseada em Informações de contexto das aplicações. Os resultados mostraram que a
abordagem, considerando todas as funções objetivo propostas, é mais eficiente quando
comparado com a abordagem utilizada pelo protocolo RPL em sua versão original. Isso
foi possível porque as funções objetivo que foram propostas para adaptação do
roteamento no protocolo RPL, apresentaram resultados positivos com relação a
Estimativa de Transmissão (ETX), Número de Saltos (NS), Energia Consumida (EC),
Energia Residual (ER) e Custo de Recebimento de Mensagens (CR).
Este capítulo também apresentou as principais características de simulação de
redes e as etapas de construção de uma simulação para IoT utilizando o simulador
Cooja. Uma simulação básica foi desenvolvida para mostrar a forma de se validar uma
proposta semelhante a que foi apresentada neste trabalho.
A avaliação da proposta por meio de simulação, demonstrou que a utilização da
abordagem para Seleção Dinâmica de Rotas em IoT baseada em Informações de
contexto das aplicações apresenta resultados positivos em todas as métricas avaliadas.
Pretende-se, em trabalhos futuros, implementar essa abordagem em outros protocolos
aplicados a IoT considerando a escalabilidade dos dispositivos que compõem uma
estrutura de IoT.
Referência
Al-Fuqaha, A., Guizani, M., MOhammade, M., Aledhari, M., e Ayyash, M. (2015).
Internet of things: A survey on enabling Technologies, protocols, and applications.
IEEE Communications Surveys Tutorials, 17(4): 2347-2376.
Atzori, L., Iera, A. and Morabito, G. (2010). The internet of things: A survey, Computer
networks 54(15): 2787–2805.
Baldauf, M., Dustdar, S., Rosenberg, F. (2007) “A survey on context-aware systems”,
International Journal of Ad Hoc and Ubiquitous Computing, vol. 2, no. 4, pp.
263277.
Boulis, A. (2009). Castalia version 2.1 user’s manual.
Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., Levis, P., Struik, R., Kelsey, R.,
Clausen, T. H., e Winter, T. (2012). RPL: IPv6 Routing Protocol for Low-Power and
Lossy Network. RFC 6550.
Brandt, A., J. Buron, and G. Porcu. Home Automation Routing Requirements in Low-
Power and Lossy Networks. Internet Engineering Task Force (IETF). 2010. RFC
5826.
Chang, X. (1999). Network simulations with opnet. In WSC ’99: Proceedings of the
31st Conference on Winter Simulation, pages 307–314, New York, NY, USA. ACM.
Chen, Y., Chanet, J., Hou, K., Shi, H., De Sousa, G.: A scalable Context-Aware
Objective Function (SCAOF) of Routing Protocol for Agricultural Low-Power and
Lossy Networks (RPAL). Sensors 19507–19540 (2015)
Curren, D. (2005). A survey of simulation in sensor networks. project report (CS580),
University of Binghamton.
Dohler, M., et al. Routing Requirements for Urban Low-Power and Lossy Networks.
Network Working Group . 2009. RFC 5548.
Downard, I. (2004). Simulating sensor networks in ns-2.
Dunkels, A., Osterlind, F., Tsiftes, N., e He, Z. (2007). Software-based on-line energy
estimation for sensor nodes. In Proceedings of the 4th Workshop on Embedded
Networked Sensors, EmNets ’07, pages 28-32, New York, NY, USA. ACM.
Egea -Lopez, E., Vales-Alonso, J., Martinez-Sala, A., Pavon-Marino, P., and Garc´ıa-
Haro, J. (2005). Simulation tools for wireless sensor networks. In Proceedings of the
International Symposium on Performance Evaluation of Computer and
Telecommunication Systems (SPECTS’05).
Forbes (2014). Internet of Things By The Numbers: Market Estimates And Forecasts.
Gaddour, O.; KOUBÂA, A.; BACCOUR, N.; ABID, M. OF-FL: QoS-aware fuzzy
logic objective function for the RPL routing protocol. In: Modeling and Optimization
in Mobile, Ad Hoc, and Wireless Networks (WiOpt), 2014 12th International
Symposium on. IEEE, 2014, p. 365-372, 2014.
Handziski, V., Kopke, A., Karl, H., and Wolisz, A. (2003). A common wireless sensor
network architecture. Proc. 1. GI/ITG Fachgesprach Sensornetze(Technical Report
TKN-03-012 of the Telecommunications Networks Group, Technische Universitat
Berlin), Technische Universitat Berlin, Berlin, Germany, pages 10–17.
IETF. IETF Datatracker. [Online] Agosto de 2013.
https://datatracker.ietf.org/wg/roll/charter/.
Jayaraman, P. P.; Delirhaghighi, P. SA-A-WSN: Situation-aware adaptation approach
for energy conservation in wireless sensor network. In: Intelligent Sensors, Sensor
Networks and Information Processing, 2013 IEEE Eighth International Conference
on. IEEE, 2013, p. 7-12, 2013.
Levis, P., Lee, N., Welsh, M., and Culler, D. (2003). TOSSIM: Accurate and scalable
simulation of entire TinyOS applications. In Proceedings of the 1st International
Conference on Embedded Networked Sensor Systems, pages 126–137. ACM New
York, NY, USA.
Martocci, J., et al. Building Automation Routing Requirements in Low-Power and
Lossy Networks. Network Working Group. 2010. RFC 5867.
Makris, P., Skoutas, D. N., Skianis, C. (2013) “A Survey on Context-Aware Mobile and
Wireless Networking: On Networking and Computing Environments’ Integration”,
IEEE Communications Surveys and Tutorials, vol. 15, no. 1, pp. 362-386
Miorandi, D., Sicari, S., De Pellegrini, F. and Chlamtac, I. (2012). Internet of things:
Vision, applications and research challenges, Ad Hoc Networks 10(7): 1497–1516.
Park, S., Savvides, A., and Srivastava, M. (2001). Simulating networks of wireless
sensors. In Proceedings of the 33nd Conference on Winter Simulation, pages 1330–
1338. IEEE Computer Society Washington, DC, USA
Kushalnagar, N., Montenegro, G., & Schumacher, C. 2007. RFC4919: IPv6 over low-
power wireless personal area networks 6LoWPANs: Overview, assumptions,
problem statement, and goals. Retrieved from http://tools.ietf.org/html/rfc4919
Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K.,
Struik, R., Vasseur, J., and Alexander, R. (2012). RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks. RFC 6550.
Martocci, J., et al. Building Automation Routing Requirements in Low-Power and
Lossy Networks. Network Working Group. 2010. RFC 5867.
Miorandi, D., Sicari, S., De Pellegrini, F. and Chlamtac, I. (2012). Internet of things:
Vision, applications and research challenges, Ad Hoc Networks 10(7): 1497–1516.
Osterlind, F.; Dunkels, A.; Eriksson, J.; Finne, N.; Voigt, T. Cross-level sensor network
simulation with cooja. In: Local Computer Networks, Proceedings 2006 31st IEEE
Conference on. IEEE, 2006, p. 641-648, 2006.
Pister, K., et al. Industrial Routing Requirements in Low-Power and Lossy Networks.
Network Working Group . 2009. RFC 5673.
Polley, J., Blazakis, D., McGee, J., Rusk, D., Baras, J., and Karir, M. (2004). Atemu: A
fine-grained sensor network simulator. In IEEE Communications Society Conference
on Sensor and Ad Hoc Communications and Networks. Citeseer.
Science, S. I. C. (2005). The Contiki Operating System.
Sharkawy, B.; Khattab, A.; Elsayed, K.M.F. Fault-tolerant RPL through context
awareness. In: Internet of Things (WF-IoT), 2014 IEEE World Forum on. IEEE,
2014. p. 437-441, 2014.
Sobral, J., Rabêlo, R., Oliveira, D., Lima, J., Araújo, H., e Holanda, R. (2015). A
framework for improving the performance of iot applications. In The 14 th
International Conference on Wireless Networks, 2015, pages 143-140, Las Vegas,
NV, USA.
Titzer, B. L., Lee, D. K., and Palsberg, J. (2005). Avrora: scalable sensor network
simulation with precise timing. In IPSN ’05: Proceedings of the 4th International
Symposium on Information Processing in Sensor Networks, page 67, Piscataway,
NJ, USA. IEEE Press.
Varga, A. et al. (2001). The OMNeT++ discrete event simulation system. In
Proceedings of the European Simulation Multiconference (ESM 2001), pages 319–
324.
Vasseur, J., et al. Routing metrics used for path calculation in low power and lossy
networks. Network Working Group . 2012. RFC 6551.
Welbourne, E., Battle, L., Cole, G., Gould, K., Rector, K., Raymer, S., Balazinska, M.,
e Borriello, G. (2009). Building the Internet of Things Using RFID: The RFID
Ecosystem Experience. Internet Computing, IEEE, 13(3):48 –55.
Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K.,
Struik, R., Vasseur, J., and Alexander, R. (2012). RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks. RFC 6550.
Zhang, C., Barnett, R., Landman, U. “Bonding, Conductance and Magnetization of
Oxygenated Au Nanowires” ed. Physical Review Letters, February 2008, Vol.: 100,
046801
