RAP: A Real-Time Communication Architec-

Um dos principais trabalhos voltados para atender aos requisitos específicos de diferenciação de serviço, como restrições temporais é o RAP [Lu et al. 2002], em que os autores propuseram uma arquitetura de comunicação para rede de sensores em larga escala com centenas de nodos sensores. RAP foi o primeiro estudo detalhado sobre o desem- penho das questões de cumprimento de prazo em uma rede de sensores multi-saltos.

A arquitetura do RAP, ilustrada na figura 2.1 é composta por cinco componentes: (i) o componente Query/Event Service APIs é uma interface entre a aplicação de sensoriamento e as camadas inferiores do protocolo; (ii) o componente Location Addressed Protocol (LAP)

é responsável pelo provimento de três tipos de comunicação: unicast, area multicaste area anycast; (iii) o componente Geographic Forwar- ding(GF) routing protocol é responsável por fazer o roteamento guloso dos pacotes; (iv) o componente Velocity Monotonic (packet) Schedu- ling (VMS) é responsável por escalonar os pacotes de acordo com o prazo e a distância do nodo fonte ao sink; (v) o MAC é priorizado para comportar a política definida pelo VMS.

Pode-se destacar o terceiro componente, GF, da arquitetura RAP por se tratar do protocolo de roteamento, que é o foco do trabalho de- senvolvido na primeira parte da tese. Dotado do conhecimento posi- cionamento, o protocolo realiza o roteamento geográfico de pacotes. O método adotado para rotear os pacotes é descrito em [Karp e Kung 2000]. Neste método, a decisão de repassar o pacote para o vizinho consideram dois fatores: i) o vizinho precisa ter a menor distância do destino dentre todos os vizinhos e ii) o vizinho precisa estar mais perto do que o nodo que precisa enviar o pacote. Segundo os autores, este método é escalável em relação ao número de nodos na rede e tamanho da rede. Outra característica do método GF, quanto mais densa a rede, maior a probabilidade de se encontrar o melhor caminho entre o nodo fonte e o nodo destinho.

Os resultados em [Lu et al. 2002] mostram que o RAP provê um cumprimento de prazos de até 60% com uma alta taxa de dados de ∼= 70 pacote por segundo e carga gerada por um terço dos nodos da rede. Entretanto, o RAP não foi projetado para o redes móveis. Além disso, o RAP não considera o tamanho do buffer como um aspecto limitador para o desempenho do protocolo.

duas características importantes que devem ser levadas em considera- ção por um protocolo de roteamento, que não foram consideradas pelo RAP. A primeira característica é a carga gerada por todos os nodos da rede, pois 100% dos nodos da rede, com exceção dos nodos sor- vedouros, são nodos fontes. Isso gera não somente uma grande carga de dados, mas uma intensa carga gerada por mensagens de controle do protocolo. No caso do cenário da corrida, todos os nodos são geradores de mensagens, pois cada nodo realiza o sensoriamento das condições físicas do atleta, por isso, cada medição precisa ser entregue ao nodo sorvedouro mais próximo.

A segunda característica é o fato de todos os nodos fontes se movimentarem, o que pode aumentar a sobrecarga na rede devido à manutenção das rotas. Outro aspecto importante é a política de escolha de rota. A política de escolha de rota é feita puramente pela posição geográfica dos nodos, o que pode gerar congestionamento em caso de larga escala de nodos fontes, além de drenar a energia dos nodos fontes que são sempre escolhidos para retransmissão.

Estes elementos presentes no protocolo RAP não são adequados para o cenário visualizado na corrida. Por outro lado, a diferenciação de serviço proposta pelo RAP é uma estratégia adequada para priorizar mensagens com requisitos de diferenciação de serviço. A diferencia- ção de serviço é um ponto importante no cenário da corrida, pois há dois tipos de mensagens trafegadas, com e sem requisitos diferencia- ção de serviço.

Fig. 2.1: Arquitetura RAP.

2.1.2 SPEED: A Stateless Protocol for Real-Time Communi- cation In Sensor Networks

O protocolo SPEED [He et al. 2003] é um protocolo de rote- amento com diferenciação de serviço para aplicações soft real-time. O SPEED cunhou a estratégia denominada “velocidade de transmis- são dos pacotes”, o que influenciou vários protocolos desde então. O protocolo SPEED também é um protocolo de roteamento geográfico e também faz uso da estratégia gulosa para realizar a retransmissão.

O SPEED constrói as rotas dos nodos fontes ao sink baseando-se na posição geográfica e na capacidade de “velocidade de transmissão” dos nodos. A velocidade de transmissão é obtida de acordo com a equação 2.1:

V elocidade = Dvizinho− Ddestino

RT T (2.1)

nho e o nodo destino e o RTT computa o round trip time da mensagem que é expresso pela fórmula 2.2:

RT T = Tack− Tenvio (2.2)

onde Tacké o tempo de recebimento do ack e Tenvioé o tempo que o pacote foi enviado, ou seja, o tempo do envio de uma mensagem e o recebimento do ACK da mesma.

Quanto a manutenção de de vizinhança o SPEED faz pela troca periódica de mensagens. Assim, os vizinhos que têm o menor atraso são escolhidos para retransmissão. O protocolo SPEED tem um meca- nismo chamado de backpressure-rerouting que é usado para lidar com os problemas causados por congestionamento nas rotas ou desconexão provocada quando um nodo na rota falha. Neste mecanismo, quando os nodos detectam uma situação de congestionamento ou ruptura na rota, os nodos enviam mensagens de alerta para o nodo fonte, para que esse reduza a taxa de transmissão ou procure novas rotas. Dessa forma, os nodos na rota enviam mensagens de aviso para o nodo fonte a fim de evitar congestionamento, sinalizando ao nodo fonte para procurar novas rotas.

O protocolo SPEED faz a busca pelas rotas mais rápidas para atender aos requisitos temporais das mensagens, além de prover um mecanismo para evitar o congestionamento das rotas. Entretanto, o protocolo foi projetado para redes estáticas, e o fato de realizar ma- nutenção de rotas em ambiente móvel não é viável devido à constante mudança de topologia. Fazer a manutenção de rota em ambiente mó- vel pode onerar bastante a rede de sensores, além de tornar difícil o

cumprimento de prazos na entrega de mensagens, pois seria necessário reconstruir as rotas caso os enlaces deixassem de existir.

2.1.3 MMSPEED: Multipath Multi-SPEED Protocol for QoS