ES2488846T3 - Identificación y retransmisión de partes perdidas - Google Patents

Identificación y retransmisión de partes perdidas Download PDF

Info

Publication number
ES2488846T3
ES2488846T3 ES05708197.8T ES05708197T ES2488846T3 ES 2488846 T3 ES2488846 T3 ES 2488846T3 ES 05708197 T ES05708197 T ES 05708197T ES 2488846 T3 ES2488846 T3 ES 2488846T3
Authority
ES
Spain
Prior art keywords
file
session
block
data
identifier
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.)
Active
Application number
ES05708197.8T
Other languages
English (en)
Inventor
Rod Walsh
Harsh Mehta
Igor Curcio
Toni Paila
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.)
Conversant Wireless Licensing SARL
Original Assignee
Core Wiresless Licensing SARL
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
Priority to US778926 priority Critical
Priority to US10/778,926 priority patent/US7599294B2/en
Application filed by Core Wiresless Licensing SARL filed Critical Core Wiresless Licensing SARL
Priority to PCT/FI2005/050029 priority patent/WO2005078982A1/en
Application granted granted Critical
Publication of ES2488846T3 publication Critical patent/ES2488846T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. van Duuren system ; ARQ protocols
    • H04L1/1809Selective-repeat protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/1607Details of the supervisory signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868Measures taken after transmission, e.g. acknowledgments
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0093Point-to-multipoint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/06Network-specific arrangements or communication protocols supporting networked applications adapted for file transfer, e.g. file transfer protocol [FTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer, i.e. layer seven

Abstract

Método para la entrega de archivos en un sistema con capacidad de transmisión de uno-a-muchos, comprendiendo el método: transferir uno o más bloques de datos de un archivo desde un emisor (10) a por lo menos un receptor (20); caracterizado por que comprende las etapas siguientes: identificar un bloque de datos del archivo que se espera recibir pero que no se recibe, comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende: un número de bloque; un identificador de codificación; un identificador de recursos uniforme del archivo; y unos parámetros de archivo; y retransmitir el bloque de datos identificado.

Description

15
25
35
45
55
65 E05708197
05-08-2014
DESCRIPCIÓN
Identificación y retransmisión de partes perdidas.
Campo de la invención
La presente invención se refiere en general a una tecnología y a servicios de transmisión por multidifusión y por difusión general, es decir, servicios con una fuente de datos (o emisor) y por lo menos un receptor.
Antecedentes de la invención
Para servicios de uno-a-muchos (es decir, de punto-a-multipunto) a través de sistemas tales como la multidifusión IP, la difusión general de datos IP (IPDC) y los servicios de difusión general/multidifusión multimedia (MBMS), la entrega de archivos (o entrega de medios discretos o descarga de archivos) es un servicio importante. Muchas de las características para entregar archivos a través de protocolos de punto-a-punto, tales como el protocolo de transferencia de archivos (FTP) y el protocolo de transferencia de hipertexto (HTTP), son problemáticas para escenarios de uno-a-muchos. En particular, la entrega fiable de archivos -es decir, la entrega garantizada de archivos -usando protocolos similares de uno-a-uno (es decir, de punto-a-punto), con acuse de recibo (ACK), tales como el protocolo de control de transmisión TCP, no es viable.
El Grupo de Trabajo de Transporte Fiable por Multidifusión (RMT) del Grupo de Tareas de Ingeniería de Internet (IETF) se encuentra en el proceso de normalizar dos categorías de protocolos de transporte por multidifusión a prueba de fallos. En la primera categoría, la fiabilidad se implementa a través del uso de una corrección directa de errores (FEC) (proactiva), es decir, enviando una cierta cantidad de datos redundantes que pueden ayudar a un receptor en la reconstrucción de datos erróneos. En la segunda categoría, se usa realimentación del receptor para implementar un transporte fiable por multidifusión. La Codificación Asíncrona por Capas (ALC, RFC 3450) es una instanciación de protocolo perteneciente a la primera categoría, mientras que el protocolo de Multidifusión Fiable Orientada a NACK (NORM) presenta un ejemplo de la segunda categoría. Los detalles de los protocolos ALC y NORM se describen de forma más detallada en publicaciones tituladas “Asynchronous Layered Coding (ALC) Protocol Instantiation” (RFC 3450) y “NACK-oriented Reliable Multicast Protocol” (Borrador de Internet) preparadas por el Grupo de Trabajo del IETF. El contenido de estas publicaciones se incorpora en su totalidad a la presente a título de referencia.
Las redes de acceso en las cuales se pueden usar estos protocolos incluyen, aunque sin carácter limitativo, redes inalámbricas de acceso múltiple, tales como redes de acceso por radiocomunicaciones del sistema de Servicios Universales de Telecomunicaciones para Móviles (UMTS), redes inalámbricas de área local (WLAN), redes de Radiodifusión de Vídeo Digital-Terrestre (DVB-T) y redes de Radiodifusión de Vídeo Digital por Satélite (DVB-S).
En pocas palabras, el protocolo ALC es un esquema proactivo basado en FEC que permite que receptores reconstruyan paquetes alterados o paquetes que no han sido recibidos. El protocolo ALC usa la codificación FEC sobre múltiples canales, permitiendo que el emisor envíe datos con múltiples velocidades (canales) a receptores posiblemente heterogéneos. Adicionalmente, el protocolo ALC usa un mecanismo de control de la congestión para mantener diferentes velocidades sobre canales diferentes.
El protocolo ALC es masivamente escalable en términos del número de usuarios puesto que no se requiere ninguna señalización de enlace ascendente. Por lo tanto, ninguna cantidad de receptores adicionales hace que aumente precisamente la demanda en el sistema. No obstante, el protocolo ALC no tiene una fiabilidad del 100% puesto que la recepción no está garantizada, y por lo tanto en general no se describe como robusto.
A su vez, el NORM especifica el uso de mensajes de acuse de recibo negativo (NACK) con el fin de señalizar qué paquetes de datos (o, definidos de otra manera, “bloques de datos”) que se esperaba que llegasen al receptor, no se recibieron en este último (o se recibieron incorrectamente). En otras palabras, los receptores utilizan mensajes NACK para indicar la pérdida o alteraciones de paquetes transmitidos, al emisor. Por consiguiente, un receptor que “echó en falta” algunos bloques de datos de una transmisión de datos puede enviar un mensaje NACK al emisor solicitando a este último que retransmita el bloque o bloques de datos ausentes. Opcionalmente, el protocolo NORM también permite el uso de codificación FEC a nivel de paquetes para transmisiones robustas proactivas.
La Entrega de Archivos a través de Transporte Unidireccional (FLUTE) es un protocolo de transporte de uno-amuchos que se constituye sobre bloques constructivos de FEC y ALC. Está pensada para la entrega de archivos desde emisor(es) a receptor(es) a través de sistemas unidireccionales. Dispone de especializaciones que la hacen adecuada para sistemas inalámbricos de punto-a-multipunto (multidifusión). Los detalles del protocolo FLUTE se describen más minuciosamente en la publicación titulada “FLUTE -File Delivery over Unidirectional Transport” (Borrador de Internet) preparada por el antes mencionado Grupo de Trabajo del IETF. El contenido de esta publicación se incorpora en su totalidad a la presente a título de referencia.
Los mensajes NACK no son en general específicos del NORM, sino que se pueden usar también en relación con
E05708197
05-08-2014
otros protocolos o sistemas. Cuando se usan mensajes NACK en relación con sesiones FLUTE (o en otras sesiones que usen un protocolo de capa de transporte dirigido especialmente para soportar una transmisión de uno-amuchos), la identificación de los paquetes (o bloques) perdidos es una cuestión importante. El uso de protocolos destinados a una transmisión de uno-a-uno (o de punto-a-punto), tales como el TCP, y sus métodos de acuse de
5 recibo no son necesariamente viables en este caso. Por ejemplo, el uso de métodos de acuse de recibo TCP en un sistema de uno-a-muchos produciría una cantidad considerable de tara. Por consiguiente, existe una necesidad de identificar de manera fiable los paquetes no recibidos en un escenario de uno-a-muchos de manera que se pueda llevar a cabo una re-transmisión precisa.
10 Sumario de la invención
Se ha observado que, cuando se usan mensajes NACK para transmitir datos de manera fiable a través de un canal de multi-difusión/difusión general, la identificación de los paquetes perdidos es una cuestión importante. Esto implica el mantenimiento de información referente al estado de la transmisión así como la identificación de bloques que es
15 necesario retransmitir. Se ha observado que, en términos de tiempo de respuesta, las solicitudes de NACK (enviadas por un receptor y recibidas por un emisor) se pueden dividir en 2 categorías:
a) solicitudes de NACK que son recibidas inmediatamente o poco después de la transmisión inicial, y se pueden satisfacer dentro de la misma sesión (por ejemplo, una sesión FLUTE o similar). 20
b) solicitudes de NACK que son recibidas después de la expiración de una sesión y se requiere que los datos se retransmitan a través de otra sesión. En este caso, la otra sesión puede ser o bien del mismo protocolo de punto-a-multipunto (por ejemplo, una nueva sesión FLUTE establecida después de la expiración de una sesión FLUTE antigua) o bien una sesión que use otro protocolo el cual puede ser un protocolo de punto-a
25 punto o de punto-a-multipunto (por ejemplo, FTP, HTTP, etcétera).
En los dos casos, es importante identificar de manera precisa el(los) bloque(s) a retransmitir.
Según un primer aspecto de la invención, se proporciona un método de acuerdo con la reivindicación 1.
30 Según una forma de realización, la otra información comprende un conjunto de parámetros de sesión y/o un identificador de objeto de transmisión.
Según otra forma de realización, la otra información comprende información del archivo y/o información de 35 constitución de bloques.
De acuerdo con un segundo aspecto de la invención, se proporciona un dispositivo de recepción según la reivindicación 25.
40 Según un tercer aspecto de la invención, se proporciona un dispositivo de emisión de acuerdo con la reivindicación
30.
Según un quinto aspecto de la invención, se proporciona una aplicación de software ejecutable en un dispositivo de recepción de acuerdo con la reivindicación 29.
45 De acuerdo con un sexto aspecto de la invención, se proporciona una aplicación de software ejecutable en un dispositivo de emisión según la reivindicación 31.
Las aplicaciones de software pueden ser productos de programa de ordenador, que comprenden código de 50 programa, almacenado en un soporte, tal como una memoria.
Este aspecto de la invención se puede interpretar como un aspecto independiente o como un aspecto a implementar en relación con cualquier(cualesquiera) otro(s) aspecto(s) de la invención.
55 Los intervalos de los números de bloque y los intervalos de los identificadores de codificación pueden ser contiguos
o no contiguos.
Se pueden implementar respectivamente un dispositivo de recepción, un dispositivo de emisión, un sistema y aplicaciones de software.
60 Las reivindicaciones dependientes se refieren a formas de realización de la invención. La materia en cuestión contenida en reivindicaciones dependientes referentes a un aspecto particular de la invención es aplicable también a otros aspectos de la invención.
15
25
35
45
55
65 E05708197
05-08-2014
Breve descripción de los dibujos
A continuación se describirán formas de realización de la invención, a título de ejemplo, y en referencia a los dibujos adjuntos, en los cuales:
la figura 1 muestra un dispositivo de emisión y un dispositivo de recepción en comunicación de acuerdo con una forma de realización de la invención;
la figura 2A ilustra una arquitectura de protocolos simplificada de acuerdo con una forma de realización de la invención;
la figura 2B ilustra una arquitectura de protocolos simplificada de acuerdo con otra forma de realización de la invención;
la figura 3 muestra un sistema y detalles de un dispositivo de recepción de acuerdo con una forma de realización de la invención; y
la figura 4 muestra un dispositivo de emisión según una forma de realización de la invención.
Descripción detallada
La materia en cuestión contenida en la parte introductoria de esta solicitud de patente se puede usar para sustentar la descripción detallada. En lo sucesivo, el protocolo de Entrega de Archivos a través de Transporte Unidireccional (FLUTE) se usa como ejemplo sin ninguna intención de limitar la presente invención al uso único del FLUTE. En el contexto de la presente invención es aplicable también cualquier otro protocolo adecuado con capacidad de entrega de archivos por multidifusión de uno-a-muchos.
La figura 1 muestra un dispositivo de emisión y un dispositivo de recepción en comunicación de acuerdo con una forma de realización de la invención. El dispositivo de emisión 10 es un servidor, un dispositivo basado en IP, un dispositivo de DVB, un dispositivo GPRS (o UMTS) o un dispositivo similar que, opcionalmente, puede usar una corrección directa de errores proactiva, tal como un mecanismo de ALC, para enviar bloques (o paquetes) de datos por multidifusión al dispositivo de recepción 20. El dispositivo de recepción 20 envía mensajes (o solicitudes) de acuse de recibo negativo NACK al dispositivo de emisión 10 en relación con bloques perdidos (bloques no recibidos
o recibidos incorrectamente). Como respuesta al(a los) mensaje(s) de NACK, el dispositivo de emisión 10 retransmite bloques perdidos al dispositivo de recepción 20 en una sesión FLUTE (la misma sesión que la sesión FLUTE original establecida para la transmisión original, o una sesión FLUTE subsiguiente). De manera alternativa, se puede usar una sesión que utilice un protocolo diferente al FLUTE. En ciertos contextos, a la sesión de retransmisión se le denomina sesión de reparación.
Los datos se transfieren como objetos. Por ejemplo, un archivo, una imagen JPEG, una fracción de archivo son, todos ellos, objetos. Se establece una sesión entre el dispositivo de emisión 10 y el dispositivo de recepción 20 para la entrega de archivos (o datos). Una única sesión puede incluir la transmisión de un único objeto o de múltiples objetos. Se usan diferentes identificadores para identificar los objetos y las sesiones. Cada sesión se identifica por la dirección (por ejemplo, una dirección IP) del emisor (fuente), la dirección del receptor (destino) y el identificador de sesión de transmisión (TSI) o similar. También es posible usar solamente la dirección del emisor o del receptor y el TSI. Además, el identificador de objeto de transmisión (TOI) o similar se usa para indicar el objeto al que pertenece el paquete que se está transmitiendo en una sesión particular. Por ejemplo, un dispositivo de emisión 10 podría enviar un número de archivos en la misma sesión usando un TOI de 0 para el primer archivo, 1 para el segundo y así sucesivamente.
Cada bloque de datos tiene un número denominado número de bloque fuente (SBN) o similar, el cual identifica cada bloque. Los bloques se representan por un conjunto de símbolos de codificación. A su vez, un identificador de símbolo de codificación (ESI) o similar indica cómo se generaron los símbolos de codificación transportados en la carga útil de un paquete (o bloque) de datos a partir del objeto antes mencionado (por ejemplo, archivo).
La figura 2A ilustra una arquitectura simplificada de protocolos de acuerdo con una forma de realización de la invención. Según esta forma de realización, la pila de protocolos a implementar para el dispositivo de emisión 10 y el dispositivo de recepción 20 comprende una capa de aplicación, una capa de protocolo FLUTE, capas UDP e IP y capas inferiores. La capa del protocolo FLUTE se construye por encima de la instanciación del protocolo ALC del bloque constructivo (no mostrado) del transporte de codificación por capas (LCT). También se pueden usar opcionalmente bloques constructivos de FEC. La capa del protocolo FLUTE junto con mensajes NACK está destinada a proporcionar una transmisión fiable de bloques de datos desde el dispositivo de emisión 10 al dispositivo de recepción 20. Esta arquitectura de protocolos se puede usar para la transmisión de uno-a-muchos (tanto para “primeras transmisiones” de uno-a-muchos como para retransmisiones de uno-a-muchos).
Alternativamente, en una forma de realización se puede usar una capa TCP en lugar de la capa UDP (véase la
15
25
35
45
55
65 E05708197
05-08-2014
figura 2B). Esto se aplica para el caso en el cual se usa una sesión de reparación independiente de punto-a-punto (en este caso: sesión TCP) para retransmisiones de uno-a-uno (es decir, de punto-a-punto). Posteriormente en esta descripción se presenta la descripción de diferentes métodos de retransmisión.
En lo sucesivo, se presentan diferentes casos para la identificación de un conjunto de paquetes (o bloques) perdidos por parte de un receptor. Existen dos métodos para identificar el bloque o símbolo de codificación fuente de FLUTE (y, como consecuencia, uno o una serie de paquetes):
Método de identificación A
La identificación se lleva a cabo sobre la base del SBN y el ESI, así como parámetros de sesión FLUTE (dirección de origen, dirección de destino y el TSI) y el TOI (Identificador de Objeto de Transmisión). Típicamente, es el dispositivo de emisión el que genera esta información mientras se transmiten paquetes FLUTE. La información está contenida en paquetes ALC/FLUTE.
Método de identificación B
La identificación se lleva a cabo sobre la base del SBN y el ESI, así como sobre la base del archivo (es decir, el URI del archivo entregado), de parámetros de archivo (longitud de archivo y el código de cifrado (tal como código MD5), del algoritmo de constitución de bloques usado y de los parámetros de constitución de bloques (longitud máxima del bloque fuente, longitud de los símbolos de codificación y longitud del archivo). La información se toma de una FDT (Tabla de Descripción de Archivos) o similar, la cual contiene estos parámetros/información. La información se transporta típicamente como un objeto independiente por medio de la sesión FLUTE.
Tal como puede observarse, los dos métodos de identificación A y B hacen uso de un número de bloque y de un identificador de codificación y, adicionalmente, de alguna otra información de identificación. El método de identificación A usa detalles que se pueden obtener directamente a partir de la propia sesión (en este caso: sesión FLUTE), mientras que el método de identificación B usa también otra información (por ejemplo, información sobre el archivo entregado).
Con independencia del método de identificación, existen las dos siguientes posibilidades para llevar a cabo la posterior retransmisión:
Método de retransmisión A
La sesión FLUTE para la retransmisión (la retransmisión se puede efectuar dentro de la misma sesión FLUTE (en curso) o en una sesión FLUTE independiente). El método se puede basar en una transmisión de punto-a-punto o de punto-a-multipunto.
Método de retransmisión B
Uso de una sesión aparte para la retransmisión con un método diferente al FLUTE, por ejemplo, HTTP, SMS, FTP, SAP, GPRS, etcétera. El método se puede basar en una transmisión de punto-a-punto o de punto-a-multipunto.
Por consiguiente, los dos métodos de identificación diferentes y el uso del FLUTE u otro protocolo para la retransmisión produce cuatro combinaciones diferentes para identificar y retransmitir paquetes:
1.
Identificación usando el método A y retransmisión usando el método A;
2.
Identificación usado el método B y retransmisión usando el método B;
3.
Identificación usando el método A y retransmisión usando el método B; y
4.
Identificación usando el método B y retransmisión usando el método A.
Lo anterior considera que, durante la transmisión, cada símbolo de codificación está contenido dentro de un mismo paquete. No obstante, si se incluyen múltiples símbolos de codificación dentro del mismo paquete, o si un único símbolo de codificación se reparte sobre múltiples paquetes, entonces es necesario que el símbolo de codificación (y la parte del paquete que contiene un símbolo de codificación o la serie de paquetes que contienen un único símbolo de codificación, respectivamente) sea identificado de manera apropiada.
La primera combinación (A+A) se considera útil en una situación en la que la retransmisión de paquetes se desea sobre el mismo canal, usando la misma información de emisor (o servidor) y dentro de la misma sesión FLUTE, en un espacio de tiempo breve. El emisor FLUTE puede, por ejemplo, almacenar en memoria intermedia (o almacenar temporalmente) todos los SBNs y ESI enviados en los últimos 5 minutos. Este método es aplicable si en este periodo de tiempo llega una solicitud de retransmisión (NACK).
La segunda combinación (B+B) se considera útil en una situación en la que la retransmisión es necesaria después de que haya finalizado la sesión actual, posiblemente mucho tiempo después de ella. Puesto que el almacenamiento
15
25
35
45
55
65 E05708197
05-08-2014
en memoria intermedia de toda la información de largo plazo sobre transmisiones durante la sesión podría resultar inviable para el dispositivo de emisión 10, en una forma de realización no limitativa un “servidor externo” o un servidor de reparación (o simplemente un servidor aparte (no mostrado)) se configura para almacenar en memoria intermedia la información de transmisión. Este servidor puede estar situado conjuntamente, por ejemplo, con el emisor original (por ejemplo, un servidor MBMS (Servicio de Difusión General/Multidifusión Multimedia), denominado también BM-SC (Centro de Servicios de Difusión General y Multidifusión)), o, por ejemplo, puede ser un servidor aparte dentro de la red de un operador UMTS. A continuación, este servidor puede retransmitir los paquetes perdidos en un momento posterior. Un ejemplo de esto es un servidor que retransmite paquetes perdidos a través de GPRS o UMTS por la noche, cuando el acceso GPRS (UMTS) puede ser más económico. La retransmisión también se puede iniciar justo después de que haya finalizado la sesión de transmisión, o en cualquier momento aleatorio después de la misma y antes de que los datos sean consumidos por el dispositivo de recepción 20, con el fin de evitar la sobrecarga del dispositivo de emisión 10 con solicitudes de retransmisión (NACK) procedentes de muchos dispositivos de recepción 20. La idea de disponer de un servidor de reparación aparte se aplica también a otras formas de realización.
Las siguientes etapas ilustran una forma de realización ejemplificativa de lo anterior:
1.
El dispositivo de emisión 10 transmite uno o más archivos usando una sesión FLUTE.
2.
Al final de la sesión, el dispositivo de recepción 20 envía uno o más mensaje(s) de NACK para todos los paquetes que no recibió. Este mensaje de NACK significa el inicio de una sesión nueva.
3.
El dispositivo de emisión 10 vuelve a enviar todos los datos solicitados por el dispositivo de recepción 20 en una sesión nueva.
4.
A continuación, la sesión recién creada se cierra en el dispositivo de emisión 10 y en el dispositivo de recepción 20.
Como ejemplo referente a la etapa 2 anterior, se puede usar el siguiente método para enviar NACK para datos usando un SBN y ESI específicos a través de HTTP:
http://www.3.com/greatmusic/number1.mp3?mbms-rel6-flute-repair&SBN=123;ESI=234.
En este caso, SBN y ESI son el Número de Bloque Fuente e ID de Símbolo de Codificación de las partes del archivo de las cuales se va a enviar un acuse de recibo negativo (es decir, NACK). El nombre de archivo es en este caso number1.mps y el SBN y ESI para los cuales se envía un acuse de recibo negativo son 123 y 234, respectivamente. En la anterior consulta HTTP, los campos de SBN y ESI también se pueden usar para un acuse de recibo negativo de intervalos de SBN y ESI. Por ejemplo,
http://www.3.com/greatmusic/number1.mp3?mbms-rel6-flute-repair&SBN=123&126&127;ESI=234-238.
Lo anterior es una emisión de acuse de recibo negativo para el archivo number1.mp3, el SBN 123, 126 y 127 y el ESI 234 a 238. Son posibles algunas otras combinaciones del estilo, por ejemplo:
a) SBN;ESI_list (por ejemplo, ...&SBN=123;ESI=234,236,238)
(una lista de ESI perdidos dentro del mismo SBN)
b) SBN; all_symbols (por ejemplo, ...&SBN=123)
(faltan todos los ESI pertenecientes al SBN 123)
c) intervalo-SBN; all_symbols (por ejemplo,..., &SBN=123-129)
(faltan todos los ESI pertenecientes al intervalo de SBN 123 a 129)
d) “intervalos no contiguos”
d.1) (por ejemplo,...&SBN=123;ESI=234+SBN=200;ESI=23)
(faltan el ESI 234 perteneciente al SBN 123 y el ESI 23 perteneciente al SBN 200), o
d.2) (...&SBN=123-129+SBN=200; ESI=23-59+SBN=200;ESI=101)
(faltan todos los ESI pertenecientes al intervalo de SBN 123 a 129 y todos los ESI dentro del intervalo 23 a 59 pertenecientes al SBN 200 y el ESI 101 perteneciente al SBN 200).
15
25
35
45
55
65 E05708197
05-08-2014
Es posible que un NACK contenga una solicitud de retransmisión de uno o más paquetes. Resulta más eficiente incluir todas las solicitudes de paquetes en una única solicitud de NACK si la misma se transmite de manera fiable a través del canal de la red. Si no, la totalidad los paquetes se pueden solicitar por varios NACK.
Lo siguiente describe todavía otra forma de realización de la invención para retransmitir paquetes que se han perdido durante una cierta sesión FLUTE. Esta forma de realización es independiente de las cuatro anteriores combinaciones de identificación/retransmisión.
En esta forma de realización, el contexto de la sesión FLUTE (SBN, ESI, TSI y TOI) se almacena para un uso posterior que no sea FLUTE. A continuación, este contexto se puede usar para transmitir datos usando un método que no sea FLUTE. Para implementar esto, se considera que es útil disponer de un identificador, por ejemplo, un ID de multidifusión, que identifique de manera exclusiva el “contexto de sesión”. En este caso, el “contexto de sesión” puede ser, por ejemplo, todos los identificadores de la sesión combinados para formar un identificador único correspondiente a la sesión. Debería indicarse que, aunque el método de retransmisión usado aquí es el mismo que en el método de combinación 4 descrito anteriormente, existe una diferencia con respecto al almacenamiento de información de sesión. En una forma de realización, la información de sesión la almacenan tanto el dispositivo de emisión como el dispositivo de recepción y la misma se comunica entre el dispositivo de emisión y el dispositivo de recepción fuera de una sesión FLUTE.
Según todavía otra forma de realización de la invención, el dispositivo de recepción 20, por contraposición al cálculo de los paquetes que requieren una retransmisión, calcula los intervalos de bytes (del objeto original transmitido por el dispositivo de emisión 10) que necesitan ser retransmitidos. También en esta forma de realización, en la identificación se pueden usar el SBN y el ESI. El dispositivo de recepción envía un mensaje de NACK para los intervalos de bytes no recibidos. Es posible que haya múltiples intervalos de bytes dentro del mismo paquete. Como respuesta al mensaje de NACK, el dispositivo de emisión 10 retransmite los intervalos de bytes del objeto original. En lugar de intervalos de bytes, el dispositivo de recepción 10 también puede calcular intervalos de bits así como intervalos de palabras, y solicitar su retransmisión.
En otra forma de realización de la invención, los símbolos de codificación redundantes, por contraposición a fuente, que se han perdido, de bloque(s) fuente, se identifican, y todos ellos o un subconjunto de los mismos se retransmiten. Así, los NACK enviados desde dispositivos de recepción 20 a dispositivos de emisión 10 (puede haber más de un dispositivo de emisión) se basan en símbolos redundantes. Este esquema resulta particularmente aplicable en esquemas sistemáticos de FEC en donde se transmiten únicamente “símbolos redundantes” codificados y no se retransmiten “símbolos fuente” no codificados, y, típicamente, es necesario un cierto número de umbral de símbolos de codificación redundantes de cada bloque fuente para completar los bloques fuente y así reconstruir el archivo.
Por ejemplo, en un esquema ejemplificativo de FEC, puede darse el caso de que haya 1000 símbolos transmitidos por el dispositivo de emisión, para cada bloque fuente, y el número de umbral requerido para su recepción por el dispositivo de recepción con el fin de completar (o realizar correctamente) la entrega del archivo sea exactamente
500. No obstante, en este caso ejemplificativo, el dispositivo de recepción obtiene únicamente 490 símbolos (suponiendo que faltan solamente símbolos de codificación de un único bloque fuente; si faltan símbolos de codificación de varios bloques fuente, entonces es necesario llevar a cabo el siguiente cálculo para cada bloque fuente en el que faltan símbolos). En un escenario de este tipo, existen las siguientes posibilidades que se aplican por cada bloque fuente de cada archivo:
1.
El dispositivo de recepción identifica los símbolos perdidos; el dispositivo de recepción resuelve cuántos bastan para completar el bloque; el dispositivo de recepción emite NACK para un subconjunto de los símbolos perdidos (suficiente para completarlo); el dispositivo de emisión vuelve a enviar estos símbolos,
2.
El dispositivo de recepción identifica los símbolos perdidos; el dispositivo de recepción emite NACK de todos los símbolos perdidos; el dispositivo de emisión vuelve a enviar todos estos símbolos,
3.
El dispositivo de recepción identifica los símbolos perdidos; el dispositivo de recepción emite NACK de todos los símbolos perdidos; el dispositivo de emisión resuelve cuántos son suficientes para completar el bloque; el dispositivo de emisión selecciona un subconjunto de símbolos perdidos (equivalentes a los “suficientes”); el dispositivo de emisión vuelve a enviar estos símbolos,
4.
El dispositivo de recepción acusa recibo (ACK) de los símbolos recibidos; el dispositivo de emisión identifica los símbolos perdidos; el dispositivo de emisión vuelve a enviar todos estos símbolos.
5.
El dispositivo de recepción acusa recibo ACK de los símbolos recibidos; el dispositivo de emisión identifica los símbolos perdidos; el dispositivo de emisión resuelve cuántos son suficientes para completar el bloque; el dispositivo de emisión selecciona un subconjunto de símbolos perdidos (equivalentes a los “suficientes”); el dispositivo de emisión vuelve a enviar estos símbolos.
15
25
35
45
55
65 E05708197
05-08-2014
La selección de la combinación de NACK (o ACK) de manera que, en cada NACK, se remita a más de un símbolo, a más de un bloque fuente y/o a más de un archivo, es cuestión de la optimización para cada aplicación.
La definición de “suficientes” símbolos puede ser exactamente el número requerido para completar el número de umbral (10 de entre 510 en el ejemplo anterior) especialmente cuando la reparación se puede efectuar de manera fiable a través de algunos otros medios (como el transporte TCP), o puede ser un número mayor para tener en cuenta las pérdidas en el enlace (por ejemplo, en el ejemplo anterior se perdió el 51% de los símbolos, por lo tanto si fuera a usarse nuevamente el mismo canal de comunicaciones se podría esperar algo similar, de manera que resultaría más apropiado volver a enviar 10*(100/51)=20 símbolos. Además, se puede añadir un margen de seguridad adicional (por ejemplo, para hacer frente a los errores de ráfagas), de manera que si el mismo fuera 3 símbolos, entonces se podría llevar a cabo una reparación con 23 símbolos aun cuando solamente serían necesarios 10 para “salir adelante”. Tanto este factor de multiplicación (en este caso: “100/51”) como la constante (en este caso: 3) pueden considerar una pérdida uniforme de paquetes (como en los ejemplos mencionados) o pueden depender del patrón de pérdidas de la transmisión original. Por ejemplo, un dispositivo de emisión puede analizar la distribución de símbolos perdidos y si la misma fuera no uniforme (por ejemplo, normalmente se pierden 3 símbolos consecutivos de manera aproximada por cada 20 símbolos), entonces se pueden añadir algunos (por ejemplo, 3 por cada 20 símbolos) símbolos adicionales (dando como resultado nuevamente 23 símbolos en este ejemplo).
Un ejemplo adicional sería que, después de identificar dicho número de umbral de 10 símbolos de un bloque fuente requerido para completar el archivo, el dispositivo de recepción enviase un NACK al dispositivo de emisión solicitando la retransmisión de estos 10 símbolos. El dispositivo de emisión puede volver a enviar estos símbolos en la medida en la que los mismos se han almacenado en memoria caché anteriormente o, en un método alternativo, el dispositivo de emisión lleva a cabo una repetición de la codificación FEC sobre el(los) archivo(s) y los bloques fuente correspondientes a los símbolos, y retransmite estos símbolos. Este último método permite desacoplar la funcionalidad de transmisión inicial y de servidor de reparación, y posiblemente su despliegue en equipos de servidor distintos.
Otro ejemplo adicional consistiría en que el dispositivo de recepción enviase un NACK para cada uno de los 510 símbolos perdidos (o, en una forma de realización alternativa acusase recibo de que ha recibido 490 símbolos). El dispositivo de emisión retransmite entonces únicamente los 10 símbolos perdidos o retransmite la totalidad de los 510 símbolos perdidos. La retransmisión puede ser de símbolos almacenados previamente en memoria caché o de símbolos recién codificados por FEC.
Además de la solicitud de retransmisión (o reparación), enviada desde el dispositivo(s) de recepción al dispositivo(s) de emisión, sobre la base de la identificación de símbolos, la solicitud puede especificar uno o más intervalos de bytes en el archivo, y/o sus bloques fuente. Esto es aplicable si los símbolos recibidos son suficientes para resolver los intervalos de bytes perdidos de los bloques.
Se ha descrito que la transmisión de punto-a-punto o de punto-a-multipunto se puede usar para retransmitir paquetes perdidos. Una forma de realización clarificadora se refiere a la retransmisión (o reparación) de punto-amultipunto. En esta forma de realización, cada dispositivo de recepción afectado envía un mensaje de acuse de recibo negativo (NACK) al dispositivo de emisión a través de una conexión (o sesión) de punto-a-punto. En función del número y/o del contenido de NACK recibidos en el dispositivo de emisión, este último toma una decisión:
1) si enviar el(los) bloque(s) perdido(s) por separado a cada dispositivo de recepción usando conexión(es) de punto-a-punto; o
2) si enviar el(los) bloque(s) perdido(s) usando una conexión de punto-a-multipunto (es decir, multidifusión o difusión general o similar).
Si un número elevado de dispositivos de recepción envía solicitudes de NACK relacionadas con los mismos paquetes perdidos, la segunda opción puede resultar más deseable. De esta manera, con una única retransmisión, es posible realizar reparaciones de múltiples receptores y ahorrar recursos.
La figura 3 muestra un sistema y detalles de un dispositivo de recepción de acuerdo con una forma de realización de la invención. El sistema comprende el dispositivo de emisión 10, una red de transmisión 30, por ejemplo, una red IP u otra red fija, una red inalámbrica o una combinación de una red fija y una inalámbrica (celular), etcétera, y el dispositivo de recepción 20. El dispositivo de recepción 20 puede ser un teléfono celular, un teléfono por satélite, un asistente personal digital o un dispositivo Bluetooth, un dispositivo WLAN, un dispositivo de DVB, u otro dispositivo inalámbrico similar. El dispositivo 20 incluye una memoria interna 21, un procesador 22, un sistema operativo 23, programas de aplicación 24, una interfaz de red 25 y un mecanismo de identificación y NACK 26. La memoria interna 21 da alojo al procesador 22, al sistema operativo 23 y a los programas de aplicación 24. El mecanismo de identificación & NACK 26 posibilita la identificación de paquetes de datos y la transmisión de NACK o datos al dispositivo de emisión 10 como respuesta a bloques de datos perdidos o alterados en una transmisión de datos. El
E05708197
05-08-2014
dispositivo 20 se puede comunicar con el dispositivo de emisión 10 y otros dispositivos por medio de la interfaz de red 25 y de lared30.
La figura 4 muestra un dispositivo de emisión 10 de acuerdo con una forma de realización de la invención. El
5 dispositivo de emisión 10 puede ser, por ejemplo, un servidor de red o cualquier dispositivo adecuado, destinado a la entrega de archivos (o medios). El dispositivo 10 incluye una memoria interna 11, un procesador 12, un sistema operativo 13, programas de aplicación 14, una interfaz de red 15 y un mecanismo de transmisión y retransmisión 16. La memoria interna 11 da alojo al procesador 12, al sistema operativo 13 y a los programas de aplicación 14. El mecanismo de transmisión y retransmisión 16 posibilita la transmisión de paquetes de datos y la retransmisión de
10 paquetes de datos como respuesta a NACK recibidos desde el dispositivo de recepción 20. El dispositivo 10 se puede comunicar con el dispositivo de recepción 20 y otros dispositivos por medio de la interfaz de red 15 y la red
30.
Mediante software se pueden implementar procedimientos referentes a la identificación de paquetes de datos
15 perdidos y retransmisiones de los mismos. Para implementar los procedimientos en el extremo de recepción de la sesión de transmisión se puede usar un producto de programa de ordenador que comprende código de programa almacenado en el dispositivo de recepción 20 y ejecutado en el procesador 22, mientras que, para implementar los procedimientos en el extremo de transmisión, se puede usar un producto de programa de ordenador que comprende código de programa almacenado en el dispositivo de emisión 10 y ejecutado en el procesador 12.
20 En lo sucesivo, se describen ventajas de las formas de realización de la invención. Formas de realización de la invención proporcionan una infraestructura nueva para retransmitir datos perdidos.
Tal como se ha puesto de manifiesto sobre la base de lo anterior, esta infraestructura permite la retransmisión de 25 datos ausentes en los siguientes escenarios:
• Dentro de una sesión de FLUTE, cuando la información referente a los paquetes perdidos sigue estando disponible en el dispositivo de emisión y el NACK es recibido por el dispositivo de emisión en un marco de tiempo breve.
30
• Cuando se requiere retransmitir paquetes perdidos, fuera de la sesión FLUTE original en la que los mismos se transmitieron originalmente. Esta retransmisión se puede producir usando FLUTE o utilizando otro método de transmisión.
35 Algunas de las ventajas que proporcionan formas de realización de la invención son:
• Un método de identificación de bloques (o paquetes) perdidos (contiguos o no contiguos) de manera exclusiva.
40 • Un método de identificación de bloques (o paquetes) perdidos de un (o múltiples) archivo(s) a través de la misma (o de varias) sesión(es).
• Un método de identificación y retransmisión de bloques (o paquetes) perdidos, a través de varios protocolos
de transmisión. 45
• La capacidad de retransmitir paquetes perdidos en un momento adecuado. El momento adecuado se selecciona usando varios criterios posibles (tales como ancho de banda disponible, operador más económico, etcétera).
50 • La capacidad de retransmitir los paquetes perdidos de manera fiable (si el protocolo de transporte subyacente es fiable) y con una única sesión de transferencia de reparación.
Por consiguiente, formas de realización de la invención presentan métodos para identificar y enviar mensajes de acuse de recibo negativo (NACK) por bloques ausentes ya sea dentro o ya sea fuera de una sesión de multidifusión 55 de uno-a-muchos.
Se han descrito implementaciones y formas de realización particulares de la invención. Resultará evidente para los expertos en la materia que la invención no se limita a detalles de las formas de realización antes presentadas, sino que la misma se puede implementar en otras formas de realización usando medios equivalentes y sin desviarse con
60 respecto a las características de la invención. El alcance de la invención queda únicamente limitado por las reivindicaciones de patente adjuntas.

Claims (35)

  1. 5
    15
    25
    35
    45
    55
    65 E05708197
    05-08-2014
    REIVINDICACIONES
    1. Método para la entrega de archivos en un sistema con capacidad de transmisión de uno-a-muchos, comprendiendo el método:
    transferir uno o más bloques de datos de un archivo desde un emisor (10) a por lo menos un receptor (20);
    caracterizado por que comprende las etapas siguientes:
    identificar un bloque de datos del archivo que se espera recibir pero que no se recibe, comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende:
    un número de bloque; un identificador de codificación; un identificador de recursos uniforme del archivo; y unos parámetros de archivo; y
    retransmitir el bloque de datos identificado.
  2. 2.
    Método según la reivindicación 1, en el que el grupo comprende además un conjunto de parámetros de sesión.
  3. 3.
    Método según la reivindicación 1, en el que la identificación del bloque de datos comprende identificar el bloque de datos sobre la base de un identificador de objeto de transmisión.
  4. 4.
    Método según la reivindicación 1, en el que la transferencia de uno o más bloques de datos de un archivo comprende transferir usando un protocolo basado en sesiones, dirigido a la entrega de archivos a través de un transporte unidireccional, y con capacidad de transmisión de uno-a-muchos.
  5. 5.
    Método según la reivindicación 4, en el que el uso del protocolo basado en sesiones comprende usar una entrega de archivos a través de un transporte unidireccional.
  6. 6.
    Método según la reivindicación 1, en el que el número de bloque comprende un número de bloque fuente.
  7. 7.
    Método según la reivindicación 1, en el que el identificador de codificación comprende un identificador de símbolo de codificación.
  8. 8.
    Método según la reivindicación 2, en el que el conjunto de parámetros de sesión se selecciona de entre un grupo que comprende: una dirección de origen, una dirección de destino; y un identificador de sesión de transmisión.
  9. 9.
    Método según la reivindicación 1, en el que el grupo comprende además un identificador de objeto de transmisión.
  10. 10.
    Método según la reivindicación 1, en el que el grupo comprende además información de constitución de bloques.
  11. 11.
    Método según la reivindicación 1, en el que el grupo comprende además unos parámetros de archivo, comprendiendo los parámetros de archivo por lo menos uno de entre longitud de archivo y código de cifrado.
  12. 12.
    Método según la reivindicación 1, en el que la información de constitución de bloques comprende información de constitución de bloques seleccionada de entre un grupo que comprende: un algoritmo de bloques, una longitud máxima de los bloques fuente, una longitud de los símbolos de codificación, y una longitud de los archivos.
  13. 13.
    Método según la reivindicación 1, que comprende además proporcionar una sesión entre el emisor y el receptor para la transmisión de bloques de datos usando un protocolo dirigido a la transmisión en un escenario de uno-amuchos.
  14. 14.
    Método según la reivindicación 1, en el que la retransmisión del bloque de datos identificado comprende enviar un mensaje de acuse de recibo negativo desde el receptor hasta el emisor.
  15. 15.
    Método según la reivindicación 14, en el que la transferencia de uno o más bloques de datos de un archivo desde un emisor hasta por lo menos un receptor comprende transferir uno o más bloques de datos en una primera sesión; y comprendiendo el envío de un mensaje de acuse de recibo negativo enviar un mensaje de acuse de recibo negativo que provoca que se produzca la retransmisión durante la primera sesión.
  16. 16.
    Método según la reivindicación 14, en el que la transferencia de uno o más bloques de datos de un archivo desde un emisor hasta por lo menos un receptor comprende transferir uno o más bloques de datos en una primera sesión; y comprendiendo el envío de un mensaje de acuse de recibo enviar un mensaje de acuse de recibo negativo
    10 5
    15
    25
    35
    45
    55
    65 E05708197
    05-08-2014
    que provoca que se produzca la retransmisión durante una segunda sesión.
  17. 17.
    Método según la reivindicación 16, en el que el envío de un mensaje de acuse de recibo negativo que provoca que se produzca la retransmisión durante la segunda sesión comprende enviar el mensaje de acuse de recibo negativo que provoca que se produzca la retransmisión durante una segunda sesión establecida después de la expiración de la primera sesión.
  18. 18.
    Método según la reivindicación 14, en el que el envío del mensaje de acuse de recibo negativo comprende enviar una solicitud para retransmitir uno o más bloques de datos.
  19. 19.
    Método según la reivindicación 14, en el que el envío del mensaje de acuse de recibo negativo comprende enviar el mensaje de acuse de recibo negativo al final de una sesión de transmisión, significando el mensaje de acuse de recibo negativo un inicio de una nueva sesión con el fin de llevar a cabo la retransmisión de bloques ausentes.
  20. 20.
    Método según la reivindicación 1, que comprende además almacenar un contexto de sesión para un uso posterior.
  21. 21.
    Método según la reivindicación 20, en el que el contexto de sesión comprende por lo menos uno de entre el grupo que comprende los identificadores que comprenden: un número de bloque fuente, un identificador de símbolo de codificación, un identificador de sesión de transmisión, un identificador de objeto de transmisión, y/o un identificador que identifica de manera exclusiva el propio contexto de sesión.
  22. 22.
    Método según la reivindicación 1, en el que la transferencia de uno o más bloques de datos de un archivo desde un emisor hasta por lo menos un receptor comprende transferir usando una primera entrega de archivos a través de una sesión de transporte unidireccional y la retransmisión del bloque de datos identificado comprende retransmitir usando una segunda entrega de archivos a través de una sesión de transporte unidireccional.
  23. 23.
    Método según la reivindicación 1, en el que la retransmisión del bloque de datos identificado comprende:
    enviar un mensaje de acuse de recibo negativo desde uno o más receptores al emisor a través de una sesión de punto-a-punto; y
    retransmitir el bloque de datos identificado a través de una sesión de punto-a-multipunto.
  24. 24.
    Método según la reivindicación 1, en el que la retransmisión del bloque de datos identificado comprende retransmitir usando una transmisión de punto-a-punto por unidifusión.
  25. 25.
    Dispositivo de recepción (20) para la entrega de archivos en un sistema con capacidad de transmisión de uno-amuchos, comprendiendo el dispositivo de recepción:
    unos medios para recibir uno o más bloques de datos de un archivo desde un emisor (10);
    caracterizado por que comprende:
    unos medios para identificar un bloque de datos del archivo que se espera recibir pero que no se recibe, comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende:
    un número de bloque; un identificador de codificación; un identificador de recursos uniforme del archivo; y unos parámetros de archivo; y
    unos medios para provocar la retransmisión del bloque de datos identificado.
  26. 26.
    Dispositivo de recepción según la reivindicación 25, en el que el grupo comprende además un conjunto de parámetros de sesión.
  27. 27.
    Dispositivo de recepción según la reivindicación 25, en el que el grupo comprende además un identificador de objeto de transmisión.
  28. 28.
    Dispositivo de recepción según la reivindicación 25, en el que el grupo comprende además información de constitución de bloques.
  29. 29.
    Soporte de memoria legible por ordenador que comprende código de programa que se puede hacer funcionar, cuando es ejecutado por un procesador en un dispositivo de recepción (20) para la entrega de archivos en un
    11 E05708197
    05-08-2014
    sistema con capacidad de transmisión de uno-a-muchos, para: recibir uno o más bloques de datos de un archivo desde un emisor (10); 5 y caracterizado por que se puede hacer funcionar para identificar un bloque de datos del archivo que se espera recibir pero que no se recibe, comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende: 10 un número de bloque; un identificador de codificación; un identificador de recursos uniforme del archivo; y parámetros de archivo; y 15 provocar la retransmisión del bloque de datos.
  30. 30. Dispositivo de emisión (10) para la entrega de archivos en un sistema con capacidad de transmisión de uno-amuchos, comprendiendo el dispositivo de emisión:
    20 unos medios para transmitir uno o más bloques de datos de un archivo a por lo menos un receptor (20);
    caracterizado por que comprende:
    unos medios para identificar un bloque de datos del archivo que se espera recibir pero que no se recibe,
    25 comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende:
    un número de bloque;
    30 un identificador de codificación; un identificador de recursos uniforme del archivo; y unos parámetros de archivo; y
    unos medios para retransmitir el bloque de datos identificado. 35
  31. 31. Soporte de memoria legible por ordenador, que comprende código de programa que se puede hacer funcionar, cuando es ejecutado por un procesador en un dispositivo de emisión (10) para la entrega de archivos en un sistema con capacidad de transmisión de uno-a-muchos, para:
    40 transmitir uno o más bloques de datos de un archivo a por lo menos un receptor (20);
    y caracterizado por que se puede hacer funcionar para
    retransmitir un bloque de datos del archivo que se espera recibir pero no se recibe, en donde el bloque de datos 45 se identifica sobre la base del grupo que comprende un número de bloque, un identificador de codificación, un identificador uniforme de recursos del archivo y parámetros de archivo.
  32. 32. Sistema con capacidad de transmisión de uno-a-muchos, comprendiendo el sistema:
    50 el dispositivo de recepción según cualquiera de las reivindicaciones 25 a 28; y el dispositivo de emisión según la reivindicación 30.
  33. 33. Sistema según la reivindicación 32, en el que la información de archivo comprende un conjunto de parámetros de
    sesión y un identificador de objeto de transmisión. 55
  34. 34. Sistema según la reivindicación 32, en el que la información de archivo comprende un identificador de objeto de transmisión.
  35. 35. Sistema según la reivindicación 32, en el que la información de archivo comprende información de constitución 60 de bloques.
    12
ES05708197.8T 2004-02-13 2005-02-11 Identificación y retransmisión de partes perdidas Active ES2488846T3 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US778926 2004-02-13
US10/778,926 US7599294B2 (en) 2004-02-13 2004-02-13 Identification and re-transmission of missing parts
PCT/FI2005/050029 WO2005078982A1 (en) 2004-02-13 2005-02-11 Identification and re-transmission of missing parts

Publications (1)

Publication Number Publication Date
ES2488846T3 true ES2488846T3 (es) 2014-08-29

Family

ID=34838272

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05708197.8T Active ES2488846T3 (es) 2004-02-13 2005-02-11 Identificación y retransmisión de partes perdidas

Country Status (14)

Country Link
US (1) US7599294B2 (es)
EP (2) EP1714415B1 (es)
JP (1) JP4357535B2 (es)
KR (1) KR100855386B1 (es)
CN (1) CN1918841B (es)
AU (1) AU2005212895A1 (es)
BR (1) BRPI0507557A (es)
CA (3) CA2553069C (es)
ES (1) ES2488846T3 (es)
MY (1) MY143914A (es)
SG (1) SG149868A1 (es)
TW (1) TWI312622B (es)
WO (1) WO2005078982A1 (es)
ZA (1) ZA200607568B (es)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
US9015564B2 (en) * 2009-08-19 2015-04-21 Qualcomm Incorporated Content delivery system with allocation of source data and repair data among HTTP servers
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
EP1552617A2 (en) 2002-10-05 2005-07-13 Digital Fountain, Inc. Systematic encoding and decoding of chain reaction codes
CN101834610B (zh) 2003-10-06 2013-01-30 数字方敦股份有限公司 通过通信信道接收从源发射的数据的方法和装置
EP1716665B1 (en) * 2004-02-18 2009-05-27 Telefonaktiebolaget LM Ericsson (publ) Method and device for reliable broadcast
US20050223098A1 (en) * 2004-04-06 2005-10-06 Matsushita Electric Industrial Co., Ltd. Delivery mechanism for static media objects
WO2005112250A2 (en) 2004-05-07 2005-11-24 Digital Fountain, Inc. File download and streaming system
GB2419975A (en) * 2004-11-09 2006-05-10 Nokia Corp Auxiliary content handling
US8806435B2 (en) * 2004-12-31 2014-08-12 Intel Corporation Remote logging mechanism
EP1859353A4 (en) * 2005-03-07 2012-02-22 Intel Corp SELF-ADAPTIVE MUTTON-DELAY FILE TRANSFER PROTOCOL
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
JP2009515401A (ja) * 2005-11-04 2009-04-09 ノキア コーポレイション マルチキャスト及び/又は同報肯定応答機構
EP1985021A4 (en) 2006-02-13 2013-05-29 Digital Fountain Inc CONTINUOUS TRANSMISSION AND BUFFER DELIVERY USING CONTINUOUS MONITORING OVERVIEW AND PERIODS OF PROTECTION
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US7664198B2 (en) * 2006-03-21 2010-02-16 Kyocera Corporation System and method for broadcasting data over a wireless network using rateless codes
WO2007115991A1 (en) 2006-04-11 2007-10-18 Thomson Licensing Data reception method, repair method and corresponding terminal
WO2007134196A2 (en) 2006-05-10 2007-11-22 Digital Fountain, Inc. Code generator and decoder using hybrid codes
CN100454822C (zh) * 2006-05-13 2009-01-21 华为技术有限公司 一种用于多媒体广播和组播业务中的下载分发方法
US20080101317A1 (en) * 2006-10-30 2008-05-01 Nokia Corporation System and method for providing advanced session control of a unicast session
CA2577030A1 (en) * 2007-01-31 2008-07-31 Unlimi-Tech Software Inc. Improved data transfer method, system and protocol
RU2010114256A (ru) * 2007-09-12 2011-10-20 Диджитал Фаунтин, Инк. (Us) Формирование и передача исходной идентификационной информации для обеспечения надежного обмена данными
JP2009094863A (ja) * 2007-10-10 2009-04-30 Nippon Telegr & Teleph Corp <Ntt> 高信頼マルチキャストデータ配信システム,高信頼マルチキャストデータ配信方法および高信頼マルチキャストデータ配信プログラム
JP2009135772A (ja) * 2007-11-30 2009-06-18 Oki Semiconductor Co Ltd ルータ装置
EP2109293A1 (en) 2008-04-11 2009-10-14 Thomson Licensing System and method for improving the file transmission reliability
TWI486040B (zh) * 2008-10-10 2015-05-21 Thomson Licensing 在接收器要求失落符號之方法及其接收器
CN101420317B (zh) * 2008-11-21 2011-10-26 华为终端有限公司 媒体文件录制错误的修复方法、录制终端、服务器和系统
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
CN102369521B (zh) * 2009-04-01 2014-12-17 高通股份有限公司 管理通过共享通信介质通信的节点间的传输
CN104067594A (zh) * 2011-11-01 2014-09-24 高通股份有限公司 在http服务器之间分配源数据和修复数据的内容传送系统
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US8397120B2 (en) * 2009-12-15 2013-03-12 Hong Kong Applied Science And Technology Research Institute Co. Ltd. Method of error correction for a multicast message
JP5709320B2 (ja) 2009-12-17 2015-04-30 インテル・コーポレーション 失われたデータブロックを再送するための方法、コンピューティングデバイス及びプログラム
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US8619776B2 (en) * 2010-12-20 2013-12-31 Lockheed Martin Corporation Multiprotocol offload engine architecture
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
CN102790664A (zh) * 2011-05-19 2012-11-21 昆盈企业股份有限公司 一对多无线数据传输方法及装置
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
CN103138871B (zh) * 2011-11-23 2015-09-30 毕书清 移动通讯系统中应用程序的服务器数据处理系统和方法
CN103209195A (zh) * 2012-01-11 2013-07-17 国家电网公司 数据获取方法、终端以及远端设备
US9213605B2 (en) 2012-01-23 2015-12-15 Intel Corporation IP multimedia subsystem and method for MBMS file repair using HTTP servers
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US8909605B1 (en) * 2013-02-28 2014-12-09 Emc Corporation Method and system for accelerating data movement using change information concerning difference between current and previous data movements
US9900166B2 (en) * 2013-04-12 2018-02-20 Qualcomm Incorporated Methods for delivery of flows of objects over broadcast/multicast enabled networks

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05219056A (ja) 1992-02-04 1993-08-27 Nec Corp 同報通信方式
JP3614907B2 (ja) * 1994-12-28 2005-01-26 株式会社東芝 データ再送制御方法及びデータ再送制御システム
JPH09270790A (ja) 1996-04-01 1997-10-14 N T T Data Tsushin Kk ファイル配信方法及び通信制御装置
US6148005A (en) * 1997-10-09 2000-11-14 Lucent Technologies Inc Layered video multicast transmission system with retransmission-based error recovery
US6505253B1 (en) * 1998-06-30 2003-01-07 Sun Microsystems Multiple ACK windows providing congestion control in reliable multicast protocol
US6678855B1 (en) * 1999-12-02 2004-01-13 Microsoft Corporation Selecting K in a data transmission carousel using (N,K) forward error correction
JP2002124992A (ja) 2000-08-10 2002-04-26 Kddi Corp マルチキャストによるデータファイル配信方法
DE10129777A1 (de) 2001-06-20 2003-01-02 Siemens Ag Verfahren und Vorrichtung zur Datenübertragung gemäß einem ARQ-Verfahren
CN1225860C (zh) * 2001-11-28 2005-11-02 华为技术有限公司 一种混合自动重传方法
AU2003238968A1 (en) 2002-06-11 2003-12-22 Meshnetworks, Inc. System and method for multicast media access in ad-hoc communication networks
US7430617B2 (en) * 2003-12-19 2008-09-30 Nokia Corporation Method and system for header compression
US7296205B2 (en) * 2004-02-18 2007-11-13 Nokia Corporation Data repair
US7423986B2 (en) * 2004-03-26 2008-09-09 Cisco Technology, Inc. Providing a multicast service in a communication network

Also Published As

Publication number Publication date
JP2007520961A (ja) 2007-07-26
TW200534630A (en) 2005-10-16
SG149868A1 (en) 2009-02-27
CA2851953A1 (en) 2005-08-25
TWI312622B (en) 2009-07-21
US20050182842A1 (en) 2005-08-18
MY143914A (en) 2011-07-29
JP4357535B2 (ja) 2009-11-04
CN1918841A (zh) 2007-02-21
BRPI0507557A (pt) 2007-07-03
CA2553069C (en) 2012-04-03
KR20060120248A (ko) 2006-11-24
EP1714415A1 (en) 2006-10-25
CN1918841B (zh) 2010-12-22
CA2770432A1 (en) 2005-08-25
KR100855386B1 (ko) 2008-09-04
CA2553069A1 (en) 2005-08-25
CA2770432C (en) 2014-07-29
US7599294B2 (en) 2009-10-06
EP2728783A1 (en) 2014-05-07
EP1714415B1 (en) 2014-06-04
ZA200607568B (en) 2009-04-29
AU2005212895A1 (en) 2005-08-25
WO2005078982A1 (en) 2005-08-25

Similar Documents

Publication Publication Date Title
JP6648211B2 (ja) マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置
US10034058B2 (en) Method and apparatus for distributing video
US9350488B2 (en) Content delivery system with allocation of source data and repair data among HTTP servers
JP6025880B2 (ja) データ伝送方法、装置及びシステム
EP2062384B1 (en) Retransmission-based stream repair and stream join
ES2388750T3 (es) Modo de RCL bidireccional no persistente para servicios de bajo retardo
KR101809124B1 (ko) Http 서버들을 이용하는 mbms 파일 수리를 위한 ip 멀티미디어 서브시스템 및 방법
TWI320273B (en) Method and apparatus for augmenting physical layer arq in a wireless data communication system
US20200084660A1 (en) Method and arrangement for distributing information during broadcast delivery
US6415312B1 (en) Reliable multicast for small groups
US7296204B2 (en) Error correction apparatus and method
US6577599B1 (en) Small-scale reliable multicasting
US7451381B2 (en) Reliable method and system for efficiently transporting dynamic data across a network
CN101473616B (zh) 用于可靠地传递多播数据的方法和装置
US7231404B2 (en) Datacast file transmission with meta-data retention
US6842461B2 (en) Method and apparatus for data retransmission within a communication system
US6574795B1 (en) Reliable communication of data by supplementing a unidirectional communications protocol
US8499212B2 (en) Method and apparatus for adaptive forward error correction with merged automatic repeat request for reliable multicast in wireless local area networks
US6574668B1 (en) Retransmission scheme in wireless computer networks
US7757146B2 (en) Transmission of data with forward error correction information
US8612617B2 (en) Reliable multicast transport protocol
KR101151935B1 (ko) Mbms 핸드오버 실행 방법, mbms 핸드오버 실행 장치, 컴퓨터 판독가능 저장 매체 및 mbms 핸드오버 실행 시스템
JP3796239B2 (ja) マルチキャストデータ再伝送方法及び装置
US7801069B2 (en) Distribution of packets among a plurality of nodes
US7423973B2 (en) Methods and apparatus for hybrid multicast and unicast transmissions in a data network