ES2378592T3

ES2378592T3 - Control de velocidad adaptativo en un sistema de telecomunicaciones

Info

Publication number: ES2378592T3
Application number: ES08779430T
Authority: ES
Inventors: Stefan WÄNSTEDT; Daniel ENSTRÖM; Ghyslain Pelletier
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2007-07-09
Filing date: 2008-07-09
Publication date: 2012-04-16
Anticipated expiration: 2028-07-09
Also published as: DK2165481T3; JP5284355B2; EP2165481B1; EP2165481A4; WO2009008829A1; US8942243B2; ATE539528T1; US20100195521A1; BRPI0813927A2; US8625608B2; CA2698344C; US20140105026A1; CA2698344A1; JP2010533419A; BRPI0813927B1; CN101743725A; EP2165481A1; CN101743725B; PL2165481T3

Abstract

Un método para controlar una velocidad binaria de una sesión entre un emisor (1200) y un receptor (1210) en un sistema de comunicaciones de paquetes conmutados donde se establecen múltiples sesiones a través de un recurso compartido (1220), dicho método que comprende los pasos de: determinar (1010, 1225) una gama de velocidad binaria válida para la sesión, la gama de velocidad binaria que tiene un límite superior y un límite inferior; recibir (1090, 1250) un mensaje de petición de adaptación de la velocidad desde el receptor; comparar una velocidad binaria actual de dicha sesión con dicha gama de velocidad binaria; en el que el método se caracteriza porque comprende los pasos de: adaptar (1094, 1260) dicha velocidad binaria actual de manera que la velocidad binaria actual se reduce más si está más cerca del límite superior de la gama de velocidad binaria que si está más cerca del límite inferior de la gama de velocidad binaria o de manera que la velocidad binaria actual se aumenta más si está más cerca del límite inferior de la gama de velocidad binaria que si está más cerca del límite superior de la gama de velocidad binaria.

Description

Control de velocidad adaptativo en un sistema de telecomunicaciones

Campo tecnico

La presente invenci6n se refiere a los metodos y adaptaciones para el control de la velocidad en los sistemas de 5 comunicaciones digitales

Antecedentes

En un sistema de comunicaciones de paquetes conmutados digital diferentes tipos de trafico, por ejemplo voz, datos, audio y video, se puede transportar entre multiples partes a traves de recursos compartidos, por ejemplo encaminadores y canales de transmisi6n. Algun trafico, tal como muchas aplicaciones de audio y video, tipicamente

10 ocurre en tiempo real, mientras que otro trafico, tal como muchas aplicaciones de datos, tipicamente es trafico no en tiempo real.

En tal sistema un emisor es una aplicaci6n o entidad que codifica y envia los medios, que se han recibido desde una parte remitente, a un receptor. Un receptor es una aplicaci6n o entidad que recibe, descodifica y presenta los medios a una parte de recepci6n. Una aplicaci6n, que actua como un emisor o como un receptor o ambos, se puede situar 15 en un cliente o en un servidor, por ejemplo en el equipo de usuario u otros componentes fisicos de una parte de envio o una de recepci6n. Una aplicaci6n se puede ejecutar en un cliente o en un servidor para proporcionar o entregar un servicio, por ejemplo a un usuario u otra parte. Mas concretamente, una aplicaci6n se puede ejecutar en un servidor para codificar y enviar los medios a un cliente, donde se esta ejecutando una aplicaci6n para recibir, descodificar y presentar los medios a un usuario, por el cual las aplicaciones que se ejecutan en el servidor y en el

20 cliente funcionan para proporcionar un servicio al usuario. Un servicio puede implicar uno o varios tipos de medios, por ejemplo voz y datos, o video y audio.

Distintos requerimientos de transmisi6n aplican para el trafico en tiempo real comparado con el trafico no en tiempo real. Por ejemplo, el trafico no en tiempo real tal como la transferencia de ficheros no permite la perdida de paquetes, es decir los paquetes de datos que no se reciben correctamente en el extremo de recepci6n, pero es 25 menos sensible al retardo de transmisi6n que el trafico en tiempo real. El trafico en tiempo real, por otra parte, puede tolerar alguna perdida de paquetes pero es mas sensible al retardo de transmisi6n que el trafico no en tiempo real. Por lo tanto se han disenado distintos tipos de protocolos de transmisi6n para cumplir con las necesidades del trafico en tiempo real y el trafico no en tiempo real respectivamente. Un ejemplo de un protocolo adaptado para cumplir los requerimientos del trafico no en tiempo real es el Protocolo de Control de Transmisi6n (TCP), y un ejemplo de

30 protocolo adaptado a cumplir los requerimientos del trafico en tiempo real es el Protocolo de Datagrama de Usuario (UDP). Un uso tipico de UDP es para datos criticos en tiempo real tal como la Voz sobre IP (VoIP) y los medios de difusi6n en forma continua. Otro uso de UDP es para datos de control de senalizaci6n para los juegos en linea.

La Fig. 1 muestra un ejemplo de un recurso compartido 120 que tiene un nodo de entrada 110 y multiples nodos de salida 100. Es un hecho bien conocido que las redes de paquetes conmutados que utilizan recursos compartidos 35 entre los usuarios pueden experimentar congesti6n. La congesti6n ocurrira cuando la suma del trafico de los nodos de entrada, es decir los puntos de entrada, del recurso compartido exceda la suma del trafico de los nodos de salida, es decir los puntos de salida, del mismo recurso compartido. El ejemplo mas tipico es un encaminador con un numero de conexiones especifico. Incluso si el encaminador tiene bastante potencia de procesamiento para reencaminar el trafico de acuerdo con el flujo de datos del enlace, el flujo de datos del enlace disponible actualmente

40 pudiera restringir la cantidad de trafico con que los enlaces salientes desde el encaminador pueden hacer frente. Por lo tanto, los almacenadores temporales del encaminador se acumularan y eventualmente se desbordaran. La red ahora experimenta congesti6n y el encaminador es forzado a descartar paquetes.

Otro ejemplo de congesti6n se puede encontrar cuando se estudian las redes inalambricas con canales compartidos tales como la Red de Area Local Inalambrica (WLAN) especificada en el IEEE 802.11 a/b/g, o las redes m6viles tales 45 como el Acceso de Paquetes de Alta Velocidad (HSPA), la Evoluci6n de Largo Plazo (LTE) y la Interoperabilidad a Nivel Mundial de Acceso de Microondas (WiMAX). En estas redes, al menos el enlace descendente esta compartido entre los usuarios y es por eso un posible candidato a experimentar congesti6n. Por ejemplo en el caso de LTE, mostrado en la Figura 2, la estaci6n base eNB 220 gestionara las retransmisiones en la capa de Control de Acceso al Medio (MAC) sobre los canales de transmisi6n 210 al terminal m6vil o Equipo de Usuario (UE) 200 que tendran

50 impacto en la cantidad de trafico para que la estaci6n base eNB en cualquier momento dado pueda proporcionar flujo de datos. Cuantas mas retransmisiones se requieran para la recepci6n con exito en el UE, menos potencia disponible para proporcionar flujo de datos para otros usuarios, haciendo por ello el uso de la capacidad de transmisi6n del recurso compartido menos eficiente.

El comportamiento normal para cualquier nodo de encaminamiento es proporcionar los almacenadores temporales

55 que pueden gestionar una cierta cantidad de variaci6n en la capacidad del enlace de entrada/salida y por lo tanto absorber menores apariciones de congesti6n. No obstante, cuando la congesti6n es bastante severa, el nodo de encaminamiento eventualmente descartara paquetes.

Para el trafico TCP, se detectara un paquete descartado por el emisor dado que no se recibe el Reconocimiento (ACK) para ese paquete particular y sucedera una retransmisi6n. Ademas, el protocolo TCP tiene un mecanismo adaptativo de la velocidad integrado que bajara la velocidad binaria de transmisi6n cuando las perdidas de paquetes sucedan y las retransmisiones ocurran en la capa del Protocolo de Internet (IP). Si no se recibe un ACK dentro de un intervalo de tiempo especifico, establecido por un valor de tiempo de espera de transmisi6n, los datos se retransmiten. El valor de tiempo de espera de retransmisi6n TCP se determina dinamicamente para cada conexi6n, en base a un tiempo de ida y vuelta. En el receptor, se usan los numeros de secuencia para ordenar correctamente los segmentos que se pueden recibir fuera de orden y eliminar los duplicados. El TCP gobierna la cantidad de datos enviados devolviendo una ventana con cada reconocimiento para indicar una gama de numeros de secuencia aceptables mas alla del ultimo segmento recibido con exito. La ventana indica un numero permitido de octetos que el emisor puede transmitir antes de recibir permiso adicional. Dado que este control de flujo se incorpora en el protocolo en si mismo, el TCP proporciona un mecanismo adaptativo de velocidad independientemente de cualquier aplicaci6n que lo use. Este mecanismo tiene el efecto que se puede reducir la velocidad binaria de transmisi6n paso a paso cuando sucede la congesti6n, y tambien esa se puede aumentar paso a paso cuando cesa la congesti6n.

En la US 2003/198184 A1 se revela un sistema de control de velocidad que utiliza un metodo de estimaci6n de almacenador temporal para controlar el ancho de banda de transmisi6n en base a los informes del Protocolo de Control en Tiempo Real (RTCP). Los informes del RTCP transportan informaci6n de realimentaci6n en forma de datos de medici6n desde un cliente a un servidor con respecto a la recepci6n de datos que esta siendo difundida de forma continua sobre una red inalambrica desde el servidor al cliente. Cuando se recibe un informe del RTCP el servidor usa los datos de medici6n para determinar si adaptar el ancho de banda de transmisi6n mediante el ajuste de un "punto de ajuste de la velocidad de datos" dentro de un intervalo limitado por un limite superior y uno inferior.

En la US 2004/071145 A1 se revela un aparato y un metodo para el control de la velocidad binaria no especificada (UBR) de acuerdo con el estado del trafico de celda y la aparici6n de congesti6n en el terminal de conmutaci6n en ATM. Si la informaci6n de congesti6n indica que no ha habido congesti6n, una unidad de determinaci6n del estado de trafico puede aumentar el ancho de banda de UBR mediante una primera velocidad o mediante una segunda velocidad, que es mas pequena que la primera velocidad.

Para aumentar ademas el rendimiento de los nodos de encaminamiento, se ha desarrollado un esquema llamado "Notificaci6n de Congesti6n Explicita (ECN) para IP", especificada en la especificaci6n RFC 3168 del IETF, que se incorpora por este medio en su totalidad por referencia. Como se muestra en la Figura 3, este esquema utiliza dos bits, bits ECN 300 en el campo del Tipo de Servicio (ToS) 310, en la cabecera IP 320 para senalar el riesgo de perdidas relacionadas con la congesti6n. El campo tiene cuatro puntos de c6digo donde dos se usan para senalar la capacidad de ECN y los otros dos se usan para senalar la congesti6n. El punto de c6digo para la congesti6n se fija por ejemplo en los encaminadores y cuando el receptor ha encontrado una notificaci6n de congesti6n propaga la informaci6n al emisor de la secuencia el cual entonces puede adaptar su velocidad binaria de transmisi6n. Para TCP, esto se hace usando dos bits, previamente reservados, en la cabecera TCP. Cuando se reciben, estos bits desencadenan que el emisor reduzca su velocidad binaria de transmisi6n.

El trafico UDP no tiene mecanismo generico similar para la transmisi6n fiable y el control del flujo. El trafico UDP es por definici6n no fiable en el sentido que la entrega no esta garantizada. Los paquetes UDP perdidos no se retransmitiran a menos que la aplicaci6n tenga algun rasgo especializado que permita esto. El UDP por si mismo no responde de ninguna manera a la congesti6n de red, y la velocidad de transmisi6n se determina por la aplicaci6n, no por el UDP en si mismo.

La ECN se define para el uso IP con cualquier protocolo de transporte. Por lo tanto, la ECN para UDP no esta excluida en la especificaci6n para la ECN, la RFC 3168 del IETF, aunque solamente se especifica en terminos de usar con el trafico TCP. El UDP por si mismo no tiene mecanismo para cambiar su comportamiento de transmisi6n en base a la recepci6n de un mensaje de notificaci6n de congesti6n. Sin este mecanismo, la ECN para UDP llega a ser altamente no fiable dado que el efecto de establecer los bits de ECN en la cabecera IP no se puede predecir. La ECN para UDP necesita los mismos mecanismos genericos que la ECN para TCP; un canal de retorno rapido para la realimentaci6n de senalizaci6n desde el receptor al emisor con respecto a las transmisiones recibidas y un algoritmo de control de velocidad para cambiar dinamicamente la velocidad binaria de transmisi6n.

Ya que los servicios de comunicaci6n sensibles al retardo, tales como los servicios de comunicaci6n en tiempo real basados en UDP, tambien pueden ser bastante sensibles a la perdida de paquetes hay una necesidad de gestionar las transmisiones a traves de recursos compartidos para tales servicios de manera que se puede aliviar o evitar la congesti6n y/o hacer uso eficiente de la capacidad de transmisi6n del recurso compartido, por ejemplo aumentando el trafico despues de que ha cesado esa congesti6n. Las transmisiones a traves de recursos compartidos se pueden gestionar controlando la velocidad binaria de transmisi6n de las aplicaciones que proporcionan los servicios a traves de los recursos compartidos. No obstante, controlar la velocidad binaria de transmisi6n de las aplicaciones impactara el retardo de transmisi6n. Mientras que un servicio menos sensible al retardo aun estara funcionando aunque se entregue en un paso mas lento si la velocidad binaria de transmisi6n se reduce, la consecuencia para un servicio sensible al retardo puede ser que el servicio no puede ser visto como que funciona si se realiza una reducci6n demasiado drastica de la velocidad binaria de transmisi6n.

Resumen

Es un objeto de al menos algunas realizaciones de acuerdo con la invenci6n proporcionar un mecanismo de control de velocidad que es capaz de hacer uso de la capacidad de transmisi6n de un recurso compartido mientras que tambien funciona para acomodar las diversas necesidades de los servicios sensibles al retardo que usan el recurso compartido en una forma adecuada y equilibrada.

De acuerdo con un primer aspecto, el objeto se logra proporcionando un metodo para controlar una velocidad binaria de una sesi6n en un sistema de comunicaciones de paquetes conmutados donde estan establecidas multiples sesiones a traves de un recurso compartido. Primero se determina una gama valida de velocidad binaria para la sesi6n. La gama de velocidad binaria esta o puede estar confinada mediante un limite o punto final superior y un limite o punto final inferior. Se determina una distancia a un limite seleccionado, es decir al limite superior o al limite inferior, de la gama de velocidad binaria comparando una velocidad binaria actual de la sesi6n con la gama de velocidad binaria. La velocidad binaria actual se adapta entonces de manera diferente dependiendo de la distancia al limite seleccionado. La velocidad binaria actual se puede adaptar en una realizaci6n mediante una cantidad que es mas grande si la distancia es pequena y mas pequena si la distancia es grande. Por ejemplo, si el limite seleccionado es el limite superior de la gama de velocidad binaria, la velocidad binaria actual se adapta mediante una reducci6n mas grande o un aumento mas pequeno si la distancia al limite seleccionado es pequena y mediante una reducci6n mas pequena o aumento mas grande si la distancia al limite seleccionado es grande. Si por otra parte el limite seleccionado es el limite inferior de la gama de velocidad binaria, la velocidad binaria actual se adapta mediante una reducci6n mas grande o un aumento mas pequeno si la distancia al limite seleccionado es grande y mediante una reducci6n mas pequena o aumento mas grande si la distancia al limite seleccionado es pequena.

De acuerdo con un segundo aspecto, el objeto se logra proporcionando un sistema de comunicaciones de paquetes conmutados para controlar las velocidades binarias de al menos una primera y una segunda sesi6n. El sistema comprende al menos un emisor operable para comunicar con un primer receptor a traves de un recurso compartido en la primera sesi6n y un segundo emisor operable para comunicar con un segundo receptor a traves del recurso compartido en la segunda sesi6n. Ademas, el sistema comprende los primeros medios de determinaci6n de la gama de velocidad binaria para la determinaci6n de una primera gama de velocidad binaria valida para la primera sesi6n y los segundos medios de determinaci6n de la gama de velocidad binaria para la determinaci6n de una segunda gama de velocidad binaria valida para la segunda sesi6n. La primera gama de velocidad binaria y la segunda gama de velocidad binaria esta o puede estar confinada mediante un limite o punto final superior respectivo y un limite o punto final inferior respectivo. El sistema tambien comprende una primera unidad de control de adaptaci6n de velocidad para controlar la adaptaci6n de la velocidad de una primera velocidad binaria actual de dicha primera sesi6n de manera que la primera velocidad binaria actual se adapte de manera diferente dependiendo de una primera distancia a un limite seleccionado, es decir al limite superior o al limite inferior, de la primera gama de velocidad binaria y una segunda unidad de control de adaptaci6n de velocidad para controlar la adaptaci6n de la velocidad de una segunda velocidad binaria actual de dicha segunda sesi6n de manera que la segunda velocidad binaria actual se adapte de manera diferente dependiendo de una segunda distancia a un limite seleccionado, es decir al limite superior o al limite inferior, de la segunda gama de velocidad binaria. La primera velocidad binaria actual y la segunda velocidad binaria actual se puede adaptar en una realizaci6n mediante las primera y segunda cantidades que son mas grandes si la distancia respectiva es pequena y mas pequenas si la distancia respectiva es grande.

De acuerdo con un tercer aspecto, el objeto se logra proporcionando un receptor para recibir los medios codificados de paquetes conmutados que se transmiten por un emisor en una sesi6n a traves de un recurso compartido. El receptor comprende los medios de determinaci6n de la gama de velocidad binaria para determinar una gama de velocidad binaria valida para la sesi6n. La gama de velocidad binaria esta o puede estar confinada mediante un limite o punto final superior y un limite o punto final inferior. El receptor ademas comprende los medios de estimaci6n de petici6n de velocidad binaria y los medios de petici6n de velocidad. Los medios de estimaci6n de petici6n de velocidad binaria funcionan para estimar una adaptaci6n de velocidad binaria mediante la comparaci6n de una velocidad binaria recibida actualmente con la gama de velocidad binaria para determinar una distancia a un limite seleccionado, es decir al limite superior o al limite inferior, de la gama de tasas de bit y estimar la adaptaci6n de velocidad binaria de manera diferente dependiendo de la distancia. La adaptaci6n de velocidad binaria estimada de esta manera en una realizaci6n puede ser mas grande si la distancia es pequena y mas pequena si la distancia es grande. Los medios de petici6n de velocidad funcionan para requerir al emisor adaptar una velocidad binaria transmitida actualmente en dicha sesi6n enviando un mensaje de petici6n de adaptaci6n de la velocidad. El mensaje de petici6n de adaptaci6n de velocidad en una realizaci6n adicional se puede enviar tras la recepci6n de un mensaje de notificaci6n de congesti6n desde el recurso compartido.

De acuerdo con un cuarto aspecto, el objeto se logra proporcionando un emisor para transmitir los medios codificados de paquetes conmutados en una sesi6n a traves de un recurso compartido a un receptor. El emisor comprende los medios de determinaci6n de la gama de velocidad binaria para la determinaci6n de una gama de velocidad binaria valida para la sesi6n. La gama de velocidad binaria esta o puede estar confinada mediante un limite o punto final superior y un limite o punto final inferior. El emisor comprende ademas los medios de recepci6n de petici6n de velocidad y una unidad de control de adaptaci6n de la velocidad. Los medios de recepci6n de petici6n de la velocidad funcionan para recibir las peticiones desde el receptor para adaptar una velocidad binaria transmitida

actualmente en la sesi6n. La unidad de control de adaptaci6n de la velocidad funciona para controlar la adaptaci6n de la velocidad binaria transmitida actualmente en la sesi6n de manera que la velocidad binaria transmitida actualmente se adapta de manera diferente dependiendo de una distancia a un limite seleccionado, es decir al limite superior o al limite inferior, de la gama de velocidad binaria. La velocidad binaria transmitida actualmente en una realizaci6n se puede adaptar mediante una cantidad que es mas grande si la distancia es pequena y mas pequena si la distancia es grande. La adaptaci6n de la velocidad se puede hacer tras la recepci6n de una petici6n en forma de un mensaje de petici6n de adaptaci6n de la velocidad desde el receptor.

Controlando la velocidad binaria de cada sesi6n que se establece a traves del recurso compartido para las aplicaciones que se ejecutan en los clientes para proporcionar servicios sensibles al retardo a los usuario en este sentido el metodo, sistema y adaptaciones emisor-receptor tienen el efecto de que las adaptaciones de la velocidad se pueden distribuir entre las aplicaciones de manera que los usuarios comparten la responsabilidad de las adaptaciones de la velocidad.

Ademas, realizando las adaptaciones de la velocidad dentro de cada gama de velocidad binaria definida de servicio el metodo, sistema y adaptaciones emisor-receptor tienen el efecto de permitir que los intentos de los servicios se puedan mantener mientras que se adaptan las respectivas velocidades de los servicios.

Una ventaja de al menos algunas realizaciones de la invenci6n es que la responsabilidad de adaptar la velocidad de transmisi6n cuando sucede la congesti6n en un nodo de red se comparte mas justamente entre nuevos usuarios, que no han tomado ninguna acci6n para aliviar la congesti6n, y los usuario que ya han reducido su velocidad binaria debido a los mensajes de notificaci6n de congesti6n previos.

Otra ventaja es que la distribuci6n de la funcionalidad de adaptaci6n de la velocidad a los clientes elimina la necesidad o requerimiento de hacer el seguimiento del usuario y la concienciaci6n del servicio en el nodo de red congestionado.

Breve descripcion de los dibujos

La invenci6n, junto con los objetos y ventajas adicionales de la misma, se puede entender mas facilmente haciendo referencia a la siguiente descripci6n tomada junto con los dibujos anexos, en los que:

La Fig. 1 ilustra un ejemplo de un recurso compartido que puede estar sujeto a congesti6n;

La Fig. 2 ilustra un ejemplo adicional de un recurso compartido que puede estar sujeto a congesti6n;

La Fig. 3 es una ilustraci6n de una cabecera IP con bits de ECN de acuerdo con la especificaci6n RFC 3169 del IETF;

La Fig. 4 es una ilustraci6n esquematica de una realizaci6n de un mecanismo de adaptaci6n de la velocidad de acuerdo con la invenci6n;

La Fig. 5 es una ilustraci6n esquematica de una realizaci6n de un sistema de acuerdo con la invenci6n;

La Fig. 6 es una ilustraci6n de una realizaci6n de una indicaci6n de la gama de velocidad binaria de acuerdo con la invenci6n;

La Fig. 7 es una ilustraci6n esquematica de bloques de funcionalidad de una realizaci6n de un receptor de acuerdo con la invenci6n;

La Fig. 8 es una ilustraci6n esquematica de bloques de funcionalidad de una realizaci6n de un emisor de acuerdo con la invenci6n;

La Fig. 9 es una ilustraci6n esquematica de bloques de funcionalidad de una realizaci6n alternativa de un emisor de acuerdo con la invenci6n;

La Fig. 10 es un diagrama de flujo de una realizaci6n de un algoritmo de control de la velocidad de acuerdo con la invenci6n;

La Fig. 11 es un diagrama de flujo de una realizaci6n de una parte de la estimaci6n de velocidad binaria de un algoritmo de control de la velocidad de acuerdo con la invenci6n;

La Fig. 12 es un diagrama de flujo de una realizaci6n de un flujo de sesi6n entre dos usuarios de acuerdo con la invenci6n;

La Fig. 13 es una ilustraci6n de una realizaci6n de la ponderaci6n de una adaptaci6n de la velocidad binaria de acuerdo con la invenci6n;

La Fig. 14 es una ilustraci6n de un nivel de carga de un recurso compartido de una realizaci6n del sistema de acuerdo con la invenci6n.

Descripcion detallada

Al menos alguna de las realizaciones de acuerdo con la invenci6n proporciona una distribuci6n compartida mas justa

o igual de la adaptaci6n de la velocidad entre usuarios de una funci6n de encaminamiento particular tomando en consideraci6n una velocidad binaria de la sesi6n actual de una aplicaci6n de usuario, incluyendo su relaci6n con una velocidad binaria de puesta en marcha de la sesi6n inicial, en la adaptaci6n de la velocidad. Se proporciona un mecanismo para guiar una respuesta a un mensaje de notificaci6n de congesti6n de manera que los usuarios en la misma clase de prioridad de red experimenten degradaciones similares de calidad. Esto significa que un nuevo usuario que justo ha iniciado su sesi6n, digamos a por ejemplo 100 kbps, seria requerido para bajar su velocidad binaria en una forma distinta que un usuario que ya, cuando se recibe algun mensaje de notificaci6n de congesti6n previo, ha bajado su velocidad binaria desde por ejemplo 100 kbps a 50 kbps.

Para asegurar que el intento de un servicio se puede mantener, los inventores se han dado cuenta que una gama definida de velocidades binarias entre las cuales el servicio se considera que funciona o trabaja es necesaria ya que los c6dec de medios modernos tienen la posibilidad de sintonizar en un conjunto discreto de velocidades binarias, en algunos casos incluso cualquier velocidad binaria dada, pero no es cierto que el intento del servicio se pueda mantener a cualquier velocidad binaria dada. Por ejemplo una sesi6n de video en tiempo real requiere velocidades binarias del orden de 100 kpbs. Aunque los c6dec de video usados en tal sesi6n tienen la posibilidad de reducir la velocidad binaria a 10 kbps, el servicio no es claramente una sesi6n de video de conversaci6n a 10 kbps. A esta velocidad binaria, se percibiria como una actuaci6n de desplazamiento lento; no el servicio conversacional en tiempo real fijado por los requerimientos de servicio. En este caso, podrias decir que las velocidades binarias validas para el servicio estan entre 40 y 100 kbps. Para otros tipos de medios, la gama de velocidad binaria valida se veria diferente, pero el principio subyacente es el mismo: hay necesidad de un cierto espacio o gama de velocidades binarias en las que se puede determinar que el servicio sea valido.

Los inventores se han dado cuenta que, especificando c6mo deberian responder las aplicaciones para la puesta en marcha de los bits de ECN en la cabecera IP, se habilita el uso fiable de ECN con UDP para los servicios de comunicaci6n en tiempo real, tales como la Telefonia Multimedia IMS (MTSI), que se dotan con un canal de retorno rapido desde el receptor al emisor y la posibilidad de cambiar dinamicamente la tasas de bit de transmisi6n.

La Figura 4 ilustra el comportamiento de la aplicaci6n requerido para usar ECN con el trafico UDP. Las pilas de protocolo de un cliente de envio 470 y un cliente de recepci6n 420 que comunican a traves de un recurso compartido 400, aqui en la forma de un encaminador, se muestran. De acuerdo con un esquema ECN para IP, el recurso compartido 400 fija los bit de ECN 300 en una cabecera IP de un paquete UDP que es reenviado sobre una conexi6n 410 al cliente de recepci6n 420. Cuando un mensaje de notificaci6n de congesti6n, es decir el establecimiento del bit de ECN, se detecta en la capa IP 430 tiene que ser reenviado a una capa de aplicaciones 440 en un receptor 700 en el cliente de recepci6n 420 como se indica por una conexi6n 450. Tras la recepci6n del mensaje de notificaci6n de congesti6n, el receptor 700 en el cliente de recepci6n 420 necesita transmitir una petici6n a un emisor 800 en el cliente de envio 470 que requiere al emisor reducir su velocidad binaria, indicado por la flecha

480. Cuando esa petici6n llega al emisor 800, deberia reducir inmediatamente la velocidad binaria transmitida al receptor 700, como se indica por la flecha 490. La cantidad de la reducci6n se puede determinar por el emisor 800 que a su vez puede basar su decisi6n en una serie de parametros.

Para los servicios basados en UDP, los inventores proponen que esa direcci6n de velocidad binaria adecuada para una sesi6n se pueda proporcionar anadiendo un parametro que determina un limite inferior, por debajo del cual un servicio no se ve que sea utilizable. Esto se puede hacer en el procedimiento de establecimiento de la sesi6n usando por ejemplo el Protocolo de Flujo de Datos en Tiempo Real (RTSP) o el Protocolo de Inicio de Sesiones (SIP), en que el Protocolo de Descripci6n de Sesiones (SDP) integrado ya transporta un parametro de velocidad binaria, el parametro b, que especifica el limite superior de la velocidad binaria de la sesi6n.

Los inventores sugieren ademas que la respuesta del emisor a la recepci6n de un mensaje de notificaci6n de congesti6n se puede basar en un procedimiento de establecimiento de la sesi6n extendido. Este procedimiento se puede usar para controlar la respuesta del emisor a los mensajes de notificaci6n de congesti6n de una forma que tiene en consideraci6n las acciones previas en los mensajes de notificaci6n de congesti6n y tambien permite que los requerimientos de servicio generales afecten la elecci6n de las acciones del emisor.

De esta manera, de acuerdo con las realizaciones de la presente invenci6n, se introducen dos rasgos en el servicio de comunicaci6n en tiempo real:

1.: La senalizaci6n de una gama de velocidad binaria de la sesi6n, es decir entre que velocidades es valido el servicio y entre que velocidades se permite al emisor de medios adaptar durante la sesi6n.

2.: Un mecanismo de adaptaci6n que cambia su comportamiento en base a la relaci6n entre la velocidad binaria de transmisi6n de medios actual o la velocidad binaria de sesi6n actual y la gama de velocidad binaria senalada en el establecimiento de la sesi6n.

El resultado sera que el emisor determine su acci6n al mensaje de notificaci6n de congesti6n basado en que velocidad binaria transmite actualmente en y d6nde reside en la gama de velocidad binaria de la sesi6n: Cuanto mas

cercana al limite inferior, mas pequena es la respuesta al mensaje de congesti6n, cuanto mas cercana al limite superior, mas drastica es la respuesta al mensaje de congesti6n. De este modo, los usuarios que consumen mas recursos en la misma clase de prioridad de red responderian con una reducci6n de la velocidad binaria mayor que un usuario que ya transmite cerca de su limite inferior para la continuidad de la sesi6n.

La Figura 5 es un sistema de acuerdo con una o mas realizaciones de la invenci6n. Por simplicidad, se elige un entorno de LTE para la descripci6n, pero la invenci6n es igualmente aplicable a cualquier sistema de comunicaci6n de paquetes conmutados que emplea servicios de comunicaci6n sobre un protocolo que no tiene control de flujo integrado. Una primera parte, el Usuario A, que usa un primer cliente 500, esta comunicando en una primera sesi6n con una segunda parte, el Usuario B, que usa un segundo cliente 530. El primer cliente 500 esta en este ejemplo conectado a traves de un cortafuegos 570 a un recurso compartido 560. El recurso compartido 560 esta a su vez conectado a traves de una red central 580 a una estaci6n base eNB 540 a la que esta conectado el segundo cliente 530 a traves de un canal de transmisi6n compartido 550. De una forma similar una tercera parte, el Usuario B, que usa un tercer cliente 520, esta comunicando en una segunda sesi6n con una cuarta parte, el Usuario C, que usa un cuarto cliente 510. El tercer cliente 520 tambien esta conectado con el recurso compartido 560, y el cuarto cliente 510 tambien esta conectado a traves del canal de transmisi6n compartido 550 a la estaci6n base eNB 540. Los clientes pueden ser por ejemplo un terminal m6vil, un ordenador personal o un cliente virtual que reside en un servidor.

En el primer y el segundo clientes 500 y 530 se esta ejecutando una primera aplicaci6n, que proporciona un primer servicio a las partes implicadas el Usuario A y el Usuario D. En el tercer y el cuarto clientes 520 y 510 se esta ejecutando una segunda aplicaci6n, que proporciona un segundo servicio a las partes implicadas el Usuario B y el Usuario C. Dependiendo de la direcci6n de la comunicaci6n, la aplicaci6n que se esta ejecutando en el respectivo de los clientes puede actuar como un emisor 800 o como un receptor 700, como se muestra en la Figura 4. Por ejemplo, para la comunicaci6n desde el Usuario A al Usuario B, la primera aplicaci6n que se ejecuta en el primer cliente 500 actua como un emisor 800 y la primera aplicaci6n que se esta ejecutando en el segundo cliente 530 actua como un receptor 700, mientras que para la comunicaci6n desde el Usuario D al Usuario A, la primera aplicaci6n que se ejecuta en el segundo cliente 530 actua como un emisor 800 y la primera aplicaci6n que se esta ejecutando en el primer cliente 500 actua como un receptor 700.

Se determina una primera gama de velocidad binaria que sea valida para la primera sesi6n y para la primera aplicaci6n, es decir necesaria para el servicio proporcionado por la primera aplicaci6n para funcionar como se pretende durante la primera sesi6n, y se determina una segunda gama de velocidad binaria que sea valida para la segunda sesi6n y para la segunda aplicaci6n, es decir necesaria para el servicio proporcionado por la segunda aplicaci6n para funcionar como se pretende durante la segunda sesi6n. Una gama de velocidad binaria es o puede ser especificada por un limite o punto final superior que indica una velocidad binaria maxima y un limite o punto final inferior que indica una velocidad binaria minima por la cual una aplicaci6n puede funcionar para proporcionar un servicio utilizable.

Una forma de indicar esta extensi6n de velocidad binaria o gama de velocidad binaria se muestra en la Figura 6. En este ejemplo, el SDP se usa para transportar la gama de velocidad binaria valida en un procedimiento de negociaci6n de sesi6n. Esto se hace introduciendo, ademas del limite superior existente para la velocidad binaria de la sesi6n, bmax, tambien un limite inferior para la velocidad binaria de la sesi6n, bmin. El ejemplo muestra que el oferente, es decir el emisor, soporta una velocidad binaria maxima mas alta, indicada por bmax en la oferta SDP 600, que el receptor, cuya velocidad binaria maxima se indica por bmax en la respuesta SDP 610, pero ambas identifican 48 kbps, indicados por bmin en la oferta de SDP 600 y la respuesta de SDP 610 como el limite inferior para el video en esta sesi6n. Esta sesi6n se ejecutaria con una velocidad binaria maxima o limite superior de 60 kbps para el video y una velocidad binaria minima o limite inferior de 48 kbps.

Tambien se pueden usar otros medios para transportar la informaci6n de la gama de velocidad binaria. Una posible alternativa podria ser tener la gama de velocidad binaria especificada en lo ajustes de la aplicaci6n, o codificada en los componentes fisicos en la aplicaci6n.

En un entorno donde los mecanismos de calidad de servicio (QoS) estan disponibles para el trafico, los limites inferior y superior de la gama de velocidad binaria se pueden relacionar con una concesi6n de QoS especifica. Un esquema de QoS especifica afecta la admisi6n dentro de la red y posiblemente tambien las reservas de recursos de red durante la sesi6n. En las redes 3GPP, los limites inferior y superior se podrian relacionar con la velocidad binaria garantizada (GBR) de los atributos de la QoS y la velocidad binaria maxima (MBR) respectivamente. No obstante, esto no se requiere y pudiera haber ocasiones en que el limite inferior podria ser mas bajo que la GBR.

Como se puede ver a partir de las Figuras 7 y 8, en que se ilustran el receptor 700 y el emisor 800 partes de una aplicaci6n, la primera aplicaci6n incluye al menos un primer codificador de medios 830 y/o al menos un primer descodificador de medios 730. Igualmente, la segunda aplicaci6n incluye al menos un segundo codificador de medios 830 y/o al menos un segundo descodificador de medios 730. Una aplicaci6n que reside en un servidor puede tener un codificador de medios, pero no descodificador de medios ya que tal aplicaci6n actua tipicamente como un emisor.

La primera aplicaci6n ademas incluye una primera unidad de control de adaptaci6n de la velocidad 870 que se conecta con el al menos un primer codificador de medios 830 y que sirve para controlar la velocidad, por ejemplo la velocidad binaria, de al menos un primer codificador de medios 830. De manera similar, la segunda aplicaci6n ademas incluye una segunda unidad de control de adaptaci6n de la velocidad 870 que se conecta con el al menos un segundo codificador de medios 830 y que sirve para controlar la velocidad, por ejemplo la velocidad binaria, de al menos un segundo codificador de medios 830. La primera unidad de control de adaptaci6n de la velocidad 830 sirve tambien por ello para controlar la velocidad, por ejemplo la velocidad binaria, de la primera sesi6n, y la segunda unidad de control de adaptaci6n de velocidad 830 sirve para controlar la velocidad , por ejemplo la velocidad binaria, de la segunda sesi6n, ya que la velocidad o velocidad binaria de una sesi6n se determina por la velocidad en la que el flujo de paquetes de medios se saca desde el al menos un codificador de medios 830.

La primera unidad de control de velocidad 870 se ha configurado para comparar una primera velocidad binaria actual que se usa actualmente en la primera sesi6n o por el al menos un primer codificador de medios 830 para dicha primera gama de velocidad binaria para determinar una primera distancia a un limite o punto final de la primera gama de velocidad binaria, es decir al limite superior o al limite inferior de la primera gama de velocidad binaria, y la segunda unidad de control de adaptaci6n de velocidad 870 se ha configurado para comparar una segunda velocidad binaria actual que se usa actualmente en la segunda sesi6n o por el al menos un segundo codificador de medios 830 para dicha segunda gama de velocidad binaria para determinar una segunda distancia a un limite o punto final de la segunda gama de velocidad binaria, es decir al limite superior o al limite inferior de la segunda gama de velocidad binaria. Las primera y segunda unidades de control de adaptaci6n de velocidad 830 se configuran ademas para adaptar la primera velocidad binaria actual y la segunda velocidad binaria actual de manera diferente dependiendo de la primera y segunda distancia, es decir para adaptar las velocidades binarias mediante cantidades que dependen del tamano de la distancia respectiva. Las adaptaciones de la velocidad se pueden realizar para aliviar o reducir la congesti6n en el recurso compartido 560 y/o el canal de transmisi6n compartido 550.

Las primera y segunda unidades de control de adaptaci6n de velocidad 830 son, o pueden ser, desencadenadas por un mensaje de petici6n de adaptaci6n de la velocidad 480 para realizar el control de adaptaci6n de la velocidad y emitir un comando de control de velocidad 880 para el al menos un primer y al menos un segundo codificador de medios 830 respectivamente. El mensaje de petici6n de adaptaci6n de velocidad se puede enviar por ejemplo por el receptor 700, es decir por la aplicaci6n que recibe los medios que han sido codificados por el respectivo al menos un primer y al menos un segundo codificador de medios 830. El mensaje de petici6n de adaptaci6n de velocidad 480 puede especificar ademas una adaptaci6n de la velocidad o velocidad binaria requerida o sugerida, por ejemplo expresada como un cambio relativo o una diferencia con la velocidad binaria actual, o como una velocidad binaria nueva o adaptada, a ser usada para la transmisi6n en la sesi6n respectiva. La adaptaci6n de la velocidad binaria se puede estimar por el receptor 700 de manera que la velocidad binaria recibida actualmente se reducira mas si esta mas cerca del limite superior de la gama de velocidad binaria que si esta mas cerca del limite inferior de la gama de velocidad binaria valida para la sesi6n respectiva.

El mecanismo de control de velocidad utiliza en conocimiento de la gama de velocidad binaria valida para el tipo de medios asi como el valor actual de la velocidad binaria transmitida. Este mecanismo se describira ahora en mas detalle con referencia a las Figuras 4 y 7 -9. Las Figuras 7 y 8 ilustran algunas partes de una pareja emisor - receptor de una aplicaci6n en que esta implementado el mecanismo de control de velocidad. Al menos algunas de estas partes, tales como las unidades de control de adaptaci6n de la velocidad 870 y 970, los medios de estimaci6n de petici6n de velocidad binaria 770, los medios de petici6n de velocidad 790, los medios de recepci6n de petici6n de velocidad 850, los medios de detecci6n 750, los medios de determinaci6n de la gama de velocidad binaria 720 y 820, los medios de determinaci6n de velocidad binaria 740 y 840, los medios de determinaci6n de la Velocidad de Perdida de Paquetes (PLR) 905, los medios de determinaci6n de la Fluctuaci6n 915, los medios de determinaci6n de los ajustes de Aplicaci6n 920 y los medios de determinaci6n de la Realimentaci6n de Red (NF) se pueden implementar por ejemplo en forma de memorias desde las cuales se puede leer la informaci6n y/o procesadores que realizan el procesamiento de la informaci6n para producir un resultado que se puede usar en la adaptaci6n de la velocidad.

La Figura 7 muestra un esquema de bloques de un receptor 700 que se configura para proporcionar un servicio recibiendo los medios codificados de paquetes conmutados 710 que se transmiten por un emisor 800 en una sesi6n a traves de un recurso compartido 400. El receptor 700 incluye los medios de determinaci6n de la gama de velocidad binaria 720 para la determinaci6n de una gama de velocidad binaria de la sesi6n valida dentro de la cual una velocidad binaria aplicada para la transmisi6n de los medios codificados debe caer para que el servicio este trabajando como se pretende, por ejemplo que el servicio proporciona suficiente calidad de medios. La gama de velocidad binaria de sesi6n valida se puede especificar por un limite o punto final superior y un limite o punto final inferior. Ademas, el receptor 700 comprende al menos un descodificador de medios 730 para descodificar dichos medios codificados a una velocidad binaria recibida actualmente para sacar los medios descodificados 745, por ejemplo audio o video, y los medios de detecci6n 750 para detectar un mensaje de notificaci6n de congesti6n desde el recurso compartido y los medios de determinaci6n de la velocidad binaria 740 para determinar la velocidad binaria recibida actualmente. La velocidad binaria recibida actualmente se puede determinar a partir del flujo IP de medios codificados 710 que se introduce al descodificador de medios 730 como se indica por la flecha discontinua 755, por ejemplo monitorizando el flujo IP y estimando un valor medio para la velocidad binaria recibida actualmente. Tambien se puede determinar a partir de otros medios disponibles en el cliente d6nde reside el receptor 700. La

informaci6n sobre la gama de velocidad binaria de la sesi6n valida, la velocidad binaria recibida actualmente y el mensaje de notificaci6n de congesti6n se proporciona en una entrada 760 a los medios de estimaci6n de petici6n de la velocidad binaria 770 para estimar una adaptaci6n de la velocidad binaria comparando la velocidad binaria recibida actualmente con la gama de velocidad binaria de la sesi6n valida para determinar una distancia a un limite, es decir al limite superior o al limite inferior, de la gama de velocidad binaria de la sesi6n valida y estimar la adaptaci6n de la velocidad binaria de manera diferente dependiendo de la distancia. La adaptaci6n de la velocidad binaria depende de la distancia, de manera que la adaptaci6n de la velocidad binaria es mas grande si la distancia es pequena y mas pequena si la distancia es grande. La estimaci6n de una adaptaci6n de la velocidad binaria se puede hacer en respuesta a un mensaje de notificaci6n de congesti6n pero tambien se podria desencadenar por otros mensajes y situaciones. La adaptaci6n de la velocidad binaria estimada, que se puede expresar como un cambio relativo o una diferencia con la velocidad binaria recibida actualmente, o como una velocidad binaria transmitida requerida, se saca entonces en linea 780 a los medios de petici6n de velocidad 790. En una primera realizaci6n, los medios de petici6n de velocidad 790 entonces requieren al emisor 800 adaptar su velocidad binaria transmitida actualmente de los medios codificados enviando una petici6n de adaptaci6n de la velocidad 480 al emisor 800. La petici6n de adaptaci6n de la velocidad 480 ademas puede incluir la adaptaci6n de la velocidad binaria estimada para ser usada como una entrada por el emisor 800 para determinar una nueva velocidad binaria transmitida, es decir una velocidad binaria adaptada, de los medios codificados 490, 810.

No obstante, en una segunda realizaci6n, la petici6n de adaptaci6n de la velocidad 480 se puede interpretar por el emisor 800 como una instrucci6n u orden para ajustar la velocidad binaria transmitida actualmente como se especifica por la adaptaci6n de la velocidad binaria estimada incluida en la petici6n de adaptaci6n de la velocidad

480.

En aun otra, tercera realizaci6n, la petici6n de adaptaci6n de la velocidad 480 enviada por el receptor 700 no incluye ninguna adaptaci6n de la velocidad binaria estimada. Esta tercera realizaci6n requiere que el emisor 800 incluya los medios de estimaci6n de la velocidad binaria, para estimar una adaptaci6n de la velocidad binaria. Ademas, es posible, pero no necesario en la tercera realizaci6n que el receptor 700 incluya los medios de estimaci6n de la velocidad binaria 770 y estime una adaptaci6n de la velocidad binaria.

La Figura 8 muestra un esquema de bloques de un emisor 800 que esta configurado para proporcionar un servicio mediante la transmisi6n de medios codificados de paquetes conmutados 810 en una sesi6n a traves de un recurso compartido 400 a un receptor 700. El emisor 800 incluye los medios de determinaci6n de la gama de velocidad binaria 820 para determinar una gama de velocidad binaria de la sesi6n valida dentro de la cual una velocidad binaria aplicada para la transmisi6n de los medios codificados 810 debe caer para que el servicio este trabajando como se pretende, por ejemplo en que el servicio proporcione suficiente calidad de medios, y al menos un codificador de medios 830 para los medios de recepci6n 835 que se introduce al codificador de medios, por ejemplo el audio o video capturado, y codificar los medios a una velocidad binaria transmitida actualmente. Ademas, el emisor 800 incluye los medios de recepci6n de la petici6n de velocidad 850 para recibir las peticiones desde el receptor 700 para adaptar la velocidad binaria transmitida actualmente de los medios codificados y los medios de determinaci6n de la velocidad binaria 840 para determinar la velocidad binaria transmitida actualmente. La velocidad binaria transmitida actualmente se puede determinar a partir de los ajustes en el codificador de medios 830 o a partir del flujo IP de los medios codificados 810 que se saca desde el codificador de medios 830 como se indica por la flecha discontinua 855, pero tambien se puede determinar a partir de otros medios disponibles en el cliente donde reside el emisor 800. La informaci6n sobre la gama de velocidad binaria de la sesi6n valida, la velocidad binaria transmitida actualmente y las peticiones 480 desde el receptor se proporciona en una entrada 860 a una unidad de control de adaptaci6n de la velocidad 870. Las peticiones 480 ademas pueden incluir una adaptaci6n de la velocidad binaria estimada hecha por el receptor 700 a ser usada como una entrada por el emisor 800 para determinar una nueva velocidad binaria transmitida, es decir una velocidad binaria adaptada, de los medios codificados 810. La unidad de control de adaptaci6n de velocidad 870 determina una adaptaci6n de la velocidad a ser hecha en base a la informaci6n proporcionada en la entrada 860 y saca un comando de control de velocidad en una salida 880 para dar instrucciones al codificador de medios 830 para cambiar la velocidad binaria transmitida actualmente en una velocidad binaria adaptada dentro de la gama de velocidad binaria de la sesi6n valida. El codificador de medios 830 entonces cambia su transmisi6n o salida de los medios codificados 810 de la velocidad binaria transmitida actualmente a la velocidad binaria adaptada. La unidad de control de adaptaci6n de la velocidad 870 puede determinar una adaptaci6n de la velocidad a ser hecha y/o sacar un comando de control de velocidad al codificador de medios en respuesta a una petici6n 480 desde el receptor 700 pero tambien podria ser desencadenado por otros mensajes o situaciones.

Con referencia de nuevo a la tercera realizaci6n de la presente invenci6n, los medios de estimaci6n de la velocidad binaria 770 se requieren en esta realizaci6n en el emisor 800 para estimar una adaptaci6n de la velocidad binaria ya que tal informaci6n no se incluye en la petici6n de adaptaci6n de la velocidad 480 enviada por el receptor 700. Los medios de estimaci6n de la velocidad binaria entonces se pueden incluir preferentemente en la unidad de control de adaptaci6n de la velocidad 870 del emisor 800.

Un mecanismo de adaptaci6n de la velocidad para un c6dec de medios, es decir una pareja codificadordescodificador de medios, puede tener en cuenta una serie de informes de medici6n distintos o parametros de informaci6n de la sesi6n cuando se determina la velocidad binaria de transmisi6n 6ptima actual, es decir la velocidad

binaria adaptada. Esto se ilustra en la Figura 9 que muestra un emisor 900 de acuerdo con una cuarta realizaci6n de la presente invenci6n. La funci6n general del emisor 900 en esta realizaci6n es la misma que aquella del emisor 800 en la primera realizaci6n descrita con referencia a la Figura 8. Para los componentes para los cuales la descripci6n seria identica a aquella de la Figura 8, las referencias numericas son las mismas que en la Figura 8 y la descripci6n no se repite aqui. Una diferencia en esta cuarta realizaci6n es que la unidad de control de adaptaci6n de la velocidad 970 puede tener en cuenta una variedad de tipos o parametros de informaci6n cuando se determina una adaptaci6n de la velocidad a ser hecha, tal como la Velocidad de Perdida de Paquetes (PLR) determinada por los medios de determinaci6n de la PLR 905, la Fluctuaci6n determinada por los medios de determinaci6n de la Fluctuaci6n 915, los mensajes de Realimentaci6n de Red (NF) determinados por los medios de determinaci6n de la NF 940 y los ajustes de Aplicaci6n determinados por los medios de determinaci6n de los ajustes de Aplicaci6n 920. La informaci6n de realimentaci6n de red puede observar un cambio en los parametros de Calidad de Servicio y la informaci6n de los ajustes de Aplicaci6n pueden ser preferencias de servicio que dependen de las capacidades m6viles. La informaci6n con respecto a la Velocidad de Perdida de Paquetes (PLR), la Fluctuaci6n, los mensajes de realimentaci6n de Red y los ajustes de Aplicaci6n se puede determinar o poner a disposici6n a traves de distintos informes de medici6n o parametros de informaci6n de sesi6n y se proporciona a la unidad de control de adaptaci6n de la velocidad 970 en una entrada 860 junto con la gama de velocidad binaria de la sesi6n valida determinada por los medios de determinaci6n de la gama de velocidad binaria 820, la velocidad binaria transmitida actualmente determinada por los medios de determinaci6n de la velocidad binaria 840 y las peticiones recibidas por los medios de recepci6n de petici6n de velocidad 850 desde el receptor 700, cuyas peticiones pueden incluir ademas una adaptaci6n de la velocidad binaria estimada. La unidad de control de la adaptaci6n de la velocidad 870 entonces tiene en cuenta la variedad de distintos tipos o parametros de informaci6n y cualquier adaptaci6n de la velocidad binaria estimada desde el receptor 700 para determinar una adaptaci6n de la velocidad a ser hecha. Como consecuencia de considerar mas informaci6n en este sentido, la influencia de la adaptaci6n de la velocidad binaria estimada por el receptor 700 en la velocidad binaria adaptada fijada por el emisor 900 se puede esperar que llegue a ser mas pequena.

Con referencia de nuevo a la segunda realizaci6n, la petici6n de adaptaci6n de la velocidad se puede interpretar en esta realizaci6n por el emisor como una instrucci6n u orden para ajustar la velocidad binaria transmitida actualmente como se especifica por la adaptaci6n de la velocidad binaria estimada incluida en la petici6n de adaptaci6n de la velocidad. Los medios de estimaci6n de petici6n de velocidad binaria 770 se podrian generalizar en una variaci6n de esta realizaci6n para tener en cuenta una variedad de tipos o parametros de informaci6n cuando se determina una adaptaci6n de la velocidad estimada a ser hecha, tal como la Velocidad de Perdida de Paquetes (PLR), la Fluctuaci6n, los mensajes de realimentaci6n de Red y los ajustes de Aplicaci6n.

Para resumir, se han tratado 4 realizaciones del mecanismo de control de adaptaci6n de la velocidad:

1.: La primera realizaci6n: El receptor 700 estima una adaptaci6n de la velocidad binaria en base a una velocidad binaria recibida actualmente 740 y una gama de velocidad binaria de la sesi6n valida 720 y envia una petici6n de adaptaci6n de la velocidad 480 que puede incluir la adaptaci6n de la velocidad binaria estimada al emisor 800. El emisor determina una nueva velocidad binaria adaptada para la transmisi6n al receptor. Para la versi6n cuando la adaptaci6n de la velocidad binaria estimada se incluye la petici6n de adaptaci6n de la velocidad desde el receptor, el emisor puede elegir si seguir o no la adaptaci6n de la velocidad binaria requerida por el receptor.

2.: La segunda realizaci6n: El receptor 700 estima una adaptaci6n de la velocidad binaria en base a al menos una velocidad binaria recibida actualmente 740 y una gama de velocidad binaria de la sesi6n valida 720 y determina la adaptaci6n de la velocidad binaria a ser realizada. El receptor se puede generalizar ademas para tener en cuenta una variedad de tipos o parametros de informaci6n cuando se determina la adaptaci6n de la velocidad binaria a ser hecha. El receptor envia una petici6n de adaptaci6n de la velocidad 480 que especifica la adaptaci6n de la velocidad binaria al emisor 800. El emisor realiza la adaptaci6n de la velocidad binaria como se manda por el receptor.

3.: La tercera realizaci6n: El receptor 700 envia una petici6n de adaptaci6n de la velocidad 480 al emisor 800. El emisor estima una adaptaci6n de la velocidad binaria en base a una velocidad binaria transmitida actualmente 840 y una gama de velocidad binaria de la sesi6n valida 820 y determina una nueva velocidad binaria adaptada para la transmisi6n al receptor 700. El receptor puede haber estimado una adaptaci6n de la velocidad binaria, posiblemente para otros prop6sitos distintos a dar entrada al emisor, pero no se incluye en la petici6n de adaptaci6n de la velocidad al emisor.

4.: La cuarta realizaci6n: El receptor 700 envia una petici6n de adaptaci6n de velocidad 480 al emisor 900 que puede incluir una adaptaci6n de la velocidad binaria sugerida en base a una adaptaci6n de la velocidad binaria estimada realizada por el receptor 700 en base a una velocidad binaria recibida actualmente 740 y una gama de velocidad binaria de la sesi6n valida 720. El emisor estima una adaptaci6n de la velocidad binaria en base a una velocidad binaria transmitida actualmente 840 y una gama de velocidad binaria de la sesi6n valida 820 ademas de una variedad de tipos o parametros de informaci6n determinados o puestos a disposici6n a traves de distintos informes de medici6n o parametros de informaci6n de sesi6n. Si una adaptaci6n de la velocidad binaria sugerida se incluye en la petici6n de adaptaci6n de la velocidad 480 tambien se puede usar como una entrada o

sustituir partes de la informaci6n, por ejemplo la velocidad binaria transmitida actualmente 840 y la gama de velocidad binaria de la sesi6n valida 820, considerada por el emisor 900 cuando se determina la adaptaci6n de la velocidad binaria a ser realizada.

La Figura 10 muestra un diagrama de flujo de un ejemplo de un algoritmo de control de la velocidad que esta ejecutandose en un cliente ejemplar con una aplicaci6n que puede actuar como un receptor y un emisor. El proceso comienza en el establecimiento de una sesi6n en el paso 1000. Los primeros parametros del ancho de banda de la sesi6n se negocian para determinar una velocidad binaria de la sesi6n maxima bmax y una velocidad binaria de la sesi6n minima bmin en el paso 1010. Entonces en 1020 una velocidad binaria transmitida actualmente bcurr se fija a bmax o a un valor menor que bmax. A partir de entonces una velocidad binaria recibida actualmente brecv se fija a bmax o a un valor inferior a bmax en 1030. Los datos, por ejemplo los medios codificados, se transmiten entonces a la velocidad binaria transmitida actualmente bcurr en 1040. En 1050 el algoritmo comprueba la recepci6n de un mensaje de notificaci6n de congesti6n. Si no se ha recibido tal mensaje, el algoritmo pasa al paso 1090. Si no obstante se determina que se ha recibido un mensaje de notificaci6n de congesti6n, un valor de petici6n de velocidad binaria, es decir una adaptaci6n de la velocidad binaria, se estima en el paso 1060. Entonces en 1070 se transmite una petici6n de velocidad, es decir una petici6n de adaptaci6n de la velocidad, a un emisor en otro cliente. La petici6n de adaptaci6n de la velocidad puede especificar o sugerir una adaptaci6n de la velocidad binaria. En este ejemplo, la adaptaci6n de la velocidad binaria se expresa como una petici6n de la velocidad binaria transmitida breqsend. Entonces en 1080 la velocidad binaria recibida actualmente brecv se fija a breqsend cuando se confirma, por ejemplo analizando la velocidad binaria recibida, que el emisor en el otro cliente ha adaptado la velocidad binaria transmitida. En este ejemplo el emisor en el otro cliente adapta la velocidad binaria transmitida de acuerdo con la petici6n por el receptor en el cliente ejemplar. El proceso entonces pasa a 1090, donde el algoritmo comprueba si se ha recibido una petici6n de velocidad, es decir una petici6n de adaptaci6n de la velocidad, desde un receptor en el otro cliente. Si no se ha recibido tal petici6n, el proceso pasa al paso 1098. Si no obstante se determina que se ha recibido una petici6n de velocidad, es decir una petici6n de adaptaci6n de la velocidad, entonces en un paso 1094 la velocidad binaria transmitida actualmente bcurr se fija o adapta a la petici6n de velocidad binaria recibida breqrecv que se ha recibido en este ejemplo en la petici6n de la velocidad desde el receptor en el otro cliente. El proceso entonces continua en el paso 1098, donde se hace una comprobaci6n en cuanto a si la sesi6n esta terminada. En caso negativo, el proceso continua en el paso 1040, transmitiendo datos a la velocidad binaria transmitida actualmente bcurr. Si por otra parte la sesi6n esta terminada, el proceso se detiene en el paso 1099.

La Figura 11 muestra un diagrama de flujo para la parte de estimaci6n de la velocidad binaria hecha en el paso 1060 del proceso mostrado en la Figura 10 en mas detalle. El proceso comienza en el paso 1100. En el paso 1100 se recibe un mensaje de notificaci6n de congesti6n, tambien llamado mensaje ECN, por ejemplo desde un recurso compartido. El mensaje se transporta fijando los bits de ECN en una cabecera IP de un paquete transmitido. Entonces en el paso 1120 una velocidad binaria recibida actualmente brecv se compara con un limite superior de sesi6n o velocidad binaria de la sesi6n maxima bmax y un limite inferior de sesi6n o velocidad binaria de la sesi6n minima bmin. Entonces, si se determina en el paso 1130 que la velocidad binaria recibida actualmente brecv es mayor que el limite inferior de la sesi6n o la velocidad binaria de la sesi6n minima bmin, una nueva velocidad binaria recibida requerida, es decir la adaptaci6n de la velocidad binaria expresada como una petici6n de la velocidad binaria transmitida breqsend, se calcula en 1140. El proceso entonces se detiene en 1150. Si por otra parte, se determina en el paso 1130 que la velocidad binaria recibida actualmente brecv esta ya en el limite inferior de la sesi6n o la velocidad binaria de sesi6n minima bmin, el proceso se detiene en 1150 y no se realiza ninguna adaptaci6n de velocidad adicional.

La Figura 12 muestra un diagrama de flujo de la sesi6n para un Usuario A 1200 y un Usuario B 1210 que estan comunicando a traves de un nodo de red capaz de ECN es decir un recurso compartido 1220. En un primer paso 1225 los mensajes de senalizaci6n se intercambian entre el Usuario A y el Usuario B en un procedimiento de negociaci6n de la sesi6n, por ejemplo a traves de SIP/SDP, para determinar una gama de velocidad binaria de la sesi6n especificada por un limite superior de sesi6n o velocidad binaria de la sesi6n maxima bmax kilobits por segundo (Kbps) y un limite inferior de sesi6n o velocidad binaria de la sesi6n minima bmin kbps. Entonces en un paso 1230 se intercambia un flujo de medios bidireccional simultaneo usando una velocidad binaria transmitida actualmente bcurr que se fija a la velocidad binaria de sesi6n maxima bmax para las transmisiones en ambas direcciones, es decir desde el Usuario A al Usuario B y desde el Usuario B al Usuario A. En un siguiente paso 1240 el recurso compartido 1220 envia un mensaje de ECN al Usuario B 1210, ajustando los bits ECN en una cabecera IP de un paquete transmitido. En el paso 1250 el Usuario B responde al mensaje de ECN enviando una petici6n, es decir una petici6n de adaptaci6n de la velocidad, al Usuario A para bajar su velocidad binaria de transmisi6n para las transmisiones al Usuario B. El Usuario A entonces responde adaptando la velocidad binaria de transmisi6n para las transmisiones desde el Usuario A al Usuario B de manera que en el paso1260 se intercambie un flujo de medios bidireccional simultaneo entre el Usuario A y el Usuario B a una velocidad binaria transmitida actualmente bcurr de la velocidad binaria de sesi6n maxima bmax desde el Usuario B al Usuario A y a una velocidad binaria transmitida actualmente bcurr que esta entre medias del limite inferior de sesi6n o velocidad binaria de sesi6n minima bmin y el limite superior o velocidad binaria de la sesi6n maxima bmax desde el Usuario A al Usuario B. En un siguiente paso 1270 el recurso compartido 1220 envia un mensaje de ECN al Usuario A 1200, ajustando los bits de ECN en una cabecera IP de un paquete transmitido. En el paso 1280 el Usuario A responde al mensaje de ECN enviando una petici6n, es decir una petici6n de adaptaci6n de velocidad, al Usuario B para bajar su velocidad binaria de

transmisi6n para las transmisiones al Usuario A. El Usuario B entonces responde adaptando la velocidad binaria de transmisi6n para las transmisiones desde el Usuario B al Usuario A de manera que en el paso 1290 se intercambie un flujo de medios bidireccional simultaneo usando una velocidad binaria transmitida actualmente bcurr que esta entre medias del limite inferior de sesi6n o velocidad binaria de sesi6n minima bmin y el limite superior o velocidad binaria de sesi6n maxima bmax para las transmisiones en ambas direcciones, es decir desde el Usuario A al Usuario B y desde el Usuario B al Usuario A. Finalmente, en el paso 1295, los mensajes de senalizaci6n se intercambian entre el Usuario A y el Usuario B para terminar la sesi6n, por ejemplo usando el protocolo SIP. En este ejemplo los usuarios A y B tienen el mismo algoritmo de adaptaci6n de velocidad en sus respectivos Equipos de Usuario, lo que significa que cuando sucede la congesti6n en la direcci6n de A a B la adaptaci6n de la velocidad binaria es la misma que cuando sucede la congesti6n en la direcci6n de B a A. Este no tiene que ser el caso si los ajustes de aplicaci6n

o las capacidades del UE son distintos en el UE del Usuario A que en el UE del Usuario B.

El mecanismo de control de la velocidad se puede aplicar para controlar la velocidad binaria de un codificador de medios asi como para controlar la velocidad binaria de un flujo de medios en el nivel de sesi6n. Para algunas aplicaciones que usan mas de un tipo de medios, por ejemplo audio y video, los flujos de medios de los distintos tipos de medios se pueden multiplexar o combinar en un flujo de medios de sesi6n o flujo de transporte IP que se envia en una sesi6n desde un emisor a un receptor. Para tal aplicaci6n, la unidad de control de adaptaci6n se puede configurar para ser aplicada en el nivel de sesi6n para controlar la velocidad binaria del flujo de medios de sesi6n que se saca para la transmisi6n desde o a traves de por ejemplo un multiplexor que recibe como entrada los flujos de medios codificados que se sacan de los codificadores de medios respectivos de distintos tipos. De una forma similar, los medios de estimaci6n de la velocidad binaria se pueden configurar para estimar una adaptaci6n de la velocidad binaria para un flujo de medios de sesi6n que consta de flujos de medios de distintos tipos de medios.

El siguiente ejemplo ilustra el control de la velocidad binaria de los flujos de medios en el nivel de sesi6n para al menos dos aplicaciones cada una que emplea los medios de dos tipos de medios distintos. No obstante, el metodo y adaptaci6n tambien aplica para las aplicaciones que emplean medios de mas de dos tipos de medios distintos. En este ejemplo al menos una primera sesi6n para una primera aplicaci6n y una segunda sesi6n para una segunda aplicaci6n se han puesto en marcha para la comunicaci6n en un sistema de comunicaciones de paquetes conmutados donde multiples sesiones para multiples partes que ejecutan aplicaciones se pueden poner en marcha a traves de un recurso compartido. Un primer flujo de medios codificado de un primer tipo de medio, por ejemplo audio, desde un primer codificador de medios y un segundo flujo de medios codificado de un segundo tipo de medio, por ejemplo video, desde un segundo codificador de medios se multiplexan por un primer multiplexor en un primer flujo de medios de sesi6n que se transmite en la primera sesi6n desde un primer emisor a un primer receptor. Ademas, un tercer flujo de medios codificado de un tercer tipo de medio, por ejemplo voz, desde un tercer codificador de medios y un cuarto flujo de medios codificado de un cuarto tipo de medio, por ejemplo datos, desde un cuarto codificador de medios se multiplexa por un segundo multiplexor en un segundo flujo de medios de sesi6n que se transmite en la segunda sesi6n desde un segundo emisor a un segundo receptor. El primer y segundo codificadores de medios y el primer multiplexor estan o pueden estar incluidos en la primera aplicaci6n, y el tercer y cuarto codificadores de medios y el segundo multiplexor estan o pueden estar incluidos en la segunda aplicaci6n. La primera aplicaci6n incluye ademas una primera unidad de control de adaptaci6n de la velocidad que se conecta con el primer y segundo codificadores de medios y con el primer multiplexor y que sirve para controlar la velocidad, por ejemplo la velocidad binaria, del primer flujo de medios de la sesi6n. Igualmente, la segunda aplicaci6n incluye ademas una segunda unidad de control de adaptaci6n de la velocidad que se conecta con el tercer y cuarto codificadores de medios y que sirve para controlar la velocidad, por ejemplo la velocidad binaria, del segundo flujo de medios de la sesi6n.

Una primera gama de velocidad binaria se determina que sea valida para la primera sesi6n y una segunda gama de velocidad binaria se determina que sea valida para la segunda sesi6n. La primera unidad de control de adaptaci6n de velocidad se ha configurado para comparar una primera velocidad binaria actual que se usa actualmente en la primera sesi6n con dicha primera gama de velocidad binaria para determinar una primera distancia a un limite o punto final de la primera gama de velocidad binaria, es decir al limite superior o al limite inferior de la primera gama de velocidad binaria, y la segunda unidad de control de adaptaci6n de velocidad se ha configurado para comparar una segunda velocidad binaria actual que se usa actualmente en la segunda sesi6n con dicha segunda gama de velocidad binaria para determinar una segunda distancia a un limite o punto final de la segunda gama de velocidad binaria, es decir al limite superior o al limite inferior de la segunda gama de velocidad binaria. La primera y segunda unidades de control de adaptaci6n de velocidad se configuran ademas para adaptar la primera velocidad binaria actual y la segunda velocidad binaria actual de manera diferente dependiendo de la primera y segunda distancia, es decir para adaptar las velocidades binarias respectivas mediante cantidades que dependen del tamano de la respectiva distancia .

Como se mencion6 antes, la medida tomada cuando se recibe un mensaje de notificaci6n de congesti6n se basa en relacionar el mensaje de notificaci6n de congesti6n con la velocidad binaria de transmisi6n actual. La ponderaci6n de la notificaci6n de congesti6n, es decir la cantidad de adaptaci6n de la velocidad binaria requerida desde el emisor como respuesta a la notificaci6n de congesti6n, se hace investigando la relaci6n entre la velocidad binaria actual y la gama de velocidad binaria valida para la sesi6n. La Figura 13 muestra una ponderaci6n ejemplo de la acci6n adaptativa desencadenadora de la ECN en base a la velocidad binaria actual y la gama de velocidad binaria de la sesi6n. En este ejemplo la ponderaci6n daria un 40� de reducci6n en la velocidad binaria cuando la velocidad binaria recibida actual es igual a bmax y una reducci6n cero cuando la velocidad binaria recibida actual se ha reducido a bmin.

La estimaci6n de la reducci6n de la velocidad binaria se puede hacer de varias formas distintas. Dependiendo de los valores reales (es decir la anchura) de la gama de velocidad binaria serian adecuadas distintas ponderaciones. Una f6rmula de ponderaci6n exponencial ejemplo se muestra en la Ecuaci6n 1, que muestra una ecuaci6n de ponderaci6n exponencial.

Esta ponderaci6n daria una reducci6n inicial del 50� en la velocidad binaria cuando la velocidad binaria recibida actual es igual a bmax y una reducci6n cero si la sesi6n ya esta en bmin.

10 La Figura 14 ilustra en un despliegue LTE, tal como el sistema mostrado en la Figura 5, un nivel de carga en el NodoB mejorado (eNB) como un recurso compartido, es decir que proporciona un canal de transmisi6n compartido, que puede fijar los bits de ECN. En el ejemplo, se usa un esquema de ponderaci6n que da una reducci6n del 50� cuando se ejecuta a bcurr�bmax y una reducci6n del 10� cuando se ejecuta a bcurr�0,5�bmax.

Los eventos mostrados en la tabla de mas abajo tienen lugar:

Tiempo, t: Eventos

t�T0: Se establece una sesi6n entre los usuarios B y C. Velocidad binaria de transmisi6n desde el usuario B a C bcurr�bmax.

t�T1: El eNB experimenta congesti6n y fija los bit de ECN en un flujo IP que va desde B a C, El usuario C recibe los bit de ECN y transmite una petici6n de reducci6n de la velocidad del 50� a B. B baja su velocidad binaria de transmisi6n por consiguiente.

t�T2: Se establece una nueva sesi6n entre los usuarios A y D. Velocidad binaria de transmisi6n desde el usuario A a D, bcurr�bmax. Senalar que el usuario B esta aun transmitiendo a 0,5�bmax.

t�T3: El eNB experimenta congesti6n y fija los bit de ECN en un flujo IP que va desde B a C y en el flujo que va desde A a D. El usuario C recibe los bits de ECN y transmite una petici6n de reducci6n de la velocidad del 10� a B dado que B ya esta ejecutando a una velocidad reducida. B baja su velocidad binaria de transmisi6n por consiguiente. El usuario D tambien recibe los bits de ECN pero transmite una petici6n de reducci6n de velocidad del 50� a A dado que el usuario A esta transmitiendo a la velocidad binaria de sesi6n maxima y deberia por lo tanto reducir en un 50�.

t�T3: Ambas sesiones se ejecutandose ahora a velocidades reducidas pero con calidad similar. La adaptaci6n hacia arriba lenta podria comenzar ahora para intentar restaurar la velocidad binaria de la sesi6n a bmax.

15 Teniendo en cuenta la velocidad binaria actual cuando se determina la acci6n adaptativa, el cliente tendra una responsabilidad mayor para aliviar la situaci6n de congesti6n en la red si su velocidad binaria actual esta cerca del limite superior de la gama de velocidad binaria de la sesi6n. En este sentido, los clientes distribuiran las acciones adaptativas de una forma justa entre ellos mismos sin castigar a los clientes que ya han tenido una responsabilidad mayor de aliviar la congesti6n en la red. Ademas, tambien tiene el beneficio de distribuir la funcionalidad a los

20 clientes que eliminan el requisito de hacer el seguimiento del usuario y el conocimiento del servicio en el nodo de red congestionado, por ejemplo el eNB o un encaminador. Este esquema se puede extender ademas a hacer frente a distintas propiedades de abonado, por ejemplo "abonados econ6micos" y "abonados oro", por ejemplo para requerir menos adaptaci6n de la velocidad binaria de los "abonados oro", por ejemplo que pagan mas por el servicio, que de los "abonados econ6micos", por ejemplo los abonados que pagan menos por el servicio, y tambien con mas

25 ponderaci6n absoluta, es decir la adaptaci6n de la velocidad binaria expresada en cuantia de velocidad binaria absoluta o la adaptaci6n de la velocidad binaria a un valor de la velocidad binaria especificado si la velocidad binaria actual esta por encima de este valor, en base al valor absoluto de la velocidad binaria actual, no solamente el valor relativo para la gama de velocidad binaria de la sesi6n. Combinaciones de la ponderaci6n absoluta y relativa

tambien son concebibles, por ejemplo reducir siempre a un valor de la velocidad binaria absoluto si la velocidad binaria actual esta por encima de este valor, luego reducir mediante cantidades que relacionan la velocidad binaria actual con un limite de la gama de velocidad binaria.

Una ventaja de al menos algunas realizaciones de esta invenci6n es que resuelven el problema de la responsabilidad injusta entre clientes en un nodo de red congestionado para aliviar la congesti6n. Sin esta funcionalidad, ambos el usuario que ya se ha adaptado a la congesti6n de red asi como el nuevo usuario que no ha reducido el consumo de ancho de banda sera requeridos para reducir su velocidad binaria de transmisi6n en una forma igual. En el caso de una sesi6n recien establecida, que no ha tomado ninguna acci6n de alivio de la congesti6n, el usuario sufrira mucha menos reducci6n de calidad de medios comparado con un cliente que ya ha reducido su velocidad binaria debido a los mensajes de notificaci6n de congesti6n previos.

Con esta funcionalidad, por otra parte, la responsabilidad se comparte de una manera mas justa con una forma comun de acciones progresivas para aliviar la congesti6n cuanto mas cerca esta el usuario al limite superior de la velocidad binaria de la sesi6n.

Aunque el mecanismo de adaptaci6n de la velocidad de la presente invenci6n se ha descrito como una respuesta a un mensaje de notificaci6n de congesti6n expedido por un recurso compartido a un receptor de una secuencia de medios de paquetes conmutados que se transmite a traves del recurso compartido, es igualmente aplicable tambien en otras circunstancias donde los datos o medios fuente sometidos a los requerimientos de transmisi6n en tiempo real se transmiten sobre una red de paquetes conmutados desde un emisor a un receptor y donde el receptor de los datos o medios fuente necesita requerir una adaptaci6n de la velocidad de transmisi6n desde el emisor de los datos

o medios fuente. Por ejemplo, el mecanismo de adaptaci6n de la velocidad se puede invocar por un mensaje de notificaci6n de congesti6n en otra capa o por otro mensaje distinto de un mensaje de notificaci6n de congesti6n recibido desde el recurso compartido. Un mensaje tal podria ser un mensaje "congesti6n aliviada", en cuyo caso el mecanismo de adaptaci6n de la velocidad se puede usar para aumentar la velocidad de transmisi6n en una forma equilibrada. Por ejemplo, esto se puede hacer de manera que las partes que han experimentado las reducciones mas grandes en la velocidad binaria obtengan aumentos mas grandes que las partes para las que se han hecho reducciones de velocidad binaria mas pequenas. Esto significa que la velocidad binaria actual, o la velocidad binaria transmitida actualmente, se aumentaria mas si esta mas cerca del limite inferior de la gama de velocidad binaria que si esta mas cerca del limite superior de la gama de velocidad binaria. Ademas, la estimaci6n de la adaptaci6n de la velocidad binaria se haria de manera que la velocidad binaria recibida actualmente se aumente mas si esta mas cerca del limite inferior de la gama de velocidad binaria que si esta mas cerca del limite superior de la gama de velocidad binaria.

El mensaje tambien se puede recibir desde otro recurso de red que tenga buen conocimiento sobre las condiciones de la red, suponiendo por ejemplo que otro nodo ajusta los bits de ECN

Claims

REIVINDICACIONES

1. Un metodo para controlar una velocidad binaria de una sesi6n entre un emisor (1200) y un receptor (1210) en un sistema de comunicaciones de paquetes conmutados donde se establecen multiples sesiones a traves de un recurso compartido (1220), dicho metodo que comprende los pasos de:

5 determinar (1010, 1225) una gama de velocidad binaria valida para la sesi6n, la gama de velocidad binaria que tiene un limite superior y un limite inferior;

recibir (1090, 1250) un mensaje de petici6n de adaptaci6n de la velocidad desde el receptor;

comparar una velocidad binaria actual de dicha sesi6n con dicha gama de velocidad binaria;

en el que el metodo se caracteriza porque comprende los pasos de:

10 adaptar (1094, 1260) dicha velocidad binaria actual de manera que la velocidad binaria actual se reduce mas si esta mas cerca del limite superior de la gama de velocidad binaria que si esta mas cerca del limite inferior de la gama de velocidad binaria o de manera que la velocidad binaria actual se aumenta mas si esta mas cerca del limite inferior de la gama de velocidad binaria que si esta mas cerca del limite superior de la gama de velocidad binaria.

15 2. El metodo de acuerdo con la reivindicaci6n 1, en el que el receptor (1210) envia dicho mensaje de petici6n de adaptaci6n de velocidad tras la recepci6n de un mensaje desde un recurso de red.
3.

El metodo de acuerdo con la reivindicaci6n 2, en el que dicho mensaje desde el recurso de red es un mensaje de notificaci6n de congesti6n.
4.

El metodo de acuerdo con la reivindicaci6n 2, en el que dicho recurso de red es el recurso compartido (1220).

20 5. El metodo de acuerdo con la reivindicaci6n 1, en el que dicho paso de determinar (1010, 1225) una gama de velocidad binaria ademas comprende senalizar la gama de velocidad binaria en un procedimiento de establecimiento de la sesi6n.
6. El metodo de acuerdo con la reivindicaci6n 1, en el que el Protocolo de Datagrama de Usuario con Notificaci6n de Congesti6n Explicita se usa para la comunicaci6n en la sesi6n.

25 7. El metodo de acuerdo con la reivindicaci6n 1, en el que dicho limite superior y dicho limite inferior para la gama de velocidad binaria se refieren a una concesi6n de Calidad de Servicio especifica para la sesi6n.
8. El metodo de acuerdo con la reivindicaci6n 1, en el que el paso de adaptar (1094, 1260) dicha velocidad binaria actual ademas comprende adaptar dicha velocidad binaria actual mediante una cantidad que depende de las propiedades del abonado.

30 9. El metodo de acuerdo con la reivindicaci6n 1, en el que el paso de adaptar (1094, 1260) dicha velocidad binaria actual ademas comprende adaptar dicha velocidad binaria actual mediante una cantidad absoluta o a un valor de velocidad binaria especifico si dicha velocidad binaria actual esta por encima del valor de velocidad binaria especificado.
10. Un receptor (700) para recibir los medios codificados de paquetes conmutados (710) que se transmiten por un 35 emisor (800, 900) en una sesi6n a traves de un recurso compartido (400), dicho receptor (700) que comprende:

los medios de determinaci6n de la gama de velocidad binaria (720) para determinar una gama de velocidad binaria valida para la sesi6n, la gama de velocidad binaria que tiene un limite superior y un limite inferior;

en el que dicho receptor se caracteriza porque comprende:

los medios de estimaci6n de la petici6n de velocidad binaria (770) para la estimaci6n de una adaptaci6n de

40 la velocidad binaria comparando una velocidad binaria recibida actualmente con dicha gama de velocidad binaria y estimar dicha adaptaci6n de velocidad binaria de manera que la velocidad binaria recibida actualmente se reduce mas si esta mas cerca del limite superior de la gama de velocidad binaria que si esta mas cerca del limite inferior de la gama de velocidad binaria o de manera que la velocidad binaria recibida actualmente se aumenta mas si esta mas cerca del limite inferior de la gama de velocidad binaria

45 que si esta mas cerca del limite superior de la gama de la velocidad binaria; y

los medios de petici6n de velocidad (790) para requerir a dicho emisor (800, 900) que adapte una velocidad binaria transmitida actualmente en dicha sesi6n.
11. El receptor (700) de acuerdo con la reivindicaci6n 10, en el que los medios de estimaci6n de la petici6n de

velocidad binaria (770) se han configurado para tener en cuenta al menos un tipo de informaci6n fuera de la 50 Velocidad de Perdida de Paquetes, la Fluctuaci6n, los mensajes de Realimentaci6n de Red y los ajustes de

Aplicaci6n para estimar la adaptaci6n de la velocidad binaria.
12. El receptor (700) de acuerdo con la reivindicaci6n 10, dicho receptor que ademas comprende:

los medios de detecci6n (750) para detectar un mensaje desde un recurso de red; y

en el que dichos medios de estimaci6n de la petici6n de velocidad binaria (770) estiman dicha adaptaci6n de la velocidad binaria tras la detecci6n de dicho mensaje desde el recurso de red.
13.

El receptor (700) de acuerdo con la reivindicaci6n 12, en el que dicho mensaje desde el recurso de red es un mensaje de notificaci6n de congesti6n.
14.

El receptor (700) de acuerdo con la reivindicaci6n 12, en el que dicho recurso de red es el recurso de red compartido (400).
15.

El receptor (700) de acuerdo con la reivindicaci6n 10, en el que dichos medios de petici6n de la velocidad (790) se han configurado para incluir dicha adaptaci6n de la velocidad binaria cuando se requiere a dicho emisor (800, 900) adaptar una velocidad binaria transmitida actualmente en dicha sesi6n.
16.

El receptor (700) de acuerdo con la reivindicaci6n 10, dicho receptor (700) que ademas comprende:

al menos un descodificador de medios (730) para descodificar dichos medios codificados (710) recibidos en dicha sesi6n.
17.

Un emisor (800, 900) para transmitir los medios codificados de paquetes conmutados (810) en una sesi6n a traves de un recurso compartido (400) a un receptor (700), dicho emisor (800, 900) que comprende:

los medios de determinaci6n de la gama de velocidad binaria (820) para determinar una gama de velocidad binaria valida para la sesi6n, la gama de velocidad binaria que tiene un limite superior y un limite inferior;

los medios de recepci6n (850) para recibir una petici6n desde dicho receptor (700) para adaptar una velocidad binaria de transmisi6n actualmente en dicha sesi6n; y

en el que dicho emisor esta caracterizado por:

una unidad de control de adaptaci6n de la velocidad (870, 970) para controlar, en respuesta a dicha petici6n desde dicho receptor (700), una adaptaci6n de la velocidad de la velocidad binaria transmitida actualmente en dicha sesi6n de manera que la velocidad binaria transmitidita actualmente se reduce mas si esta mas cerca del limite superior de la gama de velocidad binaria que si esta mas cerca del limite inferior de la gama de velocidad binaria o de manera que la velocidad binaria transmitida actualmente se aumenta mas si esta mas cerca del limite inferior de la gama de velocidad binaria que si esta mas cerca del limite superior de la gama de velocidad binaria.
18.

El emisor (800, 900) de acuerdo con la reivindicaci6n 17, en el que dicha petici6n para adaptar una velocidad binaria transmitida actualmente se envia por dicho receptor (700) tras la recepci6n de un mensaje desde un recurso de red.
19.

El emisor (800, 900) de acuerdo con la reivindicaci6n 18, en el que dicho mensaje desde el recurso de red es un mensaje de notificaci6n de congesti6n.
20.

El emisor (800, 900) de acuerdo con la reivindicaci6n 18, en el que dicho recurso de red es el recurso de red compartido (400).
21.

El emisor (800, 900) de acuerdo con la reivindicaci6n 17, en el que la unidad de control de adaptaci6n de la velocidad (870, 970) se ha configurado para determinar dicha adaptaci6n de velocidad de la velocidad binaria transmitida actualmente en dicha sesi6n comparando la velocidad binaria transmitida actualmente con la gama de velocidad binaria.
22.

El emisor (800, 900) de acuerdo con la reivindicaci6n 17, en el que una adaptaci6n de la velocidad binaria estimada se incluye en la petici6n desde dicho receptor para adaptar la velocidad binaria transmitida actualmente, y en el que la unidad de control de adaptaci6n de la velocidad (870, 970) se ha configurado para usar la adaptaci6n de la velocidad binaria estimada como una entrada para determinar dicha adaptaci6n de velocidad de la velocidad binaria transmitida actualmente en dicha sesi6n.
23.

El emisor (800, 900) de acuerdo con la reivindicaci6n 17, en el que la unidad de control de adaptaci6n de la velocidad (870, 970) se ha configurado para tener en cuenta al menos un tipo de informaci6n fuera de la Velocidad de Perdida de Paquetes, la Fluctuaci6n, los mensajes de Realimentaci6n de Red y los ajustes de Aplicaci6n para estimar la adaptaci6n de la velocidad binaria.
24.

El emisor (800, 900) de acuerdo con la reivindicaci6n 17, dicho emisor (800, 900) que ademas comprende:

al menos un codificador de medios (830) para sacar dichos medios codificados (810) a ser transmitidos en dicha sesi6n.
25.

Un sistema de comunicaciones de paquetes conmutados para controlar las velocidades binarias de al menos una primera y segunda sesi6n, dicho sistema que comprende al menos un primer emisor (500, 800, 900) operable

5 para comunicar con un primer receptor (530, 700) a traves de un recurso compartido (550, 560) en la primera sesi6n y un segundo emisor (520, 800, 900) operable para comunicar con un segundo receptor (510, 700) a traves del recurso compartido (550, 560) en la segunda sesi6n, dicho sistema que ademas comprende:

los primeros medios de determinaci6n de la gama de velocidad binaria (820) para determinar una primera gama de velocidad binaria valida para la primera sesi6n, la primera gama de velocidad binaria que tiene un limite

10 superior y un limite inferior;

los segundos medios de determinaci6n de la gama de velocidad binaria (820) para determinar una segunda gama de velocidad binaria valida para la segunda sesi6n, la segunda gama de velocidad binaria que tiene un limite superior y un limite inferior;

una primera unidad de control de adaptaci6n de la velocidad (870, 970) para controlar la adaptaci6n de la

15 velocidad de una primera velocidad binaria actual de dicha primera sesi6n de manera que la primera velocidad binaria se reduce mas si esta mas cerca del limite superior de la primera gama de velocidad binaria que si esta mas cerca del limite inferior de la primera gama de velocidad binaria o de manera que la primera velocidad binaria actual se aumenta mas si esta mas cerca del limite inferior de la primera gama de velocidad binaria que si esta mas cerca del limite superior de la primera gama de velocidad binaria; y

20 una segunda unidad de control de adaptaci6n de la velocidad (870, 970) para controlar la adaptaci6n de la velocidad de una segunda velocidad binaria actual de dicha segunda sesi6n de manera que la segunda velocidad binaria se reduce mas si esta mas cerca del limite superior de la segunda gama de velocidad binaria que si esta mas cerca del limite inferior de la segunda gama de velocidad binaria o de manera que la segunda velocidad binaria actual se aumenta mas si esta mas cerca del limite inferior de la segunda gama de velocidad

25 binaria que si esta mas cerca del limite superior de la segunda gama de velocidad binaria.
26. El sistema de acuerdo con la reivindicaci6n 25, en el que dichas primera y segunda unidades de control de adaptaci6n de la velocidad (870, 970) se desencadenan por la recepci6n de un mensaje de petici6n de adaptaci6n de velocidad.