O que é Retransmissão, ARQ e HARQ?

Postado por leopedrini sexta-feira, 22 de junho de 2012 09:27:00 Categories: Curso
Rate this Content 3 Votes

Em qualquer sistema de comunicação de dados, é de grande importância a utilização de soluções que melhorem a eficiência do modelo adotado. Se o meio de transmissão for Wireless, essa necessidade é ainda maior.

Nesse cenário temos técnicas que basicamente verificam, ou conferem se a informação enviada pelo transmissor chegou corretamente ao receptor. No exemplo a seguir, temos um pacote sendo enviado do Transmissor ao Receptor.

 

Se a informação chegou corretamente (completa), o receptor está pronto para receber (e processar) novos dados. Se a informação chegou com algum problema, corrompida, o receptor deve solicitar que a mesma seja enviada novamente pelo transmissor (retransmissão).

 

Vamos entender um pouco mais sobre esses conceitos cada vez mais utilizados (e necessários) nos sistemas atuais?

 

 

 

Verificação e Correção de Erros

Começamos falando de erros. Erros são possíveis, e principalmente ocasionados no meio de transmissão. Na verdade, podemos até já esperar pelos mesmos quando falamos de transmissão de dados Wireless.

Se temos erros, precisamos tomar alguma ação. No nosso caso, podemos dividir isso em duas etapas: a Verificação de Erros e a Correção de Erros.

A Verificação de Erros é necessária para permitir que o receptor verifique se a informação que chegou para ele está correta ou não.

Um dos métodos mais comuns de verificação de erros é o CRC, ou ‘Cyclic Redundancy Check’, onde bits (CRC) são adicionados a um grupo de bits de informação. Os bits CRC são gerados com base no conteúdo dos bits de informação. Se um erro ocorre com os bits de informação, os bits de CRC são usados para verificar e ajudar recuperar a informação degradada.

O nível de proteção fornecido é determinado pela razão: número de bits CRC pelo número de bits de Informação. Acima de um certo nível de erro, o processo é eliminado. A proteção CRC é usada praticamente em todas as aplicações existentes de Voz e Dados.

Na figura a seguir temos uma demonstração simplificada de como o CRC é usado.

 

E o CRC está diretamente ligado aos métodos de Correção de Erro. Existem diversas formas de correção direta de erro, mas a idéia principal é, dentro dos nível de qualidade do enlace, tentar obter o menor número de retransmissões necessárias.

Minimizando o número de retransmissões acabamos tendo um resultado mais eficiente do fluxo de dados, incluindo principalmente o ‘Throughput’.

De forma simplificada: o CRC permite saber se um pacote chegou certo ou errado. Todo pacote que é enviado tem um CRC, ou uma 'Assinatura'. Fazendo uma analogia, é como quando enviamos uma carta a alguém, e no final assinamos: 'Meu Nome Completo'. Quando a outra pessoa recebe essa carta (Informação), verifica a assinatura: 'Meu Errado'. Nesse caso, ela já informa ao ao mensageiro: 'Eu não conheço ‘Meu Errado’, esta informação está com problemas. Por favor, peça para enviar novamente!’.

Ou seja, faço verificações no CRC. Se o CRC estiver errado, a informação está errada. Se o CRC estiver correto, possivelmente a informação está correta.

 

Retransmissões

Retransmissões são então o reenvio (repetição) de uma informação para o receptor, após ele fazer essa solicitação. O Receptor solicita que a informação seja reenviada sempre que não conseguir decodificar o pacote, ou o resultado da decodificação tenha sido um erro. Ou seja, após verificar que a informação que chegou ao receptor não está OK, devemos solicitar que a mesma seja retransmitida.

 

Naturalmente, quando temos um bom enlace (SNR), sem interferências ou problemas que possam afetar a integridade dos dados, praticamente não temos necessidades de retransmissões.

Na prática, no mundo real, isso é muito difícil de ocorrer, pois os enlaces estão sujeitos às mais diferentes adversidades. Assim, um mecanismo eficiente para permitir e gerenciar as retransmissões é essencial.

Consideramos tal mecanismo como eficiente quando o mesmo permita a comunicação no enlace atendendo aos requisitos de qualidade que o serviço demanda (QoS).

A Voz por exemplo, é um serviço onde a retransmissão de dados não se aplica. Se uma parte da informação se perder, e for retransmitida, a conversa torna-se inteligível.

Por outro lado, Serviços de Dados praticamente contam com a retransmissão, já que a maioria possui ou permite uma certa tolerância a atrasos – uns mais, outros menos. Com exceção apenas de serviços ‘Real Time’.

Mas também é importante levar em conta que quanto maior o número de retransmissões necessárias, menor será a taxa de transmissão dos dados efetivamente alcançada: Se a informação tiver que ser retransmitida várias vezes, demorará muito para que o receptor obtenha a informação final completa.

 

ARQ

Falamos até agora de forma genérica sobre retransmissões de dados, verificação e correção erros. Vamos agora ver os principais esquemas reais e práticos existentes.

A forma mais simples (ou mais comum) de controle usando o descrito acima é o conhecido ARQ, ou ‘Automatic Repeat Request’.

No ARQ convencional, quando temos um pacote errado, o sistema simplesmente descarta, e pede uma retransmissão (desse mesmo pacote). E para isso, ele envia uma mensagem de feedback para o transmissor.

 

Essas mensagens de feedback do receptor são as mensagens para informar se a transmissão teve sucesso ou não: 'ACKnowledgement' (ACK) e 'Non-ACKnowledgement' (NACK). Essas mensagens são transmitidas do receptor para o transmissor, e indicam respectivamente uma boa (ACK) ou má (NACK) recepção dos pacotes anteriores.

Se nessa outra retransmissão o pacote ainda continua chegando errado, o sistema solicita uma nova retransmissão (ainda desse mesmo pacote). Ou seja, envia mais uma mensagem de NACK.

 

Os pacotes de dados que não são decodificados corretamente são descartados. Os pacotes de dados ou retransmissões são decodificados separadamente. Ou seja, toda vez que chega um pacote errado, ele é descartado, e é solicitado que esse mesmo pacote seja reenviado.

Mas perceba que se não houvesse retransmissões, o desempenho do fluxo de dados seria muito melhor. No exemplo abaixo, em comparação com o anterior, transmitimos 3 vezes mais informação, no mesmo intervalo de tempo.

 

Infelizmente não temos muito a fazer sobre as condições do enlace. Ou melhor, até temos condições de melhorar os enlaces, por exemplo com Otimização de Parâmetros de Configuração, mas sempre estaremos sujeitos à enfrentar condições adversas. Nesse caso, a nossa única saída é tentar minimizar as retransmissões.

E é aí que surgem outras técnicas ou esquemas mais aprimorados de retransmissão. A principal delas é o HARQ.

 

Hybrid ARQ (HARQ)

O HARQ é a utilização do ARQ convencional junto com uma técnica de correção de erros chamada ‘Soft Combining’, que já não descarta os dados recebidos com erro.

Com o ‘Soft Combining’ os pacotes de dados que não são decodificados corretamente NÃO são descartados. O sinal recebido é armazenado num ‘buffer’, e combinado com a sua retransmissão.

Ou seja, dois ou mais pacotes recebidos, cada um com a relação SNR insuficiente para permitir a decodificação individual podem ser combinados de tal forma que o sinal total possa ser decodificado!

A figura a seguir demonstra esse procedimento. O transmissor envia um pacote [1]. O pacote [1] chega, e está OK. Se o pacote [1] está Ok o receptor envia um ACK.

 

A transmissão continua, e é enviado um pacote [2]. O pacote [2] chega, mas vamos considerar que o mesmo chega errado. Se o pacote [2] chega errado, o receptor envia um NACK.

 

Só que agora esse pacote [2] (errado) não é jogado fora, como é feito no ARQ convencional. Agora ele é armazenado em um ‘buffer’.

 

Continuando, o transmissor reenvia um pacote [2.1.] Que também (vamos considerar) chega errado.

 

Temos então no buffer um pacote [2] errado, e um outro pacote [2.1] que também está errado.

Somando (combinando) esses dois pacotes ([2] + [2.1]) temos a informação completa?

Sim. Então enviamos um ACK.

 

Mas se a combinação desses dois pacotes ainda não der a informação completa, o processo deve continuar - e é enviado mais um NACK.

 

E aí vamos ter outra retransmissão. Agora o transmissor envia um terceiro pacote [2.2].

Vamos considerar que agora chegou OK, e o receptor envia um ACK.

 

Aqui podemos perceber o seguinte: junto com o pacote [2.2] recebido, o receptor tem também os pacotes [2] e [2.1], que não foram descartados e estão no buffer.

No nosso exemplo, veja que o pacote chegou errado 2 vezes. E qual é o limite dessas retransmissões? Até 4. Ou seja, posso ter até 4 retransmissões em cada processo. Esse é o número máximo suportado pelo ‘buffer’.

 

Diferentes Esquemas HARQ

Voltando um pouco ao caso do ARQ convencional, sempre que enviamos um pacote e ele chega errado, o mesmo é descartado.

Aproveitando o exemplo acima, quando enviamos o pacote [2], e ele chega errado, ele é descartado. E esse mesmo pacote [2] é enviado novamente.

O que acontece é que não temos mais o conceito de 'versão' de pacotes [2.1], [2.2], etc. Não temos a ‘versão de redundância’, ou o ganho que obtemos no processamento HARQ.

Para entender isso, precisamos saber que a informação é dividida da seguinte forma:

[Informação + Redundância + Redundância]

Quando transmitimos o pacote [2] estamos transmitindo isso:

[Informação + Redundância + Redundância]

Quando re transmitimos o mesmo pacote [2] estamos retransmitimos isso de novo:

[Informação + Redundância + Redundância]

 

Mas quando usamos o HARQ, e  retransmitimos o pacote [2.1] ou [2.2], temos a possibilidade de:

  • Ou retransmitir essa mesma informação de novo;
  • Ou retransmitir apenas a redundância.

E então, se retransmitimos menos informação (apenas a redundância), gastamos menos energia, e que ainda vai muito mais rápido. Com isso temos um ganho!

Ou seja, trabalho com versões de redundância diferentes, o que nos permite ter um ganho na retransmissão. Isso se chama 'Redundancy Version', ou qual a versão de redundância.

A versão de redundância, ou esquema HARQ com soft combining pode ser 'Chase Combination' ou 'Incremental Redundancy'.

 

 

HARQ Chase Combination

Chase Combination’: quando combinamos a mesma informação (a retransmissão é uma cópia idêntica à original).

Transmitimos uma informação,  que chegou errado, e precisamos fazer uma retransmissão. Retransmitimos a mesma informação - e aí não temos tanto ganho.

 

 

HARQ Incremental Redundancy

Incremental Redundancy’: onde retransmitimos apenas a parte que deixamos de transmitir. Assim retransmitimos menos informação. Menos informação significa menos bits, menos energia. E isso gera um ganho!

Os bits de redundância são retransmitidos gradativamente para o receptor, até que seja recebido um ACK do mesmo.

Com isso, conseguimos nos adaptar às alterações na condição do enlace. A primeira retransmissão pode por exemplo nem conter bits de redundância. Caso necessário, um pequeno número desses bits é reenviado. E assim sucessivamente.

 

Finalizando por hoje: Quais são os 2 passos do HARQ? Porque ele me dá um ganho?

  • Primeiro porque podemos obter a partir de 2 pacotes errados 1 pacote correto, já que nós não descartamos os pacotes errados.
  • Segundo porque podemos também na retransmissão, enviar menos informação, e com isso agilizar o processo.

O uso de HARQ com ‘Soft Combining’ aumenta o valor efetivo de Eb/Io recebido para cada retransmissão, e por consequência, aumenta também a probabilidade de decodificação correta de retransmissões, em comparação ao ARQ convencional.

Enviamos um pacote, e ele chega errado: mantemos esse pacote. Recebemos a retransmissão e depois somamos ou combinamos os dois.

 

Processos HARQ (Caso Prático)

O que vimos até agora nos esclarece os conceitos envolvidos. Na prática, na retransmissão, esse tipo de protocolo, esse tipo de transmissão que vimos é chamado de 'Stop And Wait' (existem outros tipos de protocolos similares).

O que seria enviar a informação e parar. Esperar a resposta para mandar outra informação. Enviar, esperar a resposta. Enviar, esperar a resposta...

 

Não! Não é assim na prática. Na prática, trabalhamos com um número de ‘processos’, que podem variar por exemplo de 4, 6 ou 8. A figura a seguir ilustra isso mais claramente.

 

Outros tipos de HARQ

Constantemente novos esquemas vão sendo desenvolvidos e utilizados, como o tipo III HARQ, que utiliza pacotes auto-decodificáveis.

Mas adentrar essas variações, terminologias e considerações específicas foge do escopo do nosso tutorial de hoje, que foi simplesmente apresentar o conceito de Retransmissão, ARQ e HARQ.

Com base nos conceitos principais exemplificados aqui hoje, você pode estender os seus estudos o quanto mais desejar, porém acreditamos que o mais importante foi alcançado – entender como funciona e para que servem todos os conceitos citados.

 

Applet JAVA

A seguir, você pode ver como alguns dos esquemas de retransmissão funcionam. Existem várias Applets disponíveis, para as inúmeras possibilidades (ARQ, HARQ, Com Sliding Windos, Seletivo, etc).

Segue exemplo de uma Applet JAVA que simula uma transmissão do protocolo ‘Selective Repeat’.

http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/SR/index.html

 

 

Conclusão

Este foi mais um tutorial sobre assuntos importantes para quem trabalha com Telecom e TI: a transmissão de dados e as técnicas de retransmissão, ARQ e HARQ.

O ARQ é utilizado para aplicações que permitam um certo atraso, como Web Browsing e até Streaming de Audio/Vídeo. É usado largamente em sistemas de comunicação Wimax e WiFi. Entretanto, não pode ser usado em transmissão de Voz, como por exemplo no GSM.

O HARQ por exemplo é utilizado em HSPA e LTE, e portanto deve ser um conceito bem entendido para quem trabalha ou deseja trabalhar com essas tecnologias.

Esperamos que tenham gostado. E até o nosso próximo tutorial.