MXPA06013543A

MXPA06013543A - Mecanismo de solicitud de reparacion punto a punto para sistemas de transmision punto a multipunto.

Info

Publication number: MXPA06013543A
Application number: MXPA06013543A
Authority: MX
Inventors: David Leon; Rod Walsh; Igor Curcio; Ramakrishna Vedantham
Original assignee: Nokia Corp
Priority date: 2004-07-30
Filing date: 2005-07-27
Publication date: 2007-01-26
Also published as: CA2574010C; CA2574010A1; US7590922B2; KR100913983B1; TWI280757B; EP1771964A1; US20090307564A1; ZA200700793B; KR20080096847A; JP2011061876A; RU2007101526A; CN1973476B; ATE405054T1; TW200623703A; EP1771964B1; ES2308525T3; AU2005268492A1; DE602005008976D1; WO2006013459A1; CN1973476A

Abstract

Esta invencion se refiere a un metodo, sistema, transmisor, elemento de red, receptor y aplicacion de software para un sistema con capacidad de transmision punto a multipunto, en donde uno o mas paquetes de datos son transmitidos de un transmisor a uno o mas receptores, en donde por lo menos en un receptor especifico de los receptores, se requiere una recepcion de paquetes de datos de reparacion, en donde la informacion de reparacion es senalizada a un servidor de reparacion a fin de iniciar una transmision de los paquetes de datos de reparacion, y en donde la informacion de reparacion comprende informacion relacionada con el numero de paquetes de datos transmitidos recibidos correctamente en el receptor especifico. El sistema puede, por ejemplo, ser el Sistema de Difusion Multidifusion Multimedia de 3GPP, la transmision de paquetes de datos puede, por ejemplo, estar controlada por el protocolo de Entrega de Archivos sobre Transporte Unidireccional y la senalizacion de la informacion de reparacion puede, por ejemplo, estar controlada por el Protocolo de Transferencia de Hipertexto.

Description

MECANISMO DE SOLICITUD DE REPARACIÓN PUNTO A PUNTO PARA SISTEMAS DE TRANSMISIÓN PUNTO A MULTIPUNTO CAMPO DE LA INVENCIÓN Esta invención se refiere a un método, sistema, transmisor, elemento de red, receptor y aplicación de software para un sistema con capacidad de transmisión punto a multipunto. ANTECEDENTES DE LA INVENCIÓN Para servicios punto a multipunto (también denotados servicios uno a muchos) sobre sistemas tales como la multidifusión de Protocolo Internet (IP) , la Difusión de Datos IP (IPDC) y los Servicios de Difusión/Multidifusión Multimedia (MBMS) , entrega.de archivos tal como, por ejemplo, la descarga de archivos multimedia es un servicio importante. No obstante, muchas de las características para entregar archivos sobre protocolos punto a punto, tales como por ejemplo, el Protocolo de Transferencia de Archivos (FTP) y el Protocolo de Transferencia de Hipertexto (HTTP) , son problemáticas para escenarios punto a multipunto. En particular, la entrega confiable de archivos, que es la entrega garantizada de archivos, que usa protocolos de confirmación (ACK) punto a punto similares tales como el Protocolo de Control de Transporte (TCP) no es viable. El Grupo de Trabajo de Transporte de Multidifusión Ref 177364 Confiable (RMT) del Grupo Especial de Ingeniería Internacional (IETF) se encuentra actualmente en el proceso de estandarizar dos categorías de protocolos de transporte de multidifusión a prueba de fallos. En la primera categoría, la confiabilidad es implementada a través del uso de Corrección Directa de Errores (FEC) (proactiva) , es decir, al enviar cierta cantidad de datos redundantes que pueden ayudar a un receptor a reconstruir datos erróneos; en la segunda categoría, la confiabilidad es implementada a través del uso de realimentación de receptor. La Codificación en Niveles Asincrona (ALC) es una instanciación de protocolo que pertenece a la primera categoría, mientras que el protocolo de Multidifusión Confiable Orientada a NACK (confirmación negativa, por sus siglas en inglés) (NORM) pertenece a la segunda categoría. Las redes de acceso en las cuales se podrían usar estos protocolos incluyen, mas no están limitadas a, redes de acceso múltiple inalámbricas tales como el Sistema Universal de Telecomunicaciones Móviles (UMTS, que incluye el Sistema Global para Red de Acceso de Radio de Evolución de Comunicaciones Móviles (GERAN) y la Red de Acceso de Radio Terrestre UMTS (UTRAN) ) , Redes de Área Local Inalámbricas (WLAN) , redes de Difusión de Video Digital - Terrestre (DVB-T) y redes de Difusión de Video Digital - Satélite (DVB-S) . Brevemente, el protocolo ALC es un esquema basado en FEC proactivo que permite que los receptores reconstruyan paquetes destrozados o paquetes que no han sido recibidos. El protocolo ALC usa codificación FEC en múltiples canales, que permite al emisor enviar datos a múltiples índices (canales) a receptores posiblemente heterogéneos. Además, el protocolo ALC usa un mecanismo de control de congestión para mantener diferentes índices en diferentes canales. El protocolo ALC es masivamente escalable en términos del número de usuarios porque no se requiere señalización de enlace ascendente. Por lo tanto, cualquier cantidad de receptores adicionales no coloca exactamente una demanda incrementada en el sistema. Sin embargo, el protocolo ALC no es 100% confiable porque la recepción no está garantizada, por ende en general no se describe como robusto. NORM, a su vez, especifica el uso de mensajes de confirmación negativa (NACK) a fin de señalizar qué paquetes de datos que se esperaba llegaran al receptor no fueron recibidos en el receptor en absoluto, o fueron recibidos en forma incorrecta. En otras palabras, los receptores emplean mensajes NACK para indicar pérdida o daño de los paquetes de datos transmitidos al transmisor. Por consiguiente, un receptor que perdió algunos paquetes de datos de una transmisión de datos puede enviar un mensaje NACK al transmisor (o un servidor de reparación) que solicita al transmisor (o servidor de reparación) que retransmita el bloque o bloques de datos faltantes . El protocolo NORM también permite de manera opcional el uso de codificación FEC de nivel de paquetes de datos para transmisiones robustas proactivas. Los mensajes NACK generalmente no son específicos de NORM, pero se pueden usar también en relación con otros protocolos o sistemas, por ejemplo, con sistemas que soportan sesiones que están controladas por el protocolo de Entrega de Archivos sobre Transporte Unidireccional (FLUTE) . FLUTE es un protocolo de transporte uno a muchos que construye sobre bloques de construcción FEC y ALC. Está diseñado para entrega de archivos de transmisor (es ) a receptor (es) sobre sistemas unidireccionales. Tiene especializaciones que lo hacen adecuado para sistemas punto a multipunto inalámbricos. Los detalles del protocolo FLUTE se discuten en más detalle en la publicación titulada "FLUTE -File Delivery Over Unidirectional Transport" (Borrador de Internet) preparado por el antes mencionado Grupo de Trabajo RMT del IETF. El uso de FLUTE es, por ejemplo, especificado por el Proyecto de Asociación de Tercera Generación (3GPP) para descarga de archivos en sesiones del sistema MBMS. FEC se puede haber usado o no en tales sesiones FLUTE. En cualquier caso, no se puede esperar que todos los receptores en la sesión reciban el archivo entero cuando la sesión termina. Para este propósito, 3GPP se encuentra en el proceso de definir sesiones de reparación punto a punto, en donde se permite • a los receptores señalizar solicitudes de retransmisiones de paquetes de datos a un transmisor o servidor de reparación vía mensajes NACK a fin de poder reconstruir el contenido descargado. Al usar mensajes NACK en relación con sesiones FLUTE (o en otras sesiones que usan un protocolo de nivel de transporte especialmente dirigido a soportar transmisiones punto a multipunto) la identificación de los paquetes de datos faltantes en lo receptores es una cuestión importante. El uso de protocolos diseñados para transmisión punto a punto, tales como TCP, y sus métodos de confirmación no son necesariamente viables aquí . En una sesión FLUTE, objetos de transporte, por ejemplo, archivos multimedia o partes de los mismos, son identificados por un Identificador de Transporte (TOI) , y son transmitidos de un transmisor a una pluralidad de receptores dentro de una sesión de transporte, que es identificada por un Identificador de Sesión de Transporte (TSI) . La transmisión de los objetos de transporte es realmente llevada a cabo por medio de la transmisión de paquetes de datos FLUTE, en donde los paquetes de datos FLUTE contienen porciones en bruto o codificadas del objeto de transporte, llamadas símbolos de codificación, como datos útiles. Los paquetes de datos FLUTE contienen además el TSI y TOI así como un ID de Datos Útiles FEC, el cual se explicará más adelante. Diversos esquemas FEC especificados por el grupo de trabajo RMT se basan en una estructura de bloque fuente y símbolo de codificación. Tales esquemas FEC se describen en la publicación RFC 3452 "Forward Error Correction Building Block" y la publicación RFC 3695 "Compact Forward Error Correction (FEC) Schemes". Cada símbolo de codificación puede ser identificado por su Número de Bloque Fuente (SBN) y su ID de Símbolo de Codificación (ESI) . Todos estos esquemas FEC suponen que dentro de cada objeto de transporte, el SBN es incrementado en uno de manera consecutiva, y que dentro de un bloque fuente, el ESI es incrementado en uno para cada símbolo de codificación que es transmitido. Tanto el SBN como ESI están contenidos en el ID de Datos Útiles FEC que está contenido en un paquete de datos FLUTE. En estos esquemas FEC, la identificación de paquetes de datos FLUTE que no son recibidos en absoluto o no son recibidos correctamente en un receptor puede ser llevada a cabo por su SBN y ESI, los cuales están contenidos en el IF de Datos Útiles FEC de paquetes de datos FLUTE. Estos parámetros pueden luego ser señalizados de vuelta como NACK al transmisor para causar una retransmisión de estos paquetes de datos identificados . No obstante, la publicación "Simple Forward Error Correction (FEC) Schemes" (Borrador de Internet) por M. Luby introduce esquemas FEC que usan un ID de Datos Útiles FEC más simple y se pueden usar para entregar objetos sin usar ninguna estructura de bloque fuente explícita. Estos esquemas FEC pueden, por ejemplo, usar códigos sin índice tales como Transformada de Luby (LT) o códigos Raptor. Un codificador LT (ver M. Luby, "LT-codes", en Proceedings of the ACM Symposium on Foundations of Computer Science (FOCS) , 2002) transmite un flujo de bits codificados, los cuales son combinaciones lineales aleatorias esparcidas de k bits dé datos . El receptor recoge versiones ruidosas de los bits codificados y usa un decodificador de propagación de la creencia para intentar deducir los k bits de datos . El número de bits codificados ruidosos n requeridos para una decodificación exitosa depende de la calidad y el tipo del canal. Códigos LT diseñados con el uso de "distribución de grado de solitón robusta" pueden obtener capacidad en cada canal de .borrado binario (BEC) . En otras palabras, R=k/n se puede hacer de manera arbitraria cercano a (1-p) para cada probabilidad de borrado p. La idea clave de la codificación Raptor (ver A.

Shokrollahi, "Raptor codes", Digital Fountain, Inc., Tech. Rep. DF2003-06-001, junio de 2003) es relajar la condición de que todos los símbolos de entrada necesitan ser recuperados . Si un código LT necesita recuperar solamente una fracción constante de sus símbolos de entrada, entonces su gráfico de decodificación necesita tener solamente 0(k) bordes, que permite codificación de tiempo lineal. Todos los símbolos de entrada pueden aún ser recuperados al concatenar un código de corrección de borrado tradicional con un código LT. n símbolos intermedios son luego obtenidos al codificar k símbolos de entrada con un (k, n) código de bloque de corrección de borrado capaz de recuperar todos los símbolos de entrada de una fracción fija de símbolos intermedios. Los n símbolos intermedios son después codificados con un código LT que puede recuperar de sus símbolos de salida la fracción requerida de los símbolos intermedios . El ID de Datos Útiles FEC propuesto para estos esquemas FEC consiste de una clave de 4 bytes a partir de la cual se genera el gráfico de decodificación. El SBN no está incluido en este ID de Datos Útiles FEC, y se pretende que el ESI lleve un identificador tal como la clave de 4 bytes en este caso. Más aún, las claves son generadas de manera aleatoria por el codificador FEC. Por ende, el receptor puede no ser capaz de identificar los paquetes de datos faltantes a partir de las claves de los otros paquetes de datos que ha recibido en la sesión. Como resultado", la identificación de paquetes de datos FLUTE faltantes por su SBN y ESI asociados no es aplicable en estos esquemas FEC.

BREVE DESCRIPCIÓN DE LA INVENCIÓN En vista de los problemas antes mencionados, existe la necesidad de un método, sistema, transmisor, elemento de red, receptor y aplicaciones de software mejorados para transmisión de paquetes de datos en un sistema con capacidad de transmisión punto a multipunto. Se propone un método para transmitir paquetes de datos en un sistema con capacidad de transmisión punto a multipunto, que comprende transmitir uno o más paquetes de datos de un transmisor a uno o más receptores, en donde por lo menos en un receptor específico de los receptores, se requiere una recepción de paquetes de datos de reparación, y señalizar información de reparación a un servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico. El sistema puede representar cualquier sistema inalámbrico o cableado, en donde paquetes de datos son transmitidos de por lo menos un transmisor a uno o más receptores. La transmisión puede ser ya sea una transmisión de difusión, en la cual todos los receptores son dirigidos por el transmisor, o una transmisión de multidifusión, en la cual solamente un subgrupo de todos los receptores es dirigido por el transmisor. El sistema puede, por ejemplo, ser desplegado en el contexto de UMTS, una LAN, una WLAN, DVB-T o DVB-S, y puede estar diseñado para distribuir contenido tal como, por ejemplo, archivos multimedia a una pluralidad de receptores. La transmisión del paquete de datos o más paquetes de datos se puede llevar a cabo en enlaces de transmisión unidireccionales o bidireccionales . Los paquetes de datos transmitidos pueden, por ejemplo, estar relacionados con contenido que se va a transferir a los receptores. Este contenido puede ser segmentado y procesado para permitir la transmisión a los receptores, mientras que los paquetes de datos se deben entender como el resultado de esta segmentación y procesamiento. Por ejemplo, los paquetes de datos pueden ser paquetes de datos FLUTE cuyos datos útiles se obtienen mediante codificación FEC de un objeto de transporte, por ejemplo, un archivo multimedia. En este caso, los datos útiles del paquete de datos FLUTE pueden, por ejemplo, ser símbolos de codificación o paquetes de codificación. Por lo menos en un receptor, el cual es denotado como receptor específico, se requiere una recepción de paquetes de datos de reparación, que se puede deber a una pluralidad de razones tales como, por ejemplo, recepción incorrecta o pérdida de paquetes de datos transmitidos . El receptor específico puede percatarse del requerimiento de recibir paquetes de datos de reparación durante la transmisión de paquetes de datos o después de que la transmisión de paquetes de datos ha terminado . Los paquetes de datos de reparación pueden, por ejemplo, ser copias simples de los paquetes de datos transmitidos que no fueron recibidos por el receptor específico. De igual modo, pueden ser diferentes con respecto al contenido tanto de codificación como real. Por ejemplo, si se usa codificación FEC sin índice, se pueden aplicar diferentes claves al generar los paquetes de datos de reparación. Por consiguiente, los paquetes de datos de reparación sirven al propósito de proporcionar al receptor específico esa cantidad de información que es requerida por el receptor específico. A fin de iniciar una transmisión de paquetes de datos de reparación desde el servidor de reparación, el receptor específico señaliza información de datos de reparación al servidor de reparación. Esto puede tener lugar en una transferencia punto a punto. Por ende, el servidor de reparación está habilitado para generar los paquetes de datos de reparación apropiados y transmitirlos al receptor específico^ Esta transferencia puede ser, por ejemplo, una transferencia punto a punto. De acuerdo con la presente invención, se propone que esta información de reparación comprenda información relacionada con un número de paquetes de datos transmitidos que fueron correctamente recibidos en el receptor específico. Ahí, el término recibido correctamente es entendido en una manera que el receptor sea capaz de usar la información contenida en el paquete de datos recibidos para procesamiento adicional y no tenga que desechar el paquete de datos. Esto, por ejemplo, se puede decidir con base en una suma de control incluida en el paquete de datos. La lógica detrás de esta propuesta es que, para ciertas técnicas de codificación FEC, las cuales se pueden usar para generar los paquetes de datos a partir de un objeto de datos que realmente se va a transferir en la transferencia punto a multipunto entre el transmisor y el receptor o más receptores, la recepción de un número mínimo de paquetes de datos es suficiente para habilitar al receptor para reconstruir el objeto de datos en sí. Por ejemplo, si un objeto de datos es codificado en N paquetes de datos, solamente L < N paquetes de datos se pueden requerir en un receptor para ser capaz de reconstruir el objeto de datos. Ahí, además puede no ser requerido que L paquetes de datos específicos sean recibidos, sino solamente que L paquetes de datos diferentes de los N paquetes de datos sean recibidos. As , para^ permitir que un servidor de reparación genere paquetes de datos de reparación, información sobre cuántos paquetes de datos fueron recibidos correctamente en el receptor . específico, junto con información estructural adicional relacionada con la técnica de codificación FEC, es suficiente. Por ende, a diferencia de la técnica anterior, una identificación exacta de los paquetes de datos que son requeridos por el receptor específico, por ejemplo, en términos de un SBN y un ESI relacionados con un cierto objeto de transporte y una cierta sesión de transporte, ya no tiene que ser señalizada de vuelta al servidor de reparación, lo cual reduce mucho la sobrecarga de señalización encontrada en las sesiones de reparación. De acuerdo con una modalidad preferida del método de la presente invención, los paquetes de datos de reparación son requeridos debido a pérdida o recepción incorrecta de al menos uno de los paquetes de datos transmitidos en el receptor específico. Esto, por ejemplo, puede ser causado por atenuaciones de canal de transmisión, retardos, distorsiones o ruido aditivo. De igual modo, algunos o todos los paquetes de datos transmitidos pueden no haber sido recibidos en el receptor específico en absoluto. De acuerdo con otra modalidad preferida del método de la presente invención, los paquetes de datos transmitidos están- relacionados con objetos de datos. Por ejemplo, los paquetes de datos pueden contener porciones del objeto de datos en bruto o en forma codificada. De acuerdo con una modalidad preferida del método de la presente invención, los paquetes de datos de reparación son requeridos para reconstruir por lo menos uno de los objetos de datos en el receptor específico. Por ejemplo, puede ocurrir el caso de que el transmisor termine la transmisión de paquetes de datos, antes de que un receptor específico haya recibido todos los paquetes de datos que requiere para reconstruir todo el objeto de transporte que está descargando actualmente. Luego los paquetes de datos que faltan en el receptor específico pueden ser paquetes de datos que realmente no han sido transmitidos por el transmisor antes. De acuerdo con otra modalidad preferida del método de la presente invención, los objetos de datos son objetos de transporte, y la información de reparación comprende un identificador de uno de los objetos de transporte. Los objetos de transporte pueden ser, por ejemplo, archivos (multimedia) o partes de los mismos. De acuerdo con otra modalidad preferida del método de la presente invención, los objetos de datos son porciones de objetos de transporte, y la información de reparación comprende un identificador de una de las porciones y un identificador del objeto de transporte correspondiente. Los objetos de transporte pueden ser, por ejemplo, archivos (multimedia) que son descargados por los receptores. Los objetos de transporte pueden ser segmentados en porciones, por ejemplo, bloques fuente de objetos de transporte, los cuales representan entonces los objetos de datos. A partir de las porciones- (bloques fuente) , los paquetes de datos pueden ser entonces generados, por ejemplo, mediante codificación FEC del bloques fuente en N paquetes de datos . Luego es favorable proveer un identificádor de la 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, con base en la información sobre cuántos paquetes de datos relacionados con el bloque fuente de un objeto de transporte son recibidos correctamente en el receptor específico, pueda determinar cuántos paquetes de datos de reparación relacionados con el bloque fuente del objeto de transporte necesitan ser transmitidos al receptor específico. Asimismo, puede ser posible que un objeto de transporte sea segmentado en diversas estructuras de bloque fuente compuestas, y el identificador de la porción del objeto de transporte pueda entonces identificar una de las estructuras de bloque fuente compuestas y el bloque fuente contenido en las mismas . - De acuerdo con otra modalidad preferida del método de la presente invención, los objetos de transporte están relacionados con una sesión de transporte, y la información de reparación comprende un identificador de la sesión de transporte. Una pluralidad de objetos de transporte puede ser transmitida dentro de la misma sesión de transporte, y puede haber también varias sesiones de transporte concurrentes.

De acuerdo con otra modalidad preferida del método de la presente invención, la información de reparación comprende el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico. De acuerdo con otra modalidad preferida del método de la presente invención, la información de reparación comprende el número de paquetes de datos transmitidos no recibidos correctamente en el receptor específico. Este número de paquetes de datos no recibidos correctamente está relacionado con el número de paquetes de datos recibidos correctamente en tanto que se pueda determinar a partir del número de paquetes de datos recibidos correctamente, si además el número total de paquetes de datos transmitidos o requeridos es conocido para el receptor específico. De acuerdo con otra modalidad preferida del método de la presente invención, los paquetes de datos y los paquetes de datos de reparación son generados a partir de los objetos de datos por medio de codificación de corrección directa de errores. Los paquetes de datos pueden, por ejemplo, ser generados al codificar el objeto de datos completo de una vez, o al codificarlo por secciones. Ahí, el término codificación se entiende como cualquier técnica que añade redundancia a los datos en bruto a fin de simplificar la detección y/o corrección de corrupciones de los datos codificados debido a corrupciones introducidas por un canal de transmisión.

De acuerdo con otra modalidad preferida del método de la presente invención, la codificación está al menos parcialmente basada en claves de codificación que están incluidas dentro de los paquetes de datos y paquetes de datos de reparación. Las claves pueden ser requeridas para decodificar los paquetes de datos. Las claves pueden, por ejemplo, ser claves pseudoaleatorias binarias. De acuerdo con otra modalidad preferida del método de la presente invención, la codificación de corrección directa de errores tiene la propiedad de que solamente una subserie de todos los paquetes de datos transmitidos que están relacionados con un objeto de datos tiene que ser recibida correctamente por un receptor a fin de ser capaz de reconstruir el objeto de datos. Por ejemplo, si N paquetes de datos son generados en el proceso de codificar el objeto de datos (o partes del mismo) , solamente L < N paquetes de datos recibidos correctamente pueden ser requeridos para reconstruir el objeto de datos (o las partes del mismo) . No obstante, la recepción de paquetes de datos adicionales puede contribuir a incrementar la calidad de la reconstrucción. De acuerdo con otra modalidad preferida del método de la presente invención, el servidor de reparación determina, al menos parcialmente basado en la información de reparación señalizada, cuántos paquetes de datos de reparación necesitan ser transmitidos al receptor específico a fin de permitirle reconstruir el objeto de datos, genera los paquetes de datos de reparación y transmite los paquetes de datos de reparación por lo menos al receptor específico. Tal determinación puede, por ejemplo, basarse en el número de paquetes de datos recibidos correctamente señalizados desde el receptor específico, el tamaño del objeto de datos, por ejemplo, en términos del número de porciones en las que el objeto de datos está segmentado, y parámetros como la sobrecarga de recepción, la cual denota cuántos paquetes de datos que exceden la cantidad mínima de paquetes de datos requeridos para una reconstrucción apropiada del objeto de datos se proveerán al receptor . De acuerdo con otra modalidad preferida del método de la presente invención, la corrección directa de errores está basada al menos parcialmente en un código LT. De acuerdo con otra modalidad preferida del método de la presente invención, la corrección directa de errores está basada al menos parcialmente en un código raptor. De acuerdo con otra modalidad preferida del método de la presente invención, la transmisión de uno o más paquetes de datos a uno o más receptores está al menos parcialmente controlada por un protocolo basado en sesión dirigido a transferencia punto a multipunto unidireccional. De acuerdo con otra modalidad preferida del método de la presente invención, la transmisión de uno o más paquetes de datos a uno o más receptores está al menos parcialmente controlada por el protocolo de Entrega de Archivos sobre Transporte Unidireccional. Luego los paquetes de datos pueden, por ejemplo, ser unidades de datos de protocolo del protocolo FLUTE . De acuerdo con otra modalidad preferida del método de la presente invención, la señalización de la información de reparación se lleva a cabo en una sesión punto a punto entre el receptor específico y el servidor de reparación. De acuerdo con otra modalidad preferida del método de la presente invención, la señalización de la información de reparación está al menos parcialmente controlada por el Protocolo de Transferencia de Hipertexto. De acuerdo con otra modalidad preferida del método de la presente invención, los métodos GET o POST del Protocolo de Transferencia de Hipertexto se usan para la señalización de la información de reparación. De acuerdo con otra modalidad preferida del método de la presente invención, la transmisión de paquetes de datos de reparación del servidor de reparación al receptor específico se lleva a cabo en una sesión punto a punto. De- acuerdo con otra modalidad preferida del método de la presente invención, el sistema es un Sistema de Difusión/Multidifusión Multimedia de acuerdo con los estándares del Proyecto de Asociación de Tercera Generación.

Se propone también un sistema para transmitir paquetes de datos, en donde el sistema tiene capacidad de transmisión punto a multipunto, que comprende un transmisor, uno o más receptores, y un servidor de reparación, en donde uno o más paquetes de datos son transmitidos del transmisor a los receptores, en donde al menos en un receptor específico de los receptores, se requiere una recepción de paquetes de datos de reparación, en donde la información de reparación es señalizada al servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, y en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico. Se propone también un transmisor en un sistema con capacidad de transmisión punto a multipunto, que comprende medios dispuestos para transmitir uno o más paquetes de datos a uno o más receptores, en donde al menos en un receptor específico de los receptores, se requiere una recepción de paquetes de datos de reparación, en donde la información de reparación es señalizada a un servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, y en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico. El transmisor puede ser co-ubicado con el servidor de reparación o incluso ser idéntico al mismo. De acuerdo con una modalidad preferida del transmisor de la presente invención, los paquetes de datos transmitidos están relacionados con objetos de datos, que comprende además medios dispuestos para generar los paquetes de datos a partir de los objetos de datos mediante codificación de corrección directa de errores. Igualmente, se propone un elemento de red en un sistema con capacidad de transmisión punto a multipunto, en donde uno o más paquetes de datos son transmitidos de un transmisor a uno o más receptores, y en donde por lo menos en un receptor específico de los receptores, se requiere una recepción de paquetes de datos de reparación; el elemento de red comprende medios dispuestos para recibir información de reparación señalizada al elemento de red a fin de iniciar una transmisión de los paquetes de datos de reparación, en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico. El elemento de red puede estar co-ubicado con el transmisor o incluso ser idéntico al mismo, y puede, por ejemplo, ser un servidor de reparación. • De acuerdo con una modalidad preferida del elemento de red de la presente invención, los paquetes de datos transmitidos están relacionados con objetos de datos, los paquetes de datos de reparación son generados a partir de los objetos de datos mediante codificación de corrección directa de errores, y la codificación de corrección directa de errores tiene la propiedad de que solamente una subserie de todos los paquetes de datos transmitidos que están relacionados con un objeto de datos tiene que se recibida correctamente por un receptor a fin de ser capaz de reconstruir el objeto de datos, y el elemento de red comprende medios para determinar, al menos parcialmente con base en la información de reparación señalizada, cuántos paquetes de datos de reparación necesitan ser transmitidos al receptor específico a fin de permitirle reconstruir el objeto de datos, medios para generar los paquetes de datos de reparación, y medios para transmitir los paquetes de datos de reparación al menos al receptor específico. De acuerdo con otra modalidad preferida del elemento de red de la presente invención, los paquetes de datos transmitidos están relacionados con objetos de datos, y el elemento de red comprende además medios dispuestos para generar los paquetes de datos de reparación a partir de los objetos de datos mediante codificación de corrección directa de errores . Asimismo, se propone un receptor en un sistema con capacidad de transmisión punto a multipunto, que comprende medios dispuestos para recibir uno o más paquetes de datos que son transmitidos de un transmisor a uno o más receptores, en donde al menos en el receptor, se requiere una recepción de paquetes de datos de reparación, y medios para señalizar información de reparación a un servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor. Se propone también una aplicación de software ejecutable en un receptor de un sistema con capacidad de transmisión punto a multipunto, la aplicación de software comprende un código de programa para hacer que el receptor reciba uno o más paquetes de datos que son transmitidos de un transmisor a uno o más receptores, en donde por lo menos en el receptor, se requiere una recepción de paquetes de datos de reparación; y un código de programa para hacer que el receptor señalice información de reparación a un servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor. La aplicación de- software puede ser también un producto de programa de computadora, que comprende un código de programa que es almacenado en un medio, como por ejemplo, una memoria.

Estos y otros aspectos de la invención serán evidentes a partir de y esclarecidos con referencia a las modalidades que se describen más adelante. BREVE DESCRIPCIÓN DE LAS FIGURAS Las figuras muestran: Figura 1: Una ilustración esquemática de la codificación de un objeto de transporte en una serie de paquetes de datos de acuerdo con la especificación de código Raptor para descarga de archivos MBMS; figura 2a: una presentación esquemática de un sistema punto a multipunto de acuerdo con la presente invención, en donde paquetes de datos son transmitidos de un transmisor a una pluralidad de receptores; figura 2b: una presentación esquemática de un sistema punto a multipunto de acuerdo con la presente invención, en donde un receptor específico señaliza de vuelta información de reparación a un servidor de reparación; figura 2c: una presentación esquemática de un sistema punto a multipunto de acuerdo con la presente invención, en donde 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 método para recibir paquetes de datos y paquetes de datos de reparación en un sistema punto a multipunto de acuerdo con la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Como comentario inicial, cabe mencionar que la materia de la parte introductoria de esta solicitud de patente se puede usar para sustentar esta descripción detallada. La presente invención propone que información relacionada con el número de paquetes de datos que son recibidos correctamente en un receptor específico en un sistema de transmisión de paquetes de datos punto a multipunto sea señalizada de vuelta a un servidor de reparación para iniciar la transmisión o paquetes de datos de reparación que son requeridos por el receptor específico. Esto permite una realimentación particularmente eficiente de información que permite que el servidor de reparación determine qué paquetes de datos de reparación necesitan ser transmitidos al receptor específico. Este enfoque es particularmente beneficioso cuando los paquetes de datos son generados mediante codificación FEC de objetos de transporte vía códigos sin índice tales como códigos LT o códigos raptor. La figura 1 ilustra de manera esquemática la codificación FEC de un objeto de transporte 1 con un tamaño de 3 MB (un tamaño típico para descargas de archivos MBMS) en una secuencia de N paquetes de codificación 3-1..3-N bajo uso de N claves de codificación 2-1..2-N, en donde esta codificación FEC corresponde a la especificación de código Raptor para descarga de archivos MBMS (ver publicación de 3GPP Tdoc S4-040230 "Raptor Code Specification for MBMS file download" , SA4 #31, Montreal, Canadá, 17-21 de mayo de 2004) . Partes de los paquetes de codificación 3-1..3-N obtenidos mediante codificación FEC (en particular, uno o más de los símbolos de codificación 30-i) pueden entonces, por ejemplo, servir como datos útiles para paquetes de datos FLUTE, como se discutirá en más detalle más adelante. El objeto de transporte 1 en la figura 1, que puede ser identificado por un TOI, representa solamente uno de una pluralidad de objetos de transporte que es transmitida de un transmisor a una pluralidad de receptores dentro de una sesión de transmisión, que es identificada por un TSI . De acuerdo con la figura 1, el objeto de transporte 1 se compone de 16 bloques fuente 10-1..10-16, en donde cada uno de estos bloques fuente se compone de K=6144 símbolos fuente de 32 bytes, los cuales son marcados de manera ejemplar para el bloque fuente 10-1 como 100-1..100-6144. Cada bloque fuente 10-1..10-16 tiene un tamaño de 32 bytes por 6144. La codificación FEC de este objeto de transporte completo 1 se lleva a cabo por medio de multiplicación matricial del objeto de transporte 1 con una matriz K x N cuyas columnas se componen de 6144 x 1 claves de codificación binaria, en donde un "1" de una clave de codificación se ilustra esquemáticamente como un área negra y un "0" se ilustra esquemáticamente como un área blanca. Las N diferentes claves de codificación pueden, por ejemplo, representar códigos pseudoaleatorios binarios, pero se pueden elegir de igual modo de manera deliberada. El número N de claves de codificación es mayor a K y determina la sobrecarga del receptor. Con N creciente, la probabilidad de reconstrucción correcta del objeto de transporte 1 a partir de la serie de símbolos de codificación 3-1..3-N incrementa. Al llevar a cabo la multiplicación matricial antes descrita, los N paquetes de codificación 3-1..3-N son obtenidos, en donde cada paquete de codificación tiene una dimensión de 512 bytes . Se puede ver fácilmente a partir de los sombreados diferentes 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 el símbolo de codificación 3-1. Asimismo, se puede ver que el símbolo de codificación 30-1 está influenciado por todos los elementos de bloque fuente 10-1, pero solamente por la clave de codificación 2-1. De manera similar, el símbolo de codificación 30-2 está influenciado por todos los elementos de bloque fuente 10-2 y clave de codificación 2-1. Por lo tanto, la clave de codificación 2-1 está incluida como clave 31 en el paquete de codificación 3-1, y de manera similar, las otras claves de codificación 2-1..2-N están incluidas en los N paquetes ' de codificación 3-2..3-N, respectivamente. Ahí, incluir no necesariamente significa que las claves binarias completas como se ilustra en la figura 1 están incluidas en los paquetes de codificación. Es más eficiente identificar la clave de codificación respectiva 2-1..2-N mediante una identificación de 4 bytes respectiva, la cual, para el paquete de codificación 3-1, se ilustra de manera ejemplar como clave 31 en la figura 1. La identificación puede, por ejemplo, relacionarse con los estados de un registro de desplazamiento que es adecuado para crear la clave de codificación requerida, o similar. El hecho de que cada paquete de codificación 3-i dependa solamente de una clave de codificación 2-i no debe causar la impresión de que una decodificación desacoplada de un bloque fuente completo basado en un solo paquete de codificación sería posible. De hecho, como se puede ver a partir de la figura 1, la información de un bloque fuente 10-i está contenida en los símbolos de codificación respectivos de todos los paquetes de codificación 3-1..3-N. Para decodificar de manera apropiada un bloque fuente 10-i, debido a las propiedades de los códigos sin índice, al menos K paquetes de codificación tienen que ser procesados. El procesamiento de más de K, por ejemplo, todos los N símbolos de codificación, mejora la calidad de la decodificación. Asimismo, se ve fácilmente que, cuando suficientes (más de K) paquetes de codificación están disponibles para decodificación, no solamente un bloque fuente 10-i, sino todos los bloques fuente 10-1..10-16 pueden ser decodificados . Por lo tanto, cuando más de K paquetes de codificación están disponibles para decodificación, el objeto de transporte 1 completo puede ser reconstruido. Este principio es explotado al usar códigos sin índice en canales de transmisión con pérdidas. Cuando un objeto de transporte, cuyos bloques fuente se componen de K símbolos fuente cada uno como se ilustra en la figura 1, es codificado en N paquetes de codificación, el receptor no necesariamente tiene que recibir todos los N paquetes de codificación correctamente para ser capaz de reconstruir el objeto de transporte 1. Además, ni siquiera se requiere una cierta secuencia de la recepción de los paquetes de codificación, o una recepción de un bloque temporalmente adyacente de paquetes de codificación, porque la información en la clave de codificación, la cual está también incluida en cada paquete de codificación, es suficiente para explotar el paquete de datos recibido para la decodificación del objeto de transporte. Para asegurar que suficientes" paquetes de codificación estén disponibles en un receptor, es por ende suficiente, como propone la presente invención, señalizar el número de paquetes de datos recibidos correctamente, el cual corresponde con el número de paquetes de codificación recibidos correctamente (ya que cada paquete de datos contiene un paquete de codificación como datos útiles en este caso) , a un servidor de reparación que después se encarga de la generación de más paquetes de codificación (paquetes de datos de reparación) que, después de su correcta recepción, permiten al receptor decodificar el objeto de transporte. La información de solicitud de reparación, compuesta al menos del número de paquetes de datos recibidos correctamente (que corresponde al número de paquetes de codificación recibidos correctamente en este caso) , de manera favorable comprende además el TSI y el TOI, para permitir la identificación de la sesión de transporte y, si hay varios objetos de transporte, del objeto de transporte para el cual se requieren paquetes de datos de reparación. Además, la solicitud de reparación puede incluir también la dirección IP del transmisor. Esto se puede requerir porque el mismo servidor puede actuar como un servidor de reparación preferido para múltiples transmisores. En tal caso, la solicitud de reparación puede tener que mencionar la dirección IP del transmisor también. Por consiguiente, la dirección IP del transmisor y el TSI identifican de manera única una sesión. En la figura 1, el bloque de transporte completo 1 es segmentado en bloques fuente 10-1..10-10, los cuales son codificados de manera conjunta con el uso de las mismas claves de codificación 2-1..2-N para obtener los paquetes de codificación 3-1..3-N. Se entiende que, si cada paquete de datos FLUTE contiene un paquete de codificación 3-i completo, también paquetes de codificación 3-i completos tienen que ser generados por el servidor de reparación en caso de una solicitud de reparación del receptor específico debido a paquetes de datos faltantes. No obstante, la segmentación del bloque de transporte en bloques fuente puede ser favorable a fin de facilitar la decodificación con una memoria rápida pequeña en el decodificador del receptor, es decir, la memoria rápida del receptor entonces necesita solamente mantener los símbolos de codificación correspondientes a un bloque fuente a la vez. Más aún, el decodificador puede repetir los mismos pasos al recuperar cada bloque fuente, porque decodifica luego a partir de símbolos de codificación que comparten exactamente las mismas posiciones en la secuencia recibida. En contraste, si cada paquete de datos FLUTE contiene un símbolo de codificación (por ejemplo 30-1 en la figura 1) de cada paquete de codificación (por ejemplo 3-1 en la figura 1) solamente, en caso de un paquete de datos faltante, solamente un paquete de datos de reparación que contiene un símbolo de codificación en lugar de un paquete de codificación completo tiene que ser generado. Sin embargo, esto puede requerir la indicación adicional del SBN en el ID de Datos Útiles FEC de cada paquete de datos FLUTE a fin de poder identificar el bloque fuente con el cual se relaciona el símbolo de codificación. Luego, cada cabecera de paquete de datos FLUTE, por ejemplo, contiene 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 ya recibidos correctamente, el receptor específico además puede tener que incluir el SBN del bloque fuente del objeto de transporte al cual se refiere el símbolo de codificación en el paquete de datos perdido. El servidor de reparación después genera solamente nuevos símbolos de codificación para el bloque fuente como es indicado en la información de reparación por el SBN. Si el archivo fuente es tan grande que no cabe en la estructura de bloque fuente compuesta mostrada en la figura 1, entonces puede ser necesario segmentar el archivo fuente en más de una estructura de bloque fuente compuesta. En ese caso, la solicitud de reparación puede tener que incluir el ID de estructura de bloque fuente compuesta también. Luego cada cabecera de paquete de datos FLUTE, por ejemplo, puede contener un TSI, TOI, SBN 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 (el cual corresponde con el número de símbolos de codificación recibidos correctamente en este caso) , el receptor específico además puede tener que incluir el SBN compuesto del bloque fuente del objeto de transporte al cual se refiere el símbolo de codificación en el paquete de datos FLUTE perdido. El servidor de reparación puede entonces generar solamente nuevos símbolos de codificación para el bloque fuente compuesto como es indicado en la solicitud de reparación por el SBN compuesto. La presente invención está dirigida a las dos posibilidades antes mencionadas de incorporar los símbolos de codificación de un paquete de codificación completo o solamente símbolos de codificación sencillos en paquetes de datos FLUTE. La figura 2a da una visión general sobre los componentes funcionales de un transmisor 4 y un receptor 5-1 en un escenario de transmisión punto a multipunto donde paquetes de datos FLUTE (que llevan todos los símbolos de codificación de un paquete de codificación o solamente un solo símbolo de codificación como datos útiles como se discute anteriormente) son transmitidos a una pluralidad de receptores 5-1.. 5-3. El transmisor 4 comprende una interfase 40 a una red 6, por ejemplo, la Internet, y, por ende, tiene acceso a contenido que es provisto por esa red y que se va a distribuir a los receptores 5-1..5-3 en una sesión de difusión/multidifusión. Luego, tal contenido puede, por ejemplo, ser almacenado en la memoria 41 del transmisor. A fin de poder transmitir el contenido, la codificación y modulación del contenido son llevadas a cabo por una instancia de modulación y codificación 42. Las operaciones realizadas por la instancia 42 cumplen los requerimientos impuestos por los diferentes niveles de protocolo de la pila de protocolos ISO/OSI. En particular, la generación de paquetes de datos FLUTE con base en codificación FEC de objetos de transporte para obtener símbolos de codificación como datos útiles (ya sea uno o varios por paquete de datos) de los paquetes de datos FLUTE y la definición de los campos de cabecera de los paquetes de datos FLUTE, que contienen, por ejemplo, el TSI, TOI e ID de Datos Útiles FEC (en el presente caso de codificación FEC sin índice correspondiente a un identificador de clave de 4 bytes y posiblemente un SBN) , se llevan a cabo en esta instancia 42. Después, la instancia 42 produce señales moduladas que son transmitidas por la instancia 43, la cual actúa como una interfase al canal de transmisión inalámbrico o cableado (por ejemplo, óptico). Todas las instancias 40, 41, 42 y 43 del transmisor 4 son controladas por una unidad de control 44. En el receptor 5-1, el cual se considera como receptor específico aquí, las señales moduladas son recibidas vía una instancia 50, y después alimentadas en una instancia de demodulación y decodificación 51 que corresponde funcionalmente a la instancia de codificación y modulación 42 del transmisor 4. En particular, las señales moduladas son demoduladas, y se verifica si los paquetes de datos FLUTE son recibidos correctamente o no. Esto se puede, por ejemplo, llevar a cabo por medio de niveles de protocolo por debajo del nivel FLUTE mediante una suma de control o técnicas similares. Si se decide que un paquete de datos FLUTE fue recibido correctamente, un contador 510 en la instancia 51 es incrementado. La instancia de demodulación y decodificación 51 sirve también como un búfer para paquetes de datos FLUTE recibidos, si se han recibido suficientes paquetes FLUTE, realiza la decodificación de los paquetes de datos FLUTE para reconstruir el objeto de transporte deseado, el cual luego puede ser almacenado en la memoria 52 del receptor 5-1. El 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 interfase 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 la transmisión de paquetes de datos como se ilustra en la figura 2a ha sido terminada. Para este fin, el receptor 5-1 verifica el contador 510 para determinar si suficientes paquetes de datos FLUTE han sido recibidos para reconstruir el objeto de transporte. Si éste no es el caso, el controlador 55 causa la generación de un mensaje de solicitud de reparación (similar a un mensaje NACK) por medio de la instancia de modulación y codificación 53, la cual contiene información de reparación, por ejemplo el TSI, el TOI, el número de paquetes de datos recibidos correctamente como contó el contador 510 y posiblemente un SBN. La generación del mensaje de solicitud de reparación puede usar una pila de protocolos al menos parcialmente diferente de la pila de protocolos que se usa para la transmisión punto a multipunto, por ejemplo, se puede usar HTTP. Luego, el mensaje de solicitud de reparación puede, por ejemplo, tomar la siguiente forma: GET http: //www.website . com/greatmusic/number1.mp3? mbms-rel6- FLUTE repair&TSI = 123&TOI = 456&NumRxedPkts=5432 HTTP/1.1 En este mensaje GET, el servidor de reparación, el TSI (123), TOI (456) y el número de paquetes de datos recibidos correctamente (5432) están contenidos como información de reparación. La dirección IP (o URL) del servidor MBMS (transmisor) podría estar incluida también en el mensaje dé solicitud de reparación. De manera alternativa, otros métodos HTTP tales como POST se podrían usar para solicitar los paquetes de datos faltantes. Por ejemplo, el siguiente mensaje POST es equivalente al mensaje GET antes mostrado. POST http://www.website.com/greatmusic/ HTTP/1.1 De: suscriptorlO@proveedor.com Tipo de contenido: aplicación/x-www-forma-url-codificada Longitud del contenido: 56 numberl.mp3&mbms-rel6-FLUTE-repair&TSI=123&TOI=456& NumRxedPkts=5432 Este mensaje de solicitud de reparación es después transmitido vía la instancia 54 al servidor de reparación 7, en donde es recibido vía las instancias 70, demodulado y decodificado en la instancia 71, la cual provee funcionalidad inversa a la instancia 53 en el receptor específico 5-1 y, si es necesario, es almacenado en la memoria 72. El 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 interfase 75 a la red 6. Todas las instancias del servidor de reparación son controladas por una instancia de control 76. Por último, la figura 2c ilustra el escenario cuando el servidor de reparación 7 transmite paquetes de datos de reparación FLUTE al receptor específico 5-1 en respuesta al mensaje de solicitud de reparación enviado en la figura 2b. Para este fin, el servidor de reparación evalúa la información de reparación recibida del receptor específico 5-1 vía HTTP, y determina cuántos paquetes de datos se necesitan generar y transmitir al receptor específico para permitirle reconstruir el objeto de transporte. El servidor de reparación 7 extrae el objeto de transporte o porciones del mismo ya sea de su memoria o, vía la interfase 75, de la red 6, y realiza una codificación FEC en el objeto de transporte o partes del mismo como se ilustra en la figura 1 para obtener los símbolos de codificación que sirven como datos útiles para los paquetes de datos de reparación FLUTE, en donde ya sea uno o varios símbolos de codificación se pueden usar como datos útiles para los paquetes de datos. El servidor de reparación 7 puede, por ejemplo, determinar el número M de paquetes de datos de reparación FLUTE para cada (TSI, TOI y posiblemente SBN) objeto con base en el número de columnas del objeto de transporte 1 (variable K en la figura 1) , la sobrecarga de recepción, y el número de paquetes de datos FLUTE recibidos correctamente como señalizó el receptor específico en su mensaje de solicitud de reparación. Después el servidor de reparación 7 genera una serie de M claves y genera los símbolos de codificación correspondientes, los cuales son luego incluidos en los paquetes de datos de reparación FLUTE (ya sea como uno o varios símbolos de codificación) , modulados y transmitidos al receptor específico 5-1 vía las instancias 73 y 74. En el receptor 5-1, las señales moduladas que contienen los paquetes de datos de reparación FLUTE son luego recibidas vía la instancia 50 y después procesadas en la instancia 51 para determinar si un paquete de datos ha sido recibido correctamente o no. Si suficientes paquetes de datos FLUTE o paquetes de datos de reparación han sido recibidos correctamente, el objeto de transporte puede ser reconstruido por la instancia 51 y almacenado en la memoria 52 para procesamiento adicional . La figura 3 ilustra un diagrama de flujo ejemplar de un método para recibir paquetes de datos en un receptor en un sistema punto a multipunto. En un primer paso 801, un contador de paquetes es ajustado a cero, por ejemplo, a fin de x empezar la recepción de paquetes de datos relacionados con un nuevo objeto de transporte. Luego los paquetes de datos tal como son transmitidos por un transmisor a una pluralidad de receptores son recibidos en un paso 802. En un paso 803, se verifica después si cada paquete de datos recibido único es correcto o no. Si éste es el caso, el contador de paquetes es incrementado en uno, de lo contrario, el incremento se omite. Después se verifica si la transmisión de paquetes de datos es terminada en un paso 805. Si éste no es el caso, el método regresa al paso 802 de recibir paquetes de datos. De otra "manera, se verifica en un paso 806 si suficientes paquetes de datos han sido recibidos al comparar si el contador de paquetes es igual a o mayor a un número requerido mínimo de paquetes de datos. Si éste es el caso, los paquetes de datos recibidos son decodificados para obtener el objeto de transporte deseado en un paso 807. Si éste no es el caso, se tiene que iniciar una sesión de reparación al señalizar información de reparación, que comprende al menos el contador de paquetes y posiblemente un SBN, y de manera favorable comprende además un TSI y TOI, dentro de un mensaje de solicitud de reparación a un servidor de reparación. Después el servidor de reparación empieza a transmitir paquetes de datos de reparación con base en la información de reparación señalizada, de manera que el receptor regrese al paso 802 de recibir paquetes de datos de reparación. Este procedimiento continúa hasta que suficientes paquetes de datos hayan sido recibidos correctamente en el receptor, como es verificado en el paso 806. La invención ha sido descrita anteriormente mediante modalidades preferidas . Cabe mencionar que existen maneras alternativas y variaciones que son obvias para un experto en la técnica y pueden ser implementadas sin desviarse del alcance y espíritu de las reivindicaciones adjuntas. Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims

REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones : 1. Un método para transmitir paquetes de datos en un sistema con capacidad de transmisión punto a multipunto, caracterizado porque comprende: transmitir uno o más paquetes de datos de un transmisor a uno o más receptores, en donde por lo menos en un receptor específico de los receptores, se requiere una recepción de paquetes de datos de reparación, y - señalizar información de reparación a un servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico.
2. El método de conformidad con la reivindicación 1, caracterizado porque los paquetes de datos de reparación son requeridos debido a pérdida o recepción incorrecta de al menos uno de los paquetes de datos transmitidos en el receptor específico .
3. El método de conformidad con la reivindicación 1, caracterizado porque los paquetes de datos transmitidos están relacionados con objetos de datos.
4. El método de conformidad con la reivindicación 3, caracterizado porque los paquetes de datos de reparación son requeridos para reconstruir por lo menos uno de los objetos de datos en el receptor específico.
5. El método de conformidad con la reivindicación 3, caracterizado porque los objetos de datos son objetos de transporte, y porque la información de reparación comprende un identificador de uno de los objetos de transporte.
6. El método de conformidad con la reivindicación 3, caracterizado porque los objetos de datos son porciones de objetos de transporte, y porque la información de reparación comprende un identificador de una de las porciones y un identificador del objeto de transporte correspondiente.
7. El método de conformidad con la reivindicación 5, caracterizado porque los objetos de transporte están relacionados con una sesión de transporte, y porque la información de reparación comprende un identificador de la sesión de transporte.
8. El método de conformidad con la reivindicación 3, caracterizado porque la información de reparación comprende un número de paquetes de datos transmitidos recibidos correctamente en el receptor específico.
9. El método de conformidad con la reivindicación 3, caracterizado porque la información de reparación comprende un número de paquetes de datos transmitidos no recibidos correctamente en el receptor específico.
10. El método de conformidad con la reivindicación 3, caracterizado porque los paquetes de datos y los paquetes de datos de reparación son generados a partir de los objetos de datos por medio de codificación de corrección directa de errores .
11. El método de conformidad con la reivindicación 10, caracterizado porque la codificación está al menos parcialmente basada en claves de codificación que están incluidas dentro de los paquetes de datos y paquetes de datos de reparación.
12. El método de conformidad con la reivindicación 10, caracterizado porque la codificación de corrección directa de errores tiene la propiedad de que solamente una subserie de todos los paquetes de datos transmitidos que están relacionados con un objeto de datos tiene que ser recibida correctamente por un receptor a fin de ser capaz de reconstruir el objeto de datos.
13. El método de conformidad con la reivindicación 12, caracterizado porque el servidor de reparación determina, al menos parcialmente basado en la información de reparación señalizada, cuántos paquetes de datos de reparación necesitan ser transmitidos al receptor específico a fin de permitirle reconstruir el objeto de datos, genera los paquetes de datos de reparación y transmite los paquetes de datos de reparación por lo menos al receptor específico.
14. El método de conformidad con la reivindicación 10, caracterizado porque la corrección directa de errores está basada al menos parcialmente en un código LT.
15. El método de conformidad con la reivindicación 10, caracterizado porque la corrección directa de errores está basada al menos parcialmente en un código raptor.
16. El método de conformidad con la reivindicación 1, caracterizado porque la transmisión de uno o más paquetes de datos a uno o más receptores está al menos parcialmente controlada por un protocolo basado en sesión dirigido a transferencia punto a multipunto unidireccional.
17. El método de conformidad con la reivindicación 1, caracterizado porque la transmisión de uno o más paquetes de datos a uno o más receptores está al menos parcialmente controlada por el protocolo de Entrega de Archivos sobre Transporte Unidireccional .
18. El método de conformidad con la reivindicación 1, caracterizado porque la señalización de la información de reparación se lleva a cabo en una sesión punto a punto entre el receptor específico y el servidor de reparación.
19. El método de conformidad con la reivindicación 1, caracterizado porque la señalización de la información de reparación está al menos parcialmente controlada por el Protocolo de Transferencia de Hipertexto.
20. El método de conformidad con la reivindicación 19, caracterizado porque los métodos GET o POST del Protocolo de Transferencia de Hipertexto se usan para la señalización de la información de reparación.
21. El método de conformidad con la reivindicación 1, caracterizado porque la transmisión de los paquetes de datos de reparación del servidor de reparación al receptor específico se lleva a cabo en una sesión punto a punto.
22. El método de conformidad con la reivindicación 1, caracterizado porque el sistema es un Sistema de Difusión Multidifusión Multimedia de acuerdo con los estándares del Proyecto de Asociación de Tercera Generación.
23. Un sistema para transmitir paquetes de datos, caracterizado porque el sistema tiene capacidad de transmisión punto a multipunto, que comprende: - un transmisor, - uno o más receptores , y - un servidor de reparación; en donde uno o más paquetes de datos son transmitidos del transmisor a los receptores, en donde al menos en un receptor específico de los receptores, se requiere una recepción de paquetes de datos de reparación, en donde la información de reparación es señalizada al servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, y en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico.
24. Un transmisor en un sistema con capacidad de transmisión punto a multipunto, caracterizado porque comprende: medios dispuestos para transmitir uno o más paquetes de datos a uno o más receptores, en donde al menos en un receptor específico de los receptores, se requiere una recepción de paquetes de datos de reparación, en donde la información de reparación es señalizada a un servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, y en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico.
25. El transmisor de conformidad con la reivindicación 24, caracterizado porque los paquetes de datos transmitidos están relacionados con objetos de datos, que comprende además : - medios dispuestos para generar los paquetes de datos a partir de los objetos de datos mediante codificación de corrección directa de errores .
26. Un elemento de red en un sistema con capacidad de transmisión punto a multipunto, caracterizado porque uno o más paquetes de datos son transmitidos de un transmisor a uno o más receptores , y en donde por lo menos en un receptor específico de los receptores, se requiere una recepción de paquetes de datos de reparación, el elemento de red comprende: - medios dispuestos para recibir información de reparación señalizada al elemento de red a fin de iniciar una transmisión de los paquetes de datos de reparación, en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor específico.
27. El elemento de red de conformidad con la reivindicación 26, caracterizado porque los paquetes de datos transmitidos están relacionados con objetos de datos, en donde los paquetes de datos de reparación son generados a partir de los objetos de datos mediante codificación de corrección directa de errores, y en donde la codificación de corrección directa de errores tiene la propiedad de que solamente una subserie de todos los paquetes de datos transmitidos están relacionados con un objeto de datos tiene que ser recibida correctamente por un receptor a fin de ser capaz de reconstruir el objeto de datos, el elemento de red comprende: - medios para determinar, al menos parcialmente con base en la información de reparación señalizada, cuántos paquetes de datos de reparación necesitan ser transmitidos al receptor específico a fin de permitirle reconstruir el objeto de datos, y - medios para generar los paquetes de datos de reparación, y - medios para transmitir los paquetes de datos de reparación al menos al receptor específico.
28. El elemento de red de conformidad con la reivindicación 26, caracterizado porque los paquetes de datos transmitidos están relacionados con objetos de datos, que comprende además : - medios dispuestos para generar los paquetes de datos de reparación a partir de los objetos de datos mediante codificación de corrección directa de errores.
29. Un receptor en un sistema con capacidad de transmisión punto a multipunto, caracterizado porque comprende: - medios dispuestos para recibir uno o más paquetes de datos que son transmitidos de un transmisor a uno o más receptores, en donde al menos en el receptor, se requiere una recepción de paquetes de datos de reparación, y - medios para señalizar información de reparación a un servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor.
30. Una aplicación de software ejecutable en un receptor de un sistema con capacidad de transmisión punto a multipunto, caracterizada porque comprende: - un código de programa para hacer que el receptor reciba uno o más paquetes de datos que son transmitidos de un transmisor a uno o más receptores, en donde por lo menos en el receptor, se requiere una recepción de paquetes de datos de reparación; y - un código de programa para hacer que el receptor señalice información de reparación a un servidor de reparación a fin de iniciar una transmisión de los paquetes de datos de reparación, en donde la información de reparación comprende información relacionada con el número de paquetes de datos transmitidos recibidos correctamente en el receptor.