MXPA06008486A - Identificacion y retransmision de partes perdidas - Google Patents

Abstract

La invención se relaciona con un método para transmitir archivos en un sistema con la capacidad de transmisión uno-a-varios, el método comprende transferir uno o más bloques de datos desde un emisor hacia por lo menos un receptor, identificar un bloque de datos que se esperaba recibir pero que no se recibiópor completo o se recibióincorrectamente en el receptor, y proceder para retransmitir el bloque de datos. En el método, la identificación se ejecuta con base en un número de bloque, un identificador de codificación y otra cierta información de identificación.

Description

For two-letter codes and other abbreviations, referto the "Guidance Notes on Codes andAbbreviations" appearing at the begin-ning ofeach regular issue ofthe PCT Gazette.

IDENTIFICACIÓN Y RETRANSMISIÓN DE PARTES PERDIDAS CAMPO DE LA INVENCIÓN La invención se relaciona en general con servicios y tecnología de transmisión de difusión y multidifusión, esto es, servicios con una fuente de datos (o emisor) y por lo menos un receptor. ANTECEDENTES DE LA INVENCIÓN Para servicios uno-a-varios (en este caso, punto-a-multipunto) sobre sistemas tales como multidifusión IP, difusión de datos IP (IPDC, por su siglas en inglés) y servicios de dif sión/multidifusión multimedia (MBMS, por sus siglas en inglés) , la distribución de registros (o distribución discreta de medios o descarga de registros) es un servicio importante. Muchas de las características para la distribución de registros sobre protocolos punto-a-punto tal como protocolos de transferencia de registros (FTP, por sus siglas en inglés) y protocolo de transferencia de hipertextos (HTTP, por sus siglas en inglés) , son problemáticas para uno-a-varios escenarios. En particular, la confiabilidad' de distribución de registros -estos es la distribución garantizada de registros - que utilizan protocolos de reconocimiento (ACK, por sus siglas en inglés) uno-a-uno similares tal como protocolo de control de transmisión (TCP, por sus siglas en inglés) no es viable.

Ref. :174280 El Grupo de Trabajo de Transporte Confiable Multidifución (RMT, por sus siglas en inglés) de la fuerza de Tarea de Ingeniería de Internet (IETF, por sus siglas en inglés) se encuentra dentro del proceso de estandarización de dos categorías de protocolos de transporte multidifusión* de error-resilente. En la primera categoría, la confiabilidad es implementada por medio del uso de la corrección adelantada (proactiva) de error (FEC, por sus siglas en inglés) , esto es, al enviar 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, una retroalimentación del receptor es utilizada con el fin de poner en marcha un transporte multidifusión confiable. La Codificación Por Capas No-sincrónica (ALC, RFC 3450) es un protocolo particularizado que pertenece a la primera categoría, mientras que el protocolo Muitidifusión Confiable Orientada-NACK (NORM, por sus siglas en inglés) es un ejemplo de la segunda categoría. Los detalles de los protocolos ALC y NORM se discuten con mayor detalle en las publicaciones tituladas "la particularización del Protocolo de Codificación .por Capas No-sincrónica (ALC)" (RFC 3450) y "Protocolo Multidifusión Confiable Orientado-NACK" (Redacción en Internet) preparada por el Grupo de Trabajo del IETF. Los contenidos de estas publicaciones son incorporadas aquí en su totalidad como referencia.

Las redes de acceso en las cuales pueden ser utilizados estos protocolos, incluyen, pero no de limita a ellos, las redes de acceso-múltiple inalámbricas tal como redes de acceso por radio del sistema de Servicios De Telecomunicaciones Móviles Universales (UMTS, por sus siglas en inglés) , redes inalámbricas de área local (WLAN) , redes de Difusión - Terrestre de Video Digital (DVB-T) y redes de Difusión - Satelital de Video Digital (DVB-S) . Brevemente,, el protocolo ALC es un esquema proactivo basado en FEC que permite a los receptores reconstruir paquetes o paquetes fragmentados que no se han recibido. El protocolo ALC utiliza la codificación FEC en canales múltiples, lo que permite al emisor enviar datos a múltiples tazas (canales) a receptores posiblemente heterogéneos. Adicionalmente, el protocolo ALC utiliza un mecanismo de control de congestión para mantener diferentes tasas en canales diferentes . El protocolo ALC se puede escalar de forma masiva en términos de número de usuarios debido a que no se requiere señalización de enlace ascendente. Por lo tanto, cualquier cantidad de receptores adicionales no suponen exactamente una demanda incrementada para el sistema. Sin embargo, el protocolo ALC no es 100% confiable debido a que la recepción no está garantizada, por ello en general no se describe como robusta .

NORM, a su vez, especifica el uso de mensajes de reconocimiento negativo (?ACK) con el propósito de señalar cuales paquetes de datos (o definidos de otra forma "bloques de datos" ) que se esperaba llegarán al receptor no fueron recibidos en el receptor (o fueron recibidos incorrectamente) . En otras palabras, los receptores emplean mensajes ?ACK para indicar pérdida o daño de paquetes trasmitidos hacia el emisor. Por consiguiente, un receptor que "perdió" algunos bloques de datos de una transmisión de datos puede enviar un mensaje ?ACK hacia el emisor que 'solicita al emisor re-transmitir el bloque o bloques de datos perdidos. El protocolo ?ORM también opcionalmente permite el uso de la codificación FEC para transmisiones preactivas robustas. Distribución de Archivos ' sobre Transporte Unidireccional (FLUTE, por sus siglas en inglés) es un protocolo de transporte de uno-a-varios que agrega bloques construidos FEC y ALC. Está previsto para la distribución de archivos del emisor (es) hacia el receptor (es) sobre sistemas unidireccionales. Esta tiene especializaciones las cuales la hacen apropiada para los sistemas punto-hacia-multipuntos (multidifusión) . Los detalles del protocolo FLUTE se discuten-con mayor detalle en la publicación titulada "FLUTE - File Delivery over Unidireccional Transport" (Redacción para internet) preparada por el Grupo de Trabajo del IETF mencionado anteriormente. Los contenidos de esta publicación se incorporan por completo aquí como referencia. Los mensajes NACK generalmente no son NORM específicos, pero también pueden ser utilizados en conexión con otros sistemas o protocolos. Cuando se utilizan los mensajes NACK en conexión con sesiones FLUTE (o en otras sesiones que utilizan un protocolo de transporte por capas dirigido específicamente para soportar transmisiones de uno-a-varios) la identificación de los paquetes (o bloques) perdidos es un tema importante. El uso de los protocolos previstos para transmisiones uno-a-uno (o punto-a- unto) , tal como TCP, y sus métodos de reconocimiento no son aquí necesariamente 'viables. Por ejemplo, el uso de los métodos de reconocimiento TCP en un sistema uno-a-varios produciría una cantidad considerable de suplementos. Por consiguiente, existe una necesidad por una identificación confiable de los paquetes no recibidos en un escenario de uno-a-varios para que se pueda ejecutar una retransmisión precisa. SUMARIO DE LA INVENCIÓN Se ha observado que cuando se utilizan mensajes NACK para la transmisión confiable de datos sobre un canal multidifusión/difusión, la identificación de los paquetes perdidos es un asunto importante . Esto involucra el mantenimiento de información referente al estado de la transmisión así como la identificación de bloques que necesitan ser retransmitidos. Se ha observado que en términos de tiempo de respuesta, las solicitudes NACK (enviada por un receptor y recibida por un emisor) pueden ser divididas en 2 categorías : a) Solicitudes NACK que son recibidas inmediatamente o poco después de la transmisión inicial, y pueden ser cumplimentadas dentro de la misma sesión (por ejemplo, una sesión FLUTE o similar) . b) Solicitudes NACK que son recibidas después de que ha expirado una sesión y los datos son requeridos para ser retransmitidos a través de otra sesión. En este caso, la otra sesión puede ser cualquiera del mismo protocolo punto-a-multipunto (por ejemplo, una nueva sesión FLUTE establecida después de que ha expirado una sesión FLUTE antigua) o una sesión que utiliza otro protocolo el cual puede ser uno punto-a-punto o punto-a-multipuntos (por ejemplo, FTP, HTTP, etc . ) . En ambos casos, es importante identificar de forma precisa el bloque (s) a ser retransmitido (s) . De conformidad con un primer aspecto de la invención se proporciona un método para la distribución de archivos en un sistema con la capacidad de transmisión de uno-a-varios, el método comprende : transferir uno o más bloques de datos desde un emisor hacia por lo menos un receptor; identificar un bloque de datos que se esperaba ser recibido pero que no se recibió por completo o se recibió incorrectamente en el receptor; realizar la acción, de retransmitir el bloque de datos, en donde el método comprende : ejecutar la identificación con' base en. un número de bloque, un identificador codificado y otra información de identificación. De conformidad con una modalidad, la otra información comprende un conjunto de parámetros de sesión y/o un identificador de objeto de transmisión. De conformidad con otra modalidad, la otra información comprende información del archivo y/o información de agrupamiento . De conformidad con un segundo aspecto de la invención, se proporciona un dispositivo receptor para distribución de archivos en un sistema con la capacidad de transmisión de uno-a-varios, el dispositivo receptor comprende: medios para recibir uno o más bloques de datos de un emisor; medios para identificar un bloque de datos que se esperaba recibir pero que no se recibió por completo o se recibió incorrectamente; medios para realizar la acción de provocar la retransmisión del bloque de datos, en donde los medios de identificación son configurados para identificar el bloque de datos con base en un número de bloque, un identificador de codificación y otra información de identificación . De conformidad con un tercer aspecto de la invención, se proporciona un dispositivo emisor para la distribución de archivos en un sistema con la capacidad de transmisión de uno-a-varios, el dispositivo emisor comprende: medios para transmitir uno o más bloques de datos hacia por lo menos un receptor; y medios para retransmitir un bloque de datos que se esperaba recibir pero no se recibió completamente o se recibió de forma incorrecta en el receptor, el bloque de datos que ha sido identificado con base en el número de bloque, un identificador de codificación y otra información de identificación. De conformidad con un cuarto aspecto de la invención, se proporciona un sistema con la capacidad de transmisión de uno-a-varios, el sistema comprende: medios para transferir uno o más bloques de datos de un emisor a al menos un receptor; medios para identificar un bloque de datos que se esperaba recibir pero no recibió completamente o se recibió de forma incorrecta en el. receptor; medios para realizar la acción de retransmitir los bloque de datos, en donde los medios para identificar son configurados para la identificación de los bloques de datos sobre la base del número de bloque, un identificadpr de codificación y otra información de identificación. De conformidad con un quinto aspecto de la invención, se proporciona una aplicación de programa ejecutable en un dispositivo receptor para distribución de archivos se proporciona un sistema con la capacidad de transmisión de uno-a-varios, la aplicación de programa computacional comprende: un código de programa para provocar que el dispositivo receptor reciba uno o más bloques de datos de un emisor ; un código de programa para identificar un bloque de datos que se esperaba recibir pero no se recibió por completo o se recibió incorrectamente; código de programa para provocar que el dispositivo receptor efectúe una acción con el propósito de provocar una retransmisión del bloque de datos, en donde el código de programa para la identificación está configurado para la identificación del bloque de datos con base en el número de bloque, un identificador de codificación y otra información de identificación. De conformidad con un sexto aspecto de la invención, se proporciona un programa computacional de aplicación ejecutable en un dispositivo emisor para distribución de archivos en un sistema con la capacidad de transmisión uno-a- varios, el programa de computación de aplicación comprende: un código de programa para provocar el dispositivo emisor para transmitir uno o más bloques de datos hacia al menos un receptor; y un código de programa para provocar que el dispositivo emisor retransmita un bloque de datos que se esperaba recibir pero no se recibió completamente o se recibió incorrectamente en el receptor, el bloque de datos que ha sido identificado con base en un número de bloque, un identificador de código y otra información de identificación. Las aplicaciones del programa computacional pueden ser productos de programa de computadoras, que comprenden el código de programa, almacenado en un medio de almacenamiento, tal como una memoria. De conformidad con aun otro aspecto de la invención se proporciona un método para la distribución de archivos en un sistema de transmisión de uno-a-varios, el método comprende: transferir uno o más bloques de datos desde un emisor hasta por lo menos un receptor; identificar bloques de datos perdidos que se deben retransmitir con base en los intervalos de número de bloque y/o identificador de codificación. Este aspecto de la invención puede ser comprendida como un aspecto separado o como un aspecto a ser llevado a cabo junto con otro(s) aspecto (s) de la invención. Los intervalos de número de bloque e intervalos de identificadores de codificación pueden ser contiguos o no contiguos. Un dispositivo receptor, un dispositivo emisor, sistema y aplicaciones de programa computacional pueden ser respectivamente implementados . Reivindicaciones dependientes relacionadas con las modalidades de la invención. La materia objeto contenida en las reivindicaciones dependientes que se relacionan con un aspecto particular de la invención también es aplicable a otros aspectos de la invención. BREVE DESCRIPCIÓN DE LAS FIGURAS A continuación se describirán las modalidades de la invención a manera de ejemplo con referencia a las figuras anexas en las cuales : Figura 1: - muestra un dispositivo emisor y un dispositivo receptor en comunicación de conformidad con una modalidad de la invención; Figura 2A: ilustra una arquitectura de protocolo simplificado de conformidad con una modalidad de la invención; Figura 2B : ilustra una arquitectura de protocolo simplificada de conformidad con . otra modalidad de la invención; Figura 3 : muestra un sistema y detalles de un dispositivo receptor de conformidad con una modalidad de la invención; y - A- ~ • Figura 4 : muestra un dispositivo emisor de conformidad con una modalidad de la invención. -' DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La materia objeto contenida en la parte de introducción de esta solicitud de patente puede ser empleada para dar soporte a la descripción detallada. A continuación se utiliza como ejemplo el protocolo de Distribución de Archivos sobre Transporte Unidireccional (FLUTE) , sin la intención de limitar la presente invención al uso exclusivo del FLUTE. También es aplicable cualquier otro protocolo apropiado con la capacidad de distribución de archivos de uno-a-varios dentro del contexto de la presente invención. La Figura 1 muestra un dispositivo emisor y un dispositivo receptor comunicados de conformidad con una modalidad de la presente invención. El dispositivo emisor 10 es un servidor, dispositivo basado-en IP, dispositivo DVB, dispositivo GPRS (o UMTS) o un dispositivo similar que puede utilizar opcionalmente una corrección de error adelantada preactiva, tal como . un mecanismo ALC, para enviar bloques de datos multidifusión (o paquetes) hacia el dispositivo receptor 20. El dispositivo receptor 20 envía mensajes de reconocimiento negativo NACK (o solicitudes) hacia el dispositivo emisor 10 que concierne a los bloques perdidos (bloques no recibidos o recibidos incorrectamente) . En respuesta al mensaje(s) NACK, el dispositivo emisor 10 retransmite los bloques perdidos hacia el dispositivo receptor 20 en una sesión FLUTE (la misma sesión como la sesión FLUTE original establecida para la transmisión original, o una sesión FLUTE subsecuente) . Alternativamente se puede utilizar una sesión diferente a la que utiliza el protocolo FLUTE. En cierto contexto, una sesión de retransmisión es denominada como sesión de reparación. Los datos son transferidos como objetos. Por ejemplo, un archivo, una imagen JPEG, piezas de archivos, todos .son objetos. Una sesión es establecida entre el dispositivo emisor 20 y el dispositivo receptor 20 para la distribución de archivos (o datos) . Una sesión sencilla puede incluir la transmisión de un objeto individual o múltiples objetos. Diferentes identificadores son utilizados para identificar los objetos y las sesiones. Cada sesión, es identificada mediante la dirección (por ejemplo, una dirección IP) del emisor (fuente) , las direcciones del receptor (destino) y el identificador de sesión de transmisión (TSI, por sus siglas en inglés) o similar. También es posible utilizar únicamente la dirección del emisor o receptor y el TSI . Adicionalmente, el identificador de objeto de transmisión (TOI, por sus siglas en inglés) o similar es utilizado para señalar el objeto al cual el paquete es transmitido en una sesión particular perteneciente. Por ejemplo, un dispositivo emisor 5 10 podría enviar un número de archivos en la misma sesión que utiliza un TOI de 0 para el primer archivo, 1 para el segundo y así consecutivamente. Cada bloque de datos tiene un número llamado número de bloque fuente (SBN, por sus siglas en inglés) o similar, la . cual identifica cada bloque. Los bloques son presentados por un conjunto de símbolos de codificación. Un identificador de símbolo de codificación (ESI, por sus siglas en inglés) o similares, a su vez, indica cómo los símbolos de codificación portados en la carga neta de un paquete de datos (o bloque)' fueron generados a partir de los objetos mencionados anteriormente (por ejemplo, archivos) . La Figura 2A ilustra una arquitectura de protocolo simplificada de conformidad con una modalidad de la invención. De conformidad con esta modalidad, la pila de 0 protocolo a ser implementada por el dispositivo emisor 10 y el dispositivo receptor 20 comprende una capa de aplicación, capa de protocolo FLUTE, capas UDP e IP y capas inferiores. La capa de protocolo FLUTE se construye sobre la particularización del protocolo ALC del bloque (no se 5 muestra) preconstruido de transporte de codificación en capas (LCT, por sus siglas en inglés) . También pueden ser utilizados opcionalmente los bloques preconstruidos FEC. La capa de protocolo FLUTE junto con los mensajes NACK están previstos para proporcionar una transmisión de bloque de datos confiable desde el dispositivo emisor 10 hasta el dispositivo receptor 20. Esta arquitectura de protocolo puede ser utilizada para una transmisión de uno-a-varios (tanto para las "primeras" transmisiones" uno-a-varios como para las retransmisiones un -a-varios) . Alternativamente, en una modalidad una capa TCP puede ser utilizada en lugar de la capa UDP (ver Figura 2B) . Esto aplica para el caso en el cual una sesión de reparación punto-a-punto (aquí: sesión TCP) es utilizada para retransmisiones uno-a-uno (en este caso, punto-a-punto) . Se presenta la descripción de métodos diferentes de retransmisión más adelante en esta descripción. A continuación, se presentan diferentes casos para un receptor para identificar un conjunto de paquetes perdidos (o bloques) . Existen dos métodos para identificar el bloque fuente FLUTE o el símbolo de codificación (y, como resultado, uno o una serie de paquetes) : Método de identificación A La identificación es ejecutada con base en el SBN y el ESI, así como los parámetros de sesión FLUTE (dirección fuente, dirección de destino y el TSI) y el TOI (Identificador de Objeto de Transmisión) . Típicamente, éste es el dispositivo emisor que genera esta información mientras que transmite los paquetes FLUTE. La información es contenida en los paquetes ALC/FLUTE. Método de identificación B La identificación se ejecuta con base en el SBN y el ESI, así como en base en el archivo (en este caso, el URI del archivo distribución) , parámetros del archivo (longitud del archivo y el código de encriptación (tal como el código MD5) , los algoritmos de agrupamiento usado y los parámetros de agrupamiento (longitud máxima del bloque fuente, longitud del símbolo de codificación y la longitud del archivo) . La información es tomada desde un FDT (Tabla de Definición de Archivos) o similares, la cual contiene estos parámetros/información. La información típicamente es portada como un objeto separado por la sesión FLUTE. Como se puede observar, ambos métodos de identificación A y B hacen uso de un número bloque y un identificador de codificación y, adicionalmente cierta información de identificación diferente. El método de identificación A utiliza detalles que se pueden obtener directamente de la misma sesión (aquí: sesión FLUTE) , mientras que el método de identificación B utiliza también otra información (por ejemplo, información sobre el archivo distribución) . Independientemente del método de identificación, existen las siguientes posibilidades para ejecutar la subsecuente retransmisión: Método de retransmisión A La sesión FLUTE es utilizada para la retransmisión (la retransmisión puede ser efectuada dentro de la misma sesión FLUTE (en curso) o en una sesión FLUTE separada) . El método se puede basar en una transmisión punto-a-punto o punto-a-multipunto. Método de retransmisión B Utiliza una sesión separada para la retransmisión con un método diferente que el FLUTE, por ejemplo, HTTP, SMS, FTP, SAP, GPRS, etc. El método se puede basar en una transmisión pünto-a-punto o punto-a-multipunto. Por consiguiente, los dos métodos de identificación diferentes y el uso del protocolo FLUTE u otro protocolo para la retransmisión producen cuatro diferentes combinaciones para identificar y retransmitir paquetes . 1. Identificación que utiliza el método A y la retransmisión que utiliza el método A; 2. Identificación que utiliza el método B y la retransmisión que utiliza el método B; 3. Identificación que utiliza el método A y la retransmisión que utiliza el método B; y 4. Identificación que utiliza el método B y la retransmisión que utiliza el 'método A.

Por lo anterior se asume que durante la transmisión, cada símbolo codificado es contenido dentro de uno y únicamente un paquete. Sin embargo, si son incluidos múltiples símbolos codificados dentro del mismo paquete o si un símbolo codificado es ampliado hacia múltiples paquetes, entonces el símbolo codificado (y la parte del paquete que contiene un símbolo codificado o la serie de paquetes que contiene un símbolo codificado individual respectivamente) necesita ser identificado de manera apropiada. La primera combinación (A+A) es combinada útil en una situación en la cual es deseable la retransmisión de paquetes en el mismo canal, utilizando la misma información del emisor (o servidor) y dentro de la misma sesión FLUTE, dentro de un periodo de corto plazo. El emisor FLUTE puede, por ejemplo, almacenar (o almacenar temporalmente) todos los SBNs y ESIs enviados en los últimos 5 minutos. Si una solicitud de retransmisión (NACK) llega dentro de este periodo, este método es aplicable. La segunda combinación (B+B) es considerada útil en una situación en la cual se necesita la retransmisión después de que ha concluido la sesión en curso, posiblemente mucho después. Conforme se almacena toda la información de largo-plazo acerca de las transmisiones durante la sesión podría no ser factible para el dispositivo emisor 10, en una modalidad la cual no es una limitante, un "tercer servidor" o un servidor de reparación (o simplemente un servidor separado (no se muestra) ) es configurado para almacenar información de transmisión. Este servidor puede, por ejemplo, estar coubicado con el servidor emisor original (por ejemplo, un MBMS (Servicio de Difusión/Difusión Multimedia) , también llamado BM-SC (Centro de Servicio - Difusión Multidifusión) ) , o, por ejemplo, ser un servidor separado dentro de red del operador UMTS . Este servidor después puede retransmitir los paquetes perdidos en un periodo posterior. Un ejemplo de esto es un servidor que retransmite paquetes perdidos sobre un GPRS o UMTS durante la noche, cuando el acceso GPRS (UMTS) puede ser más económico. La retransmisión también puede iniciar inmediatamente después de que ha finalizado sesión de transmisión, o después en cualquier momento aleatorio y antes de que los datos sean recibidos por el dispositivo receptor 20, con el propósito de evitar sobrecargar el dispositivo emisor 10 con solicitudes de retransmisión (NACKs) provenientes de varios dispositivos receptores 20. La idea de contar con un servidor de reparación separado también aplica a otras modalidades. Los siguientes pasos ilustran una modalidad ejemplar de lo anterior: 1. El dispositivo emisor 10 transmite uno o más archivos que utilizan una sesión FLUTE. 2. Al final de la sesión, el dispositivo receptor 20 envía uno o más mensajes NACK para todos los paquetes que no lo(s) recibieron. Este mensaje NACK significa el inicio de una nueva sesión. 3. El dispositivo emisor 10 reenvía todos los datos solicitados por el dispositivo receptor 20 en una nueva sesión. 4. La sesión creada nuevamente después es cerrada en el dispositivo emisor 10 y en el dispositivo receptor 20. De acuerdo a un ejemplo que relaciona el paso 2 anterior,- el siguiente método puede ser utilizado para enviar NACK para datos que utilizan un SBN y ESIs específicos sobre un HTTP.: http: //www. 3 . com. /greatmusic/numberl . mp3 ?mbms-rel6-flute-repair&SBN=123 ; ESI=234 . Aquí el SBN y ESI son el Número de Bloque Fuente y el Símbolo Codificado ID de las partes del archivo que son reconocidas negativamente (esto es, consideradas NACK) . Aquí el nombre del archivo es numberl . mps y el SBN y ESi considerados NACK son 123 y 234, respectivamente. En la anterior consulta de HTTP, los campos SBN y ESI también pueden ser utilizados para considerar NACK para los intervalos de SBN y ESI. Por ejemplo, http: //www. 3 . com. /greatmusic /number 1. mp3 ?mbms-rel6-flute-repair&SBN=123&126&127;ESI=234 -238. Los NACKs anteriores para el archivo numberl . p3, SBN 123, 126 y 127 y ESI 234 a ESI 238.

Son posibles otras diferentes combinaciones, por ej emplo : a) SBN;ESI_list (por ejemplo, ...&SBN=123 ;ESI=234, 236, 238) (una lista de ESIs perdidos dentro del mismo SBN) b) SBN;all_symbols (por ejemplo, ...&SBN=123) (todos los ESIs que pertenecen al SBN 123 se encuentran perdidos) c) SBN-range; all_symbols (por ejemplo, ...&SB?=123-129) (todos los ESIs que pertenecen al intervalo SB? de 123- 129 se encuentran perdidos) d) "intervalos no contiguos" d.l) (por ejemplo, ...&SB?=123 ;ESI=234+SB?=200;ESI=23) (ESI 234 que pertenece al SB? 123 y ESI 23 que pertenece al SB? 200 se encuentran perdidos) , o d.2) (...&SB?=123-129+SB?=200;ESI=23-59+SB?=200;ESI=101) (todos los ESIs que pertenecen al intervalo SB? de 123-129 y todos los ESIs en el intervalo 23-59 que pertenecen al SB? 200 y el ESI 101 que pertenece al SB? 200 se encuentran perdidos) . Es posible que un ?ACK contenga una solicitud para la retransmisión de uno o más paquetes. Es más eficiente incluir todas las solicitudes de paquetes dentro de una solicitud ?ACK individual si esta es transmitida de forma confiable sobre el canal de red. De otra forma, todos los paquetes pueden ser solicitados por medio de varios NACKs . A continuación se describe aun otra modalidad de la invención para retransmitir paquetes que han sido perdidos durante una cierta sesión FLUTE. Esta modalidad es independiente de las cuatro combinaciones identificación/retransmisión anteriores . En esta modalidad el contexto de sesión FLUTE (SBN, ESI, TSI y TOI) es almacenado para un uso no-FLUTE posterior. Este contexto después puede ser utilizado para transmitir datos que utilizan un método no-FLUTE. Para llevar a cabo esto, se considera útil contar con un identificador, por ejemplo, un ID de multidifusión, el cual identifica únicamente el "contexto de sesión" . Aquí el "contexto de sesión" puede, por ejemplo, ser el total de los identificadores de la sesión combinada para formar un identificador único para la sesión. Se deberá observar que aun cuando el método de retransmisión usado aquí es el mismo como en la combinación del método 4 descrito al principio, existe una diferencia con respecto al almacenamiento de la información de sesión. En una modalidad, la información de sesión es almacenada por ambos dispositivos, el dispositivo emisor y el dispositivo receptor y es comunicada entre el dispositivo emisor y el dispositivo receptor exteriormente a una sesión FLUTE.

De conformidad con aun otra modalidad de la invención,' el dispositivo receptor 20, en lugar de calcular los paquetes que necesitan retransmitirse, calcula los intervalos de bytes (del objeto original transmitido por el dispositivo emisor 10) que necesitan retransmitirse. También en esta modalidad, el SBN y ESI pueden ser utilizados en la identificación.. El dispositivo receptor envía un mensaje NACK por los intervalos de "bytes no recibidos. Es pos'ible que existan, múltiples intervalos de bytes dentro del mismo paquete . En respuesta al mensaje NACK, el dispositivo emisor 10 retransmite los intervalos de bytes del objeto original. En lugar de los intervalos de bytes, el dispositivo receptor 10 también puede calcular intervalos de bits así como intervalos de palabras y los solicita para ser retransmitidos. En otra modalidad de la invención, la pérdida redundante, más que la fuente, los símbolos codificados del bloque (s) fuente son identificados y todos o un subconjunto son retransmitidos, El NACK enviado desde los dispositivos receptores 20 hacia los dispositivos emisores 10 (podría existir más de un dispositivo emisor) son de esa forma basados en los símbolos redundantes. Este esquema es particularmente aplicable a los esquemas sistemáticos FEC en donde solamente "símbolos redundantes" codificados • son transmitidos y los "símbolos fuente" no decodificados no lo son y, típicamente, un cierto número de umbral de los símbolos codificados redundantes de cada bloque fuente son requeridos para completar los bloques de fuente y de esa forma reconstruir el archivo. Por ejemplo, en un esquema FEC ejemplar el caso puede ser que existan 1000 símbolos transmitidos por el dispositivo emisor, para cada bloque fuente, y exactamente 500 es el número umbral requerido para ser recibido por el-dispositivo receptor para completar (o ejecutar correctamente) la distribución del archivo. Sin embargo, en este caso ejemplar, el dispositivo receptor obtiene solamente 490 símbolos (asumiendo ' que únicamente símbolos codificados de un bloque fuente individual se encuentran perdidos; si los símbolos codificados provenientes de varios bloques fuente se encuentran perdidos, entonces el siguiente cálculo necesita ser llevado a cabo para cada bloque fuente que tiene símbolos perdidos) . En tal escenario, existen las siguientes posibilidades las cuales aplican por bloque fuente de cada archivo: 1. El dispositivo receptor identifica los símbolos perdidos; el dispositivo receptor calcula cuánto es suficiente para completar el bloque; el dispositivo receptor considera NACK a un ' sub-conjunto de símbolos perdidos (suficiente para completarlo) ; el dispositivo emisor reenvía estos símbolos, 2. El dispositivo receptor identifica los símbolos perdidos; los NACKs del dispositivo receptor considera NACK a todos los símbolos perdidos; el dispositivo emisor reenvía todos estos símbolos, 3. el dispositivo receptor identifica los símbolos perdidos; el dispositivo receptor considera NACK a todos los símbolos perdidos; el dispositivo emisor calcula cuánto es suficiente para completar el bloque; el dispositivo selecciona un subconjunto de símbolos perdidos (numeración "suficiente"); el dispositivo emisor reenvía estos símbolos, 4. El dispositivo receptor reconoce (ACKs) los símbolos recibidos; el dispositivo emisor identifica los símbolos perdidos; el dispositivo emisor reenvía todos estos símbolos.

. El dispositivo receptor considera ACK los símbolos recibidos; el dispositivo emisor identifica los símbolos perdidos; el dispositivo emisor calcula cuantos son suficientes para completar el bloque; el dispositivo emisor selecciona un subconjunto de símbolos perdidos (numeración "suficiente"); el dispositivo emisor reenvía estos símbolos.

La selección de combinación de NACKs (o ACKs) de esta forma, más que un símbolo, más que un bloque fuente y/o más de un archivo como referencias a cada NACK es un asunto a favor de la optimización de la aplicación. La definición de símbolos "suficientes" puede ser exactamente el número requerido para completar el número de umbral (10 de cada 510 en el ejemplo anterior) especialmente cuando la reparación se puede efectuar confiablemente por algunos otros medios (como el transporte TCP) , o puede ser más que el tomar en cuenta las pérdidas en la conexión (por ejemplo, en el ejemplo anterior 51% de .los símbolos se perdieron, por eso si las mismos canales de comunicación se utilizarán otra vez uno podría esperar algo semejante, así tal vez sería más apropiado reenviar 10* (100/51) =20 símbolos.

También, se puede agregar un margen de seguridad adicional (por ejemplo, para detectar ráfagas de errores) , por eso si existieran 3 símbolos, entonces uno podría repararla con 23 símbolos aun cuando solamente se requieran 10 para "aprobarla". Ambos, este multiplicador (aquí: "100/51") y constante (aquí: 3) pueden asumir perdidas uniformes de paquetes (como en esos ejemplos) o depender de los patrones de pérdida de la transmisión original. Por ejemplo, un dispositivo emisor puede analizar el distribución de los símbolos perdidos y si no fueron uniformes (por ejemplo, frecuentemente se pierden 3 símbolos consecutivos por cada 20 símbolos) entonces algunos (por ejemplo, e por 20 símbolos) símbolos adicionales pueden ser agregados (lo que resulta nuevamente en 23 símbolos en este ejemplo) . Un ejemplo adicional sería que después de identificar el número de umbral de 10 símbolos de un bloque fuente requerido para completar el archivo, el dispositivo receptor envía un NACK hacia el dispositivo emisor solicitando la retransmisión de estos 10 símbolos. El dispositivo emisor puede reenviar estos símbolos conforme han sido guardados al principio o, en un método alternativo, el dispositivo emisor ejecuta una repetición de codificación FEC en el archivo (s) y bloques fuente correspondientes a los símbolos y retransmite estos símbolos. Este último método permite la transmisión inicial y repara la funcionalidad de servidor para ser desacoplada, y posiblemente ser desplegada dentro eguipo servidor distinto. Otro ejemplo adicional sería que el dispositivo receptor envía un NACK para cada uno de los 510 símbolos perdidos (o, en una modalidad alternativa se reconoce que ha recibido 490 " símbolos) . El dispositivo emisor entonces retransmite solamente 10 símbolos perdidos o retransmite el total de los 510 símbolos perdidos. La retransmisión puede conformarse por los símbolos guardados previamente o símbolos codificados-FEC nuevamente. En adición a la solicitud de retransmisión (o reparación), enviada desde el dispositivo (s) receptor hacia el dispositivo (s) emisor, con base en los símbolos identificados, la solicitud puede especificar uno o más intervalos de bytes en el archivo, y/o sus bloques fuente. Esto es aplicable si los símbolos recibidos son los suficientes para calcular los intervalos de bytes perdidos de los bloques . Se ha descrito que la transmisión punto-a-punto o punto-a-multipunto puede ser utilizada para retransmitir paquetes perdidos. Una modalidad que aclara esto, es dirigida para la retransmisión punto-a-multipunto (o reparación). En esta modalidad, cada dispositivo receptor relacionado envía un mensaje de reconocimiento negativo (NACK) hacia el dispositivo emisor sobre " una conexión punto-a-punto (o sesión) . Dependiendo del número y/o contenido ' de NACKs recibidos en el dispositivo emisor, el dispositivo emisor efectúa una decisión: 1) si envía el bloque (s) perdido (s) de forma separada hacia cada dispositivo receptor utilizando una conexión (es) punto-a-punto; o 2) si envía el bloque (s) perdido (s) utilizando una conexión punto-a-multipunto (que es, multidifusión o. de difusión o similar) . Si un gran número de dispositivos receptores envía solicitudes NACK relacionadas con los mismos paquetes perdidos, la segunda opción puede ser más deseable. En esta forma, con una retransmisión individual, es posible realizar múltiples reparaciones de los receptores y ahorrar recursos .

La Figura 3 muestra un sistema y detalles de un dispositivo receptor de conformidad con una modalidad de la invención. El sistema comprende al dispositivo emisor 10 una red de transmisión 30, por ejemplo una red IP u otra red fija, una red inalámbrica o una combinación de una red fija y una inalámbrica (celular), etc., y el dispositivo receptor . El dispositivo receptor 20 puede ser un teléfono celular, un teléfono satelital, un asistente personal digital o un dispositivo Bluetooth, dispositivo WLAN, dispositivo DVB, u otro dispositivo inalámbrico similar. El dispositivo 20 incluye una memoria interna 21, un procesador 22, un sistema operativo 23, programas de aplicación 24, una interface de red 25 y un mecanismo de identificación y NACK 26. La memoria interna 21 aloja al procesador 22, el sistema operativo 23 y programas de aplicación 24. El mecanismo de identificación y NACK 26 permite la identificación de los paquetes de datos y la transmisión de NACKs o datos hacia el dispositivo emisor en respuesta a los bloques de datos perdidos o fraccionados en una transmisión de datos. El dispositivo 20 tiene la capacidad de comunicarse con el dispositivo emisor 10 y otros dispositivos por medio de la interface de red 25 y la red 30. La Figura 4 muestra un dispositivo emisor 10 de conformidad con una modalidad de la invención. El dispositivo emisor 10 puede ser, por ejemplo, un servidor de red o cualquier dispositivo apropiado previsto para la transmisión de archivos (o sistemas de medios) . El dispositivo 10 incluye una memoria interna 11, un procesador 12, un sistema operativo 13, programas de aplicación 14, una interface de red 15 y un mecanismo .de transmisión y retransmisión 16. La memoria interna 11 aloja al procesador 12, sistema operativo 13 y los programas de aplicación 14. El mecanismo de transmisión y retransmisión 16 permite la transmisión de paquetes de datos y la retransmisión de paquetes de datos en respuesta a los NACKs recibidos desde el dispositivo receptor 20. El dispositivo 10 tiene la capacidad de comunicarse con el dispositivo receptor 20 y otros dispositivos por medio de la interface de red 15 y la red 30. Los procedimientos relacionados con la identificación de los paquetes de datos perdidos y la retransmisión de los mismos pueden ser ejecutados mediante un programa computacional . Un producto de programa computacional que comprende un código de programa almacenado en el dispositivo receptor 20 y que corre en el procesador 22 se puede utilizar para ejecutar los procedimientos al termino de la recepción de la sesión de transmisión, mientras que un producto de programa de computadora que comprende un código de programa almacenado en el dispositivo emisor 10 y corre en el procesador 12 puede ser utilizado para ejecutar los procedimientos al termino de la transmisión. A continuación se discuten las ventajas de las modalidades de la invención. Las modalidades de la invención proporcionan una nueva red para retransmitir datos perdidos .

Conforme a lo clarificado por lo anterior, este marco permite la retrasmisión de datos perdidos en ' los siguientes escenarios : • Dentro de una sesión FLUTE, cuando la información concerniente a los paquetes perdidos aun se encuentra disponible en el dispositivo emisor y el NACK es recibido por el dispositivo emisor dentro de una dimensión de poco tiempo. • Cuando se requiere retransmitir paquetes perdidos fuera del la sesión FLUTE original en la. cual fueron transmitidos originalmente. Esta retransmisión puede ocurrir utilizando una FLUTE o utilizando otro método de transmisión. Algunas de las ventajas que proporciona las modalidades son: • Un método para identificar (contiguos o no contiguos) únicamente bloques (o paquetes) perdidos. • Un método para identificar bloques perdidos (o paquetes) de un (o múltiples) archivo (s) sobre la misma (o número de) sesión(es). • Un método para identificar y retransmitir bloques perdidos (o paquetes) sobre un número de protocolos de transmisión. • La capacidad para retransmitir paquetes perdidos en un tiempo apropiado. En donde el tiempo apropiado se selecciona utilizando un número de criterios posibles (tal como disponibilidad de banda ancha, portadores más baratos, etc. ) • La capacidad para retransmitir los paquetes perdidos de forma confiable (si el protocolo de transporte señalado es confiable) y con una sesión de transferencia de reparación individual . Por consiguiente, las modalidades de la invención presentan métodos para identificar y enviar mensaje de reconocimiento negativo (NACK) para los bloques perdidos ya sea dentro o fuera de una sesión multidifusión uno-a-muchos .

Se han descrito las ejecuciones y modalidades particulares de la invención. Es claro para una persona experimentada en la técnica que la invención no se restringe a los detalles de las modalidades presentadas anteriormente, sino que se pueden llevar a cabo otras modalidades utilizando medios equivalentes sin desviarse de las características de la invención. El alcance de la invención únicamente está restringido por las reivindicaciones de patente anexas . Se hace constar que con relación a esta fecha, el mejor método conocido por el 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 (35)

1. 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 archivos en un sistema con la capacidad de transmisión uno-a-muchos-, . caracterizado porque comprende : transferir uno o más bloques de datos desde un emisor hacia por lo menos un receptor; identificar un bloque de datos que se esperaba recibir pero que no se recibió completamente o se recibió incorrectamente en el receptor; efectuar la acción de retransmitir el bloque de datos, en donde el método comprende : ejecutar la identificación con base en un número de bloque, un identificador de codificación y otra información de identificación.
2. 2. El método de conformidad con la reivindicación 1, caracterizado porque la otra información de identificación comprende un conjunto de parámetros de sesión.
3. 3. El método de conformidad con la reivindicación 1, caracterizado porque la otra información de identificación comprende un identificador de objeto de transmisión.
4. 4. El método de conformidad con la reivindicación 1, caracterizado porque se utiliza un protocolo de basado en sesión dirigido a la transmisión de archivos sobre un transporte unidireccional y con la capacidad de un escenario de transmisión uno-a-varios.
5. 5. El método de conformidad con la reivindicación 4, caracterizado porque el protocolo es FLUTE (Transmisión de Archivos sobre Transporte Unidireccional) o similar y el número de bloque es un número de bloque fuente (SBN) , el identificador de codificaciones es un identificador de símbolo de codificación (ESI) , un conjunto de parámetros de sesión a ser utilizados en la identificación, son seleccionados de un grupo que consiste de : una dirección fuente, una dirección destino y un identificador de sesión de transmisión (TSI) , • y en donde se utiliza para la identificación un identificador de objeto de transmisión (TOI) de acuerdo a lo definido por FLUTE.
6. 6. El método de conformidad con la reivindicación 1, caracterizado porque la otra información de identificación comprende información del archivo.
7. 7. El método de conformidad con la reivindicación 1, caracterizado porque la otra información de identificación comprende información de agrupamiento.
8. 8. El método de conformidad con la reivindicación 1, caracterizado porque se utiliza un protocolo basado en sesión dirigido a la transmisión de archivos sobre transporte unidireccional y con la capacidad de un escenario de transmisión uno-a-varios.
9. 9 . El método de conformidad con la reivindicación 8, caracterizado porque el protocolo es FLUTE (Transmisión de Archivos sobre Transporte Unidireccional) o similar y el número de bloque es un número de bloque fuente (SBN) , el identificador de codificación es un identificador de símbolo de codificación (ESI) , la información del archivo a ser utilizada para la identificación se selecciona de grupo que consiste de: un indicador uniforme de recurso (URI, por sus siglas en inglés) del archivo y parámetros de archivo, tal como longitud de archivo y código de encriptación, tal como el código MD5 , y en donde la información de agrupamiento que se utilizará para la identificación se selecciona de un grupo que consiste de : un algoritmo de agrupamiento usado y parámetros de agrupamiento, tal como longitud de bloque fuente máxima, longitud de símbolo codificado y longitud de archivo .
10. 10. El método de conformidad con la reivindicación 1, caracterizado porque comprende proporcionar una sesión entre el emisor y el receptor para la transmisión del bloque de datos que utiliza un protocolo, tal como FLUTE o similar, dirigido para la transmisión en un escenario uno-a-varios.
11. 11. El método de conformidad con la reivindicación 1, caracterizado porgue efectuar la acción de retransmitir el bloque de datos comprende enviar un mensaje de reconocimiento negativo (NACK) desde el receptor hacia el emisor,
12. 12. El método de conformidad con la reivindicación 11, caracterizado porque la transmisión de archivos se lleva a cabo en una primera sesión y el mensaje de reconocimiento negativo provoca que la retransmisión ocurra durante la misma primera sesión.
13. 13. El método de conformidad con la reivindicación 11, caracterizado porque la transmisión de archivos se lleva a cabo en una primera sesión y el mensaje de reconocimiento negativo provoca que la retransmisión ocurra durante una .sesión diferente a la primera sesión.
14. 14. El método de conformidad con la reivindicación 13 , caracterizado porque la otra sesión es una sesión establecida después de la primera sesión la cual ha finalizado.
15. 15. El método de conformidad con la reivindicación 11, caracterizado porque el mensaje de reconocimiento negativo comprende una solicitud para retransmitir uno o más bloques o paquetes de datos .
16. 16. El método de conformidad con la reivindicación 15, caracterizado porque el mensaje de reconocimiento negativo es transmitido durante la finalización de una sesión de transmisión, el mensaje de reconocimiento negativo que indica un inicio de una nueva sesión con el propósito de ejecutar la retransmisión de los bloques de datos perdidos .
17. 17. El método de conformidad con la reivindicación 1, caracterizado porque un contexto de sesión es almacenado para un uso posterior.
18. 18. El método de conformidad con la "reivindicación 17, caracterizado porque el contexto de sesión comprende identificadores dentro de la sesión, tal como un número de bloque fuente (SBN) , un identificador de símbolo de codificación (ESI) , un identificador de sesión de transmisión (TSI) , y un identificador de objeto de transmisión (TOI), así como únicamente un identificador que identifica el mismo contexto de --- sesión.
19. 19. El método de conformidad con la reivindicación 1, caracterizado porque la transmisión inicial de bloque de datos se lleva a cabo en una sesión FLUTE y la retransmisión se ejecuta en la misma o en diferente sesión FLUTE u otra sesión.
20. 20. El método de conformidad con la reivindicación 1, caracterizado porque un mensaje de reconocimiento negativo es enviado desde un conjunto de receptores hacia el emisor sobre una sesión punto-a-punto, y se ejecuta una retransmisión sobre una sesión punto-a-multipuntos .
21. 21. El método de conformidad con la reivindicación 20, caracterizado porque el conjunto de receptores comprende más de un receptor.
22. 22. El método de conformidad con la reivindicación 1, caracterizado porque la retransmisión es ejecutada mediante una transmisión de difusión sencilla (punto-a-punto) .
23. 23. Un dispositivo receptor para transmitir archivos en un sistema con la capacidad de transmisión uno-a-varios, caracterizado porque comprende : medios para recibir uno o más bloques de datos provenientes de un emisor; medios para identificar un bloque de datos que se esperaba recibir pero que no se recibió por completo o se recibió incorrectamente; medios de procedimiento con el propósito de provocar la retransmisión del bloque de datos, en donde los medios para la identificación están configurados para la identificación del bloque de datos con base en un número de bloque, un identificador de codificación y otra información de identificación.
24. 24. El dispositivo receptor de conformidad con la reivindicación 23, caracterizado porque la otra información de identificación comprende un conjunto de parámetros de sesiones.
25. 25. El dispositivo receptor de conformidad con la reivindicación 23 , caracterizado porque la otra información de identificación comprende un identificador de objeto de transmisión.
26. 26. El dispositivo receptor de conformidad con la reivindicación 23 , caracterizado porque la otra información de identificación comprende información del archivo.
27. 27. El dispositivo receptor de conformidad con' la reivindicación 23 , caracterizado porque la otra información de identificación comprende información de agrupamiento.
28. 28. Una aplicación de programa computacional ejecutable ' en un dispositivo receptor para transmitir archivos en un sistema con la capacidad de transmisión uno-a-varios, caracterizada porque comprende: código de programa para provocar que el dispositivo receptor reciba uno o más bloques de datos desde un emisor; código de programa para identificar un bloque de datos que se esperaba recibir pero que no se recibió por completo o se recibió incorrectamente; código de programa para provocar que el dispositivo receptor proceda con el propósito de provocar la retransmisión del bloque de datos, en donde el código de programa para la identificación está configurado para la identificación del bloque de datos con base en el número de bloque,, un identificador de codificación y otra información de identificación.
29. 29. El dispositivo emisor para la transmisión de archivos en un sistema con la capacidad de transmsión uno-a-varios, caracterizado porque comprende: medios para transmitir uno o más bloques de datos hacia por lo menos un receptor; y medios para retransmitir un bloque de datos que se esperaba recibir pero que no se recibió por completo o se recibió incorrectamente en el receptor, el bloque de datos que ha sido identificado con base en número de bloque, un identificador de codificación y otra información de identificación.
30. 30. Un programa computacional de aplicación ejecutable en un dispositivo emisor para la transmisión de archivos en un sistema con la capacidad de transmisión uno-a-varios, caracterizado porque comprende: código de programa para provocar que el dispositivo emisor transmita uno o más bloques de datos hacia por lo menos un receptor; y código de programa para provocar que el dispositivo emisor retransmita un bloque de datos que se esperaba recibir pero que no se recibió por completo o se recibió incorrectamente en el receptor, el bloque de datos que ha sido identificado con base en un número de bloque, un identificador de codificación y otra información de identificación.
31. 31. Un sistema con la capacidad de transmisión uno-a-varios, caracterizado porque comprende: medios para transferir uno o más bloques de datos desde un emisor hacia por lo menos un receptor; medios para identificar un. bloque de datos que se esperaba recibir pero que no se recibió por completo o se recibió incorrectamente en el receptor; medios de procedimiento para retransmitir el bloque de datos , en donde los medios para la identificación están configurados para identificar el bloque de datos con base en un número de bloque, un identificador de codificación y otra información de identificación.
32. 32. El sistema de conformidad con la reivindicación 31, caracterizado porque la otra información de identificación comprende un conjunto de parámetros de sesión y un identificador de objetos de transmisión.
33. 33. El sistema de conformidad con la reivindicación 31, caracterizado porque la otra información de identificación comprende un identificador de objetos de transmisión.
34. 34. El sistema de conformidad con la reivindicación 31, caracterizado porque la otra información de identificación comprende información del archivo.
35. 35. El sistema de conformidad con la reivindicación 31, caracterizado porque la otra información de identificación comprende información de agrupamiento.