ES2488846T3

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

Info

Publication number: ES2488846T3
Application number: ES05708197.8T
Authority: ES
Inventors: Rod Walsh; Harsh Mehta; Igor Curcio; Toni Paila
Original assignee: Core Wiresless Licensing SARL
Current assignee: Conversant Wireless Licensing SARL
Priority date: 2004-02-13
Filing date: 2005-02-11
Publication date: 2014-08-29
Anticipated expiration: 2025-02-11
Also published as: TWI312622B; CA2553069A1; US7599294B2; CA2770432A1; JP4357535B2; EP1714415B1; ZA200607568B; TW200534630A; US20050182842A1; KR20060120248A; AU2005212895A1; CA2770432C; MY143914A; JP2007520961A; CA2851953A1; EP1714415A1; CN1918841B; EP2728783A1; BRPI0507557A; WO2005078982A1

Abstract

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

Description

15

25

35

45

55

65 E05708197

05-08-2014

DESCRIPCIÓN

Identificación y retransmisión de partes perdidas.

Campo de la invención

La presente invención se refiere en general a una tecnología y a servicios de transmisión por multidifusión y por difusión general, es decir, servicios con una fuente de datos (o emisor) y por lo menos un receptor.

Antecedentes de la invención

Para servicios de uno-a-muchos (es decir, de punto-a-multipunto) a través de sistemas tales como la multidifusión IP, la difusión general de datos IP (IPDC) y los servicios de difusión general/multidifusión multimedia (MBMS), la entrega de archivos (o entrega de medios discretos o descarga de archivos) es un servicio importante. Muchas de las características para entregar archivos a través de protocolos de punto-a-punto, tales como el protocolo de transferencia de archivos (FTP) y el protocolo de transferencia de hipertexto (HTTP), son problemáticas para escenarios de uno-a-muchos. En particular, la entrega fiable de archivos -es decir, la entrega garantizada de archivos -usando protocolos similares de uno-a-uno (es decir, de punto-a-punto), con acuse de recibo (ACK), tales como el protocolo de control de transmisión TCP, no es viable.

El Grupo de Trabajo de Transporte Fiable por Multidifusión (RMT) del Grupo de Tareas de Ingeniería de Internet (IETF) se encuentra en el proceso de normalizar dos categorías de protocolos de transporte por multidifusión a prueba de fallos. En la primera categoría, la fiabilidad se implementa a través del uso de una corrección directa de errores (FEC) (proactiva), es decir, enviando una cierta cantidad de datos redundantes que pueden ayudar a un receptor en la reconstrucción de datos erróneos. En la segunda categoría, se usa realimentación del receptor para implementar un transporte fiable por multidifusión. La Codificación Asíncrona por Capas (ALC, RFC 3450) es una instanciación de protocolo perteneciente a la primera categoría, mientras que el protocolo de Multidifusión Fiable Orientada a NACK (NORM) presenta un ejemplo de la segunda categoría. Los detalles de los protocolos ALC y NORM se describen de forma más detallada en publicaciones tituladas “Asynchronous Layered Coding (ALC) Protocol Instantiation” (RFC 3450) y “NACK-oriented Reliable Multicast Protocol” (Borrador de Internet) preparadas por el Grupo de Trabajo del IETF. El contenido de estas publicaciones se incorpora en su totalidad a la presente a título de referencia.

Las redes de acceso en las cuales se pueden usar estos protocolos incluyen, aunque sin carácter limitativo, redes inalámbricas de acceso múltiple, tales como redes de acceso por radiocomunicaciones del sistema de Servicios Universales de Telecomunicaciones para Móviles (UMTS), redes inalámbricas de área local (WLAN), redes de Radiodifusión de Vídeo Digital-Terrestre (DVB-T) y redes de Radiodifusión de Vídeo Digital por Satélite (DVB-S).

En pocas palabras, el protocolo ALC es un esquema proactivo basado en FEC que permite que receptores reconstruyan paquetes alterados o paquetes que no han sido recibidos. El protocolo ALC usa la codificación FEC sobre múltiples canales, permitiendo que el emisor envíe datos con múltiples velocidades (canales) a receptores posiblemente heterogéneos. Adicionalmente, el protocolo ALC usa un mecanismo de control de la congestión para mantener diferentes velocidades sobre canales diferentes.

El protocolo ALC es masivamente escalable en términos del número de usuarios puesto que no se requiere ninguna señalización de enlace ascendente. Por lo tanto, ninguna cantidad de receptores adicionales hace que aumente precisamente la demanda en el sistema. No obstante, el protocolo ALC no tiene una fiabilidad del 100% puesto que la recepción no está garantizada, y por lo tanto en general no se describe como robusto.

A su vez, el NORM especifica el uso de mensajes de acuse de recibo negativo (NACK) con el fin de señalizar qué paquetes de datos (o, definidos de otra manera, “bloques de datos”) que se esperaba que llegasen al receptor, no se recibieron en este último (o se recibieron incorrectamente). En otras palabras, los receptores utilizan mensajes NACK para indicar la pérdida o alteraciones de paquetes transmitidos, al emisor. Por consiguiente, un receptor que “echó en falta” algunos bloques de datos de una transmisión de datos puede enviar un mensaje NACK al emisor solicitando a este último que retransmita el bloque o bloques de datos ausentes. Opcionalmente, el protocolo NORM también permite el uso de codificación FEC a nivel de paquetes para transmisiones robustas proactivas.

La Entrega de Archivos a través de Transporte Unidireccional (FLUTE) es un protocolo de transporte de uno-amuchos que se constituye sobre bloques constructivos de FEC y ALC. Está pensada para la entrega de archivos desde emisor(es) a receptor(es) a través de sistemas unidireccionales. Dispone de especializaciones que la hacen adecuada para sistemas inalámbricos de punto-a-multipunto (multidifusión). Los detalles del protocolo FLUTE se describen más minuciosamente en la publicación titulada “FLUTE -File Delivery over Unidirectional Transport” (Borrador de Internet) preparada por el antes mencionado Grupo de Trabajo del IETF. El contenido de esta publicación se incorpora en su totalidad a la presente a título de referencia.

Los mensajes NACK no son en general específicos del NORM, sino que se pueden usar también en relación con

E05708197

05-08-2014

otros protocolos o sistemas. Cuando se usan mensajes NACK en relación con sesiones FLUTE (o en otras sesiones que usen un protocolo de capa de transporte dirigido especialmente para soportar una transmisión de uno-amuchos), la identificación de los paquetes (o bloques) perdidos es una cuestión importante. El uso de protocolos destinados a una transmisión de uno-a-uno (o de punto-a-punto), tales como el TCP, y sus métodos de acuse de

5 recibo no son necesariamente viables en este caso. Por ejemplo, el uso de métodos de acuse de recibo TCP en un sistema de uno-a-muchos produciría una cantidad considerable de tara. Por consiguiente, existe una necesidad de identificar de manera fiable los paquetes no recibidos en un escenario de uno-a-muchos de manera que se pueda llevar a cabo una re-transmisión precisa.

10 Sumario de la invención

Se ha observado que, cuando se usan mensajes NACK para transmitir datos de manera fiable a través de un canal de multi-difusión/difusión general, la identificación de los paquetes perdidos es una cuestión importante. Esto implica el mantenimiento de información referente al estado de la transmisión así como la identificación de bloques que es

15 necesario retransmitir. Se ha observado que, en términos de tiempo de respuesta, las solicitudes de NACK (enviadas por un receptor y recibidas por un emisor) se pueden dividir en 2 categorías:

a) solicitudes de NACK que son recibidas inmediatamente o poco después de la transmisión inicial, y se pueden satisfacer dentro de la misma sesión (por ejemplo, una sesión FLUTE o similar). 20

b) solicitudes de NACK que son recibidas después de la expiración de una sesión y se requiere que los datos se retransmitan a través de otra sesión. En este caso, la otra sesión puede ser o bien del mismo protocolo de punto-a-multipunto (por ejemplo, una nueva sesión FLUTE establecida después de la expiración de una sesión FLUTE antigua) o bien una sesión que use otro protocolo el cual puede ser un protocolo de punto-a

25 punto o de punto-a-multipunto (por ejemplo, FTP, HTTP, etcétera).

En los dos casos, es importante identificar de manera precisa el(los) bloque(s) a retransmitir.

Según un primer aspecto de la invención, se proporciona un método de acuerdo con la reivindicación 1.

30 Según una forma de realización, la otra información comprende un conjunto de parámetros de sesión y/o un identificador de objeto de transmisión.

Según otra forma de realización, la otra información comprende información del archivo y/o información de 35 constitución de bloques.

De acuerdo con un segundo aspecto de la invención, se proporciona un dispositivo de recepción según la reivindicación 25.

40 Según un tercer aspecto de la invención, se proporciona un dispositivo de emisión de acuerdo con la reivindicación

30.

Según un quinto aspecto de la invención, se proporciona una aplicación de software ejecutable en un dispositivo de recepción de acuerdo con la reivindicación 29.

45 De acuerdo con un sexto aspecto de la invención, se proporciona una aplicación de software ejecutable en un dispositivo de emisión según la reivindicación 31.

Las aplicaciones de software pueden ser productos de programa de ordenador, que comprenden código de 50 programa, almacenado en un soporte, tal como una memoria.

Este aspecto de la invención se puede interpretar como un aspecto independiente o como un aspecto a implementar en relación con cualquier(cualesquiera) otro(s) aspecto(s) de la invención.

55 Los intervalos de los números de bloque y los intervalos de los identificadores de codificación pueden ser contiguos

o no contiguos.

Se pueden implementar respectivamente un dispositivo de recepción, un dispositivo de emisión, un sistema y aplicaciones de software.

60 Las reivindicaciones dependientes se refieren a formas de realización de la invención. La materia en cuestión contenida en reivindicaciones dependientes referentes a un aspecto particular de la invención es aplicable también a otros aspectos de la invención.

15

25

35

45

55

65 E05708197

05-08-2014

Breve descripción de los dibujos

A continuación se describirán formas de realización de la invención, a título de ejemplo, y en referencia a los dibujos adjuntos, en los cuales:

la figura 1 muestra un dispositivo de emisión y un dispositivo de recepción en comunicación de acuerdo con una forma de realización de la invención;

la figura 2A ilustra una arquitectura de protocolos simplificada de acuerdo con una forma de realización de la invención;

la figura 2B ilustra una arquitectura de protocolos simplificada de acuerdo con otra forma de realización de la invención;

la figura 3 muestra un sistema y detalles de un dispositivo de recepción de acuerdo con una forma de realización de la invención; y

la figura 4 muestra un dispositivo de emisión según una forma de realización de la invención.

Descripción detallada

La materia en cuestión contenida en la parte introductoria de esta solicitud de patente se puede usar para sustentar la descripción detallada. En lo sucesivo, el protocolo de Entrega de Archivos a través de Transporte Unidireccional (FLUTE) se usa como ejemplo sin ninguna intención de limitar la presente invención al uso único del FLUTE. En el contexto de la presente invención es aplicable también cualquier otro protocolo adecuado con capacidad de entrega de archivos por multidifusión de uno-a-muchos.

La figura 1 muestra un dispositivo de emisión y un dispositivo de recepción en comunicación de acuerdo con una forma de realización de la invención. El dispositivo de emisión 10 es un servidor, un dispositivo basado en IP, un dispositivo de DVB, un dispositivo GPRS (o UMTS) o un dispositivo similar que, opcionalmente, puede usar una corrección directa de errores proactiva, tal como un mecanismo de ALC, para enviar bloques (o paquetes) de datos por multidifusión al dispositivo de recepción 20. El dispositivo de recepción 20 envía mensajes (o solicitudes) de acuse de recibo negativo NACK al dispositivo de emisión 10 en relación con bloques perdidos (bloques no recibidos

o recibidos incorrectamente). Como respuesta al(a los) mensaje(s) de NACK, el dispositivo de emisión 10 retransmite bloques perdidos al dispositivo de recepción 20 en una sesión FLUTE (la misma sesión que la sesión FLUTE original establecida para la transmisión original, o una sesión FLUTE subsiguiente). De manera alternativa, se puede usar una sesión que utilice un protocolo diferente al FLUTE. En ciertos contextos, a la sesión de retransmisión se le denomina sesión de reparación.

Los datos se transfieren como objetos. Por ejemplo, un archivo, una imagen JPEG, una fracción de archivo son, todos ellos, objetos. Se establece una sesión entre el dispositivo de emisión 10 y el dispositivo de recepción 20 para la entrega de archivos (o datos). Una única sesión puede incluir la transmisión de un único objeto o de múltiples objetos. Se usan diferentes identificadores para identificar los objetos y las sesiones. Cada sesión se identifica por la dirección (por ejemplo, una dirección IP) del emisor (fuente), la dirección del receptor (destino) y el identificador de sesión de transmisión (TSI) o similar. También es posible usar solamente la dirección del emisor o del receptor y el TSI. Además, el identificador de objeto de transmisión (TOI) o similar se usa para indicar el objeto al que pertenece el paquete que se está transmitiendo en una sesión particular. Por ejemplo, un dispositivo de emisión 10 podría enviar un número de archivos en la misma sesión usando un TOI de 0 para el primer archivo, 1 para el segundo y así sucesivamente.

Cada bloque de datos tiene un número denominado número de bloque fuente (SBN) o similar, el cual identifica cada bloque. Los bloques se representan por un conjunto de símbolos de codificación. A su vez, un identificador de símbolo de codificación (ESI) o similar indica cómo se generaron los símbolos de codificación transportados en la carga útil de un paquete (o bloque) de datos a partir del objeto antes mencionado (por ejemplo, archivo).

La figura 2A ilustra una arquitectura simplificada de protocolos de acuerdo con una forma de realización de la invención. Según esta forma de realización, la pila de protocolos a implementar para el dispositivo de emisión 10 y el dispositivo de recepción 20 comprende una capa de aplicación, una capa de protocolo FLUTE, capas UDP e IP y capas inferiores. La capa del protocolo FLUTE se construye por encima de la instanciación del protocolo ALC del bloque constructivo (no mostrado) del transporte de codificación por capas (LCT). También se pueden usar opcionalmente bloques constructivos de FEC. La capa del protocolo FLUTE junto con mensajes NACK está destinada a proporcionar una transmisión fiable de bloques de datos desde el dispositivo de emisión 10 al dispositivo de recepción 20. Esta arquitectura de protocolos se puede usar para la transmisión de uno-a-muchos (tanto para “primeras transmisiones” de uno-a-muchos como para retransmisiones de uno-a-muchos).

Alternativamente, en una forma de realización se puede usar una capa TCP en lugar de la capa UDP (véase la

15

25

35

45

55

65 E05708197

05-08-2014

figura 2B). Esto se aplica para el caso en el cual se usa una sesión de reparación independiente de punto-a-punto (en este caso: sesión TCP) para retransmisiones de uno-a-uno (es decir, de punto-a-punto). Posteriormente en esta descripción se presenta la descripción de diferentes métodos de retransmisión.

En lo sucesivo, se presentan diferentes casos para la identificación de un conjunto de paquetes (o bloques) perdidos por parte de un receptor. Existen dos métodos para identificar el bloque o símbolo de codificación fuente de FLUTE (y, como consecuencia, uno o una serie de paquetes):

Método de identificación A

La identificación se lleva a cabo sobre la base del SBN y el ESI, así como parámetros de sesión FLUTE (dirección de origen, dirección de destino y el TSI) y el TOI (Identificador de Objeto de Transmisión). Típicamente, es el dispositivo de emisión el que genera esta información mientras se transmiten paquetes FLUTE. La información está contenida en paquetes ALC/FLUTE.

Método de identificación B

La identificación se lleva a cabo sobre la base del SBN y el ESI, así como sobre la base del archivo (es decir, el URI del archivo entregado), de parámetros de archivo (longitud de archivo y el código de cifrado (tal como código MD5), del algoritmo de constitución de bloques usado y de los parámetros de constitución de bloques (longitud máxima del bloque fuente, longitud de los símbolos de codificación y longitud del archivo). La información se toma de una FDT (Tabla de Descripción de Archivos) o similar, la cual contiene estos parámetros/información. La información se transporta típicamente como un objeto independiente por medio de la sesión FLUTE.

Tal como puede observarse, los dos métodos de identificación A y B hacen uso de un número de bloque y de un identificador de codificación y, adicionalmente, de alguna otra información de identificación. El método de identificación A usa detalles que se pueden obtener directamente a partir de la propia sesión (en este caso: sesión FLUTE), mientras que el método de identificación B usa también otra información (por ejemplo, información sobre el archivo entregado).

Con independencia del método de identificación, existen las dos siguientes posibilidades para llevar a cabo la posterior retransmisión:

Método de retransmisión A

La sesión FLUTE para la retransmisión (la retransmisión se puede efectuar dentro de la misma sesión FLUTE (en curso) o en una sesión FLUTE independiente). El método se puede basar en una transmisión de punto-a-punto o de punto-a-multipunto.

Método de retransmisión B

Uso de una sesión aparte para la retransmisión con un método diferente al FLUTE, por ejemplo, HTTP, SMS, FTP, SAP, GPRS, etcétera. El método se puede basar en una transmisión de punto-a-punto o de punto-a-multipunto.

Por consiguiente, los dos métodos de identificación diferentes y el uso del FLUTE u otro protocolo para la retransmisión produce cuatro combinaciones diferentes para identificar y retransmitir paquetes:

1.: Identificación usando el método A y retransmisión usando el método A;

2.: Identificación usado el método B y retransmisión usando el método B;

3.: Identificación usando el método A y retransmisión usando el método B; y

4.: Identificación usando el método B y retransmisión usando el método A.

Lo anterior considera que, durante la transmisión, cada símbolo de codificación está contenido dentro de un mismo paquete. No obstante, si se incluyen múltiples símbolos de codificación dentro del mismo paquete, o si un único símbolo de codificación se reparte sobre múltiples paquetes, entonces es necesario que el símbolo de codificación (y la parte del paquete que contiene un símbolo de codificación o la serie de paquetes que contienen un único símbolo de codificación, respectivamente) sea identificado de manera apropiada.

La primera combinación (A+A) se considera útil en una situación en la que la retransmisión de paquetes se desea sobre el mismo canal, usando la misma información de emisor (o servidor) y dentro de la misma sesión FLUTE, en un espacio de tiempo breve. El emisor FLUTE puede, por ejemplo, almacenar en memoria intermedia (o almacenar temporalmente) todos los SBNs y ESI enviados en los últimos 5 minutos. Este método es aplicable si en este periodo de tiempo llega una solicitud de retransmisión (NACK).

La segunda combinación (B+B) se considera útil en una situación en la que la retransmisión es necesaria después de que haya finalizado la sesión actual, posiblemente mucho tiempo después de ella. Puesto que el almacenamiento

15

25

35

45

55

65 E05708197

05-08-2014

en memoria intermedia de toda la información de largo plazo sobre transmisiones durante la sesión podría resultar inviable para el dispositivo de emisión 10, en una forma de realización no limitativa un “servidor externo” o un servidor de reparación (o simplemente un servidor aparte (no mostrado)) se configura para almacenar en memoria intermedia la información de transmisión. Este servidor puede estar situado conjuntamente, por ejemplo, con el emisor original (por ejemplo, un servidor MBMS (Servicio de Difusión General/Multidifusión Multimedia), denominado también BM-SC (Centro de Servicios de Difusión General y Multidifusión)), o, por ejemplo, puede ser un servidor aparte dentro de la red de un operador UMTS. A continuación, este servidor puede retransmitir los paquetes perdidos en un momento posterior. Un ejemplo de esto es un servidor que retransmite paquetes perdidos a través de GPRS o UMTS por la noche, cuando el acceso GPRS (UMTS) puede ser más económico. La retransmisión también se puede iniciar justo después de que haya finalizado la sesión de transmisión, o en cualquier momento aleatorio después de la misma y antes de que los datos sean consumidos por el dispositivo de recepción 20, con el fin de evitar la sobrecarga del dispositivo de emisión 10 con solicitudes de retransmisión (NACK) procedentes de muchos dispositivos de recepción 20. La idea de disponer de un servidor de reparación aparte se aplica también a otras formas de realización.

Las siguientes etapas ilustran una forma de realización ejemplificativa de lo anterior:

1.: El dispositivo de emisión 10 transmite uno o más archivos usando una sesión FLUTE.

2.: Al final de la sesión, el dispositivo de recepción 20 envía uno o más mensaje(s) de NACK para todos los paquetes que no recibió. Este mensaje de NACK significa el inicio de una sesión nueva.

3.: El dispositivo de emisión 10 vuelve a enviar todos los datos solicitados por el dispositivo de recepción 20 en una sesión nueva.

4.: A continuación, la sesión recién creada se cierra en el dispositivo de emisión 10 y en el dispositivo de recepción 20.

Como ejemplo referente a la etapa 2 anterior, se puede usar el siguiente método para enviar NACK para datos usando un SBN y ESI específicos a través de HTTP:

http://www.3.com/greatmusic/number1.mp3?mbms-rel6-flute-repair&SBN=123;ESI=234.

En este caso, SBN y ESI son el Número de Bloque Fuente e ID de Símbolo de Codificación de las partes del archivo de las cuales se va a enviar un acuse de recibo negativo (es decir, NACK). El nombre de archivo es en este caso number1.mps y el SBN y ESI para los cuales se envía un acuse de recibo negativo son 123 y 234, respectivamente. En la anterior consulta HTTP, los campos de SBN y ESI también se pueden usar para un acuse de recibo negativo de intervalos de SBN y ESI. Por ejemplo,

http://www.3.com/greatmusic/number1.mp3?mbms-rel6-flute-repair&SBN=123&126&127;ESI=234-238.

Lo anterior es una emisión de acuse de recibo negativo para el archivo number1.mp3, el SBN 123, 126 y 127 y el ESI 234 a 238. Son posibles algunas otras combinaciones del estilo, por ejemplo:

a) SBN;ESI_list (por ejemplo, ...&SBN=123;ESI=234,236,238)

(una lista de ESI perdidos dentro del mismo SBN)

b) SBN; all_symbols (por ejemplo, ...&SBN=123)

(faltan todos los ESI pertenecientes al SBN 123)

c) intervalo-SBN; all_symbols (por ejemplo,..., &SBN=123-129)

(faltan todos los ESI pertenecientes al intervalo de SBN 123 a 129)

d) “intervalos no contiguos”

d.1) (por ejemplo,...&SBN=123;ESI=234+SBN=200;ESI=23)

(faltan el ESI 234 perteneciente al SBN 123 y el ESI 23 perteneciente al SBN 200), o

d.2) (...&SBN=123-129+SBN=200; ESI=23-59+SBN=200;ESI=101)

(faltan todos los ESI pertenecientes al intervalo de SBN 123 a 129 y todos los ESI dentro del intervalo 23 a 59 pertenecientes al SBN 200 y el ESI 101 perteneciente al SBN 200).

15

25

35

45

55

65 E05708197

05-08-2014

Es posible que un NACK contenga una solicitud de retransmisión de uno o más paquetes. Resulta más eficiente incluir todas las solicitudes de paquetes en una única solicitud de NACK si la misma se transmite de manera fiable a través del canal de la red. Si no, la totalidad los paquetes se pueden solicitar por varios NACK.

Lo siguiente describe todavía otra forma de realización de la invención para retransmitir paquetes que se han perdido durante una cierta sesión FLUTE. Esta forma de realización es independiente de las cuatro anteriores combinaciones de identificación/retransmisión.

En esta forma de realización, el contexto de la sesión FLUTE (SBN, ESI, TSI y TOI) se almacena para un uso posterior que no sea FLUTE. A continuación, este contexto se puede usar para transmitir datos usando un método que no sea FLUTE. Para implementar esto, se considera que es útil disponer de un identificador, por ejemplo, un ID de multidifusión, que identifique de manera exclusiva el “contexto de sesión”. En este caso, el “contexto de sesión” puede ser, por ejemplo, todos los identificadores de la sesión combinados para formar un identificador único correspondiente a la sesión. Debería indicarse que, aunque el método de retransmisión usado aquí es el mismo que en el método de combinación 4 descrito anteriormente, existe una diferencia con respecto al almacenamiento de información de sesión. En una forma de realización, la información de sesión la almacenan tanto el dispositivo de emisión como el dispositivo de recepción y la misma se comunica entre el dispositivo de emisión y el dispositivo de recepción fuera de una sesión FLUTE.

Según todavía otra forma de realización de la invención, el dispositivo de recepción 20, por contraposición al cálculo de los paquetes que requieren una retransmisión, calcula los intervalos de bytes (del objeto original transmitido por el dispositivo de emisión 10) que necesitan ser retransmitidos. También en esta forma de realización, en la identificación se pueden usar el SBN y el ESI. El dispositivo de recepción envía un mensaje de NACK para los intervalos de bytes no recibidos. Es posible que haya múltiples intervalos de bytes dentro del mismo paquete. Como respuesta al mensaje de NACK, el dispositivo de emisión 10 retransmite los intervalos de bytes del objeto original. En lugar de intervalos de bytes, el dispositivo de recepción 10 también puede calcular intervalos de bits así como intervalos de palabras, y solicitar su retransmisión.

En otra forma de realización de la invención, los símbolos de codificación redundantes, por contraposición a fuente, que se han perdido, de bloque(s) fuente, se identifican, y todos ellos o un subconjunto de los mismos se retransmiten. Así, los NACK enviados desde dispositivos de recepción 20 a dispositivos de emisión 10 (puede haber más de un dispositivo de emisión) se basan en símbolos redundantes. Este esquema resulta particularmente aplicable en esquemas sistemáticos de FEC en donde se transmiten únicamente “símbolos redundantes” codificados y no se retransmiten “símbolos fuente” no codificados, y, típicamente, es necesario un cierto número de umbral de símbolos de codificación redundantes de cada bloque fuente para completar los bloques fuente y así reconstruir el archivo.

Por ejemplo, en un esquema ejemplificativo de FEC, puede darse el caso de que haya 1000 símbolos transmitidos por el dispositivo de emisión, para cada bloque fuente, y el número de umbral requerido para su recepción por el dispositivo de recepción con el fin de completar (o realizar correctamente) la entrega del archivo sea exactamente

500. No obstante, en este caso ejemplificativo, el dispositivo de recepción obtiene únicamente 490 símbolos (suponiendo que faltan solamente símbolos de codificación de un único bloque fuente; si faltan símbolos de codificación de varios bloques fuente, entonces es necesario llevar a cabo el siguiente cálculo para cada bloque fuente en el que faltan símbolos). En un escenario de este tipo, existen las siguientes posibilidades que se aplican por cada bloque fuente de cada archivo:

1.: El dispositivo de recepción identifica los símbolos perdidos; el dispositivo de recepción resuelve cuántos bastan para completar el bloque; el dispositivo de recepción emite NACK para un subconjunto de los símbolos perdidos (suficiente para completarlo); el dispositivo de emisión vuelve a enviar estos símbolos,

2.: El dispositivo de recepción identifica los símbolos perdidos; el dispositivo de recepción emite NACK de todos los símbolos perdidos; el dispositivo de emisión vuelve a enviar todos estos símbolos,

3.: El dispositivo de recepción identifica los símbolos perdidos; el dispositivo de recepción emite NACK de todos los símbolos perdidos; el dispositivo de emisión resuelve cuántos son suficientes para completar el bloque; el dispositivo de emisión selecciona un subconjunto de símbolos perdidos (equivalentes a los “suficientes”); el dispositivo de emisión vuelve a enviar estos símbolos,

4.: El dispositivo de recepción acusa recibo (ACK) de los símbolos recibidos; el dispositivo de emisión identifica los símbolos perdidos; el dispositivo de emisión vuelve a enviar todos estos símbolos.

5.: El dispositivo de recepción acusa recibo ACK de los símbolos recibidos; el dispositivo de emisión identifica los símbolos perdidos; el dispositivo de emisión resuelve cuántos son suficientes para completar el bloque; el dispositivo de emisión selecciona un subconjunto de símbolos perdidos (equivalentes a los “suficientes”); el dispositivo de emisión vuelve a enviar estos símbolos.

15

25

35

45

55

65 E05708197

05-08-2014

La selección de la combinación de NACK (o ACK) de manera que, en cada NACK, se remita a más de un símbolo, a más de un bloque fuente y/o a más de un archivo, es cuestión de la optimización para cada aplicación.

La definición de “suficientes” símbolos puede ser exactamente el número requerido para completar el número de umbral (10 de entre 510 en el ejemplo anterior) especialmente cuando la reparación se puede efectuar de manera fiable a través de algunos otros medios (como el transporte TCP), o puede ser un número mayor para tener en cuenta las pérdidas en el enlace (por ejemplo, en el ejemplo anterior se perdió el 51% de los símbolos, por lo tanto si fuera a usarse nuevamente el mismo canal de comunicaciones se podría esperar algo similar, de manera que resultaría más apropiado volver a enviar 10*(100/51)=20 símbolos. Además, se puede añadir un margen de seguridad adicional (por ejemplo, para hacer frente a los errores de ráfagas), de manera que si el mismo fuera 3 símbolos, entonces se podría llevar a cabo una reparación con 23 símbolos aun cuando solamente serían necesarios 10 para “salir adelante”. Tanto este factor de multiplicación (en este caso: “100/51”) como la constante (en este caso: 3) pueden considerar una pérdida uniforme de paquetes (como en los ejemplos mencionados) o pueden depender del patrón de pérdidas de la transmisión original. Por ejemplo, un dispositivo de emisión puede analizar la distribución de símbolos perdidos y si la misma fuera no uniforme (por ejemplo, normalmente se pierden 3 símbolos consecutivos de manera aproximada por cada 20 símbolos), entonces se pueden añadir algunos (por ejemplo, 3 por cada 20 símbolos) símbolos adicionales (dando como resultado nuevamente 23 símbolos en este ejemplo).

Un ejemplo adicional sería que, después de identificar dicho número de umbral de 10 símbolos de un bloque fuente requerido para completar el archivo, el dispositivo de recepción enviase un NACK al dispositivo de emisión solicitando la retransmisión de estos 10 símbolos. El dispositivo de emisión puede volver a enviar estos símbolos en la medida en la que los mismos se han almacenado en memoria caché anteriormente o, en un método alternativo, el dispositivo de emisión lleva a cabo una repetición de la codificación FEC sobre el(los) archivo(s) y los bloques fuente correspondientes a los símbolos, y retransmite estos símbolos. Este último método permite desacoplar la funcionalidad de transmisión inicial y de servidor de reparación, y posiblemente su despliegue en equipos de servidor distintos.

Otro ejemplo adicional consistiría en que el dispositivo de recepción enviase un NACK para cada uno de los 510 símbolos perdidos (o, en una forma de realización alternativa acusase recibo de que ha recibido 490 símbolos). El dispositivo de emisión retransmite entonces únicamente los 10 símbolos perdidos o retransmite la totalidad de los 510 símbolos perdidos. La retransmisión puede ser de símbolos almacenados previamente en memoria caché o de símbolos recién codificados por FEC.

Además de la solicitud de retransmisión (o reparación), enviada desde el dispositivo(s) de recepción al dispositivo(s) de emisión, sobre la base de la identificación de símbolos, la solicitud puede especificar uno o más intervalos de bytes en el archivo, y/o sus bloques fuente. Esto es aplicable si los símbolos recibidos son suficientes para resolver los intervalos de bytes perdidos de los bloques.

Se ha descrito que la transmisión de punto-a-punto o de punto-a-multipunto se puede usar para retransmitir paquetes perdidos. Una forma de realización clarificadora se refiere a la retransmisión (o reparación) de punto-amultipunto. En esta forma de realización, cada dispositivo de recepción afectado envía un mensaje de acuse de recibo negativo (NACK) al dispositivo de emisión a través de una conexión (o sesión) de punto-a-punto. En función del número y/o del contenido de NACK recibidos en el dispositivo de emisión, este último toma una decisión:

1) si enviar el(los) bloque(s) perdido(s) por separado a cada dispositivo de recepción usando conexión(es) de punto-a-punto; o

2) si enviar el(los) bloque(s) perdido(s) usando una conexión de punto-a-multipunto (es decir, multidifusión o difusión general o similar).

Si un número elevado de dispositivos de recepción envía solicitudes de NACK relacionadas con los mismos paquetes perdidos, la segunda opción puede resultar más deseable. De esta manera, con una única retransmisión, es posible realizar reparaciones de múltiples receptores y ahorrar recursos.

La figura 3 muestra un sistema y detalles de un dispositivo de recepción de acuerdo con una forma de realización de la invención. El sistema comprende el dispositivo de emisión 10, una red de transmisión 30, por ejemplo, una red IP u otra red fija, una red inalámbrica o una combinación de una red fija y una inalámbrica (celular), etcétera, y el dispositivo de recepción 20. El dispositivo de recepción 20 puede ser un teléfono celular, un teléfono por satélite, un asistente personal digital o un dispositivo Bluetooth, un dispositivo WLAN, un dispositivo de DVB, u otro dispositivo inalámbrico similar. El dispositivo 20 incluye una memoria interna 21, un procesador 22, un sistema operativo 23, programas de aplicación 24, una interfaz de red 25 y un mecanismo de identificación y NACK 26. La memoria interna 21 da alojo al procesador 22, al sistema operativo 23 y a los programas de aplicación 24. El mecanismo de identificación & NACK 26 posibilita la identificación de paquetes de datos y la transmisión de NACK o datos al dispositivo de emisión 10 como respuesta a bloques de datos perdidos o alterados en una transmisión de datos. El

E05708197

05-08-2014

dispositivo 20 se puede comunicar con el dispositivo de emisión 10 y otros dispositivos por medio de la interfaz de red 25 y de lared30.

La figura 4 muestra un dispositivo de emisión 10 de acuerdo con una forma de realización de la invención. El

5 dispositivo de emisión 10 puede ser, por ejemplo, un servidor de red o cualquier dispositivo adecuado, destinado a la entrega de archivos (o medios). El dispositivo 10 incluye una memoria interna 11, un procesador 12, un sistema operativo 13, programas de aplicación 14, una interfaz de red 15 y un mecanismo de transmisión y retransmisión 16. La memoria interna 11 da alojo al procesador 12, al sistema operativo 13 y a los programas de aplicación 14. El mecanismo de transmisión y retransmisión 16 posibilita la transmisión de paquetes de datos y la retransmisión de

10 paquetes de datos como respuesta a NACK recibidos desde el dispositivo de recepción 20. El dispositivo 10 se puede comunicar con el dispositivo de recepción 20 y otros dispositivos por medio de la interfaz de red 15 y la red

30.

Mediante software se pueden implementar procedimientos referentes a la identificación de paquetes de datos

15 perdidos y retransmisiones de los mismos. Para implementar los procedimientos en el extremo de recepción de la sesión de transmisión se puede usar un producto de programa de ordenador que comprende código de programa almacenado en el dispositivo de recepción 20 y ejecutado en el procesador 22, mientras que, para implementar los procedimientos en el extremo de transmisión, se puede usar un producto de programa de ordenador que comprende código de programa almacenado en el dispositivo de emisión 10 y ejecutado en el procesador 12.

20 En lo sucesivo, se describen ventajas de las formas de realización de la invención. Formas de realización de la invención proporcionan una infraestructura nueva para retransmitir datos perdidos.

Tal como se ha puesto de manifiesto sobre la base de lo anterior, esta infraestructura permite la retransmisión de 25 datos ausentes en los siguientes escenarios:

• Dentro de una sesión de FLUTE, cuando la información referente a los paquetes perdidos sigue estando disponible en el dispositivo de emisión y el NACK es recibido por el dispositivo de emisión en un marco de tiempo breve.

30

• Cuando se requiere retransmitir paquetes perdidos, fuera de la sesión FLUTE original en la que los mismos se transmitieron originalmente. Esta retransmisión se puede producir usando FLUTE o utilizando otro método de transmisión.

35 Algunas de las ventajas que proporcionan formas de realización de la invención son:

• Un método de identificación de bloques (o paquetes) perdidos (contiguos o no contiguos) de manera exclusiva.

40 • Un método de identificación de bloques (o paquetes) perdidos de un (o múltiples) archivo(s) a través de la misma (o de varias) sesión(es).

• Un método de identificación y retransmisión de bloques (o paquetes) perdidos, a través de varios protocolos

de transmisión. 45

• La capacidad de retransmitir paquetes perdidos en un momento adecuado. El momento adecuado se selecciona usando varios criterios posibles (tales como ancho de banda disponible, operador más económico, etcétera).

50 • La capacidad de retransmitir los paquetes perdidos de manera fiable (si el protocolo de transporte subyacente es fiable) y con una única sesión de transferencia de reparación.

Por consiguiente, formas de realización de la invención presentan métodos para identificar y enviar mensajes de acuse de recibo negativo (NACK) por bloques ausentes ya sea dentro o ya sea fuera de una sesión de multidifusión 55 de uno-a-muchos.

Se han descrito implementaciones y formas de realización particulares de la invención. Resultará evidente para los expertos en la materia que la invención no se limita a detalles de las formas de realización antes presentadas, sino que la misma se puede implementar en otras formas de realización usando medios equivalentes y sin desviarse con

60 respecto a las características de la invención. El alcance de la invención queda únicamente limitado por las reivindicaciones de patente adjuntas.

Claims

5

15

25

35

45

55

65 E05708197

05-08-2014

REIVINDICACIONES

1. Método para la entrega de archivos en un sistema con capacidad de transmisión de uno-a-muchos, comprendiendo el método:

transferir uno o más bloques de datos de un archivo desde un emisor (10) a por lo menos un receptor (20);

caracterizado por que comprende las etapas siguientes:

identificar un bloque de datos del archivo que se espera recibir pero que no se recibe, comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende:

un número de bloque; un identificador de codificación; un identificador de recursos uniforme del archivo; y unos parámetros de archivo; y

retransmitir el bloque de datos identificado.
2.

Método según la reivindicación 1, en el que el grupo comprende además un conjunto de parámetros de sesión.
3.

Método según la reivindicación 1, en el que la identificación del bloque de datos comprende identificar el bloque de datos sobre la base de un identificador de objeto de transmisión.
4.

Método según la reivindicación 1, en el que la transferencia de uno o más bloques de datos de un archivo comprende transferir usando un protocolo basado en sesiones, dirigido a la entrega de archivos a través de un transporte unidireccional, y con capacidad de transmisión de uno-a-muchos.
5.

Método según la reivindicación 4, en el que el uso del protocolo basado en sesiones comprende usar una entrega de archivos a través de un transporte unidireccional.
6.

Método según la reivindicación 1, en el que el número de bloque comprende un número de bloque fuente.
7.

Método según la reivindicación 1, en el que el identificador de codificación comprende un identificador de símbolo de codificación.
8.

Método según la reivindicación 2, en el que el conjunto de parámetros de sesión se selecciona de entre un grupo que comprende: una dirección de origen, una dirección de destino; y un identificador de sesión de transmisión.
9.

Método según la reivindicación 1, en el que el grupo comprende además un identificador de objeto de transmisión.
10.

Método según la reivindicación 1, en el que el grupo comprende además información de constitución de bloques.
11.

Método según la reivindicación 1, en el que el grupo comprende además unos parámetros de archivo, comprendiendo los parámetros de archivo por lo menos uno de entre longitud de archivo y código de cifrado.
12.

Método según la reivindicación 1, en el que la información de constitución de bloques comprende información de constitución de bloques seleccionada de entre un grupo que comprende: un algoritmo de bloques, una longitud máxima de los bloques fuente, una longitud de los símbolos de codificación, y una longitud de los archivos.
13.

Método según la reivindicación 1, que comprende además proporcionar una sesión entre el emisor y el receptor para la transmisión de bloques de datos usando un protocolo dirigido a la transmisión en un escenario de uno-amuchos.
14.

Método según la reivindicación 1, en el que la retransmisión del bloque de datos identificado comprende enviar un mensaje de acuse de recibo negativo desde el receptor hasta el emisor.
15.

Método según la reivindicación 14, en el que la transferencia de uno o más bloques de datos de un archivo desde un emisor hasta por lo menos un receptor comprende transferir uno o más bloques de datos en una primera sesión; y comprendiendo el envío de un mensaje de acuse de recibo negativo enviar un mensaje de acuse de recibo negativo que provoca que se produzca la retransmisión durante la primera sesión.
16.

Método según la reivindicación 14, en el que la transferencia de uno o más bloques de datos de un archivo desde un emisor hasta por lo menos un receptor comprende transferir uno o más bloques de datos en una primera sesión; y comprendiendo el envío de un mensaje de acuse de recibo enviar un mensaje de acuse de recibo negativo

10 5

15

25

35

45

55

65 E05708197

05-08-2014

que provoca que se produzca la retransmisión durante una segunda sesión.
17.

Método según la reivindicación 16, en el que el envío de un mensaje de acuse de recibo negativo que provoca que se produzca la retransmisión durante la segunda sesión comprende enviar el mensaje de acuse de recibo negativo que provoca que se produzca la retransmisión durante una segunda sesión establecida después de la expiración de la primera sesión.
18.

Método según la reivindicación 14, en el que el envío del mensaje de acuse de recibo negativo comprende enviar una solicitud para retransmitir uno o más bloques de datos.
19.

Método según la reivindicación 14, en el que el envío del mensaje de acuse de recibo negativo comprende enviar el mensaje de acuse de recibo negativo al final de una sesión de transmisión, significando el mensaje de acuse de recibo negativo un inicio de una nueva sesión con el fin de llevar a cabo la retransmisión de bloques ausentes.
20.

Método según la reivindicación 1, que comprende además almacenar un contexto de sesión para un uso posterior.
21.

Método según la reivindicación 20, en el que el contexto de sesión comprende por lo menos uno de entre el grupo que comprende los identificadores que comprenden: un número de bloque fuente, un identificador de símbolo de codificación, un identificador de sesión de transmisión, un identificador de objeto de transmisión, y/o un identificador que identifica de manera exclusiva el propio contexto de sesión.
22.

Método según la reivindicación 1, en el que la transferencia de uno o más bloques de datos de un archivo desde un emisor hasta por lo menos un receptor comprende transferir usando una primera entrega de archivos a través de una sesión de transporte unidireccional y la retransmisión del bloque de datos identificado comprende retransmitir usando una segunda entrega de archivos a través de una sesión de transporte unidireccional.
23.

Método según la reivindicación 1, en el que la retransmisión del bloque de datos identificado comprende:

enviar un mensaje de acuse de recibo negativo desde uno o más receptores al emisor a través de una sesión de punto-a-punto; y

retransmitir el bloque de datos identificado a través de una sesión de punto-a-multipunto.
24.

Método según la reivindicación 1, en el que la retransmisión del bloque de datos identificado comprende retransmitir usando una transmisión de punto-a-punto por unidifusión.
25.

Dispositivo de recepción (20) para la entrega de archivos en un sistema con capacidad de transmisión de uno-amuchos, comprendiendo el dispositivo de recepción:

unos medios para recibir uno o más bloques de datos de un archivo desde un emisor (10);

caracterizado por que comprende:

unos medios para identificar un bloque de datos del archivo que se espera recibir pero que no se recibe, comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende:

un número de bloque; un identificador de codificación; un identificador de recursos uniforme del archivo; y unos parámetros de archivo; y

unos medios para provocar la retransmisión del bloque de datos identificado.
26.

Dispositivo de recepción según la reivindicación 25, en el que el grupo comprende además un conjunto de parámetros de sesión.
27.

Dispositivo de recepción según la reivindicación 25, en el que el grupo comprende además un identificador de objeto de transmisión.
28.

Dispositivo de recepción según la reivindicación 25, en el que el grupo comprende además información de constitución de bloques.
29.

Soporte de memoria legible por ordenador que comprende código de programa que se puede hacer funcionar, cuando es ejecutado por un procesador en un dispositivo de recepción (20) para la entrega de archivos en un

11 E05708197

05-08-2014

sistema con capacidad de transmisión de uno-a-muchos, para: recibir uno o más bloques de datos de un archivo desde un emisor (10); 5 y caracterizado por que se puede hacer funcionar para identificar un bloque de datos del archivo que se espera recibir pero que no se recibe, comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende: 10 un número de bloque; un identificador de codificación; un identificador de recursos uniforme del archivo; y parámetros de archivo; y 15 provocar la retransmisión del bloque de datos.
30. Dispositivo de emisión (10) para la entrega de archivos en un sistema con capacidad de transmisión de uno-amuchos, comprendiendo el dispositivo de emisión:

20 unos medios para transmitir uno o más bloques de datos de un archivo a por lo menos un receptor (20);

caracterizado por que comprende:

unos medios para identificar un bloque de datos del archivo que se espera recibir pero que no se recibe,

25 comprendiendo la identificación del bloque de datos identificar el bloque de datos sobre la base del grupo que comprende:

un número de bloque;

30 un identificador de codificación; un identificador de recursos uniforme del archivo; y unos parámetros de archivo; y

unos medios para retransmitir el bloque de datos identificado. 35
31. Soporte de memoria legible por ordenador, que comprende código de programa que se puede hacer funcionar, cuando es ejecutado por un procesador en un dispositivo de emisión (10) para la entrega de archivos en un sistema con capacidad de transmisión de uno-a-muchos, para:

40 transmitir uno o más bloques de datos de un archivo a por lo menos un receptor (20);

y caracterizado por que se puede hacer funcionar para

retransmitir un bloque de datos del archivo que se espera recibir pero no se recibe, en donde el bloque de datos 45 se identifica sobre la base del grupo que comprende un número de bloque, un identificador de codificación, un identificador uniforme de recursos del archivo y parámetros de archivo.
32. Sistema con capacidad de transmisión de uno-a-muchos, comprendiendo el sistema:

50 el dispositivo de recepción según cualquiera de las reivindicaciones 25 a 28; y el dispositivo de emisión según la reivindicación 30.
33. Sistema según la reivindicación 32, en el que la información de archivo comprende un conjunto de parámetros de

sesión y un identificador de objeto de transmisión. 55
34. Sistema según la reivindicación 32, en el que la información de archivo comprende un identificador de objeto de transmisión.
35. Sistema según la reivindicación 32, en el que la información de archivo comprende información de constitución 60 de bloques.

12