¿Qué es Retransmisión, ARQ y HARQ?

Escrito por leopedrini viernes, 22 de junio de 2012 17:12:00 Categories: Curso
Valorar Este Contenido 2 Votos.

Es muy importante utilizar soluciones que mejoran la eficiencia del modelo adoptado en cualquier sistema de comunicación de datos. Si la transmisión es 'Wireless', esta necesidad es aún mayor.

En este escenario tenemos técnicas que básicamente comprueba, o verificar si la información enviada por el transmisor correctamente llegó en el receptor. En el siguiente ejemplo, tenemos un paquete que se envía desde el transmisor al receptor.

 

Si la información llegó correctamente (completo), el receptor está listo para recibir (y procesar) nuevos datos. Si la información llegó con algún problema, corrompido, el receptor debe solicitar que el transmisor envía el paquete nuevo (retransmisión).

 

¿Vamos a entender un poco más sobre estos conceptos cada vez más utilizado (y necesario) en los sistemas actuales?

 

 

Nota: Todas las telecomHall artículos están escritos originalmente en Portugués. A continuación se hacen traducciones en Inglés y Español. Como nuestro tiempo es escaso, sólo se producen varios errores de ortografía (que utilizar el traductor automático, y sólo entonces hacer una revisión final). Pedimos disculpas, y contamos con su comprensión de nuestro esfuerzo. Si usted quiere contribuir traduciendo / corregir una de estas lenguas, o incluso uno nuevo, por favor comuníquese con nosotros: contacto.

 

Comprobación y corrección de errores

Empezamos hablando de errores. Los errores son posibles y debido principalmente a la transmisión. De hecho, podemos incluso 'esperar' errores cuando se trata de transmisión de datos 'wireless'.

Si tenemos errores, tenemos que tomar algunas medidas. En nuestro caso, lo podemos dividir en dos pasos: comprobación de errores y corrección de errores.

Comprobación de errores es necesaria para que el receptor pueda verificar que la información que llegó es correcta o no.

Uno de los métodos de comprobación de errores más comunes es el CRC, o 'Cyclic Redundancy Check', donde se agregan bits (CRC) a un grupo de bits de información. Los bits CRC se generan en función del contenido de los bits de información. Si un error ocurre con los bits de información, los bits CRC se utilizan para verificar y ayudar a recuperar la información degradada.

Se determina el nivel de protección proporcionado por la relación: número de CRC bits por el número de bits de información. Por encima de un cierto nivel de error, se elimina el proceso. Protección de CRC se utiliza prácticamente en todas las aplicaciones de voz y datos existentes.

El siguiente diagrama muestra una demostración simplificada de cómo se utiliza el CRC.

 

Y el CRC está conectado directamente a los métodos de corrección de errores. Hay varias formas de corrección de Error de adelante (FEC - 'Forward Error Correction'), pero la idea principal es, dado un nivel de calidad en el enlace, trate de obtener el menor número de retransmisiones requeridos.

Minimizar el número de retransmisiones terminamos teniendo un resultado del flujo de datos más eficiente - principalmente - incluyendo el 'Throughput'.

De manera simplificada: el CRC le permite saber si un paquete llegó 'OK' o 'No OK'. Cada paquete que se envía tiene un CRC, o una 'firma'. Como una analogía, es como cuando enviamos una carta a alguien, y al final firmamos: 'Mi nombre completo'. Cuando la otra persona recibe esta carta (información), comprueba la firma: 'Mi error'. En este caso, le dice el mensajero: 'No sé 'Mi error', esta información tiene algunos problemas. Por favor pregunte remitente que envíe nuevamente!'.

Es decir, hacer comprobaciones CRC. Si el CRC es 'equivocado', la información es 'equivocada'. Si el CRC es 'correcto', probablemente la información es 'correcta'.

 

Retransmisiones

Retransmisiones son entonces: enviar información nuevamente (repetir) en el receptor, después de que dicha solicitud. El receptor pide que se retransmiten la información siempre que no puede descodificar el paquete, o el resultado de descodificación ha sido un error. Es decir, después de comprobar que la información llegue al receptor no es 'OK', nos deberíamos solicitar a retransmitirse.

 

Por supuesto, cuando tenemos un buen 'link' (SNR), sin interferencias o problemas que puedan afectar la integridad de los datos, no tenemos prácticamente necesidad de retransmisiones.

En la práctica, en el mundo real, esto es muy difícil que suceda, porque los enlaces pueden enfrentar las adversidades más diferentes. Así, un mecanismo eficaz para habilitar y administrar la retransmisión es esencial.

Consideramos uno mecanismo eficaz cuando permitir la comunicación de datos un enlace y satisfacer las necesidades de calidad que el servicio exige (QoS).

Voz por ejemplo, es un servicio de retransmisión no se apliquen. Si un pedazo de información se pierde y es retransmitido, la conversación se hace inteligible.

Por otro lado, servicios de datos prácticamente se basan en la retransmisión, ya que la mayoría tienen - o permite - una cierta tolerancia a retrasa – algunos más, algunos menos. Con la excepción sólo para servicios de 'Tiempo Real'.

Pero también es importante tener en cuenta que cuanto mayor sea el número de retransmisiones necesarios, bajar la tasa de transmisión de datos que es efectivamente alcanzada: Si la información tiene que ser retransmitido varias veces, tomará tiempo para el receptor obtener la información completa - final.

 

ARQ

Hasta ahora hablamos en forma genérica sobre las retransmisiones de datos, comprobación y corrección de errores. Ahora veamos algunos esquemas reales y prácticos.

La forma más sencilla (o más común) control utilizando lo que describimos anteriormente se conoce como ARQ - 'Automatic Repeat Request'.

En ARQ, cuando tenemos un paquete 'malo', el sistema simplemente descarta y pide una retransmisión (del mismo paquete). Y para ello, se envía un mensaje de retroalimentación al emisor.

 

Estos son mensajes que el receptor utiliza para informar si la transmisión fue correcta o no: 'ACKnowledgement' (ACK) y 'Non-ACKnowledgement' (NACK). Estos mensajes se transmiten desde el receptor al transmisor y respectivamente informa una buena (ACK) o mala (NACK) recepción de los paquetes anteriores.

Si en la retransmisión nueva el paquete llega con errores, el sistema pide una nueva retransmisión (aún para este mismo paquete). Es decir, envía mensaje de otro 'NACK'.

 

Se descartan los paquetes de datos que no son decodificados correctamente. Los paquetes de datos o retransmisiones son descodificadas por separado. Es decir, cada vez que un paquete que llega es malo, se descarta y se solicita que este mismo paquete se reenvía.

Pero veo que si no hubiera ningún retransmisiones, el rendimiento del flujo de datos sería mucho mejor. En el ejemplo siguiente, en comparación con la anterior, transmitimos información más - 3 veces en el mismo intervalo de tiempo.

 

Lamentablemente no tenemos mucho que hacer sobre las condiciones del enlace. O mejor, somos capaces de mejorar el rendimiento de enlaces, por ejemplo con la optimización de los parámetros de configuración, pero siempre estaremos sujetos a condiciones adversas del mismo. En este caso, nuestra única salida es tratar de minimizar las retransmisiones.

Y que es donde surgen otras técnicas o más 'mejoradas' esquemas para la retransmisión. La principal es HARQ.

 

Hybrid ARQ (HARQ)

El HARQ es el uso de ARQ convencional junto con una técnica de corrección de errores llamada 'Soft Combining', que ya no descarta los datos malos recibidos (con error).

Con 'Soft Combining' los paquetes de datos que no son decodificados correctamente no se descartan ya. La señal recibida se almacena en un 'buffer' y se combinará con la próxima retransmisión.

Es decir, dos o más paquetes recibidos, cada uno con SNR insuficiente para permitir la decodificación individuales puede combinarse de tal manera que puede ser decodificada la señal total!

Este procedimiento explica en la siguiente imagen. El transmisor envía un paquete [1]. El paquete [1] llega y es 'OK'. Si el paquete [1] es 'OK' el receptor envía un 'ACK'.

 

La transmisión continúa y se envía un paquete [2]. Llega el paquete [2], pero consideremos ahora que llega con errores. Si el paquete [2] llega con errores, el receptor envía un 'NACK'.

 

Sólo ahora este paquete [2] (malo) no se decarta, como se hace en ARQ convencional. Ahora se almacena en un 'buffer'.

 

Continuando, el transmisor envía otro paquete [2.1] que también (consideremos) llega con errores.

 

Tenemos entonces en un búfer: paquete malo [2] y otro paquete [2.1], que también es malo.

¿Agregando (combinar) estos dos paquetes ([2] + [2.1]) tenemos la información completa?

Sí. Así que enviamos un 'ACK'.

 

Pero si la combinación de estos dos paquetes todavía no nos dan la información completa, el proceso debe continuar - y se envía otro 'NACK'.

 

Y allí tenemos otra retransmisión. Ahora el transmisor envía un tercer paquete [2.2].

Consideremos que ahora es 'OK', y el receptor envía un 'ACK'.

 

Aquí podemos ver lo siguiente: junto con el paquete recibido [2.2], el receptor también tiene paquetes [2] y [2.1], que no han decartado y se almacenan en el 'buffer'.

En nuestro ejemplo, vemos que el paquete llegó 2 veces 'equivocados'. Y ¿cuál es el límite de estas retransmisiones? Hasta 4. IE, podemos tener hasta 4 retransmisión en cada proceso. Este es el número máximo soportado por 'buffer'.

 

Diferentes esquemas HARQ

Volviendo un poco en el caso de ARQ convencional, cada vez que enviamos un paquete y llega con problemas, se descarta.

Tomando el ejemplo anterior, cuando enviamos el paquete [2], y llega con errores, se descarta. Y este mismo paquete [2] se envía nuevamente.

Lo que pasa es que ya no tenemos el concepto de 'versión de paquete' - [2.1], [2.2], etc. No tenemos la versión de 'redundancia', o la ganancia que obtenemos en el procesamiento de HARQ.

Para entender esto, necesitamos saber que la información se divide como sigue:

[Información + redundancia + redundancia]

Cuando transmitimos el paquete [2] estamos transmitiendo esto:

[Información + redundancia + redundancia]

Cuando retransmitir el mismo paquete [2] estamos retransmiting una vez más:

[Información + redundancia + redundancia]

 

Pero cuando usamos HARQ y retransmitir paquetes [2.1] o [2.2], tenemos la posibilidad de:

  • O retransmitir la misma información nuevamente;
  • O retransmitir sólo la redundancia.

Y luego, si nos retransmitir menos información (sólo redundancia), gastamos menos energía, y que irá mucho más rápido. Con esto tenemos una ganancia!

Es decir, trabajamos con diferentes 'versiones de redundancia', que nos permite tener una ganancia en la retransmisión. Esto se llama 'Redundancia Version', o qué versión de redundancia.

La versión de redundancia, o esquema de HARQ con 'Soft Combining' puede ser 'Chase Combination' o 'Incremental Redundancy'.

 

 

HARQ Chase Combination

Chase Combination’: cuando combinamos la misma información (la retransmisión es una copia idéntica del paquete original).

Transmitimos una información, que llegó mal, y tenemos que hacer una retransmisión. Nos retransmitir la misma información - y allí no tenemos mucha ganancia.

 

 

HARQ Incremental Redundancy

Incremental Redundancy’: donde retransmiten sólo la parte no transmitida antes. Así nos retransmitir menos información. Menos información significa menos bits, menos energía. Y esto da una ganancia!

Bits de redundancia se retransmiten gradualmente al receptor, hasta que se recibe un ACK.

Con esto, nos adaptamos a los cambios en la condición del enlace. La primera retransmisión puede, por ejemplo, contienen o no bits de redundancia. Si es necesario, un pequeño número de estos bits se reenvía. Y así sucesivamente.

 

Acabado para hoy: ¿Cuáles son los 2 pasos de HARQ? ¿Por qué me da una ganancia?

  • Primero porque desde paquetes mal 1 y 2 podemos lograr una correcta, desde entonces no descartamos paquetes erróneos.
  • En segundo lugar porque podemos - también en retransmisión - enviar menos información y optimizar el proceso.

El uso de HARQ con 'Soft Combining' aumenta el valor efectivo de Eb/Io recibido para cada retransmisión y por lo tanto, también aumenta la probabilidad decodificación correctas de retransmisiones, en comparación con los convencional ARQ.

Enviamos un paquete, y llega con errores: mantenemos este paquete. Recibir la retransmisión y luego agregar o combinar ambos.

 

Procesos HARQ (estudio de caso)

Lo que hemos visto hasta ahora aclara los conceptos involucrados. En la práctica, en retransmisiones, este tipo de protocolo se denomina 'Stop And Wait' (hay otros tipos de protocolos similares).

¿Cuál sería: enviar la información y detener. Esperar la respuesta a enviar otra información. Enviar, espere respuesta. Enviar, espere respuesta...

 

¡No! No así en la práctica. En la práctica, trabajamos con un número de 'procesos', que puede variar por ejemplo de 4, 6 u 8. La siguiente imagen ilustra más claramente.

 

Otros tipos de HARQ

Nuevos planes se están desarrollando constantemente y usa, como el tipo III HARQ, que utiliza paquetes 'self-decodable'.

Pero entrar en estas variaciones, terminología y consideraciones, no es el razón de nuestro tutorial, que fue simplemente introducir el concepto de Retransmisión, ARQ y HARQ.

Basado en los conceptos clave que se ilustra aquí hoy, puede ampliar sus estudios como desea, sin embargo, creemos que lo más importante se logró – entender cómo funciona y cuáles son los conceptos citados.

 

Applet de JAVA

A continuación, puede ver cómo funcionan algunos esquemas de retransmisión. Hay varios Applets disponibles, de las muchas posibilidades (ARQ, HARQ, con 'Sliding Windows', selectivo, etc.).

El siguiente es un enlace a un Applet de JAVA que simula 'Selective Repeat Protocol transmission'.

 

 

Conclusión

Este fue otro tutorial sobre cuestiones importantes para aquellos que trabajan con la informática y telecomunicaciones: transmisión de datos y técnicas de retransmisión, ARQ y HARQ.

ARQ se utiliza para aplicaciones que permiten un cierto retraso, como navegar por la Web y Streaming Audio y video. Se utiliza ampliamente en los sistemas de comunicación WiFi y Wimax. Sin embargo, no puede utilizarse en la transmisión de voz, como por ejemplo en GSM.

HARQ se utiliza por ejemplo en HSPA y LTE y por lo tanto, debe ser un concepto bien entendido para quienes trabajan o quieren trabajar con estas tecnologías.

Esperamos que haya gustado. Y hasta nuestro próximo tutorial.