ES2325317T3 - Metodo y dispositivos para controlar las retransmisiones en el flujo de datos. - Google Patents
Metodo y dispositivos para controlar las retransmisiones en el flujo de datos. Download PDFInfo
- Publication number
- ES2325317T3 ES2325317T3 ES02777018T ES02777018T ES2325317T3 ES 2325317 T3 ES2325317 T3 ES 2325317T3 ES 02777018 T ES02777018 T ES 02777018T ES 02777018 T ES02777018 T ES 02777018T ES 2325317 T3 ES2325317 T3 ES 2325317T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- delay
- transmission
- allocation
- data packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
- H04L1/1838—Buffer management for semi-reliable protocols, e.g. for less sensitive applications such as streaming video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1848—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—Real-time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
- H04L47/263—Rate modification at the source after receiving feedback
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1854—Scheduling and prioritising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Vehicle Body Suspensions (AREA)
- Electrotherapy Devices (AREA)
Abstract
Un método para la transmisión de una pluralidad de paquetes de datos desde un emisor (1) a un receptor (2), en el que la transmisión de datos se lleva a cabo sobre un enlace (5) con una capacidad de transmisión que tiene un límite, y se define un tiempo de presentación para un primer paquete de datos de la citada pluralidad, y en el que el receptor (2) lleva a cabo una primera comprobación de si los paquetes de datos se reciben correctamente y al menos un paquete de datos es seleccionado para su retransmisión de acuerdo con el resultado de la primera comprobación, caracterizado porque se determina una asignación de retardo (DB) a partir del tiempo de presentación del primer paquete de datos, en el que la asignación de retardo puede ser atribuida a retransmisiones sin retardar el primer paquete de datos más allá del tiempo de presentación, se determina un requisito de retardo para la retransmisión del paquete de datos seleccionado a partir del límite de la capacidad de transmisión y a partir de la capacidad de transmisión requeridos para el paquete de datos seleccionado. se lleva a cabo una comparación (30) del requisito de retardo con la asignación de retardo (DB), y se ejecuta la retransmisión para el paquete de datos seleccionado de acuerdo con el resultado de la comparación (30).
Description
Método y dispositivos para controlar las
retransmisiones en el flujo de datos.
La presente invención se refiere a un método de
acuerdo con el preámbulo de la reivindicación 1. Se describen
también dispositivos y programas de software que realizan la
invención.
Las aplicaciones de transmisión en directo o en
tiempo real son cada vez más importantes, tanto en redes fijas como
la Internet como en el contexto de redes móviles de 3^{rd}
Generación como UMTS (Universal Mobile Telephone System - Sistema
de Teléfono Móvil Universal). La tecnología de transmisión en
directo o en tiempo real permite un acceso casi instantáneo para
los usuarios al contenido pre-almacenado sin
necesidad de transferir un fichero completo antes de su
presentación. Las aplicaciones de transmisión en directo o en tiempo
real son ampliamente usadas para medios de video y audio.
En una aplicación de transmisión en directo o en
tiempo real, una corriente o flujo de paquetes de datos es
transmitida desde un servidor que es el emisor original a un cliente
como receptor final de los paquetes de datos. Pueden perderse
paquetes durante la transmisión, por ejemplo debido a errores de
transmisión o debido a extracción mediante métodos para evitar la
congestión. También pueden retrasarse paquetes, por ejemplo debido
a las características del enlace, congestión del enlace y
retransmisiones de paquetes perdidos. Diferentes retardos
individuales para los paquetes pueden provocar una fluctuación del
retardo dentro del flujo de paquetes. La velocidad de los datos de
un flujo puede tener también variaciones debido a la codificación de
los medios. Por ejemplo, una opción para transmitir una secuencia
de video es la transmisión de las diferencias entre imágenes
consecutivas. Esto provoca una alta velocidad de datos en el caso de
que haya muchas diferencias mientras la velocidad de datos es lenta
si varias imágenes consecutivas son idénticas.
Cada paquete tiene un tiempo de presentación en
el cual debe estar disponible en el cliente para su tratamiento y
presentación, por ejemplo para mostrarlo en una secuencia de video o
de audio. Paquetes, que se pierden o llegan demasiado tarde, no
pueden ser mostrados. En consecuencia, las aplicaciones de
transmisión en directo o en tiempo real son sensibles tanto a
pérdida de paquetes como a retardos. Por lo tanto, los clientes de
transmisión en directo o en tiempo real generalmente tienen una
memoria temporal, que permite compensar fluctuaciones en el retardo
de la transmisión y en el retardo introducido por la retransmisión
de paquetes de datos perdidos o erróneos. Tanto la memoria del
cliente requerida para almacenar en la memoria temporal como el
ancho de banda del enlace son no obstante recursos limitados y
caros, sobre todo en aplicaciones móviles. Por lo tanto, a menudo
se seleccionan requisitos casi mínimos para una calidad de servicio
deseada.
El protocolo RTP (Real-tiempo
Transport Protocol - Protocolo de Transporte en
Tiempo-Real) permite un suministro eficiente de
paquetes de datos para medios de comunicación en tiempo real como
ficheros de audio o de video. El RTP es transportado en un UDP
(User Datagram Protocol - Protocolo de Diagrama de Datos del
Usuario), que no incluye un mecanismo de retransmisión para la
recuperación de paquetes perdidos o corrompidos. Por lo tanto,
además de un RTP se requiere un mecanismo de retransmisión para
compensar las pérdidas de paquetes. El RTCP (RTP control protocol -
protocolo de control de RTP) especifica un formato de paquete de
datos que puede ser usado para implementar tal mecanismo de
retransmisión. El método de control de retransmisión no está
especificado en el RTCP con el fin de permitir adaptaciones a
aplicaciones individuales. Diferentes métodos de control de
retransmisiones para el protocolo RTP son por lo tanto posibles
basados en el formato de paquete de datos del RTCP.
Un ejemplo de un método de retransmisión se
describe en la patente US 6.275.471. Cuando un receptor recibe un
flujo desde un emisor tras una petición acordada, el receptor
comprueba si hay algún paquete de datos pedido. Si este es el caso,
el receptor determina un período de transmisión restante para los
paquetes de datos perdidos, es decir el último tiempo en el cual el
paquete necesita estar disponible en el receptor para su
presentación. El período de transmisión restante es enviado con el
acuse de recibo negativo para el paquete de datos perdido al
emisor. El emisor compara el período de transmisión restante con un
tiempo de ida y vuelta estimado para comprobar si el paquete
solicitado puede llegar al receptor antes del tiempo de presentación
requerido, si este es el caso, la retransmisión se lleva a cabo. Si
no, el paquete no es retransmitido y el receptor construye la
salida de la aplicación sin el paquete perdido, por ejemplo usando
técnicas de ocultación de error.
Entre el servidor y el cliente, los paquetes de
datos son transportados mediante una o varias redes de transporte,
típicamente sobre una pluralidad de enlaces con diferentes
características. A menudo, uno de los citados enlaces es un cuello
de botella para la transmisión puesto que tiene la velocidad de
datos más baja y/o un tiempo de ida y vuelta alto, influyendo este
último sobre todo en el retardo de las retransmisiones. En los
sistemas de comunicación inalámbrica, el cuello de botella es
generalmente el enlace inalámbrico hacia un equipo de usuario
móvil, por ejemplo un teléfono móvil. La solicitud de patente
Europea EP 1 130 839 describe una opción para calcular el retardo
de transmisión de paquetes de datos.
\newpage
En un enlace con ancho de banda limitado, puede
ocurrir una auto-congestión. Si los paquetes de
datos son retransmitidos, el servidor tiene que asegurar que el
tráfico total que comprende tanto paquetes originales como paquetes
de datos retransmitidos no excede una tasa de errores permitida o
garantizada. Debido a la limitación, paquetes de datos originales a
menudo son retardados cuando se lleva a cabo una retransmisión,
sobre todo si la velocidad de los datos de los paquetes de datos
originales es parecida a la capacidad del enlace. Este retardo
puede alterar el comportamiento de la presentación del flujo de
datos mediante la aplicación de transmisión en directo o en tiempo
real, que puede ser interrumpida o puede necesitar aplicar una
corrección u ocultación de error.
La velocidad de los datos puede variar
considerablemente para algunos tipos de enlaces, por ejemplo de
acuerdo con el comportamiento de otros usuarios que comparten los
mismos recursos, mientras que otros enlaces proporcionan un ancho
de banda constante o casi constante para transmisión. Por ejemplo,
los portadores de transmisión de UMTS en directo o en tiempo real
que transportan los paquetes de datos a clientes móviles pueden ser
negociados para combinaciones de tasas de error garantizadas
específicas, pérdida de paquetes, y retardo para los paquetes de
datos. Muchas aplicaciones de transmisión en directo o en tiempo
real permiten una adaptación del flujo a parámetros garantizados,
por ejemplo seleccionando la velocidad de datos original por debajo
de la tasa de error garantizada, permitiendo una velocidad de
retransmisiones de acuerdo con la diferencia entre la tasa de error
seleccionada y la garantizada. Una pasarela, por ejemplo una
3G-GGSN (Gateway GPRS Support Node - Nodo de
Soporte de GPRS que funciona como Pasarela) en el ejemplo de un
sistema de UMTS, controla el tráfico desde el servidor hasta el
cliente usando una función de control del tráfico. Si el tráfico
excede los parámetros garantizados, pueden extraerse paquetes. Esto
puede llevar a una severa alteración de la presentación del flujo,
especialmente si las retransmisiones aumentan la tasa de error del
flujo por encima de una tasa de error garantizada.
Es un objeto de la presente invención obviar los
inconvenientes anteriores y proporcionar un método y dispositivos
para controlar las retransmisiones en transmisión de datos en
directo o en tiempo real que reduce la alteración de la aplicación
de recepción mediante paquetes de datos retardados o extraídos. Otro
objeto es permitir una alta utilización del ancho de banda
disponible para la transmisión. Otro objeto más es llevar a cabo el
control de la retransmisión con una baja complejidad.
De acuerdo con la invención, se lleva un cabo el
método descrito en la reivindicación 1. Además, la invención es
realizada en dispositivos y en un programa de software como el
descrito en las reivindicaciones 11 a 13. Realizaciones ventajosas
se describen en las reivindicaciones dependientes.
En un método para la transmisión de una
pluralidad de paquetes de datos desde un emisor hasta un receptor,
la transmisión de datos se lleva a cabo sobre un enlace con una
limitada capacidad de transmisión. El emisor y el receptor no
necesitan ser el origen y el destino final de la transmisión sino
que pueden ser también entidades intermedias, por ejemplo
servidores de proximidad. El método puede ser implementado más
fácilmente si el límite de la capacidad de transmisión es constante
o si los cambios en el límite pueden ser predichos fácilmente, por
ejemplo debido a variaciones lentas o a información desde otras
entidades del protocolo en la transmisión.
El receptor lleva a cabo una primera
comprobación de si los paquetes de datos se reciben correctamente.
Por ejemplo, el receptor puede comprobar si los paquetes faltan por
completo usando números de secuencia de paquetes o puede determinar
a partir de información redundante en el paquete de datos, por
ejemplo a partir de una CRC (cyclic redundancy check - comprobación
de redundancia cíclica), si un paquete es erróneo debido a errores
de transmisión. Al menos se selecciona un paquete de datos para su
retransmisión de acuerdo con el resultado de la primera
comprobación, es decir el paquete es seleccionado si es erróneo o
faltante.
Se define un tiempo de presentación para un
primer paquete de datos de la citada pluralidad. Típicamente, la
pluralidad de paquetes de datos para transmisión es un flujo de
paquetes aunque el método es generalmente aplicable si hay un
tiempo de presentación definido para los paquetes transmitidos sobre
un enlace. El tiempo de presentación corresponde al último tiempo
en el que el primer paquete de datos debe llegar al receptor para
ser procesado y, en el caso del receptor final en una transmisión,
ser presentado por la aplicación. El tiempo de presentación puede
por ejemplo ser indicado en un campo de datos en una cabecera de
protocolo del citado paquete o en una información de control
enviada con un flujo. En la mayoría de los casos, los tiempos de
presentación se definen para todos los paquetes de datos de la
pluralidad.
En esta especificación, los paquetes
transmitidos por primera vez son llamados paquetes originales. Los
paquetes originales y las retransmisiones no son necesariamente
idénticos, por ejemplo si un protocolo permite retransmitir sólo
las secciones de un paquete original que eran erróneas. También es
posible que se detecte una retransmisión como faltante o errónea y
sea seleccionada para otra retransmisión. Tanto los primeros
paquetes de datos como los paquetes de datos seleccionados pueden
por lo tanto ser una transmisión original o una retransmisión.
A partir del tiempo de presentación del primer
paquete de datos, se determina una asignación de retardo. La
asignación de retardo indica una capacidad de transmisión, que puede
ser atribuida a retransmisiones sin retardar el primer paquete de
datos por encima del tiempo de presentación. Además, se determina un
requisito de retardo para la retransmisión del paquete de datos
seleccionado. El requisito de retardo es calculado a partir del
límite de la capacidad de transmisión y a partir de la capacidad de
transmisión requerida por el paquete de datos seleccionado, es
decir el requisito de retardo es calculado bajo la asunción de que
la retransmisión es llevada a cabo usando el límite de la capacidad
de transmisión.
Se lleva a cabo una comparación del requisito de
retardo y de la asignación de retardo. La retransmisión del paquete
de datos seleccionado es ejecutada de acuerdo con el resultado de la
comparación, es decir el paquete de datos seleccionado sólo es
retransmitido si la asignación de retardo es al menos igual al
requisito de retardo mientras que la retransmisión es de otro modo
cancelada.
Típicamente, el límite de la capacidad de
transmisión corresponde a una velocidad de datos máxima. No
obstante, otro u otros recursos relativos a la capacidad de
transmisión pueden ser considerados en la comparación, por ejemplo
capacidades de tratamiento del emisor o del receptor. El requisito
de retardo corresponde generalmente a un tamaño de paquete del
paquete de datos seleccionado. La comparación con la asignación de
retardo es en este caso llevada a cabo preferiblemente para el
tamaño de paquete dividido por el límite de la velocidad de
transmisión.
Aunque el método y la comparación
correspondiente se describen a lo largo de esta especificación de
acuerdo con el tiempo requerido para la transmisión, debe
observarse que existen representaciones equivalentes. Por ejemplo,
en el caso de una velocidad de datos constante, es equivalente
determinar la asignación de retardo como un número de bloques de
datos de una capa de protocolo inferior o de bytes o de bits
permisibles y comparar el tamaño de los paquetes de datos
seleccionados con la asignación de retardo determinada de esta
manera.
La idea básica del método propuesto es un
control de retransmisión, que evita el problema de la
auto-congestión provocada por las retransmisiones
cuando se transmite sobre un enlace de cuello de botella. El método
evita sub-flujos de la memoria temporal mientras
que permite una implementación con una baja complejidad. Es
especialmente adecuado para la transmisión de datos en directo o en
tiempo real como la que se lleva a cabo por ejemplo en aplicaciones
de multimedia móviles. Para este caso, el método aprovecha el hecho
de que un flujo codificado de velocidad variable no siempre utiliza
toda la capacidad del enlace. Sobre todo, la calidad de la salida
de la aplicación percibida se mejora considerablemente porque se
evitan las interrupciones del flujo de datos. El método puede ser
implementado en el servidor o en el cliente. Para mejorar el
rendimiento en una conexión, una opción es dividirla en uno o en
ambos extremos de un enlace de cuello de botella mediante un
servidor de proximidad. En este caso, puede también ser ventajoso
implementar el método en el servidor de proximidad que es un emisor
y receptor intermedio en la transmisión de datos.
En una realización preferida del método, el
receptor almacena paquetes de datos en una memoria temporal con un
nivel de llenado de la memoria temporal que varía a lo largo del
tiempo. En este caso, la asignación de retardo es una función del
nivel de llenado de la memoria temporal y se calcula con respecto al
nivel de llenado de la memoria temporal. Una memoria temporal
generalmente tiene un tamaño de memoria temporal predeterminado
correspondiente al máximo nivel de llenado y así a la máxima
asignación de retardo. Preferiblemente, la transmisión es
controlada de tal manera que el nivel de llenado es cercano al
tamaño de la memoria temporal con el fin de maximizar la asignación
de retardo.
Preferiblemente, la asignación de retardo es
determinada para varios primeros paquetes de datos, es decir para
un grupo que comprende al menos dos primeros paquetes de datos. De
esta manera, la asignación de retardo puede considerar todos los
primeros paquetes de datos, que pueden ser retardados por la
retransmisión del paquete de datos seleccionado. Una opción simple
en este caso es calcular primero una asignación de retardo
individual para cada primer paquete de datos del grupo y determinar
a continuación la asignación de retardo como el mínimo de las
asignaciones de retardo individuales.
La asignación de retardo considera
preferiblemente los tiempos de presentación para todos los primeros
paquetes de datos, que pueden ser retardados por las
retransmisiones. Por otro lado, el esfuerzo de tratamiento aumenta
con el número de paquetes de datos en el grupo considerados para la
asignación de retardo. Si los primeros paquetes de datos son
transmitidos en una secuencia predefinida, es por lo tanto ventajoso
seleccionar sólo aquellos paquetes de datos para el grupo de
paquetes considerados que son los siguientes paquetes de datos para
su transmisión en la citada secuencia. O bien puede considerarse un
cierto número de paquetes o se define un criterio para detener la
selección. Un criterio de detención ventajoso es terminar la
selección de paquetes de datos para el grupo si la asignación de
retardo permanece constante para cualesquiera otros paquetes. Para
un tamaño de memoria temporal limitado, generalmente es posible
detener el cálculo de la asignación de retardo sin pérdida de
información cuando la transmisión de los paquetes en el grupo en el
límite de la capacidad de transmisión alcanza el tamaño de memoria
temporal limitado. La consideración de otros paquetes de datos no
afecta a la asignación de retardo y la selección de paquetes de
datos para el grupo puede por lo tanto detenerse.
El método es ventajoso si el receptor solicita
los paquetes de datos seleccionados sin un mensaje de estado. En
este caso, el método puede ser implementado en el receptor para
controlar el envío de mensajes de estado o en el emisor para
controlar si y qué retransmisiones se llevan a cabo en respuesta a
un mensaje de estado.
Cuando se usa el método, varios paquetes de
datos pueden ser seleccionados para su retransmisión, es decir el
paquete de datos seleccionado y al menos otro paquete de datos. Por
lo tanto, la asignación de retardo se reduce preferiblemente
mediante el requisito de retardo si se lleva a cabo una
retransmisión de un paquete de datos. La reducción permite una
adaptación de la asignación de retardo simple para otras
comparaciones con respecto a otros paquetes de datos seleccionados
para su retransmisión. En este caso, una nueva asignación de
retardo es calculada sólo a partir de los tiempos de presentación de
los primeros paquetes de datos si la asignación de retardo asignada
no es suficiente para otro requisito de retardo. Alternativamente,
una nueva asignación de retardo puede ser calculada a partir de los
tiempos de presentación de los primeros paquetes de datos para cada
una de las otras comparaciones. No obstante, el último planteamiento
requiere generalmente más capacidad de tratamiento.
Si la asignación de retardo es ajustada de
acuerdo con las retransmisiones llevadas a cabo, es ventajoso llevar
a cabo otro cálculo de la asignación de retardo a partir de los
tiempos de presentación de los primeros paquetes de datos después
de otra comparación de la asignación de retardo con otro requisito
de retardo. Esto permite una reducción del esfuerzo de tratamiento
para determinar una asignación de retardo para otras
retransmisiones.
Generalmente, el cálculo de la asignación de
retardo asume que los datos son transmitidos en el límite de la
capacidad de transmisión. No obstante, la presente velocidad de
datos puede estar sujeta a otras restricciones, por ejemplo
restricciones temporales mediante el sistema de transmisión debido a
un tráfico priorizado o debido a una velocidad de transmisión más
baja por el emisor para absorber un tamaño de memoria temporal
limitado del receptor. Por lo tanto, la asignación de retardo está
preferiblemente adaptada si una velocidad de la transmisión de
datos presente es menor que el límite de la capacidad de transmisión
de datos.
Es posible extender el método utilizando
información adicional acerca de los paquetes de datos con el fin de
optimizar el rendimiento global de la aplicación en presencia de
pérdidas de paquetes. Para este propósito, preferiblemente se le
atribuye una prioridad a un paquete de datos primero o seleccionado
y la retransmisión es llevada a cabo de acuerdo con la citada
prioridad. Por ejemplo, la información que afecta a la presentación
de un elevado número de tramas subsiguientes puede tener una
prioridad mayor en una aplicación de transmisión en directo o en
tiempo real. La prioridad puede ser considerada en diferentes etapas
del método, por ejemplo puede ser considerada en la primera
comprobación, en la determinación de la asignación de retardo, en la
determinación del requisito de retardo, en la comparación del
requisito de retardo con la asignación de retardo, o para iniciar
una retransmisión. Por ejemplo, puede evitarse que una transmisión
original con prioridad baja bloquee una retransmisión con prioridad
alta mediante el establecimiento del requisito de retardo para la
retransmisión a cero u omitiendo paquetes con prioridad baja a
partir del cálculo de la asignación de retardo. En otro ejemplo,
una retransmisión de un paquete con baja prioridad puede ser evitada
no seleccionándolo en la primera comprobación y omitiendo la
ejecución de la retransmisión después de la comparación. En la
comparación, el ajuste de parámetros puede usarse de acuerdo con
las prioridades. Esta realización del método es especialmente
ventajosa en un servidor porque las prioridades no necesitan ser
transmitidas al receptor en este caso.
Si las prioridades son especificadas de acuerdo
con el contenido de la aplicación, puede también indicarse que las
pérdidas de paquetes son más aceptables en ciertas posiciones en un
flujo de datos, por ejemplo en cortes de escena o durante imágenes
fijas de un video. Es entonces posible omitir el método propuesto
para paquetes suficientemente cercanos a la posición aceptable, por
ejemplo estableciendo el requisito de retardo para todos aquellos
paquetes de datos a cero, que son más cercanos a la posición
aceptable que uno o dos tiempos de ida y vuelta de la transmisión.
De esta manera pérdidas inevitables y casos de nuevo almacenamiento
en la memoria temporal pueden ser desplazados a posiciones en el
flujo de paquetes para las cuales el impacto el impacto en la
calidad percibida es minimizado.
Preferiblemente, en otra comprobación se compara
un tiempo de presentación para el paquete de datos seleccionado con
un tiempo de llegada estimado del paquete de datos seleccionado al
receptor. La retransmisión del paquete de datos seleccionado se
lleva a cabo de acuerdo con el resultado de otra comprobación. De
manera correspondiente, pueden evitarse las retransmisiones de esos
paquetes de datos, que llegarían demasiado tarde al receptor para su
tratamiento.
Un emisor preferible para la transmisión de una
pluralidad de paquetes de datos a un receptor tiene una unidad de
transmisión para enviar los datos hasta el receptor. La transmisión
de datos puede ser llevada a cabo sobre un enlace con una capacidad
de transmisión que tiene un límite. Además, el emisor tiene una
unidad receptora para recibir una indicación de si el receptor ha
recibido correctamente los paquetes de datos. Una unidad de
tratamiento está "conectada" con la unidad de transmisión y con
la unidad de recepción, típicamente integrada en un transceptor, y
procesa los paquetes de datos transmitidos y recibidos. Sobre todo,
la unidad de tratamiento puede definir un tiempo de presentación
para un primer paquete de datos de la citada pluralidad, por ejemplo
extrayendo un campo de datos correspondiente desde una cabecera del
primer paquete de datos, además, la unidad de tratamiento puede
seleccionar al menos un paquete de datos para su retransmisión de
acuerdo con una indicación recibida.
A partir del tiempo de presentación del primer
paquete de datos, la unidad de tratamiento determina una asignación
de retardo. Además, la unidad de tratamiento determina un requisito
de retardo para la retransmisión del paquete de datos seleccionado
a partir del límite de la capacidad de transmisión y a partir de la
capacidad de transmisión requerida para el paquete de datos
seleccionado. La unidad de tratamiento está adaptada para llevar a
cabo una comparación del requisito de retardo y la asignación de
retardo y para iniciar la retransmisión para el paquete de datos
seleccionado de acuerdo con el resultado de la comparación, es decir
para iniciarla sólo si la comparación indica una asignación de
retardo suficiente para la retransmisión.
Un receptor para la recepción de una pluralidad
de paquetes de datos desde un emisor tiene una unidad de recepción
para recibir los paquetes de datos. Los paquetes de datos son
transmitidos sobre un enlace con una capacidad de transmisión que
tiene un límite. Una unidad de transmisión del receptor puede enviar
indicaciones de si los paquetes de datos se reciben correctamente.
Una unidad de tratamiento está conectada con la unidad de
transmisión y con la unidad de recepción, lleva a cabo una
comprobación, si los paquetes de datos se reciben correctamente, y
selecciona al menos un paquete de datos para la indicación de
acuerdo con el resultado de la citada comprobación. La unidad de
tratamiento está también adaptada para definir un tiempo de
presentación para un primer paquete de datos de la citada
pluralidad.
Además, la unidad de tratamiento está adaptada
para determinar una asignación de retardo a partir del tiempo de
presentación del primer paquete de datos. La unidad de tratamiento
determina también un requisito de retardo para la retransmisión del
paquete de datos "seleccionado" a partir del límite de la
capacidad de transmisión y a partir de la capacidad de transmisión
requerida para el paquete de datos seleccionado. La unidad de
tratamiento lleva a cabo una comparación del requisito de retardo y
de la asignación de retardo y selecciona el paquete de datos para
la indicación de acuerdo con el resultado de la comparación, es
decir un paquete de datos es incluido en la indicación sólo si no
se ha recibido correctamente y si la asignación de retardo permite
una retransmisión.
Tanto el emisor como el receptor pueden
adaptarse a cualquier realización del método anterior. El método
puede también ser implementado mediante una unidad de programa de
software que comprende un código para llevar a cabo las etapas del
método cuando es ejecutado en el sistema de tratamiento de un
cliente, un servidor o un servidor de proximidad. La unidad de
programa está por ejemplo almacenada en un portador de datos o puede
cargarse en el sistema de tratamiento, por ejemplo como una
secuencia de señales. Puede ser parte de un paquete de software que
incluye otras unidades de software.
El anterior y otros objetos, características y
ventajas de la presente invención resultarán más evidente en la
siguiente descripción detallada de las realizaciones preferidas como
se ilustra en los dibujos que se acompañan.
La Fig. 1 muestra una transmisión de datos desde
un servidor hasta un cliente
La Fig. 2 muestra un sub-flujo
de una memoria temporal provocado por las retransmisiones cuando se
lleva a cabo una transmisión en directo o en tiempo real sobre un
enlace de cuello de botella
La Fig. 3 muestra un diagrama de flujo de un
método de retransmisión de acuerdo con la invención
La Fig. 4 muestra el cómputo del tiempo de envío
más temprano t_{n} para un paquete de datos n
La Fig. 5 muestra un ejemplo de computar la
asignación de retardo para retransmisiones
La Fig. 1 representa una transmisión de datos
desde un servidor que es el emisor 1 de los paquetes de datos hasta
un cliente que es el receptor 2 para los paquetes enviados. La
transmisión se lleva a cabo sobre uno o más enlaces
3-5, que son por ejemplo conexiones en un sistema de
comunicación. Típicamente, uno de los enlaces es un enlace de
cuello de botella 5 con una velocidad baja de transmisión de datos.
Opcionalmente, el rendimiento de la transmisión es mejorado
mediante uno o dos servidores de proximidad 6,7 en los extremos del
enlace de cuello de botella 5. En este caso, los servidores de
proximidad 6, 7 pueden ser emisores y receptores intermedios en la
transmisión.
El emisor 1 tiene una memoria M, en la cual el
contenido para transmitir es almacenado y de la que es extraído y
procesado por una unidad de tratamiento PS antes de su transmisión
hacia el receptor 2 mediante una unidad transceptora TRS. También
el receptor 2 está provisto de una unidad transceptora TRR para
descodificar los paquetes de datos recibidos y enviarlos hasta una
unidad de tratamiento PR, que procesa el contenido para su
presentación a un usuario. Una memoria temporal BU en el receptor
permite un almacenamiento temporal del contenido para compensar
variaciones en la velocidad de transmisión. Unidades
correspondientes pueden también tratar los datos en los servidores
de proximidad 6, 7 opcionales y se omiten en la figura sólo por
simplificación.
La Figura 2 ilustra el problema subyacente de un
protocolo que lleva a cabo retransmisiones sobre un enlace con
ancho de banda limitado. La figura representa los datos acumulados,
es decir el número B total de bytes, transmitidos en el tiempo t.
La línea de presentación 11 corresponde a la cantidad total de
datos, que necesitan ser transmitidos al receptor en cualquier
momento para permitir una presentación uniforme de los medios. Si
en un cierto momento están disponibles menos datos, es decir en caso
de un sub-flujo de la memoria temporal del cliente,
no hay datos presentes para la presentación continua. La
presentación tiene que parar hasta que otros datos son transmitidos
y están disponibles, es decir hasta que haya tenido lugar un nuevo
almacenamiento en la memoria temporal.
Generalmente se procesan y envían paquetes de
datos completos para su tratamiento a la aplicación. Por lo tanto,
la línea de presentación 11 corresponde a una secuencia de puntos
discretos en el tiempo cuando el último bloque de datos de cada
paquete tiene que estar disponible en el receptor. Por simplicidad
de representación, estos puntos están representados por la línea de
presentación 11 de conexión.
Un cliente de transmisión en directo o en tiempo
real habitualmente almacena en una memoria temporal más datos de
los requeridos para una presentación uniforme para ser capaz de
compensar pequeñas fluctuaciones en el rendimiento del enlace.
Normalmente, el espacio disponible en la memoria temporal es
limitado, sobre todo cuando la memoria es cara como es el caso en
los terminales móviles. El límite superior 12 en la cantidad de
datos, que pueden ser almacenados por el cliente, se muestra en la
Fig.2 mediante una línea discontinua. El límite superior 12 es
copia de la línea de presentación 11 desplazada verticalmente. El
desplazamiento entre la línea de presentación 11 y el límite
superior 12 corresponde al tamaño de la memoria temporal. Deben
descartarse datos en caso de una sobrecarga de la memoria temporal,
es decir si el cliente, debido a un tamaño de memoria temporal
limitado, no puede almacenar datos transmitidos por el emisor.
Para evitar tanto un sub-flujo
como una sobrecarga de la memoria temporal, el servidor envía los
paquetes de datos de acuerdo con un plan de transmisión 13, que es
calculado para mantener los datos acumulados entre la línea de
presentación 11 y el límite superior 12. Siempre que los datos sigan
el plan de transmisión 13, no ocurren ni un
sub-flujo de la memoria temporal ni una sobrecarga
de la memoria temporal. El servidor puede determinar el plan de
transmisión 13 porque tanto el tamaño de la memoria temporal del
cliente como la línea de presentación 11 son conocidos. El tamaño
de la memoria temporal del cliente es a menudo negociado durante el
establecimiento de la sesión mientras que la línea de presentación
11 es una función del contenido almacenado en el servidor.
Preferiblemente, el plan de transmisión 13 corresponde casi al
límite superior 12 de la memoria temporal para permitir variaciones
de transmisión o una rotura del enlace temporal, sobre todo para
transmisión inalámbrica.
Debido a los paquetes retransmitidos, la
planificación de los datos originales puede ser retardada. Esto se
indica en la Fig. 2 mediante la línea de puntos 14. Durante la
sección horizontal de la línea 14, la transmisión de paquetes
originales de datos es suspendida y en su lugar se llevan a cabo
retransmisiones. El retardo puede provocar un inmediato
sub-flujo en la memoria temporal o bien puede
provocar un sub-flujo U en un momento posterior.
Esto se debe al hecho de que la velocidad de transmisión máxima,
correspondiente a la máxima pendiente del plan de transmisión 13,
está limitada. La línea de presentación 11 puede tener temporalmente
una pendiente mayor que la máxima velocidad de transmisión y la
transmisión de un paquete de datos consecutivo puede ser todavía
incompleta en el momento de la presentación. En este caso, los
paquetes de datos llegan al cliente después del tiempo de
presentación
requerido.
requerido.
El método propuesto permite evitar
perturbaciones debido a las retransmisiones, sobre todo sobrecargas
de la memoria temporal y los correspondientes casos de nuevos
almacenamientos en la memoria temporal, cuando tiene lugar una
transmisión en directo o en tiempo real sobre un enlace de cuello de
botella. La idea básica es una predicción del comportamiento de la
transmisión futura, que permite al servidor retransmitir paquetes
sólo en aquellos casos, en los que la retransmisión no provoca una
sobrecarga en la memoria temporal inmediata o futura, en
particular, el método descrito permite una implementación con baja
complejidad en el servidor. Esto es sobre todo ventajoso para el
tratamiento de elevados volúmenes de datos y aumenta el número de
flujos, que el servidor puede tratar simultáneamente.
La Figura 3 muestra un ejemplo del método de
control de retransmisión. Para las retransmisiones, se computa y
gestiona una asignación de retardo. La asignación de retardo indica
la cantidad de tiempo en el cual paquetes originales de datos
pueden ser retardados sin provocar una sobrecarga de la memoria
temporal, es decir si una retransmisión particular provocará una
sobrecarga de la memoria temporal.
El diagrama de flujo ilustra una implementación
del método en el servidor. En la selección 22, un paquete de datos
es seleccionado para su retransmisión, por ejemplo de acuerdo con
una petición recibida desde el cliente. Después de la selección 22
de un paquete, una comprobación 24 opcional es llevada a cabo si la
retransmisión puede llegar al cliente antes del tiempo de
presentación requerido para la presentación planificada por la
aplicación del cliente. Preferiblemente, una retransmisión se lleva
a cabo sólo si la comprobación 24 indica que el último tiempo de
presentación es posterior al tiempo estimado para extraer la
retransmisión más el tiempo requerido para el procedimiento de
transmisión. El tiempo de presentación puede ser indicado en la
petición de retransmisión o puede ser determinado de acuerdo con la
información de presentación en el emisor mientras que el valor del
tiempo requerido para la transmisión puede ser estimado, por ejemplo
como la mitad del tiempo de ida y vuelta entre el cliente y el
servidor medido, o puede ser pre-configurado. Si la
retransmisión no llega a tiempo, el tratamiento para el paquete
seleccionado se detiene. Los recursos de transmisión pueden ser
entonces usados para otros paquetes en el mismo flujo, sobre todo
nuevos paquetes originales de datos, o pueden ser usados por otros
emisores que comparten los mismos recursos.
Para el paquete de datos seleccionado, se lleva
a cabo una determinación 26 del requisito de retardo para la
retransmisión. En la realización de la fig. 3, subsiguientemente
sigue un procedimiento de actualización 28 de la asignación de
retardo. En el procedimiento de actualización 28, se calcula una
nueva asignación de retardo de acuerdo con los tiempos de
presentación de los siguientes paquetes de datos no enviados y con
la velocidad de datos máxima como se describe con más detalle a
continuación. Después del procedimiento de actualización 28, se
ejecuta una comparación 30 de la asignación de retardo y del
requisito de retardo. Si la asignación de retardo es al menos igual
al requisito de retardo, es decir suficiente para la retransmisión,
se llevan a cabo una iniciación 32 de la retransmisión y una
reducción 34 de la asignación de retardo mediante el requisito de
retardo del paquete de datos retransmitido. Si no el proceso es
detenido sin retransmisión. El tiempo de iniciación 32 puede ser
diferente de la transmisión real del paquete de datos seleccionado,
por ejemplo de la planificación de otros paquetes de datos.
Cualquier nuevo cálculo de la asignación de
retardo requiere un considerable esfuerzo de tratamiento. En una
alternativa ventajosa al método representado en la fig. 3, se lleva
a cabo una primera comparación entre la asignación de retardo y el
requisito de retardo antes de un procedimiento de actualización de
la asignación de retardo. Si la última asignación de retardo
calculada es al menos igual al requisito de retardo, es decir aún
suficiente para la retransmisión, el procedimiento de actualización
28 es omitido y la iniciación 32 de la retransmisión así como la
correspondiente reducción 34 de la asignación de retardo se lleva a
cabo inmediatamente. Si la asignación de retardo es menor que el
requisito de retardo, el procedimiento de actualización 28 es
ejecutado y se lleva a cabo otra comparación 30 de la asignación de
retardo. La retransmisión se inicia u omite entonces de acuerdo con
el resultado de la otra comparación. A pesar de la repetida
comparación de la asignación de retardo, esta implementación es más
eficiente en la mayoría de los casos porque la citada comparación
requiere un bajo esfuerzo de tratamiento.
Aparte del procedimiento de actualización 28,
debe observarse que también la secuencia de algunas otras etapas
del método anterior puede ser alterada. Por ejemplo la secuencia de
iniciación 32 y de reducción 34 puede ser revertida, o la
determinación 26 del requisito de retardo puede ser llevada a cabo
en cualquier momento hasta que se ejecuta la comparación 30.
Además, aunque el diagrama de flujo describe el tratamiento para un
único paquete de datos, es a menudo más preferible seleccionar más
de un paquete de datos en la etapa 22. En este caso, las etapas del
método deben ser repetidas para cada paquete de datos excepto el
procedimiento de actualización 28, que es preferiblemente repetido
sólo cuando una comparación 30 no permite una retransmisión.
Como alternativa a una implementación en el
servidor como se describe en la fig. 3, el método puede ser
implementado también en el cliente si la información necesaria para
calcular la asignación de retardo es transmitida al cliente. En
este caso, el cliente compara la asignación de retardo con el
requisito de retardo antes de solicitar una retransmisión desde el
servidor. Si una retransmisión provocase una futura sobrecarga de la
memoria temporal, la petición de retransmisión es cancelada, es
decir la petición no es enviada o la petición es omitida a partir
de un mensaje que solicita varios paquetes. Una implementación en el
cliente tiene la ventaja de una reducida complejidad en el
servidor, que generalmente trata muchos flujos de datos en paralelo
y por lo tanto típicamente tiene una carga de tratamiento mucho
mayor. Además se envía menos tráfico en la dirección de enlace
ascendente desde el cliente al servidor puesto que se evitan
innecesarias peticiones de retransmisión. Un inconveniente de esta
solución es la transmisión de información hasta el cliente
requerida, que necesita ser realizada al menos en parte antes del
inicio de la transmisión de paquetes de datos. Esto puede aumentar
los retardos de establecimiento de sesión. Además, se requieren
extensiones a protocolos existentes para permitir la transmisión de
tal información. La alternativa más ventajosa depende por lo tanto
del protocolo y de la implementación.
Una parte central del método propuesto es
computar la asignación de retardo. Con respecto a las figuras 4 y
5, se describe un ejemplo preferible para el cómputo de la
asignación del retardo de retransmisión. En la descripción, se
asume que un flujo es codificado a una velocidad variable y
transmitido a una velocidad constante sobre un enlace de cuello de
botella mientras que el tamaño de la memoria temporal del cliente es
limitado.
La transmisión de un flujo de paquetes requiere
una planificación de los paquetes de datos, lo que asegura que ni
la velocidad de datos del enlace de cuello de botella ni el tamaño
de la memoria temporal del cliente se exceden. Típicamente, el
tamaño de los paquetes de datos puede variar. La ecuación (1)
especifica el tiempo t_{n} en el cual un paquete original de
datos n puede ser enviado. t_{n} es determinado por el tiempo
t_{n-1} en el cual los paquetes de datos
originales previos fueron enviados, por la velocidad de datos R del
enlace de cuello de botella en bits por segundo, y por el tamaño
s_{n-1} del paquete previo en bytes, asumiendo 8
bits en un byte, como
\delta es una función del tamaño de la memoria
temporal y designa el tiempo de espera requerido para evitar una
sobrecarga de la memoria temporal. Durante el tiempo de espera
\delta, los datos necesitan ser planificados a una velocidad
menor que R. Si este no es el caso, es decir si 2
la memoria temporal del cliente excede su máximo a menos que los
paquetes de datos sean retardados o extraídos.
Un ejemplo para este caso se representa en la
Fig. 4 que muestra los datos acumulados a lo largo del tiempo con
la línea de presentación 11' y el límite superior 12' de la memoria
temporal como se describe con respecto a la figura 2. Cuando en el
tiempo t_{n-1}, se transmiten datos a la capacidad
límite, el límite superior de la memoria temporal 12' se excederá
partiendo del punto 15 como se indica por la línea discontinua 16.
Por lo tanto, la planificación del siguiente tiempo de transmisión
t_{n} es desplazada al tiempo t_{n-1} +
\delta, es decir la función max en la ecuación (1) selecciona el
máximo de 3 y S.
Un cómputo de una nueva asignación de retardo en
un tiempo t_{s} dado requiere un análisis del comportamiento
futuro de la presentación, es decir de la línea de presentación, en
comparación con la máxima velocidad de datos del enlace de cuello
de botella. El análisis es posible puesto que toda la información
relevante está disponible desde la aplicación de la transmisión en
directo o en tiempo real, en particular el último tiempo de
presentación de los paquetes originales de datos subsiguientes. Un
nuevo cómputo de la asignación de retardo es necesario y cuando la
asignación de retardo real no es suficientemente grande para
permitir retransmisiones del paquete de datos faltantes o
erróneas.
Con respecto a la fig. 5, el cómputo de la
asignación de retardo para un tiempo t_{s} específico es explicado
con más detalle. La asignación de retardo en el tiempo t_{s}
asume un plan de velocidad de transmisión máxima 41, que planifica
los datos a la máxima velocidad del enlace de cuello de botella. El
plan de velocidad de transmisión máxima 41 es entonces insertado en
el gráfico de manera que toca la línea de presentación de arriba
sin cortarla. En la fig. 5 este es el caso en el tiempo t_{c}. La
distancia horizontal entre el plan de transmisión original 43 en
t_{s} y el plan de velocidad de transmisión máxima 41 es la
asignación de retardo DB mediante la cual el plan de transmisión
real puede ser retardado en el tiempo sin provocar en un futuro una
sobrecarga de la memoria temporal.
Si la velocidad de transmisión presente es
inferior a la velocidad máxima, se requiere una actualización de la
asignación de retardo. Por ejemplo, entre los tiempos t_{s} y
t_{1}, la asignación de retardo disminuye comparada con t_{s}
puesto que los datos son transmitidos a una velocidad inferior a la
velocidad de datos máxima para evitar una sobrecarga de la memoria
temporal del cliente, que ya está llena hasta el límite superior.
Por lo tanto, en esta región la asignación de retardo necesita ser
actualizada de manera continua hasta que se alcanza una asignación
de retardo reducida DB' en el tiempo t_{i}. En contraste, entre
los tiempos t_{1} y t_{2} la asignación de retardo DB'
permanece constante puesto que el plan de transmisión original 43
envía datos a la velocidad de datos máxima para llenar el espacio
de memoria temporal libre mediante la velocidad de presentación que
excede la velocidad de transmisión máxima en el intervalo anterior
t_{c}. De manera correspondiente, la distancia entre el plan de
transmisión original 43 y el plan de transmisión de velocidad
máxima 41 es constante. Entre t_{2} y t_{e} la asignación de
retardo necesita ser actualizada de nuevo de manera continua puesto
que también en esta región el plan de transmisión original no está
transmitiendo a toda la velocidad. El procedimiento de
actualización reduce la asignación de retardo real en la diferencia
entre la velocidad de transmisión real y máxima multiplicada por la
duración de la menor velocidad de transmisión.
Debe observarse que reducciones de la asignación
de retardo calculada después del tiempo t_{2} resultan del hecho
de que se evita un nuevo cálculo de la asignación para ahorrar el
esfuerzo de tratamiento requerido. La asignación de retardo real
aumenta de nuevo después del tiempo t_{c} porque la velocidad de
presentación es menor que la velocidad de transmisión máxima. Si,
después del tiempo t_{c}, la retransmisión de un paquete de datos
requiere una asignación de retardo mayor que la asignación de
retardo DB' calculada puede llevarse a cabo un nuevo cálculo de la
asignación de retardo como se describe para t_{s}. Esto aumenta la
asignación de retardo hasta el valor presente real.
Más formalmente, se requiere una actualización
de la asignación de retardo en el tiempo t_{n-1}
si 4 con las variables como las definidas con
respecto a la ecuación (1). En este caso, la asignación de retardo
actualizada es
Después de que se ha enviado una retransmisión,
la asignación de retardo necesita ser reducida mediante el retardo
provocado por la retransmisión, es decir mediante el requisito de
retardo. Si s_{r} designa el tamaño del paquete retransmitido, el
requisito de retardo para la retransmisión es 6 y
la asignación de retardo necesita ser actualizada de acuerdo
con
Cuando el plan de transmisión 41 a la velocidad
máxima interseca al límite superior de la memoria temporal 44 en el
tiempo t_{e}, el cálculo de la asignación de retardo puede ser
detenido. Cualquier paquete de datos, que es transmitido después de
t_{e} puede no influir en la asignación de retardo porque la
memoria temporal limitada no permite un mayor nivel de memoria
temporal.
Simulaciones del método propuesto han sido
llevadas a cabo con un flujo de video codificado a velocidad
variable que tiene una velocidad de datos media de 59 kbps y una
velocidad de enlace de cuello de botella de 65 kbps para un tamaño
de la memoria temporal del cliente de 32 Kbytes y un tiempo de
almacenamiento en la memoria temporal inicial de 1.7 sec. Se ha
asumido un tiempo de ida y vuelta de red de 400 ms. Los parámetros
permiten una realización uniforme de la aplicación en condiciones
de operación habituales.
La tabla compara el mecanismo de retransmisión
propuesto comparado con un método de acuerdo con el estado de la
técnica. En ambos casos 78 de 782 paquetes transmitidos se
perdieron, correspondiendo a una probabilidad de pérdida de
paquetes de aproximadamente 10%.
El mecanismo de retransmisión de acuerdo con el
estado de la técnica retransmite 47 de los 78 paquetes perdidos,
llegando todos ellos al cliente a tiempo. Los paquetes restantes no
son retransmitidos puesto que llegarían demasiado tarde. No
obstante, puesto que la auto-congestión no se tiene
en cuenta, 51 paquetes originales del flujo de datos llegan al
cliente demasiado tarde, siendo retardados por las retransmisiones.
Los paquetes retardados no pueden ser usados para la presentación y
son extraídos.
El presente método retransmite 45 de los
paquetes perdidos, llegando todos ellos a tiempo. Debido al análisis
del impacto de las retransmisiones en el comportamiento futuro de
la presentación, ningún paquete de los datos originales es
retardado más allá del tiempo de presentación, debe observarse que
el número de retransmisiones sólo es marginalmente menor comparado
con el estado de la técnica porque se evitan totalmente
transmisiones innecesarias de paquetes originales. Como resultado,
sólo un total de 33 paquetes de datos se pierden para la aplicación
mientras que el estado de la técnica 82 paquetes, es decir 51
paquetes originales retardados y 31 retransmisiones retardadas, se
pierden para la aplicación.
Claims (13)
-
\global\parskip0.950000\baselineskip
1. Un método para la transmisión de una pluralidad de paquetes de datos desde un emisor (1) a un receptor (2), en el que la transmisión de datos se lleva a cabo sobre un enlace (5) con una capacidad de transmisión que tiene un límite, y se define un tiempo de presentación para un primer paquete de datos de la citada pluralidad, y en el que el receptor (2) lleva a cabo una primera comprobación de si los paquetes de datos se reciben correctamente y al menos un paquete de datos es seleccionado para su retransmisión de acuerdo con el resultado de la primera comprobación, caracterizado porquese determina una asignación de retardo (DB) a partir del tiempo de presentación del primer paquete de datos, en el que la asignación de retardo puede ser atribuida a retransmisiones sin retardar el primer paquete de datos más allá del tiempo de presentación,se determina un requisito de retardo para la retransmisión del paquete de datos seleccionado a partir del límite de la capacidad de transmisión y a partir de la capacidad de transmisión requeridos para el paquete de datos seleccionado.se lleva a cabo una comparación (30) del requisito de retardo con la asignación de retardo (DB),y se ejecuta la retransmisión para el paquete de datos seleccionado de acuerdo con el resultado de la comparación (30). - 2. El método de acuerdo con la reivindicación 1, en el que el receptor almacena paquetes de datos en una memoria temporal (BU) con un nivel de llenado de la memoria temporal y en el que el retardo-asignación (DB) es una función del nivel de llenado de la memoria temporal.
- 3. El método de acuerdo con la reivindicación 1 ó 2, en el que la asignación de retardo (DB) es determinada para un grupo que comprende al menos dos primeros paquetes de datos.
- 4. El método de acuerdo con la reivindicación 3, en el que los primeros paquetes de datos son transmitidos en una secuencia predefinida y esos paquetes de datos son seleccionados para el grupo, que son los siguientes paquetes de datos para su transmisión en la citada secuencia, y en el que la selección de paquetes de datos para el grupo se detiene si la asignación de retardo (DB) permanece constante para otros paquetes seleccionados.
- 5. El método de acuerdo con cualquier reivindicación precedente, en el que el receptor (1) solicita los paquetes de datos seleccionados en un mensaje de estado.
- 6. El método de acuerdo con cualquier reivindicación precedente, en el que la asignación de retardo (DB) se reduce mediante el requisito de retardo si se lleva a cabo una retransmisión.
- 7. El método de acuerdo con la reivindicación 6, en el que se lleva a cabo otra comparación de la asignación de retardo con otro requisito de retardo antes de otro cálculo de la asignación de retardo desde los tiempos de presentación de los primeros paquetes de datos.
- 8. El método de acuerdo con la reivindicación 6 ó 7, en el que la asignación de retardo (DB) es adaptada si una velocidad presente de la transmisión de datos es inferior al límite de la capacidad de transmisión de datos.
- 9. El método de acuerdo con cualquier reivindicación precedente, en el que se atribuye una prioridad a un paquete de datos primero o seleccionado y en el que la retransmisión es ejecutada de acuerdo con la citada prioridad.
- 10. El método de acuerdo con cualquier reivindicación precedente, en el que un tiempo de presentación para el paquete de datos seleccionado es comparado con un tiempo de llegada estimado del paquete de datos seleccionado en el receptor en otra comprobación (24), y en el que la retransmisión del paquete de datos seleccionado es llevada a cabo de acuerdo con el resultado de la otra comprobación (24).
- 11. Un emisor (1) para la transmisión de una pluralidad de paquetes de datos a un receptor (2), en el que el emisor (1) tiene una unidad de transmisión adaptada para llevar a cabo la transmisión de datos sobre un enlace (5) con una capacidad de transmisión que tiene un límite, una unidad de recepción adaptada para recibir una indicación de si los paquetes de datos son correctamente recibidos por el receptor (2), y una unidad de tratamiento (PS) adaptada para definir un tiempo de presentación para un primer paquete de datos de la citada pluralidad, y para seleccionar al menos un paquete de datos para su retransmisión de acuerdo con la indicación, caracterizado porquela unidad de tratamiento (PS) está adaptada para determinar una asignación de retardo (DB) a partir del tiempo de presentación del primer paquete de datos, en el que la asignación de retardo puede ser atribuida a retransmisiones sin retardar el primer paquete de datos más allá del tiempo de presentación,la unidad de tratamiento (PS) está adaptada para determinar un requisito de retardo para la retransmisión del paquete de datos seleccionado a partir del límite de la capacidad de transmisión y a partir de la capacidad de transmisión requerida para el paquete de datos seleccionado,
\global\parskip1.000000\baselineskip
la unidad de tratamiento (PS) está adaptada para llevar a cabo una comparación (30) del requisito de retardo y la asignación de retardo,y la unidad de tratamiento (PS) está adaptada para iniciar la retransmisión para el paquete de datos seleccionado de acuerdo con el resultado de la comparación (30). - 12. Un receptor (2) para la recepción de una pluralidad de paquetes de datos desde un emisor (1), en el que el receptor (2) tiene una unidad de recepción adaptada para recibir los paquetes de datos sobre un enlace (5) con una capacidad de transmisión que tiene un límite, una unidad de transmisión adaptada para enviar una indicación de si los paquetes de datos son correctamente recibidos, y una unidad de tratamiento (PR) adaptada para definir un tiempo de presentación para un primer paquete de datos de la citada pluralidad y para llevar a cabo una comprobación, si los paquetes de datos son correctamente recibidos y para seleccionar al menos un paquete de datos para la indicación de acuerdo con el resultado de la citada comprobación, caracterizado porquela unidad de tratamiento (PR) está adaptada para determinar una asignación de retardo (DB) a partir del tiempo de presentación del primer paquete de datos, en el que la asignación de retardo puede ser atribuida a las retransmisiones sin retardar el primer paquete de datos más allá del tiempo de presentación,la unidad de tratamiento (PR) está adaptada para determinar un requisito de retardo para la retransmisión del paquete de datos seleccionado a partir del límite de la capacidad de transmisión y a partir de la capacidad de transmisión requerida para el paquete de datos seleccionado,la unidad de tratamiento (PR) está adaptada para llevar a cabo una comparación (30) del requisito de retardo y la asignación de retardo (DB),y la unidad de tratamiento (PR) está adaptada para seleccionar el paquete de datos para la indicación de acuerdo con el resultado de la comparación (30).
- 13. Unidad de programación que comprende un código para llevar a cabo las etapas de un método de acuerdo con cualquiera de las reivindicaciones 1 a 10.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2002/010003 WO2004023706A1 (en) | 2002-09-06 | 2002-09-06 | Method and devices for controlling retransmissions in data streaming |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2325317T3 true ES2325317T3 (es) | 2009-09-01 |
Family
ID=31970249
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02777018T Expired - Lifetime ES2325317T3 (es) | 2002-09-06 | 2002-09-06 | Metodo y dispositivos para controlar las retransmisiones en el flujo de datos. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7707303B2 (es) |
| EP (1) | EP1535419B1 (es) |
| AT (1) | ATE431022T1 (es) |
| AU (1) | AU2002339523A1 (es) |
| DE (1) | DE60232278D1 (es) |
| ES (1) | ES2325317T3 (es) |
| WO (1) | WO2004023706A1 (es) |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100608715B1 (ko) * | 2003-09-27 | 2006-08-04 | 엘지전자 주식회사 | ＱｏＳ보장형 멀티미디어 스트리밍 서비스 시스템 및 방법 |
| US7818444B2 (en) | 2004-04-30 | 2010-10-19 | Move Networks, Inc. | Apparatus, system, and method for multi-bitrate content streaming |
| US8868772B2 (en) * | 2004-04-30 | 2014-10-21 | Echostar Technologies L.L.C. | Apparatus, system, and method for adaptive-rate shifting of streaming content |
| CA2909150C (en) | 2004-10-12 | 2017-11-07 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
| US7787366B2 (en) * | 2005-02-02 | 2010-08-31 | Interdigital Technology Corporation | Method and apparatus for controlling wireless medium congestion by adjusting contention window size and disassociating selected mobile stations |
| US8683066B2 (en) | 2007-08-06 | 2014-03-25 | DISH Digital L.L.C. | Apparatus, system, and method for multi-bitrate content streaming |
| US7903690B2 (en) * | 2005-04-28 | 2011-03-08 | Hewlett-Packard Development Company, L.P. | Method and system of sending an audio stream and a data stream |
| US8370514B2 (en) | 2005-04-28 | 2013-02-05 | DISH Digital L.L.C. | System and method of minimizing network bandwidth retrieved from an external network |
| US7965771B2 (en) * | 2006-02-27 | 2011-06-21 | Cisco Technology, Inc. | Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network |
| US8218654B2 (en) * | 2006-03-08 | 2012-07-10 | Cisco Technology, Inc. | Method for reducing channel change startup delays for multicast digital video streams |
| BRPI0709871B1 (pt) | 2006-04-12 | 2019-10-15 | Tq Delta, Llc. | Retransmissão de pacote e compartilhamento de memória |
| US20070271335A1 (en) * | 2006-05-18 | 2007-11-22 | James Edward Bostick | Electronic Conferencing System Latency Feedback |
| US8031701B2 (en) | 2006-09-11 | 2011-10-04 | Cisco Technology, Inc. | Retransmission-based stream repair and stream join |
| US7937531B2 (en) * | 2007-02-01 | 2011-05-03 | Cisco Technology, Inc. | Regularly occurring write back scheme for cache soft error reduction |
| US8769591B2 (en) * | 2007-02-12 | 2014-07-01 | Cisco Technology, Inc. | Fast channel change on a bandwidth constrained network |
| US7940644B2 (en) * | 2007-03-14 | 2011-05-10 | Cisco Technology, Inc. | Unified transmission scheme for media stream redundancy |
| GB0705325D0 (en) | 2007-03-20 | 2007-04-25 | Skype Ltd | Method of transmitting data in a communication system |
| US9686044B2 (en) * | 2007-03-27 | 2017-06-20 | Qualcomm Incorporated | Rate matching with multiple code block sizes |
| US20080253369A1 (en) * | 2007-04-16 | 2008-10-16 | Cisco Technology, Inc. | Monitoring and correcting upstream packet loss |
| FR2917937B1 (fr) * | 2007-06-25 | 2009-10-16 | Alcatel Lucent Sas | Procede de communication avec interception de messages de controle |
| JP5075536B2 (ja) * | 2007-09-03 | 2012-11-21 | 株式会社東芝 | Ｆｅｃ送信処理装置、ならびにｆｅｃ送信処理のための方法およびプログラム |
| US8787153B2 (en) * | 2008-02-10 | 2014-07-22 | Cisco Technology, Inc. | Forward error correction based data recovery with path diversity |
| JP4950938B2 (ja) * | 2008-04-24 | 2012-06-13 | 株式会社日立製作所 | データ転送方法とプロキシサーバおよびストレージサブシステム |
| EP2129130A1 (fr) | 2008-05-26 | 2009-12-02 | THOMSON Licensing | Procédé de transmission simplifié d'un flux de signaux entre un émetteur et un appareil électronique |
| US9401867B2 (en) * | 2009-01-13 | 2016-07-26 | Alcatel Lucent | Method of handling transmission of data to a mobile device through multiple channels |
| JP2011041018A (ja) * | 2009-08-11 | 2011-02-24 | Sony Corp | 情報処理装置、情報処理方法、プログラムおよび通信端末 |
| US9168946B2 (en) * | 2010-03-19 | 2015-10-27 | Javad Gnss, Inc. | Method for generating offset paths for ground vehicles |
| US9052867B2 (en) | 2010-07-08 | 2015-06-09 | International Business Machines Corporation | Feedback mechanism |
| US8560635B1 (en) * | 2011-03-30 | 2013-10-15 | Google Inc. | User experience of content rendering with time budgets |
| KR20130003544A (ko) * | 2011-06-30 | 2013-01-09 | 한국전자통신연구원 | 단말 장치들 사이의 콘텐츠 동기화 방법 및 시스템 |
| US9124482B2 (en) * | 2011-07-19 | 2015-09-01 | Cisco Technology, Inc. | Delay budget based forwarding in communication networks |
| US9307441B1 (en) * | 2013-05-24 | 2016-04-05 | Sprint Spectrum L.P. | Systems and methods of transferring information to a wireless device |
| JP6415537B2 (ja) * | 2014-03-11 | 2018-10-31 | セイコーインスツル株式会社 | 通信システム |
| KR102532645B1 (ko) * | 2016-09-20 | 2023-05-15 | 삼성전자 주식회사 | 적응적 스트리밍 서비스에서 스트리밍 어플리케이케이션으로 데이터를 제공하는 방법 및 장치 |
| US11647415B2 (en) * | 2018-06-15 | 2023-05-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Handling delay budget in a wireless communication system |
| US11601851B2 (en) | 2019-05-13 | 2023-03-07 | Qualcomm Incorporated | Early resource reservation |
| FR3100096B1 (fr) * | 2019-08-22 | 2023-07-14 | Sagemcom Broadband Sas | Systeme de restitution sonore deportee comportant un diffuseur audionumérique connecte a un recepteur audionumerique par au moins deux liaisons sans fil |
| US11589104B1 (en) * | 2022-06-17 | 2023-02-21 | Userful Corporation | Latency compensation for external networks |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5768527A (en) * | 1996-04-23 | 1998-06-16 | Motorola, Inc. | Device, system and method of real-time multimedia streaming |
| US7139241B1 (en) * | 1998-09-14 | 2006-11-21 | Optibase Ltd. | Method for preventing buffer underflow during digital transport stream transmission, multiplexing and splicing |
| IL132859A (en) * | 1999-11-10 | 2008-07-08 | Nds Ltd | Data stream processing system |
| US6700893B1 (en) * | 1999-11-15 | 2004-03-02 | Koninklijke Philips Electronics N.V. | System and method for controlling the delay budget of a decoder buffer in a streaming data receiver |
| DE60020672T2 (de) * | 2000-03-02 | 2005-11-10 | Matsushita Electric Industrial Co., Ltd., Kadoma | Verfahren und Vorrichtung zur Wiederholung der Videodatenrahmen mit Prioritätsstufen |
| US6882634B2 (en) * | 2000-04-07 | 2005-04-19 | Broadcom Corporation | Method for selecting frame encoding parameters to improve transmission performance in a frame-based communications network |
| US7016970B2 (en) * | 2000-07-06 | 2006-03-21 | Matsushita Electric Industrial Co., Ltd. | System for transmitting stream data from server to client based on buffer and transmission capacities and delay time of the client |
| US7068619B2 (en) * | 2000-08-07 | 2006-06-27 | Lucent Technologies Inc. | Radio link control with limited retransmissions for streaming services |
| US7099273B2 (en) * | 2001-04-12 | 2006-08-29 | Bytemobile, Inc. | Data transport acceleration and management within a network communication system |
| US7454527B2 (en) * | 2001-05-02 | 2008-11-18 | Microsoft Corporation | Architecture and related methods for streaming media content through heterogeneous networks |
| US7164680B2 (en) * | 2001-06-04 | 2007-01-16 | Koninklijke Philips Electronics N.V. | Scheme for supporting real-time packetization and retransmission in rate-based streaming applications |
| GB0117926D0 (en) * | 2001-07-23 | 2001-09-12 | Nds Ltd | Method for random access to encrypted content |
| US7376695B2 (en) * | 2002-03-14 | 2008-05-20 | Citrix Systems, Inc. | Method and system for generating a graphical display for a remote terminal session |
-
2002
- 2002-09-06 WO PCT/EP2002/010003 patent/WO2004023706A1/en not_active Application Discontinuation
- 2002-09-06 DE DE60232278T patent/DE60232278D1/de not_active Expired - Lifetime
- 2002-09-06 AT AT02777018T patent/ATE431022T1/de not_active IP Right Cessation
- 2002-09-06 ES ES02777018T patent/ES2325317T3/es not_active Expired - Lifetime
- 2002-09-06 US US10/526,807 patent/US7707303B2/en not_active Expired - Lifetime
- 2002-09-06 AU AU2002339523A patent/AU2002339523A1/en not_active Abandoned
- 2002-09-06 EP EP02777018A patent/EP1535419B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US7707303B2 (en) | 2010-04-27 |
| EP1535419A1 (en) | 2005-06-01 |
| AU2002339523A1 (en) | 2004-03-29 |
| ATE431022T1 (de) | 2009-05-15 |
| EP1535419B1 (en) | 2009-05-06 |
| US20060112168A1 (en) | 2006-05-25 |
| WO2004023706A1 (en) | 2004-03-18 |
| DE60232278D1 (de) | 2009-06-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2325317T3 (es) | Metodo y dispositivos para controlar las retransmisiones en el flujo de datos. | |
| US9647945B2 (en) | Mechanisms to improve the transmission control protocol performance in wireless networks | |
| US8516346B2 (en) | Packet transmission apparatus, communication system and program | |
| EP2109954B1 (en) | Ack prioritization in wireless networks | |
| US7352700B2 (en) | Methods and devices for maximizing the throughput of TCP/IP data along wireless links | |
| AU708421B2 (en) | Non-transparent data transmission in a digital telecommunications system | |
| US8730885B2 (en) | Method for improved robust header compression with low signal energy | |
| US20150163153A1 (en) | Packet aggregation | |
| US11949512B2 (en) | Retransmission of data in packet networks | |
| US20080101290A1 (en) | Apparatus for Arq Controlling in Wireless Portable Internet System and Method Thereof | |
| US20060092910A1 (en) | Method and apparatus for organizing and scheduling multimedia data transfers over a wireless channel | |
| US20090141631A1 (en) | Voice adaptive gateway pacing methods and systems for wireless multi-hop networks | |
| US20050152350A1 (en) | System and method for transmitting/receiving automatic repeat request | |
| US20060222010A1 (en) | Method of performing a layer operation in a communications network | |
| US20040105463A1 (en) | Method for enhancing transmission quality of streaming media | |
| WO2012129922A1 (zh) | 一种报文处理方法、转发设备及*** | |
| JP2002158712A (ja) | パケット・データ・システムでパケットをトンネルする方法と装置 | |
| US7355976B2 (en) | Method and apparatus for providing retry control, buffer sizing and management | |
| US20050120124A1 (en) | Streaming of media from a server to a client device | |
| JP5085821B2 (ja) | Ｉｒ機能を具備したａｒｑを用いて通信システムで情報を送信する方法 | |
| CN111092907B (zh) | 基于udp协议的数据流快速传输方法、***及介质 | |
| US20090257377A1 (en) | Reducing buffer size for repeat transmission protocols | |
| JP3802363B2 (ja) | データを分配の際の遅延時間を低減する方法と装置 | |
| JP5239477B2 (ja) | 無線基地局装置及びその通信方法 | |
| GB2414637A (en) | Data transmission method using a transmission time threshold |