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.

Projeto de Estimador de Estado de Enlace - Semestre 2

Índice