ES2386476T3 - Método y disposición para adaptar la transmisión de medios codificados - Google Patents

Método y disposición para adaptar la transmisión de medios codificados Download PDF

Info

Publication number
ES2386476T3
ES2386476T3 ES07748525T ES07748525T ES2386476T3 ES 2386476 T3 ES2386476 T3 ES 2386476T3 ES 07748525 T ES07748525 T ES 07748525T ES 07748525 T ES07748525 T ES 07748525T ES 2386476 T3 ES2386476 T3 ES 2386476T3
Authority
ES
Spain
Prior art keywords
transmission
transmission format
performance
adaptation
format
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES07748525T
Other languages
English (en)
Inventor
Ingemar Johansson
Tomas Frankkila
Jonas Svedberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2386476T3 publication Critical patent/ES2386476T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • H04L1/0003—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate by switching between different modulation schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0014—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the source coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0016—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy involving special memory structures, e.g. look-up tables

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método para adaptar a diferentes condiciones de funcionamiento la transmisión de contenido multimedia codificado (802) en una red de conmutación de paquetes, donde están disponibles una serie de formatos (808) de transmisión, en el que cada formato (808) de transmisión define una combinación de por lo menos dos características; comprendiendo dicho método las etapas de: recibir (1105) información acerca de si la métrica de rendimiento del contenido multimedia codificado (802) transmitido satisface un objetivo predeterminado (814), si la métrica de rendimiento del contenido multimedia codificado (802) transmitido no satisface el objetivo predeterminado (814); seleccionar (1106) otro formato (808) de transmisión entre los formatos (808) de transmisión disponibles, hasta que la métrica de rendimiento del contenido multimedia codificado (802) transmitido satisfaga el objetivo predeterminado, caracterizado por que dichas características son combinadas entre las de agregación de tramas, velocidad binaria de codificación fuente y redundancia.

Description

Metodo y disposici6n para adaptar la transmisi6n de medios codificados
Campo tecnico
La presente invenci6n se refiere a un metodo y una disposici6n para la transmisi6n de medios codificados, y en 5 concreto a una soluci6n para adaptar la transmisi6n a diferentes condiciones de funcionamiento.
Antecedentes
En los sistemas de protocolo de internet (IP, Internet Protocol), especialmente los sistemas de IP inalambricos tales como el acceso de paquetes de alta velocidad (HSPA, High Speed Packet Access) (es decir, enlace ascendente mejorado y acceso de paquetes de datos de alta velocidad), los servicios han de funcionar en un amplio intervalo de
10 condiciones de funcionamiento. Las condiciones de funcionamiento dependen de una serie de factores:
El tipo de acceso que se utilice, tal como HSPA, portadoras de canal dedicado (DCH, Dedicated Channel), tasas de datos mejoradas para evoluci6n de GSM (EDGE, Enhanced Data Rates for GSM Evolution), etc.
Las condiciones del canal para el usuario actual, es decir, si el usuario tiene buenas o malas condiciones de canal.
15 La actual carga de celda en el sistema
La mezcla de trafico, es decir si todos los usuarios estan utilizando, por ejemplo, voz sobre IP (VoIP, Voice over IP) o si existe una mezcla de usuarios VoIP, usuarios de videotelefonfa y usuarios navegando o transfiriendo archivos.
Especfficamente para HSPA, diferentes planificadores proporcionan un rendimiento muy diferente para usuarios 20 diferentes.
Carga del sistema. En situaciones de carga elevada los encaminadores pierden paquetes cuando las colas se llenan.
Todas estas diferentes condiciones de funcionamiento tienen como resultado diferentes problemas de rendimiento y requieren adaptaciones diferentes para mejorar la calidad de una sesi6n VoIP.
25 Para voz con conmutaci6n de circuitos (CS, circuit switched) con multi-velocidad adaptativa (AMR, Adaptive MultiRate), es posible adaptar la velocidad binaria del c6dec de voz (denominado tambien c6dec fuente) y la velocidad binaria de la codificaci6n de canal, de tal modo que:
Para buenas condiciones del canal, puede utilizarse un modo AMR con una velocidad binaria elevada, por ejemplo AMR 122, que permite una cantidad muy pequena de codificaci6n del canal. Esto proporciona la
30 maxima calidad pero lo hace menos resistente a errores de canal.
Para malas condiciones del canal, puede utilizarse un modo AMR con una velocidad binaria reducida, por ejemplo AMR 475, que permite una codificaci6n del canal extensiva. Esto mejora la resistencia frente a errores de canal, sacrificando en parte un comportamiento claro del canal.
Para condiciones de canal entre estos extremos, puede utilizarse un modo AMR con una velocidad binaria 35 intermedia, por ejemplo AMR 74, que permite una codificaci6n de canal considerable.
En los sistemas CS, tales como GSM, W-CDMA, la suma de los bits de codificaci6n de voz y los bits de codificaci6n de canal es constante. Sin embargo, este no es el caso necesariamente para sistemas PS. Ademas, para sistemas CS, adaptar las velocidades binarias de la codificaci6n fuente y la codificaci6n de canal permite por lo tanto la maximizaci6n de la calidad de la voz para buenas condiciones de canal y la maximizaci6n de la resistencia para
40 malas condiciones de canal.
Para sistemas IP, adaptar la velocidad binaria puede o no cambiar la cantidad de codificaci6n de canal, dependiendo del diseno del sistema IP. Por ejemplo:
− Algunos sistemas IP pueden adaptar la codificaci6n del canal de manera similar a como lo hacen los sistemas CS.
45 − Algunos sistemas IP pueden siempre anadir una cantidad fija de codificaci6n de canal, o un esquema de modulaci6n fijo. Por ejemplo, si la codificaci6n de canal es fija, por ejemplo un c6digo de canal de velocidad 1/2, entonces el tamano del bloque transmitido es siempre proporcional al tamano del paquete de datos que esta siendo transmitido.
− Algunos sistemas IP pueden tener una codificaci6n de canal fija pero pueden permitir el envfo de varios paquetes en el mismo bloque de transmisi6n, si las condiciones del canal son lo suficientemente buenas.
− Algunos sistemas IP, tales como HSPA, pueden adaptar la cantidad de codificaci6n de canal y el numero de paquetes IP que son empaquetados en un bloque de transmisi6n.
Es importante destacar que, para sistemas IP, adaptar las velocidades binarias del c6dec fuente (tal como seleccionar un modo AMR) y del c6dec de canal funciona para algunos escenarios de funcionamiento y algunas condiciones de funcionamiento, pero no para todos. La adaptaci6n de la velocidad binaria no funciona demasiado bien cuando el sistema esta limitado en la velocidad de paquetes. Asimismo, existe una tendencia general en la industria a avanzar hacia la separaci6n de la codificaci6n fuente respecto de la codificaci6n de canal. En este caso, reducir la velocidad binaria, que proporciona paquetes IP menores, no necesariamente significa que se aplique automaticamente mayor codificaci6n de canal (= protecci6n frente a errores).
VoIP tiene asimismo que funcionar para diferentes combinaciones de metodos de acceso. Por ejemplo, un usuario puede utilizar HSPA mientras que el otro usuario en la sesi6n puede utilizar, por ejemplo, EDGE, servicios y protocolos de telecomunicaciones e internet convergentes para redes avanzadas (TISPAN, Telecoms & Internet converged Services & Protocols for Advanced Networks), una red de acceso generico (GAN, Generic Access network)/red de area local inalambrica (WLAN, Wireless Local Area Network), o un tipo de red de lfnea de abonado digital (xDSL, Digital Subscriber Line). Estos metodos de acceso tienen propiedades diferentes, y un esquema de adaptaci6n que esta disenado (u optimizado) para un metodo de acceso especffico puede no funcionar igual de bien para otro metodo de acceso.
Para complicar mas el problema, sistemas diferentes tienen capacidades diferentes, lo que permite la adaptaci6n de diferentes maneras. Algunos ejemplos de capacidades son:
•
La flexibilidad en esquemas de modulaci6n y codificaci6n de canal.
•
Los tamanos mfnimo y maximo de bloques de transmisi6n posibles son diferentes para sistemas diferentes.
•
Algunos sistemas IP permiten transmitir varios paquetes IP en un bloque de transmisi6n, mientras que otros sistemas IP pueden no permitir esto.
Pueden existir otras capacidades que son diferentes para sistemas diferentes.
Un problema adicional es que la aplicaci6n VoIP puede no saber que tipo de acceso esta siendo utilizado. Las aplicaciones VoIP implementadas en un telefono m6vil pueden estar al tanto del tipo de acceso, pero si la aplicaci6n VoIP esta implementada en un PC (ordenador portatil), que utiliza el telefono m6vil como un m6dem, entonces puede no existir la senalizaci6n necesaria entre la aplicaci6n VoIP y el telefono m6vil para intercambiar esta informaci6n. Para simplificar la implementaci6n, puede desearse asimismo separar la codificaci6n fuente respecto de la transmisi6n. En cualquier caso, el cliente VoIP tendra informaci6n solamente acerca de su propio tipo de acceso. Es improbable que se anada senalizaci6n para informar a un primer cliente sobre el tipo de acceso que esta utilizando un segundo cliente.
Se describe tecnica relacionada la patente US 5.490.168, que da a conocer un metodo para adaptar la transmisi6n, tal como se indica en los preambulos de las reivindicaciones 1 y 18, y en la patente US 2004/160979, que describe un terminal que comprende un codificador adaptativo multi-velocidad. Se da a conocer otra tecnica relacionada en la patente US 6.154.489, que muestra una transmisi6n de imagenes digitales comprimidas sobre conexiones de comunicaci6n inalambrica degradadas, habitualmente una conexi6n por radiofrecuencia, con una calidad mejorada, y en la patente W02004/114549, que describe un sistema mejorado de datos de paquetes de alta velocidad.
Compendio
Por lo tanto, es un objetivo de la presente invenci6n conseguir una soluci6n que no requiera estar en conocimiento del tipo de acceso.
Esto se consigue seleccionando un esquema de adaptaci6n para la transmisi6n de medios codificados, que tiene como resultado un rendimiento satisfactorio del medio codificado transmitido. De acuerdo con la presente invenci6n, cada esquema de adaptaci6n define un conjunto de formatos de transmisi6n diferentes, en el que cada uno de los formatos de transmisi6n es una combinaci6n de, por lo menos, dos de las caracterfsticas siguientes: la velocidad binaria del c6dec fuente; la velocidad de paquetes, que esta relacionada con el numero de tramas que son encapsuladas en cada paquete (denominado agregaci6n de tramas); el nivel de redundancia; y la cantidad de desplazamiento utilizada por la redundancia. Mediante el recurso de utilizar los formatos de transmisi6n diferentes, la transmisi6n puede ser adaptada a condiciones de funcionamiento diferentes y por lo tanto se mejora el rendimiento.
De este modo, de acuerdo con un primer aspecto, la presente invenci6n se refiere a un metodo para adaptar la transmisi6n de medios codificados en una red de conmutaci6n de paquetes, tal como se indica en la reivindicaci6n 1.
Una ventaja de la presente invenci6n es que la utilizaci6n de diferentes formatos de transporte mejora el rendimiento.
Otra ventaja es que al tener diferentes mecanismos de adaptaci6n, la soluci6n es fuerte frente a diferentes sistemas, diferentes combinaciones de sistema y diferentes implementaciones.
Una ventaja de una realizaci6n es que se consigue asimismo una soluci6n para adaptaci6n ascendente.
Breve descripci6n de los dibujos
La figura 1 muestra una tabla 1 que ejemplifica formatos de transmisi6n etiquetados del 1 al 7 que pueden ser evaluados en un esquema de adaptaci6n.
La figura 2 muestra la tabla 2, que ejemplifica los formatos de transmisi6n correspondientes al numero de formato de transmisi6n 1 de la tabla 1.
La figura 3 muestra la tabla 3, que ejemplifica los formatos de transmisi6n correspondientes al numero de formato de transmisi6n 4 de la tabla 1.
La figura 4 muestra la tabla 4, que ejemplifica los formatos de transmisi6n correspondientes al numero de formato de transmisi6n 5 de la tabla 1.
La figura 5 muestra la tabla 5, que ejemplifica los formatos de transmisi6n correspondientes al numero de formato de transmisi6n 6 de la tabla 1.
La figura 6 muestra la tabla 6, que ejemplifica los formatos de transmisi6n correspondientes al numero de formato de transmisi6n 7 de la tabla 1.
La figura 7 muestra un diagrama de flujo de posibles transiciones entre diferentes estados, de acuerdo con una realizaci6n de la presente invenci6n.
La figura 8 muestra una implementaci6n en que el control de adaptaci6n esta implementado en el receptor, de acuerdo con una realizaci6n de la presente invenci6n.
La figura 9 muestra una implementaci6n alternativa en que el control de adaptaci6n esta implementado en el transmisor, de acuerdo con una realizaci6n de la presente invenci6n.
La figura 10 muestra la arquitectura en detalle cuando se implementa el control de adaptaci6n en el receptor, de acuerdo con una realizaci6n de la presente invenci6n.
La figura 11 es un diagrama de flujo del metodo para llevar a cabo adaptaci6n descendente, de acuerdo con la realizaci6n en la que se implementa control de adaptaci6n en el receptor.
La figura 12 es un diagrama de flujo del metodo para llevar a cabo adaptaci6n ascendente, de acuerdo con otra realizaci6n de la presente invenci6n.
Descripci6n detallada
El enfoque principal de las soluciones existentes de adaptaci6n de los medios es reducir la velocidad binaria y, en concreto, realizar adaptaci6n descendente, es decir adaptar a peores condiciones mediante de reducir la velocidad binaria. Puesto que para transporte IP reducir la velocidad binaria no significa automaticamente que se utilice mas codificaci6n del canal (= protecci6n contra errores), las soluciones existentes no necesariamente aumentan la fortaleza frente a errores/resistencia frente a errores cuando se requiere.
Ademas, no existen mecanismos en la tecnica anterior que permitan la adaptaci6n ascendente y aseguren que la calidad de los medios no se degrada al intentar la adaptaci6n ascendente.
La idea basica de la presente invenci6n es seleccionar un esquema de adaptaci6n para la transmisi6n del medio codificado, que tenga como resultado un rendimiento satisfactorio del medio codificado transmitido. Una diferencia respecto de la tecnica anterior es que cada esquema de adaptaci6n define un conjunto de formatos de transmisi6n diferentes, en el que cada uno de los formatos de transmisi6n es una combinaci6n de, por lo menos, dos de las caracterfsticas siguientes: la velocidad binaria del c6dec fuente; la velocidad de paquetes, que esta relacionada con el numero de tramas que son encapsuladas en cada paquete (denominado, agregaci6n de tramas); el nivel de redundancia; y la cantidad de desplazamiento utilizado por la redundancia. Mediante el recurso de utilizar los formatos de transmisi6n diferentes, la transmisi6n puede ser adaptada a condiciones de funcionamiento diferentes y por lo tanto se mejora el rendimiento.
Debe observarse que el termino escenario de funcionamiento se refiere, en esta descripci6n, a los sistemas y nodos que son utilizados en la sesi6n. Por ejemplo, un cliente utiliza HSPA; el otro cliente utiliza EDGE; y comunican a traves de HSPA, red central IP y EDGE (y viceversa). En esta descripci6n, el termino condici6n de funcionamiento
implica las condiciones de canal para los diferentes tipos de acceso inalambrico y la carga de red para la red central. Esto puede expresarse de varios modos. Por ejemplo:
•
la relaci6n canal/interferencia (C/I) para la respectiva red de acceso inalambrico; o:
•
la tasa de errores de bloque (BLER) o la tasa de errores de paquetes (PLR) para la red de acceso inalambrico;
o:
•
la tasa de errores de paquetes para la red central; o:
•
el nivel de carga del sistema (en principio, el numero de usuarios).
De acuerdo a la presente invenci6n, puede seleccionarse y evaluarse un nuevo formato de transmisi6n entre un conjunto de formatos de transmisi6n disponibles. El nuevo formato de transmisi6n puede seleccionarse cuando se detecta que el rendimiento es insuficiente, pero debe observarse que puede asimismo seleccionarse y evaluarse un nuevo formato de transmisi6n independientemente del rendimiento actual. Si el rendimiento del nuevo formato de transmisi6n es aceptable, entonces se continua con este formato de transmisi6n; de lo contrario se intenta otro formato de transmisi6n hasta que se encuentra un formato de transmisi6n que tiene como resultado un rendimiento aceptable. Si no es posible encontrar un formato de transmisi6n aceptable, entonces existe un esquema de adaptaci6n "de reserva", denominado un formato de transmisi6n de reserva que proporciona una maxima resistencia, lo que implica el formato de transporte que ofrece la maxima fortaleza frente a perdidas de paquetes. Habitualmente, este es el formato que tiene la mayor cantidad de redundancia. Con frecuencia es necesario definir un lfmite superior para la redundancia permitida. Esto se debe a dos razones:
1) Mucha redundancia supone un aumento en la carga de la celda, puesto que el c6dec de voz puede reducir la velocidad binaria de la codificaci6n fuente solamente en cierta medida.
2) La redundancia introduce retardo y para servicios en tiempo real existe un lfmite superior para el retardo desde un punto de vista practico.
Tal como se ha indicado anteriormente, un esquema de adaptaci6n comprende un conjunto de formatos de transmisi6n. Los diferentes formatos de transmisi6n pueden evaluarse en un orden predeterminado, en el que el orden puede depender de la caracterfstica de los errores de transmisi6n, o el orden puede depender de un objetivo que determina el rendimiento aceptable.
Un rendimiento aceptable del esquema de transmisi6n implica que el rendimiento del esquema de transmisi6n seleccionado esta por encima de cierto objetivo, por ejemplo en terminos de la tasa de perdida de paquetes o de la tasa de borrado de tramas, o que el rendimiento del nuevo esquema de transmisi6n es mejor que un esquema de transmisi6n previo.
De acuerdo con una realizaci6n, se incluye un mecanismo para evaluar si es posible volver a un formato de transmisi6n utilizado previamente. Esto se lleva a cabo mediante "sondeo" (es decir, probar si el rendimiento resulta aceptable si se utiliza un formato de transmisi6n menos resistente), tal como se describira en mayor detalle a continuaci6n. El sondeo puede conseguirse aumentando la velocidad binaria mediante anadir informaci6n redundante, y evaluando a continuaci6n la tasa de perdida de paquetes.
A continuaci6n, para proporcionar una mejor comprensi6n de las realizaciones de la presente invenci6n se proporcionaran ejemplos de los diversos problemas de rendimiento para los diferentes escenarios de funcionamiento, y un bosquejo de una manera apropiada para adaptar el escenario de funcionamiento mediante el recurso de seleccionar el formato de transmisi6n apropiado para cada uno, y el orden de los formatos de transmisi6n apropiados.
Escenario de funcionamiento 1: HSPA con usuarios VoIP, con carga elevada, donde el planificador esta optimizado para VoIP:
Es probable que algunos usuarios experimenten tasas elevadas de perdida de paquetes cuando aumenta la carga del sistema. Sin embargo, un planificador optimizado para VoIP asegura que las perdidas de paquetes estan bastante bien distribuidas y que se evitan rafagas largas de perdida de paquetes.
En este caso, las acciones apropiadas pueden ser (por orden):
1.
Reducir la velocidad binaria de c6dec.
2.
Anadir redundancia, paquetes consecutivos, mantener reducida la velocidad binaria de c6dec.
3.
Utilizar agregaci6n de tramas, mantener reducida la velocidad binaria de c6dec.
Estas acciones pueden aplicarse utilizando los formatos de transporte mostrados en la tabla 1 de la figura 1. En la etapa 1, se puede conmutar del formato de transmisi6n 1 al 2 y a continuaci6n al formato de transmisi6n 3 si el formato de transmisi6n 2 no es suficiente. En algunos casos, puede ser necesario conmutar directamente desde el formato de transmisi6n 1 al 3. En la etapa 2, los formatos de transmisi6n 5, 6 y 7 pueden ser utilizados en el orden indicado. Ademas, la etapa 3 corresponde a la utilizaci6n del formato de transmisi6n 4.
Escenario de funcionamiento 2: HSPA con usuarios VoIP, con carga elevada, donde el planificador no esta optimizado para VoIP.
Si el planificador no esta optimizado para VoIP, por ejemplo un planificador Max-COI o un planificador proporcional equitativo, entonces es probable que este presente un numero sustancial de rafagas largas de perdida de paquetes.
En este caso, las acciones apropiadas pueden ser (por orden):
1.
Reducir la velocidad binaria de c6dec.
2.
Anadir redundancia con desplazamiento, mantener una velocidad binaria de c6dec reducida. La redundancia con desplazamiento implica que los bits redundantes no son insertados de manera consecutiva, sino que son dispersados en el paquete, lo que tiene como resultado un buen funcionamiento en un entorno con rafagas.
3. Mantener la velocidad de c6dec reducida pero desactivar la redundancia. Escenario de funcionamiento 3. HSPA con usuarios VoIP y condiciones de canal malas. Cuando las condiciones del canal son malas, una soluci6n es reducir en primer lugar el tamano de los bloques de
transmisi6n. En este caso, las acciones apropiadas pueden ser (por orden):
1.
Reducir la velocidad binaria de c6dec.
2.
Mantener la velocidad de c6dec reducida y anadir redundancia.
3.
Mantener la velocidad de c6dec reducida y anadir redundancia con un desplazamiento.
Escenario de funcionamiento 4. EDGE
Puede no siempre ser factible anadir redundancia en EDGE, puesto que EDGE tiene multiples "esquemas de codificaci6n" o velocidades binarias. El operador puede configurar el sistema para permitir solamente, por ejemplo, los esquemas de codificaci6n con las 2-3 velocidades binarias menores. En este caso, habitualmente no existe espacio para anadir redundancia. Sin embargo, un operador puede permitir asimismo los esquemas de codificaci6n de velocidades binarias superiores. En este caso, es posible utilizar una cantidad limitada de redundancia.
En este caso, las acciones apropiadas pueden ser (por orden):
1. Reducir la velocidad binaria de c6dec.
2. Aplicar agregaci6n de tramas TISPAN La redes IP terrestres pueden estar limitadas en la velocidad binaria o limitadas en la velocidad de paquetes. Cuando la red esta limitada en la velocidad binaria, las acciones apropiadas son las mismas que para HSPA con un planificador optimizado para VoIP. Cuando la red esta limitada en la velocidad de paquetes, las acciones apropiadas son las mismas que se describen a continuaci6n para WLAN.
WLAN
Puesto que habitualmente WLAN esta limitada en la velocidad de paquetes, la mejor soluci6n es utilizar agregaci6n de tramas cuando las condiciones del canal se deterioran. En este caso, las acciones apropiadas pueden ser (por orden):
1.
Aplicar agregaci6n de tramas
2.
Reducir la velocidad binaria de c6dec.
3.
Anadir redundancia.
Tal como se ha descrito anteriormente, un esquema de adaptaci6n incluye varios formatos de transmisi6n en los que cada formato de transmisi6n es una combinaci6n especffica de: − Velocidad binaria de codificaci6n fuente, es decir modo de c6dec AMR.
− Paquetizaci6n, es decir el numero de tramas encapsuladas en cada paquete.
− Nivel de redundancia, es decir cuantas veces es transmitida una trama (en paquetes diferentes).
− Desplazamiento de la redundancia, es decir si son insertadas tramas "de relleno" entre las tramas que son
encapsuladas en cada paquete. Una trama de relleno es una trama que no contiene datos relevantes, pero tiene
que contener algunos datos de tal manera que sea posible identificar la trama como una trama de relleno.
Los formatos de transmisi6n evaluados son habitualmente ordenados y evaluados en cierto orden. La tabla 1 de la figura 1 describe un ejemplo de c6mo pueden construirse dichos formatos de transmisi6n identificados de 1 a 7.
Es posible disenar otros formatos de transmisi6n con grados variables de retroceso y resistencia. El retroceso es una reducci6n de la velocidad binaria (es decir, pasar de AMR 12,2 Kbps a AMR 5,9 Kbps) o de la velocidad de paquetes (es decir, pasar de 50 paquetes/segundo a 25).
La resistencia es una terminologfa generica que describe c6mo de fuerte es un formato de transporte frente a perdidas de paquetes. "Resistencia" se utiliza a menudo cuando se habla sobre fortaleza sin cuantificar exactamente dicha fortaleza. Ejemplos:
Esquema 1 = 1 trama/paquete, sin redundancia
Esquema 2 = 2 tramas/paquete, 100% redundancia (cada trama se transmite dos veces)
Con una tasa de perdida de paquetes del 10%, el esquema 1 proporciona una tasa de borrado de tramas del 10% pero el esquema 2 proporciona una tasa de borrado de tramas de aproximadamente el 1% (en funci6n de lo bien distribuidas que esten las perdidas de paquetes).
Los diferentes formatos de transmisi6n 1 a 7 mostrados en la tabla 1 de la figura 1 se explican en las tablas mostradas en las figuras 2 a 6.
La tabla 2 de la figura 2 muestra el formato de transmisi6n 1 de la tabla 1. En el formato de transmisi6n mostrado en la tabla 2, cada trama de voz es transmitida solamente una vez y en paquetes individuales. De este modo, la perdida de paquetes se corresponde con la perdida de tramas. Los formatos de transmisi6n 2 y 3 son similares, excepto en que el modo de c6dec de voz se reduce a AMR 74 y AMR 59, respectivamente.
De este modo, los formatos de transmisi6n 2 y 3 proporcionan un retroceso de la velocidad binaria, que reduce la carga de sistema.
El formato de transmisi6n correspondiente al formato de transmisi6n 4 de la tabla 1, mostrado en la tabla 3 de la figura 3, reduce la velocidad de paquetes de 50 a 25 paquetes por segundo. Esto es beneficioso puesto que se reduce la sobrecarga de paquetes IP, UDP y RTP, ya que la sobrecarga de cada paquete es compartida por dos tramas. Sin embargo, el inconveniente es que se pierden dos tramas de voz por cada paquete perdido.
En el formato de transmisi6n correspondiente al formato de transmisi6n 5 de la tabla 1, mostrado en la tabla 4 de la figura 4, se ha anadido redundancia. Esto posibilita recuperar todas las tramas de voz para cualquier caso de perdidas de paquetes aislados, puesto que cada trama de voz es transmitida dos veces pero en paquetes diferentes. Por ejemplo, si se ha perdido el paquete N + 3, entonces la trama M + 3 se encuentra en el paquete N + 2 y la trama M + 4 se encuentra en el paquete N + 4. Si se pierden 2 paquetes en una fila, entonces se perdera una trama de voz. Sin embargo, el inconveniente es que se anade cierto retardo. Asimismo, puesto que cada trama es transmitida dos veces, es importante reducir la velocidad binaria de codificaci6n fuente con objeto de no cargar el sistema mas de lo que en lo esta en el formato de transmisi6n numero 1.
El formato de transmisi6n correspondiente al formato de transmisi6n 6 de la figura 1, mostrado en la tabla 5 de la figura 5, es similar al formato de transmisi6n de la tabla 4 con las excepciones de que se utiliza una velocidad de modo de c6dec menor y de que todas las tramas de voz son transmitidas tres veces en paquetes diferentes. De este modo, es posible recuperar todas las tramas de voz incluso si se han perdido dos paquetes en una fila.
El formato de transmisi6n correspondiente al formato de transmisi6n 7 de la tabla 1 se muestra en la tabla 6 de la figura 6. Este formato de transmisi6n aumenta la resistencia frente a rafagas aun mas largas de perdidas de paquetes, puesto que se anaden tramas redundantes con un desplazamiento sin necesidad de anadir demasiada sobrecarga extra (las tramas SIN DATOS incrementan s6lo marginalmente los tamanos de los paquetes). Sin embargo, el inconveniente es que se anade aun mas retardo.
Las tramas SIN DATOS mostradas en la figura 6 son tramas "de relleno" (o vacfas) necesarias para completar el espacio entre las tramas de voz en la carga util RTP. La necesidad de utilizar tramas de relleno depende del formato de la carga util. Para el formato de carga util AMR es necesario utilizar estas tramas de relleno, puesto que las tramas que son encapsuladas en la carga util deben ser consecutivas. Otros formatos de carga util pueden proporcionar funcionalidad para evitar las tramas de relleno.
Debe resultar obvio que los formatos de transmisi6n pueden variarse indefinidamente, y resultan obvias otras alternativas de formatos de transmisi6n para un experto en la materia.
Para verificar que funciona bien un formato de transmisi6n que esta siendo evaluado, puede definirse un objetivo para el rendimiento del medio cuando se esta utilizando el formato de transmisi6n. El objetivo de la adaptaci6n puede ser un objetivo absoluto o un objetivo relativo. Preferentemente, este objetivo es diferente para condiciones de funcionamiento diferentes, y puede depender asimismo de las metricas de rendimiento elegidas:
Si el problema principal son las perdidas de paquetes y las perdidas de paquetes estan bastante bien distribuidas en el tiempo (no consecutivas), entonces el objetivo sera reducir la tasa de perdida de paquetes. Esto puede definirse de varios modos, por ejemplo:
La tasa de perdida de paquetes, despues de la adaptaci6n, debera ser menor que X% (umbral absoluto).
La tasa de perdida de paquetes, despues de la adaptaci6n, debera reducirse en Y% (umbral relativo).
Si las perdidas de paquetes son consecutivas, entonces el objetivo debera ser reducir la cantidad de perdidas consecutivas.
Asimismo, es posible definir objetivos para borrados de trama. Si el esquema de adaptaci6n contiene formatos de transmisi6n en los que se modifica la redundancia y/o la agregaci6n de tramas, entonces el objetivo debera ser reducir la tasa de borrado de tramas en lugar de la tasa de perdida de paquetes, puesto que la FER es "neutral" con respecto a la redundancia y la agregaci6n de tramas. El objetivo puede definirse de varios modos, por ejemplo:
La tasa de borrado de tramas, despues de la adaptaci6n, debera ser menor que X% (umbral absoluto).
La tasa de borrado de tramas, despues de la adaptaci6n, debera reducirse en Y% (umbral relativo).
Si los borrados de trama son consecutivos, entonces el objetivo debera ser reducir la cantidad de borrados de trama consecutivos.
La carga del sistema y los canales varfan hacia condiciones peores y retornan a condiciones mejores. De acuerdo con las realizaciones de la presente invenci6n, se necesita por lo tanto una soluci6n para adaptaci6n ascendente, ademas de la adaptaci6n descendente que se descrito anteriormente.
Si el cliente VoIP no tiene conocimiento de las condiciones radioelectricas, entonces el cliente VoIP no sabe si las condiciones del canal mejoran de tal modo que puedan ser enviados paquetes mayores. De acuerdo con las realizaciones de la presente invenci6n, esto se soluciona evaluando si es factible dicha posibilidad.
La evaluaci6n se obtiene mediante "sondear" una velocidad binaria superior. El sondeo se realiza de manera resistente, mediante mantener una velocidad de modo de c6dec reducida pero incluyendo mas tramas redundantes en los paquetes. A continuaci6n, el tamano del paquete aumentara hasta un tamano similar al tamano de los paquetes utilizados en el estado original.
Por ejemplo: si se utiliza AMR 122 en el estado normal, entonces el tamano de paquete RTP es tfpicamente de 32 octetos cuando se encapsula 1 trama por paquete. Si se ha realizado adaptaci6n descendente, a AMR 59 y una trama por paquete, entonces el tamano de paquete RTP es de 16 octetos. El sondeo se llevarfa a caboa continuaci6n encapsulando una nueva trama de voz (no redundante) y una trama de voz redundante en el paquete, de tal modo que se transmitan dos tramas en cada paquete. Entonces el tamano de paquete RTP pasa a 32 octetos.
En el diagrama de flujo de la figura 12 se ilustra un ejemplo de una soluci6n para "adaptaci6n ascendente":
1200. Se aplica un estado con una velocidad de modo de c6dec baja.
1201. Se detecta que se ha mejorado significativamente la tasa de perdida de paquetes (u otras metricas), es decir se ha mejorado el rendimiento.
1202. Se mantiene la velocidad de modo de c6dec baja, de tal modo que el tamano del paquete aumenta hasta el tamano normal.
1203. Si la tasa de perdida de paquetes sigue siendo baja, entonces se conmuta a la velocidad de modo de c6dec superior.
1204. Si la tasa de perdida de paquetes aumenta, entonces se vuelve al estado de velocidad de modo de c6dec baja.
Mediante el recurso de utilizar redundancia se puede evaluar si es posible una velocidad binaria superior continuando sin comprometer la calidad de la voz.
Puesto que los esquemas de adaptaci6n descendente son diferentes para sistemas diferentes, se prefiere por tanto evaluar cada uno de estos en un orden adecuado, tal como se muestra en esta secci6n. Este orden puede estar predeterminado, o puede ser dinamico y depender de las caracterfsticas de los errores de transmisi6n o de un objetivo que determina el rendimiento aceptable. Ejemplos de c6mo se decide el orden predeterminado en el que son evaluados los esquemas de transmisi6n especffico del sistema, son:
•
Decidido en la fase de diseno, es decir durante la implementaci6n.
•
Decidido por el operador, es decir cuando se construye la red.
•
Decidido en el establecimiento de llamada y mantenido a continuaci6n durante toda la sesi6n.
•
Decidido en el establecimiento de llamada pero modificado a otro orden predeterminado en el traspaso (o cambio de celda).
Asimismo, puede evaluarse el rendimiento del orden predeterminado. Por ejemplo, contando cuantas veces el primer esquema de adaptaci6n evaluado resulta ser el correcto a utilizar. Si casi nunca se permanece en este estado, esto constituye una indicaci6n de que el orden predeterminado no es apropiado y debe ser modificado.
Para conseguir la adaptaci6n es necesario intercambiar informaci6n entre el receptor y el transmisor, relativa a los esquemas de transmisi6n disponibles y al rendimiento resultante de los esquemas de transmisi6n. La informaci6n puede ser intercambiada utilizando senalizaci6n en banda o utilizando senalizaci6n fuera de banda. La senalizaci6n en banda implica que algunos bits (u octetos) de informaci6n son incorporados al flujo RTP (Real-time protocol, protocolo de tiempo real) desde el emisor al receptor. La senalizaci6n fuera de banda implica que la informaci6n es transmitida en paquetes separados, por ejemplo paquetes de protocolo RTCP (protocolo de control RTP) que son transmitidos en paralelo con los paquetes que contienen el medio.
En una realizaci6n de la invenci6n se utiliza la senalizaci6n en banda para este intercambio de informaci6n. Para este prop6sito, de acuerdo con realizaciones de la presente invenci6n se proponen diferentes mecanismos de senalizaci6n en banda. Esta senalizaci6n se especificara como peticiones, lo que significa que no existe obligaci6n por la parte de recepci6n de obedecer las peticiones. Por ejemplo, si el lado B de una sesi6n transmite alguna solicitud al lado A mediante senalizaci6n en banda, esta es una solicitud de que el lado A deberfa codificar y transmitir de una manera especffica el flujo RTP desde el lado A al lado B. El lado A no tiene por que cumplir las solicitudes, por ejemplo si el formato propuesto por la solicitud se estima inapropiado para el acceso especffico. No obstante, se espera que en la mayor parte de los casos se cumpla la solicitud, transmitiendo el medio exactamente como se espera o con un formato de transmisi6n que es similar al formato solicitado.
Corresponde al emisor de las solicitudes verificar que estas han sido atendidas y, asimismo, adoptar las acciones necesarias en base a la respuesta a las solicitudes.
Los mecanismos de senalizaci6n en banda que se utilizan en el ejemplo de la siguiente secci6n son:
CMR (codec mode request, solicitud de modo de c6dec): una solicitud que es enviada de una parte a otra con el prop6sito de aumentar o reducir la velocidad binaria de c6dec.
REO RED: una senalizaci6n en banda que se utiliza para solicitar transmisi6n redundante.
REO AGG: una senalizaci6n en banda que se utiliza para solicitar agregaci6n de tramas.
Ademas, puede llevarse a cabo senalizaci6n fuera de banda de la solicitud de adaptaci6n mediante la utilizaci6n de mensajes RTCP APP (Real time Control Protocol Application Specific Packets, paquetes especfficos de aplicaci6n del protocolo de control de tiempo real).
A continuaci6n se describira una implementaci6n a modo de ejemplo de la presente invenci6n. No obstante, debe entenderse a partir de la discusi6n anterior que existen tambien otros medios para implementar el esquema de adaptaci6n, que siguen estando dentro del alcance de la presente invenci6n.
El ejemplo descrito de implementaci6n de la presente invenci6n se describe en relaci6n con la figura 7, en la que se utilizan mecanismos de senalizaci6n en banda.
Debe observarse que las cifras de perdida de paquetes son solamente indicativas y se muestran solamente para facilitar la comprensi6n del concepto.
A continuaci6n se proporciona una descripci6n de los estados S1, S2, S2a, S2b, S3 y S4 mostrados en la figura 7.
S1: S1 es un estado por defecto: buenas condiciones de canal. En este caso se utiliza la velocidad de c6digo maxima y la velocidad de paquetes maxima.
S2: en este estado S2 se reducen la velocidad de c6dec y posiblemente tambien la velocidad de paquetes. Este estado esta dividido en 2 subestados (S2a y S2b). En el estado S2a se reduce la velocidad de c6dec. El estado S2b se reduce asimismo la velocidad paquetes. El estado S2a puede involucrar asimismo una reducci6n gradual de la velocidad de c6dec, y en su implementaci6n mas simple implica la reducci6n de la velocidad binaria en una cantidad importante, por ejemplo de AMR 12,2 a AMR 5,9.
S3: este es un estado provisional en el que se comprueban una velocidad binaria total superior y la misma velocidad de paquetes que en S1, para evaluar si es posible pasar despues a S1. Esto se consigue mediante un sondeo de redundancia, tal como se describe en relaci6n con la figura 12.
S4: en este estado se reduce la velocidad de c6dec y se activa la redundancia. Opcionalmente, asimismo la velocidad paquetes se mantiene igual que en el estado S2.
A continuaci6n se describen las posibles transiciones de estado realizadas utilizando CMR con mecanismo de senalizaci6n en banda. Debe observarse que preferentemente existe un retardo implfcito entre las transacciones de estado, con objeto de obtener estadfsticas fiables. Habitualmente, este retardado es del orden de 100 a 200 tramas. En este ejemplo se asume que la metrica utilizada para determinar la transici6n entre estados es la perdida de paquetes, pero es posible utilizar otras metricas, tales como metricas de canal de capa inferior. Asimismo, se mencionan algunos valores (5%, 2%, etc.), siendo estos solamente indicativos y estando incluidos unicamente para facilitar la lectura.
A continuaci6n se enumeran las posibles transiciones de estado y la senalizaci6n de solicitud de adaptaci6n (CMR, agregaci6n de tramas o redundancia) que este involucrada.
S1-S2a: la condici6n para la transici6n de S1 a S2a es que la perdida de paquetes sea mayor igual al 5% o que se detecten rafagas de perdida de paquetes.
Se reduce la velocidad de conexi6n (por ejemplo desde AMR 12,2 hasta AMR 5,9) mediante una CMR (solicitud de modo de c6dec).
S2a-S2b: la condici6n para la transici6n desde S2a hasta S2b es que la perdida de paquetes sea mayor o igual al 5%.
Esta transici6n de estado se produce si la perdida de paquetes sigue siendo elevada a pesar de la reducci6n en la velocidad de c6digo. La velocidad de c6digo se reduce por medio de REO AGG.
S2b-S2a: la condici6n para la transici6n desde S2b hasta S2a es que la perdida de paquetes sea menor que el 1%.
Esta transici6n de estado involucra un incremento en la velocidad de paquetes. Asimismo, se restablece la velocidad de paquetes al mismo valor que S1 por medio de REO AGG. Si se produce la transici6n de estado S2b-S2a-S2b, el estado sera bloqueado en S2b durante algun tiempo, debiendo este tiempo ser un valor aleatorio comprendido en [Td1...Td2], con objeto de evitar un comportamiento oscilatorio a gran escala.
S2a-S3: la condici6n para la transici6n desde S2a a S3 es que la perdida de paquetes sea menor que el 1%. Se activa la redundancia (100%) mediante la solicitud de adaptaci6n REO RED. Asimismo, por medio de REO AGG se restablece la velocidad de paquetes al mismo valor que en el estado S1.
S3-S2a: la condici6n para la transici6n de S3 a S2a es que la perdida de paquetes sea mayor igual al 2% o que se detecten rafagas de perdida de paquetes.
Deberan llevarse a cabo las mismas acciones que en la transici6n S1-S2a. Si se produce la transici6n S2a-S3-S2a-S3-S2a, el estado S3 es deshabitado durante algun tiempo, debiendo ser este tiempo un valor haber aleatorio dentro del valor [Td1...Td2], para evitar un comportamiento oscilatorio a gran escala.
S3-S1: la condici6n para la transici6n desde S3 hasta S1 es que la perdida de paquetes sea menor que el 2% y que no se detecten rafagas de perdida de paquetes.
La redundancia es desactivada mediante la solicitud de adaptaci6n REO RED. La tasa de c6digo aumenta mediante CMR.
S2b-S4: la condici6n para la transici6n desde S1 hasta S2a es que la perdida de paquetes sea mayor o igual que el 2%.
Se activa la redundancia (100%) mediante la solicitud de adaptaci6n REO RED. Asimismo, se restablece la velocidad de paquetes al mismo valor que S1 por medio de REO AGG.
S4-S2: la condici6n para la transici6n desde S4 hasta S2 es que la perdida de paquetes sea mayor o igual que el 10%. Esto es indicativo de que la velocidad binaria total es demasiado elevada.
La redundancia se desactiva mediante una solicitud de adaptaci6n REO RED. El estado S4 se deshabilita durante algun tiempo, debiendo estar este tiempo en un valor aleatorio comprendido en el valor [Td1...Td2], para evitar un comportamiento oscilatorio a gran escala.
S4-S1: la condici6n para la transici6n desde S4 hasta S1 es que la perdida de paquetes sea menor que el 1%.
La redundancia se desactiva mediante una solicitud de adaptaci6n REO RED. La tasa de c6digo aumenta mediante CMR.
S1-S4: la condici6n para la transici6n desde S1 hasta S4 es que la perdida de paquetes sea mayor igual que el 5% o que se detecten rafagas de perdida de paquetes Y (AND) que la transici6n anterior haya sido S4-S1, de lo contrario se llevara a cabo la transici6n S1-S2a.
Se activa la redundancia (100%) mediante la solicitud de adaptaci6n REO RED. La velocidad de c6digo se reduce (en el ejemplo, desde AMR 12,2 hasta AMR 5,9) por medio de una CMR.
Una manera tfpica de implementar la presente invenci6n es tener un control de adaptaci6n en el receptor, tal como se muestra en la figura 8.
El medio 801 entra en el transmisor 805, que codifica el medio a un medio codificado 810 mediante el codificador
811. El medio codificado es transmitido sobre una red 803 al receptor 804, que descodifica el medio. En este caso, el receptor 804 comprende un analizador 810 del rendimiento del medio, que esta adaptado para evaluar el rendimiento del medio recibido, y un controlador 806 de adaptaci6n que esta adaptado para evaluar el rendimiento del medio recibido en base a uno o varios objetivos 814 y para determinar c6mo adaptar, es decir seleccionar, un formato de transmisi6n adecuado. El receptor comprende ademas un descodificador 812 de medios y una unidad 818 de almacenamiento adaptada para almacenar informaci6n de los formatos de transmisi6n que ya han sido evaluados.
Comprende por lo tanto un medio de salida 816 para enviar un mensaje 807 de solicitud de adaptaci6n, tal como CMR, REO RED o REO AGG al transmisor/codificador 805/811, los cuales comprenden entonces preferentemente una unidad 808 que almacena los formatos de transmisi6n disponibles, que esta configurada para cambiar el formato de transmisi6n de la codificaci6n y la paquetizaci6n del medio.
No obstante, es posible asimismo implementar el control de adaptaci6n en el transmisor, tal como se muestra en la figura 9. Tal como en la implementaci6n de la figura 8, el medio 801 entra en el transmisor 805, que codifica el medio en un medio codificado 802. El medio codificado es transmitido sobre una red 803 al receptor 804 que descodifica el medio.
En este caso, el receptor 804 comprende un descodificador 812, y un analizador 810 del rendimiento del medio, que esta configurado para medir metricas de rendimiento tales como: tasa de perdida de paquetes; metricas de rafagas de perdida de paquetes, tasa de borrado de tramas, variaci6n del retardo; etc. A continuaci6n, estas metricas 815 son transmitidas al transmisor/codificador 805/811 mediante un medio 816 de salida con un canal de retorno al transmisor/codificador 805/811, de tal modo que el control 806 de adaptaci6n implementado en el transmisor puede seleccionar un formato de transmisi6n adecuado en base a la metrica de rendimiento recibida y al objetivo 814. Ademas, el receptor comprende una unidad 818 de almacenamiento adaptada para almacenar informaci6n de los formatos de transmisi6n que ya han sido evaluados.
La implementaci6n del control de adaptaci6n en el receptor tiene como resultado que las solicitudes de adaptaci6n de senalizaci6n requieren habitualmente menos bits que las metricas de senalizaci6n. Dado el mismo ancho de banda permitido para la senalizaci6n de adaptaci6n, es posible enviar senales de solicitud de adaptaci6n mas frecuentemente que con la implementaci6n del control de adaptaci6n en el transmisor.
En la figura 10 se muestra una arquitectura de receptor mas detallada para el caso en el que se implementa control de adaptaci6n en el receptor. El receptor 804 de la figura 10 comprende un analizador 810 del rendimiento del medio, un controlador 806 de adaptaci6n, uno o varios objetivos 814 y un descodificador 812 del medio. El analizador 810 del rendimiento del medio analiza una metrica 815 de rendimiento del medio codificado transmitido
802. La metrica 815 del rendimiento es enviada al controlador 806 de adaptaci6n, que esta configurado para determinar si la metrica de rendimiento satisface un objetivo predeterminado 814. Inicialmente, el objetivo es un objetivo 813 por defecto, pero puede ser modificado en base a la metrica de rendimiento. Si la metrica o metricas de rendimiento no satisfacen el objetivo predeterminado, se envfa mediante el medio 816 de salida una solicitud 807 de adaptaci6n al transmisor 805 para solicitar un nuevo formato de transmisi6n. El descodificador 812 del medio descodifica el medio codificado recibido, entregando el medio descodificado 801. Tal como se ha indicado anteriormente, el receptor puede comprender asimismo una unidad 818 de almacenamiento, adaptada para almacenar informaci6n de los formatos de transmisi6n que ya han sido evaluados. No obstante, dicha unidad no se muestra en la figura 10.
Tal como se ha indicado anteriormente, una realizaci6n de la presente invenci6n proporciona una adaptaci6n ascendente. Por lo tanto, de acuerdo con esta realizaci6n el analizador 810 del rendimiento esta configurado para
detectar que ha mejorado significativamente una metrica del rendimiento. El controlador 806 de adaptaci6n esta configurado para seleccionar un formato de transmisi6n que proporciona redundancia anadida a la transmisi6n, de tal modo que aumenta el tamano de los paquetes hasta el tamano normal, si la metrica del rendimiento sigue indicando buena calidad, entonces el controlador 806 de adaptaci6n esta configurado para solicitar una velocidad binaria de c6dec fuente superior y un formato de transmisi6n menos resistente, o si la metrica del rendimiento indica una calidad reducida, entonces el controlador 806 de adaptaci6n esta configurado para seleccionar el formato de transmisi6n anterior. En este caso, el control de adaptaci6n puede implementarse en el transmisor y en el receptor.
El receptor 804 puede implementarse en un terminal m6vil y el transmisor 805 puede implementarse en una pasarela de medios, tal como se muestra en la figura 10, y/o el receptor 804 puede implementarse en una pasarela de medios y el transmisor 805 puede implementarse en un terminal m6vil.
En la figura 11 se muestra un ejemplo de diagrama de flujo de la funcionalidad cuando se implementa control de adaptaci6n en el receptor. Este diagrama de flujo muestra solamente el retroceso o adaptaci6n descendente hacia esquemas que cargan menos el sistema y/o proporcionan mas resistencia contra perdidas. El sondeo de velocidades binarias superiores se ha mostrado anteriormente en la figura 12.
Etapa 1101. El medio codificado es formateado de acuerdo con el esquema normal o de acuerdo con una solicitud de adaptaci6n precedente.
Etapa 1102. Se selecciona un conjunto de metricas, una o varias metricas. Estas metricas del rendimiento se corresponden preferentemente con el formato de transmisi6n seleccionado. Debe observarse que esta etapa es opcional. Si la metrica o metricas del rendimiento que se utilizan son neutrales con respecto al formato de transmisi6n, por ejemplo la tasa de borrado de tramas (FER, frame erasure rate), entonces es posible utilizar la misma metrica o metricas para todos los formatos de transmisi6n. Por otra parte, si se seleccionan metricas que no son neutrales, por ejemplo la tasa de perdida de paquetes (PLR), entonces es necesario modificar la metrica o metricas o por lo menos los objetivos para las metricas.
Etapa 1103. El rendimiento del medio recibido es monitorizado y comparado con los objetivos para las metricas del rendimiento. Habitualmente, las metricas del rendimiento estan basadas en el medio recibido, tal como:
�
Tasa de perdida de paquetes (PLR)
�
Metricas de rafagas de perdida de paquetes, por ejemplo: numero (o porcentaje) de perdidas dobles (dos perdidas en una fila); numero (o porcentaje) de perdidas triples (tres perdidas en una fila); etc.. Las metricas de rafagas de perdida de paquetes pueden incluir asimismo metricas para la distancia entre rafagas de perdidas de paquetes.
�
Variaci6n del retardo
�
Tasa de borrado de tramas (FER) basada en perdidas de paquetes.
�
Gran cantidad de borrados de tramas consecutivos.
�
Mediciones de la calidad del canal, por ejemplo las mediciones COI que se utilizan en HSDPA.
�
Estimaciones sobre la calidad del medio actual (por ejemplo, utilizando la evaluaci6n de la calidad de la senal de voz sintetizada (o generada)).
�
BER en bloques de transmisi6n.
Si se utiliza mas de un medio en el servicio, pueden utilizarse metricas combinadas. Por ejemplo, si se utiliza voz y video en un servicio de comunicaciones multimedia, las metricas PLR/variaci6n/COI/evaluaci6n de la calidad de la senal de voz sintetizada (o generada) consideradas para la voz pueden utilizarse para adaptar el video (debido a que la voz se considera mas importante para este servicio y contexto especfficos).
Etapas 1104-1105. Se utilizara preferentemente el formato de transmisi6n seleccionado siempre que el rendimiento exceda el objetivo de rendimiento. Si el rendimiento se degrada, lo cual se detecta cuando la metrica o metricas del rendimiento estan por debajo del objetivo u objetivos, entonces el esquema de adaptaci6n determina que se debe intentar otro formato de transmisi6n.
Etapa 1106. Se selecciona un nuevo formato de transmisi6n a partir de la lista de formatos de transmisi6n. La selecci6n del formato de transmisi6n puede, o no, ser una hip6tesis inteligente. Algunos formatos pueden estar disenados especfficamente para tratar algunos problemas de transporte concretos, por ejemplo muchas perdidas consecutivas. Si se detecta esto, y si el formato de transmisi6n adecuado no es el formato siguiente en la lista, entonces la adaptaci6n puede omitir los formatos intermedios y saltar directamente al formato que esta disenado para tratar el problema de transporte especffico.
Etapa 1107. Para cambiar el formato de transmisi6n, el receptor/descodificador tiene que senalizar una solicitud de adaptaci6n al transmisor/codificador, el cual a continuaci6n reconfigura la transmisi6n para adaptarse al formato solicitado.
Puede ser necesario seleccionar nuevas metricas de rendimiento que son adecuadas para el nuevo formato de transmisi6n. La necesidad de seleccionar nuevas metricas depende de las metricas que se utilicen, por ejemplo:
La tasa de borrado de tramas (FER) es habitualmente una buena aproximaci6n de la calidad. Al mismo tiempo, la FER es asimismo independiente de c6mo esta paquetizado en medio en los paquetes RTP.
Cuando se utiliza la tasa de perdida de paquetes (PLR), es necesario recordar que la FER depende de c6mo esta paquetizado el medio en los paquetes RTP. Si se envfa 1 trama por paquete, entonces FER = PLR. Si se envfan 2 tramas por paquete, sin redundancia, entonces FER = 2 � PLR. Si se utiliza redundancia, entonces la FER es mucho menor que la PLR (dependiendo de la cantidad de redundancia y de la distribuci6n de la perdida de paquetes).
Etapa 1108. El proceso prosigue hasta la finalizaci6n de la llamada.
La adaptaci6n ascendente, hacia velocidades binarias superiores y menos resistencia, es similar excepto en lo siguiente.
Las metricas de rendimiento que se seleccionan para el esquema definen un umbral de rendimiento superior en lugar de un umbral de rendimiento inferior. Normalmente no debera superarse el umbral superior salvo que las condiciones de funcionamiento sean mejores que las condiciones para cuyo tratamiento esta disenado el formato de transmisi6n utilizado. Si se excede el umbral superior, entonces la adaptaci6n selecciona un nuevo esquema de transmisi6n que carga mas el sistema.
En primer lugar, se intenta cargar mas el sistema mediante el recurso de aumentar la redundancia, denominado sondeo de redundancia. Este esquema esta disenado especfficamente para cargar mas el sistema, en la misma cantidad que el esquema al que se hara finalmente la adaptaci6n si todo funciona bien, mientras que sigue siendo resistente a tasas de perdida superiores que pueden producirse debido a la carga superior.
Si este sondeo de redundancia funciona bien, entonces se conmuta al esquema que proporciona mejor calidad, siempre que las tasas de perdida de paquetes sean bajas, incluso aunque se reduzca la resistencia.
Debe observarse que, en este caso, las metricas de rendimiento que se utilizan son las que se corresponden con el formato de transmisi6n al que se conmutara, no las que se corresponden con el formato del sondeo de redundancia.
Debe entenderse que la implementaci6n dada a conocer anteriormente es solamente un ejemplo de una variedad de posibles implementaciones de la presente invenci6n. El medio puede ser video o audio, ademas de voz (= habla). Ademas, los formatos de transmisi6n dados a conocer son solamente ejemplos. Otros sistemas pueden funcionar mejor con otros tipos de formatos de transmisi6n.
La presente invenci6n no se limita a las realizaciones preferidas descritas anteriormente. Pueden utilizarse diversas alternativas, modificaciones y equivalentes. Por lo tanto, las realizaciones anteriores no deben tomarse como limitativas del alcance de la invenci6n, la cual se define mediante las reivindicaciones anexas.

Claims (31)

  1. REIVINDICACIONES
    1. Un metodo para adaptar a diferentes condiciones de funcionamiento la transmisi6n de contenido multimedia codificado (802) en una red de conmutaci6n de paquetes, donde estan disponibles una serie de formatos (808) de transmisi6n, en el que cada formato (808) de transmisi6n define una combinaci6n de por lo menos dos
    5 caracterfsticas; comprendiendo dicho metodo las etapas de:
    recibir (1105) informaci6n acerca de si la metrica de rendimiento del contenido multimedia codificado (802) transmitido satisface un objetivo predeterminado (814), si la metrica de rendimiento del contenido multimedia codificado (802) transmitido no satisface el objetivo predeterminado (814);
    seleccionar (1106) otro formato (808) de transmisi6n entre los formatos (808) de transmisi6n disponibles, hasta 10 que la metrica de rendimiento del contenido multimedia codificado (802) transmitido satisfaga el objetivo predeterminado,
    caracterizado por�que dichas caracterfsticas son combinadas entre las de agregaci6n de tramas, velocidad binaria de codificaci6n fuente y redundancia.
  2. 2. El metodo acorde con la reivindicaci6n 1, en el que la metrica de rendimiento depende de los parametros 15 definidos mediante el formato (808) de transmisi6n seleccionado.
  3. 3.
    El metodo acorde con cualquiera de las reivindicaciones 1 6 2, en el que la redundancia de parametros comprende una redundancia con desplazamiento.
  4. 4.
    El metodo acorde con cualquiera de las reivindicaciones anteriores, en el que si ninguna de las metricas de
    rendimiento de los formatos (808) de transmisi6n disponibles satisface el objetivo predeterminado (814) se 20 selecciona un formato de transmisi6n de reserva predeterminado.
  5. 5. El metodo acorde con cualquiera de las reivindicaciones 1 a 3, en el que el metodo comprende ademas las etapas de:
    -
    detectar (1201) que se ha mejorado significativamente una metrica de rendimiento,
    -
    seleccionar (1202) redundancia anadida para la transmisi6n, de tal modo que el tamano de los paquetes 25 aumente hasta el tamano normal, si la metrica de rendimiento sigue indicando buena calidad, entonces
    -
    seleccionar (1204) un formato de transmisi6n menos resistente, o si la metrica indica una calidad reducida, entonces
    -
    volver (1200) al formato de transmisi6n anterior.
  6. 6. El metodo acorde con cualquiera de las reivindicaciones 1 a 5, en el que el metodo es implementado en un 30 receptor (804).
  7. 7. El metodo acorde con la reivindicaci6n 6, en el que la informaci6n sobre si una metrica de rendimiento del contenido multimedia codificado (802) transmitido satisface el objetivo predeterminado (814) es obtenida mediante:
    -
    analizar el rendimiento del contenido multimedia codificado (802) transmitido, cuando se esta utilizando un primer formato (808) de transmisi6n seleccionado, y el metodo comprende la etapa adicional de solicitar al 35 transmisor (805) el otro formato (808) de transmisi6n seleccionado entre los formatos (808) de transmisi6n disponibles.
  8. 8. El metodo acorde con la reivindicaci6n 7, en el que la etapa de solicitar el otro formato (808) de transmisi6n seleccionado se lleva a cabo enviando al transmisor (805) una solicitud (807) de adaptaci6n utilizando senalizaci6n en banda.
    40 9. El metodo acorde con la reivindicaci6n 7, en el que la etapa de solicitar el otro formato (808) de transmisi6n seleccionado se lleva a cabo enviando al transmisor (805) una solicitud (807) de adaptaci6n utilizando senalizaci6n fuera de banda.
  9. 10. El metodo acorde con cualquiera de las reivindicaciones 6 a 9, en el que el receptor (804) esta situado en un terminal.
    45 11. El metodo acorde con cualquiera de las reivindicaciones 6 a 9, en el que el receptor (804) esta situado en una pasarela de medios.
  10. 12. El metodo acorde con cualquiera de las reivindicaciones 1 a 5, en el que el metodo es implementado en un transmisor (804).
  11. 13.
    El metodo acorde con la reivindicaci6n 12, en el que el metodo comprende ademas la etapa de aplicar a la transmisi6n del contenido multimedia codificado (802) el formato (808) de transmisi6n seleccionado.
  12. 14.
    El metodo acorde con cualquiera de las reivindicaciones 12 a 13, en el que la etapa de seleccionar otro formato
    (808) de transmisi6n se lleva a cabo mediante la recepci6n de retroalimentaci6n (815) del rendimiento desde el receptor (804) mediante senalizaci6n en banda.
  13. 15. El metodo acorde con cualquiera de las reivindicaciones 12 a 13, en el que la etapa de seleccionar otro formato
    (808) de transmisi6n se lleva a cabo mediante la recepci6n de retroalimentaci6n (815) del rendimiento desde el receptor (804) mediante senalizaci6n fuera de banda.
  14. 16.
    El metodo acorde con cualquiera de las reivindicaciones 12 a 15, en el que el transmisor (805) esta situado en un terminal.
  15. 17.
    El metodo acorde con cualquiera de las reivindicaciones 12 a 15, en el que el transmisor (805) esta situado en una pasarela de medios.
  16. 18.
    Una disposici6n para adaptar a diferentes condiciones de funcionamiento la transmisi6n decontenido multimedia codificado (802) en una red de conmutaci6n de paquetes, en donde estan disponibles una serie de formatos (808) de transmisi6n, en el que cada formato (808) de transmisi6n define una combinaci6n de por lo menos dos caracterfsticas; y la disposici6n comprende:
    un controlador (806) de adaptaci6n configurado para recibir informaci6n sobre si una metrica de rendimiento del contenido multimedia codificado (802) transmitido satisface un objetivo predeterminado (814), y para evaluar el rendimiento del contenido multimedia recibido en funci6n del objetivo predeterminado (814), y para seleccionar otro formato (808) de transmisi6n si la metrica de rendimiento del contenido multimedia codificado (802) transmitido no satisface el objetivo predeterminado (814),
    caracterizado por que dichas caracterfsticas son combinadas entre las de agregaci6n de tramas, velocidad binaria de codificaci6n fuente y redundancia.
  17. 19.
    La disposici6n acorde con la reivindicaci6n 18, en la que la metrica de rendimiento depende de los parametros definidos mediante el formato (808) de transmisi6n seleccionado.
  18. 20.
    La disposici6n acorde con cualquiera de las reivindicaciones 18 a 19, en la que la redundancia de parametros comprende una redundancia con desplazamiento.
  19. 21.
    La disposici6n acorde con cualquiera de las reivindicaciones anteriores 18 a 20, en la que el controlador (806) de adaptaci6n esta configurado para seleccionar un formato de transmisi6n de reserva predeterminado, si ninguna de las metricas de transmisi6n de los formatos (808) de transmisi6n disponibles satisface el objetivo predeterminado (814).
  20. 22.
    La disposici6n acorde con cualquiera de las reivindicaciones 18 a 21, en la que el analizador (810) del rendimiento esta configurado para detectar que una metrica de rendimiento ha sido mejorada significativamente,
    el controlador (806) de adaptaci6n esta configurado para seleccionar un formato (808) de transmisi6n que proporciona redundancia anadida a la transmisi6n, de tal modo que el tamano de los paquetes aumenta hasta el tamano normal, si la metrica de rendimiento sigue indicando una buena calidad, entonces
    el controlador (806) de adaptaci6n esta configurado para solicitar un formato (808) de transmisi6n menos resistente,
    o si la metrica de rendimiento indica una calidad reducida, entonces el controlador (806) de adaptaci6n esta configurado para solicitar seleccionar el formato (808) de transmisi6n anterior.
  21. 23.
    La disposici6n acorde con cualquiera de las reivindicaciones 18 a 22, en la que la disposici6n esta implementada en un receptor (804).
  22. 24.
    La disposici6n acorde con la reivindicaci6n 18, en la que el analizador (819) de medios esta configurado para analizar el rendimiento del contenido multimedia codificado transmitido, cuando se esta utilizando un primer formato
    (808) de transmisi6n seleccionado y la disposici6n comprende medios (806) de salida configurados para solicitar el otro formato (808) de transmisi6n seleccionado.
  23. 25.
    La disposici6n acorde con la reivindicaci6n 24, en la que el medio (816) de salida esta configurado para solicitar otro formato (808) de transmisi6n mediante enviar al transmisor (805) una solicitud (807) de adaptaci6n utilizando senalizaci6n en banda.
  24. 26.
    La disposici6n acorde con la reivindicaci6n 24, en la que el medio (816) de salida esta configurado para solicitar otro formato (808) de transmisi6n mediante enviar al transmisor una solicitud (807) de adaptaci6n utilizando senalizaci6n fuera de banda.
  25. 27.
    La disposici6n acorde con cualquiera de las reivindicaciones 23 a 26, en la que el receptor (804) esta situado en un terminal.
  26. 28.
    La disposici6n acorde con cualquiera de las reivindicaciones 23 a 26, en la que el receptor (804) esta situado en una pasarela de medios.
    5 29. La disposici6n acorde con cualquiera de las reivindicaciones 18 a 22, en la que la disposici6n esta implementada en un transmisor.
  27. 30. La disposici6n acorde con la reivindicaci6n 29, en la que el controlador (806) de adaptaci6n esta configurado para recibir un analisis del rendimiento del contenido multimedia codificado transmitido, cuando se esta utilizando un primer formato (808) de transmisi6n seleccionado, y en la que el controlador (806) de adaptaci6n esta configurado
    10 para aplicar a la transmisi6n del contenido multimedia codificado (802) el formato (808) de transmisi6n seleccionado.
  28. 31.
    La disposici6n acorde con cualquiera de las reivindicaciones 29 a 30, en la que el controlador (806) de adaptaci6n esta configurado para recibir desde el receptor (804) retroalimentaci6n (815) del rendimiento mediante senalizaci6n en banda.
  29. 32.
    La disposici6n acorde con cualquiera de las reivindicaciones 29 a 30, en la que el controlador (806) de
    15 adaptaci6n esta configurado para recibir desde el receptor (804) retroalimentaci6n (815) del rendimiento mediante senalizaci6n fuera de banda.
  30. 33. La disposici6n acorde con cualquiera de las reivindicaciones 29 a 33, en la que el transmisor (805) esta situado en un terminal.
  31. 34. La disposici6n acorde con cualquiera de las reivindicaciones 29 a 33, en la que el transmisor (805) esta situado 20 en una pasarela de medios.
ES07748525T 2006-08-21 2007-05-28 Método y disposición para adaptar la transmisión de medios codificados Active ES2386476T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US83888506P 2006-08-21 2006-08-21
US838885P 2006-08-21
PCT/SE2007/050364 WO2008024056A1 (en) 2006-08-21 2007-05-28 Method and arrangement for adapting transmission of encoded media

Publications (1)

Publication Number Publication Date
ES2386476T3 true ES2386476T3 (es) 2012-08-21

Family

ID=39107057

Family Applications (1)

Application Number Title Priority Date Filing Date
ES07748525T Active ES2386476T3 (es) 2006-08-21 2007-05-28 Método y disposición para adaptar la transmisión de medios codificados

Country Status (7)

Country Link
US (1) US8422382B2 (es)
EP (1) EP2055036B1 (es)
KR (1) KR101419959B1 (es)
CN (1) CN101507164B (es)
BR (1) BRPI0715131B1 (es)
ES (1) ES2386476T3 (es)
WO (1) WO2008024056A1 (es)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8811335B2 (en) * 2007-04-20 2014-08-19 Qualcomm Incorporated Method and apparatus for dynamic adjustment of uplink transmission time
US8913672B2 (en) 2008-09-12 2014-12-16 Qualcomm Incorporated Efficiently identifying system waveform in uplink transmission
KR101523590B1 (ko) * 2009-01-09 2015-05-29 한국전자통신연구원 통합 인터넷 프로토콜망의 코덱 모드 제어방법 및 단말기
EP2394460B1 (en) * 2009-02-05 2019-06-26 Samsung Electronics Co., Ltd. Communication system and method for media adaptation therein
JP2011055286A (ja) * 2009-09-02 2011-03-17 Toshiba Corp 映像配信装置および映像配信方法
BR112013011977A2 (pt) 2010-12-03 2016-08-30 Ericsson Telefon Ab L M agregação de quadro adaptável de sinal de fonte
US10951743B2 (en) * 2011-02-04 2021-03-16 Adaptiv Networks Inc. Methods for achieving target loss ratio
US9338580B2 (en) * 2011-10-21 2016-05-10 Qualcomm Incorporated Method and apparatus for packet loss rate-based codec adaptation
KR101930057B1 (ko) * 2011-10-28 2018-12-17 한국전자통신연구원 통신 시스템에서 데이터 송수신 장치 및 방법
US9280413B2 (en) 2013-12-12 2016-03-08 Talkatone, Llc Redundant encoding
US9844074B2 (en) * 2014-07-31 2017-12-12 Telefonaktiebolaget Lm Ericsson (Publ) Maximizing channel capacity for common downlink channels
WO2016185649A1 (ja) * 2015-05-20 2016-11-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信ノード、端末及び通信制御方法
KR102656013B1 (ko) * 2016-10-28 2024-04-11 삼성전자주식회사 컨텐츠 출력 장치 및 그 제어 방법
FR3071997A1 (fr) * 2017-10-02 2019-04-05 Orange Signalisation d’une requete d’adaptation d’une session de communication en voixsur ip
FR3082386A1 (fr) * 2018-06-08 2019-12-13 Orange Adaptation de debit d'une session de communication en voix sur ip
CN110149452A (zh) * 2019-03-27 2019-08-20 杭州叙简科技股份有限公司 一种降低网络丢包率提升通话声音效果的方法
EP4123610A1 (en) * 2021-07-20 2023-01-25 Tunstall Integrated Health & Care Limited Social alarm system

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5490168A (en) * 1994-07-08 1996-02-06 Motorola, Inc. Method and system for automatic optimization of data throughput using variable packet length and code parameters
US5671253A (en) * 1995-07-12 1997-09-23 Thomson Consumer Electronics, Inc. Apparatus for demodulating and decoding video signals encoded in different formats
US6154489A (en) * 1998-03-30 2000-11-28 Motorola, Inc. Adaptive-rate coded digital image transmission
DE19846721B4 (de) * 1998-10-12 2009-09-10 Ipcom Gmbh & Co. Kg Verfahren zur Kodierung und Dekodierung und Vorrichtung zum Kodieren oder Dekodieren
AU3467900A (en) * 1999-02-26 2000-09-14 Telefonaktiebolaget Lm Ericsson (Publ) Adaptive header compression for packet communications
GB2349042B (en) * 1999-04-12 2003-07-23 Motorola Ltd A communication apparatus and method of format adaptation therfor
US6584190B1 (en) * 1999-09-07 2003-06-24 Nortel Networks Limited Communications of telephony control signaling over data networks
US7319701B2 (en) * 2000-12-29 2008-01-15 Texas Instruments Incorporated Modem relay protocol redundancy for reliable low speed modem communications over IP networks with substantial packet loss
GB2391431A (en) * 2002-07-30 2004-02-04 Fujitsu Ltd Adaptive modulation and coding method
US7295549B2 (en) * 2003-02-14 2007-11-13 Ntt Docomo, Inc. Source and channel rate adaptation for VoIP
WO2004114549A1 (en) * 2003-06-13 2004-12-29 Nokia Corporation Enhanced data only code division multiple access (cdma) system
WO2005050875A1 (en) 2003-11-19 2005-06-02 Samsung Electronics Co., Ltd. Apparatus and method for transmitting and receiving common control information in a wireless communication system
US7689162B2 (en) * 2005-10-28 2010-03-30 Viasat, Inc. Adaptive coding and modulation flow control and traffic shaping systems and methods
US20070147314A1 (en) * 2005-12-22 2007-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Network processing node and method for manipulating packets

Also Published As

Publication number Publication date
WO2008024056A1 (en) 2008-02-28
BRPI0715131B1 (pt) 2019-11-05
KR20090071543A (ko) 2009-07-01
EP2055036A1 (en) 2009-05-06
US20100232297A1 (en) 2010-09-16
CN101507164B (zh) 2012-10-10
CN101507164A (zh) 2009-08-12
EP2055036B1 (en) 2012-05-23
US8422382B2 (en) 2013-04-16
KR101419959B1 (ko) 2014-07-16
BRPI0715131A2 (pt) 2012-12-25
EP2055036A4 (en) 2010-06-02

Similar Documents

Publication Publication Date Title
ES2386476T3 (es) Método y disposición para adaptar la transmisión de medios codificados
RU2404523C2 (ru) УЛУЧШЕННОЕ КАЧЕСТВО ПОТОКА МЕДИАДАННЫХ VoIP ПОСРЕДСТВОМ АДАПТАЦИИ КОДИРОВАНИЯ РЕЧИ НА ОСНОВЕ ВЫБРАННОЙ СХЕМЫ МОДУЛЯЦИИ И КОДИРОВАНИЯ (MCS)
US9306852B2 (en) Coding and packet distribution for alternative network paths in telecommunications networks
ES2378592T3 (es) Control de velocidad adaptativo en un sistema de telecomunicaciones
FI105734B (fi) Automaattinen uudelleenlähetys
CN102118357B (zh) 一种流媒体处理方法、设备和系统
EP2218204B1 (en) Method and system for data transmission in a data network
US20080031176A1 (en) Radio Communications Gateway And Radio Communications Terminal
JP5956348B2 (ja) 可変レート・ボコーダを利用するユーザ機器のためのボイスオーバｉｐ容量を改善する方法
CN100493223C (zh) 自适应多速率分组语音编码模式调整方法及基站控制器
BRPI0617710A2 (pt) método e sistema para codificação adaptativa de informação em tempo real em redes sem fio
KR100723822B1 (ko) 통신 유형에 기초한 무선 인터페이스의 전송 파라미터들의 최적화
ES2264363B2 (es) Metodos y disposiciones en aplicaciones relacionadas con un sistema de telecomunicaciones.
WO2000072496A1 (en) Adaptive joint-detection cdma video transceiver
JP5349447B2 (ja) 無線通信システム
CN107404363B (zh) 一种语音码率的调整方法、系统、终端和网络侧设备
RU2295838C2 (ru) Способ передачи пакетных данных
US8300601B2 (en) System and method for implementing effective channel quality indication
JP2012114584A (ja) 無線通信システム
Kapoor et al. Link layer support for streaming MPEG video over wireless links
AU4446199A (en) A method of changing the encoding level of digital data transmitted between a transmitter and a receiver at constant rate
JP4847543B2 (ja) メディアフレームの耐性のある表現形を使用してメディア伝送品質を改善する方法および装置
WO2006135250A2 (en) Method for down-speeding in an ip communication network
Fabri et al. Provision of streaming media services over mobile networks
Huang et al. Adaptive forward error correction with cognitive technology mechanism for video streaming over wireless networks