Estudio y evaluación de técnicas FEC para la recuperación frente a

MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
1
Estudio y evaluación de técnicas FEC para la
recuperación frente a errores
Rafael Ubal Tena
Resumen—En este trabajo se da una breve descripción de las
principales características de los mecanismos de corrección de
errores FEC (Forward Error Correction) y del protocolo de
transmisión de datos multimedia RTP (Real-time Transport
Protocol). Estos dos ámbitos se tratan por separado y en conjunto,
discutiendo la aplicación de técnicas FEC sobre RTP. Además, se
describe la implementación de un simulador que modela una red
imperfecta (con errores de transmisión) sobre la que se evalúa la
eficacia de las técnicas de corrección de errores, utilizando
diferentes variantes de FEC y múltiples tasas de error.
I. INTRODUCCIÓN
L
AS redes actuales que forman Internet son en su mayoría
redes IP. A pesar de que este protocolo de red ha gozado
de actualizaciones, la versión 4 del mismo es la que se emplea
más comúnmente, en la mayoría de casos por compatibilidad
hacia atrás con recursos hardware y software.
Uno de los principales problemas de IPv4 en el ámbito de la
transmisión de datos multimedia es su carencia de garantías en
cuanto a calidad de servicio. Concretamente, existe un riesgo
continuo de pérdida de paquetes, ocasionado principalmente
por la congestión de nodos enrutadores o por errores en la
transmisión debidos a fenómenos físicos. Además, este tipo de
redes no fueron diseñadas en sus orígenes como redes capaces
de entregar paquetes en tiempo real, lo cual es asimismo un
requisito de las transmisiones multimedia.
Las limitaciones de los medios físicos y de los mecanismos
fijados durante la juventud de Internet se han paliado con el
tiempo mediante el diseño de protocolos de más alto nivel que
detecten y actúen frente a eventos de pérdida, desordenación o
corrupción de datos, siendo el protocolo de transporte TCP el
más ampliamente utilizado. Sin embargo, el requisito del
tiempo real impide la utilización de protocolos altamente
interactivos, como TCP, cuya sobrecarga haría inviable una
recepción de paquetes sobre los que se imponga una cota
superior en cuanto al tiempo de transmisión.
Por esta razón surge el protocolo RTP (con sus hermanos
RTCP y RTSP), comentados en la siguiente sección. Ya que
no es posible exigir a protocolos inferiores una cierta calidad
de servicio, la filosofía de RTP consiste en monitorizar de
forma continua las características de las redes sobre las que se
trabaja y variar los parámetros de transmisión adaptándose
dinámicamente a la situación del medio y dispositivos de
transmisión.
El protocolo TCP soluciona las consecuencias de la pérdida
de paquetes a través de retransmisiones de los mismos, lo cual
requiere un mecanismo de notificación de recepción: cuando el
emisor no recibe reconocimientos en un cierto tiempo, reenvía
los paquetes implicados. De nuevo, esta característica resulta
inviable en una transmisión de datos multimedia en tiempo
real, ya que el retardo adicional de una retransmisión
excedería muy probablemente las restricciones temporales
preestablecidas. En este sentido, las técnicas de inclusión de
redundancia son las que sustituyen a las retransmisiones. Las
técnicas FEC, descritas en la siguiente sección, son las más
ampliamente utilizadas para este propósito, hasta el punto de
que los estándares RFC incorporan la utilización de FEC sobre
RTP.
En cuanto a los medios de transmisión hacia los que está
enfocado RTP, se puede afirmar que pueden ser de naturaleza
variopinta: desde redes de área local con una tasa de fallos,
retardos y jitter muy bajos, hasta redes de área amplia
proclives a ocasionar pérdidas de paquetes y alta variabilidad
en su transmisión. Por ello, tanto el protocolo RTP como las
técnicas de tolerancia a fallos aplicadas sobre él (FEC) deben
contemplar este hecho para actuar con eficacia.
Todas estas circunstancias motivan el desarrollo del
presente trabajo, en el que se propone una pequeña
herramienta para simular una red con una tasa de fallos
parametrizable, sobre la cual se transmite un flujo de datos
RTSP utilizando tolerancia a fallos en forma de paquetes FEC
con un código de redundancia variable. Mediante esta
herramienta, se pretende obtener el código FEC idóneo, o lo
que es lo mismo, la cantidad de información redundante
apropiada, para redes de diferente naturaleza y, por tanto, con
diferentes tasas de error.
El resto de este trabajo sigue la siguiente estructura. La
sección II describe brevemente los protocolos FEC y RTP. La
sección III presenta la herramienta construida y la metodología
de simulación. Por último, la sección IV incluye unas notas
concluyentes a este trabajo.
II. ESTÁNDARES Y PROTOCOLOS
A. Forward Error Correction (FEC)
Forward Error Correction es un sistema de corrección de
errores para transmisiones de datos en el que el emisor añade
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
datos redundantes que permiten al receptor detectar y corregir
errores sin la necesidad de solicitar de nuevo los datos. La
principal ventaja de este mecanismo reside en la elusión de
retransmisiones, a costa de incrementar el volumen de datos
enviados (y por tanto el ancho de banda necesario).
Las técnicas FEC son una alternativa a la corrección de
errores en medios donde la retransmisión es demasiado
costosa, como por ejemplo aplicaciones en tiempo real, o
imposible, como soportes físicos de almacenamiento (CD,
memorias FLASH, etc).
El volumen de información redundante y su disposición
determina el código FEC, que puede variar según las
condiciones del medio de transmisión. Asimismo, el código
FEC determina el número máximo de errores que se pueden
corregir.
1) Evolución de técnicas FEC
La primera técnica FEC que se publicó [1] utilizaba
codificación algebraica. En este caso, el codificador interpone
bits de paridad entre la secuencia de datos utilizando un
algoritmo algebraico determinado.
Una técnica FEC posterior fue la conocida como
codificación convolucional [2], que trabaja sobre flujos de
datos, en lugar de hacerlo sobre bloques. La principal
característica de estos códigos FEC es que la codificación de
una secuencia de bits está altamente influenciada por bits
anteriores, por lo que el algoritmo de decodificación los tiene
en cuenta para estimar la secuencia más probable de bits
correctos a la hora de recomponer la secuencia original.
Originalmente, la decodificación convolucional tenía el
inconveniente de ser espacialmente costosa, y generalmente
ocasionaba desbordamiento de buffers en implementaciones
deficientes.
Más tarde, A. Viterbi desarrolló una técnica de
decodificación convolucional [3] que supuso a partir de
entonces el estándar de decodificación FEC. Este algoritmo
compara los bits recibidos con los bits que podrían haberse
generado para cada posible transición desde estados previos
del decodificador. Basado en métricas de similitud, se escoge
la secuencia más cercana a que podría ser la original, la cual se
devuelve como flujo de bits decodificado. El algoritmo de
Viterbi, basado en programación dinámica, tiene la ventaja de
hacer un uso eficiente de la memoria utilizada, desechando
flujos de bits anteriores que tienen poca probabilidad de ser
reutilizados.
2) Turbo-Coding
En 1993, C. Berrou desarrolló la técnica FEC más potente
hasta el momento, llamada turbo-coding [4]. Con esta técnica,
los sistemas de comunicación pueden alcanzar el límite
máximo teórico de la capacidad de los canales, caracterizada
anteriormente por Shannon, y considerada inalcanzable
durante mucho tiempo.
Una de las características de tubo-coding es que el
codificador debe incluir combinaciones de, como mínimo, dos
codificadores FEC. Entre ellos se pueden encontrar tanto
2
codificadores algebraicos como convolucionales. Sin embargo,
en cualquier caso, la codificación global se procesa en
bloques, cuyo tamaño viene dictado por un codificador
intermediario (interleaver), que separa a cada uno de los
componentes.
Los bits de información son codificados por el primer
componente codificador directamente, mientras que el segundo
componente codificador opera con una versión desordenada de
ellos. Con ello producimos los bits de paridad del primer y el
segundo codificador. La señal a enviar por el canal estará
formada por los bits sistemáticos que coinciden con los de
información y los bits de paridad de ambos componentes
codificadores.
En recepción, la turbo decodificación iterativa está formada
por dos componentes decodificadores convolucionales en
paralelo que decodifican los bits recibidos por su
correspondiente componente codificador. El primer
componente decodificador produce además cierta información
no relacionada con los bits de entrada, que permite al segundo
componente decodificar los mismos bits recibidos con una tasa
de error menor. El proceso se reitera hasta que se obtiene la
tasa de error deseada, teniendo en cuenta que por cada
iteración se aumenta el grado de complejidad del turbo
decodificador convolucional.
El método de la turbo codificación ha pasado a formar parte
de estándares, como UTRA (UMTS Terrestrial Radio Access),
debido a su gran potencia de recuperación de errores en
comunicaciones.
B. Real-Time Transport Protocol (RTP)
El protocolo RTP define un formato estándar de paquetes
para transmitir audio y vídeo en Internet. Fue publicado
originalmente en el RFC 1889 y, más tarde, en el RFC 3550
[5], dejando obsoleta la primera versión. El estándar define el
uso de RTP bien con conexiones TCP en un puerto arbitrario,
o bien con conexiones UDP en puertos pares. En este último
caso, el siguiente puerto impar se utiliza para comunicaciones
de control con RTCP (RTP Control Protocol).
Inicialmente, RTP se diseñó como un protocolo multicast,
pero ha acabado utilizándose en muchas aplicaciones unicast,
principalmente en streaming de audio/vídeo (junto con el
protocolo RTSP) y videoconferencias. Las aplicaciones que
utilizan RTP son poco sensibles a la pérdida de paquetes, pero
sí lo son a los retardos de la comunicación, por lo que la
implementación de RTP sobre el protocolo de transporte UDP
es una opción más sensata que sobre TCP.
Los paquetes RTP dan información sobre el tipo de
contenido multimedia que se está transmitiendo, números de
secuencia de paquetes, marca de tiempo real que representa el
instante de presentación de los datos (time-stamping) y
monitorización de entrega.
En sí mismo, el protocolo RTP no garantiza calidad de
servicio, entrega de paquetes a tiempo u ordenación de
paquetes a la llegada. Sin embargo, el protocolo asociado
RTCP da información de la calidad de recepción, con lo que la
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
tasa de transmisión de datos puede ajustarse a los parámetros
de la red monitorizada.
A continuación se pasa a describir brevemente los
protocolos RTCP y RTSP, ambos estrechamente ligados a
RTP:
1) Real Time Control Protocol (RTCP)
El protocolo RTCP [5] está ligado a cualquier conexión
RTP, y da información sobre la utilización de la red por la que
se transmiten los datos multimedia. Los paquetes RTCP no
transportan datos en sí mismos, sino que se envían
periódicamente a todos los participantes de una sesión de
streaming multimedia, de forma que todos obtengan pistas
sobre la calidad del servicio que la red está proporcionando a
sus demandas.
RTCP recoge estadísticas de una conexión multimedia, tales
como el número de bytes enviados, paquetes perdidos, jitter
(variación del retardo), etc. Las aplicaciones de envío pueden
hacer uso de esta información ajustando la calidad de los datos
enviados, bien cambiando la resolución de las imágenes o la
tasa de bits del audio, o bien ajustando los parámetros de
compresión del codificador.
2) Real Time Streaming Protocol (RTSP)
El protocolo RTSP, publicado en el RFC 2326 [6], se utiliza
asimismo generalmente junto con RTP, y permite que los
clientes controlen el flujo de datos multimedia generado por el
3
servidor, utilizando órdenes similares al VCR (play, pause…).
También soporta el acceso basado en tiempo a los ficheros
multimedia del servidor.
Las órdenes RTSP tienen una sintaxis similar a HTTP, con
la principal diferencia de que el servidor RTSP mantiene
información de sesión. Para ello, existe un mecanismo de
asignación de identificadores de sesión, que permite cerrar y
abrir conexiones conservando información entre ellas, incluso
eludiendo el protocolo TCP. Las órdenes principales de RTSP
son las siguientes:
• DESCRIBE: Una petición de este tipo incluye una URL
(rtp://…) y obtiene como respuesta la descripción del
contenido asociado.
• SETUP: Especifica cómo se transportarán los datos que
se enviarán. Para ello, se incluye típicamente el puerto
local de recepción RTP y metainfomación RTCP. La
respuesta del servidor confirma los parámetros y añade
otros, como el puerto RTP del servidor.
• PLAY: Comienza la reproducción del medio
especificado. Esta orden puede desencadenar la
transmisión de uno o más flujos multimedia.
• PAUSE: Para temporalmente la reproducción,
reanudándola con la orden PLAY siguiente.
• RECORD: Utilizada para enviar un flujo al servidor, de
forma que éste lo almacene.
• TEARDOWN: Terminación de la sesión actual. Para todos
los flujos asociados a esta sesión y libera los datos de la
Figura 1: Captura del tráfico RTSP con Ethereal
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
sesión en el servidor.
C. FEC sobre RTP
El RFC 2733 [7] propone la aplicación de técnicas FEC
sobre el protocolo RTP. Este protocolo está destinado a
funcionar sobre cualquier tipo de redes IP, incluyendo las
redes de área amplia (WAN). Es en estas redes donde existe
un gran riesgo de pérdida de paquetes, debido principalmente
a posibles congestiones de notos intermedios. Por otra parte, la
transmisión de datos multimedia (por ejemplo, voz) tiene
restricciones temporales que no permiten solicitud de
retransmisión en caso de pérdidas.
RTP es, por tanto, un protocolo muy susceptible de
incorporar técnicas FEC, que añaden redundancia al flujo de
datos enviado, compensando así la imposibilidad de aplicar el
mecanismo de reenvíos.
La aplicación de FEC sobre RTP consiste en escoger un
conjunto de paquetes RTP y combinarlos utilizando la
operación xor. Para ello, se deben extender los datos de los
paquetes RTP originales de forma que alcancen una longitud
igual a la del paquete más largos. Las cabeceras de los
paquetes RTP se combinan de forma selectiva, aunque también
utilizando la operación xor. Este proceso queda detallado en la
sección 6 del RFC.
El estándar deja la libertad de escoger un código FEC libre
según la implementación. Se llama código a las combinaciones
específicas de paquetes RTP que se utilizan para construir la
secuencia de paquetes FEC. El código FEC puede variar
incluso dinámicamente, adaptándose a características variables
del medio de transmisión. Para la especificar qué paquetes
RTP están asociados a un paquete FEC, este último incorpora
una cabecera de 24 bits, de los cuales, el bit i indica que el
paquete RTP con número de secuencia N+i se utilizó en la
operación xor, siendo N el número de secuencia del propio
paquete FEC.
En este RFC, se propone enviar el flujo de paquetes FEC de
forma independiente respecto al flujo RTP original, con la
ventaja de que los usuarios que no implementen FEC sean
capaces de ignorar la información redundante y conservar la
original. Sin embargo, el flujo de datos original puede
reconstruirse únicamente a partir de paquetes FEC, evitando el
envío de los paquetes RTP, pero obligando al receptor a
implementar este estándar.
Las diferentes secciones del RFC 2733 enumeran la
nomenclatura utilizada a lo largo de la especificación,
describen la metodología de incorporación de redundancia,
incorporan una serie de ejemplos de códigos FEC y fijan el
formato de los paquetes FEC. Adicionalmente, las secciones 9
y 10 añaden un posible algoritmo a implementar en el receptor
(incluyendo el código en C) y dan un ejemplo de sesión RTP
en el que se aplica el protocolo especificado en sus secciones
anteriores.
III. ENTORNO EXPERIMENTAL
Para este trabajo, se ha perfilado un entorno experimental
4
que permite evaluar la eficacia de las técnicas FEC a la hora
de corregir errores sobre un flujo de datos RTSP real. Con este
objetivo, se ha seguido la siguiente metodología:
• En primer lugar, se ha capturado tráfico RTSP real.
Para ello, se ha descargado el software libre
QuickTime, reproductor de vídeo de Apple, y se ha
introducido la siguiente URL, que hace referencia a un
flujo de datos RTSP: rtsp://stsv01.st.ehu.es/MSR.mov
• A continuación, hemos descargado el software, también
libre, Ethereal, una aplicación que permite capturar,
analizar y clasificar el tráfico que atraviesa la tarjeta de
red local. Con Ethereal, seleccionamos el tráfico RTSP
entrante, correspondiente al vídeo recibido con
QuickTime, y lo volcamos en un fichero.
• Este fichero sirve como entrada a la herramienta
construida, que simula tres elementos principales: i) un
emisor de datos con capacidad de incluir redundancia
FEC, ii) una red imperfecta que introduce errores de
transmisión y iii) un receptor capaz de reconstruir los
paquetes recibidos, siempre que la información FEC lo
permita.
El objetivo de este estudio es analizar varios códigos FEC
actuando sobre datos RTSP que se transmiten sobre una red
cuya tasa de fallos puede especificarse en cada experimento.
Variando la redundancia FEC y la frecuencia con que ocurren
los errores en el medio de transmisión, mediremos el grado de
pérdida de datos en forma de bytes erróneos y paquetes
erróneos.
A continuación, se detalla este proceso y se describe la
herramienta desarrollada, así como los resultados obtenidos a
partir de ella.
A. Captura de tráfico RTSP
Para generar tráfico RTSP entrante, escogemos una URL
aleatoria, obtenida en Google, y la introducimos en
QuickTime. Por otra parte, iniciamos una captura de tráfico
con Ethereal, como se muestra en la Figura 1.
Adicionalmente, Ethereal permite filtrar el tráfico
capturado. Al encontrarnos en una máquina con más
aplicaciones abiertas que comparten tarjeta de red, e incluso
una misma aplicación generando diferentes tipos de tráfico,
debemos seleccionar únicamente el tráfico RTSP. Esta acción
se consigue introduciendo en el campo Filter la siguiente
cadena:
ip dst eq 192.168.123.100 and rtsp
De esta forma, indicamos que sólo queremos visualizar
tráfico que tenga como IP destino la de nuestra máquina, y que
además sea tráfico RTSP. El resultado de la aplicación del
filtro lo almacenamos en un nuevo fichero, de nombre
stream.cap.
Una vez disponemos del flujo de datos sobre el que
experimentar con técnicas FEC, debemos volcarlo en un
fichero cuyo formato sea analizable por nuestra aplicación.
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
Nombre
Tamaño
Descripción
(bytes)
fec
1
0 si el paquete es RTSP y 1 si
es FEC
error
1
1 si el paquete contiene error, 0
si no
seq
2
Número de secuencia del
paquete (0 para FEC)
length
2
Tamaño del paquete
feclength*
1
Número de paquetes RTSP a
partir de los que se construyó
un paquete FEC
fecseq0*
2
Número de secuencia de
fecseq1*
2
paquetes RTSP a partir de los
...
...
que se construyó un paquete
fecseqfeclength-1*
2
FEC
data
length
Datos del paquete
*Estos campos sólo se encuentran cuando fec es igual a 1.
Tabla 1: Formato de los ficheros FecRtsp
Ethereal tiene una opción descrita como Follow TCP Stream,
mostrada al pulsar con el botón derecho sobre la lista de
paquetes. Con esta opción, podemos eliminar la información
de control introducida por el nivel físico, el nivel de red y el
protocolo TCP, obteniendo un simple flujo de datos
correspondiente al flujo RTSP.
Además, el cuadro de diálogo resultante ofrece la opción de
representar el contenido de la información en diferentes
formatos, entre los cuales escogemos el de C Arrays. Con este
formato, los datos se representan en forma de vectores con la
sintaxis del lenguaje C, estando cada vector formado por los
bytes de un solo paquete. Esto resulta idóneo para nuestros
objetivos, puesto que no sólo obtenemos una representación en
texto plano de los datos analizable mediante scripts, sino que
además quedan delimitados los bytes correspondientes a
diferentes paquetes, lo cual es una información que habríamos
perdido eliminando las cabeceras TCP.
Los vectores C los almacenamos en un fichero, stream.c,
que servirá como referencia para los programas construidos.
Sin embargo, requieren una conversión al formato de fichero,
esta vez binario, que se utilizará a lo largo de los
experimentos. Este formato, así como el proceso de
conversión, se describe a continuación.
B. Formato de ficheros internos
Los ficheros manejados internamente siguen un formato
específico, denominado formato FecRtsp en lo sucesivo. Los
ficheros FecRtsp representan una secuencia de paquetes FEC o
RTSP. La siguiente tabla muestra el formato empleado, a su
vez, para cada uno de los paquetes de dicha secuencia:
Encadenando estructuras de datos con este formato, cada
uno de los programas utilizados lee ficheros, los procesa, y
5
genera otros que a su vez pueden servir como entrada de un
nuevo proceso. Concretamente, los programas desarrollados y
su forma de operar es la siguiente:
• buildstream.py: Éste es un script en Python que
transforma la salida de Ethereal, en forma de vectores
C, en un fichero FecRtsp. Se utiliza para convertir el
fichero stream.c en stream.sender.
• stream.py send: El programa stream.py, con la
opción send, lee un fichero que contenga una captura
de paquetes RTSP y añade redundancia FEC, utilizando
un código FEC determinado. Además se introducen
errores aleatoriamente, simulando el envío de paquetes
por una red. Se utiliza para convertir stream.sender en
stream.network, todos ellos en formato FecRtsp.
• stream.py recv: Con esta opción, se simula la
recepción de paquetes en el extremo opuesto de la
conexión RTSP. El receptor intenta reconstruir los
paquetes RTSP originales a partir de la información
FEC introducida. Se utiliza para convertir
stream.network en stream.recv.
• stream.py comp: Por último, esta opción permite
comparar dos archivos FecRtsp, obteniendo estadísticas
sobre el número de bytes y el número de paquetes
perdidos y no reconstruidos. Se utiliza para comparar
stream.sender con stream.recv.
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
6
Figura 2: Porcentaje de bytes perdidos
A continuación, se describen con detalle los procesos de
incorporación de redundancia, inyección de errores de
transmisión y recomposición de paquetes, todos ellos
localizados en el programa stream.py.
C. Envío del flujo RTSP (stream.py send)
La parte del script stream.py dedicada a la simulación del
envío del flujo RTSP pretende generar un fichero FecRtsp
conteniendo una serie de paquetes RTSP y FEC con una serie
de errores forzados. El código FEC y la tasa de errores de la
red vienen especificados en la línea de órdenes, durante la
llamada al script.
Los códigos FEC implementados se corresponden con
diferentes grados de redundancia. Suponiendo que los
paquetes a, b, c... son los que forman el flujo RTSP y que
f(x,y...) es la función de construcción de paquetes FEC, los
códigos implementados se pueden representar así:
• Código 0; 0% de redundancia: a b c d ...
• Código 1; 50% de redundancia: a b f(a,b) c d
f(c,d) ...
• Código 2; 75% de redundancia: a b c f(a,b,c) d
f(a,c,d) f(a,b,d) d ...
• Código 3; 100% de redundancia: a b f(a,b) c
f(b,c) d f(c,d) ...
Por otra parte, el parámetro que especifica la tasa de
inyección de errores es la inversa del tiempo medio que
transcurrirá entre un error y el siguiente. El programa genera
números aleatorios con distribución exponencial para calcular
el número de bytes íntegros antes de que ocurra un nuevo
error. Las tasas de error analizadas varían entre 10-5 y 10-2.
El script de Python se basa en la clase Packet, que modela
un paquete RTSP o FEC. Sus métodos principales son read y
write, utilizados respectivamente para leer y escribir un
paquete en un archivo FecRtsp.
El proceso a seguir en el envío se basa en leer paquetes del
archivo de origen y escribirlos en el fichero destino,
incluyendo paquetes FEC según el código especificado. Para
crear un paquete FEC a partir de dos o más paquetes RTSP, se
utiliza la función Packet.buildfec. Asimismo, para escribir
un paquete en el archivo destino, se utiliza la función
Packet.WriteWithError, una extensión de Packet.write que
inyecta errores según la tasa de error especificada. Los errores
se inyectan tanto en los paquetes RTSP como en los paquetes
FEC.
La función Packet.buildfec recibe una lista de paquetes
RTSP, y convierte el paquete actual en un paquete FEC
generado a partir de los paquetes de dicha lista. La longitud
del paquete FEC será la máxima de todos los paquetes RTSP.
Para generar los datos, se rellenan primero con 0 todos los
paquetes hasta que tengan la misma longitud, y, a
continuación, se realiza la operación xor sobre todos ellos.
Disponiendo de la lista de paquetes RTSP y del paquete FEC
resultante, cualquiera de ellos puede reconstruirse a partir del
resto, realizando el mismo proceso.
La función Packet.WriteWithError escribe un paquete en
el fichero introduciendo errores en los bytes que corresponda.
Para ello, se mantiene un contador que indica el número de
bytes restantes hasta que se produzca un error. Cada byte
íntegro que se escribe en el fichero de salida provoca una
disminución del contador. Cuando éste llega a 0, el siguiente
byte contendrá un error y el contador toma un valor aleatorio
con distribución exponencial y con la inversa de la tasa de
error como media.
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
7
Figura 3: Porcentaje de paquetes perdidos
D. Recepción del flujo RTSP (stream.py recv)
El proceso de recepción de los datos consiste en almacenar
en un buffer los diez últimos paquetes recibidos (permitiendo
códigos FEC que actúen hasta sobre diez paquetes). Cuando se
recibe un paquete RTSP o FEC erróneo, éste se descarta. En
las simulaciones, la existencia de error viene determinada por
el campo error del formato FecRtsp, aunque en la realidad,
esta condición se determinaría haciendo una comprobación del
checksum en un nivel inferior del protocolo TCP/IP.
Cuando se recibe un paquete FEC, se comprueba si hubo
algún paquete RTSP erróneo, almacenado en el buffer, que sea
posible reconstruir a partir de aquél. En tal caso, una llamada a
la función reconstruct se encarga de esta tarea. Esta función
se aplica sobre el paquete FEC recibido, y tiene como
argumentos una lista de paquetes entre los cuales se podrían
encontrar los paquetes RTSP erróneos.
E. Comparación de los flujos RTSP (stream.py comp)
La última utilidad del script creado es la de comparar los
flujos de datos generados por el emisor y los obtenidos por el
receptor tras el proceso de recomposición con técnicas FEC.
Introduciendo como parámetros los ficheros que representan
ambos flujos de datos, el programa muestra estadísticas que
permiten analizar la eficiencia de las técnicas FEC en cuanto a
paquetes y bytes reconstruidos. Para ello, el programa extrae
en la salida estándar una lista de cuatro valores de esta forma:
totalbytes
errbytes
totalpackets
errpackets
Estos valores representan el tamaño en bytes del flujo
original (sin la redundancia FEC), el número de bytes erróneos
recibidos, el número total de paquetes del flujo original y el
número de paquetes erróneos recibidos, respectivamente.
F. Resultados
A continuación se presentan una serie de resultados (Figuras
2 y 3) obtenidos tras la puesta en marcha del script de
simulación desarrollado. Para generarlos, se ha experimentado
con varias tasas de inyección de errores, intentando representar
redes más fiables (como redes Ethernet locales) o redes menos
fiables (como redes de área amplia o redes inalámbricas).
Concretamente, se ha variado la tasa de error desde 10-5 (un
error cada 105 bytes transferidos, con distribución
exponencial) hasta 10-2 (un error cada 100 bytes).
Por otro lado, para cada tasa de error se ha experimentado
con diferentes códigos FEC, representados desde el código 0
(0% de redundancia) hasta el código 3 (100% de redundancia),
descritos anteriormente. Las dos variables monitorizadas y
representadas en estas gráficas son el porcentaje de bytes
perdidos y el porcentaje de paquetes perdidos.
1) Porcentaje de bytes perdidos:
Observando la primera de las gráficas de la Figura 1,
podemos ver que para una tasa de error de 10-5, el código FEC
1 (redundancia del 25%) ya consigue recuperar la totalidad de
los errores inducidos por la red, llegando a un 0% de bytes
perdidos.
Para las tasas de error de 10-4 y 10-3, observamos una caída
del porcentaje de bytes perdidos conforme aumentamos la
redundancia FEC. Es importante recordar que los errores
introducidos en la red afectan tanto a paquetes originales como
a paquetes FEC. Sin embargo, cuanta más redundancia FEC se
introduzca, existe mayor probabilidad de encontrar un paquete
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
RTSP/FEC no afectado por ningún error que permita
reconstruir un determinado paquete RTSP original.
La tasa de error de 10-2 es muy agresiva, ya que provoca una
alta probabilidad de que incluso caigan varios errores en un
mismo paquete. En este caso, la redundancia FEC no obtiene
prácticamente ningún beneficio, puesto que en todos los casos
se obtiene prácticamente un 1% de bytes perdidos (igual a la
tasa de error).
2) Porcentaje de paquetes perdidos:
En la primera de las cuatro gráficas de la Figura 3, podemos
realizar la misma observación que en la monitorización del
porcentaje de bytes perdidos: para tasas de errores pequeñas,
el código FEC 1 ya soluciona todos los problemas de
transmisión.
La red con tasa de fallos de 10-3 es la que muestra más
beneficios con un aumento de la redundancia FEC.
Observando la gráfica correspondiente, podemos ver que, si no
se introdujera ninguna técnica de recuperación de errores, los
paquetes perdidos ascenderían al 42%. Sin embargo, una
redundancia FEC del 100% es capaz de disminuir el
porcentaje de paquetes perdidos al 17%.
Por último, la última de las cuatro gráficas no aporta
información adicional respecto a las cuatro anteriores. De ella
se desprende de nuevo que una tasa de errores de 10-2 es
demasiado alta como para compensarla con técnicas FEC.
100%) para paliar completamente el problema. Sin embargo,
un aumento de redundancia se traduce en una disminución
agresiva del número de errores observados por el receptor.
Para tasas de error de 10-3, redundancias razonables
simplemente reducen suavemente el total de errores
percibidos, mientras que una tasa de 10-2 se traduce en una
transmisión irreparable mediante FEC.
Como trabajo futuro, se puede proponer la extensión de la
herramienta diseñada para modelar los retardos de los
paquetes, así como el jitter dependiente de los diferentes tipos
de redes. Con estas ampliaciones podría evaluarse la forma en
que afectan las citadas variables a un flujo de datos
multimedia, como por ejemplo, la medida en que un jitter
determinado afecta al retardo mínimo que deben sufrir los
paquetes (y por tanto el tamaño de los buffers en el receptor)
dependiendo también del tamaño de los paquetes. En este y
otros estudios, la captura de los datos multimedia realizada
mediante Ethereal podría ser reutilizable.
REFERENCIAS
[1]
[2]
[3]
3) Conclusión
De entre las dos métricas utilizadas, la segunda de ellas
(porcentaje de paquetes perdidos) es la que tiene sentido en
una transmisión de datos convencionales, por ejemplo
ficheros. En este caso, un paquete erróneo deja de superar la
prueba del checksum y es descartado por el propio protocolo
TCP/IP.
Sin embargo, en una transmisión de datos multimedia,
podría resultar de utilidad la primera métrica (porcentaje de
bytes perdidos), ya que un paquete erróneo, e imposible de
recuperar, puede continuar conteniendo información válida
para el receptor. Esto podría darse, por ejemplo, en una
transmisión de vídeo, en la que un byte erróneo puede suponer
un píxel erróneo en la imagen final. En tal caso, tiene más
sentido obtener el paquete e interpretarlo erróneamente que
descartarlo a priori.
IV. CONCLUSIONES
En este trabajo, se ha construido una herramienta de
simulación de redes con diferentes tasas de errores y se ha
estudiado la influencia que tiene la aplicación de diferentes
códigos FEC sobre cada una de ellas.
Los resultados han demostrado que, para redes con una tasa
de errores de 10-5, un código FEC de baja redundancia
soluciona los errores de transmisión en su totalidad. Como
término medio, redes con tasa de error de 10-4 necesitan
aumentar en gran medida la redundancia (incluso superando el
8
[4]
[5]
[6]
[7]
C. E. Shannon. “A Mathematical Theory of Communication”. The Bell
System Technical Journal, Vol. 27, pp. 379–423, 623–656, July,
October, 1948.
P. Elias, “Coding for noisy channels”, IRE Convention Record, pt.4,
pp.37-47, 1955
Andrew J. Viterbi. Error bounds for convolutional codes and an
asymptotically optimum decoding algorithm. IEEE Transactions on
Information Theory 13(2):260–269, April 1967.
Berrou C., Glavieux A., and Thitimajshima P. (1993). “Near Shannon
limit error-correcting coding and decoding: Turbo-Codes,” ICC’93,
Geneva, Switzerland, pp. 1064-1070, May.
RFC 1889 and 3550 - RTP: A Transport Protocol for Real-Time
Applications.
RFC 2326 - Real Time Streaming Protocol (RTSP).
RFC 2733 - An RTP Payload Format for Generic Forward Error
Correction.