VANETs e sua possibilidade de comunicações entre veículos facilitaria o avanço dos ITS, além de atingir ainda o consumidor final.

No entanto, a realização de tais redes está ligada à necessidade de disseminação de dados, seja em arquiteturas puramente ad-hoc ou híbridas. A disseminação de dados deve atender às demandas, enviando a informação àqueles que a desejarem, enquanto atende a certos objetivos, como alta taxa de dados. 

2.1 DSRC

DSRC é a sigla para Dedicated Short Range Communications, Comunicações Dedicadas em Curto Alcance, protocolo desenvolvido para oferecer comunicações entre veículos e entre veículos e equipamentos de acostamento. O uso mais conhecido de DSRC é no pagamento eletrônico de pedágios e de estacionamentos. Todavia, o futuro almeja aplicações mais ousadas, tais como evitar colisões (acidentes automobilísticos), avisar aos motoristas quando ambulâncias estão se aproximando (para que abram caminho), inspeção de segurança em veículos.

O protocolo possui alta taxa de dados, de até 27Mbps, em alcance de até 1km, num padrão multicanal baseado no IEEE 802.11/802.11a e já opera nos EUA em um espectro licenciado de 75MHz em 5.9GHz pelo governo, para aplicações em ITS, Intelligent Transport Systems.

Embora baseie sua camada física no IEEE 802.11a, DSRC diferencia-se deste sobretudo por operar numa banda já dita licenciada, além de permitir aplicações adaptadas a altas velocidades de veículos (até 190km/h) e 7 canais de 10MHz cada dando suporte a aplicações seguras e não seguras.

A banda de 5.9GHz consiste de sete canais de 10MHz que incluem um controle de canal e seis controles de serviços. DSRC, que envolve comunicações V2V (Veículo para veículo) e V2R (Veículo para infra-estrutura de acostamento), deverá suportar aplicações seguras e não-seguras. No entanto, a prioridade é dada às aplicações seguras, uma vez que o uso da banda de 5.9GHz pelas aplicações não seguras seria inapropriado se isto conduzir a uma depreciação de performance das aplicações seguras. Isto se deve ao fato de que supõe-se que aplicações seguras em VANETs devam ser as responsáveis por assegurar vidas, alertando os motoristas de condições impróprias de direção. Assim, o tempo de resposta e confiança são requisitos básicos em aplicações seguras.

A camada física do DSRC usa modulação OFDM (Orthogonal frequency-division multiplexing) para multiplexação de dados.

A descrição de um quadro de dados da camada física DSRC:

A1-A10 são dez símbolos de treinamento idênticos de 2 bytes, cada um com 16 amostras. Um subconjunto destes símbolos é usado para detecção de dados, ganho de controle automático e várias outras combinações. Os demais símbolos de treinamento são usados para estimativas de offset (distância) de freqüências inferiores e estimativas de sincronização de símbolos inferiores. Os símbolos de treinamento são seguidos de dois símbolos de treinamento de 4 bytes, C1 e C2, usados para estimativas de canal e sincronia de símbolos e freqüências superiores. C1 e C2 têm, 64 amostras, e CP1, de 32 amostras, é o prefixo cíclico que executa proteção contra interferência inter-símbolos (distorção do sinal recebido). Após os símbolos de treinamento, seguem-se os símbolos OFDM modulados. O primeiro símbolo OFDM é o cabeçalho da camada física, modulado por BPSK, e que especifica o tipo de modulação usado nos símbolos OFDM.

Cada símbolo OFDM consiste de 64 amostras e um CP de 16 amostras pré-anexado para cada símbolo OFDM, para combater interferência inter-símbolos.

Transmissor DSRC

Figura 1. Transmissor DSRC (adaptado de [1])

O fluxo de dados de entrada primeiro é embaralhado através de uma seqüência de bits pré-definida aleatória. Os dados embaralhados são codificados usando convolução de 64 estados e taxa ½.

Depois de codificados, os dados seguem para um arranjador de blocos. O arranjador redistribui os bits transmitidos em tempo e freqüência de forma tal que erros de quebra de bits contínuos tenham pouco impacto na performance do decodificador de convolução. Um padrão desejável de arranjador depende das características do canal. Por exemplo, usando um arranjador sob AWGN (Ruído Branco Gaussiano Aditivo), o canal não aumenta a performance do sistema. Para um sistema fechado típico, o canal pode ser caracterizado como um canal seletivo de baixas freqüências. Devido à baixa mobilidade, o tempo de coerência do canal é geralmente muito maior do que a duração do pacote transmitido.

Após o arranjo, os bits são mapeados em símbolos de acordo com diferentes tipos de modulação. Uma Transformada Rápida Inversa de Fourier é aplicada nestes símbolos modulados, e os símbolos são portados em um conjunto de sub-portadoras ortogonais. Um prefixo cíclico (ou intervalo de guarda) é inserido antes de cada símbolo OFDM para prevenir interferência inter-símbolos gerada pelo canal, e preâmbulos curtos e longos são inseridos no começo do pacote, que agora está pronto pra transmissão.

2.2 VITP

VITP, Vehicular Information Transfer Protocol, é um protocolo de aplicação que especifica a sintaxe e semântica de mensagens de consultas sensíveis a local entre nós de VANETs. É uma proposta feita por Dikaikos et al no 2nd ACM international workshop on VANETs.

Entende-se por “sensível a local” a possibilidade de fornecer explicitamente a localização da demanda. No escopo de veículos, que têm movimentação limitada às malhas rodoviárias, pode-se assumir que estas são o domínio geográfico a ter sensibilidade estudada.

Um cliente VITP instalado em computadores embarcados em carros modernos seria responsável por gerenciar o funcionamento do protocolo.

Um esquema de codificação de localidades organizaria e representaria simbolicamente segmentos rodoviários. Este esquema possibilitaria as consultas sensíveis a local, e pelo suporte de outros protocolos geográficos, que fazem uso de serviços onboard para transformar as representações simbólicas em coordenadas GPS.

Propõe-se características no protocolo que permitam otimizações de performance (caching de mensagens, redução de tráfego VITP), assegurar qualidade para resultados VITP e a proteção da privacidade dos motoristas.

Diferentemente dos sistemas de monitoração atuais, baseados em disseminação contínua de condições de tráfego via VANET, VITP propõe recuperação de tráfego em empuxe (pull-based), acionado por demanda de consultas sensíveis a local feitas por veículos munidos de VITP. O protocolo se propõe ainda a propagação de mensagens por empurro (push-based), mecanismo de disseminar vários alertas que carregam informação sobre emergências e outras ocorrências nas condições normais de tráfego.

Como a centralização de servidores de dados em redes móveis, em especial veiculares, é inviável – custo e escalabilidade – o VITP não assume nenhuma infra-estrutura além de veículos e equipamentos de acostamento. Assim, o servidor que fornece respostas a consultas VITP é uma coleção dinâmica de clientes VITP, que ora constituem um veículo que se locomove dentro da área de localização do alvo da consulta, ora é um veículo capaz de contribuir com o resultado da consulta a partir de informações armazenadas na memória local dos seus dispositivos embarcados. Essa coleção de veículos se estabelece de forma ad-hoc, e depende da VANET constituída na região entre a consulta e seu resultado. À alocação dinâmica de usuários de VITP que estão na localização-alvo de uma consulta VITP e influenciam no diagnóstico desta, chama-se Virtual Ad-Hoc Server, VAHS. Note que esta coleção de clientes VITP constituirá uma estrutura de melhor-esforço. Ou seja, não fornecerá garantias da recuperação de mensagens perdidas. Ainda, um cliente VITP que se junte ao VAHS não tem informações sobre outros membros do grupo; Um veículo pode adentrar um VAHS, participar da computação de um diagnóstico e abandonar o grupo antes da complementação da resolução da consulta. Por sua vez, o VAHS também não mantém conhecimento explícito de seus membros. É identificado tão somente por uma consulta e a localização-alvo, e não pelos clientes VITP que dele participam.

Transação VITP

Figura 2. Transação VITP (Adaptado de [6])

A figura acima mostra uma transação VITP. Ela é iniciada pelo veículo A, que está no segmento rodoviário S e pede informação sobre a velocidade média de pelo menos quatro veículos dentro do segmento L, para estimativa de condições de tráfego lento em L. Para tal, o veículo A envia um pedido Q com sua assinatura. Assume-se que S e L estão  conectadas por uma VANET.

A transação consiste, assim, de quatro fases:

1.      Envio da consulta – Q é transportada pela VANET até a localização-alvo L. Q passa por nós intermediários da VANET, as quais empurram a mensagem até seu destino usando roteamento geográfico. Os nós intermediários não precisam ser um cliente VITP: Apenas aqueles que processarão o diagnóstico precisam sê-lo. Os intermediários apenas encaminham a mensagem até L.

2.      Computação VAHS – É a fase que se inicia quando Q chega a um cliente B que está na região L e deseja participar de um VAHS para resolver Q. Nesta fase, a consulta VITP é roteada entre os clientes VITP do VAHS. Estes modificam a consulta para indicar que ela é parte de uma computação VAHS (esta modificação acontece apenas quando Q está no primeiro cliente que adentra o VAHS) e multiplexar resultados parciais da consulta. Por exemplo, quando B recebe Q, resolve-a, extrai a informação pedida de seu sistema de diagnóstico, reescreve a consulta para armazenar nela o resultado parcial e indicar que a consulta é agora parte de uma computação VAHS. A seguir, passa a mensagem adiante. A semântica da consulta indicará como a rede tratará a consulta reescrita (se enviará unicast ou multicast a seus vizinhos). A consulta é repassada entre clientes do VAHS até que alguma condição de retorno seja satisfeita. O cliente VAHS que detectar uma dessas condições cria uma resposta VITP e a encaminha até a região-fonte S, através da VANET.

3.      Envio de resposta – Inicia-se quando a resposta VITP chega a S. A rede envia a resposta em broadcast aos nós de S, para que possa ser recebida pelo nó A. Quando é o caso em que o veículo consultor já deixou a área inicial onde se encontrava, o VAHS pode especificar uma região estendida na qual a resposta deve ser enviada por broadcast. 

Condições de retorno

Um detalhe importante da fase de computação VAHS é especificar quando se dão as condições de retorno que engatilharão a fase de envio da resposta.

No caso da figura, por exemplo, supõe-se que A procurava um posto de gasolina em L. Quando o pedido chega ao posto de gasolina G, o cliente modifica o pedido para fase de computação, resolve a consulta, detectando que há ao menos um posto de gasolina em G, e decide que pode resolver a consulta e que a condição de retorno está, portanto, satisfeita. Assim, uma mensagem de resposta VITP é criada com as coordenadas e preços de G, e enviada por broadcast a S.

Por outro lado, se A procura por preços de mais de um posto em L, o cliente em G começará a fase de computação VAHS, reescreverá a consulta e tentará passá-la adiante, em busca de outros postos: Ainda não foi satisfeita uma condição de retorno. Caso não haja outros postos de gasolina em G, nem sequer será possível satisfazer uma condição, e A não receberá nenhuma resposta. Para lidar com estes casos, VITP suporta uma condição de retorno alternativa, que é restringida pelo tempo em que uma infra-estrutura pode passar fazendo determinada computação VAHS.

2.3 PAVAN

PAVAN é um protocolo de monitoramento de disponibilidade de conteúdos de mídia, projetado para entretenimento intraveicular, em dispositivos C2P2 (Car-to-Car / Peer-to-Peer), sistemas de entretenimento que complementam as redes multimídia cabeadas existentes nos veículos. É uma proposta de Ghandeharizade et al, em artigo submetido ao 1st ACM international workshop on VANETs, 2004.

 Dispositivos C2P2 podem formar uma rede ad-hoc para troca de áudio e vídeo, para aplicações como vídeo sob demanda. Um sistema C2P2 pode atuar sob três papéis, simultaneamente: Pode exibir um título (de conteúdo de mídia); pode fazer streaming de um clipe armazenado localmente para outro dispositivo C2P2; por fim, pode rotear dados entre dispositivos C2P2.

A precisão do PAVAN está relacionada às entradas fornecidas. Três informações essenciais podem ser fornecidas:

·        Tabela de replicação de títulos - Baseada em dados de entrada regionais e globais, com identificação e nível de replicação dos títulos, seria composta de I linhas, uma para cada título

·        Tabela de mobilidade regional – Células (nós) agrupados podem formar um mapa regional (matriz). Uma estação base (de acostamento) monitora os dispositivos C2P2 em sua célula e utiliza as informações para construir uma tabela de mobilidade intercelular Markoviana. O modelo de mobilidade assume que, em cada instante de tempo discretizado, um C2P2 pode se locomover para um de seus oito vizinhos ou permanecer no mesmo ponto.

·        Tabela look-ahead regional – É criada para mostrar disponibilidade dos títulos. A tabela tem R entradas, cada uma com I + log ( C ) bits de informação, onde C é o número máximo de C2P2s em uma célula.

Pode-se ainda fornecer o atraso máximo aceito por um cliente.

Em sua forma mais simples, o PAVAN pode utilizar apenas a tabela de replicação global para produzir a saída para o usuário, composta da lista de títulos. Com base nesta tabela e em um limiar x, o protocolo decide que títulos estão disponíveis para um cliente. Se o grau de replicação de um clipe i for maior que x, o clipe estará disponível, e indisponível caso contrário. O valor x é um percentual.

É possível refinar buscas com modelos de mobilidade fornecidos ao PAVAN, capturando as rotas de locomoção dos dispositivos C2P2. O modelo de mobilidade usado é probabilístico e Markoviano. Cada célula do mapa constitui um estado. Uma transição entre dois estados é independente do histórico prévio de um C2P2 no estado inicial da transição. A agregação de transições de cada célula (estado) para todos os outros estados dá a matriz de probabilidade de transições Q = [q_ij], onde cada termo é a probabilidade da transição do estado i para o estado j. Usando cadeias de Markov torna-se possível estimar a distribuição de probabilidades dos diferentes estados.

Assim, o modelo de mobilidades passado ao PAVAN é ora de prognóstico, quando a matriz Q é usado em cada passo, ora é estado variável, quando apenas as probabilidades de equilíbrio, calculadas resolvendo Π = Π * Q (onde Π é o vetor que representa as probabilidades de estar em cada estado), são usadas.

Os dados de resposta do PAVAN ao usuário são uma lista de títulos mostrada em um menu que exibe títulos que ficarão disponíveis, bem como o tempo estimado para que ocorra a disponibilidade (tempo de latência).