ES2308525T3 - Mecanismo de peticion de reparacion punto a punto para sistema de transmision punto a multipunto. - Google Patents
Mecanismo de peticion de reparacion punto a punto para sistema de transmision punto a multipunto. Download PDFInfo
- Publication number
- ES2308525T3 ES2308525T3 ES05767499T ES05767499T ES2308525T3 ES 2308525 T3 ES2308525 T3 ES 2308525T3 ES 05767499 T ES05767499 T ES 05767499T ES 05767499 T ES05767499 T ES 05767499T ES 2308525 T3 ES2308525 T3 ES 2308525T3
- Authority
- ES
- Spain
- Prior art keywords
- repair
- data packets
- receiver
- data
- transmitter
- 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
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/1607—Details of the supervisory signal
- H04L1/1628—List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
-
- 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/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
- H04L1/1816—Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of the same, encoded, message
-
- 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/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
- H04L1/1819—Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of additional or different redundancy
-
- 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
-
- 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
- H04L2001/0092—Error control systems characterised by the topology of the transmission link
- H04L2001/0093—Point-to-multipoint
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Radio Relay Systems (AREA)
- Small-Scale Networks (AREA)
- Computer And Data Communications (AREA)
- Vehicle Body Suspensions (AREA)
Abstract
Un procedimiento para transmitir paquetes de datos en un sistema capaz de transmisión punto a multipunto, que comprende: - transmitir uno o más paquetes de datos desde un transmisor (4) a uno o más receptores (5-1, 5-2, 5-3); y - señalizar información de reparación a partir de al menos un receptor específico (5-1) de dichos receptores (5-1, 5-2, 5-3), en cuyo receptor específico (5-1) se requiere una recepción de paquetes de datos de reparación, a un servidor de reparación (7) con el fin de activar una transmisión de dichos paquetes de datos de reparación, caracterizado porque para una técnica de codificación de corrección de error sin vía de retorno usada para generar dichos paquetes de datos a partir de un objeto de datos que se ha de transferir entre dicho transmisor y dichos uno o más receptores, la recepción de un número mínimo de paquetes de datos es suficiente para habilitar a un receptor para que reconstruya dicho objeto de datos y porque dicha información de reparación comprende información relacionada con el número de paquetes de datos transmitidos correctamente recibidos a nivel de dicho receptor específico (5-1).
Description
Mecanismo de petición de reparación punto a
punto para sistema de transmisión punto a multipunto.
La presente invención se refiere a un
procedimiento, sistema, transmisor, elemento de red, receptor y
aplicación de software para un sistema capaz de transmisión punto a
multipunto.
Para los servicios punto a multipunto (también
denominados servicios uno a varios) sobre sistemas tales como la
multidifusión del Protocolo de Internet (IP), la Difusión de datos
IP (OPDC) y los servicios de difusión/multidifusión multimedia
(MBMS), distribución de ficheros tales, como por ejemplo, la
descarga de ficheros multimedia es un servicio importante.
Sin embargo, muchas de las características para
distribuir ficheros sobre protocolos punto a punto, tales como por
ejemplo el Protocolo de transferencia de ficheros (FTP) y el
Protocolo de transferencia de hipertexto (http), son problemáticos
para escenarios de punto a multipunto. En particular, la
distribución fiable de ficheros, es decir, la distribución
garantizada de ficheros, usando protocolos similares de
reconocimiento punto a punto (ACK) tales como el Protocolo de
control de transporte (TCP) no es factible.
La solicitud de patente internacional WO
03/105353 desvela un sistema para transmitir mensajes a múltiples
nudos de destinos, en los cuales un mensaje de un nudo fuente se
direcciona a una dirección de multidifusión/difusión, y se incluyen
las direcciones de múltiples nodos de destinos en la cabecera de
mensaje. Los nudos de destino que reciben con éxito la transmisión
calculan un intervalo de tiempo en el cual transmitir un mensaje de
reconocimiento basado en la posición de su dirección en la cabecera
de mensaje. El nudo fuente puede entonces proporcionar una
retransmisión a los nodos destino que no recibieron con éxito la
transmisión bien como una comunicación de multidifusión/difusión o
una comunicación de unidifusión dependiente de los mensajes de
reconocimiento recibidos.
El grupo de trabajo de Transporte de
multidifusión fiable (RMT) del Grupo internacional de trabajo de
ingeniería (IETF) está actualmente en proceso de estandarización de
dos categorías de protocolos de transporte multidifusión de
resiliencia de error. En la primera categoría, la fiabilidad se
lleva a cabo mediante el uso de la Corrección de error sin vía de
retorno (proactiva) (FEC), 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, la
fiabilidad se lleva a cabo mediante el uso de realimentación de
recepción.
La codificación asíncrona de capas (ALC) es una
particularización de protocolos que pertenece a la primera
categoría, mientras que el protocolo (NORM) de multidifusión fiable
orientado a NACK pertenece a la segunda categoría. Las redes de
acceso sobre las cuales estos protocolos se podrían usar incluyen,
pero no se limitan a ello, redes inalámbrica de acceso múltiple
tales como el Sistema de telecomunicaciones móviles universal
(UMTS, que incluye el sistema global para la Red de Acceso
radioeléctrico de evolución de las comunicaciones móviles (GERAN) y
la Red de acceso radio terrestre UMTS (UTRAN)), Redes inalámbricas
de área local (WLAN), redes terrestre de difusión de vídeo digital
(DVB-T) y redes de difusión de vídeo digital por
satélite (DVB-S).
En resumen, el protocolo ALC es un esquema
basado en FEC proactiva que permite que los receptores reconstruyan
paquetes mutilados o paquetes que no se han recibido. El protocolo
ALC utiliza la codificación FEC sobre múltiples canales,
permitiendo que el remitente envíe datos a múltiples velocidades
(canales) a receptores posiblemente heterogéneos. Además, el
protocolo ALC usa un mecanismo de control de congestión para
mantener diferentes velocidades sobre diferentes canales.
El protocolo ALC es masivamente escalable en
términos de números de usuarios, ya que no se requiere señalización
de enlace ascendente. Por lo tanto, cualquier cantidad de receptores
adicionales no introducirá exactamente una mayor demanda sobre el
sistema. Sin embargo, el protocolo ALC no es fiable al 100% porque
no se garantiza la recepción, por lo tanto no se le describe
generalmente como resistente.
NORM, a su vez, especifica el uso de mensajes de
reconocimiento negativo (NACK) con el fin de señalizar que paquetes
de datos con expectativas de llegar al receptor no se recibieron en
absoluto en el receptor, o se recibieron incorrectamente: Dicho de
otro modo, los receptores emplean mensajes NACK para indicar la
pérdida o el daño de paquetes de datos transmitidos al transmisor.
Por consiguiente, un receptor que hecha de menos algunos paquetes
de datos a partir de una transmisión de datos puede enviar un
mensaje NACK al transmisor (o un servidor de reparación) pidiendo
al transmisor (o servidor de reparación) que retransmita el bloque
o bloques de datos que faltan. El protocolo NORM también permite
opcionalmente el uso de FEC del nivel de paquetes de datos que
codifica transmisiones robustas proactivas.
Los mensajes NACK no son generalmente
específicos de NOTM, pero se puede usar también en combinación con
otros protocolos o sistemas, por ejemplo con sistemas que respaldan
sesiones que son controladas por el protocolo de distribución de
ficheros sobre transporte unidireccional (FLUTE).
FLUTE es un protocolo de transporte de uno a
varios que se construye sobre bloque de construcción FEC y ALC. Se
destina a la distribución de ficheros de transmisor(es) a
receptor(es) sobre sistemas unidireccionales. Tiene
especializaciones que le hace apropiado para sistema inalámbrico
punto a multipunto. Los detalles del protocolo FLUTE se mencionan
más en detalle en la publicación titulada "FLIUTE" "File
Delivery over Unidireccional Transport" (Internet Draft)
preparado por el grupo de trabajo RMT del IETF.
El uso de FLUTE está por ejemplo especificado
para el "Proyecto de colaboración de tercera generación (3GPP)
para descargar ficheros en sesiones del sistema MBMS". Se puede
haber usado o no FEC en tales sesiones FLUTE. En cualquier caso, no
todos los receptores en la sesión pueden esperar recibir la
totalidad del fichero cuando termina la sesión. Con este fin, 3GPP
es el proceso de definición de sesiones de reparación punto a
punto, en el cual se permite a los receptores señalizar peticiones
de retransmisiones de paquetes de datos a un transmisor o servidor
de reparación mediante mensajes NACK con el fin de poder reconstruir
el contenido descargado.
Cuando se usan mensajes NACK en combinación con
sesiones FLUTE (o en otras sesiones que usan un protocolo de capas
de transporte especialmente dirigido a apoyar la transmisión punto a
multipunto) la identificación de los paquetes de datos que faltan a
los receptores es una cuestión importante. El uso de protocolos
destinados a transmisión punto a punto, tales como TCP, y sus
procedimientos de reconocimiento no son necesariamente factibles en
dicho caso.
En una sesión FLUTE, se identifican objetos de
transporte, por ejemplo, ficheros multimedia o partes de los mismos
mediante un identificador de transporte (TOI), y se transmiten a
partir de un transmisor a una pluralidad de receptores dentro de
una sesión de transporte, que se identifica mediante un
Identificador de sesión de transporte (TSI). La transmisión de
dichos objetos de transporte se lleva a cabo de hecho por la
transmisión de paquete de datos FLUTE, en la cual los paquetes de
datos FLUTE contienen porciones brutas o codificadas de dicho
objeto de transporte, denominado símbolos de codificación, como
carga útil. Dichos paquetes de datos FLUTE contienen, además, el
TSI y el TOI así como un ID de carga útil de FEC, que se explicará
más adelante.
Diversos esquemas de FEC especificados por el
grupo de trabajo RMT se basan en una estructura de bloques fuente y
símbolos de codificación. Tales esquemas FEC se describen en la
publicación RFC 3452 "Forward Correction Buidlding Block" y la
publicación RFC 3695 "Compact Forward Error Correction (FEC)
Schemes". Cada símbolo de codificación se puede identificar por
su Número de bloque fuente (SBN) y su ID de símbolo de codificación
(ESI). Todos estos esquemas FEC asumen que dentro de cada objeto de
transporte, el SBN se incrementa secuencialmente por 1, y que
dentro de un bloque fuente, el ESI se incrementa por uno por cada
símbolo de codificación que se transite. Tanto SBN como ESI están
contenidos en el ID de carga útil de FEC que está contenido en un
paquete de datos FLUTE.
En estos esquemas FEC, la identificación de
paquetes de datos FLUTE que no se han recibido en absoluto o no se
han recibido correctamente en un receptor se puede llevar a cabo
mediante su SBN y ESI, que están contenido en el ID de carga útil
de FEC de los paquetes de datos FLUTE. Estos parámetros se pueden
remitir como NACK al transmisor para producir una retransmisión de
estos paquetes de datos identificados.
Sin embargo, la publicación "Simple Forward
Error Correction (FEC) Schemes" (Internet Draft) por M. Luby
Presenta esquemas FEC que usan un ID de carga útil FEC más simple y
se puede usar para distribuir objetos sin usar ninguna estructura
explicita de bloques fuente. Estos esquemas FEC puede usar por
ejemplo códigos sin tipo como Transformada de Luby (LT) o códigos
raptor.
Un codificador LT (véase M. Luby,
"LT-codes", en Proceedings of the ACM Symposium
on foundations of Computer Science (FOCS), 2002) transmite un flujo
de bits codificados, que son combinaciones lineales esparcidas
aleatoriamente de k bits de datos. El receptor toma versiones
ruidosas de los bits codificados y usa un decodificador de
propagación de coherencia para intentar descifrar los k bits de
datos. El número de n bits codificados ruidosos requeridos para la
decodificación con éxito depende de la calidad y el tipo de canal.
Los códigos LT designados que usan la "distribución de grados de
solitones robustos" se pueden llevar c a cabo sobre cada canal
binario de borrado (BEC). Dicho de otro modo, R = k/n se puede
realizar arbitrariamente cercano a (1-p) = para cada
probabilidad de borrado p.
La idea clave de la codificación raptor (véase
A. Shkrollahi, "Raptor codes", Digital Fountain, Inc, Tech.
Re.p. DF2003-06-001, Junio 2003) es
relajar la condición que todos los símbolos de entrada necesitan
recuperar. Si un código LT necesita recuperar solamente una
fracción constante de sus símbolos de entrada, entonces su gráfica
de decodificación necesita solamente tener bordes o(k), que
permiten la codificación de tiempo lineal. Todos los símbolos de
entrada se pueden recuperar todavía concatenando un código de
corrección de borrado tradicional con un código LT. Se obtiene
entonces n códigos intermedios codificando k símbolos de entrada
con un código de bloques de corrección de borrado (k, n) capaz de
recuperar todos los símbolos de entrada de una fracción fija de
símbolos intermedios. Los n símbolos intermedios se codifican
entonces con un código LT que puede recuperar de sus símbolos de
salida la fracción requerida de símbolos intermedios.
El ID de carga útil FEC propuesto para este
esquema FEC consiste en una clave de 4 bytes a partir de la cual se
genera la gráfica de decodificación. El SBN no se incluye en este ID
de carga útil FEC, y se entiende que el ESI ha de llevar un
identificador tal como dicha clave de 4 bytes en este caso.
Además las claves se generan aleatoriamente por
el codificador FEC, de este modo, el receptor no puede identificar
los paquetes de datos que faltan de las claves de los otros paquetes
de datos que ha recibido en la sesión. Por consiguiente, la
identificación de los paquetes de datos FLUTE que faltan por su SBN
y ESI asociados no se puede aplicar en estos esquemas FEC.
La patente de los Estados Unidos US 6.212.240 se
refiere a un procedimiento para transportar datos entre dispositivos
de comunicación. Un primer dispositivo de comunicación transmite
datos de usuario, divididos en una pluralidad de bloques de datos,
a una primera velocidad de modulación (por ejemplo
64-QAM). El primer dispositivo de comunicación
recibe un acuse del segundo dispositivo de comunicación que indica
una cantidad de los bloques de datos que no se recibieron y compara
esta cantidad con un umbral. Cuando la cantidad es inferior al
umbral, los bloques de datos que no se recibieron se retransmiten a
una segunda velocidad de modulación, normalmente inferior (por
ejemplo
16-QAN). En caso contrario, se retransmiten a la primera velocidad de modulación. De este modo, puesto que la primera velocidad de modulación requiere menos ancho de banda que la segunda velocidad de modulación para transmitir una cantidad equivalente de bloques de datos, reduciendo la velocidad de modulación solamente cuando la cantidad de bloques de datos a reenviar es inferior al umbral, se lleva a cabo una asignación eficaz del ancho de banda RF para transmisiones y retransmisiones de datos de usuario.
16-QAN). En caso contrario, se retransmiten a la primera velocidad de modulación. De este modo, puesto que la primera velocidad de modulación requiere menos ancho de banda que la segunda velocidad de modulación para transmitir una cantidad equivalente de bloques de datos, reduciendo la velocidad de modulación solamente cuando la cantidad de bloques de datos a reenviar es inferior al umbral, se lleva a cabo una asignación eficaz del ancho de banda RF para transmisiones y retransmisiones de datos de usuario.
A la vista de los problemas anteriormente
mencionados, existe una necesidad de un procedimiento mejorado y
dispositivos relacionados para señalizar información de reparación
en un sistema capaz de transmisión punto a multipunto.
Se propone un procedimiento para transmitir
paquetes de datos como se especifica en la reivindicación 1.
Dicho sistema puede representar cualquier
sistema inalámbrico o unido por cable, en el cual los paquetes de
datos se transmiten a partir de al menos un transmisor a uno o más
receptores. Dicha transmisión puede ser bien una transmisión
difundida, en la cual todos los receptores están direccionados por
dicho transmisor, o una transmisión multidifundida, en la cual
solamente un subgrupo de todos los receptores está direccionado por
dicho transmisor. Dicho sistema se puede, por ejemplo, desplegar en
el contexto de UMTS, LAN, WLAN, DVB-T o
DVB-S, y se puede destinar a distribuir contenido
tal como, por ejemplo, ficheros multimedia a una pluralidad de
receptores. Dicha transmisión de dicho uno o más paquetes de datos
se puede llevar a cabo sobre enlaces de transmisión
unidireccionales o bidireccionales.
Dichos paquetes de datos transmitidos se pueden,
por ejemplo, relacionar con el contenido que se ha de transferir a
dichos receptores. Este contenido se puede segmentar y procesar para
permitir la transmisión a dichos receptores, con lo cual dichos
paquetes de datos se han de entender como el resultado de esta
segmentación y procesamiento. Por ejemplo, dicho paquetes de datos
pueden ser paquetes de datos FLUTE, obteniéndose la carga útil de
los cuales por codificación FEC de un objeto de transporte, por
ejemplo un fichero multimedia. En este caso, dicha carga útil de
dicho paquete de datos FLUTE puede, por ejemplo, ser símbolos de
codificación o paquetes de codificación.
Al menos en un receptor, que se denomina
receptor específico, se requiere una recepción de paquetes de datos
de reparación, que puede ser debida a una pluralidad de razones
tales como, por ejemplo, una recepción incorrecta o la pérdida de
paquetes de datos transmitidos. Dicho receptor específico puede caer
en la cuenta de que el requisito para recibir paquetes de datos de
reparación durante dicha transmisión de paquetes de datos o después
de la transmisión de paquetes de datos se ha acabado.
Dichos paquetes de datos de reparación pueden
ser, por ejemplo, copias únicas de los paquetes de datos
transmitidos que no fueron recibidos por dicho receptor específico.
Igualmente, pueden ser diferentes tanto respecto del contenido de
codificación como del contenido efectivo. Por ejemplo, si se usa
codificación FEC de velocidad inferior, se pueden aplican
diferentes claves cuando se generan los paquetes de datos de
reparación. Los paquetes de datos de reparación sirven de este modo
para el fin de proporcionar dicho receptor específico con esa
cantidad de información requerida por dicho receptor
específico.
Con el fin de disparar una transmisión de
paquetes de datos de reparación a partir de dicho servidor de
reparación, dichos receptor específico señaliza información de
datos de reparación a dicho servidor de reparación. Esto se lleva a
cabo en una transferencia punto a punto. Esto permite entonces que
el servidor de reparación genere los paquetes de datos de
reparación apropiados y que los transmita al receptor específico.
Esta transferencia puede, por ejemplo, ser una transferencia punto
a punto.
Según la presente invención, se propone que esta
información de reparación comprenda información relacionada con una
serie de paquetes de datos transmitidos que se recibieron
correctamente por dicho receptor específico. De este modo, el
término correctamente recibido se entiende del modo que el receptor
puede usar la información contenido en dicho paquete de datos
recibidos para otro procesamiento y no tiene que desechar el paquete
de datos. Esto se puede, por ejemplo, decidir sobre la base de una
suma de control incluida en el paquete de datos. La razón
fundamental de esta propuesta es que, para algunas técnica de
codificación FEC, que se pueden usar para generar dichos paquetes
de datos a partir de un objeto de datos que se ha de transferir
efectivamente en dicha transferencia punto a multipunto entre dicho
transmisor y uno o más receptores, la recepción de un mínimo de
paquetes de datos es suficiente para habilitar que un receptor
reconstruya en sí dicho objeto de datos. Por ejemplo, si un objeto
de datos se codifica en paquetes de datos N, sólo se puede requerir
que los L < N paquetes de datos en un receptor puedan
reconstruir dicho objeto de datos. De este modo, no se puede,
además, requerir que los L paquetes de datos específicos sean
recibidos, sino solamente que los L paquetes de datos diferentes
distintos de los N paquetes de datos sean recibidos. De este modo,
para habilitar a un servidor de reparación genere paquetes de datos
de reparación, la información acerca de cuantos paquetes de datos
fueron recibidos correctamente por dicho receptor específico, en
combinación con información estructural adicional relativa a la
técnica de codificación FEC es suficiente.
A diferencia de la técnica anterior, de este
modo, ya no se ha de volver a señal una identificación exacta de
los paquetes de datos que son requerido por dicho receptor
específico, por ejemplo en términos de un SBN o un ESI relacionado
con un cierto objeto de transporte y una cierta sesión de
transporte, a dicho servidor de reparación, lo cual reduce en gran
medida el encabezado de señalización que se encuentra en las
sesiones de reparación.
Según una realización preferida del
procedimiento de la presente invención, se requieren dichos paquetes
de datos de reparación debido a la pérdida o la recepción
incorrecta de al menos uno de dichos paquetes de datos transmitidos
a dicho receptor específico.
Esto puede, por ejemplo, ser causado por
atenuaciones, retardos, distorsiones o ruido aditivo de canales de
transmisión. Igualmente, alguno de o todos dichos paquetes de datos
transmitidos pueden no haber sido recibidos en absoluto por dicho
receptor específico.
Según otra realización preferida del
procedimiento de la presente invención, dichos paquetes de datos
transmitidos se relacionan con objetos de datos. Por ejemplo,
dichos paquetes de datos pueden contener partes de dicho objeto de
datos en forma no codificada o codificada.
Según una realización preferida del
procedimiento de la presente invención, se requieren dichos paquetes
de datos de reparación para reconstruir al menos uno de dichos
objetos de datos en dicho receptor específico. Por ejemplo, se
puede dar el caso de que dicho transmisor termine la transmisión de
paquetes de datos, antes de que un receptor haya recibido todos los
paquetes de dato que requiere para reconstruir la totalidad del
objeto de transporte que está descargándose actualmente. A
continuación, los paquetes de datos que le faltan a dicho receptor
específico pueden ser paquetes de datos que no han sido
efectivamente transmitidos por dicho transmisor con
anterioridad.
Según otra realización preferida del
procedimiento de la presente invención, dichos objetos son objetos
de transporte, y dicha información de reparación comprende un
identificador de uno de dichos objetos de transporte. Dichos
objetos de transporte pueden, por ejemplo, ser ficheros (multimedia)
o partes de los mismos.
Según otra realización preferida del
procedimiento de la presente invención, dichos objetos de datos son
porciones de objetos de transporte, y dicha información comprende
un identificador de una de dichas porciones y un identificador del
objeto de transporte correspondiente. Dichos objetos de transporte
pueden, por ejemplo, ser ficheros (multimedia) que son descargados
por dichos receptores. Dichos objetos de transporte se pueden
segmentar en porciones, por ejemplo, bloques fuente de objetos de
transporte, que representan entonces dichos objetos de datos. A
partir de dichas porciones (bloques fuente), se pueden generar
entonces dichos paquetes de datos, por ejemplo, por FEC que
codifica dicho bloque fuente en paquetes de datos N. Es por lo tanto
ventajoso proporcionar un identificador de dicha porción (por
ejemplo, su SBN) y un identificador del objeto de transporte
correspondiente (por ejemplo su TOI), de manera que un servidor de
reparación, basado en la información acerca de cuantos paquetes de
datos relacionados con el bloque fuente del objeto de transporte se
reciben correctamente en dicho receptor específico, puede
determinar cuantos paquetes de datos de reparación relacionados con
dicho bloque fuente de dicho objeto de transporte necesitan ser
transmitidos a dicho receptor específico. También es posible que un
objeto de transporte se segmente en diversas estructuras compuestas
de bloques fuente, y dicho identificador de dicha porción de dicho
objeto de transporte puede entonces identificar una de dichas
estructuras compuestas de bloques fuente y el bloque fuente
contenido en las mismas.
Según otra realización preferida del
procedimiento de la presente invención, dichos objetos de transporte
están relacionados con una sesión de transporte, y dicha
información de reparación comprende un identificador de dicha
sesión de transporte. Una pluralidad de objetos de transporte se
pueden transmitir dentro de la misma sesión de transporte, y puede
haber igualmente diversas sesiones de transporte concurrentes.
Según otra realización preferida del
procedimiento de la presente invención, dicha información de
reparación comprende la serie de paquetes de datos transmitidos
recibidos correctamente por dicho receptor específico.
Según otra realización preferida del
procedimiento de la presente invención, dicha información de
reparación comprende la serie de paquetes de datos transmitidos no
recibidos correctamente por dicho receptor específico. Esta serie
de paquetes de datos no correctamente recibidos se relaciona con la
serie de paquetes de datos recibidos correctamente en la medida en
que se puede determinar a partir de dicha serie de paquetes de datos
correctamente recibidos, si, además, se conoce la serie global de
paquetes de datos transmitidos o requeridos a dicho receptor
específico.
Según otra realización preferida del
procedimiento de la presente invención, dichos paquetes de datos y
dichos paquetes de datos de reparación se generan a partir de
dichos objetos de por codificación de corrección de error sin vía
de retorno. Dichos paquetes de datos se pueden, por ejemplo, generar
codificando dicho objeto de datos completo de una vez, o
codificándolo pieza a pieza. De este modo, el término codificar se
entiende como cualquier técnica que añade redundancia a los datos
brutos con el fin de simplificar la detección y/o corrección de
degradaciones de los datos codificados debido a las degradaciones
introducidas por un canal de transmisión.
Según otra realización preferida del
procedimiento de la presente invención, dicha codificación se basa
al menos parcialmente en claves de codificación que se incluyen en
dichos paquetes de datos y paquetes de datos de reparación. Se
pueden requerir que dichas claves descodifiquen dichos paquetes de
datos. Dichas claves pueden, por ejemplo, ser claves binarias
seudo-aleatorias.
Según otra realización preferida del
procedimiento de la presente invención, dicha codificación de
corrección de error sin vía de retorno tiene la propiedad de que
solamente un subconjunto de todos los paquetes de datos
transmitidos que se relacionan con un objeto de datos se ha de
recibir correctamente por un receptor para poder reconstruir dicho
objeto de datos. Por ejemplo, Si Se generan N paquetes de datos en
el procedimiento de codificar dicho objeto de datos (o partes del
mismo) solamente se pueden requerir L < N paquetes de datos
correctamente recibidos para reconstruir dicho objeto de datos (o
las partes del mismo). Sin embargo, la recepción de paquetes de
datos adicionales puede contribuir a aumentar la calidad de la
reconstrucción.
Según otra realización preferida del
procedimiento de la presente invención, dicho servidor de reparación
determina, al menos basado parcialmente en información de
reparación señalizada, cuanto paquetes de datos de reparación se
necesitan para ser transmitidos a dicho receptor específico con el
fin de permitirle reconstruir dicho objeto de datos, genera dichos
paquetes de datos de reparación y transmite dichos paquetes de datos
de reparación al menos a dicho receptor específico. Dicha
determinación se puede, por ejemplo, basar en el número de paquetes
de datos correctamente recibidos señalizados desde el receptor
específico, la dimensión de dicho objeto de datos, por ejemplo
desde el punto de vista del número de porciones en que dicho objeto
de datos se segmenta, y parámetros como el encabezamiento de
recepción, que indica cuantos paquetes de datos sobrepasan la
cantidad mínima de paquetes de datos requeridos para una
reconstrucción apropiada del objeto de datos se debería
proporcionar al receptor.
Según otra realización preferida del
procedimiento de la presente invención dicha corrección de error sin
vía de retorno se basa al menos parcialmente en un código LT.
Según otra realización preferida del
procedimiento de la presente invención, dicha corrección de error
sin vía de retorno se basa al menos parcialmente en un código
raptor.
Según otra realización preferida del
procedimiento de la presente invención, dicha transmisión de uno o
más paquetes de datos a uno o más receptores se controla al menos
parcialmente mediante un protocolo basado en sesiones dirigido a
una transferencia punto a multipunto unidireccional.
Según otra realización preferida del
procedimiento de la presente invención, dicha transmisión de uno o
más paquetes de datos a uno o más receptores se controla al menos
parcialmente mediante el protocolo de distribución de ficheros
sobre transporte unidireccional. A continuación dichos paquetes de
datos pueden, por ejemplo, ser unidades de datos de protocolo del
protocolo FLUTE.
Según otra realización preferida del
procedimiento de la presente invención, dicha señalización de dicha
información de reparación se lleva a cabo en una sesión punto a
punto entre dicho receptor específico y dicho servidor de
reparación.
Según otra realización preferida del
procedimiento de la presente invención, dicha señalización de dicha
información de reparación se controla al menos parcialmente
mediante el protocolo de transferencia de hipertexto.
Según otra realización preferida del
procedimiento de la presente invención los procedimientos GET o POST
del protocolo de transferencia de hipertexto se usan para dicha
señalización de dicha información de reparación.
Según otra realización preferida del
procedimiento de la presente invención, dicha transmisión de dichos
paquetes de datos de reparación a partir de dicho servidor de
reparación a dicho receptor específico se lleva a cabo en una
sesión punto a punto.
Según otra realización preferida del
procedimiento de la presente invención, dicho sistema es un sistema
de difusión/multidifusión multimedia según los estándares del
proyecto de colaboración de tercera generación.
Se propone, además, un sistema para transmitir
paquetes de datos tal como se especifica en la reivindicación
20.
Se propone, además, un transmisor en un sistema
capaz de transmisión punto a multipunto tal como se especifica en
la reivindicación 22.
Dicho transmisor se puede
co-localizar con o incluso ser idéntico a dicho
servidor de reparación.
\newpage
Según una realización preferida del transmisor
de la presente invención, dichos paquetes de datos transmitidos se
relacionan con objetos de datos, que comprende, además, medios
dispuestos para generar dichos paquetes de datos a partir de dichos
objetos de datos por codificación de corrección de error sin vía de
retorno.
Se propone, además, un elemento de red en un
sistema capaz de transmisión punto a multipunto tal como se
especifica en la reivindicación 28. dicho elemento de red se puede
co-localizar con o incluso ser idéntico a dicho
transmisor, y puede, por ejemplo, ser un servidor de
reparación.
Según una realización preferida del elemento de
red de la presente invención, dichos paquetes de datos transmitidos
se relacionan con objetos de datos, dichos paquetes de datos de
reparación se generan a partir de dichos objetos de datos por
codificación de corrección de error sin vía de retorno, y dicha
codificación de corrección de error sin vía de retorno tiene la
propiedad de que solamente un subconjunto de todos los paquetes de
datos transmitidos que se relacionan con un objeto de datos se ha
de recibir correctamente por un receptor con el fin de poder
reconstruir dicho objeto de datos, y dicho elemento de red comprende
medios para determinar, al menos parcialmente basado en dicha
información de reparación señalizada, cuantos paquetes de datos de
reparación se necesitan para ser transmitidos a dicho receptor
específico con el fin de permitirle reconstruir dicho objeto de
datos, medios para generar dichos paquetes de datos de reparación, y
medios para transmitir dichos paquetes de datos de reparación al
menos a dicho receptor
específico.
específico.
Según otra realización preferida del elemento de
red de la presente invención, dichos paquetes de datos transmitidos
se relacionan con objetos de datos, y dicho elemento de red
comprende, además, medios dispuestos para generar dichos paquetes
de datos de reparación a partir de dichos objetos de datos por
codificación de corrección de error sin vía de retorno.
Se propone, además, un receptor en un sistema
capaz de transmisión punto a multipunto tal como se especifica en
la reivindicación 31.
Se propone, además, una aplicación de software
ejecutable en un receptor de un sistema capaz de transmisión punto
a multipunto tal como se especifica en la reivindicación 39.
La aplicación de software también puede ser un
producto de programa informático, que comprende un código de
programa que se almacena en un soporte, como por ejemplo, una
memoria.
Estos y otros aspectos de la invención se harán
evidentes y saldrán a la luz con referencia a las realizaciones
descritas más adelante.
En las figuras se muestra:
Figura 1: Una ilustración esquemática de la
codificación de un objeto de transporte en una serie de paquetes de
datos según la especificación del código Raptor para la descarga de
archivos MBMS.
Figura 2a: Una representación esquemática de un
sistema punto a multipunto según la presente invención, en el cual
se transmiten paquetes de datos a partir de un transmisor a una
pluralidad de receptores;
Figura 2b: Una representación esquemática de un
sistema punto a multipunto según la presente invención, en el cual
un receptor específico remite información de reparación a un
servidor de reparación.
Figura 2c: Una representación esquemática de un
sistema punto a multipunto según la presente invención, en el cual
un servidor de reparación transmite paquetes de datos de reparación
a un receptor específico; y
Figura 3: Un diagrama de flujo ejemplar de un
procedimiento para recibir paquetes de datos y paquetes de datos de
reparación en un sistema punto a multipunto según la presente
invención.
A modo de observación inicial, se debería
resaltar que el asunto objeto de la parte introductoria de esta
solicitud de patente se puede usar para apoyar esta descripción
detallada.
La presente invención propone que la información
relacionada con la serie de paquetes de datos que son recibidos
correctamente por un receptor específico en un sistema de
transmisión de paquetes de datos punto a multipunto se remita a un
servidor de reparación para activar los paquetes de datos de
transmisión o reparación que son requeridos por dicho receptor
específico. Esto permite una realimentación particularmente eficaz
de información que permite que el servidor de reparación determine
qué paquetes de datos de reparación necesitan ser transmitidos a
dicho receptor específico. Este enfoque es particularmente ventajoso
cuando dichos paquetes de datos son generados por codificación FEC
de objetos de transporte mediante códigos de velocidad inferior
tales como códigos LT o códigos raptor.
La figura 1 describe esquemáticamente la
codificación FEC de un objeto de transporte 1 de dimensión de 3 MB
(dimensión típica para descargas de ficheros MBMS) en una secuencia
de N claves de codificación 2-1 ...
2-N, en la cual esta codificación FEC corresponde a
la especificación de código Raptor para descarga de ficheros MBMS
(véase la publicación 3 GPP Tdos S4-040230 "Raptor
Code Specification form MBMS file dowload", SA4#31, Montreal,
Canada, 17-21 de mayo de 2004). Las partes de los
paquetes de codificación 3-1 ... N obtenidas por
codificación FEC (en particular, uno o más de los símbolos de
codificación 30-i) pueden entonces, por ejemplo,
servir de carga útil para paquetes de datos FLUTE, como se
mencionará más en detalle más adelante.
El objeto de transporte 1 de la figura 1, que se
puede identificar por un TOI, representa solamente uno de una
pluralidad de objetos de transporte que se transmite a partir de un
transmisor a una pluralidad de receptores, dentro de una sesión de
transmisión, que se identifica mediante un TSI. Según la figura 1,
el objeto de transmisión 1 se compone de 16 bloques fuente
10-1 ... 10-16, en el cual cada uno
de estos bloques fuente se compone de K=6144 símbolos fuente de 32
bytes, que se marcan ejemplarmente por bloques 10-1
como 100-1 ... 10-6144. Cada bloque
fuente
10-1 ... 10-16 tiene una dimensión de 32 bytes multiplicado por 6144.
10-1 ... 10-16 tiene una dimensión de 32 bytes multiplicado por 6144.
La codificación FEC de la totalidad del objeto
de transporte 1 se lleva a cabo por multiplicación de matriz del
objeto de transporte 1 con una K x N matriz, las columnas de la cual
se componen de 6144 x 1 claves de codificación binaria, en la cual
un "1" de una clave de codificación se representa
esquemáticamente como área negra y un "0" se representa
esquemáticamente como área blanca. Dicha N claves de codificación
diferentes pueden, por ejemplo representar códigos binario
seudo-aleatorios, pero también se pueden elegir más
deliberadamente.
Dicho número N de claves de codificación usadas
es superior a K y determina la cabecera de receptor. Con N
creciente, aumenta la probabilidad de reconstrucción correcta del
objeto de transporte 1 a partir del conjunto de símbolos de
codificación 3-1 ... 3-N.
Llevando a cabo la multiplicación de matriz
anteriormente descrita, se obtienen los N paquetes de
codificación
3-1 ... 3-N, en la cual el paquete de codificación es de una dimensión de 512 bytes. Se puede observar fácilmente a partir de los diferentes sombreados aplicados en los paquetes de codificación, que cada paquete de codificación se compone de 16 símbolos de codificación, respectivamente, por ejemplo paquetes de codificación 30-1 ... 30-16 para codificar el símbolo 3-1. Igualmente se puede observar que el símbolo de codificación 30-1 está influido por todos los elementos del bloque fuente 10-1, pero solamente por la clave de codificación 2-1. Igualmente, el símbolo de codificación 30-2 está influida por todos los elementos del bloque fuente 10-2 y la clave de codificación 2-1. Por lo tanto, la clave de codificación 2-1 se incluye como clave 31 en el paquete de codificación 3-1, e igualmente, las otras claves de codificación 2-1 ... 2-N se incluyen en los N paquetes de codificación 3-2 ... 3-N, respectivamente. De este modo, la inclusión no significa necesariamente que la totalidad de las claves binarias representadas en la figura 1 se incluyen en los paquetes de codificación. Es más eficaz para identificar la clave de codificación respectiva
2-1 ... 2-N por una identificación respectiva de 4 bytes, que, para el paquete de codificación 3-1 se ilustra ejemplarmente como la clave 31 en la figura 1. dicha identificación puede, por ejemplo, relacionarse con los estados de un registro de desplazamiento que es apropiado para crear la clave de codificación requerida, o similar.
3-1 ... 3-N, en la cual el paquete de codificación es de una dimensión de 512 bytes. Se puede observar fácilmente a partir de los diferentes sombreados aplicados en los paquetes de codificación, que cada paquete de codificación se compone de 16 símbolos de codificación, respectivamente, por ejemplo paquetes de codificación 30-1 ... 30-16 para codificar el símbolo 3-1. Igualmente se puede observar que el símbolo de codificación 30-1 está influido por todos los elementos del bloque fuente 10-1, pero solamente por la clave de codificación 2-1. Igualmente, el símbolo de codificación 30-2 está influida por todos los elementos del bloque fuente 10-2 y la clave de codificación 2-1. Por lo tanto, la clave de codificación 2-1 se incluye como clave 31 en el paquete de codificación 3-1, e igualmente, las otras claves de codificación 2-1 ... 2-N se incluyen en los N paquetes de codificación 3-2 ... 3-N, respectivamente. De este modo, la inclusión no significa necesariamente que la totalidad de las claves binarias representadas en la figura 1 se incluyen en los paquetes de codificación. Es más eficaz para identificar la clave de codificación respectiva
2-1 ... 2-N por una identificación respectiva de 4 bytes, que, para el paquete de codificación 3-1 se ilustra ejemplarmente como la clave 31 en la figura 1. dicha identificación puede, por ejemplo, relacionarse con los estados de un registro de desplazamiento que es apropiado para crear la clave de codificación requerida, o similar.
El hecho de que cada paquete de codificación
3-i solamente depende de una clave de codificación
2-i no debería causar la impresión de que sería
posible una descodificación desacoplada de un bloque fuente entero
basado en un único paquete de codificación. De hecho, como se puede
observar en la figura 1, la información de un bloque fuente
10-i está contenida en los símbolos respectivos de
codificación de todos los paquetes de codificación
3-1 ... 3-N. Para decodificar
apropiadamente un bloque fuente 10-i, debido a las
propiedades de códigos de velocidad inferior, se han de procesar al
menos K paquetes de codificación. A continuación el procesamiento
de más de k, por ejemplo, todos los N símbolos de codificación,
mejora la calidad de la decodificación. Se puede observar también
fácilmente que, cuando están disponibles suficientes paquetes de
codificación (mas de K) para decodificar, se pueden decodificar no
solamente un bloque fuente 10-i, sino todos los
bloques fuente 10-1 ... 10-16. De
este modo, cuando están disponibles más de K paquetes de
codificación para descodificar, se puede reconstruir la totalidad
del objeto de transporte 1.
Este principio se utiliza cuando se usan códigos
de velocidad inferior sobre canales de transmisión disipativa,
cuando un objeto de transporte, cuyos bloques fuente se componen de
K símbolos fuente cada uno descrito en la figura 1, se codifica en
N paquetes de codificación, el receptor no tiene necesariamente que
recibir correctamente todos los N paquetes de codificación para
poder reconstruir el objeto de transporte 1. Además, no requiere
siquiera una cierta secuencia de la recepción de los paquetes de
codificación, ni una recepción de bloque temporalmente adyacente de
paquetes de codificación, porque la información en la clave de
codificación, que también se incluye en cada paquete de
codificación, es suficiente para utilizar el paquete de datos
recibido para la decodificación del objeto de transporte.
Para garantizar que hay suficientes paquetes de
codificación disponibles en un receptor, basta por lo tanto, como
lo propone la presente invención, con señalizar el número de
paquetes de datos correctamente recibidos, lo cual corresponde al
número de paquetes de codificación correctamente recibidos (ya que
cada paquete de datos contiene un paquete de codificación como
carga útil en este caso), a un servidor de reparación que en
consecuencia se ocupa de la generación de otros paquetes de
codificación (paquetes de datos de reparación), que, después de su
correcta recepción, permiten que el receptor decodifique dicho
objeto de transporte. Dicha información de petición de reparación,
compuesto por al menos dicho número de paquetes de datos
correctamente recibidos (correspondientes al número de paquete de
codificación correctamente recibidos en este caso), comprende,
además, ventajosamente el TSI y el TOI, para permitir la
identificación de la sesión de transporte y, si hay diversos
objetos de transporte, del objeto de transporte para el cual se
requieren paquetes de datos de reparación. Además, la petición de
reparación puede, además, incluir la dirección IP del transmisor.
Esto se puede solicitar porque el mismo servidor puede actuar como
un servidor de reparación preferido para múltiples transmisores. En
tal caso, la petición de reparación puede también tener que
mencionar la dirección IP del transmisor. De este modo, la
dirección IP del transmisor y el TSU identifican únicamente una
sesión.
En la figura 1, la totalidad del bloque de
transporte 1 se segmenta en bloques fuente 10-1 ...
10-10, que se codifican conjuntamente usando las
mismas claves de codificación 2-1 ...
2-N para obtener los paquetes de codificación
3-1 ... 3-N. Se entiende que, cada paquete de datos FLUTE contiene un paquete entero de codificación 3-i, también los paquetes completos de codificación 3-i se tienen que generar mediante el servidor de reparación en caso de una petición de reparación del receptor específico debida a los paquetes de datos que faltan. Sin embargo, la segmentación del bloque de transporte en los bloques fuente puede ser ventajosa con el fin de facilitar la decodificación como pequeñas memorias rápidas en el decodificador del receptor, es decir, la memoria rápida del receptor necesita por lo tanto solamente mantener los símbolos de codificación correspondientes a un bloque fuente a la vez. Además, el decodificador puede repetir los mismos pasos para la recuperación de cada bloque fuente, porque entonces decodifica a partir de símbolos de codificación que comparten exactamente las mismas posiciones en la secuencia recibida.
3-1 ... 3-N. Se entiende que, cada paquete de datos FLUTE contiene un paquete entero de codificación 3-i, también los paquetes completos de codificación 3-i se tienen que generar mediante el servidor de reparación en caso de una petición de reparación del receptor específico debida a los paquetes de datos que faltan. Sin embargo, la segmentación del bloque de transporte en los bloques fuente puede ser ventajosa con el fin de facilitar la decodificación como pequeñas memorias rápidas en el decodificador del receptor, es decir, la memoria rápida del receptor necesita por lo tanto solamente mantener los símbolos de codificación correspondientes a un bloque fuente a la vez. Además, el decodificador puede repetir los mismos pasos para la recuperación de cada bloque fuente, porque entonces decodifica a partir de símbolos de codificación que comparten exactamente las mismas posiciones en la secuencia recibida.
Por el contrario, si cada paquete de datos FLUTE
contiene solamente un símbolo de codificación (por ejemplo
30-1 en la figura 1) fuera de cada paquete de
codificación (por ejemplo 3-1 en la figura 1), en
caso de un paquete de datos faltante, solamente se ha de generar un
paquete de datos de reparación que contenga un símbolo de
codificación en lugar de un paquete de codificación entero. Sin
embargo, esto puede requerir la indicación adicional del SBN en el
ID de carga útil FEC de cada paquete de datos FLUTE con el fin de
poder identificar el bloque fuente al que se refiere el símbolo de
codificación. Cada cabecera de paquete de datos FLUTE contiene
entonces, por ejemplo, un TSI, TOI, SBN, y un identificador de clave
y en caso de pérdida o recepción incorrecta de un paquete de datos
FLUTE, además del número de paquetes de datos FLUTE recibidos
correctamente, el receptor específico puede, además, tener que
incluir el SBN del bloque fuente del objeto de transporte al que se
refiere el símbolo de codificación en el paquete de datos perdidos.
El servidor de reparación genera solamente, entonces nuevos
símbolos de codificación para el bloque fuente como se indica en la
información de reparación por el SBN.
Si el fichero fuente es tan grande que no se
cabe dentro de la estructura compuesta de bloques fuente mostrada
en la figura 1, entonces puede ser necesario segmentar el fichero
fuente en más de una estructura compuesta de bloques fuente. En
este caso, la petición de reparación puede tener que incluir también
el ID de estructura compuesta de bloques fuente. Cada cabecera de
paquete de datos FLUTE puede contener entonces, por ejemplo, un
TSI, TOI, SBM compuesto y un identificador de clave, y en caso de
pérdida o recepción incorrecta de un paquete de datos FLUTE, además
del número de paquetes de datos FLUTE ya recibidos correctamente
(que corresponde en este caso con el número de símbolo de
codificación correctamente recibidos), el receptor específico puede,
además, tener que incluir el SBN compuesto del bloque fuente del
objeto de transporte al que se refiere el símbolo de codificación
en el paquete de datos FLUTE perdido. El servidor de reparación
puede solamente generar entonces nuevos símbolos de codificación
para los bloques fuente compuestos como se indica en la petición de
reparación por el SBN compuesto.
Ambas posibilidades anteriormente mencionadas de
incorporar bien los símbolos de codificación de un paquete de
codificación entero o solamente símbolos de codificación
individuales en paquetes de datos FLUTE son apuntadas por la
presente invención.
La figura 2a proporciona una visión global de
los componentes funcionales de un transmisor 4 y un receptor
5-1 en un escenario de transmisión punto a
multipunto donde se transiten paquetes de datos FLUTE (que llevan
todos símbolos de codificación de un paquete de codificación o
solamente un único símbolo de codificación como carga útil como se
ha mencionado anteriormente) a una pluralidad de receptores
5-1 ... 5-3.
El transmisor 4 comprende una interfaz 40 a una
red 6, por ejemplo Internet, y de este modo tiene acceso al
contenido que es suministrado por esa red y que se ha de distribuir
a dichos receptores 5-1 ... 5-3 en
una sesión de difusión/multidifusión. Tal contenido se puede
entonces, por ejemplo, almacenar en la memoria 41 de dicho
transmisor. Con el fin de poder transmitir dicho contenido, la
codificación y la modulación de dicho contenido se lleva a cabo por
una instancia de modulación y codificación 42. Las operaciones
llevada a cabo por dicha instancia 42 cumple los requisitos
impuestos por las diferentes capas de protocolo de la pila de
protocolo ISO/OSI. En particular, la generación de paquetes de datos
FLUTE basado en la codificación FEC de objetos de transporte para
obtener símbolos de codificación como carga útil (bien uno o vario
por paquete de datos) de los paquetes de datos FLUTE y la
definición de los cambos de cabecera de los paquetes de datos
FLUTE, que contienen por ejemplo el TSI, TOI y el ID de carga útil
FEC (en el caso actual de codificación FEC de velocidad inferior
que corresponde a un identificador de calve de 4 bytes y
posiblemente un SBN), se llevan a cabo en esta instancia 42. La
instancia 42 introduce entonces señales moduladas que se transiten
por la instancia 43, que actúa como una interfaz al canal de
transmisión inalámbrico o conectado por cable (por ejemplo óptico).
Todas las instancias 40, 41, 42 y 43 del transmisor 43 son
controladas por una unidad de control 44.
En el receptor 5-1, que aquí se
considera como receptor específico, se reciben las señales moduladas
mediante una instancia 50, y a continuación se envían a una
instancia de desmodulación y decodificación 51 que corresponde
funcionalmente a la instancia de decodificación y desmodulación 42
del transmisor 4. En particular, las señales moduladas se
desmodulan, y se verifica si los paquetes de datos FLUTE se reciben
o no correctamente. Esto se puede por ejemplo, conseguir mediante
capas de protocolo por debajo de la capa FLUTE mediante una suma de
control o técnicas similares. Si se decide que un paquete de datos
FLUTE se ha recibido correctamente, se incrementa un contador 510
en esta instancia 51. Dicha instancia de desmodulación y
descodificación 51 también sirve como memoria intermedia para
recibir paquetes de datos FLUTE, y, si se han recibido suficientes
paquetes FLUTE, realiza la descodificación de los paquetes de datos
FLUTE, que se pueden almacenar en la memoria 52 del receptor
5-1. dicho receptor 5-1 comprende,
además, una instancia de modulación y codificación 53 con
funcionalidad similar a la instancia de modulación y codificación 42
del transmisor 4, y una instancia 54 que actúa como una interfaz al
canal de transmisión. Todas las instancias 50, 51, 52, 53 y 54 son
controladas por una instancia de control 55.
La figura 2b ilustra la sesión de reparación
punto a punto que se establece entre un servidor de reparación 7 y
el receptor específico 5-1 durante o después de que
se haya terminado la transmisión de paquetes de datos tal como se
representa en la figura 2a. Con este fin, el receptor
5-1 verifica el contador 510 para determinar si se
han recibido suficientes paquetes de datos FLUTE para reconstruir el
objeto de transporte. Si no es el caso, el controlador 55 produce
la generación de un mensaje de petición de reparación (similar a un
mensaje NACK) por la instancia de modulación y codificación 53) que
contiene información de reparación, por ejemplo el TSI, el TOI, el
número de paquetes de datos correctamente recibidos contados por
dicho contador 510 y posiblemente un SBN. La generación de dicho
mensaje de petición de reparación puede usar al menos una pila de
protocolo parcialmente diferente como la pila de protocolo que se
usa para dicha transmisión punto a multipunto, por ejemplo se puede
usar http. Dicho mensaje de petición de reparación puede entonces,
por ejemplo adoptar la siguiente forma:
En este mensaje GET, el servidor de reparación,
el TSI (123), TOI (456) y el número de paquetes de datos
correctamente recibidos (5432) son contenidos como información de
reparación. La dirección IP (o URL) del servidor MBMS (transmisor)
también podría estar incluida en el mensaje de petición de
reparación.
Alternativamente, se podrían usar otros
procedimientos http tales como POST para solicitar los paquetes de
datos que faltan. Por ejemplo, el siguiente mensaje POST es
equivalente al mensaje GET mostrado anteriormente:
Este mensaje de petición de reparación se
transite entonces por la instancia 54 al servidor de reparación 7,
en el cual se recibe por las instancias 70, desmodulado y
descodificado en la instancia 71, que proporciona funcionalidad
inversa a la instancia 53 en el receptor específico
5-1 y si fuese necesario, se almacena en la memoria
72. Dicho servidor de reparación 7 comprende, además, una instancia
de modulación y codificación 73, una instancia de transmisión 74 y
una
interfaz a una red 6. Todas las instancias del servidor de reparación son controladas por una instancia de control 76.
interfaz a una red 6. Todas las instancias del servidor de reparación son controladas por una instancia de control 76.
Finalmente, la figura 2c representa el escenario
donde el servidor de reparación 7 transmite paquetes de datos de
reparación FLUTE a dicho receptor específico 5-1 en
respuesta a dicho mensaje de petición de reparación enviado en la
figura 2b. Con este fin, el servidor de reparación evalúa la
información de reparación recibida del receptor específico
5-1 por http, y determina cuantos paquetes de datos
necesitan ser generados y transmitidos a dicho receptor específico
para permitirle reconstruir dicho objeto de transporte. El servidor
de reparación 7 trae dicho objeto de transporte o porciones del
mismo bien desde su memoria o, bien mediante la interfaz 75, desde
la red 6, y realiza una codificación FEC sobre dicho objeto de
transporte o partes del mismo como se ilustra en la figura 1 para
obtener los símbolos de codificación que sirven de carga útil para
los paquetes de datos de reparación FLUTE, en los cuales se pueden
usar bien uno o diversos símbolos de codificación como carga útil
para los paquetes de datos. El servidor de reparación 7 puede
determinar, por ejemplo, el número M de paquete de datos de
reparación FLUTE para cada objeto (TSI, TOI y posiblemente SBN)
basado en el número de columnas del objeto de transporte 1
(variable K en la figura 1), el encabezamiento de recepción y el
número de paquetes de datos FLUTE correctamente recibidos
señalizados por el receptor específico en su mensaje de petición de
reparación. A continuación el servidor de reparación 7 genera un
conjunto de M claves y genera los símbolos de codificación
correspondientes, que se insertan entonces en los paquetes de datos
de reparación FLUTE (bien como uno o más símbolos de codificación),
se modulan y se transmiten a dicho receptor específico
5-1 por las instancias 73 y 74.
En dicho receptor 5-1, las
señales moduladas que contienen los paquetes de datos de reparación
FLUTE se reciben entonces por la instancia 50 y a continuación se
procesan en la instancia 51 para determinar si se ha recibido o no
correctamente un paquete de datos. Si se han recibido correctamente
suficiente paquetes de datos FLUTE o paquetes de datos de
reparación, el objeto de transporte se puede reconstruir por dicha
instancia 51 y almacenar en dicha memoria 52 para su posterior
procesamiento.
La figura 3 representa un diagrama de flujo
ejemplar de un procedimiento para recibir paquetes de datos en un
receptor en un sistema punto a multipunto. en una primera etapa 801,
se pone a cero un contador de paquetes, para, por ejemplo, iniciar
la recepción de paquetes de datos relacionados con un nuevo objeto
de transporte. A continuación los paquetes de datos transmitidos
por un transmisor a una pluralidad de receptores se reciben en una
etapa 802. En una etapa 803, se verifica entonces si cada paquete de
datos individual es correcto o no. Si este es el caso, el contador
de paquetes se incrementa en uno, de otro modo, se obvia el
incremento. A continuación se verifica si la transmisión de
paquetes de datos se termina en una etapa 805. Si no es el caso, el
procedimiento vuelve a la etapa 802 de recepción de paquetes de
datos. En caso contrario, se verifica en una etapa 806 si se han
recibido suficientes paquetes de datos comparando si el contador de
paquetes es igual o superior a un número mínimo requerido de
paquetes de datos. Si es el caso, los paquetes de datos recibidos
se descodifican para obtener el objeto de transporte deseado en una
etapa 807. Si no es el caso, se ha de iniciar una sesión de
reparación para señalizar la información de reparación, que
comprende al menos el contador de paquetes y posiblemente un SBN, y
que comprende, además, ventajosamente un TSI y TOI, dentro de un
mensaje de petición de reparación, a un servidor de reparación. El
servidor de reparación empieza entonces a transmitir paquetes de
datos de reparación basados en dicha información de reparación
señalizada, para que de este modo el receptor vuelva a la etapa 802
de recepción de paquetes de datos. Este procedimiento continúa hasta
que se hayan recibido correctamente suficiente paquetes de datos en
dicho receptor, como se verifica en la etapa 806.
La invención se ha descrito anteriormente
mediante realizaciones preferidas. Se ha de subrayar que existen
maneras alternativas y variaciones que serán obvias para un experto
en la técnica y que se pueden llevar a la práctica sin salirse del
alcance de las reivindicaciones anexas.
Claims (40)
1. Un procedimiento para transmitir paquetes de
datos en un sistema capaz de transmisión punto a multipunto, que
comprende:
- -
- transmitir uno o más paquetes de datos desde un transmisor (4) a uno o más receptores (5-1, 5-2, 5-3); y
- -
- señalizar información de reparación a partir de al menos un receptor específico (5-1) de dichos receptores (5-1, 5-2, 5-3), en cuyo receptor específico (5-1) se requiere una recepción de paquetes de datos de reparación, a un servidor de reparación (7) con el fin de activar una transmisión de dichos paquetes de datos de reparación,
caracterizado porque para
una técnica de codificación de corrección de error sin vía de
retorno usada para generar dichos paquetes de datos a partir de un
objeto de datos que se ha de transferir entre dicho transmisor y
dichos uno o más receptores, la recepción de un número mínimo de
paquetes de datos es suficiente para habilitar a un receptor para
que reconstruya dicho objeto de datos y porque dicha información de
reparación comprende información relacionada con el número de
paquetes de datos transmitidos correctamente recibidos a nivel de
dicho receptor específico
(5-1).
2. Procedimiento según la reivindicación 1, en
el cual se requieren dichos paquetes de datos de reparación debido
a la pérdida o la recepción incorrecta de al menos uno de dichos
paquetes de datos transmitidos a nivel de dicho receptor específico
(5-1).
3. Procedimiento según la reivindicación 1, en
el cual se requieren dichos paquetes de datos de reparación para
reconstruir al menos uno de dichos objetos de datos a nivel de dicho
receptor específico (5-1).
4. Procedimiento según la reivindicación 1, en
el cual dichos objetos de datos son objetos de transporte, y en el
cual dicha información de reparación comprende un identificador de
uno de dichos objetos de transporte.
5. Procedimiento según la reivindicación 1, en
el cual dichos objetos de datos son porciones de objetos de
transporte, y en el cual dicha información de reparación comprende
un identificador de una de dichas porciones y un identificador del
objeto de transporte correspondiente.
6. Procedimiento según la reivindicación 4, en
el cual dichos objetos de transporte se relacionan con una sesión
de transporte, y en el cual dicha información de reparación
comprende un identificador de dicha sesión de transporte.
7. Procedimiento según la reivindicación 1, en
el cual dicha información de reparación comprende una serie de
paquetes de datos transmitidos correctamente recibidos a nivel de
dicho receptor específico (5-1).
8. Procedimiento según la reivindicación 1, en
el cual dicha información de reparación comprende una serie de
paquetes de datos transmitidos no correctamente recibidos a nivel de
dicho receptor específico (5-1).
9. Procedimiento según la reivindicación 1, en
el cual dicha codificación se basa al menos parcialmente en claves
de codificación que se incluyen en dichos paquetes de datos y
paquetes de datos de reparación.
10. Procedimiento según la reivindicación 1, en
el cual dicho servidor de reparación (7) determina al menos basado
parcialmente en base a dicha información de reparación señalizada,
cuantos paquetes de datos de reparación necesitan ser transmitidos
a dicho receptor específico (5-1) con el fin de
permitirle reconstruir dicho objeto de datos, genera dichos
paquetes de datos de reparación y transmite dichos paquetes de datos
de reparación al menos a dicho receptor específico
(5-1).
11. Procedimiento según la reivindicación 1, en
el cual dicha corrección de error sin vía de retorno se basa al
menos parcialmente en un código LT.
12. Procedimiento según la reivindicación 1, en
el cual dicha corrección de error sin vía de retorno se basa al
menos parcialmente en un código raptor.
13. Procedimiento según la reivindicación 1, en
el cual dicha transmisión de uno o más paquetes de datos a uno o
más receptores (5-1, 5-2,
5-3) se controla, al menos parcialmente, mediante un
protocolo basado en sesiones dirigido a una transferencia punto a
multipunto unidireccional.
14. Procedimiento según la reivindicación 1, en
el cual dicha transmisión de uno o más paquetes de datos a uno o
más receptores (5-1, 5-2,
5-3) se controla, al menos parcialmente, mediante el
protocolo de distribución de ficheros sobre de transporte
unidireccional.
15. Procedimiento según la reivindicación 1, en
el cual dicha señalización de dicha información de reparación se
lleva a cabo en una sesión punto a punto entre dicho receptor
específico (5-1) y dicho servidor de reparación
(7).
16. Procedimiento según la reivindicación 1, en
el cual dicha señalización de dicha información de reparación se
controla, al menos parcialmente, mediante el protocolo de
transferencia de hipertexto.
17. Procedimiento según la reivindicación 16, en
el cual los procedimientos GET o POST del protocolo de
transferencia de hipertexto se usan para dicha señalización de dicha
información de reparación.
18. Procedimiento según la reivindicación 1, en
el cual dicha transmisión de dichos paquetes de datos de reparación
desde dicho servidor de reparación (7) a dicho receptor específico
(5-1) se lleva a cabo en una sesión punto a
punto.
19. Procedimiento según la reivindicación 1, en
el cual dicho sistema es un sistema de servicio de
difusión/multidi-
fusión multimedia.
fusión multimedia.
20. Un sistema para transmitir paquetes de
datos, en el cual dicho sistema es capaz de transmisión punto a
multipunto, que comprende
- -
- un transmisor (4)
- -
- uno o más receptores (5-1, 5-2, 5-3); y
- -
- un servidor de reparación (7);
en el cual dicho transmisor (4) está dispuesto
para transmitir uno o más paquetes de datos a dichos receptores
(5-1, 5-2, 5-3) ,y
en el cual dicho servidor de reparación (7) está dispuesto para
recibir información de reparación señalizada a partir de al menos
un receptor específico (5-1) de dichos receptores
(5-1, 5-2, 5-3), en
cuyo receptor específico (5-1) se requiere una
recepción de paquetes de datos de reparación a dicho servidor de
reparación (7) con el fin de activar una transmisión de dichos
paquetes de datos de reparación
caracterizado porque para una técnica de
codificación de corrección de error sin vía de retorno usada para
generar dichos paquetes de datos a partir de un objeto de datos que
se ha de transferir entre dicho transmisor y dichos uno o más
receptores, la recepción de un número mínimo de paquetes de datos es
suficiente para habilitar a un receptor para que reconstruya dicho
objeto de datos y porque dicha información de reparación comprende
información relacionada con el número de paquetes de datos
transmitidos correctamente recibidos a nivel de dicho receptor
específico (5-1).
21. Sistema según la reivindicación 20, en el
cual dicha corrección de error sin vía de retorno se basa al menos
parcialmente en un código raptor.
22. Un transmisor (4) para un sistema capaz de
transmisión punto a multipunto, comprendiendo dicho transmisor
- -
- medios dispuestos para transmitir uno o más paquetes de datos a uno o más receptores (5-1, 5-2, 5-3), y
- -
- medios dispuestos para recibir información de reparación señalizada a partir de, al menos, un receptor específico (5-1) de dichos receptores (5-1, 5-2, 5-3), en cuyo receptor específico (5-1) se requiere la recepción de paquetes de datos de reparación, a dicho transmisor con el fin de activar una transmisión de dichos paquetes de datos de reparación,
caracterizado porque para
una técnica de codificación de corrección de error sin vía de
retorno usada para generar dichos paquetes de datos a partir de un
objeto de datos que se ha de transferir entre dicho transmisor y
dichos uno o más receptores, la recepción de un número mínimo de
paquetes de datos es suficiente para habilitar a un receptor para
que reconstruya dicho objeto de datos y porque dicha información de
reparación comprende información relacionada con el número de
paquetes de datos transmitidos correctamente recibidos a nivel de
dicho receptor específico
(5-1).
(5-1).
23. Transmisor (4) según la reivindicación 22,
en el cual dicha corrección de error sin vía de retorno se basa, al
menos parcialmente, en un código raptor.
24. Transmisor (4) según cualquiera de las
reivindicaciones 22-23, en el cual dicha transmisión
de uno o más paquetes de datos a dicho uno o más receptores
(5-1, 5-2, 5-3) se
controla, al menos parcialmente, mediante el protocolo de
distribución de ficheros sobre transporte unidireccional.
25. Transmisor (4) según cualquiera de las
reivindicaciones 22-24, en el cual dicha información
de reparación comprende un número de paquetes de datos transmitidos
correctamente recibidos a nivel de dicho receptor
(5-1).
26. Transmisor (4) según cualquiera de las
reivindicaciones 22-24, en el cual dicha información
de reparación comprende un número de paquetes de datos transmitidos
no correctamente recibidos a nivel de dicho receptor
(5-1).
27. Transmisor (4) según cualquiera de las
reivindicaciones 22-26, en el cual dicho sistema es
un sistema de servicio de difusión-multidifusión
multimedia.
\global\parskip0.900000\baselineskip
28. Un elemento de red (7) para un sistema
capaz de transmisión punto a multipunto, en el cual se transmiten
uno o más paquetes de datos desde un transmisor (4) a uno o más
receptores (5-1, 5-2,
5-3), comprendiendo dicho elemento de red (7):
- -
- medios dispuestos para recibir información de reparación señalizada desde, al menos, un receptor específico (5-1) de dichos receptores (5-1, 5-2, 5-3), en cuyo receptor específico (5-1) se requiere la recepción de paquetes de datos de reparación, a dicho elemento de red con el fin de activar una transmisión de dichos paquetes de datos de reparación,
caracterizado porque para
una técnica de codificación de corrección de error sin vía de
retorno usada para generar dichos paquetes de datos a partir de un
objeto de datos que se ha de transferir entre dicho transmisor y
dichos uno o más receptores, la recepción de un número mínimo de
paquetes de datos es suficiente para habilitar a un receptor para
que reconstruya dicho objeto de datos y porque dicha información de
reparación comprende información relacionada con el número de
paquetes de datos transmitidos correctamente recibidos en dicho
receptor específico
(5-1).
29. Elemento de red (7) según la reivindicación
28, comprendiendo dicho elemento de red (7):
- -
- medios para determinar, al menos parcialmente, basado en dicha información de reparación señalizada, cuantos paquetes de datos de reparación necesitan ser transmitidos a dicho receptor específico (5-1) con el fin de permitirle reconstruir dicho objeto de datos,
- -
- medios para generar dichos paquetes de datos de reparación, y
- -
- medios para transmitir dichos paquetes de datos de reparación al menos a dicho receptor específico (5-1).
30. Elemento de red según cualquiera de las
reivindicaciones 28-29, en el cual dicha corrección
de error sin vía de retorno se basa al menos parcialmente en un
código raptor.
31. Un receptor (5-1) para un
sistema capaz de transmisión punto a multipunto, comprendiendo dicho
receptor
- -
- medios dispuestos para recibir uno o más paquetes de datos transmitidos desde un transmisor (4) a uno o más receptores (5-1, 5-2, 5-3); y
- -
- medios para señalizar información de reparación a un servidor de reparación (7) con el fin de activar una transmisión de paquetes de datos de reparación, cuya recepción es requerida por dicho servidor (5-1),
caracterizado porque para
una técnica de codificación de corrección de error sin vía de
retorno usada para generar dichos paquetes de datos a partir de un
objeto de datos que se ha de transferir entre dicho transmisor y
dichos uno o más receptores, la recepción de un número mínimo de
paquetes de datos es suficiente para habilitar a un receptor para
que reconstruya dicho objeto de datos y porque dicha información de
reparación comprende información relacionada con el número de
paquetes de datos transmitidos correctamente recibidos en dicho
receptor específico
(5-1).
32. Receptor (5-1) según la
reivindicación 31, en el cual dicha corrección de error sin vía de
retorno se basa, al menos parcialmente, en un código raptor.
33. Receptor (5-1) según
cualquiera de las reivindicaciones 31-32, en el cual
dicha transmisión de uno o más paquetes de datos a dicho uno o más
receptores (5-1, 5-2,
5-3) se controla, al menos parcialmente, mediante
el protocolo de distribución de ficheros sobre transporte
unidireccional.
34. Receptor (5-1) según
cualquiera de las reivindicaciones 31-33, en el cual
dicha información de reparación comprende un número de paquetes de
datos transmitidos correctamente recibidos a nivel de dicho receptor
(5-1).
35. Receptor (5-1) según
cualquiera de las reivindicaciones 31-33, en el cual
dicha información de reparación comprende un número de paquetes de
datos transmitidos no correctamente recibidos a nivel de dicho
receptor (5-1).
36. Receptor (5-1) según
cualquiera de las reivindicaciones 31-35, en el cual
dicha señalización de dicha información de reparación se controla
al menos parcialmente por el protocolo de transferencia de
hipertexto.
37. Receptor (5-1) según la
reivindicación 36, en el cual los procedimientos GET o POST del
protocolo de transferencia de hipertexto se usan para dicha
señalización de dicha información de reparación.
38. Receptor (5-1) según
cualquiera de las reivindicaciones 31-37, en el cual
dicho sistema es un sistema de servicio difusión/multidifusión
multimedia.
39. Una aplicación de software ejecutable en un
receptor (5-1) de un sistema es capaz de transmisión
punto a multipunto, comprendiendo la aplicación de software:
- -
- un código de programa para hacer que el receptor (5-1) reciba uno o más paquetes de datos que se transmiten a partir de un transmisor (4) a uno o más receptores (5-1, 5-2, 5-3); y
\global\parskip1.000000\baselineskip
- -
- un código de programa para hacer que el receptor (5-1) señalice la información de reparación a un servidor de reparación (7) con el fin de activar una transmisión de paquetes de datos de reparación, cuya recepción se requiere a nivel de dicho receptor (5-1).
caracterizado porque para
una técnica de codificación de corrección de error sin vía de
retorno usada para generar dichos paquetes de datos a partir de un
objeto de datos que se ha de transferir entre dicho transmisor y
dichos uno o más receptores, la recepción de un número mínimo de
paquetes de datos es suficiente para habilitar a un receptor para
que reconstruya dicho objeto de datos y porque dicha información de
reparación comprende información relacionada con el número de
paquetes de datos transmitidos correctamente recibidos en dicho
receptor específico
(5-1).
40. Aplicación de software según la
reivindicación 39, en la cual dicha corrección de error sin vía de
retorno se basa, al menos parcialmente, en un código raptor.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/903,489 US7590922B2 (en) | 2004-07-30 | 2004-07-30 | Point-to-point repair request mechanism for point-to-multipoint transmission systems |
| US903489 | 2004-07-30 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2308525T3 true ES2308525T3 (es) | 2008-12-01 |
Family
ID=35276226
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05767499T Active ES2308525T3 (es) | 2004-07-30 | 2005-07-27 | Mecanismo de peticion de reparacion punto a punto para sistema de transmision punto a multipunto. |
Country Status (16)
| Country | Link |
|---|---|
| US (2) | US7590922B2 (es) |
| EP (1) | EP1771964B1 (es) |
| JP (2) | JP2008508761A (es) |
| KR (1) | KR100913983B1 (es) |
| CN (1) | CN1973476B (es) |
| AT (1) | ATE405054T1 (es) |
| AU (1) | AU2005268492B2 (es) |
| BR (1) | BRPI0513975B1 (es) |
| CA (1) | CA2574010C (es) |
| DE (1) | DE602005008976D1 (es) |
| ES (1) | ES2308525T3 (es) |
| MX (1) | MXPA06013543A (es) |
| RU (1) | RU2369971C2 (es) |
| TW (1) | TWI280757B (es) |
| WO (1) | WO2006013459A1 (es) |
| ZA (1) | ZA200700793B (es) |
Families Citing this family (110)
| 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 |
| US20020129159A1 (en) | 2001-03-09 | 2002-09-12 | Michael Luby | Multi-output packet server with independent streams |
| US9240810B2 (en) | 2002-06-11 | 2016-01-19 | Digital Fountain, Inc. | Systems and processes for decoding chain reaction codes through inactivation |
| EP2355360B1 (en) | 2002-10-05 | 2020-08-05 | QUALCOMM Incorporated | Systematic encoding and decoding of chain reaction codes |
| US9077991B2 (en) * | 2002-12-10 | 2015-07-07 | Sony Computer Entertainment America Llc | System and method for utilizing forward error correction with video compression |
| US7586874B2 (en) * | 2003-01-06 | 2009-09-08 | Interdigital Technology Corporation | Wireless communication method and apparatus for providing multimedia broadcast services |
| EP2722995B1 (en) | 2003-10-06 | 2023-04-19 | QUALCOMM Incorporated | Soft-Decision Decoding of Multi-Stage Chain Reaction Codes |
| WO2005112250A2 (en) | 2004-05-07 | 2005-11-24 | Digital Fountain, Inc. | File download and streaming system |
| US8406211B2 (en) * | 2004-09-29 | 2013-03-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Forward error correction for broadcast/multicast service |
| US8467333B2 (en) * | 2005-02-15 | 2013-06-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Receiver and receiver control method |
| US20070147371A1 (en) * | 2005-09-26 | 2007-06-28 | The Board Of Trustees Of Michigan State University | Multicast packet video system and hardware |
| KR101292851B1 (ko) | 2006-02-13 | 2013-08-02 | 디지털 파운튼, 인크. | 가변적 ｆｅｃ 오버헤드 및 보호 구간을 이용하는 스트리밍및 버퍼링 |
| US9270414B2 (en) | 2006-02-21 | 2016-02-23 | Digital Fountain, Inc. | Multiple-field based code generator and decoder for communications systems |
| US7673219B2 (en) * | 2006-03-16 | 2010-03-02 | Mitsubishi Electric Research Laboratories, Inc. | Cooperative relay networks using rateless codes |
| US8595581B2 (en) * | 2006-04-11 | 2013-11-26 | Thomson Licensing | Data reception method, repair method and corresponding terminal |
| US7971129B2 (en) | 2006-05-10 | 2011-06-28 | Digital Fountain, Inc. | Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient users of the communications systems |
| US9209934B2 (en) | 2006-06-09 | 2015-12-08 | Qualcomm Incorporated | Enhanced block-request streaming using cooperative parallel HTTP and forward error correction |
| US9432433B2 (en) | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
| US9178535B2 (en) | 2006-06-09 | 2015-11-03 | Digital Fountain, Inc. | Dynamic stream interleaving and sub-stream based delivery |
| US9386064B2 (en) | 2006-06-09 | 2016-07-05 | Qualcomm Incorporated | Enhanced block-request streaming using URL templates and construction rules |
| US9380096B2 (en) | 2006-06-09 | 2016-06-28 | Qualcomm Incorporated | Enhanced block-request streaming system for handling low-latency streaming |
| 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 |
| KR101419287B1 (ko) * | 2006-07-07 | 2014-07-14 | 삼성전자주식회사 | Ｉｐｄｃ 서비스를 제공하는 장치 및 방법 및 ｉｐｄｃ서비스를 처리하는 장치 및 방법 |
| TWI325732B (en) * | 2006-07-31 | 2010-06-01 | Ind Tech Res Inst | File repair mechanism for mbms and umts network |
| EP1901525A1 (en) * | 2006-09-15 | 2008-03-19 | THOMSON Licensing | File repair method for a content distribution system |
| US20080101317A1 (en) * | 2006-10-30 | 2008-05-01 | Nokia Corporation | System and method for providing advanced session control of a unicast session |
| CN101536416B (zh) * | 2006-10-31 | 2012-09-12 | 汤姆森特许公司 | 用于恢复数据的方法及装置 |
| CA2599303A1 (en) | 2007-08-29 | 2009-02-28 | Gbd Corp. | Surface cleaning apparatus |
| WO2008073144A1 (en) | 2006-12-14 | 2008-06-19 | Thomson Licensing | Rateless encoding in communication systems |
| CN101558593A (zh) | 2006-12-14 | 2009-10-14 | 汤姆逊许可证公司 | 通信系统的带自适应调制的arq |
| WO2008073103A1 (en) | 2006-12-14 | 2008-06-19 | Thomson Licensing | Rateless codes decoding method for communication systems |
| EP2103024B1 (en) * | 2006-12-14 | 2018-04-25 | Thomson Licensing | Modulation indication method for communication systems |
| JP5153784B2 (ja) * | 2006-12-14 | 2013-02-27 | トムソン ライセンシング | 通信システムにおける連結符号化／復号 |
| US10165912B2 (en) | 2006-12-15 | 2019-01-01 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| US9888817B2 (en) | 2014-12-17 | 2018-02-13 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| US9192269B2 (en) | 2006-12-15 | 2015-11-24 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| US11857142B2 (en) | 2006-12-15 | 2024-01-02 | Omachron Intellectual Property Inc. | Surface cleaning apparatus having an energy storage member and a charger for an energy storage member |
| US20210401246A1 (en) | 2016-04-11 | 2021-12-30 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| RU2436245C2 (ru) * | 2007-01-10 | 2011-12-10 | Нокиа Корпорейшн | Система и способ для осуществления хэндовера mbms во время доставки в режиме загрузки |
| EP1944944A1 (en) * | 2007-01-12 | 2008-07-16 | Thomson Licensing | System and method for combining pull and push modes |
| WO2008119673A1 (en) * | 2007-03-30 | 2008-10-09 | Thomson Licensing | Robust file casting for mobile tv |
| RU2010114256A (ru) | 2007-09-12 | 2011-10-20 | Диджитал Фаунтин, Инк. (Us) | Формирование и передача исходной идентификационной информации для обеспечения надежного обмена данными |
| US8849183B2 (en) | 2007-10-05 | 2014-09-30 | Qualcomm Incorporated | Location and time based filtering of broadcast information |
| BRPI0722125B1 (pt) * | 2007-10-23 | 2020-03-03 | Interdigital Ce Patent Holdings | Método, sistema e aparelho para correção de erro de encaminhamento adaptativo com pedido de repetição automática combinada para multitransmissão confiável em redes de área local sem fio |
| 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 | 在接收器要求失落符號之方法及其接收器 |
| CN101742413B (zh) * | 2008-11-24 | 2014-06-18 | 株式会社Ntt都科摩 | 基站、用户终端和单小区增强型组播和广播业务实现方法 |
| US9280778B2 (en) | 2008-12-15 | 2016-03-08 | Qualcomm Incorporated | Location logging and location and time based filtering |
| US9281847B2 (en) | 2009-02-27 | 2016-03-08 | Qualcomm Incorporated | Mobile reception of digital video broadcasting—terrestrial services |
| JP2010213150A (ja) * | 2009-03-12 | 2010-09-24 | Nec Corp | 送信装置、大容量ファイル配信システム、同システムにおけるファィル再送制御方法、再送制御プログラム |
| US10722086B2 (en) | 2017-07-06 | 2020-07-28 | Omachron Intellectual Property Inc. | Handheld surface cleaning apparatus |
| US9265395B2 (en) | 2010-03-12 | 2016-02-23 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| 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 |
| 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 |
| US9136981B2 (en) | 2010-03-03 | 2015-09-15 | Qualcomm Incorporated | Block aggregation of objects in a communication system |
| KR101737843B1 (ko) * | 2010-03-11 | 2017-05-29 | 엘지전자 주식회사 | 비실시간 방송 서비스 처리 시스템 및 그 처리방법 |
| US9485546B2 (en) | 2010-06-29 | 2016-11-01 | Qualcomm Incorporated | Signaling video samples for trick mode video representations |
| US8918533B2 (en) | 2010-07-13 | 2014-12-23 | Qualcomm Incorporated | Video switching for streaming video data |
| US9185439B2 (en) | 2010-07-15 | 2015-11-10 | Qualcomm Incorporated | Signaling data for multiplexing video components |
| US9596447B2 (en) | 2010-07-21 | 2017-03-14 | Qualcomm Incorporated | Providing frame packing type information for video coding |
| US9456015B2 (en) | 2010-08-10 | 2016-09-27 | Qualcomm Incorporated | Representation groups for network streaming of coded multimedia data |
| US9270299B2 (en) | 2011-02-11 | 2016-02-23 | Qualcomm Incorporated | Encoding and decoding using elastic codes with flexible source block mapping |
| US8958375B2 (en) | 2011-02-11 | 2015-02-17 | Qualcomm Incorporated | Framing for an improved radio link protocol including FEC |
| US9485108B2 (en) * | 2011-03-14 | 2016-11-01 | Qualcomm Incorporated | System and apparatus for using multichannel file delivery over unidirectional transport (“FLUTE”) protocol for delivering different classes of files in a broadcast network |
| CN102098149A (zh) * | 2011-03-28 | 2011-06-15 | 东南大学 | 一种无线多播中的本地协作方法 |
| US9451401B2 (en) | 2011-05-27 | 2016-09-20 | Qualcomm Incorporated | Application transport level location filtering of internet protocol multicast content delivery |
| KR20120137198A (ko) * | 2011-06-11 | 2012-12-20 | 삼성전자주식회사 | 통신 시스템에서 패킷 송수신 장치 및 방법 |
| 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 |
| US9055136B2 (en) * | 2011-10-13 | 2015-06-09 | Qualcomm Incorporated | Controlling streaming delay in networks |
| KR101591238B1 (ko) * | 2011-11-01 | 2016-02-18 | 퀄컴 인코포레이티드 | Ｈｔｔｐ 서버들 사이의 소스 데이터 및 리페어 데이터의 할당에 의한 컨텐츠 전달 시스템 |
| US9213605B2 (en) * | 2012-01-23 | 2015-12-15 | Intel Corporation | IP multimedia subsystem and method for MBMS file repair using HTTP servers |
| KR102027916B1 (ko) | 2012-02-27 | 2019-10-02 | 삼성전자주식회사 | 순방향 오류정정스킴을 사용하는 패킷 송수신 장치 및 방법 |
| US9294226B2 (en) | 2012-03-26 | 2016-03-22 | Qualcomm Incorporated | Universal object delivery and template-based file delivery |
| KR101961736B1 (ko) * | 2012-04-23 | 2019-03-25 | 삼성전자 주식회사 | 통신 시스템에서 패킷 송수신 장치 및 방법 |
| KR20130126876A (ko) | 2012-04-30 | 2013-11-21 | 삼성전자주식회사 | 통신 시스템에서 패킷 송수신 방법 및 장치 |
| EP2878098B1 (en) * | 2012-07-27 | 2018-11-21 | Telefonaktiebolaget LM Ericsson (publ) | User equipment node, server node and methods performed in such nodes for performing file repair procedure |
| US9591958B2 (en) | 2013-02-27 | 2017-03-14 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| US9027198B2 (en) | 2013-02-27 | 2015-05-12 | G.B.D. Corp. | Surface cleaning apparatus |
| US9900166B2 (en) * | 2013-04-12 | 2018-02-20 | Qualcomm Incorporated | Methods for delivery of flows of objects over broadcast/multicast enabled networks |
| CN103401718A (zh) * | 2013-08-08 | 2013-11-20 | 天津恒达文博科技有限公司 | 一种对设备进行无线设置的方法及装置 |
| US20150172066A1 (en) * | 2013-12-13 | 2015-06-18 | Qualcomm Incorporated | Practical implementation aspects of unicast fetch for http streaming over embms |
| KR102208814B1 (ko) * | 2014-03-28 | 2021-01-28 | 삼성전자주식회사 | 통신 시스템에서 패킷 송수신 방법 및 장치 |
| US9585530B2 (en) | 2014-07-18 | 2017-03-07 | Omachron Intellectual Property Inc. | Portable surface cleaning apparatus |
| US9451853B2 (en) | 2014-07-18 | 2016-09-27 | Omachron Intellectual Property Inc. | Portable surface cleaning apparatus |
| US9420925B2 (en) | 2014-07-18 | 2016-08-23 | Omachron Intellectual Property Inc. | Portable surface cleaning apparatus |
| US9314139B2 (en) | 2014-07-18 | 2016-04-19 | Omachron Intellectual Property Inc. | Portable surface cleaning apparatus |
| US9571155B2 (en) * | 2014-08-25 | 2017-02-14 | Samsung Display Co., Ltd. | Method of startup sequence for a panel interface |
| US11950745B2 (en) | 2014-12-17 | 2024-04-09 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| US10251519B2 (en) | 2014-12-17 | 2019-04-09 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| US10136778B2 (en) | 2014-12-17 | 2018-11-27 | Omachron Intellectual Property Inc. | Surface cleaning apparatus |
| WO2016101213A1 (zh) | 2014-12-25 | 2016-06-30 | 华为技术有限公司 | 一种文件修复的方法、相关装置及系统 |
| CN106406246B (zh) * | 2015-07-31 | 2019-09-20 | 中国联合网络通信集团有限公司 | 调度消息传输的方法及装置 |
| US9673937B2 (en) * | 2015-10-12 | 2017-06-06 | International Business Machines Corporation | Adaptive network communication protocols |
| US10702113B2 (en) | 2017-07-06 | 2020-07-07 | Omachron Intellectual Property Inc. | Handheld surface cleaning apparatus |
| US10842330B2 (en) | 2017-07-06 | 2020-11-24 | Omachron Intellectual Property Inc. | Handheld surface cleaning apparatus |
| US10537216B2 (en) | 2017-07-06 | 2020-01-21 | Omachron Intellectual Property Inc. | Handheld surface cleaning apparatus |
| US10750913B2 (en) | 2017-07-06 | 2020-08-25 | Omachron Intellectual Property Inc. | Handheld surface cleaning apparatus |
| US11666193B2 (en) | 2020-03-18 | 2023-06-06 | Omachron Intellectual Property Inc. | Surface cleaning apparatus with removable air treatment member assembly |
| US10631693B2 (en) | 2017-07-06 | 2020-04-28 | Omachron Intellectual Property Inc. | Handheld surface cleaning apparatus |
| US11445878B2 (en) | 2020-03-18 | 2022-09-20 | Omachron Intellectual Property Inc. | Surface cleaning apparatus with removable air treatment member assembly |
| US11766156B2 (en) | 2020-03-18 | 2023-09-26 | Omachron Intellectual Property Inc. | Surface cleaning apparatus with removable air treatment member assembly |
| US10506904B2 (en) | 2017-07-06 | 2019-12-17 | Omachron Intellectual Property Inc. | Handheld surface cleaning apparatus |
| US11730327B2 (en) | 2020-03-18 | 2023-08-22 | Omachron Intellectual Property Inc. | Surface cleaning apparatus with removable air treatment assembly |
| CN108712235B (zh) * | 2018-05-29 | 2020-11-20 | 北京光润通科技发展有限公司 | 一种单向无反馈传输方法 |
| US11192122B2 (en) | 2018-08-13 | 2021-12-07 | Omachron Intellectual Property Inc. | Cyclonic air treatment member and surface cleaning apparatus including the same |
| US11013384B2 (en) | 2018-08-13 | 2021-05-25 | Omachron Intellectual Property Inc. | Cyclonic air treatment member and surface cleaning apparatus including the same |
| US11006799B2 (en) | 2018-08-13 | 2021-05-18 | Omachron Intellectual Property Inc. | Cyclonic air treatment member and surface cleaning apparatus including the same |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS61216542A (ja) * | 1985-03-22 | 1986-09-26 | Nec Corp | 再送要求信号の伝送方法 |
| JPH01289341A (ja) * | 1988-05-17 | 1989-11-21 | Toshiba Corp | パケット伝送方式 |
| JP3127440B2 (ja) * | 1995-10-23 | 2001-01-22 | 日本電信電話株式会社 | 誤り回復装置 |
| JP3571918B2 (ja) * | 1997-06-04 | 2004-09-29 | 株式会社東芝 | 符号伝送方法、送信装置、受信装置および通信システム |
| US6278716B1 (en) * | 1998-03-23 | 2001-08-21 | University Of Massachusetts | Multicast with proactive forward error correction |
| US6421387B1 (en) * | 1998-05-15 | 2002-07-16 | North Carolina State University | Methods and systems for forward error correction based loss recovery for interactive video transmission |
| US6212240B1 (en) * | 1998-06-24 | 2001-04-03 | Motorola, Inc. | Method and apparatus for conveying data between communication devices |
| US6782490B2 (en) * | 1999-03-17 | 2004-08-24 | At&T Corp. | Network-based service for the repair of IP multicast sessions |
| US6574795B1 (en) * | 1999-05-28 | 2003-06-03 | Intel Corporation | Reliable communication of data by supplementing a unidirectional communications protocol |
| JP4000905B2 (ja) * | 2002-05-22 | 2007-10-31 | ソニー株式会社 | 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム |
| AU2003238968A1 (en) | 2002-06-11 | 2003-12-22 | Meshnetworks, Inc. | System and method for multicast media access in ad-hoc communication networks |
| KR20030095709A (ko) * | 2002-06-14 | 2003-12-24 | 삼성전자주식회사 | 할당된 채널을 통해 다중 서비스모드의 오에프디엠신호의전송이 가능한 오에프디엠 전송 시스템 |
| CN100379191C (zh) * | 2002-06-26 | 2008-04-02 | 华为技术有限公司 | 通信网络中的数据重传方法 |
| US7065780B2 (en) * | 2002-09-20 | 2006-06-20 | Opentv, Inc. | Method and system for emulating and HTTP server through a broadcast carousel |
| AU2002359137A1 (en) * | 2002-12-13 | 2004-10-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Error messaging method in http based communication systems |
| US7536622B2 (en) * | 2004-03-29 | 2009-05-19 | Nokia Corporation | Data repair enhancements for multicast/broadcast data distribution |
-
2004
- 2004-07-30 US US10/903,489 patent/US7590922B2/en active Active
-
2005
- 2005-07-19 TW TW094124255A patent/TWI280757B/zh active
- 2005-07-27 BR BRPI0513975-9A patent/BRPI0513975B1/pt active IP Right Grant
- 2005-07-27 AU AU2005268492A patent/AU2005268492B2/en active Active
- 2005-07-27 MX MXPA06013543A patent/MXPA06013543A/es active IP Right Grant
- 2005-07-27 WO PCT/IB2005/002411 patent/WO2006013459A1/en active IP Right Grant
- 2005-07-27 CN CN200580020399.9A patent/CN1973476B/zh active Active
- 2005-07-27 DE DE602005008976T patent/DE602005008976D1/de active Active
- 2005-07-27 ES ES05767499T patent/ES2308525T3/es active Active
- 2005-07-27 JP JP2007523175A patent/JP2008508761A/ja not_active Withdrawn
- 2005-07-27 EP EP05767499A patent/EP1771964B1/en active Active
- 2005-07-27 RU RU2007101526/09A patent/RU2369971C2/ru active
- 2005-07-27 KR KR1020087023256A patent/KR100913983B1/ko active IP Right Grant
- 2005-07-27 AT AT05767499T patent/ATE405054T1/de not_active IP Right Cessation
- 2005-07-27 CA CA2574010A patent/CA2574010C/en active Active
-
2007
- 2007-01-29 ZA ZA200700793A patent/ZA200700793B/xx unknown
-
2009
- 2009-08-06 US US12/462,775 patent/US20090307564A1/en not_active Abandoned
-
2010
- 2010-12-27 JP JP2010290240A patent/JP2011061876A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| BRPI0513975B1 (pt) | 2019-04-24 |
| MXPA06013543A (es) | 2007-01-26 |
| AU2005268492B2 (en) | 2009-10-01 |
| JP2008508761A (ja) | 2008-03-21 |
| JP2011061876A (ja) | 2011-03-24 |
| CA2574010A1 (en) | 2006-02-09 |
| TW200623703A (en) | 2006-07-01 |
| KR20080096847A (ko) | 2008-11-03 |
| TWI280757B (en) | 2007-05-01 |
| RU2007101526A (ru) | 2008-09-10 |
| US20060023732A1 (en) | 2006-02-02 |
| CN1973476A (zh) | 2007-05-30 |
| US7590922B2 (en) | 2009-09-15 |
| ZA200700793B (en) | 2010-03-31 |
| ATE405054T1 (de) | 2008-08-15 |
| BRPI0513975A (pt) | 2008-05-20 |
| EP1771964A1 (en) | 2007-04-11 |
| CN1973476B (zh) | 2010-09-01 |
| RU2369971C2 (ru) | 2009-10-10 |
| EP1771964B1 (en) | 2008-08-13 |
| CA2574010C (en) | 2012-04-10 |
| KR100913983B1 (ko) | 2009-08-25 |
| WO2006013459A1 (en) | 2006-02-09 |
| AU2005268492A1 (en) | 2006-02-09 |
| DE602005008976D1 (de) | 2008-09-25 |
| US20090307564A1 (en) | 2009-12-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2308525T3 (es) | Mecanismo de peticion de reparacion punto a punto para sistema de transmision punto a multipunto. | |
| US7376150B2 (en) | Point-to-point repair response mechanism for point-to-multipoint transmission systems | |
| ES2488846T3 (es) | Identificación y retransmisión de partes perdidas | |
| US9350488B2 (en) | Content delivery system with allocation of source data and repair data among HTTP servers | |
| KR101591238B1 (ko) | Ｈｔｔｐ 서버들 사이의 소스 데이터 및 리페어 데이터의 할당에 의한 컨텐츠 전달 시스템 | |
| US20100214970A1 (en) | Method and system for transmitting data packets from a source to multiple receivers via a network | |
| BRPI0418723B1 (pt) | método para o reparo de dados em um sistema capaz de comunicações ponto-multiponto, sistema de comunicação e dispositivo emissor | |
| Jenkač et al. | Cross-layer assisted reliability design for wireless multimedia broadcast | |
| Gasiba et al. | Enhanced system design for download and streaming services using Raptor codes | |
| Gasiba et al. | Reliable and efficient download delivery with Raptor codes | |
| KR20070030932A (ko) | 점―대―다지점 전송 시스템용 점―대―점 수리 요구메커니즘 | |
| KR100870236B1 (ko) | 점-대-다중점 송신 시스템을 위한 점-대-점 보수 응답메커니즘 | |
| Yetgin et al. | Reliable download analyses for multimedia broadcast multicast services | |
| Luby | Raptor codes Application Layer FEC | |
| Makharia | Video multicast over wireless local area networks | |
| Gasiba et al. | Communication Networks |