Espaço do Bolsista

Assunto: Projeto de Estimador de estado de enlace
Aluno: Nelson Espindola Alves
Matricula: 141003075-0

Horário disponível

Segunda-Feira - 13:30 às 15:30 (2h)
Terça-Feira - 13:30 às 17:30 (4h)
Quarta-feira - 9:40 às 11:40 e 15:20 às 17:30 (4h)
Quinta feira - 7:30 às 11:30 e 13:30 às 17:30 (8h)
Sexta-feira - 15:40 às 17:30 (2h)

Total = 20 hrs

Progresso da bolsa - 2018/2

Base de conhecimento

Este tópico foi idealizado com a intenção de juntar informações encontradas sobre o assunto do projeto para formar uma base de conhecimento para o bolsista atual e também para futuros estudantes do câmpus interessados sobre o assunto, seja para a continuação da mesma bolsa ou para um tcc.

uIp

Conjunto mínimo de recursos necessários de uma pilha TCP / IP. Como resultado dessa alteração, o uIP somente lida com uma única interface de rede e não implementa o protocolo UDP, porém possui como foco central os protocolos IP, ICMP e TCP. Deste modo, devido ser mais leve e a sua adaptabilidade aos sistemas com baixos recursos (pouco processamento e pouca memória), a pilha de comunicação uIP acabou se encaixando no âmbito da Internet das Coisas e servindo como um dos pilares principais para a sua execução na prática.

Assim para tais sistemas utiliza-se a pilha uIP que implementa apenas o conjunto mínimo de recursos necessários ao funcionamento do TCP, o que permite retirar alguns dos mecanismos como: janela deslizante, controle de fluxo, controle de congestionamento, dados urgente e cálculos de verificação em prol de uma considerável economia de memória aos sistemas de pequeno porte.

Apesar da maioria das implementações TCP utilizarem a janela deslizante para enviar dados em sucessão sem que seja necessário esperar uma confirmação para cada segmento, o uIP não guarda pacotes enviados e permite que somente um segmento TCP por conexão receba uma confirmação de entrega (frequentemente chamado de acknowledgment ou ack) em determinado tempo, inviabilizando a implementação deste mecanismo, já que tornará a aplicação mais complexa por não guardar os pacotes enviados.

O controle de fluxo é implementado no TCP para prover comunicação entre os mais variados tamanhos de memória de diferentes hosts, onde o destinatário da mensagem indica em uma janela o tamanho disponível em seu buffer. Em uIP, a aplicação não pode enviar mais dados do que o host receptor possa armazenar, a aplicação também não pode enviar mais dados do que a quantidade de bytes enviadas permitida pelo servidor (CONTIKI,2012). Como uIP manuseia apenas um segmento TCP por conexão e o controle de congestionamento serve justamente para limitar o número de conexões simultâneas TCP na rede, este mecanismo não se faz necessário.

Rime

Diferentemente das arquiteturas de comunicação tradicionais, as camadas de abstração da pilha Rime são extremamente simples tanto em relação à interface quanto a implementação e são combinadas para formar abstrações poderosas em alto nível. Por ser tão simples e genérica, cada camada pode ser utilizada para objetivos diferentes. Desse modo, a pilha acaba por simplificar a implementação de protocolos de redes de sensores e facilitando o reuso de código. Rime possui uma arquitetura limitada que não permite uma estrutura totalmente modular, podendo somente ser substituída a camada mais baixa, que é o módulo abc(anonymous best effort broadcast – permite uma abstração de um canal de dezesseis bits em que envia um broadcast sem endereçamento) e a camada de aplicação. Porém, a presença do código de Rime é pequena e leve não ultrapassando dois quilobytes e exigindo requisitos de memória por volta de dez bytes.

RDC

A camada Radio Duty-Cycle (RDC) manipula o período de sono dos nós. Esta camada decide quando pacotes serão transmitidos e garante que os nós estejam acordados quando os pacotes forem recebido.

Framer

O driver Framer é na verdade um conjunto de funções para enquadrar os dados a serem transmitidos e para os dados recebidos. As implementações do Framer estão localizadas no core / net / mac, das quais os mais notáveis são framer-802154 e framer-nullmac.

Contiki

O que é o Contiki

Contiki é um sistema operacional de código aberto que conecta micro controladores de baixa potência à Internet. Contiki apoia plenamente o padrão IPv6 e IPv4 e os últimos padrões wireless de baixo consumo: 6LoWPAN , RPL, COAP. Contiki é executado em uma grande quantidade de dispositivos sem fio de baixa potência (Contiki et al. 2013). O Contiki introduziu a comunicação IP em redes de sensores de baixa potência (CONTIKI, 2012), este é desenvolvido por um grupo de desenvolvedores liderados por Adam Dunkels e contém duas pilhas de comunicação: uIP e Rime.

O kernel é orientado a eventos, mas o sistema suporta dar preferência à programação multi-threading que pode ser aplicado em uma base por processo. De preferência multi-threading é implementado como uma biblioteca que está ligada apenas com programas que exigem explicitamente multi-threading (DUNKELS et al, 2004). Este sistema operacional oferece suporte à comunicação IP, neste trabalho utilizamos uma pilha de comunicação μIP a qual também é suportada pelo sistema operacional, tanto nas versões quatro (IPv4) como na versão seis (IPv6). μiP e Contiki são utilizadas em centenas de empresas em sistemas de navios cargueiros, satélites e equipamentos de perfuração de petróleo, e são altamente reconhecidos pela popular ferramenta de escaneamento de redes nmap (CONTIKI 2.6, 2012)

Download Contiki e VMWare Player

Para instalar o Contiki acesse:

http://sourceforge.net/projects/contiki/files/Instant%20Contiki/

Foi escolhido o software VMWare Player pra simular a maquina virtual do Contiki. O VMWare pode ser baixado em:

http://www.vmware.com/go/downloadplayer/

Instalação

Em breve...

Teclado de Inglês para Português: > sudo dpkg-reconfigure keyboard-configuration

Estrutura genérica da aplicação Contiki

PROCESS(process_name, "The string representation of the process name"); 
AUTOSTART_PROCESSES(&process_name); 

PROCESS_THREAD(process_name, process_event_t, process_data_t){
 PROCESS_BEGIN();
 /*Execução do código*/
 PROCESS_END();
}

Erros previstos

Tópico reservado para anotar soluções de problemas previstos no uso do mote MicaZ no Cooja.

Cooja não compila arquivos para mote MicaZ

Esse é um erro que já é deparado em interações iniciais com o Cooja. Qualquer que seja o arquivo .c compilado pro MicaZ, dá o seguinte erro:

 
In file included from ../../cpu/avr/dev/flash.c:4:0:
/usr/lib/avr/include/avr/boot.h:112:16: error: attempt to use poisoned "SPMCR"
 #elif defined (SPMCR)

Este é um bug do avr-gcc e é bem reportado. Então foi fácil consertar. Você precisa corrigir /usr/lib/avr/include/avr/boot.h da seguinte forma:

#if defined (SPMCSR)
#  define __SPM_REG SPMCSR
#else
 #if defined (SPMCR)
  #  define __SPM_REG SPMCR
#else
  #  error AVR processor does not provide bootloader support!
 #endif
#endif

Com isso, os erros de compilação passam a não aparecer mais.

Módulo MicaZ não recebe informação

Esse problema é caracterizado usando o módulo MicaZ no Cooja. Usando exemplos simples como "examples/rime/example-abc.c", os motes transmitiam as mensagens porém o outro lado não recebia e vice-versa (printf da função receive não aparecia no output do Cooja).

A solução foi trocar os protocolos no arquivo "platform/micaz/contiki-conf.h", deixando assim:

#define NETSTACK_CONF_NETWORK sicslowpan_driver
#define NETSTACK_CONF_MAC     csma_driver
//#define NETSTACK_CONF_MAC     nullmac_driver
#define NETSTACK_CONF_RDC     nullrdc_driver
//#define NETSTACK_CONF_RDC     sicslowmac_driver
#define NETSTACK_CONF_FRAMER  framer_802154

Criando um makefile

Para cada código .c que for criado, é necessária a criar o arquivo que contém as instruções para as ferramentas de compilação da tarefa, o conhecido makefile. O arquivo makefile deve estar no mesmo diretório do código criado para a aplicação Contiki. A seguir, alguns passos de como criar o seu makefile: Em breve...

Iniciando a implementação

Process

Como visto anteriormente, o process é um método essencial para o funcionamento da aplicação. Nesta seção, iremos estar explicando melhor cada método da biblioteca process.h e como são implementados no Contiki.

Uma process_thread contém o código do processo. Nela há uma protothread que é invocada pelo escalonador de processos. A protothread é uma maneira de estruturar o código de modo que permita que o sistema execute outras atividades enquanto o código está aguardando que algum determinado evento aconteça.

Vamos agora para os métodos:

PROCESS() -> Criador do processo.
AUTOSTART_PROCESS() -> Inicia o processo automaticamente passado o seu nome por referência.
PROCESS_BEGIN() -> Define o inicio de um processo.
PROCESS_END() -> Define o fim de um processo.
PROCESS_WAIT_EVENT() -> bloqueia o processo atualmente em execução até que o processo receba um evento.
PROCESS_WAIT_EVENT_UNTIL() -> Necessita ser passada uma condição que deve ser verdadeira para chamar o processo.
PROCESS_EXITHANDLER(handler) -> Especifica uma ação quando há uma saída do processo.

Timers

A utilização dos timers nos permitirá acionar eventos em um determinado momento, acelerando a transição de um estado para outro e automatizar um determinado processo ou tarefa.

No Contiki existem 4 tipos de timers:

Simple timer: A aplicação deve conferir manualmente se o timer expirou. #include "sys/timer.h".
Callback timer: Quanto o timer expira o callback chama uma determinada função. #include "sys/ctimer.h".
Timer Event: O mesmo que acima, mas em vez de chamar uma função, quando o timer expira posta um evento sinalizando sua expiração. #include "sys/etimer.h".
Real time timer: O módulo em tempo real lida com o agendamento e execução de tempo real tarefas. #include "sys/rtimer.h"

Clock Timer

A biblioteca clock é a interface entre o Contiki e a funcionalidade clock da plataforma especificada.

CLOCK_SECOND - A biblioteca clock define esse macro para converter segundos na resolução de instante da plataforma.

Interface de sistema de arquivo do Contiki

A interface do sistema de arquivos Contiki (CFS) define uma API abstrata para ler diretórios e ler e gravar arquivos. A seguir alguns principais métodos e atributos da biblioteca.

cfs_open (const char *name, int flags) - Abre um arquivo.
cfs_close (int fd) - Fecha um arquivo.
cfs_read (int fd, void *buf, unsigned int len) - Lê o dado de um arquivo aberto.
cfs_write (int fd, const void *buf, unsigned int len) - Escreve dado em um arquivo aberto.
cfs_seek (int fd, cfs_offset_t offset, int whence) - Procura uma posição especifica em um arquivo aberto.
cfs_remove (const char *name) - Remove um arquivo.
CFS_READ - Atributo que especifica ao cfs_open() que o arquivo aberto é para leitura.
CFS_WRITE - Atributo que especifica ao cfs_open() que o arquivo aberto é para escrita.

Packet buffer

Um packet buffer é uma estrutura que é usada para criar pacotes de saída ou para armazenar um pacote de entrada. Um packet buffer também é usado para realizar operações em um pacote e só é possível armazenar um pacote por vez.

Resumo artigo estimador estado de link

Link do artigo

O estimador de estado de link de radios no WSN tem um impacto fundamental na performance de rede e também afeta o design de protocolo da camada superior. Este artigo fornece uma pesquisa abrangente sobre literatura relacionada, abrangendo características dos links de baixa potência, os conceitos fundamentais de estimativa de qualidade de links em RSSFs, uma taxonomia de estimadores de qualidade de link existentes e sua análise de desempenho.

A propagação dos sinais de rádio são afetados por muitos fatores que contribuem para a degradação do sinal. Os efeitos desses fatores são mais significantes se tratando de propagação sinal wireless com baixa potência, tipicamente usados em WSN. De fato, sua qualidade é instável e a conectividade é assimétrica.

Hoje em dia sabe-se que temos três fatores que levam a links inseguros:

O ambiente, no qual causam efeitos de propagação de multi-percursos, contribuindo com os ruídos.
Interferência, que resulta em transmissões simultâneas dentro de uma rede sem fio.
hardwares transmissores, que podem distorcer os sinais enviados e recebidos devido ao seu ruído interno. No WSN, esses tranmissores transmitem sinais de baixa potência, no qual são mais propensos à ruido, interferência e distorção de multipercursos.

Na literatura, muitos estudos focam na caracterização estatística de links de baixa potência através de uma teoria de estimação, que é comumente conhecida como Estimador de qualidade do link, para estudar os comportamentos analisados até então. Entregar dados através de links com alta qualidade melhora o rendimento da rede, limitando a perda de pacotes e maximizando vida útil, minimizando o número de retransmissões e evitando a reprogramação de rotas desencadeada pela falha dos links. A estimativa da qualidade dos links também desempenha um papel crucial para mecanismos de controle para manter a estabilidade da topologia.

Hardware de comunicação do rádio

Interferência interna x externa

- Interferência externa pode ocorrer em redes que operam na mesma banda de frequência que o WSN; - Interferência interna pode ocorrer pela transmissão simultânea de nós pertencentes ao mesmo WSN. Interferência externa tem um forte impacto no desempenho das comunicações WSN porque aumenta a taxa de perda de pacotes, que por sua vez aumenta o número de retransmissões e, portanto, a latência das comunicações.

Passos para a estimação da qualidade do link

Basicamente, o LQE consiste em avaliar uma métrica, isto é, uma expressão, dentro de uma janela de estimativa w (por exemplo, a cada w segundos, ou com base em w pacotes recebidos / enviados). Nos referimos a essa métrica como o Estimador de qualidade de link (LQE). A avaliação de LQE requer medições de link. Por exemplo, para avaliar o estimador de PRR, medições de link consistem em extrair o número de seqüência de cada recebido pacote. O monitoramento de links define uma estratégia para ter tráfego sobre o link, permitindo medições de link. Portanto, o processo de estimativa da qualidade do link envolve três etapas: monitoramento de link, medições de link e avaliação métrica.

- Monitoramento de links. Existem três tipos de monitoramento de link: (i) monitoramento de link ativo, (ii) monitoramento de link passivo e (iii) monitoramento de link híbrido.

(i) Monitoramento de link ativo. No monitoramento de link ativo, um nó monitora os links para seus vizinhos enviando pacotes de teste. Os pacotes de sonda podem ser enviados por transmissão, ou por unicast.
(ii) Monitoramento de link passivo. Ao contrário do monitoramento de link ativo, as explorações de monitoramento de link passivo tráfego existente sem incorrer em sobrecarga adicional de comunicação. De fato, um nó ouve os pacotes transmitidos, mesmo que esses pacotes não sejam endereçados a ele . Ele também pode ouvir os ACK de mensagens enviadas por diferentes vizinhos. Monitoramento de link passivo tem sido amplamente usado em RSSFs devido a sua eficiência energética comparado ao monitoramento de link ativo.
(iii) Monitoramento de link híbrido. O uso de um mecanismo híbrido combinando ativos e monitoramento passivo pode produzir um equilíbrio eficiente entre medições de link atualizadas e eficiência energética.

- Medições de link 4.1.2. Medidas de Link. As medições de links são realizadas recuperando informações úteis: (i) de pacotes recebidos / confirmações ou (ii) de pacotes enviados. Dados recuperados de pacotes / confirmações recebidos, como números sequenciais, timestamp, O RSSI e o LQI são usados para calcular os estimadores de qualidade de link do lado do receptor. Por outro lado, os dados recuperados de pacotes enviados, por exemplo, números de seqüência, timestamp, e contagem de retransmissão de pacotes, permite o cálculo do link do lado do remetente estimadores de qualidade.

- Avaliação Métrica. Com base nas medições de link, uma métrica é avaliada para produzir uma estimativa da qualidade do link. Geralmente, essa métrica é projetada de acordo com certa técnica de estimação, que pode ser uma média simples ou mais sofisticada técnica como filtragem, aprendizagem, regressão, lógica difusa, etc.

REQUISITOS PARA A ESTIMAÇÃO DO ESTADO DE LINK

A estimativa eficiente da qualidade do link possui vários requisitos, que são descritos a seguir.

- Eficiência energética. Como a energia pode ser uma grande preocupação em RSSFs, os LQEs devem envolver baixa sobrecarga de computação e comunicação. Consequentemente, algumas técnicas de estimativas complexas podem não ser apropriadas em RSSFs. Além disso, os LQEs também deve envolver baixa sobrecarga de comunicação. Normalmente, um monitoramento ativo com alta taxa de beacons deve ser evitada, pois consome energia.

- Precisão. Refere-se à capacidade do LQE para caracterizar corretamente o estado do link, isto é, capturar o comportamento real do link. A precisão da estimativa da qualidade do link impacta grandemente a eficácia dos protocolos de rede.

- Reatividade. Refere-se à capacidade de reagir rapidamente a mudanças persistentes na qualidade do link. Por exemplo, um LQE reativo permite protocolos de roteamento e mecanismos de controle de topologia para se adaptar rapidamente às mudanças na conectividade subjacente.

- Estabilidade

Uma pesquisa sobre estimadores de qualidade de link

LQEs em WSNs podem ser classificados em duas categorias: baseadas em hardware e software.

LQE baseado em hardware

Três LQEs pertencem à família de LQEs baseados em hardware: LQI, RSSI e SNR. Estes estimadores são diretamente lidos a partir do transceptor de rádio2 (por exemplo, o CC2420). Sua vantagem é que eles não exigem nenhum cálculo adicional.

O RSSI pode fornecer uma estimativa rápida e precisa de se um link é de muito boa qualidade (região conectada). O RSSI mostrou-se muito estável (desvio padrão inferior a 1 dBm) ao longo de um curto intervalo de tempo (2 s), assim, uma única leitura RSSI (através de uma recepção de pacotes) é suficiente para determinar se a ligação está na região de transição ou não.
O LQI pode determinar se o link é de muito boa qualidade ou não. No entanto, não é um bom indicador de ligações de qualidade intermédia devido à sua alta variação,

a menos que seja calculada a média de um certo número de leituras.

A SNR é um bom indicador e até um preditor da PRR, mas não é precisa,

especialmente para links intermediários.

Projeto de Estimador de Estado de Enlace - Semestre 2

Índice