MX2010012117A - Manipulacion de canal rapida y proteccion de corriente de alta calidad sobre un canal de difusion. - Google Patents

Manipulacion de canal rapida y proteccion de corriente de alta calidad sobre un canal de difusion.

Info

Publication number
MX2010012117A
MX2010012117A MX2010012117A MX2010012117A MX2010012117A MX 2010012117 A MX2010012117 A MX 2010012117A MX 2010012117 A MX2010012117 A MX 2010012117A MX 2010012117 A MX2010012117 A MX 2010012117A MX 2010012117 A MX2010012117 A MX 2010012117A
Authority
MX
Mexico
Prior art keywords
data
block
physical layer
symbols
source
Prior art date
Application number
MX2010012117A
Other languages
English (en)
Inventor
Michael G Luby
Thomas Stockhammer
Mohammad Amin Shokrollahi
Original Assignee
Digital Fountain Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digital Fountain Inc filed Critical Digital Fountain Inc
Publication of MX2010012117A publication Critical patent/MX2010012117A/es

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2383Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4382Demodulation or channel decoding, e.g. QPSK demodulation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4383Accessing a communication channel
    • H04N21/4384Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency

Abstract

La señalización del envío de bloques fuente dentro de múltiples bloques de capa física se realiza para aplicaciones de entrega de objeto y en corriente, utilizando sobrecarga adicional mínima, y en algunos casos ninguna sobrecarga, para señalizar bloques fuente intercalados dentro de un bloque de capa física, señalizando la manera en que los símbolos están relacionados con los bloques fuente a partir de los cuales son generados, y señalizando el envío e indicaciones de datos priorizados para bloques fuente; la organización y envío de corrientes sobre uno o más canales se puede realizar para mejorar la calidad de las corrientes entregadas, al mismo tiempo que se reduce al mínimo o se mejora la cantidad necesaria de recursos de canal y recursos de potencia del receptor necesarios.

Description

MA : NI ¡PUL ,—A .CI 1ON >—. DE CA .NAL R—A—PI 1D !A 1 Y PRO ,T¦ iECC JI¦O ,N¦ ¦DE l CO ? R IRI—E—N—TE—D—E ALTA CALIDAD SOBRE UN CANAL DE DIFUSION CAMPO DE LA INVENCION La presente invención se refiere a corriente y entrega de objeto en general y, en particular a corriente y entrega de objeto sobre canales menos confiables utilizando FEC para proteger la calidad de la corriente entregada.
ANTECEDENTES DE LA INVENCION Se ha vuelto una práctica común considerar el envío de datos en corriente, típicamente datos de audio y/o video pero también otros tipos de datos tales como datos telemétricos, sobre un canal. Una preocupación principal es asegurar que la calidad de la corriente entregada sea alta, por ejemplo, que todos o la mayoría de los datos de corriente original sean entregados a un receptor o conjunto de receptores, o que la calidad del video de la reproducción en un receptor o un conjunto de receptores sea alta. Por ejemplo, el canal sobre el cual los datos en corriente son entregados puede no ser completamente confiable, por ejemplo, partes de los datos se pierden o corrompen en la transmisión. Por lo tanto, con frecuencia se tiene el caso en que se necesitan tomar otras medidas para superar la degradación de la entrega a fin de lograr una entrega de alta calidad, en donde dichas medidas pueden incluir la aplicación de FEC a la corriente de datos original, por ejemplo, en la capa física para proteger contra la corrupción del paquete o en el enlace, transporte o capa de aplicación para proteger contra la pérdida de paquete. Otras medidas incluyen utilizar una estrategia de retransmisión para retransmitir datos perdidos o corrompidos, por ejemplo, un protocolo de retransmisión de capa de enlace o un protocolo de retransmisión de capa de aplicación.
Otra preocupación principal cuando se diseña dicho sistema es, por ejemplo, la cantidad de tiempo que le toma iniciar la muestra de una corriente de video desde el momento en que un usuario final solicita primero el inicio de la visualización de la corriente de video, o la cantidad de tiempo que le toma detener la muestra de una corriente de video actual e iniciar la muestra de una nueva corriente de video disparada por una solicitud de usuario. Esta cantidad de tiempo con frecuencia se denomina como el tiempo de manipulación de canal. Típicamente, mientras más corto es el tiempo de manipulación de canal, mejor es la experiencia del usuario final y, por lo tanto, más valioso el servicio en general. Por ejemplo, con frecuencia un requerimiento es que el tiempo de manipulación de canal sea lo más pequeño posible, por ejemplo, por debajo de 1 segundo .
Con frecuencia es posible lograr dichos tiempos de manipulación de canal y entrega de corriente de alta calidad cuando las corrientes son entregadas sobre canales altamente confiables sin canal de respaldo o, cuando las corrientes son entregadas sobre canales menos confiables y cuando existe un canal de respaldo que puede ser utilizado para solicitar la retransmisión de datos perdidos, pero con frecuencia un reto es lograr dichos tiempos de manipulación de canal cuando la corriente es entregada sobre canales menos confiables y cuando no se está utilizando un canal de respaldo para mejorar la conflabilidad, y por el contrario el uso de FEC pudiera ser apropiado.
Recientemente, se ha vuelto una práctica común considerar el uso de códigos FEC para protección de medios en corriente durante la transmisión. Cuando se envía sobre una red de paquete, ejemplos de los cuales incluyen la Internet y redes inalámbricas tal como aquellas estandarizadas por grupos tales como 3GPP, 3GPP2 y DVB, la corriente fuente es colocada en paquetes a medida que es generada o puesta a disposición, y por lo tanto los paquetes son utilizados para llevar la corriente fuente en el orden en que es generada o puesta a disposición de los receptores. En una aplicación típica de códigos FEC a estos tipos de escenarios, el código FEC es utilizado para agregar paquetes de reparación adicionales a los paquetes fuente originales que contienen . la corriente fuente, y estos paquetes de reparación tienen la propiedad que, cuando ocurre una pérdida de paquete fuente, paquetes de reparación recibidos pueden ser utilizados para recuperar los datos contenidos en los paquetes fuente perdidos. En otros ejemplos, es posible que ocurra una pérdida parcial de paquetes, es decir, los receptores pueden perder partes de un paquete mientras que reciben otras partes de ese paquete, y por lo tanto, en estos ejemplos paquetes de reparación completa o parcialmente recibidos pueden ser utilizados para recuperar paquetes fuente parcial o completamente perdidos. En otros ejemplos todavía, puede ocurrir otros tipos de corrupción a los datos enviados, por ejemplo, valores de bits pueden ser basculados, y por lo tanto, se pueden utilizar paquetes de reparación para corregir dicha corrupción y proporcionar una recuperación lo más precisa posible de los paquetes fuente. En otros ejemplos, la corriente fuente no necesariamente es enviada en paquetes discretos, sino que mas bien puede ser enviada, por ejemplo como una corriente de bits continua.
Existen muchos ejemplos de códigos FEC que pueden ser utilizados para proporcionar protección de una corriente fuente. Los códigos Reed-Solomon son códigos muy conocidos para la corrección de error y borrado en sistemas de comunicación. Para corrección de borrado sobre, por ejemplo, redes de datos en paquete, una implementación eficiente bien conocida de los códigos Reed-Solomon es utilizar matrices Cauchy q Vandermonde tal como se describe en L. Rizzo, "Effective Erasure Codes for Reliable Computer Communication Protocols" , Computer Communication Review, 27(2):24-36 (Abril 1997) (en lo sucesivo "Rizzo") y J. Bloemer, M. Kalfane, R. Karp, M. Karpinski, M. Luby, D. Zuckerman, "An XOR-Based Erasure -Resilient Coding Scheme" , Technical Report TR-95-48, International Computer Science Institute, Berkeley, California, (1995) (en lo sucesivo "XOR-Reed-Solomon" ) . Otros ejemplos de códigos FEC incluyen códigos LDPC, códigos de reacción en cadena y códigos de reacción en cadena multi-etapa, tal como aquellos descritos en la Patente EUA No. 6,307,487 (en lo sucesivo "Luby I") y la Solicitud de Patente Publicada EUA No. 2003/0058958 (en lo sucesivo "Shokrollahi I"), respectivamente, las cuales se incorporan aquí para todos los propósitos.
Ejemplos del proceso de decodificación FEC para variantes de códigos Reed-Solomon se describen en "Rizzo" y "XOR-Reed-Solomon" . En estos ejemplos, la decodificación se aplica una vez que se han recibido suficientes paquetes de datos fuente y de reparación. El proceso de decodificación puede ser computacionalmente intenso y, dependiendo de los recursos disponibles del CPU, esto puede tomar un tiempo considerable de completar, con relación a la longitud de tiempo abarcada por el medio en el bloque.
En muchas aplicaciones, los paquetes además son subdivididos en símbolos en los cuales se aplica el proceso FEC. Un símbolo puede tener cualquier tamaño, pero con frecuencia el tamaño de un símbolo es máximo igual al tamaño del paquete. En lo sucesivo, podemos denominar a los símbolos que comprende el bloque de codificación los símbolos fuente" , y los símbolos generados durante el proceso FEC los "símbolos de codificación" . Para algunos códigos FEC, notablemente códigos Reed-Solomon, el tiempo de codificación y decodificación se vuelve impráctico a medida aumenta que el número de símbolos de codificación por bloque fuente. Por lo tanto, en la práctica, con frecuencia existe un límite superior, por ejemplo, 255, en el número total de símbolos de codificación que pueden ser generados por bloque fuente. Debido a que los símbolos con frecuencia son colocados en diferentes cargas útiles de paquete, esto en ocasiones coloca un límite superior práctico sobre la longitud máxima en la codificación de un bloque fuente, por ejemplo, si un carga útil de paquete es máximo 1024 bytes, entonces un bloque fuente codificado puede ser máximo 255 KB (kilobytes) , y por supuesto esto también es un límite superior práctico sobre el tamaño del bloque fuente en sí mismo si cada símbolo es enviado en un paquete separado.
Con frecuencia es deseable aplicar la codificación y decodificación FEC en bloques de datos dentro de una corriente que es enviada esparcida sobre un periodo de tiempo largo, debido a que la aplicación de la codificación FEC sobre bloques de datos que son enviados sobre un intervalo de tiempo más largo, generalmente proporciona mejor protección a la corriente para la misma sobrecarga de ancho de banda que la codificación FEC sobre bloques de datos que son enviados sobre un intervalo de tiempo más pequeño. Esto se debe a que muchos - canales están sujetos a características de corrupción y/o pérdida correlacionadas con el tiempo, por ejemplo, es probable que los datos se pierdan en ráfagas, o es probable que haya periodos de tiempo cortos cuando las características del canal son mucho peores de lo que pueden ser sobre otros intervalos de tiempo cortos.
Un reto con el uso de la codificación FEC aplicada a bloques de datos que son enviados esparcidos sobre un intervalo de tiempo más largo es que esto puede afectar de manera adversa el tiempo de manipulación de canal. Por ejemplo, en el receptor, un bloque de datos codificados sólo puede ser completamente recuperado y reproducido después que se han recibido suficientes datos para el bloque completo. Por lo tanto, si el bloque de datos codificados FEC es enviado sobre un intervalo de tiempo más largo, entonces el tiempo de manipulación de canal puede ser inaceptablemente alto.
Un método para lograr el objetivo del tiempo de manipulación de canal corto mientras que al mismo tiempo se envía un bloque de datos codificados FEC sobre un intervalo de tiempo más largo es ordenar los datos en una manera en que los datos más importantes sean enviados al último y los datos menos importantes sean enviados primero entre los datos codificados FEC. Por ejemplo, la Solicitud de Patente EUA No .11/423 , 391 , titulada "Codificación y Corriente de Corrección de Error de Avance (FEC)" (en lo sucesivo "Corriente FEC"), la cual se incorpora aquí para todos los propósitos, describe métodos para enviar datos de reparación FEC antes que los datos fuente para un. bloque fuente, permitiendo así a un receptor recibir una porción de los datos fuente para el bloque fuente e iniciar el envío de éstos, por ejemplo, a un reproductor de medios para reproducción incluso si el receptor une la corriente a la mitad del bloque fuente, reduciendo así al mínimo el tiempo de manipulación de canal.
Otra preocupación es reducir al mínimo la cantidad de recursos del canal utilizados por datos de cabecera que son utilizados para identificar los datos reales que van a ser enviados. En general, los datos de cabecera generalmente son de sobrecarga que impactan negativamente la cantidad de capacidad que está disponible para la entrega de datos. Por ejemplo, si se utilizan 4 bytes de datos de cabecera para identificar cada 100 bytes de datos reales, entonces la sobrecarga de cabecera es un significativo 4%. Es deseable reducir al mínimo la sobrecarga de cabecera lo más posible, específicamente para aplicaciones de entrega de objeto y corriente, pero de manera más general para cualquier aplicación de entrega de datos .
Lo que se desea son métodos, procesos y aparatos que permitan que una corriente de alta calidad sea entregada sobre canales menos confiables cuando no se utilizan canales de respaldo para mejorar la conflabilidad en las situaciones en que se requieren tiempos de manipulación de canal cortos. También es de vital importancia la reducción al mínimo de los recursos físicos para lograr un nivel de conflabilidad determinado, por ejemplo, sobrecargas de cabecera y sobrecargas FEC.
SUMARIO DE LA INVENCION Modalidades presentan métodos y procesos novedosos para enviar y recibir datos en corriente sobre un canal utilizando códigos FEC para proporcionar entrega de alta calidad y permitir tiempos de manipulación de canal cortos. Se describen métodos de señalización novedosos que reducen al mínimo las sobrecargas de cabecera necesarias en dicho sistema para entrega de objeto y corriente. También se describen arreglos novedosos para enviar y proteger corrientes.
La siguiente descripción detallada junto con las figuras acompañantes proporcionará un mejor entendimiento de la naturaleza y ventajas de la presente invención.
BREVE DESCRIPCION DE LAS FIGURAS La figura 1 es un diagrama en bloques de un sistema de comunicaciones de acuerdo con una modalidad de la presente invención.
La figura 2 es un dibujo que ejemplifica los componéntés de la latencia del receptor para un sistema conocido .
La figura 3 es un dibujo que ejemplifica los componentes de la latencia del receptor cuando símbolos de reparación FEC son enviados antes que los símbolos fuente correspondientes a partir de los cuales se generan.
La figura 4 es un diagrama en bloques que ilustra la manera en que una modalidad puede priorizar datos en sub-bloques y mapear los sub-bloques en un orden de envío priorizado .
La figura 5 es un diagrama en bloques que ilustra la manera en que una modalidad puede mapear sub-relojes en bloques de capa física con base en el mapeo integral de sub-bloques en cada bloque de capa física.
La figura 6 es un diagrama en bloques que ilustra la manera en que una modalidad puede mapear sub-relojes en bloques de capa física donde una cantidad igual de datos de sub-bloque es mapeada a cada bloque de capa física y en la cual sub-bloques son divididos en ocasiones a través de los bloques de capa física.
DESCRIPCION DETALLADA DE LA INVENCION Modalidades aquí descritas proporcionan métodos novedosos para señalizar el envío de bloques fuente dentro de múltiples bloques de capa física, tanto para aplicaciones de corriente como de entrega de objeto. Estos métodos de señalización comprenden métodos que utilizan sobrecarga adicional mínima, y en algunos casos ninguna sobrecarga, para señalizar bloques fuente intercalados dentro de un bloque de capa física, señalizando la manera en que los símbolos están relacionados con los bloques fuente a partir de los cuales son generados, y señalizando el envío e indicaciones de datos priorizados para bloques fuente. Se describen métodos adicionales para organizar y enviar corrientes sobre más canales que mejoran la calidad de las corrientes entregadas, al mismo tiempo que se reduce al mínimo o se mejora la cantidad necesaria de recursos del canal y recursos de potencia del receptor necesarios.
En lo sucesivo, se asume que la red que lleva datos está basada en paquete para simplificar las presentes descripciones, con el reconocimiento de que un experto en la técnica fácilmente puede observar la manera en que los procesos y métodos aquí descritos se pueden aplicar a otros tipos de redes de transmisión tal como redes de corriente de bits continua. En lo sucesivo se asume que los códigos FEC proporcionan protección contra paquetes perdidos o datos de pérdida parcial dentro de los paquetes para simplificar las presentes descripciones, con el reconocimiento de que un experto en la técnica fácilmente puede observar la manera en que los procesos, y métodos aquí descritos se pueden aplicar a otros tipos de corrupción de transmisión de datos, tal como basculamientos de bits.
La figura 1 es un diagrama en bloques de un sistema de comunicaciones 100 que utiliza codificación de reacción en cadena. En el sistema de comunicaciones 100, un archivo de entrada 101, o una corriente de entrada 105, es proporcionada a un generador de símbolos de entrada 110. El generador de símbolos de entrada 110 genera una secuencia de uno o más símbolos de entrada (IS(0), IS(1), IS(2), ...) desde el archivo o corriente de entrada, donde cada símbolo de entrada tiene un valor y una posición (denotado en la figura 1 como un entero en paréntesis) . Los posibles valores para los símbolos de entrada, es decir, su alfabeto, típicamente es un alfabeto de 2M símbolos, de manera que cada símbolo de entrada se codifica para M bits del archivo de entrada. El valor de M generalmente es determinado por el uso del sistema de comunicación 100, pero un sistema de propósito general pudiera incluir una entrada de tamaño de símbolo para el generador de símbolos de entrada 110 de manera que M puede ser modificado de uso a uso. La salida del generador de símbolos de entrada 110 es proporcionada a un codificador 115.
El generador de clave 120 genera una clave para cada símbolo de salida que va a ser generado por el codificador 115. Cada clave es generada de acuerdo con uno de los métodos descritos en Luby I o en Shokrollahi I, o cualquier método comparable que asegure que una fracción grande de las claves generadas para el mismo archivo de entrada o bloque de datos en una corriente es única, ya sea que éstas sean generadas por éste u otro generador de clave. Por ejemplo, el generador de clave 120 puede utilizar una combinación de la salida de un contador 125, un identificador de corriente única 130, y/o la salida de un generador aleatorio 135 para producir cada clave. La salida del generador de clave 120 se proporciona al codificador 115. En otros ejemplos, por ejemplo algunas aplicaciones de corriente, el conjunto de claves puede ser fijo y reutilizado una vez más para cada bloque de datos en una corriente.
A partir de cada clave I proporcionada por el generador de clave 120, el codificador 115 genera un símbolo de salida, con un valor B(I), a partir de los símbolos de entrada proporcionados por el generador de símbolos de entrada. El valor de cada símbolo de salida es generado con base en su clave y en alguna función de uno o más de los símbolos de entrada, referidos aquí como "símbolos de entrada asociados" del símbolo de salida o simplemente sus "asociados". Típicamente, pero no siempre, M es lo mismo para los símbolos de entrada y símbolos de salida, es decir, ambos codifican para el mismo número de bits .
En algunas modalidades, el número K de símbolos de entrada es utilizado por el codificador para seleccionar a los asociados. Si K no es conocido por anticipado, tal como en la situación donde la entrada es una corriente y K puede variar entre cada bloque en la corriente, K puede ser sólo un estimado. El valor K también pudiera ser utilizado por el codificador 115 para asignar almacenamiento para símbolos de entrada.
El codificador 115 proporciona símbolos de salida a un módulo de transmisión 140. El módulo de transmisión 140 también recibe la clave de cada símbolo de salida desde el generador de clave 120. El módulo de transmisión 140 transmite los símbolos de salida, y dependiendo del método de generación de claves utilizado, el módulo de transmisión 140 también podría transmitir algunos datos relacionados con las claves de los símbolos de salida transmitidos, sobre un canal 145 a un módulo de recepción 150. Se asume que el canal 145 es un canal de borrado, pero eso no es un requerimiento para la operación adecuada del sistema de comunicación 100. Los módulos 140, 145 y 150 pueden ser cualesquiera componentes de hardware convenientes, componentes de software, medios, físicos, o cualquier combinación de los mismos, siempre y cuando el módulo de transmisión 140 esté adaptado para transmitir símbolos de salida y cualquier dato necesario referente a sus claves para el canal 145 y el módulo de recepción 150 esté adaptado para recibir símbolos y potencialmente algunos datos sobre sus claves del canal 145. El valor de K, si se utiliza para determinar a los asociados, puede ser enviado sobre el canal 145, o puede ser establecido por anticipado mediante acuerdo del codificador 115 y el decodificador 155.
El canal 145 puede ser un canal de tiempo real, tal como una trayectoria a través de la Internet o un enlace de difusión desde un transmisor de televisión a un destinatario de televisión o una conexión de teléfono desde un punto a otro, o el canal 145 puede ser un canal de almacenamiento, tal como un CD-ROM, unidad de disco, sitio Web, o similar. El canal 145 incluso podría ser una combinación de un canal de tiempo real y un canal de almacenamiento, tal como un canal formado cuando una persona transmite un archivo de entrada desde una computadora personal a un Proveedor de Servicio de Internet (ISP) sobre una línea telefónica, el archivo de entrada es almacenado en un servidor Web y posteriormente es transmitido a un destinatario sobre la Internet.
En la situación donde el canal 145 comprende una red de paquete, el sistema de comunicaciones 100 pudiera no estar en condiciones de asumir que el orden relativo de cualesquiera dos o más paquetes sea preservado en el tránsito a través del canal 145. Por lo tanto, la clave de los símbolos de salida se determina utilizando uno o más de los esquemas de generación de claves antes descritos, y no necesariamente es determinada por el orden en el cual los símbolos de salida salen del módulo de recepción 150.
El módulo de recepción 150 proporciona los símbolos de salida a un decodificador 155, y cualquier módulo de recepción de datos 150 recibe las claves de estos símbolos de salida que son proporcionadas a un regenerador de clave 160. El regenerador de clave 160 regenera las claves para los símbolos de salida recibidos y proporciona estas claves al decodificador 155. El decodificador 155 utilizada las claves proporcionadas por el regenerador de clave 160 junto con los símbolos de salida correspondientes, para recuperar los símbolos de entrada (una vez más IS(0), IS(1), IS(2), ...). El decodificador 155 proporciona los símbolos de entrada recuperados a un re-ensamblador de archivo de entrada 165, el cual genera una copia 170 del archivo de entrada 101 o una copia 175 de la corriente de entrada 105.
Cuando se utilizan en aplicaciones de corriente de medios, los paquetes fuente que forman la corriente de medios fuente en ocasiones son recolectados en grupos denominados bloques fuente. Por ejemplo, un bloque fuente podría ser uñ grupo de paquetes fuente que abarca una longitud de tiempo fija, y por ejemplo un código de borrado Reed-Solomon podría ser aplicado de manera independiente a estos bloques fuente para generar paquetes de reparación que son enviados, junto con los paquetes fuente originales del bloque fuente, a los receptores.
En el remitente, la corriente fuente puede ser continuamente dividida en bloques fuente a medida que llegan los paquetes fuente, y después se generan paquetes de reparación para cada bloque fuente y son enviados. Es preferible reducir al mínimo el retardo total extremo-a-extremo agregado por el uso de códigos FEC, especialmente para aplicaciones en corriente interactivas o en vivo, y por lo tanto es preferible si el diseño general de la solución FEC es tal que los paquetes fuente son retardados lo más poco posible en el remitente antes de ser enviados, y todos los paquetes de reparación y fuente para un bloque fuente son enviados con lo más poco posible de retardo.
También es preferible si la velocidad de la corriente codificada FEC es lo más suave posible, es decir, hay la más poca variabilidad posible en la velocidad de la corriente codificada FEC o al menos no hay amplificación de alguna variabilidad que ya exista en la corriente fuente original, debido a que esto hace que el uso del ancho de banda de la corriente codificada FEC sea más previsible y reduce al mínimo el impacto en la red y en otras corrientes posiblemente en competencia. También es preferible si los datos enviados en paquetes para un bloque fuente son esparcidos de la manera más uniforme posible sobre el periodo cuando los paquetes son enviados para ese bloque fuente, debido a que esto proporciona la mejor protección contra pérdidas de ráfaga.
En el receptor, si se pierden paquetes o si éstos son recibidos con errores (los cuales pueden ser detectados y descartados, por ejemplo, utilizando revisiones CRC) , entonces, asumiendo que suficientes paquetes de reparación han sido recibidos, los paquetes de reparación pueden ser utilizados para recuperar uno o más de los paquetes fuente perdidos .
En algunas aplicaciones, los paquetes además son subdivididos en símbolos en los cuales se aplica el proceso FEC. Para algunos códigos FEC, notablemente códigos Reed- Solomon, el tiempo de codificación y decodificación se vuelve impráctico a medida que crece el número de símbolos de codificación por bloque fuente y con frecuencia hay un límite superior en el número total de símbolos de codificación que pueden ser generados por bloque fuente. Debido a que los símbolos generalmente son colocados en diferentes cargas útiles de paquete cuando son utilizados en la capa de aplicación, esto coloca un límite superior práctico sobre la longitud máxima en la codificación de un bloque fuente . y esto también por supuesto es un límite superior en el tamaño del bloque fuente en sí mismo.
Para muchas aplicaciones, cuando se va a proporcionar protección sobre un periodo de tiempo largo o cuando la velocidad de la corriente de medios es alta, puede ser conveniente proporcionar protección sobre un tamaño de bloque fuente más grande de lo que puede ser soportado al llevar un símbolo por paquete. En estos casos, el uso de bloques fuentes más cortos y después la intercalación de los paquetes fuente de diferentes bloques fuente proporciona una solución donde los paquetes fuente de un bloque fuente individual . son esparcidos sobre periodos de tiempo más largos. Otro método relacionado es formar el bloque fuente más grande de símbolos más grandes que no se ajustan en los paquetes, y dividir los símbolos en sub- símbolos que pueden ser colocados en paquetes consecutivos. Al utilizar este método, se pueden soportar bloques fuente más grandes, a expensas de tener patrones de corrupción o pérdida de sub-símbolos potencialmente diferentes para un símbolo. No obstante, en muchos casos, en la situación donde un canal muestra una corrupción fuertemente correlacionado o en ráfaga, la pérdida o corrupción de sub-símbolos que comprenden un símbolo está altamente correlacionada, y por lo tanto en ocasiones hay poca degradación de la protección FEC proporcionada cuando se utiliza este método.
Terminología Códigos FEC En esta descripción, se asume que los datos que van a ser codificados (datos fuente) han sido separados en "símbolos", de igual longitud, los cuales pueden ser de cualquier . longitud (incluso hasta un solo bit) . Los símbolos pueden ser llevados sobre la red de datos en paquetes, con un número completo de símbolos explícitamente llevados o implicados en cada paquete. En algunos casos, es posible que un paquete fuente no sea un múltiplo de la longitud de símbolo, en cuyo caso, el último símbolo en el paquete puede ser truncado. En este caso, para los propósitos de la codificación FEC, se asume que este último símbolo de manera implícita está .rellenado con un patrón fijo de bits, por ejemplo, bits de valor cero, de manera que aún cuando estos bits no son llevados en el paquete, el receptor, puede seguir rellenando este último símbolo truncado a un símbolo completo. En otras modalidades, el patrón fijo de bits puede ser colocado en el paquete, rellenando así de manera efectiva los símbolos a una longitud igual a aquella del paquete. El tamaño de un símbolo con frecuencia puede ser medido en bits, donde un símbolo tiene el tamaño de M bits y el símbolo es seleccionado de un alfabeto de 2M símbolos. También se tienen contemplados dígitos no binarios, pero se prefieren los bits binarios ya q e son utilizados de manera más común.
Los códigos FEC que en este documento se consideran para corriente típicamente son códigos FEC sistemáticos, es decir, los símbolos fuente del bloque fuente son incluidos como parte de la codificación del bloque fuente y, por lo tanto, los símbolos fuente son transmitidos. Un código FEC sistemático entonces genera a partir de un bloque fuente de símbolos fuente cierto número de símbolos de reparación, y después la combinación de los símbolos fuente y de reparación son los símbolos de codificación que so enviados para el bloque fuente. Algunos de los códigos FEC tienen la capacidad para generar de manera eficiente tantos símbolos de reparación como sea necesario. Dichos códigos se refieren como "códigos aditivos de información" y como "códigos de fuente" y ejemplos de estos códigos incluyen "códigos de reacción en cadena" y "códigos de reacción en cadena de multi-etapa" .
Otros códigos FEC tal como los códigos Reed-Solomon de manera práctica pueden sólo generar un número limitado de símbolos de reparación a partir de un número limitado de símbolos fuente. Para estos tipos de códigos, un bloque fuente" puede seguir siendo relativamente grande, en donde el bloque fuente es dividido en símbolos de un tamaño lo suficientemente grande para que el número de símbolos fuente del bloque fuente se ubique máximo en el límite superior sobre el número práctico de símbolos fuente, y de manera que el número deseado de símbolos de reparación generados a partir del bloque fuente se ubique máximo en el límite superior sobre el número práctico de símbolos de reparación. En algunos casos, cuando estos símbolos son más grandes que el tamaño apropiado para el transporte de paquetes de capa física, los símbolos además pueden ser divididos en sub- símbolos que pueden ser llevados de manera individual en dichos paquetes. Para simplificar las posteriores descripciones, típicamente se describen símbolos como unidades indivisibles, mientras que en muchos casos, los símbolos pueden estar compuestos de múltiples sub-símbolos, en donde el entendimiento es que los símbolos podrían ser divididos en sub-símbolos en las descripciones y los métodos y procesos resultantes serían bastante similares a las descripciones que utilizan símbolos.
Existen muchos otros métodos para llevar símbolos dentro de los paquetes, y aunque las siguientes descripciones utilizan este ejemplo por simplicidad, no significa que quede limitado o que sea comprensivo. En el contexto de las siguientes descripciones, el término "paquete" no pretende quedar restringido para significar literalmente lo que se envía como una sola unidad de datos. Por el contrario, significa incluir la noción más amplia de la definición de un agrupamiento lógico de símbolos y símbolos parciales que pueden o no ser enviados como una sola unidad de datos .
También existen formas de corrupción de datos diferentes a la pérdida de símbolos, por ejemplo, símbolos que en la transmisión cambian su valor o son corrompidos en otras formas, a los cuales los métodos que se describen a continuación aplican de igual manera. Por lo tanto, aunque las siguientes descripciones con frecuencia describirán la pérdida de símbolos, los métodos aplican igualmente a otros tipos de corrupción y a otros tipos de códigos FEC más allá de los códigos de borrado FEC, tal como los códigos de corrección de error FEC y códigos de suma-revisión FEC y códigos de verificación FEC.
Corriente Para los propósitos de proporcionar protección FEC de una corriente fuente, la corriente fuente puede ser una combinación de una o más corrientes lógicas, ejemplos de las cuales son una combinación de una corriente RTP de audio y una corriente RTP de video, una combinación de una corriente MIKEY y una corriente RTP, una combinación de dos o más corrientes de video, y una combinación de tráfico RTCP de control y una corriente RTP. Conforme la corriente fuente llega al remitente, en un formato que por ejemplo es una corriente de bits fuente, una corriente de símbolos fuente, o una corriente de paquete fuente, el remitente puede almacenar en memoria intermedia la corriente dentro de bloques fuente y generar una corriente de reparación a partir de los bloques fuente. El remitente programa y envía la corriente fuente y la corriente de reparación, por ejemplo, en paquetes que van a ser enviados sobre una red de paquete. La. corriente codificada FEC es la corriente fuente y de reparación combinada. El receptor recibe la corriente codificada FEC, la cual pudiera haber sido corrompida, por ejemplo, debido a pérdidas o basculamientos de bits. El receptor intenta reconstruir partes o todos los bloques fuente originales de la corriente fuente y pone a disposición, por ejemplo, para un reproductor de medios, estas partes reconstruidas de la. corriente fuente original en el receptor.
Para una aplicación en corriente, existen varios parámetros clave que son entradas al diseño de la manera en cómo utilizar los códigos FEC para proteger la corriente fuente y varias métricas clave que son típicamente de importancia para optimizar.
Dos parámetros de entrada clave en el diseño son el periodo de protección y la cantidad de protección. El periodo de protección del remitente para un bloque fuente es la duración de tiempo sobre la cual son enviados los símbolos generados a partir de ese bloque fuente. La cantidad de protección para un bloque fuente es el número de símbolos de reparación FEC enviados para el bloque fuente, expresados como una fracción o un porcentaje del número de símbolos fuente en el bloque fuente. Por ejemplo, si el periodo de protección es 2 segundos y la cantidad de protección es 20% y hay 10,000 símbolos fuente en el bloque fuente, entonces los 10,000 símbolos fuente y los 2,000 símbolos de reparación para el bloque fuente son enviados esparcidos sobre una ventana de tiempo de 2 segundos. Tanto el periodo de protección como la cantidad de protección por bloque fuente pueden variar de un bloque fuente al siguiente. Por ejemplo, cuando un bloque fuente de preferencia no abarca entre algunos paquetes fuente en una corriente fuente, por ejemplo cuando un primer paquete es el último paquete de un Grupo de Imágenes (GOP) en una corriente de video MPEG2 y un segundo paquete consecutivo es el primer paquete de un siguiente GOP, entonces un bloque fuente pudiera ser terminado después del primer paquete y antes del segundo paquete, incluso si esto ocurre antes del final de un periodo de protección. Esto permite que el bloque de protección FEC quede alineado con el bloque de codificación de video, lo cual puede tener muchas ventajas, incluyendo la ventaja de que la latencia del receptor debido al almacenamiento en memoria intermedia del video y el almacenamiento en memoria intermedia de FEC se puede reducir al mínimo.
En otras aplicaciones, puede ser conveniente, por una variedad de motivos, siempre mantener' el mismo periodo de protección y/o tamaño de bloque fuente para cada bloque fuente consecutivo. En muchas de las siguientes descripciones, por simplicidad, tanto el periodo de protección como la cantidad de protección se asumen que son las mismas para cada bloque fuente posterior. Para aquellos expertos en la técnica, debiera ser claro que esto no es una limitación, ya que uno puede fácilmente determinar, al momento de leer esta descripción, la manera en que los procesos y métodos aquí descritos también aplican cuando la cantidad de protección o periodo de protección o ambos varían de un bloque fuente al siguiente, y cuando los tamaños de bloque fuente varían de uno al siguiente.
Para simplificar algunos de los análisis posteriores, con frecuencia se asume que símbolos fuente de la corriente original llegan al remitente que va a ejecutar la codificación FEC a una velocidad constante, y que una vez que el receptor pone por primera vez a disposición los símbolos fuente en el receptor, entonces símbolos fuente posteriores son puestos a disposición por el receptor a la misma velocidad constante, asumiendo que en el primer bloque fuente desde el cual se recibe un símbolo fuente no hay pérdida de símbolos fuente y que en cada bloque fuente posterior la pérdida de símbolos de codificación es por mucho el máximo posible para permitir la decodificación FEC exitosa. Esta suposición de simplificación no es inherente en la operación o diseño de los procesos y métodos que se describen a continuación, y no pretende quedar limitada a estos procesos para esta suposición en forma alguna, sino que se introduce simplemente como una herramienta para simplificar algunas de las descripciones de las propiedades de los procesos y métodos. Por ejemplo, para corrientes de velocidad variable, la condición correspondiente es que los símbolos fuente son puestos a disposición por el receptor a la misma o casi la misma velocidad a la que llegan en el remitente.
Algunas métricas clave de importancia a minimizar incluyen la latencia del remitente, que es la latencia introducida por el remitente. La reducción al 'mínimo de la latencia del remitente es un objetivo deseable para algunas aplicaciones tales como aplicaciones interactivas o de corriente de video en vivo tal como conferencia de video. Un aspecto de un diseño general que ayuda a reducir al mínimo la latencia del remitente es que el remitente envíe símbolos fuente en el mismo orden en el que llegan en el remitente. A continuación se describen otros aspectos del diseño que reducen al mínimo la latencia del remitente.
Otra métrica importante es el tiempo de manipulación de canal. Éste es el tiempo entre el momento en que el receptor une o solicita la corriente y primero inicia la recepción de los símbolos de codificación desde la corriente hasta el momento en que el receptor primero pone a disposición los símbolos fuente de la corriente. En general, es deseable reducir al mínimo el tiempo de manipulación de canal, debido a que esto reduce al mínimo los requerimientos de memoria en el receptor para almacenar símbolos antes de que sean decodificadas y pasados por el receptor, y esto también reduce al mínimo la cantidad -de tiempo entre el momento en que una corriente es unida y cuando la corriente primero comienza a volverse disponible, por ejemplo para reproducción de una corriente de video.
Para muchos sistemas conocidos, un aspecto importante de la reducción al mínimo del tiempo de manipulación de canal es para que el remitente mantenga el orden de envío original de los símbolos fuente. En una sección posterior se describen formas novedosas para ordenar y codificar los. símbolos fuente en un bloque, aplicar los códigos FEC, y enviar los datos codificados para cada bloque fuente en formas que reducen al mínimo los tiempos de manipulación de canal.
Tal como ahora se describe, para muchos sistemas ¦ conocidos, el tiempo de manipulación de canal típicamente comprende múltiples componentes. Un ejemplo de estos componentes para una corriente que es dividida en bloques fuente secuenciales se muestra en la figura 2. La figura 2 muestra un diseño que pudiera' ser utilizado en un despliegue IPTV clásico donde existe un solo bloque fuente por periodo de protección en donde los símbolos de reparación para cada bloque fuente son enviados justo después de los símbolos fuente para ese bloque fuente, y el ejemplo muestra el caso donde el receptor une la corriente al inicio del bloque fuente. Los dos componentes del tiempo de manipulación de canal en este ejemplo son el periodo de protección y la latencia de decodificación. El periodo de protección del receptor es el tiempo durante el cual el receptor está almacenando en memoria intermedia los símbolos de codificación recibidos desde el bloque fuente. Observar que el periodo de protección del' remitente y el periodo de protección del receptor son los mismos en caso que el canal entre el remitente y el receptor no tenga alguna variación en términos de la cantidad de tiempo que le toma a cada bit, byte, símbolo o paquete desplazarse desde el remitente al receptor. Por lo tanto, en la práctica el periodo de protección del remitente puede diferir del periodo de protección del receptor para el mismo bloque fuente debido a las variaciones de temporización de la red en la entrega. Para simplificar la descripción, en lo sucesivo se asume que el periodo de protección del remitente y el periodo de protección del receptor son los mismos para cada bloque fuente, y se utiliza el término "periodo de protección" de manera sinónima para el periodo de protección del remitente y el periodo de protección del receptor, es decir, se asume que el tiempo de entrega de la red es el mismo para todos los datos, y se observa que un experto en la técnica puede realizar los cambios necesarios a los métodos y aparatos aquí descritos para tomar en cuenta diferencias en los periodos de protección del remitente y receptor debido a las fluctuaciones de entrega de la red.
El componente del periodo de protección de la latencia del receptor es inevitable en estos sistemas conocidos, debido a que incluso si en el primer bloque fuente no hay pérdida de algún símbolos fuente, incluso se tiene que retardar la puesta a disposición de los símbolos fuente al menos por el periodo de protección a fin de asegurar una entrega de símbolos fuente suave de todos los símbolos de codificación posteriores cuando hay pérdida de símbolos de codificación en bloques fuente posteriores. Durante el periodo de protección, parte o la mayoría o toda la decodificación FEC del bloq e fuente puede estar ocurriendo de manera concurrente con la recepción de los símbolos de codificación. Al final del periodo de protección, puede haber una decodificación FEC adicional que ocurra antes que el primer símbolo fuente del bloque fuente esté disponible del receptor, y este periodo de tiempo es etiquetado como la latencia de decodificación en la figura 2. Además, incluso después que el primer símbolo fuente está disponible, puede haber decodificación FEC adicional que ocurre antes que el segundo y posteriores símbolos fuente del bloque fuente estén disponibles. Por simplicidad, esta decodificación FEC adicional no se muestra en la figura 2, y se asume, en este ejemplo, que hay suficientes recursos disponibles del CPU para decodificar todos los símbolos fuente después del primero a una velocidad lo suficientemente rápida.
En estos sistemas conocidos, cuando el receptor une la corriente a la mitad de un bloque fuente, entonces el tiempo de manipulación de canal puede ser tan pequeño como un periodo de protección más la latencia de decodificación cuando no hay pérdida de símbolos fuente de ese primer bloque fuente parcial, siempre y cuando el orden de envío original de los paquetes fuente sea mantenido por el remitente. Por lo tanto, para estos sistemas conocidos, es deseable que el remitente mantenga el orden de envío original de los símbolos fuente.
Otro objetivo de un método de corriente es reducir al mínimo la latencia FEC extremo-a-extremo, la cual es la latencia general del peor caso introducida por el uso de FEC entre el momento en que un paquete fuente está listo para ser puesto en corriente en el remitente antes que la codificación FEC sea aplicada y cuando está disponible para reproducción en el receptor después que la decodificación FEC ha sido aplicada.
Otro objetivo de un método de corriente es reducir al mínimo las fluctuaciones en la velocidad de envío cuando se utiliza FEC. Un motivo para este objetivo es que, dentro de redes de paquete, las corrientes con una velocidad de envío fluctuante son más susceptibles a la pérdida de paquete debido a la congestión o sobreflujo de memoria intermedia cuando los picos en la velocidad de envío de la corriente coinciden con los picos en otro tráfico en puntos en la red con capacidad limitada. Mínimo, las fluctuaciones en la velocidad de la corriente codificada FEC no debieran ser peores que las fluctuaciones en la velocidad de la corriente fuente original, y de preferencia, a medida que se aplica más protección FEC a la corriente fuente original, las fluctuaciones en la velocidad de la corriente codificada FEC se vuelven más pequeñas. Como un caso especial, si la corriente original envía a una velocidad constante, entonces la corriente codificada FEC también debiera enviar a una velocidad que esté lo más · cerca posible de una constante.
Otro objetivo de un método de corriente es poder utilizar lógica tan simple como sea posible en el receptor. Esto es importante en muchos contextos debido a que el receptor puede estar integrado en un dispositivo con memoria computacional limitada y otras capacidades de recursos. Además, en algunos casos, puede haber una pérdida o corrupción significativa de símbolos en la transmisión, y por lo tanto el receptor pudiera tener que recuperar a partir de escenarios de pérdida o corrupción catastróficos en la situación en que, cuando las condiciones mejoran, hay poco o ningún contexto para entender desde dónde en la corriente está continuando la recepción. Por lo tanto, mientras más simple y más robusta sea la lógica del receptor, de manera más rápida y confiable el receptor podrá comenzar a recuperar y poner a disposición una vez más los símbolos fuente de la corriente fuente a partir de la recepción de la corriente.
Cuando los datos codificados FEC que van a ser enviados para un bloque fuente son enviados esparcidos sobre un periodo de tiempo más largo intercalados con datos enviados para otros bloques fuente, el envío de los datos codificados FEC para el bloque fuente debieran ser realizado de la manera más uniforme posible en tiempo para asegurar la mejor protección posible contra la pérdida o corrupción en el canal.
El envío de los datos para un bloque fuente debiera ser de manera que el receptor pueda recuperar los datos fuente del bloque fuente en un orden de prioridad determinado en una forma oportuna.
Los datos enviados para una corriente debieron ser enviados con tan poca información de cabecera asociada con la corriente como sea posible, a fin de reducir al mínimo la sobrecarga de cabecera. De preferencia, ninguna información de cabecera es enviada con la corriente, y .alguna o toda la información de cabecera es derivada de o ya está disponible de otra información incorporada en el sistema y/o alguna o toda la información de cabecera puede ser inferida de otra información, tal como la temporización de la llegada de la información en el receptor.
En la siguiente sección se describen métodos, procesos y aparatos para cumplir con algunos o todos estos objetivos.
Procesos y métodos de envío y recepción mejorados En algunos casos, los datos que van a ser entregados como un bloque pueden ser priorizados. En otros casos, los datos que van a ser entregados como un bloque no necesariamente son priorizados. En cualquier caso, una corriente original de datos es dividida en bloques fuente, datos de reparación FEC son generados para cada bloque fuente, y después los datos codificados para cada uno de dichos bloques fuente, que comprenden los datos del bloque fuente original y los datos de reparación FEC generados a partir de ese bloque fuente, son esparcidos s.obre más tiempo que el tiempo de reproducción original del bloque fuente (y por lo tanto, los datos codificados para bloques fuente posteriores son intercalados entre sí) . En estos casos, los códigos FEC aplicados pueden ser códigos de borrado, los cuales protegen los datos en la corriente contra la pérdida de datos hasta una cantidad de protección deseada, aunque también se contemplan otros tipos de códigos FEC, tal como códigos FEC que son códigos de corrección de error, o códigos FEC que pueden ser utilizados para verificar la integridad de los datos. En estos casos, mientras mayor es el tiempo en el que los datos codificados para cada bloque fuente de la corriente son enviados, denominado el periodo de protección, y mientras más igual son esparcidos los datos codificados sobre el periodo de protección, mejor es el nivel de protección contra la pérdida de paquete proporcionada por el código FEC de capa de aplicación.
En una modalidad de la presente invención, el envío de los datos codificados se realiza dentro de un • canal físico en piezas de igual tamaño, por ejemplo, 120 bytes cada una, aquí denominados paquetes de capa física. Los paquetes de capa física pueden tener un código FEC de capa física aplicado a éstos para proteger cada paquete de capa física contra la corrupción. En algunos casos, el número de paquetes de capa física, se divide en ranuras de igual número de paquetes de capa física por ranura, por ejemplo, 512 paquetes de capa física. Los protocolos en la capa física en ocasiones se pueden utilizar para distinguir e identificar de manera única los paquetes de capa física dentro de cada ranura de tiempo. En estos casos, símbolos FEC pueden ser mapeados directamente en paquetes de capa física, y además la identificación de cuáles símbolos son llevados en cuáles paquetes de capa física puede ser por mucho o completamente determinada a través del método de determinación de la identidad de los paquetes de capa física, aligerando la necesidad o eliminando por completo la necesidad de llevar datos de identificación de símbolo dentro ' de cada paquete de capa física junto con- los datos de símbolo. En algunos casos, una cantidad parcial de datos de identificación de símbolo, o cierta información referente a partir de cuál parte de la corriente o bloque fuente se generó el símbolo, de preferencia es llevada en el paquete de capa física junto con el símbolo. Por ejemplo, para un paquete de capa física de 121 bytes, pudiera haber 1 byte de dichos datos de identificación de símbolo y el tamaño de símbolo . pudieran ser los restantes 120 bytes, mientras que para determinar completamente la manera en que el símbolo fue generado a partir de las corrientes fuentes originales pudiera ser a partir de una combinación de los datos de identificación de símbolo llevados en el paquete de capa física junto con el símbolo y el método en el que el paquete de capa física es identificado de forma única, por ejemplo, mediante la posición del paquete de capa física dentro de un cuadro y/o mediante el identificador del cuadro que contiene el paquete de capa física, y/o mediante la temporización de la recepción del paquete de capa física y/o el cuadro que contiene el paquete de capa física. Por ejemplo, el identificador de 1 byte identifica la parte del bloque fuente de la cual proviene el símbolo, donde por ejemplo, las diferentes partes del bloque fuente son etiquetadas por la prioridad de la que son parte los datos de esa porción del bloque fuente, y/o son etiquetadas por la corriente de las múltiples corrientes de la que proviene un símbolo fuente .
Se pueden realizar algunas mejoras al proceso anterior si paquetes de reparación son enviados por anticipado de los paquetes fuente, por ejemplo, tal como se describe en "corriente FEC" . Este enfoque tiene el costo de inyectar retardo adicional en el remitente, debido a que los paquetes fuente generalmente son guardados en una memoria intermedia para que sean enviados después de los paquetes de reparación. Como otro ejemplo, los datos de reparación pueden ser generados a partir de todo o partes del bloque fuente. Por ejemplo, porciones de los datos de reparación pueden ser generados a partir de un bloque fuente completo, otras partes pueden ser generadas a partir de. una p más capas de prioridad diferentes del bloque fuente. Si hay datos de símbolo de identificación llevados con un símbolo en un paquete de capa física o paquete de capa de aplicación que puede abarcar más de un paquete de capa física, entonces parte de estos datos de símbolo de identificación para un símbolo de reparación pueden identificar a partir de cuáles porciones del bloque fuente se generó.
Métodos de Señalización En algunas modalidades, para cada símbolo, datos de cabecera asociados con el símbolo, por ejemplo un byte de datos de cabecera, pueden ser utilizados para señalizar información referente a ese símbolo, por ejemplo, un identificador de corriente si hay más de una corriente, un identificador de segmento si un bloque fuente va a ser enviado sobre más de un bloque de capa física, un identificador de sub-bloque si un bloque fuente comprende múltiples sub-bloques, una posición del símbolo en un bloque fuente de acuerdo con un ordenamiento de símbolo de los símbolos en el bloque fuente, etc. En algunas modalidades, algunos o todos los datos de cabecera pueden ser enviados con cada símbolo en paquetes de capa física. En otras modalidades, los datos de cabecera para cada símbolo son en gran medida o en total derivados de otra información, y pocos o ningún dato de cabecera es enviado con cada símbolo en paquetes de capa física.
Símbolos dentro de un bloque fuente ¦ De preferencia, un ordenamiento de símbolos de un bloque fuente es explícita o implícitamente determinado y es el mismo ordenamiento en uri remitente ' que en un receptor. Algunas otras propiedades preferibles en el ordenamiento en ocasiones son benéficas para una corriente o aplicación de entrega de objeto. Una propiedad preferida, por ejemplo, podría ser que el ordenamiento de los símbolos para un bloque fuente tiene todos los símbolos fuente primero en el ordenamiento seguido por todos los símbolos de reparación. Otro ejemplo es que los símbolos están en el orden determinado por la estructura de sub-bloque del bloque fuente, por ejemplo, todos los símbolos asociados con el primer sub-bloque de un bloque fuente son primeros en el ordenamiento, todos los símbolos asociados con el segundo sub-bloque de un bloque fuente son segundos en el ordenamiento, etc. Tal como se describió previamente, los símbolos también pueden comprender múltiples sub- símbolos .
ESI dentro de un bloque fuente Un ESI ( identificador de símbolos codificados) es cualquier identificador que determine, en algunos casos en conjunto con otra información tal como el número de símbolos fuente en un bloque fuente, la manera en que el símbolo es generado a partir de un bloque fuente. Un ESI puede ser explícitamente utilizado en un remitente para generar símbolos o en un receptor para identificar y/o recuperar símbolos, o el ESI puede ser utilizado de forma implícita. De preferencia, los símbolos para cada bloque fuente son ordenados en una manera en que el remitente y el receptor pueden determinar un ESI para un símbolo determinado a partir de la posición de ese símbolo dentro del ordenamiento de símbolos. Por ejemplo, si el símbolo es el j-avo símbolo en el ordenamiento de símbolos para un bloque fuente, éste pudiera ser el - caso en que el ESI para ese símbolo sea j, donde j es un entero positivo.
De preferencia, pero no de forma exclusiva, el mapeo entre ESI de los símbolos y el ordenamiento de símbolos f cilmente puede ser calculado tanto por un remitente como por un receptor. Por ejemplo, los ESI consecutivos para el conjunto ordenado de símbolos pudieran ser 0, 1, 2, 3,...,, j, j+1, etc., es decir, los ESI son enteros consecutivos comenzando en cero y, por lo tanto, la posición del símbolo es la misma que el ESI en este caso. Como otro ejemplo, los ESI consecutivos para el conjunto ordenado de símbolos pudieran ser 5, 10, 15, 20,..., 5*j , 5* (j+1), etc. Puede haber muchas otras formas para determinar el mapeo de los ESI al conjunto ordenado de símbolos que permita tanto al remitente como al receptor determinar el ESI para un símbolo determinado dada la posición del símbolo dentro del ordenamiento de símbolos. De preferencia, se puede utilizar una secuencia ESI que sea fácil de calcular tanto para el remitente como por el receptor para expresar un ordenamiento de símbolos para los símbolos asociados con un bloque fuente.
Paquetes de capa física dentro de un bloque de capa física Cuando los paquetes de capa física son enviados en bloques de capa física, el ordenamiento de los paquetes de capa física dentro de un bloque de capa física con frecuencia puede ser determinado por las propiedades de la arquitectura general. Además, la diferenciación de un bloque de capa física de otro bloque de capa física puede ser determinada por el remitente y el receptor, por ejemplo, con base en la información de temporización y la señalización de capa física. Los símbolos ordenados pueden ser mapeados a paquetes de capa . física utilizando una variedad de diferentes métodos, incluyendo mapeo congruente lineal, o utilizando un mapeo que asegure que símbolos consecutivos sean mapeados a paquetes de capa física que serán enviados en una manera diversificada en tiempo dentro del envío del bloque de capa física, por ejemplo, cada símbolo consecutivo es mapeado a un paquete de capa física que es enviado en un cuadrante de tiempo diferente del envío del bloque de capa física, o símbolos consecutivos son mapeados a paquetes de capa física que son enviados con conjuntos de frecuencias bastante divergentes.
El conjunto ordenado de símbolos que va a ser enviado en un bloque de capa física puede estar compuesto de los símbolos asociados con el identificador del primer segmento seguido por los símbolos asociados con el identificador del segundo segmento seguido por los símbolos asociados con el identificador de un tercer segmento, etc., donde el número total de identificadores de segmento pueden ser uno o más. Entre los símbolos asociados con cada identificador de segmento, los símbolos pudieran ser ordenados incrementando consecutivamente el ESI. Una propiedad preferible es que el mapeo entre símbolos ordenados y paquetes de capa física dentro de un bloque de capa física es muy conocido (ya sea de manera explícita o implícita) y fácil de determinar por los remitentes y receptores .
Tal como se describió previamente, los símbolos pueden estar compuestos de múltiples sub-símbolos , en donde cada paquete de capa física puede llevar uno o más sub-símbolos pero puede no ser lo suficientemente grande para llevar un símbolo. En estos casos, la descripción previa de métodos y procesos para mapear símbolos a paquetes de capa física puede ser fácilmente enmendada para tomar en consideración esto. Por ejemplo, el ESI puede ser modificado para identificar no solamente símbolos, sino también sub-símbolos particulares dentro de un símbolo, por ejemplo, el ESI es tanto un símbolo como un identificador de sub-símbolo. Como otro ejemplo, el mapeo pudiera ser tal que los sub- símbolos de un símbolo siempre sean enviados en forma consecutiva, y el mapeo de símbolos ordenados a paquete de capa física identifica el paquete de capa física que lleva el primer sub- símbolo del símbolo.
En algunos casos, una gran cantidad de los datos de señalización pueden estar disponibles en los bloques de capa física, por ejemplo, la habilidad para derivar los ESI de símbolos o las posiciones de símbolos en el ordenamiento de símbolos a partir de las posiciones de los paquetes de capa física dentro de los bloques de capa física, un identificador de bloque de capa física, y otra información llevada dentro de la información de cabecera del bloque de capa física.
En algunas modalidades de la presente invención, un símbolo, ya sea un símbolo fuente o de reparación, es llevado , en cada paquete de capa física junto con una cantidad mínima de datos de identificación de cabecera. Un conjunto ordenado de símbolos para un bloque fuente es mapeado secuencialmente a paquetes de capa física dentro de un bloque de capa física utilizando un proceso que es bien conocido tanto para el remitente como para el receptor. Por ejemplo, un conjunto ordenado de .512 símbolos puede ser mapeado a 512 paquetes de capa física en secuencia. El ordenamiento de los símbolos se puede determinar en el remitente y puede ser comunicado al receptor ya sea explícitamente fuera de banda, o de preferencia implícitamente entre el remitente y el receptor a través de procesos predeterminados que determinan el ordenamiento de los símbolos para cada bloque. Cuando los símbolos de más de un bloque fuente van a ser mapeados a paquetes de capa física dentro del mismo bloque de capa física, si los bloques fuente son ordenados, entonces el ordenamiento de los símbolos con respecto a cada bloque fuente junto con el ordenamiento de los bloques fuente se puede utilizar para determinar un ordenamiento de todos los símbolos que van a ser mapeados al paquete de capa física dentro del bloque de capa física. En otras modalidades, múltiples símbolos son llevados en cada paquete de capa física. En otras modalidades todavía, un símbolo puede abarcar más de un paquete de capa física, por ejemplo, cuando los símbolos son divididos en sub-símbolos y cada sub-símbolo es llevado dentro de un paquete de capa física. Un experto en la técnica reconocerá que los procesos y métodos aquí descritos también pueden aplicar a estas otras modalidades.
En algunas modalidades, el bloque de capa física puede ser un bloque en una capa diferente, por ejemplo, un bloque o datos lógicos, o un bloque de datos definido por aplicación, o un bloque de transporte, o un bloque de capa de medios. Además los paquetes de capa física pueden ser paquetes de transporte, o paquetes lógicos, o paquetes de aplicación, o un paquete de capa de medios. Tal como un experto en la técnica lo reconocerá, hay muchas variantes esencialmente equivalentes de estas modalidades.
Segmentos Símbolos fuente y de reparación asociados con un bloque fuente pueden ser enviados dentro de más de un bloque de capa física. Un identificador de segmento de un símbolo fuente o de reparación se puede utilizar para indicar en cuál bloque de capa física es llevado el símbolo, con relación al primer bloque de capa física que lleva cualesquiera símbolos para ese bloque fuente, de preferencia en orden inverso. Por ejemplo, todos los símbolos asociados con un bloque fuente llevado en el último bloque de capa física que lleva cualesquiera símbolos para ese bloque fuente puede tener un identificador de segmento 0, mientras que el identificador de segmento para todos los símbolos asociados con un bloque fuente en cada bloque de capa física previo puede tener un identificador de segmento uno más grande que el identificador de segmento en el bloque de capa física posterior que lleva cualesquiera símbolos para ese bloque fuente. Observar que no todos los bloques de capa física consecutivos pueden llevar símbolos para ' un bloque fuente particular entre los bloques de capa física que llevan símbolos para ese bloque fuente, por ejemplo, un primer bloque de capa física puede llevar símbolos para un bloque fuente, un siguiente segundo bloque de capa física puede no llevar símbolos para ese bloque fuente, mientras que un siguiente tercer bloque de capa física puede llevar símbolos para ese bloque fuente. En otros casos, la estructura de segmento de un bloque fuente puede ser señalizada indicando, por ejemplo, la posición de un paquete de capa física dentro del ordenamiento del paquete de capa física o un bloque de capa física que es un indicador de límite de segmento que indica el final de un segmento para un bloque fuente y el inicio de un nuevo segmento para otro bloque fuente. Por ejemplo, para un bloque de capa física con 2000 paquetes de capa física, donde los primeros 500 paquetes de capa física corresponden a un segmento de un primer bloque fuente, los siguientes 600 paquetes de capa física corresponden a un segmento de un segundo bloque fuente, y los restantes 900 paquetes de capa física corresponden a un segmento de un tercer bloque fuente, los indicadores de límite de segmento 500, 600 pudieran ser utilizados para indicar que el segmento del primer bloque fuente corresponde a los primeros. 500 paquetes de capa física, el segmento del segundo bloque fuente corresponde a los siguientes 600 paquetes de capa física, y el segmento del tercer bloque fuente corresponde a los restantes 900 paquetes de capa física. De manera alternativa, los identificadores de límite de segmento pueden ser expresados en unidades de símbolos y pueden ser determinados con respecto al ordenamiento de los símbolos dentro de un bloque de capa física.
En algunas modalidades preferidas, dentro de cada bloque de capa física existe por mucho un bloque fuente asociado con cada identificador de segmento, y por lo tanto, un identificador de segmento puede ser utilizado para distinguir .de manera única los símbolos de diferentes bloques fuente, y por lo tanto, en estos casos, un identificador de segmento también es utilizado como un identificador de bloque fuente para diferenciar los símbolos llevados dentro de un bloque de capa física. En otras modalidades, los identificadores de bloque fuente para los símbolos son llevados por otros medios, por ejemplo, incluyendo un identificador de bloque fuente en los datos de cabecera asociados con cada símbolo, o incluyendo un identificador de bloque fuente en los datos de cabecera asociados con cada bloque de capa física.
Existen otras variaciones en donde un identificador de bloque fuente no necesariamente es llevado en las cabeceras de bloques de capa física, pero podrían ser llevados en otros lugares, por ejemplo, una corriente de- datos de control, en un bloque de capa física separado que contenga información de cabecera para múltiples bloques de capa física, o enviado a través de otra red. Un experto en la técnica reconocerá que hay muchas otras variaciones similares .
Sub-bloque.s Un bloque fuente codificado o no codificado puede comprender más de un sub-bloque, por ejemplo, los sub-bloques corresponden a diferentes símbolos fuente y de reparación asociados con un bloque fuente que corresponde a partes lógicamente asociadas de los símbolos. Por ejemplo, un primer conjunto de símbolos fuente y/o de reparación que comprende un primer sub-bloque puede corresponder a una porción del bloque fuente que puede ser utilizada para entregar un video de baja resolución de la porción del video asociada con el bloque fuente, mientras que un segundo conjunto de símbolos fuente y/o de reparación que comprende un segundo sub-bloque puede entregar un video de resolución más elevada de la porción de video asociada con el bloque fuente cuando se utilice en conjunto con parte o todo el primer sub-bloque. Como otro ejemplo, un identificador. de sub-bloque puede identificar algunos o todos los símbolos de reparación asociados con un bloque fuente, o un identificador de sub-bloque puede identificar algunos o todos los símbolos fuente asociados con un bloque fuente. En algunos casos, un identificador de sub-bloque puede ser señalizado etiquetando . de manera explícita cada sub-bloque con un número. Por ejemplo, el primer sub-bloque de un bloque fuente puede tener el identificador de sub-bloque 0, mientras que el segundo sub-bloque de un bloque fuente puede tener el identificador de sub-bloque 1. En otros casos, la estructura de sub-bloque puede ser señalizada indicando por ejemplo un ESI o posición de símbolo dentro del ordenamiento de símbolos que es un indicador del límite de sub-bloque que indica el final de un sub-bloque y el inicio de un nuevo sub-bloque dentro del ESI u ordenamiento de símbolos. Por ejemplo, para un bloque fuente con 900 símbolos fuente y 100 símbolos de reparación, donde los ESI de los símbolos son enteros consecutivos iniciando en cero y donde el primer sub-bloque comprende los símbolos fuente y el segundo sub-bloque comprende los símbolos de reparación, el indicador de límite de sub-bloque 900 pudiera ser utilizado para indicar que el primer sub-bloque corresponde a los símbolos con los ESI de 0.a 899 y el segundo sub-bloque comienza con el símbolo con el ESI 900. El identificador de sub-bloque de un símbolo fuente o de reparación indica de cuál sub-bloque es parte el símbolo.
Método de datos de cabecera enviados con cada símbolo En una modalidad, los datos de cabecera asociados con cada símbolo que va a ser enviado junto con el símbolo en un paquete de capa física que comprende un identificador de segmento, un identificador de sub-bloque y un ESI. Por ejemplo, si el número de posibles identificadores de segmento es 8 y el número de posibles identificadores de sub-bloque es 8 y el número de ESI es 1024, entonces 16 bits o equivalentemente 2 bytes de datos de cabecera son suficientes para cada símbolo. Dentro de cada paquete de capa física dentro de un bloque de capa física, el contenido del paquete de capa física comprende un símbolo junto con los datos de cabecera asociados con ese símbolo, donde los datos de cabecera comprenden un identificador de segmento. y un identificador de sub-bloque.
En esta modalidad, un receptor pudiera procesar paquetes de capa física recibidos dentro de un bloque de capa física de la siguiente forma. Al momento de la recepción de los paquetes de capa física dentro de un bloque de capa física, el receptor determina a partir de los datos de cabecera asociados con un símbolo dentro de cada paquete de capa física que éste puede leer. A partir de los datos de cabecera, el receptor puede determinar un identificador de segmento, un identificador de sub-bloque y un ESI para el símbolo contenido dentro del paquete de capa física. A partir del identificador de segmento, el receptor puede determinar con cuál bloque fuente está asociado el símbolo entre los posibles bloques fuente. A partir del identificador de sub-bloque, el receptor puede determinar con cuál sub-bloque está asociado el símbolo entre los posibles sub-bloques del bloque fuente. A partir del ESI, ' el ' receptor puede determinar la relación del símbolo al bloque fuente y al sub-bloque del¦ bloque fuente, donde el ESI puede ser utilizado para determinar la posición de símbolo de los símbolos dentro del bloque fuente, y/o que va a ser utilizado en la decodificación FEC para recuperar símbolos fuente faltantes de los. símbolos de reparación recibidos y de otros símbolos fuente.
El receptor entonces puede, con base en esta información, decidir ciertas acciones. Por ejemplo, el receptor puede utilizar los datos . de sub-bloque asociados con los símbolos para diferentes propósitos. Por ejemplo, los datos de sub-bloque pueden ser utilizados parcialmente para determinar la manera en la cual decodificar FEC para recuperar parte o todo un bloque fuente. Los datos de sub-bloque también pueden ser utilizados, por ejemplo, para determinar qué porciones de los datos debieran ser pasadas a una aplicación de capa superior, por ejemplo, un proceso de reproductor de multimedia dentro del receptor, a fin de soportar funcionalidad de nivel más elevado dentro del receptor, por ejemplo, para determinar cuáles porciones de un bloque fuente recuperado pasar como una totalidad a un reproductor multimedia para reproducción de multimedia. Por ejemplo, cuando un receptor recibe un primer bloque de capa física, una porción de los símbolos asociados con el primer identificador de segmento puede ser asociada con un primer sub-bloque el cual puede ser pasado a un reproductor multimedia para reproducción de una porción de video de baja calidad asociada con el bloque fuente asociado con el primer identificador de segmento. El receptor también puede decidir guardar los símbolos extraídos y/o recuperados asociados con los bloques fuente con identificadores de segmento, diferentes al primer identificador de segmento, para combinarlos con símbolos para los mismos bloques fuente recibidos en bloques de capa física posteriores y combinar estos símbolos para decodificación FEC y/o para pasarlos a un reproductor de medios, probablemente en unidades de sub-bloques de símbolos o conjuntos de sub-bloques de símbolos.
Tal como lo reconocerá un experto en la técnica, hay variantes y combinaciones de las modalidades anteriores. Por ejemplo, los datos de cabecera para un símbolo que son enviados con el símbolo pueden incluir identificadores de segmento e identificador de sub-bloques, pero no un ESI. Como otro ejemplo de una variante, solamente el ESI es enviado en los datos de cabecera con el símbolo, y otros datos, tales como un identificador de segmento o identificador de sub-bloque, en caso de ser utilizado, es determinado a partir de otros datos.
Como otro ejemplo de una variación, los datos de cabecera asociados con cada símbolo pueden no incluir un identificador de sub-bloque. En este caso, un identificador de sub-bloque puede ser determinado, por ejemplo, de manera explícita por los ESI derivados, o los sub-bloques coinciden con los segmentos de un bloque fuente, o el sub-bloque no es utilizado.
Como otro ejemplo de una . variación, los datos de cabecera asociados con cada símbolo pueden no incluir un identificador de segmento. En este caso, el identificador de segmento puede ser determinado, por ejemplo, de manera implícita mediante la asignación de una cantidad fija de paquetes de capa física dentro de cada bloque de capa física, o los sub-bloques coinciden con segmentos, o la segmentación no es utilizada.
Como otro ejemplo de una variación, los datos de cabecera asociados con cada símbolo también pueden incluir un identificador de corriente. En este caso, el identificador de corriente puede determinar con cuál corriente, entre un número pequeño de corrientes, está asociado un símbolo, por ejemplo, una corriente de audio o una corriente de video. Observar que un identificador de corriente puede estar al alcance de otros identificadores , por ejemplo, si las corrientes están lógicamente conectadas, tal como corrientes de audio y video para el mismo segmento de programa, entonces por ejemplo, un identificador de sub-bloque puede estar al alcance de algunos o todos los identificadores de corriente. Observar que el identificador de corriente también puede estar al alcance de otros identificadores , por ejemplo, si las corrientes son lógicamente independientes, tal como corrientes de audio/video para diferentes segmentos de programa, entonces por ejemplo, un identificador de corriente puede estar al alcance de algunos o todos los identificadores de sub-bloque.
Método Sin datos de cabecera enviados con cada símbolo.
En otra modalidad, no hay datos de cabecera asociados con un símbolo que sean llevados en un paquete de capa física. Por el contrario, algunos datos mínimos pueden ser llevados dentro de los datos de cabecera del bloque de capa física. Los datos mínimos pueden incluir, por ejemplo, una tabla de segmento, donde cada fila de la tabla de segmentos corresponde a un identificador de segmento que comprende el número de símbolos del segmento para un bloque fuente que son llevados en ese bloque de capa física y el ESI del primer símbolo en el ordenamiento de símbolos para ese segmento de un bloque fuente entre todos los símbolos del segmento para el bloque fuente que son llevados en ese bloque de capa física. El número de símbolos en el segmento puede no estar incluido en algunas modalidades, por ejemplo, debido a que el número de símbolos en cada segmento siempre es el mismo a través de todos los bloques de capa física.
En algunas modalidades, la tabla de segmentos puede ser, por el contrario, una tabla de bloques fuente, en casos donde el mismo identificador de segmento va a ser utilizado para dos o más bloques fuente dentro del mismo bloque de capa física.
Los datos mínimos también pueden incluir, por ejemplo, una tabla de sub-bloques, la cual indica cuáles sub-bloques de los símbolos para cada bloque fuente son llevados dentro del bloque de capa física. Existen muchas formas para esta tabla de sub-bloque, por ejemplo, la información de sub-bloque puede ser anexada a cada fila de la fila de identificador de segmento apropiada en la tabla de segmentos, o como otro ejemplo, la información de sub-bloque puede ser almacenada en una tabla separada. En algunas modalidades, la tabla de sub-bloques puede no estar incluida, por ejemplo, debido a que ya sea que el sub-bioqueo no sea utilizado o debido a que la señalización del sub-bloqueo sea manejada en una capa de aplicación más elevada.
En esta modalidad, un receptor podría procesar paquetes de capa física recibidos dentro de un bloque de capa física de la siguiente forma. El receptor lee y almacena la tabla de segmentos y/o tabla de sub-bloques a partir de los datos de cabecera del bloque de capa física. A partir de la tabla de segmentos, el receptor puede determinar el número de símbolos y el ESI, inicial asociado con cada segmento de uri bloque fuente para el cual hay símbolos llevados con el bloque de capa física. A partir de la identificación de capa física de la posición de un paquete de capa física que lleva un símbolo, a partir de la tabla de segmentos que contiene el número y ESI inicial asociado con cada segmento, y a partir del mapeo del-conjunto ordenado combinado de símbolos de todos los segmentos de los bloques fuente contenidos en el bloque de capa física a los paquetes de capa física, el receptor puede determinar el ESI del símbolo y con cuál bloque fuente está asociado el símbolo. A partir de la tabla de sub-bloque, en una manera similar, el receptor puede determinar con cuál sub-bloque del bloque fuente está asociado el símbolo.
A partir del ESI, el receptor puede determinar la relación del símbolo al bloque fuente y al sub-bloque del bloque fuente, donde el ESI puede ser utilizado para determinar la posición de símbolo de los símbolos dentro del bloque fuente, y/o que va a ser utilizado en la decodificación FEC para recuperar símbolos fuente que no son recibidos desde los símbolos de reparación recibidos y otros símbolos fuente.
El receptor entonces puede, con base en esta información, decidir ciertas acciones, incluyendo aquellas descritas anteriormente para el método de "Datos de cabecera enviados con cada símbolo" aquí descrito.
Tal como lo reconocerá un experto en la técnica, existen muchas variaciones de lo anterior. Como un ejemplo de una variación, los datos de cabecera asociados con cada símbolo pueden comprender el identificador de sub-bloque, por ejemplo utilizando una porción de un byte de cada paquete de capa física para este propósito. Esto puede ser preferible en algunos casos, ya que la estructura de sub-bloque abarca todo un- bloque fuente, mientras que el envío de los datos para el bloque fuente puede ser sobre varios bloques de capa física, y por lo tanto llevar un identificador de sub-bloque dentro de los datos de cabecera enviados con cada símbolo puede permitir a un receptor que une el canal en la parte media de la transmisión de un bloque fuente entender rápidamente la estructura de sub-bloque del bloque fuente.
Como otro ejemplo, el sub-bloque pudiera no ser utilizado.
Como otro ejemplo, los datos de cabecera asociados con cada paquete de capa física pueden ser enviados, por ejemplo, como datos separados dentro del mismo bloque de capa física o pueden ser comunicados a través de otros medios al receptor, por ejemplo, . enviados dentro de un canal de control que está disponible al receptor, o como otro ejemplo, enviados en un bloque de capa física separado que contiene información de cabecera para múltiples bloques de capa física, o como otro ejemplo, enviados a través de otra red.
Como otro ejemplo, los datos de cabecera asociados con cada símbolo también pueden incluir un identificador de corriente. En este caso, el identificador de corriente puede determinar con cuál corriente, entre un número pequeño de corrientes, está asociado un símbolo, por ejemplo, una corriente de audio o una corriente de video. Observar que el identificador de corriente puede estar al alcance de otros identificadores , por ejemplo, si las corrientes están lógicamente conectadas, tal . como corrientes de audio y video para el mismo segmento de programa, entonces por ejemplo, un identificador de sub-bloque puede estar al alcance de algunos o todos los identificadores de corriente. Observar que el identificador de corriente también puede estar al alcance de otros identificadores , por ejemplo, si las corrientes son lógicamente independientes, tal como corrientes de audio/video para diferentes segmentos de programa, entonces por ejemplo, un identificador de corriente puede estar al alcance de algunos o todos los identificadores de sub-bloque. Un identificador de corriénte también puede estar incluido dentro de los datos de cabecera para un bloque de capa física en un formato similar a aquél descrito anteriormente para identificadores de segmento e identificador de sub-bloque, y en cuyo caso pudiera no ser necesario incluir un identificador de corriente en los datos de cabecera asociados con cada símbolo a fin de comunicar la estructura de corriente a un receptor.
Como un ejemplo, asumir qye el número de segmentos por bloque fuente es 4, el número de sub-bloques es 3, el número de paquetes de capa física por bloque de capa física es 512, y tres símbolos con un tamaño de 100 bytes cada uno, están incluidos en cada paquete de capa física de 300 bytes, y por lo tanto cada bloque de capa física contiene 3*512 = 1536 símbolos. Entonces, una primera tabla de segmentos para un primer bloque de capa física particular y una segunda tabla de segmentos para un segundo bloque de capa física pudieran ser como se muestra en la figura 3, donde el segundo bloque de capa física es enviado consecutivamente después del primer bloque de capa física. En este ejemplo, el identificador de segmento pudiera no ser explícitamente llevado en la tabla de segmentos, sino que más bien pudiera estar implicado por el número de fila en la tabla, es decir, la fila j corresponde al identificador de segmento j .
En la primera tabla de segmentos, el número de símbolos para el segmento con el identificador 0 es 450, el cual sería llevado por los 150 paquetes de capa física, los primeros- 450 símbolos son mapeados de acuerdo con los símbolos ordenados al mapeo de paquete de capa física. Los ESI para los símbolos con el identificador de segmento 0 son los enteros consecutivos que varían de 0 hasta 449 en este ejemplo. El número de símbolos para el segmento con el identificador 1 es 300, el cual sería llevado por los 100 paquetes de capa física después de los primeros 150 paquetes de capa física, los 300 símbolos son mapeados de acuerdo con los símbolos ordenados al mapeo de paquete de capa física. Los ESI para los símbolos con el identificador de segmento 1 son los enteros consecutivos que varían de 420 hasta 719 en este ejemplo.
En la segunda tabla de segmentos, el número de símbolos para el segmento con el identificador 0 es 420, el cual sería llevado por los 140 paquetes de capa física, los primeros 420 símbolos son mapeados de acuerdo con los símbolos ordenados al mapeo de paquete de capa física. Se puede observar que el bloque fuente con el identificador de segmento j en la primera tabla de segmentos puede ser el mismo que el bloque fuente con el identificador de segmento j+1 en la segunda tabla de segmentos, para j=0, 1, 2. Por lo tanto, el ESI inicial para el segmento con el identificador j en la primera tabla de segmentos es bajo este mapeo la suma del ESI inicial y el número de símbolos del segmento con el identificador j+1 en la segunda tabla de segmentos .
Existen otras variaciones en donde los datos no necesariamente son llevados, en las cabeceras de bloques de capa física, pero podrían ser llevados en otros lugares, por ejemplo, una corriente de datos de control, en un bloque de capa física separado que' contiene información de cabecera para, múltiples bloques de capa física, o enviados a través de otra red. Un experto en la técnica reconocerá que son posibles muchas otras variaciones similares del método antes descrito.
Mapeos hacia y desde ID de carga útil FEC Para muchos códigos FEC de capa de aplicación descritos en normas, por ejemplo tal como se describe en IETF RFC 5052 (Solicitud de la Fuerza de Tarea de Ingeniería de Internet para Comentarios 5052) e IETF RFC 5053 (Solicitud de la Fuerza de Tarea de Ingeniería de Internet para Comentarios 5053), típicamente asociados con símbolo o grupo de símbolos o grupo de sub- símbolos enviados en un paquete de capa de aplicación es un ID ( Identificador) de Carga Útil FEC. Para el caso más simple, cuando el ID de Carga Útil FEC está asociado con un símbolo, el ID de Carga Útil FEC comprende el número de bloque fuente a partir del cual fue generado el símbolo, el ESI del símbolo, y en algunos casos el ESI inicial del símbolo de reparación con el ESI asociado más pequeño (y este ESI inicial puede ser visto como un identificador de sub-bloque, identificando los símbolos fuente como parte de un primer sub-bloque y los símbolos de reparación como parte de un segundo sub-bloque) .
En algunos de los métodos y procesos antes descritos, el ID de Carga Útil FEC no es enviado con cada símbolo, y por el contrario se describen otros medios que reducen al mínimo la cantidad de datos de cabecera que son enviados con cada símbolo a fin de elevar al máximo la capacidad del canal. Es útil en algunos casos en un remitente trasladar el formato de envío de uno que utiliza un ID de Carga Útil FEC a uno que utiliza los medios antes descritos para transmitir esta información a un receptor. También resulta útil, en algunos casos, en un receptor trasladar el formato de envío de uno que utiliza los medios antes descritos para comunicar esta información a un receptor a uno que utiliza un ID ' de Carga Útil FEC. Por ejemplo, pudiera haber ya software desarrollado que utilice el ID de Carga Útil FEC para identificar símbolos, y puede ser conveniente tomar una corriente de salida de símbolos y datos de cabecera asociados generados utilizando este software para producir una corriente de salida de símbolos y datos asociados compatibles con el formato de envío utilizando los medios antes descritos.
Los métodos de mapeo hacia y desde el formato de ID de Carga Útil FEC pueden ser fácilmente derivados de la descripción antes proporcionada.
Arreglos de envío para optimizar la manipulación de canal Para una corriente priorizada que va a ser enviada sobre un canal, donde los datos que van a, ser enviados son divididos en diferentes bloques de capa física, por ejemplo, cuadros o súper cuadros, los datos de símbolos que van a ser enviados para un. bloque fuente pueden ser intercalados sobre múltiples de dichos bloques de capa física en una manera priorizada, en el orden inverso de su prioridad. Por ejemplo, tal como se describió en "corriente FEC" , los datos de reparación para un bloque fuente pueden ser enviados previo a los datos -fuente para un bloque fuente a fin de reducir, en el contexto de estas descripciones, el tiempo de manipulación de canal. Los datos que comprenden datos a un nivel de prioridad determinado para un bloque fuente pueden ser agrupados en un sub-bloque. Por ejemplo, continuando con el ejemplo antes descrito, los símbolos de reparación pueden ser considerados como un sub-bloque de prioridad más baja, y los símbolos fuente como un segundo sub-bloque de prioridad más elevada, y por lo tanto, el sub-bloque de prioridad más baja puede ser enviado previo al sub-bloque de prioridad más elevada.
La figura 4 ilustra un ejemplo de la manera en que una modalidad puede priorizar datos en sub-bloques y mapear los sub-bloques en un orden de envío priorizado. En la figura 4, la corriente de datos 470 es representada con varios bloques y sub-bloques de datos. Por ejemplo, la corriente de datos 470 se muestra' con un bloque de audio 450 y varios bloques de video tal como un I-Cuadro (ZI) 410 y varios sub-bloques de datos de símbolos tales como ??-?? 420- 422, b!-b2, 430-435, y Bi - ?? 440-442. En la figura 4, Pi 420 representa el sub-bloque con prioridad más elevada en la corriente, seguido por bi-bz 430-435, Bi-B2 440-442, P2-Px 421- 422, el bloque de audio 450, y el I-Cuadro (ZI) 410, respectivamente. Dados estos niveles de prioridad, los bloques y sub-bloques de la corriente pueden ser acomodados · como se ilustra mediante el arreglo de envío 480. El bloque de prioridad más baja (ZI 410) puede ser transmitido a un receptor al inicio de una transmisión, mientras que los datos de prioridad más elevada (Pi ,420) pueden ser enviados al último. De manera adicional, también se pueden tomar en cuenta las dependencias entre los diversos sub-bloques cuando se crea el orden de envío priorizado. Por ejemplo, de acuerdo con algunas modalidades, los sub-bloques bi, Bi, y b2 pueden depender de ??. En estas modalidades, puede ser conveniente transmitir estos sub-bloques dependientes antes que i sea transmitido. Por lo tanto, tan pronto como Pi es recibido, todos los datos en Px y todos sus sub-bloques dependientes pueden ser puestos a disposición rápidamente en un receptor. Una vez que se ha determinado un arreglo de envío, el arreglo de envío puede ser utilizado para dividir los datos en diferentes bloques de capa física por consiguiente .
Un método para mapear sub-bloques priorizados en bloques de capa física para mapear sub-bloques en cada bloque de capa física. La figura 5 muestra un ejemplo de una modalidad de este método. La figura 5 muestra un conjunto de datos 500 separados en varios bloques de capa física 501-504. Los bloques en la figura 5 son representados como siendo transmitidos en la dirección indicada por la flecha 509. Por ejemplo, el bloque de capa física 501 es transmitido por anticipado del bloque de capa física 504 (y, por lo tanto, es transmitido antes que el bloque físico 504) , y dentro del bloque de capa física 501, la sección 580 es transmitida por anticipado de la sección 520. Tal como se ilustra en la figura 5, algunos de los datos 500 son colocados en cada bloque de capa física 501-504. Para propósitos de claridad, cada segmento de datos en los datos 500 es mostrado solamente colocado en uno de los bloques de capa física 501-504 aún cuando cada segmento es colocado en una sección correspondiente de cada bloque de capa física. Los datos FEC 510 son colocados en los bloques de capa física en 520-523; los datos Pi 420 son colocados en los bloques de capa física en 540-543; los datos bi-bz 430-435 son colocados en los bloques de capa física en 530-533; los datos ??-?? 440-442 son colocados en los bloques de capa física en 550-553; los datos ?2~?? 421-422 son colocados en los bloques de capa física en 560-563; los datos de audio 450 son colocados en los bloques posteriores físicos en 570-573; y el I-Cuadro (ZI) 410 es colocado en los bloques de capa física 580-583. Una ventaja de mapear sub-bloques en bloques de capa física en la forma ilustrada en la figura 5 es que el comportamiento de reproducción en un receptor será más predecible debido a que segmentos de cada grupo de prioridad estarán contenidos en cada bloque de capa física. No obstante, varios segmentos dentro de cada bloque de capa física típicamente tendrán diferentes tamaños, debido a que los diversos niveles de prioridad por lo regular contendrán diferentes cantidades de datos. Esto puede conducir a problemas de rendimiento potenciales en el receptor debido a un procesamiento más complicado en el receptor para desempacar los datos, y puede haber problemas con multiplexación estadística debido a los diferentes tamaños de segmento.
Otro método es esparcir los datos de símbolos de la manera más igual posible sobre los diferentes bloques de capa física, ya que esto generalmente proporciona la mejor protección contra disparidades de canal. La figura 6 muestra un ejemplo de una modalidad de este método. La figura 6 muestra un conjunto de datos 600 separados en varios bloques de capa física 601-604. Los bloques en la figura 6 son representados como siendo transmitidos en la dirección indicada por la flecha 609. Por ejemplo, el bloque de capa física 601 es transmitido antes que el bloque de capa física 604 (y por lo tanto, es transmitido antes que el bloque físico 604) , y dentro del bloque de capa física 601, la sección 640 es transmitida antes que la sección 610. Tal como se ilustra en la figura 6, las diversas prioridades de datos en los datos d símbolos 600 han sido agrupadas en bloques 605-608. Estos bloques 650-608, a su vez, han sido mapeados en bloques de capa física 601-604 en cantidades iguales. Para propósitos de claridad, cada segmento de datos 600 solamente se muestra colocado en uno de los bloques de capa física 601-604 aún cuando cada segmento es colocado en una sección correspondiente de cada bloque de capa física. Por ejemplo, el bloque 605 es mapeado en 610-613; el bloque 606 es mapeado en 620-623; el bloque 607 es mapeado en 630-633; el bloque 608 es mapeado en 640-643. Como resultado del mapeo ilustrado en la figura 6, algunos sub-bloques son divididos entre agrupamientos . Por ejemplo, los datos del segmento de datos ??-?? 440-442 pueden ser incluidos en ambos bloques 606 y 607. De manera adicional, un bloque físico determinado puede no contener datos de prioridad particular. Por ejemplo, el bloque 601 puede no contener dato alguno del ,FEC 510 en 610 mientras que el bloque 604 puede no contener dato alguno de Pi 420 en 613. Una ventaja del método ilustrado en la figura 6 es que debido a que los segmentos de los bloques de capa física son del mismo tamaño, el receptor requerirá menos procesamiento para desempacar los- segmentos. Esto puede dar como resultado un rendimiento de receptor mejorado. De manera adicional, el tamaño de segmento uniforme hace más fácil multiplexación estadística. Sin embargo, debido a que pudiera no haber garantías respecto a los niveles de prioridad exactos que estarán contenidos en algún bloque de capa física, el comportamiento de reproducción en el receptor puede ser menos predecible.
Una preocupación mientras se mapean datos es que una cantidad suficiente de los datos de alta prioridad para el bloque fuente es enviada en el primer bloque de capa física a fin de permitir que el receptor comience a reproducir tan pronto como estos datos de alta prioridad son recibidos. Un método para lograr esto es priorizar los datos en los bloques fuente codificados o no codificados en una manera en que la cantidad de datos de alta prioridad sea por mucho una fracción de 1/N de la cantidad total de datos que van a ser enviados para el bloque fuente, en donde N es el número de bloques de capa física sobre los cuales los datos van a ser enviados para el bloque fuente, en el caso donde datos de alta prioridad para algún bloque fuente debieran estar disponibles después que un receptor recibe un primer bloque de capa física. En general, si el requerimiento es que las primeras J prioridades de datos necesitan estar disponibles para cierto primer bloque fuente después que el receptor recibe K bloques de capa física, entonces esto se puede lograr en caso que la fracción de datos en las primeras J prioridades sea por mucho K/N.
Un ejemplo de una estrategia de división preferida es la siguiente, la cual puéde ser utilizada ya sea que se utilice o no el método anterior. Asumir que los datos enviados para un bloque fuente van a ser enviados dentro de N bloques de capa física, donde los datos enviados comprenden los símbolos fuente para el bloque fuente y los símbolos de reparación FEC, en caso de haberlos, generados a partir del bloque fuente que van a ser enviados. Suponer que los datos enviados para un bloque fuente se dividen en K prioridades, donde la fracción de los datos enviados con la prioridad j es P_j para j=l, K.
Tal como se describió anteriormente, los datos enviados con una prioridad j pueden ser agrupados en un sub-bloque, denominado sub-bloque j. Después, la fracción de los datos enviados, enviada en el último bloque de capa física, puede ser el máximo de P_l y 1/N, es decir, todos los datos en el sub-bloque de prioridad más elevada 1 y posiblemente algunos de los datos restantes sean enviados en el último bloque de capa física N. Asumir que M_l sea este máximo, y asumir L_l = 1-M_1 sea la fracción restante de datos que va a ser enviada en los bloques de capa física N-l,...,l después que una fracción _l de los datos es enviada en el último bloque de capa física N. Después, la fracción de los datos enviados, enviada en el bloque de capa física N-l puede ser el máximo de P_l+P_2-M_l y 1/N-l, es decir, todo el sub-bloque de prioridad más elevada y el segundo sub-bloque de prioridad más elevada es enviado en los últimos dos bloques de capa física, y posiblemente algunos de los datos restantes también. Esto es asumiendo que los datos de las dos primeras prioridades van a ser reproducidos en el receptor después que se han recibido dos bloques de capa física.
Este método se puede extender para determinar cuáles datos enviados enviar en cada bloque de capa física. Este método también se puede extender al caso en que los requerimientos del receptor para que el receptor reproduzca los datos del bloque fuente enviados sean diferentes, por ejemplo, los datos enviados de prioridad 2 van a ser reproducidos después de recibir tres bloques de capa física en lugar de realizarse después de dos bloques de capa física. Los métodos anteriores también podrían ser modificados por el requerimiento para multiplexar muchas corrientes diferentes o agrupamientos de corrientes sobre el mismo canal físico, donde la cantidad de espacio disponible en cada bloque de capa física se utiliza para determinar cuánta de cada prioridad de datos enviados para cada corriente o corrientes agrupadas van a ser enviada en cada bloque .
Observar que las prioridades antes descritas no necesitan describir un ordenamiento completo, es decir, las prioridades pueden ser un orden parcial, en cuyo caso hay elecciones respecto al orden para colocar los datos priorizados, y de hecho datos. priorizados que son incomparables en términos de prioridad pueden ser mezclados en el orden de envío, en algunas modalidades.
Tal como se describió anteriormente, la implementación de algunos de estos arreglos de envío propuestos se puede lograr utilizando cualquiera de los métodos y procesos de envío y recepción aquí descritos, por ejemplo, ESI, incluyendo datos de cabecera enviados con cada símbolo, datos de no cabecera enviados con cada símbolo, etc.
Codificación FEC parcial de un bloque fuente Los datos de reparación FEC pueden ser generados a partir de un bloque fuente completo, y proporcionan la capacidad para recuperar todo o porciones significativas de un bloque fuente en caso que se reciban suficientes símbolos fuente del bloque fuente más símbolos de reparación generados del bloque fuente. Los datos de reparación FEC pueden ser generados a partir de únicamente partes del bloque fuente, por ejemplo, un conjunto de datos de reparación FEC puede ser generado a partir de una primera porción del bloque fuente, un segundo conjunto de datos de reparación FEC puede ser generado a partir de una segunda porción del bloque fuente. Como un ejemplo, la segunda porción del bloque fuente puede incluir la primera porción del bloque fuente más algunas partes adicionales del bloque fuente. Suponer que los símbolos fuente para un bloque fuente son divididos en un sub-bloque fuente de baja prioridad y un sub-bloque de alta prioridad. Después, un primer sub-bloque de símbolos de reparación FEC puede ser generado a partir del sub-bloque fuente de alta prioridad y un segundo sub-bloque de símbolos de reparación FEC puede ser generado a partir de la concatenación del sub-bloque fuente de baja prioridad y el sub-bloque fuente de alta prioridad. El orden de envío de los sub-bloques entonces podría ser: segundo sub-bloque de símbolos de reparación FEC, sub-bloque fuente de baja prioridad, primer sub-bloque de símbolos de reparación FEC, sub-bloque fuente de alta prioridad. En este caso, si un receptor recibe únicamente todo o parte del sub-bloque fuente de alta prioridad, entonces puede intentar reproducir esto inmediatamente, en caso que no haya demasiada corrupción. Si un receptor recibe todo o parte del primer sub-bloque de los símbolos de reparación FEC y el sub-bloque fuente de alta prioridad entonces el receptor puede intentar recuperar el sub-bloque fuente de alta prioridad utilizando el primer sub-bloque de símbolos de reparación FEC en caso que no haya mucha corrupción. Si un receptor recibe todo o parte del sub-bloque fuente de baja prioridad, el primer sub-bloque de símbolos de reparación FEC y el sub-bloque fuente de alta prioridad entonces el receptor puede intentar recuperar partes corrompidas del sub-bloque fuente de alta prioridad utilizando el primer sub-bloque de símbolos de reparación FEC y después enviar un reproductor de medios para las porciones recibidas del sub-bloque fuente de baja prioridad y las porciones recuperadas del sub-bloque fuente . de alta prioridad. Si un receptor recibe todos o porciones de los cuatro sub-bloques, entonces el receptor puede utilizar todos los símbolos de reparación FEC para recuperar todos los símbolos fuente.
Observar que los métodos anteriores pueden ser preferibles para proporciona protección FEC sobre cada sub-bloque de forma separada, por ejemplo, haciendo que el segundo sub-bloque de símbolos de. reparación FEC proteja todo el bloque fuente en lugar de sólo el sub-bloque fuente de baja prioridad lo cual puede ser preferible. Por ejemplo, suponer que cada uno de los dos sub-bloques fuente comprende 100 símbolos fuente cada uno, y cada uno de los dos sub-bloques de reparación FEC comprende 50 símbolos de reparación cada uno. El uso de los métodos antes descritos puede permitir la recuperación de todo el bloque fuente incluso cuando 60 de los símbolos fuente del sub-blo.que fuente de alta prioridad se pierden y 30 de los símbolos fuente del sub-bloque fuente de baja prioridad se pierden, mientras que si los dos sub-bloques fuente son protegidos independientemente por los dos sub-bloques de reparación FEC, entonces la recuperación del sub-bloque de alta prioridad no es posible (perdidos 60 símbolos fuente del sub-bloque, hay solamente 50 símbolos de reparación que protegen el sub-bloque) . Dicha protección FEC puede ser, por ejemplo, obtenida utilizando códigos Reed-Solomon, donde los experimentos muestra que los códigos Reed-Solomon muestran propiedades de recuperación casi ideales cuando se utilizan en las formas antes descritas para' proteger sub-bloques en traslape.
Estos métodos también son útiles para protección en caso de protección a través de un periodo de tiempo muy largo que ocasiona que periodos de tiempo completos de datos recibidos sean barridos ocasionalmente. Por el contrario, proporcionar protección FEC sobre bloques cortos, y después también proporcionar protección FEC sobre bloques más largos que incluyen los bloques cortos, puede ser preferible. De esta forma, si existe un paro sin demasiada pérdida en periodos de tiempo circundantes, entonces la protección FEC a través de los bloques cortos puede permitir que éstos sean recuperados, mientras que una protección FEC adicional a través de bloques más largos permite más pérdida sobre periodos de tiempo más prolongados .
' -· . ' ' Recepción de múltiples corrientes de bloque de capa física Para aplicaciones en corriente donde las corrientes lógicamente conectadas son enviadas sobre una sola corriente de bloques de capa física, todo el canal físico pudiera estar compuesto de múltiples corrientes de bloque de capa física. Por ejemplo, cada corriente de bloque de capá física pudiera ser 256 Kbps, o 1 Mbps , mientras que pudiera haber 50 de dichas corrientes de manera que todo el canal físico disponible pudiera ser 12.5 a 50 Mbps en este ejemplo.
Típicamente, un receptor puede recibir una de las corrientes de bloques de capa física en un tiempo, debido a una variedad de diferentes motivos incluyendo problemas de potencia y problemas de memoria. No obstante, puede haber ventajas para que el receptor reciba más de una corriente de bloques de capa física. Por ejemplo, si el receptor está recibiendo todas esas corrientes, entonces la manipulación de canal de una corriente a otra puede ocurrir casi instantáneamente, y la nueva corriente que el receptor mueve puede ser reproducida desde el inicio al nivel de calidad más elevado, debido a que todos los datos para la nueva corriente han estado llegando por un periodo de tiempo antes que el receptor cambie los canales a esa corriente. Esto es verdadero incluso si las corrientes son protegidas utilizando protección FEC con un periodo de protección largo, o si las corrientes son video codificado en una manera en que está altamente comprimido, por ejemplo, cuando cuadros de renovación en una corriente de video, en ocasiones denominados I-Cuadros, algunas veces denominados cuadros IDR (cuadros de Renovación de Datos Independientes) , son enviados con poca frecuencia debido a su tamaño grande. Esto típicamente significa que el tiempo abarcado por un GOP (Grupo de Imágenes) puede ser más bien grande en una corriente de video altamente comprimido. Por ejemplo, la duración GOP para una corriente de video pudiera ser 10 segundos, y la protección FEC pudiera ser proporcionada para proteger el GOP .completo de 10 segundos. En este caso, sin utilizar algunos de los métodos antes descritos donde los datos de alta prioridad de la corriente son desplegados lo más rápidamente posible y después los datos de prioridad más bajos y , más bajos también son desplegados para mejorar la calidad de reproducción a medida que avanza la reproducción de la corriente, si un receptor estuviera recibiendo únicamente un canal a la vez, el tiempo de manipulación de canal podría ser tan alto como 10 segundos, mientras que si el receptor está recibiendo todos los canales entonces el tiempo de manipulación de canal podría ser casi instantáneo.
Existen algunas optimizaciones posibles cuando se considera una solución donde un receptor está recibiendo de manera concurrente más de una corriente de paquetes de capa física. Por ejemplo, el receptor solamente necesita decodificación FEC, por ejemplo, ejecutar ya sea decodificación de corrección de error o decodificación de protección de borrado, únicamente en las corrientes que están siendo actualmente enviadas, por' ejemplo, al reproductor de medios para reproducción. Los datos para otras corrientes pueden ser almacenados, y únicamente FEC decodificado si el receptor cambia canales, y después la decodificación FEC puede ocurrir muy rápidamente en los datos que ya han sido recibidos para el nuevo canal a fin de iniciar la reproducción de medios casi inmediatamente.
Como otra optimización posible, cuando un receptor está recibiendo únicamente una corriente a la vez, puede haber datos redundantes que estén incluidos en la corriente los cuales no son necesarios en caso que el receptor tuviera partes previas de las corrientes disponibles para reproducción cuando el receptor primero une la corriente. Ejemplos de dichos datos redundantes pudieran ser cuadros IDR de video de baja calidad que son incluidos con mucha frecuencia en una corriente de video únicamente de forma que un receptor puede unir una corriente e iniciar la reproducción de cierto video casi inmediatamente, incluso si está en una calidad degradada. Si el receptor tenía porciones previas de la corriente, incluyendo un cuadro IDR de alta calidad, y todos los cuadros posteriores enviados previamente-, entonces no habría necesidad de incluir los cuadros IDR de baja calidad. Los cuadros IDR de baja calidad pueden utilizar una cantidad significativa del ancho de banda disponible, por ejemplo, si cada cuadro IDR de baja calidad es 3 KB y son enviados cada segundo en una corriente de 256 Kbps, entonces los cuadros IDR de baja calidad utilizan más del 9% del ancho de banda disponible. El envío de los cuadros IDR de bajá calidad no es necesario en caso que el receptor esté recibiendo datos para la corriente que el receptor cambia antes del cambio de canal para esa corriente.
Un inconveniente de escuchar múltiples corrientes de los bloques de capa física es que utiliza más potencia en el receptor que escuchar una sola corriente. De manera adicional, se necesita más memoria y otros recursos para almacenar los datos recibidos desde múltiples corrientes que de una sola corriente . Hay algunos métodos que pueden ser utilizados para reducir al mínimo estos inconvenientes. Uno de estos métodos es organizar la lógica y/o los datos globalmente sobre las corrientes disponibles en una manera en que un receptor necesita recibir solamente unas pocas corrientes a la vez para lograr los beneficios anteriores.
Por ejemplo, si hay lógica que puede predecir a ¦ cuáles corrientes probablemente un receptor podría cambiar canales, la lógica puede ser de tal manera que el receptor esté recibiendo estos probables canales por anticipado de un cambio real a ese canal.
Como otro ejemplo, los datos en las corrientes del bloque de capa física pudieran ser organizados de manera que haya una sola corriente de bloque de capa física que lleve todos los cuadros IDR para todas las otras corrientes de video, denominada la corriente IDR, y después cada otra corriente de bloque de capa física lleva todos los datos para una de las corrientes de video excepto para los cuadros IDR para esa corriente de video. En este ejemplo, un receptor podría recibir la corriente de bloque de capa física actual para la corriente de video que actualmente está siendo reproducida por el reproductor de medios mientras que, al mismo tiempo (ya sea siempre o de manera intermitente cuando es apropiado) recibe la corriente IDR. Por lo tanto, el receptor puede tener disponibles los cuadros IDR para todas o algunas de las corrientes de video, las cuales puede utilizar ya sea para reproducción cuando despliega información referente a todas o algunas de las corrientes de video, disponibles en un modo de guía de canal de croquis, o utilizar para iniciar el despliegue de una nueva corriente de video cuando se realiza un cambio de canal en el receptor. La corriente IDR puede ser recibida en todo momento, o puede ser recibida de forma intermitente, por ejemplo, únicamente recibir bloques de capa física de la corriente IDR que contiene cuadros IDR para la corriente de video actualmente en reproducción. En todos los casos, se puede proporcionar la protección FEC en cada corriente de bloque de capa física si así se desea. Una ventaja de estos métodos es que el receptor recibe máximo dos corrientes de bloque de capa física en cualquier punto en tiempo y todavía obtiene todas o la mayoría de las ventajas de recibir todos los canales de bloque de capa física de manera concurrente.
Aunque la invención se ha descrito con respecto a modalidades ejemplares, un experto en la técnica reconocerá que son posibles numerosas modificaciones. Por ejemplo, los procesos aquí descritos pueden ser implementados utilizando componentes de hardware, componentes de software, y/o cualquier combinación de los mismos. Por ejemplo, los métodos aquí descritos podrían ser incorporados en un medio legible por computadora, tal como un CD-ROM, DVD, etc., que comprenda un código ejecutable por computadora el cual pueda ordenar a un procesador de una computadora llevar a cabo los métodos. Por lo tanto, aunque la invención se ha descrito con respecto a modalidades ejemplares, se apreciará que la invención pretende cubrir todas las modificaciones y equivalentes dentro del alcance de las • siguientes reivindicaciones.

Claims (20)

NOVEDAD DE LA INVENCION Habiendo descrito el presente invento, se considera como una novedad y, por lo tanto, se reclama como prioridad lo contenido en las siguientes: REIVINDICACIONES
1.- Un sistema de entrega electrónica para entregar corrientes de. datos sobre un canal de difusión, en •donde el canal de difusión es un canal para transmitir señales desde una o más fuentes a una pluralidad de receptores, en donde cada receptor intenta recibir sustancialmente la misma señal, el sistema de entrega electrónica comprende: un sistema de remitente que envía datos para la corriente de datos dentro de los paquetes de capa física de los bloques de capa física, en donde indicaciones de la manera en que los datos enviados están relacionados con la corriente de datos se basan al menos en parte en los bloques de capa física.
2. - El sistema de entrega electrónica de conformidad con la reivindicación 1, caracterizado porque las indicaciones de la manera en que los datos enviados están relacionados con la corriente de datos se basan, al menos en parte, en información en las cabeceras de los bloques de capa física, en donde el sistema de remitente configura las cabeceras de los bloques de capa física para incluir las indicaciones.
3. - El sistema de entrega electrónica de conformidad con la reivindicación 1, caracterizado porque las indicaciones de la manera en que los datos enviados están relacionados con la corriente de datos se basan, al menos en parte, en información en las cabeceras de los paquetes de capa física.
. - El sistema de entrega electrónica de conformidad con la reivindicación 1, caracterizado porque los datos enviados están organizados en símbolos dentro de bloques fuente de datos, en donde las indicaciones comprenden indicaciones de cómo un símbolo es generado a partir de un bloque fuente e indicaciones de una asociación entre un símbolo y un bloque fuente.
5. - El sistema de entrega electrónica de conformidad con la reivindicación 4, caracterizado porque las indicaciones son identificadores de símbolo de codificación, en donde los identificadores de símbolo de codificación son al menos parcialmente llevados en cabeceras de bloques de capa física.
6. - El sistema de entrega electrónica de conformidad con la reivindicación 4, caracterizado porque las indicaciones son identificadores de símbolo de codificación, en donde los identificadores de símbolo de codificación son llevados en un canal de datos de control.
7. - El sistema de entrega electrónica de conformidad con la reivindicación 4, caracterizado porque la asociación entre símbolos y bloques fuente puede ser determinada en gran medida a partir de las cabeceras de bloques de capa física.
8. - El sistema de entrega electrónica de conformidad con la reivindicación 4, caracterizado porque los símbolos enviados de datos incluyen datos de reparación FEC generados a partir de los bloques fuente.
9. - El sistema de entrega electrónica de conformidad con la reivindicación 4, caracterizado porque más de una corriente lógica de datos es enviada dentro de una sola corriente de bloques de capa física.
10. - El sistema de entrega electrónica de conformidad con la reivindicación 4, caracterizado porque los símbolos enviados de datos son enviados sobre más de una corriente de bloques de capa física.
11. - El sistema de entrega electrónica de conformidad con la reivindicación 4, caracterizado porque las indicaciones de la manera en que los símbolos enviados de datos están relacionados con la corriente o datos de objeto son al menos parcialmente llevadas en paquetes de capa física que llevan los símbolos de datos enviados.
12. - El sistema de entrega electrónica de conformidad con la reivindicación 4, caracterizado porque los datos enviados para un bloque fuente están organizados en diferentes sub-bloqúes o diferentes prioridades.
13. - El sistema de entrega electrónica de conformidad con la reivindicación 12, caracterizado porque indicaciones de la estructura de sub-bloque de un bloque fuente son determinadas en gran medida a partir de cabeceras de bloques de capa física.
14. - El sistema de entrega electrónica de conformidad con la reivindicación 12, caracterizado porque - las indicaciones de la estructura de sub-bloque de un bloque fuente pueden ser determinadas en gran medida a partir de las cabeceras de paquetes de capa física llevados en bloques de capa física.
15. - El sistema de entrega electrónica de conformidad con la reivindicación 12, caracterizado porque los símbolos enviados de datos incluyen datos de reparación FEC generados a partir de diferentes sub-bloques y combinaciones de sub-bloques.
16. - El sistema de entrega electrónica de conformidad con la reivindicación 12, caracterizado porque los sub-bloques de prioridades se utilizan para determinar un orden de envío de los sub-bloques.
17. - El sistema de entrega electrónica de conformidad con la reivindicación 12, caracterizado porque los sub-bloques de prioridades son utilizados para mapear los sub-bloques en los bloques de capa física.
18. - El sistema de entrega electrónica de conformidad con la reivindicación 17, caracterizado porque los sub-bloques de prioridades mapeadas en los bloques de capa física son divididos entre diferentes bloques de capa física.
19. - Un método para transmitir datos desde un remitente a un receptor en un sistema de entrega electrónica para entregar corrientes de datos sobre un canal de difusión, en donde el canal de difusión es un canal para transmitir señales desde una o más fuentes a una pluralidad de receptores, en donde cada receptor intenta recibir sustancialmente la misma señal, el método comprende : enviar datos par la corriente de datos dentro de los paquetes de capa física de bloques de capa física desde el remitente, en donde indicaciones de la manera en que los datos enviados están relacionados con la corriente de datos se basan al menos en parte en la capa física de bloques.
20.- Un medio legible por computadora que comprende un código ejecutable por computadora para ejecutar el método de la reivindicación 19.
MX2010012117A 2008-05-07 2009-05-07 Manipulacion de canal rapida y proteccion de corriente de alta calidad sobre un canal de difusion. MX2010012117A (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US5132508P 2008-05-07 2008-05-07
PCT/US2009/043184 WO2009137705A2 (en) 2008-05-07 2009-05-07 Fast channel zapping and high quality streaming protection over a broadcast channel

Publications (1)

Publication Number Publication Date
MX2010012117A true MX2010012117A (es) 2010-12-01

Family

ID=41265414

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2010012117A MX2010012117A (es) 2008-05-07 2009-05-07 Manipulacion de canal rapida y proteccion de corriente de alta calidad sobre un canal de difusion.

Country Status (14)

Country Link
US (1) US20100017686A1 (es)
EP (1) EP2286585A4 (es)
JP (2) JP5847577B2 (es)
KR (1) KR101367886B1 (es)
CN (1) CN102017617B (es)
AU (1) AU2009244223B2 (es)
BR (1) BRPI0912524A2 (es)
CA (1) CA2723386A1 (es)
IL (1) IL208689A0 (es)
MX (1) MX2010012117A (es)
RU (1) RU2010150108A (es)
TW (1) TW201014366A (es)
UA (1) UA95881C2 (es)
WO (1) WO2009137705A2 (es)

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
CN100539439C (zh) 2002-10-05 2009-09-09 数字方敦股份有限公司 连锁反应码的系统编码和解码系统和方法
US8005222B2 (en) * 2003-07-15 2011-08-23 Sony Corporation Radio communication system, radio communication device, radio communication method, and computer program
KR101205758B1 (ko) 2004-05-07 2012-12-03 디지털 파운튼, 인크. 파일 다운로드 및 스트리밍 시스템
CN101686107B (zh) 2006-02-13 2014-08-13 数字方敦股份有限公司 使用可变fec开销和保护周期的流送和缓冲
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US7971129B2 (en) 2006-05-10 2011-06-28 Digital Fountain, Inc. Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient users of the communications systems
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
KR101129260B1 (ko) 2007-09-12 2012-03-27 디지털 파운튼, 인크. 신뢰성 있는 통신들을 가능하게 하는 소스 식별 정보 생성 및 통신
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US9136981B2 (en) * 2010-03-03 2015-09-15 Qualcomm Incorporated Block aggregation of objects in a communication system
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US9697086B2 (en) 2010-06-30 2017-07-04 EMC IP Holding Company LLC Data access during data recovery
US9235585B1 (en) 2010-06-30 2016-01-12 Emc Corporation Dynamic prioritized recovery
US8438420B1 (en) 2010-06-30 2013-05-07 Emc Corporation Post access data preservation
US9367561B1 (en) * 2010-06-30 2016-06-14 Emc Corporation Prioritized backup segmenting
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US8958375B2 (en) * 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US20120208580A1 (en) * 2011-02-11 2012-08-16 Qualcomm Incorporated Forward error correction scheduling for an improved radio link protocol
KR20120137198A (ko) * 2011-06-11 2012-12-20 삼성전자주식회사 통신 시스템에서 패킷 송수신 장치 및 방법
GB2492830B (en) 2011-07-14 2018-06-27 Skype Correction data
US10498359B2 (en) 2011-07-14 2019-12-03 Microsoft Technology Licensing, Llc Correction data
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
JP5860673B2 (ja) 2011-11-07 2016-02-16 日東電工株式会社 粘着剤組成物、粘着剤層、粘着剤層付偏光板および画像形成装置
KR102028948B1 (ko) * 2011-11-08 2019-10-17 삼성전자주식회사 멀티미디어 통신 시스템에서 어플리케이션 계층-순방향 오류 정정 패킷 송/수신 장치 및 방법
JP5908107B2 (ja) 2011-11-21 2016-04-26 フラウンホッファー−ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー.ファオ 層認識のある前方誤り訂正のためのインターリーブ
JP5875106B2 (ja) 2011-11-24 2016-03-02 日東電工株式会社 粘着剤組成物、粘着剤層、粘着剤層付偏光板および画像形成装置
CN108600786A (zh) * 2011-11-30 2018-09-28 三星电子株式会社 用于发送/接收广播数据的装置和方法
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
JP5425258B2 (ja) * 2012-04-16 2014-02-26 日東電工株式会社 粘着剤組成物、粘着剤層、粘着剤層付偏光フィルムおよび画像形成装置
KR101961736B1 (ko) 2012-04-23 2019-03-25 삼성전자 주식회사 통신 시스템에서 패킷 송수신 장치 및 방법
CN109618185A (zh) 2012-07-10 2019-04-12 Vid拓展公司 由wtru执行的方法、wtru及编码设备
CN109089122B (zh) * 2013-01-18 2022-08-05 弗劳恩霍夫应用研究促进协会 一种前向纠错数据生成器和前向纠错解码器
EP3001691A4 (en) * 2013-05-22 2016-10-19 Lg Electronics Inc METHOD AND DEVICE FOR PROCESSING SIGNALING DATA BETWEEN LAYERS IN AN IP-BASED DIGITAL BROADCAST SYSTEM
US9805479B2 (en) 2013-11-11 2017-10-31 Amazon Technologies, Inc. Session idle optimization for streaming server
US9641592B2 (en) 2013-11-11 2017-05-02 Amazon Technologies, Inc. Location of actor resources
US9582904B2 (en) 2013-11-11 2017-02-28 Amazon Technologies, Inc. Image composition based on remote object data
US9578074B2 (en) 2013-11-11 2017-02-21 Amazon Technologies, Inc. Adaptive content transmission
US9604139B2 (en) 2013-11-11 2017-03-28 Amazon Technologies, Inc. Service for generating graphics object data
US9634942B2 (en) 2013-11-11 2017-04-25 Amazon Technologies, Inc. Adaptive scene complexity based on service quality
US9413830B2 (en) 2013-11-11 2016-08-09 Amazon Technologies, Inc. Application streaming service
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
KR102208814B1 (ko) * 2014-03-28 2021-01-28 삼성전자주식회사 통신 시스템에서 패킷 송수신 방법 및 장치
US9455750B2 (en) 2014-07-28 2016-09-27 Qualcomm Incorporated Source block size selection
CN105531951A (zh) * 2014-07-29 2016-04-27 华为技术有限公司 数据加密传输方法和装置
US20160323063A1 (en) * 2015-05-01 2016-11-03 Qualcomm Incorporated Bundled Forward Error Correction (FEC) for Multiple Sequenced Flows
KR101870750B1 (ko) * 2017-12-28 2018-06-26 오픈스택 주식회사 패킷 전송 순서 재배열을 이용한 영상 인코딩 장치 및 그 동작 방법
US11863317B2 (en) * 2021-08-25 2024-01-02 BitRipple, Inc. Methods for reliable low latency data delivery using erasure codes and feedback

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6307487B1 (en) * 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
KR100607934B1 (ko) * 1999-08-27 2006-08-03 삼성전자주식회사 광대역 무선 통신에서의 링크 계층의 오류 제어방법 및 이를위한 기록 매체
US6633564B1 (en) * 1999-09-22 2003-10-14 Nortel Networks Limited Method and apparatus for inserting packets into a data stream
US6845105B1 (en) * 2000-09-28 2005-01-18 Telefonaktiebolaget Lm Ericsson Method and apparatus for maintaining sequence numbering in header compressed packets
US7136395B2 (en) * 2000-11-30 2006-11-14 Telefonaktiebolaget L M Ericsson (Publ) Method and system for transmission of headerless data packets over a wireless link
US7289497B2 (en) * 2001-07-03 2007-10-30 Telefonaktiebolaget Lm Ericsson (Publ) Implicit packet type identification
EP1521384A3 (en) * 2003-08-20 2007-03-14 Siemens Aktiengesellschaft A method for transmitting a multimedia message
KR100602633B1 (ko) * 2003-11-08 2006-07-19 삼성전자주식회사 패킷의 헤더를 압축하는 방법 및 그 장치
US7817579B2 (en) * 2004-03-29 2010-10-19 Intel Corporation Access point having at least one or more configurable radios
KR100800887B1 (ko) * 2004-05-07 2008-02-04 삼성전자주식회사 무선 통신 시스템에서 방송 서비스 데이터 송/수신 방법 및 시스템
KR101205758B1 (ko) * 2004-05-07 2012-12-03 디지털 파운튼, 인크. 파일 다운로드 및 스트리밍 시스템
MXPA06013210A (es) * 2004-05-13 2007-02-28 Qualcomm Inc Suministro de informacion en un canal de comunicacion.
WO2006038054A1 (en) * 2004-10-06 2006-04-13 Nokia Corporation Packet transmission using error correction of data packets
US7751324B2 (en) * 2004-11-19 2010-07-06 Nokia Corporation Packet stream arrangement in multimedia transmission
CN100413370C (zh) * 2004-12-13 2008-08-20 上海贝尔阿尔卡特股份有限公司 传输多媒体广播/多播业务告知指示的方法和设备
RU2384956C2 (ru) * 2005-05-19 2010-03-20 Нокиа Корпорейшн Система и способ обеспечения неравномерной защиты от ошибок для маркированных согласно приоритету дейтаграмм в системе передачи dvb-h
AU2006258372A1 (en) * 2005-06-17 2006-12-21 Samsung Electronics Co., Ltd. Apparatus and method for transmitting/receiving broadcast data in a mobile communication system
CN1917411B (zh) * 2005-08-16 2012-03-07 中兴通讯股份有限公司 一种实现多载波高速下行分组接入的系统和方法
US7676733B2 (en) * 2006-01-04 2010-03-09 Intel Corporation Techniques to perform forward error correction for an electrical backplane
PL1969856T3 (pl) * 2006-01-05 2013-01-31 Ericsson Telefon Ab L M Zarządzanie plikiem zasobnika medialnego
EP1980074A4 (en) * 2006-02-13 2012-12-19 Digital Fountain Inc CONTINUOUS CONTINUOUS CONTINUOUS TRANSMISSION WITH CONCURRENT FLUX AGGREGATION FOR CONTINUOUS CONTROL CALCULATION
CN101072227A (zh) * 2006-05-11 2007-11-14 华为技术有限公司 一种视频广播系统中的发送系统、方法和接收系统
KR101129260B1 (ko) * 2007-09-12 2012-03-27 디지털 파운튼, 인크. 신뢰성 있는 통신들을 가능하게 하는 소스 식별 정보 생성 및 통신
US20090094356A1 (en) * 2007-10-09 2009-04-09 Nokia Corporation Associating Physical Layer Pipes and Services Through a Program Map Table

Also Published As

Publication number Publication date
AU2009244223A1 (en) 2009-11-12
WO2009137705A2 (en) 2009-11-12
IL208689A0 (en) 2010-12-30
JP2015222954A (ja) 2015-12-10
JP5847577B2 (ja) 2016-01-27
AU2009244223B2 (en) 2013-02-14
CA2723386A1 (en) 2009-11-12
JP2011523806A (ja) 2011-08-18
KR101367886B1 (ko) 2014-02-26
EP2286585A4 (en) 2015-06-17
UA95881C2 (ru) 2011-09-12
EP2286585A2 (en) 2011-02-23
RU2010150108A (ru) 2012-06-20
WO2009137705A3 (en) 2010-02-11
CN102017617A (zh) 2011-04-13
CN102017617B (zh) 2014-08-13
KR20110015615A (ko) 2011-02-16
US20100017686A1 (en) 2010-01-21
TW201014366A (en) 2010-04-01
BRPI0912524A2 (pt) 2015-10-13

Similar Documents

Publication Publication Date Title
AU2009244223B2 (en) Fast channel zapping and high quality streaming protection over a broadcast channel
JP5442816B2 (ja) 可変fecオーバヘッド及び保護期間を利用したストリーミング及びバッファリング
US9350488B2 (en) Content delivery system with allocation of source data and repair data among HTTP servers
CN100375538C (zh) 在分组信道上多媒体通信的方法
AU2008242911B2 (en) Dynamic stream interleaving and sub-stream based delivery
US9246630B2 (en) Method, device, and system for forward error correction
US20120151302A1 (en) Broadcast multimedia storage and access using page maps when asymmetric memory is used
WO2013067219A2 (en) Content delivery system with allocation of source data and repair data among http servers
WO2010124651A1 (zh) 前向纠错方法、装置和系统
US8458571B2 (en) Data transmission method and equipment
JP3730977B2 (ja) データ伝送方法およびデータ処理方法

Legal Events

Date Code Title Description
FG Grant or registration