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 PDF

Info

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
Application number
ES02777018T
Other languages
English (en)
Inventor
Bastian Albers
Uwe Horn
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2325317T3 publication Critical patent/ES2325317T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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.
Campo técnico de la invención
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.
Antecedentes de 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.
Compendio y descripción de la invención
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.
Breve descripción de los dibujos
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
Descripción detallada de las realizaciones preferidas
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.
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
1
\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
5
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
7
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.
8
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)

  1. \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 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).
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 porque
    la 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. 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 porque
    la 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. 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.
ES02777018T 2002-09-06 2002-09-06 Metodo y dispositivos para controlar las retransmisiones en el flujo de datos. Expired - Lifetime ES2325317T3 (es)

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 (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100608715B1 (ko) * 2003-09-27 2006-08-04 엘지전자 주식회사 ＱｏＳ보장형 멀티미디어 스트리밍 서비스 시스템 및 방법
US8868772B2 (en) * 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
US7818444B2 (en) 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
EP3340511B1 (en) 2004-10-12 2022-11-30 TQ Delta, LLC Resource sharing in a telecommunications enviroment
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
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
US8683066B2 (en) 2007-08-06 2014-03-25 DISH Digital L.L.C. Apparatus, system, and method for multi-bitrate content streaming
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
AU2007257055A1 (en) 2006-04-12 2007-12-13 Aware, Inc. Packet retransmission and memory sharing
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
CN115836543A (zh) * 2020-07-17 2023-03-21 索尼集团公司 通信设备和通信方法
CN114827698B (zh) * 2022-03-22 2024-02-02 北京字跳网络技术有限公司 一种播放信息的同步方法、装置、终端设备和存储介质
US11589104B1 (en) * 2022-06-17 2023-02-21 Userful Corporation Latency compensation for external networks
CN118381839A (zh) * 2023-01-20 2024-07-23 达发科技(苏州)有限公司 计算机装置及其传输控制协议报文处理方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
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 System for data stream processing
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
EP1130839B1 (en) * 2000-03-02 2005-06-08 Matsushita Electric Industrial Co., Ltd. Method and apparatus for retransmitting video data frames with priority levels
US6988236B2 (en) * 2000-04-07 2006-01-17 Broadcom Corporation Method for selecting frame encoding parameters in a frame-based communications network
EP1182875A3 (en) * 2000-07-06 2003-11-26 Matsushita Electric Industrial Co., Ltd. Streaming method and corresponding system
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

Also Published As

Publication number Publication date
DE60232278D1 (de) 2009-06-18
WO2004023706A1 (en) 2004-03-18
EP1535419B1 (en) 2009-05-06
ATE431022T1 (de) 2009-05-15
AU2002339523A1 (en) 2004-03-29
EP1535419A1 (en) 2005-06-01
US20060112168A1 (en) 2006-05-25
US7707303B2 (en) 2010-04-27

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
CN106341738B (zh) 流媒体网络传输的带宽计算方法、服务器端和系统
US8730885B2 (en) Method for improved robust header compression with low signal energy
US20060092910A1 (en) Method and apparatus for organizing and scheduling multimedia data transfers over a wireless channel
US20150163153A1 (en) Packet aggregation
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
US20040105463A1 (en) Method for enhancing transmission quality of streaming media
EP1301041A1 (en) Video data transmission method and apparatus
WO2012129922A1 (zh) 一种报文处理方法、转发设备及系统
US20080101290A1 (en) Apparatus for Arq Controlling in Wireless Portable Internet System and Method Thereof
WO2017144643A1 (en) Retransmission of data in packet networks
US20050120124A1 (en) Streaming of media from a server to a client device
CN102160340B (zh) 传送速率控制装置和传送速率控制方法
US7355976B2 (en) Method and apparatus for providing retry control, buffer sizing and management
JP2002152311A (ja) Ｉｒ機能を具備したａｒｑを用いて通信システムで情報を送信する方法
CN111092907B (zh) 基于udp协议的数据流快速传输方法、系统及介质
CN111601343B (zh) 帧聚合方法、终端设备及计算机存储介质
JP5239477B2 (ja) 無線基地局装置及びその通信方法
US20090257377A1 (en) Reducing buffer size for repeat transmission protocols