ES2260651T3 - Generacion de informes para servicios multiusuario en redes inalambricas. - Google Patents

Abstract

Un método para la adaptación de datos multimedia multiusuario en un sistema de comunicaciones con un servidor que proporciona los datos multimedia multiusuario a clientes, y con una parte de red intermedia, caracterizado porque dicha parte de red intermedia proporciona información sobre el sistema de comunicaciones entre el servidor y los clientes, y dicho método comprende las operaciones de: cursar información de flujo de datos desde el servidor hacia los clientes; determinar las características de distribución asociadas con los clientes; en dicha parte de red intermedia, generar informes de realimentación agregados sobre las condiciones de recepción del flujo de transferencia de datos por los clientes considerando las características de distribución, en cuya operación dicho informe de realimentación incluye información relativa al modo de agregación; enviar al servidor el informe de realimentación agregado; y adaptar la transmisión del flujo de datos desde el servidor hasta los clientes de acuerdo con el informe de realimentación agregado.

Description

Generación de informes para servicios multiusuario en redes inalámbricas.

Campo técnico del invento

El presente invento se refiere a un método para multidifusión en una red de telecomunicaciones.

Especialmente, el presente invento es aplicable a una red de telecomunicaciones punto a punto de paquetes conmutados.

Antecedentes

El sistema UMTS (Universal Mobile Telecommunication System: sistema universal de telecomunicaciones móviles) se está desarrollando para ofrecer servicio multimedia de banda ancha inalámbrico utilizando protocolo de Internet. El sistema UMTS, como sistema de comunicaciones móviles 3G de tercera generación, combina la transferencia de flujo con una gama de servicios singulares, por ejemplo el posicionamiento geográfico, para proporcionar a los usuarios un contenido de Internet de alta calidad. Los contenidos de imágenes, voz, audio y vídeo son ejemplos de servicios móviles multimedia, que son suministrados a los usuarios mediante técnicas de transferencia de flujo y de descarga. Esto significa que una vez que el contenido se ha situado en un servidor multimedia, puede ser suministrado bajo demanda mediante descarga o transferencia de flujo simultáneas. Para descargar el contenido, el usuario marca con el ratón un enlace y espera la descarga del contenido y el inicio de la reproducción. Las capacidades de descarga son fáciles de integrar puesto que puede utilizarse el protocolo http (hypertest transfer protocol: protocolo de transferencia de hipertexto) para descargar archivos. Para acceder a datos de grabación-reproducción o, hablando en general, a datos multimedia, el usuario marca con el ratón un enlace para iniciar la reproducción, que es casi inmediata. Debido a que la técnica de transferencia de flujo corresponde a un servicio en tiempo semireal que recibe y reproduce datos al mismo tiempo, impone demandas más exigentes en la implementación de protocolos y servicios, especialmente cuando los servicios han de funcionar sobre redes con poca o ninguna calidad de servicio, como es el caso del sistema UMTS. Los recursos de radio, que se utilizan en la última parte de una transmisión, han de ser usados de un modo más idóneo.

Actualmente se están realizando trabajos para introducir la radiodifusión y multidifusión en redes inalámbricas WCDMA y GSM. Tanto la difusión como la multidifusión proporcionan eficiencia de transporte y reducen la carga de los servidores de contenidos, por ejemplo los servidores de datos de transferencia de flujo. Adicionalmente, se está trabajando en soluciones para realizar la transmisión de flujo o transmisión de datos multimedia formulada en general en una red inalámbrica. A continuación se presentan las arquitecturas correspondientes.

La figura 1 muestra la arquitectura actualmente denominada MBMS (Multimedia Broadcast/
Multicast Service: servicio de radiodifusión/multi-
difusión de ficheros multimedia). Se mencionan a continuación meramente los nodos más importantes y ejemplos de las diferentes redes de acceso, como UTRAN, GERAN, que establecen conexión con el usuario final. Las redes de acceso son manejadas por medio de un nodo de servicio (SGSN) que establece comunicación con un nodo de borde GGSN que es responsable de la conexión a las redes externas, como la red Internet. La entidad BM-SC conectada al nodo GGSN es responsable de proporcionar la multidifusión/radiodifusión, por ejemplo para el establecimiento de portadores y transmisión de datos. La entidad BM-SC ofrece unidades de interfaz con un suministrador de contenidos, de modo que dicho suministrador de contenidos puede solicitar a los usuarios la entrega de datos. La entidad BM-SC puede autorizar y hacer cargos a los suministradores de conteni-
dos.

Con el fin de aplicar de un modo sencillo la solución, se prevé actualmente que la parte de red de radio soporte solamente un canal descendente para tráfico de datos hacia el usuario final (UE). Esto significa que no existe un canal ascendente en una red de acceso, que pueda ser utilizado por los usuarios finales para enviar, por ejemplo, informes relativos a la calidad de la recepción.

La transmisión del flujo multimedia para un solo usuario se realiza en una red inalámbrica por medio de una arquitectura de Flujo de Paquetes Conmutados. Dicha arquitectura se ilustra en la figura 2. Dicha figura muestra un cliente de servicio de transferencia de flujo que está conectado, a través de una red de acceso, tal como las redes UTRAN y GERAN, con una red de núcleo UMTS. En el sistema UMTS se ilustran dos tipos importantes de nodos, a saber los nodos SGSN y GGSN. El primero de ellos es un nodo de servicio para el manejo de los usuarios asociados a las redes de acceso. El nodo GGSN es responsable de la conexión a las redes externas, como la red IP (protocolo de Internet). Con el fin de suministrar contenidos multimedia, existen tres entidades diferentes en la red IP, como un servidor de contenidos que es responsable de suministrar datos multimedia.

Los datos multimedia se distribuyen por medio de protocolos multimedia. La figura 3 muestra una pila de protocolos con las capas de protocolo responsables de la transmisión multimedia, relativas al protocolo RTP (Real-time Transport Protocol: protocolo de transporte en tiempo real). El protocolo RTP utiliza el protocolo UDP (Universal Datagram Protocol) como protocolo de transporte adecuado para la transmisión de datos de transferencia de flujo, porque el protocolo UDP proporciona una transmisión rápida aunque no fiable, como en el caso del protocolo TCP (Transmission Control Protocol: protocolo de control de transmisión). Los protocolos HTTP y RTSP funcionan sobre el protocolo fiable TCP. El protocolo RTSP proporciona control de sesión para sesiones de transferencia de flujo. El protocolo HTTP se utiliza para la transmisión de imágenes sin movimiento, gráficos de mapa de bits y texto.

El protocolo RTP proporciona funciones de transporte de red de extremo a extremo adecuadas para aplicaciones que transmiten datos en tiempo real, tales como datos de audio, vídeo o simulación, a través de servicios de red multidifusión o unidifusión. Las funciones proporcionadas por el protocolo RTP incluyen la identificación de tipo de carga de pago, numeración de secuencia, asignación de marcas indicadoras de tiempo y vigilancia de entrega. El protocolo RTP contiene un protocolo RTCP relacionado con el protocolo RTP que mejora el transporte de datos, que se utiliza para vigilar la calidad de servicio y transportar información relativa a los participantes en una sesión en curso. Cada cadena de datos multimedia en una conferencia se transmite como sesión RTP independiente con una cadena de datos RTCP independiente.

El protocolo RTP añade una marca indicadora de tiempo y un número de secuencia a cada paquete UDP en un encabezamiento especial de protocolo RTP. La marca indicadora de tiempo está relacionada con el muestreo, presentación o tiempo de composición de los medios transportados en la carga de pago del paquete RTP. Se utiliza para reproducir medios en sentido inverso a la velocidad correcta y, junto con el protocolo RTCP, se utiliza para sincronizar la presentación de otros medios de transferencia de flujo. Una especificación de carga de pago define la interpretación de la marca indicadora de tiempo y otros campos del protocolo RTP. El receptor utiliza el número de secuencia para detectar la pérdida de paquetes. Los datos estadísticos de pérdida de paquetes pueden reportarse al servidor por medio del protocolo RTCP.

Los informes RTCP proporcionan datos estadísticos relativos a los datos recibidos de una fuente de datos particular, tales como el número de paquetes perdidos desde el informe anterior, el número acumulativo de paquetes perdidos, la fluctuación entre las llegadas de paquetes, etc. Un borrador adicional define un formato para aplicación a los informes del emisor y receptor con protocolo RTCP. Puede encontrarse una descripción detallada del protocolo RTCP en la publicación RFC 1889, capítulo 6. El protocolo de control RTCP está basado en la transmisión periódica de paquetes de control a todos los participantes en la sesión, utilizando el mismo mecanismo de distribución que los paquetes de datos. El protocolo subyacente debe permitir el multiplexado de los paquetes de datos y control, por ejemplo utilizando números de puerto independientes con el protocolo UDP.

La función principal del protocolo RTCP es proporcionar realimentación sobre al calidad de la distribución de datos. Esta es una parte integral del papel del protocolo RTP como protocolo de transporte y tiene relación con las funciones de control de congestión y flujo de otros protocolos de transporte. La información de realimentación puede ser útil directamente para diagnosticar fallos en la distribución. El envío de informes de realimentación de recepción a todos los participantes permite a uno que esté observando problemas evaluar si estos problemas son locales o globales. Con un mecanismo de distribución como la multidifusión con protocolo IP, es posible también que una entidad, tal como un suministrador de servicios de red que no está implicado en la sesión, reciba la información de realimentación y actúe como vigilante terciario para diagnosticar problemas de red. Esta función de realimentación es realizada por los informes de emisor y receptor con protocolo RTCP. La especificación RTCP requiere que todos los participantes envíen paquetes RTCP, y consiguientemente la tasa de transmisión de ser controlada para que el protocolo RTP se amplíe en su aplicación a un gran número de participantes. En la situación en que cada participante envía sus paquetes de control a todos los demás, cada uno de ellos puede ver independientemente el número de participantes. Este número se utiliza para calcular la tasa de transferencia a la cual se envían los paquetes.

Adicionalmente, el protocolo RTCP tiene una función opcional de transportar información mínima de control de sesión, por ejemplo la identificación de participantes a visualizar en la interfaz de usuario. Esto tiene una alta probabilidad de ser útil en sesiones en la que entran y salen participantes sin control de miembros o negociación de parámetros. El protocolo RTCP sirve como canal conveniente para llegar a todos los participantes, pero no se espera necesariamente que soporte todos los requerimientos de comunicación de control de una aplicación. Puede ser necesario un protocolo control de sesión de nivel superior, que se sale del ámbito de este documento.

Las funciones descritas anteriormente, junto a la última que es opcional, son obligatorias cuando se utiliza el protocolo RTP en un ambiente de multidifusión con protocolo IP y se recomiendan para todos los ambientes.

Por consiguiente, el servicio multimedia en una red inalámbrica ha de utilizarse también para un solo usuario, en las denominadas conexiones de unidifusión, pero cuando se trata de un grupo de usuarios, se utilizan las denominadas conexiones de punto a multipunto o incluso de multipunto a multipunto. Los servicios de punto a multipunto imponen altas demandas a la infraestructura de red y consumen cantidades considerables de ancho de banda. Algunos ejemplos de tales servicios son la videoconferencia, conferencia de datos, juegos multiusuario en tiempo real, mensajería multimedia, mundos virtuales, etc. Este tipo de aplicaciones multimedia utiliza para el transporte el modo de difusión o multidifusión. La difusión tiene la posibilidad de dirigir un paquete a todos los destinos utilizando un código especial en el campo de dirección. Cuando se transmite un paquete con este código, es recibido y procesado por cada usuario de la red. Este modo de funcionamiento se denomina de difusión. La multidifusión soporta la transmisión a un subconjunto de los usuarios. Cada uno puede registrarse en un grupo de multidifusión. Cuando se envía un paquete a un cierto grupo, se entrega a todos los usuarios registrados en ese grupo.

El protocolo RTCP tiene mecanismos para informar en caso de sesiones multidifusión. Sin embargo, en el caso de redes de radio, el informe de multidifusión gasta recursos de interfaz con el aire y potencialmente sobrecarga los servidores de la red. Adicionalmente, en la solución preferida de multidifusión existe solamente un enlace descendente y ningún canal ascendente. Esto implica que los usuarios no pueden enviar informes RTCP a la fuente de datos.

En el sistema de la publicación RFC 1889 existe una entidad introducida, el denominado mezclador. El mezclador recibe paquetes RTP procedentes de una o más fuentes, cambia posiblemente el formato de datos, combina los paquetes de algún modo y cursa a continuación un nuevo paquete RTP. Puesto que la temporización entre varias fuentes de datos de entrada no estará en general sincronizada, el mezclador realizará ajustes de temporización entre las cadenas de datos y generará su propia temporización para la cadena combinada. De este modo, todos los paquetes de datos que proceden de un mezclador serán identificados como paquetes que tienen el mezclador como fuente de sincronismo. Por consiguiente, el mezclador crea un nuevo mensaje que es una combinación de los mensajes recibidos.

Sin embargo, para el sistema RTP en uso normal es obligatoria la utilización de informes de receptor RTCP en sesiones multidifusión. En particular, es importante que el que envía el mensaje multidifusión reciba estos informes para indicar que existen aun clientes en lista. La revisión en curso del protocolo RTP aporta una característica específica para suprimir el uso de informes de receptor RTCP. Sin embargo, la omisión de informes de receptor RTCP constituye también un medio importante para obtener información de realimentación sobre la calidad de los receptores en los que se omiten. En la fuente de datos no puede adaptarse a los cambios en las condiciones de transmisión ni pueden tampoco proporcionar cadenas de datos alternativas.

Es cuestionable a todas luces lo que la fuente de datos debe hacer si un informe RTCP procedente de un solo cliente indica que se alteraron o perdieron varios cuadros RTP y que el cliente sería atendido mejor con una tasa de transferencia de datos más baja. Esta es una cuestión especialmente importante en redes inalámbricas con usuarios de heterogeneidad creciente. Los usuarios multimedia están caracterizados por una variedad de terminales móviles y una amplia gama de capacidades y tamaños de la pantalla de visualización. En soluciones actuales de multidifusión la fuente de datos indistintamente ignorará tales informes o se adaptará al receptor de tasa de transferencia más baja. Ambas alternativas no son adecuadas cuando se les cobra a los clientes el servicio y el portador que se utiliza para el servicio. Adicionalmente, diferentes redes de radioacceso disponen de varias velocidades máximas de enlace de acceso. Debido a las características físicas de las redes celulares por radio, variará también la calidad y, por tanto, la tasa de transferencia de datos, de la conexión entrante, contribuyendo a aumentar el problema de la heterogeneidad.

El documento EP 1063819 A1 describe un método para crear un mapa topológico que indica la calidad de la conectividad de cada dispositivo en red de una red inalámbrica con todos los demás dispositivo de dicha red inalámbrica. Se presentan los siguientes problemas en relación con los informes RTCP en sesiones multidifusión en redes inalámbricas. Los recursos de radio escasos son utilizados ineficientemente cuando cada usuario envía un informe RTCP. Esto puede también conducir a la sobrecarga de servidores, como los servidores RNC, SGSN, GGSN, por ejemplo en caso de que los informes sean generados por un gran número de usuarios, por ejemplo en un partido de fútbol. Debido a las redes heterogéneas, la fuente de transmisión debe adaptarse al usuario de tasa de transferencia más baja. Adicionalmente, debido al número creciente de informes y al largo período que se necesita para su evaluación, se genera un retardo grande antes de que la fuente de datos tenga conocimiento de un problema. Además, los informes RTCP no contienen toda la información necesaria para redes inalámbricas.

Resumen y descripción del invento

Un objeto del presente invento es crear una solución para una utilización eficiente de una interfaz de radio para servicios multimedia multiusuario en una red inalámbrica.

El invento se realiza en un método de acuerdo con las reivindicaciones 1ª, 18ª. Se describen realizaciones ventajosas en las reivindicaciones dependientes.

La idea básica es adaptar datos multimedia multiusuario en un sistema de comunicaciones con un servidor que proporciona los datos multiusuario multimedia a clientes y con una parte de red intermedia. Dicha parte de red intermedia está dispuesta para proporcionar información en la comunicación entre el servidor y los clientes. El servidor envía datos multimedia a los clientes. Se determinan para los clientes características de distribución, que se consideran por generación del informe de realimentación asociado con las condiciones de recepción de los clientes de los datos multimedia en la parte de red intermedia. Dicho informe de realimentación incluye información adicional sobre el modo de agregación. Dicho informe de realimentación agregado se envía al servidor con el fin de que este último adapte la transmisión de los datos multimedia desde el servidor hasta los clientes de acuerdo con el informe de realimentación agregado.

Una ventaja del invento es que posibilita la utilización eficiente de recursos de red escasos y costosos en redes inalámbricas, en particular en la dirección del enlace ascendente. Con el presente invento se consigue que los recursos de radio se utilicen de un modo mejor porque los informes son relevantes para más de un usuario. En caso de un solo usuario, la fuente de emisión necesita realizar muchos análisis de informes en caso de grandes sesiones de usuario. Esto implica especialmente un mal uso de los recursos si los miembros pueden ser agrupados en una o unas pocas redes de acceso con características y comportamiento muy similares. Adicionalmente, esto reducirá la carga y complejidad en la fuente de datos. Esta solución proporciona el único modo de informar en caso de que no esté disponible un canal ascendente, como ocurre en la solución de difusión por radio. Además, el informe RTCP agregado puede considerar toda la información presente en la célula, en vez de un solo informe RTCP dedicado por cliente. Por ejemplo, en caso de situaciones de casi sobrecarga, el controlador de red de radio (RNC) conoce el problema antes de que se produzca la congestión por pérdida de cuadros, y puede informar de esto a la fuente de difusión para todos los clientes en la misma célula. Esto mejoraría la experiencia de calidad para el usuario final. Adicionalmente, en general la generación del informe es más rápida puesto que se omite el retardo de la interfaz con el aire. Esta situación es casi idéntica a la correspondiente al caso de un solo usuario multimedia.

En una realización del presente invento, las características de distribución están relacionadas con un área geográfica que incluye un grupo de clientes. Una o más células definidas en una red de comunicaciones inalámbricas puede conformar el área geográfica.

En otra realización, las características de distribución están relacionadas con una estructura determinada de grupo multidifusión, que puede incluir clientes que tienen dispositivos para recibir datos transmitidos con alta o baja velocidad.

En una realización preferida, las características de distribución están relacionadas con información recibida de un sistema de gestión de recursos de radio. El sistema de gestión de recursos de radio tiene la información actual relativa al rendimiento de transmisión en curso en la interfaz de radio. Por consiguiente, es preferible considerar esta información en la generación del informe de realimentación.

La interacción entre el nodo intermedio y el sistema de gestión de recursos de radio puede realizarse indistintamente de un modo frecuente o en caso de producirse un evento.

En otra realización, las características de distribución están relacionadas con información recibida de los clientes.

Con el fin de mejorar la calidad del informe de realimentación agregado, los clientes envían sus propios informes. La ventaja de esta solución es que los informes de realimentación agregados incluyen información que no puede ser determinada a partir de las características de distribución que se obtienen de las capas de radio.

Se propone que la información recibida de los clientes se envíe indistintamente con frecuencia o al producirse un evento, cuando, por ejemplo, se produce un evento extraordinario.

Es preferible que los informes de realimentación procedentes de los clientes se supriman en los terminales de cliente. La ventaja de esta realización es que no se produce tráfico en el enlace ascendente, de modo que se ahorran recursos de radio. En particular, en el caso de que no exista un canal ascendente disponible, esta es una solución preferible.

Adicionalmente, es ventajoso recibir información del sistema de gestión de recursos de radio, que tiene la información real relativa a la disponibilidad en curso de recursos de radio y de los clientes, y combinar la información para generar un informe de realimentación más adecuado para el servidor.

En una realización preferida del presente invento, la información adicional relativa al modo de agregación incluye un número de clientes a los cuales se aplica el informe de realimentación, de modo que el servidor puede distinguir cuando un informe se aplica a un cliente o a un grupo de clientes. De acuerdo con esta información, puede decidirse realizar una acción correcta, por ejemplo si una adaptación es útil o si una replicación de la cadena de datos real es más adecuada.

En otra realización preferida del presente invento, la información adicional sobre el modo de agregación comprende características de radio de una red de acceso en la cual están los clientes. Al tener esta información, el servidor puede distinguir como adaptar el flujo de datos multimedia considerando las características específicas de diferentes redes de acce-
so.

Se propone que el informe de realimentación agregado incluya también información para el servidor relacionada con el modo de adaptación. Así, el servidor recibe información adicional para juzgar mejor como podría o debería adaptarse el flujo de datos.

Es preferible que se realice una negociación sobre la frecuencia de informes de realimentación procedentes de los clientes y/o del sistema de gestión de recursos de radio para el nodo intermedio. Esto puede realizarse indistintamente a intervalos fijos o en base a eventos, significando esto último que se han producido ciertas circunstancias.

En una realización ventajosa, los clientes se reprimen en cuanto a enviar informes de realimentación a otros clientes que reciben la cadena de datos, de modo que se garantiza el anonimato de los clientes multimedia a los cuales han de enviarse los datos multimedia por multidifusión.

En una realización preferida del presente invento, el informe de realimentación agregado generado incluye una fracción de paquetes perdidos proporcionada por el nodo intermedio dependiendo de las condiciones de entrega en curso. Esta fracción puede ser, por ejemplo, un número de secuencia más alto que ha recibido el nodo intermedio o una fluctuación entre llegadas generada por el nodo intermedio.

Se propone que el servidor que recibe el informe de realimentación agregado actúe de un modo correcto. Por ejemplo, el servidor se adapta consiguientemente después que se utiliza la información incluida en el informe considerando el porcentaje de los clientes para los cuales se aplica dicha información de realimentación. La reacción puede consistir en anunciar a los clientes un nuevo canal o adaptar el flujo de datos, por ejemplo para reducir la tasa de transferencia de bits o para conmutar a un programa de codificación decodificación más fiable.

Se propone adicionalmente implementar la funcionalidad de la parte de red intermedia en la misma parte de la red. En la solución alternativa se propone dividir la funcionalidad entre diferentes nodos que forman la parte de red intermedia.

Una realización del presente invento está basada en el protocolo de transporte en tiempo real (RTP) que tiene un protocolo de control de transporte en tiempo real (RTCP) para informes de realimentación. Sin embargo, el presente invento no deberá estar restringido a este ejemplo de protocolos multimedia.

Adicionalmente, el presente invento describe una parte de red intermedia destinada a realizar una adaptación de datos multimedia multiusuario en un sistema de comunicaciones con un servidor que suministra los datos multimedia multiusuario a clientes. La parte de red intermedia está dispuesta para proporcionar información sobre la comunicación entre el servidor y los clientes. Incluye medios para cursar datos multimedia desde el servidor hacia los clientes. Forman también parte de la parte de red intermedia medios para la determinación de características de distribución asociadas con los clientes. La tarea de dichos medios es determinar, a partir del sistema de gestión de recursos de radio que tiene acceso a las capas inferiores, las condiciones de transmisión en las cuales se transmiten los datos multimedia a los clientes.

Adicionalmente, el nodo de la parte de red intermedia tiene medios para generar un informe de realimentación agregado sobre las condiciones de recepción de los clientes de los datos multimedia considerando las características de distribución, en cuya disposición dichos informes de realimentación incluyen información adicional relativa al modo de agregación. De este modo, se envía el informe de realimentación generado al servidor por medio de la transmisión del informe de realimentación.

Se propone que los medios de la parte de red intermedia estén implementados en el mismo nodo de red. Alternativamente, se propone que los medios para determinar las características de distribución asociadas con los clientes y los medios para generar un informe de realimentación agregado estén divididos entre nodos diferentes. En el último caso se requiere crear medios para recibir las características de distribución externas determinadas asociadas con los clien-
tes.

A continuación se expone una descripción detallada del invento.

Figura 1: arquitectura del Servicio de Difusión/Multidifusión (MBMS).

Figura 2: arquitectura de transferencia de flujo de paquetes conmutados (PSS).

Figura 3: pila de protocolos con las capas de protocolo para la transmisión de cadenas de datos.

Figura 4: modelo de protocolo para el presente invento.

Figura 5: realización del presente invento para determinar las características de distribución asociadas con los clientes.

Figura 6: realización del presente invento para la generación de un informe de realimentación agregado por terminal móvil.

Figura 7: realización del presente invento para la generación de un informe de realimentación agregado por célula.

Se explica a continuación el presente invento con respecto a una red inalámbrica que utiliza el protocolo RTP. Se utilizan como sinónimos los términos "nudo intermedio" y "parte de red intermedia".

La idea básica es disponer una parte de red intermedia en la red inalámbrica teniendo la precaución de generar un informe RTCP agregado, en vez de que cada usuario individual genere sus propios informes. Los términos "parte de red intermedia" describen una funcionalidad que puede ser implementada en un nodo, descrito en lo que sigue como nodo intermedio, o bien la funcionalidad puede dividirse entre diferentes nodos de red.

Se genera el informe RTCP agregado, o en general un informe de realimentación, por ejemplo para un grupo de multidifusión. Se realiza una determinación en tiempo real de características de distribución considerando la determinación de características relacionadas con células y la estructura de grupo. La generación del informe de realimentación está basada en la determinación en tiempo real de características de distribución, comprendiendo dicho informe de realimentación información adicional que incluye, por ejemplo, el número de usuarios a los cuales se aplica dicho informe de realimentación. Dicho informe de realimentación se envía al servidor que constituye la fuente de multidifusión, que utiliza el informe de realimentación de grupo considerando el porcentaje de los usuarios para los cuales se aplica dicho informe de realimentación. La transmisión de multidifusión/difusión se adapta de acuerdo con el informe de realimentación utilizado. Adicionalmente, opcionalmente el nodo intermedio propone a la fuente de multidifusión el modo de adaptar la cadena de datos de transferencia de flujo al grupo correspondiente de usuarios, por ejemplo se propone una difusión individual múltiple si dicha opción es posible o puede proponerse la conmutación a una célula de cobertura solapada u otra red de acceso. La razón de esto es que leal controlador de red de radio, que puede proporcionar ciertos datos al nodo intermedio, puede tener información que no tiene la fuente de datos, como por ejemplo características de cobertura de radio del área de la célula, y puede estar así en un situación mejor para juzgar como podría/debería adaptarse la cadena de datos. Como ejemplo, el protocolo RTCP indica en cada momento que la calidad de recepción no es buena, lo cual hace que una fuente de datos disminuya la tasa de transferencia de bits hasta el siguiente nivel inferior. Un controlador de red de radio que determina una situación de casi sobrecarga de célula y muchas iniciaciones de sesión por unidad de tiempo, podría indicar la necesidad de disminuir la tasa de transferencia de bits.

Al recibir el informe de realimentación agregado, la fuente de datos utiliza la información incluida en el informe considerando el porcentaje de clientes para los cuales se aplica la información de realimentación. La reacción puede ser anunciar a los clientes un nuevo canal o adaptar la cadena de datos, por ejemplo para reducir la tasa de transferencia de bits o para conmutar a un programa de codificación decodificación más fiable.

Para evitar en lo posible que los clientes envíen informes de receptor con protocolo RTCP y generen informes de receptor RTCP en un nodo intermedio, se ocultan los receptores de una célula completa. El nodo intermedio obtiene información del sistema RNC y crea un informe RTCP correspondiente. Adicionalmente, pueden utilizarse paquetes RTCP con información de transmisión inalámbrica especial y filtrarse en el nodo de generación del protocolo RTCP, que corresponde al nodo intermedio.

Adicionalmente, el informe RTCP podría contener opcionalmente, además del número de usuarios, las direcciones reales de los usuarios finales, puesto que esta información puede ser de interés para los otros usuarios y para la fuente de datos.

Se expone a continuación un descripción relativa a la figura 4.

La figura 4 presenta un modelo de protocolo para el presente invento. Dicha figura representa una fuente de multidifusión, que envía los datos multimedia a los clientes por medio de mensajes RTP, no ilustrados en la figura. La pila de protocolos en la fuente de multidifusión incluye el protocolo RTP con la correspondiente capa RTCP situada por encima de los protocolos UDP e IP. La indicación L2 corresponde a una descripción general de una capa de enlace, que difiere dependiendo de la red a la cual se envían los datos. Se muestra una pila de protocolos correspondiente en el lado receptor, que corresponde a un receptor multidifusión. Sin embargo, la capa de enlace especificada para la red inalámbrica es la capa de protocolo de radioenlace con el protocolo de control de recursos de radio (RRC). De acuerdo con el invento, existe una parte de red intermedia situada entre la fuente multidifusión y el receptor multidifusión, que corresponde al nodo intermedio. En la figura 4 se presentan diferentes opciones para la generación de un informe de realimentación agregado.

Es posible que el nodo intermedio no reciba ninguna información de los clientes. Esto indica que no se dispone de informes RTCP a través de la interfaz con el aire. La generación del informe de realimentación RTCP se realiza provisionalmente en el nodo intermedio en base a la cadena de datos de protocolo RTP recibida y potencialmente en base al conocimiento del sistema de gestión de recursos de radio relativo a cierta célula o área. Con el fin de recibir la información del sistema de gestión de recursos de radio, se utiliza el enlace 10 de comunicaciones. Esta información puede ser enviada indistintamente con frecuencia o en base a eventos. No se envía un informe procedente de los clientes debido al hecho de que el cliente se reprime en cuanto a enviar informes RTCP en el nivel RTP/RTCP, o porque todos los informes RTCP están bloqueados en el terminal del cliente.

En ciertas situaciones se le permite al cliente enviar informes RTCP a través de canales multidifusión ascendentes, informes en base a eventos a través del enlace de comunicaciones entre el receptor multidifusión y el nodo intermedio, etc. Esto significa que incluso en casos en que el informe está restringido o bloqueado en el terminal del cliente, existe una opción de enviar solamente informes de protocolo RTCP con información especial, sin que se envíen informes de protocolo RTCP regulares. Solamente en caso de eventos extraordinarios, se emite el informe RTCP. En caso de que un informe esté restringido en el terminal del cliente, esta situación se trata a nivel RTCP. En caso de informes bloqueados en el lado del cliente, el terminal tendría que filtrar los informes de protocolo RTCP regulares. La determinación de los informes de protocolo RTCP que se consideran como extraordinarios depende del servicio y de la red de acceso y puede someterse a negociación entre la fuente de datos y los destinos y/o entre las redes de acceso y los destinos. Por ejemplo, puede ser generado un informe de protocolo RTCP extraordinario cuando la tasa de pérdidas supera un cierto umbral. Los informes de protocolo RTCP se utilizan entonces como entrada adicional para formar un mensaje de protocolo RTCP agregado.

Otra opción del invento es restringir el envío de informes de protocolo RTCP a todos los receptores multidifusión con el fin de mantener el anonimato entre los usuarios. Típicamente, los usuarios tampoco están interesados en la persona que está recibiendo la información. Esta opción reduce adicionalmente la carga del enlace descendente de la red. De este modo, no se envían en la dirección descendente informes de protocolo RTCP, con la excepción de los informes de emisor. Esta opción se no se ilustra en la figura 4 porque solamente se representa un cliente.

Se describe a continuación, de acuerdo con la figura 5, una alternativa para la determinación de características de distribución asociadas con los clientes.

La figura 5 ilustra una arquitectura lógica alternativa con clientes en comunicación con el controlador de red de radio. Adicionalmente, la vía de comunicación se establece a través de enlaces de radio y red de núcleo hasta los denominados nodos de servicio en los cuales se genera el mensaje de realimentación agregado considerando la información de realimentación de red recibida del sistema RNC. Esto se refiere a la funcionalidad de obtener la información de calidad necesaria a nivel de células que están separadas físicamente del nodo, y que están compilando y enviando los informes de protocolo RTCP. No se envían informes de receptor de protocolo RTCP desde el cliente móvil. El nodo de servicio puede ser indistintamente un nodo especial o una función implementada en GGSN, o bien una función de recursos multimedia (MRF) en la que dicho nodo de servicio exterior al núcleo móvil genera los informes de protocolo RTCP de receptor. Los informes de protocolo RTCP de receptor pueden ser enviados por controlador de red de radio (RNC) o por célula.

Adicionalmente, la creación de los informes de protocolo RTCP por célula o por estructura RNC aumenta también la periodicidad de la información de realimentación de calidad y permite a la entidad que envía el mensaje adaptarse con mayor rapidez a condiciones cambiantes. El intervalo de informe de protocolo RTCP puede depender del número de participantes en la sesión.

Se describen a continuación más detalladamente diferentes soluciones para diferentes escenarios.

Uno de los posibles escenarios es el de radiodifusión, que está caracterizado por un esquema de radioacceso en el que no existe enlace ascendente. Esto significa que los diagramas de datos de multidifusión se envían en la dirección descendente, pero no se produce respuesta de retorno del cliente. La falta de un canal de retorno impide que se envíe información de realimentación con protocolo RTCP por parte de los clientes. Aunque podrían generarse mensajes de protocolo RTCP, no existe medio para su entrega.

Para el escenario de radiodifusión la idea es que se generen mensajes de protocolo RTCP en un nodo de red, por ejemplo en el controlador de red de radio, para acceso WCDMA, que es básicamente la posición lógica para generar los informes de protocolo RTCP. El nuevo informe de protocolo RTCP de receptor se crea en base a información relacionada con transmisiones por radio. Por consiguiente, la función de crear y enviar un informe de protocolo RTCP de receptor y la función de recogida de datos pueden dividirse.

Para fines de comunicación, el protocolo RTCP define diferentes mensajes de protocolo RTCP. Se describe a continuación un modo de generar un mensaje agregado utilizando los mensajes de protocolo RTCP.

El protocolo RTCP define un informe de emisor (SR), un informe de receptor (RR), bloques de descripción de entidad de origen (SDES), un mensaje de despedida (BYE), y funciones específicas de aplicación (APP). Los mensajes pueden agruparse para formar un denominado mensaje compuesto. Para el invento en particular es importante el informe de receptor (RR), que necesita ser recibido por la entidad que envía el mensaje con el fin de facilitar la adaptación a condiciones de ancho de banda cambiantes. Se propone que tales informes de receptor sean generados en el controlador de red de radio, en base al conocimiento que tiene este punto en relación con las condiciones del enlace en una o más llamadas. El controlador de red de radio puede generar un mensaje para cada célula y es responsable de un único mensaje para todos los receptores, o incluso de la formación de dicho mensaje.

A continuación se describen los diferentes campos de un mensaje RR como se definen en la publicación RFC 1884.

El campo SSRC_n (identificador de origen) con 32 bits es el identificador SSRC del origen al cual atañe la información de este bloque de informe de recepción.

El campo fracción perdida con 8 bits describe la fracción de los paquetes de datos de protocolo RTP procedentes del origen SSRC_n que se han perdido desde que el paquete anterior de característica SR o RR fue enviado, expresada como número en coma fija.

El campo número acumulativo de paquetes perdidos, con 24 bits, corresponde al número total de paquetes de datos de protocolo RTP procedentes del origen SSRC_n que se han perdido desde el comienzo de la recepción.

Para el campo número de secuencia extendido más alto recibido se reservan 32 bits. Los 16 bits de orden inferior contienen el número de secuencia más alto recibido en un paquete de datos RTP desde el origen SSRC_n, y los 16 bits más significativos extienden ese número de secuencia con el cómputo correspondiente de ciclos de número de secuencia.

Existe también un campo fluctuación entre llegadas con 32 bits, que corresponde a una estimación de la varianza estadística del intervalo entre llegadas de paquetes de daros RTP, medida en unidades de marca indicadora de tiempo y expresada como un número entero sin signo. La fluctuación entre llegadas se define como la desviación media (valor absoluto suavizado) de la diferencia entre la separación de paquetes en el receptor y la misma diferencia en el emisor para un par de paquetes.

El campo última marca indicadora de tiempo SR (LSR), con 32 bits, describe el paquete de informe de emisor RTCP más reciente procedente del origen SSRC_n. Si no se han recibido aun los datos SR, el campo se pone a cero.

El campo retardo desde el último informe de emisor (DLSR), con 32 bits, indica un retardo, expresado en unidades de 1/65536 segundos, entre la recepción del último paquete de informe de emisor procedente del origen SSRC_n y el envío de este bloque de informe de recepción. Si no se ha recibido aun ningún paquete de informe de emisor desde el origen SSRC_n, se pone a cero el campo DLSR.

Los valores para las entradas en el informe de recepción necesitan ser ajustados de acuerdo con el presente invento para generar un mensaje de realimentación agregado.

El primer campo es simplemente la identificación del emisor, que es conocida. Para el segundo campo, la fracción de paquetes perdidos tiene diferentes alternativas. Un valor adecuado podría ser la fracción de paquetes perdidos vista por el nodo RNC, o bien una estimación realizada por este último dependiendo de la situación en curso de la célula, por ejemplo la utilización de recursos de radio, interferencias, etc, y dependiendo del nivel de fiabilidad escogido para la transmisión en la célula.

El tercer campo, que corresponde al número acumulativo de paquetes perdidos, necesita ser seleccionado de acuerdo con el concepto utilizado en el campo anterior para evitar una desadaptación. Por ejemplo, si la fracción de paquetes perdidos está basada en las pérdidas de paquetes vistas por el controlador de red de radio (RNC), dichas pérdidas deberán ser utilizadas también para esta entrada. El número de secuencia más alto recibido deberá ser el más alto que ha visto la estructura RNC. La fluctuación entre llegadas podría basarse indistintamente en la fluctuación observada por el controlador de red de radio, o en un valor estimado teniendo en cuenta los parámetros del enlace, por ejemplo si se utiliza información ARQ, codificación de repetición, o codificación FEC, para asegurar un cierto grado de fiabilidad. La marca indicadora de tiempo del último informe de emisor puede ser asumida sin modificación a partir del informe de emisor recibido de la entidad emisora. En caso de que no haya sido recibido aun el informe de emisor, el campo se pone a cero. El último campo DLSR puede quedar sin modificar o puede introducirse una mejora adicional. Por ejemplo, con el fin de proporcionar una mejor estimación del tiempo de recorrido circular (RTT) para el emisor, se propone reducir el valor de retardo en un intervalo de recorrido circular de radioacceso. Con el fin de adaptar el valor del retardo para compensar los retardos de la red de acceso, el valor de retardo puede reducirse, por ejemplo, en dos intervalos RTT. Aun cuando estos son simplemente ejemplos, no restringen el ámbito de aplicación del invento.

Se presenta a continuación el escenario siguiente, es decir el escenario de multidifusión.

El escenario de multidifusión difiere del escenario de radiodifusión principalmente en que está disponible un canal de retorno. Esta disposición es tal que haría posible el intercambio de señales RTCP de extremo a extremo, pero debido a los problemas indicados, a saber la sobrecarga de los recursos de radio cuando cada cliente envía un informe, se propone generar los mensajes de protocolo RTCP en la parte de red intermedia, preferiblemente en el controlador de red de radio para acceso WCDMA. Se describen a continuación dos posibles realizaciones actuales.

En la primera realización, los mensajes RTCP generados por clientes se descartan en el terminal del cliente y los generados como borrador en el nodo intermedio, como el RNC. De acuerdo con la especificación del protocolo RTP, es posible normalmente que la entidad de origen indique a los clientes que no utilicen informes de receptor con protocolo RTCP. Al recibir esta información, se descartan los mensajes de realimentación en el terminal del cliente, o incluso no se generan.

En la segunda realización, se anticipa que los mensajes de protocolo RTCP generados en los clientes se transmiten a través de la interfaz de radio hasta la parte de red intermedia, pero modificados en dicha parte de red de acuerdo con ciertos principios que se describen posteriormente. El intervalo de mensaje de protocolo RTCP para los mensajes de protocolo RTCP procedentes del cliente puede ser mayor que el intervalo de mensaje de protocolo RTCP para mensajes de protocolo RTCP transmitidos desde el nodo intermedio hasta el emisor. El cliente puede incluso enviar mensajes de protocolo RTCP solamente activados por eventos, por ejemplo cuando ciertos valores están fuera de rango.

La entrada para ajustar los diferentes campos de los mensajes de informe de receptor es la misma que para el escenario de radiodifusión. Aun cuando se trate de la estructura de multidifusión, pueden seguirse los siguientes principios cuando se ajustan los campos en los mensajes de informe de receptor. El primer principio que podría aplicarse es que cuando se utiliza un canal de transporte común en acceso WCDMA, existirán siempre algunos receptores con condiciones de funcionamiento de canal pobres que experimentan grandes pérdidas de paquetes, mientras que otros tendrán buena calidad. La estructura RNC podría en este caso apantallar los informes de receptor de baja calidad para mantener la calidad para las transmisiones dirigidas a usuarios con buenas condiciones de recepción. El segundo principio puede aplicarse si la estructura RNC detecta una sobrecarga en una célula y quiere reducir la tasa de transferencia de bits en el canal común utilizado para servicio multidifusión/radiodifusión, pudiendo utilizarse los informes de protocolo RTCP para indicar esta situación al servidor de multidifusión. Esto puede hacerse indistintamente aumentando en los informes el coeficiente de pérdida de paquetes medido, o reduciendo el número de secuencia más alto recibido. Esto será más rápido que el intercambio de señales de extremo a extremo debido a la latencia de la interfaz de radio y porque los informes de protocolo RTCP por usuario se hacen más inusuales para grandes grupos de usuarios.

Se describe a continuación un mecanismo general común para los escenarios descritos anteriormente.

Como ya se ha mencionado anteriormente, los mensajes de realimentación de protocolo RTCP agregados se generan en una parte de red intermedia. En la descripción anterior, la generación de informes de protocolo RTCP se realiza en el punto RNC. En general, esta generación de informes y toda la funcionalidad relacionada es una función lógica que podría también residir en otras entidades de red, tales como el servidor de multidifusión/radiodifusión (MB-SC). Podrían utilizarse protocolos dedicados para cursar la información pertinente desde el controlador de red de radio hasta el servidor MB-SC en ese caso.

En una realización preferida del presente invento, ha de garantizarse el anonimato del usuario. A diferencia de algunas aplicaciones de multidifusión en Internet fija, como las audio y vídeo conferencias, los usuarios móviles forman típicamente una comunidad anónima. Los usuarios de redes móviles que buscan el mismo vídeo clip muy probablemente no están interesados en conocer los nombres de otros usuarios y tampoco podrían estar interesados en revelar su identidad. Los mensajes de protocolo RTCP, en particular los mensajes de informe de receptor y los mensajes de descripción de origen de acuerdo con la norma deberán incluir la identidad de los usuarios, por ejemplo en formato de dirección de correo electrónico. De este modo, el invento propone transmitir los mensajes de protocolo RTCP que son generados en el nodo intermedio solamente en retorno al emisor de la cadena de datos de protocolo RTP.

Además de la generación de un informe de protocolo RTCP agregado, se añade al informe el número de destinos para los cuales se aplica el informe de protocolo RTCP. Esta información es considerada entonces potencialmente por la entidad de origen en caso de adaptaciones de cadenas de multidifusión. Esto significa que si un informe de protocolo RTCP agregado cubre miles de destinos, la entidad de origen puede adaptarse a estos destinos. Si cubre solamente diez destinos en una sesión en la que están implicados miles de destinos, puede ser mejor aconsejar a los clientes que conmuten a una sesión de unidifu-
sión.

Se describen a continuación dos realizaciones del presente invento. En la primera, se genera un mensaje de realimentación agregado en el nodo intermedio en base a los informes de protocolo RTCP por terminal móvil, como se ilustra de acuerdo con la figura 6.

La figura 6 ilustra una fuente de multidifusión que envía un flujo de datos de protocolo RTP, en tráfico multidifusión aguas abajo a través de un nodo intermedio y las correspondientes unidades RNC hasta los clientes con sus terminales móviles. El nodo intermedio genera informes de protocolo RTCP de receptor y envía estos como información de realimentación a la fuente de multidifusión. Esta información de realimentación se genera considerando la información de usuario y célula recibida del controlador de red de radio.

Para distinguir entre varias fuentes de multidifusión, cada paquete de informe de receptor es direccionado la entidad SSRC del emisor. Por consiguiente, el nodo intermedio debe procesar y cursar el tráfico multidifusión aguas abajo desde la fuente hasta los receptores y extraer la información SSRC de la fuente de multidifusión. La información SSRC es necesaria para direccionar los paquetes de informe de protocolo RTCP de receptor aguas arriba, que son generados en el nodo intermedio. El número de terminales móviles por célula más las condiciones de recepción por terminal son proporcionados por el controlador de red de radio.

El nodo intermedio debe asignar un identificador SSRC a cada terminal de cliente. Junto al identificador SSRC, el nodo intermedio debe también proporcionar un bloque SDES CNAME a cada cliente. Existen varias opciones para elegir la información CNAME para un usuario particular. En caso de participación anónima, cuando la entidad de origen no obtiene una información CNAME clara, el bloque SDES CNAME se escoge aleatoriamente. Dicho bloque puede expresarse, por ejemplo, en la forma <random-number>@host. El bloque CNAME debe ser singular. En caso de un bloque CNAME no anónimo, el operador indistintamente predetermina el nombre de usuario, por ejemplo phonenumber@domain, o especifica el bloque CNAME en una base de datos de preferencias. Por consiguiente, el nodo intermedio debe mantener una lista de terminales de cliente por célula mas los identificadores SSRC asociados asignados por el nodo intermedio y los bloques CNAME. La funcionalidad del nodo intermedio está incluida posiblemente en la estructura BM-SC o en el nodo GGSN. El contenido de cada paquete RTCP se crea como se ha descrito en los capítulos anteriores.

En el caso de un grupo de usuarios muy grande, que está distribuido en un número muy grande de células, el nodo intermedio enviará paquetes de protocolo RTCP por célula y no por cliente. Es muy posible que cada célula dé servicio aproximadamente al mismo numero de miembros de grupo. Esta realización se ilustra en la figura 7, que muestra hechos coincidentes que aparecen también en la figura 6. La diferencia es que el nodo intermedio genera uno mensaje de realimentación por célula.

En este caso, el nodo intermedio asigna identificadores SSRC válidos y bloques CNAME a cada célula que contiene miembros del grupo. El número de paquetes RTCP a enviar se disminuye. El intervalo de transmisión de paquetes RTCP, y consiguientemente también el tiempo de reacción de la fuente de multidifusión, disminuye enviando paquetes RTCP por célula.

Como tipo de paquete RTCP adicional, puede introducirse el número de usuarios en la célula en el peso del informe de receptor RTCP. Este tipo de paquete RTCP debe ser parte de un paquete de protocolo RTCP compuesto siempre que estos paquetes de protocolo RTCP contengan informes de receptor para más de un miembro.

El presente invento ofrece una solución para la generación de informes de protocolo RTCP específicos en sistemas inalámbricos y de multidifusión que consideran las características específicas de las redes inalámbricas y mejoran la calidad global del servicio. Puede considerarse en los informes otra información diferente de los protocolos de capa de nivel bajo como es conocido ya en el servidor RNC, para optimizar adicionalmente la calidad del servicio. Sin embargo, constituye solamente una parte del invento cursar a la entidad de origen de datos información adicional relacionada con recursos de radio. Otra característica del invento es que el controlador de red de radio considera la información y realiza una propuesta de adaptación a la fuente de datos. Con esta disposición, la fuente de datos no necesita tener información relativa a la red de radio, puesto que es la red de radio la que convierte esta información en una propuesta de adaptación conocida para dicha fuente.

Claims (23)

1. Un método para la adaptación de datos multimedia multiusuario en un sistema de comunicaciones con un servidor que proporciona los datos multimedia multiusuario a clientes, y con una parte de red intermedia, caracterizado porque dicha parte de red intermedia proporciona información sobre el sistema de comunicaciones entre el servidor y los clientes, y dicho método comprende las operaciones de: cursar información de flujo de datos desde el servidor hacia los clientes; determinar las características de distribución asociadas con los clientes; en dicha parte de red intermedia, generar informes de realimentación agregados sobre las condiciones de recepción del flujo de transferencia de datos por los clientes considerando las características de distribución, en cuya operación dicho informe de realimentación incluye información relativa al modo de agregación; enviar al servidor el informe de realimentación agregado; y adaptar la transmisión del flujo de datos desde el servidor hasta los clientes de acuerdo con el informe de realimentación agregado.

2. Un método de acuerdo con la reivindicación 1ª, caracterizado porque las características de distribución están relacionadas con un área geográfica que incluye un grupo de clientes.

3. Un método de acuerdo con la reivindicación 2ª, caracterizado porque el área geográfica está cubierta por una más células en una red de comunicaciones inalámbricas.

4. Un método de acuerdo con la reivindicación 1ª, caracterizado porque las características de distribución están relacionadas con una estructura de grupo multidifusión determinada.

5. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 4ª, caracterizado porque las características de distribución están relacionadas con información recibida de un sistema de gestión de recursos de radio.

6. Un método de acuerdo con la reivindicación 5ª, caracterizado porque la información recibida del sistema de gestión de recursos de radio en enviada con frecuencia o en base a eventos.

7. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 4ª, caracterizado porque las características de distribución están relacionadas con información recibida de los clientes.

8. Un método de acuerdo con la reivindicación 7ª, caracterizado porque la información recibida de los clientes se envía con frecuencia o en base a eventos.

9. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 4ª, caracterizado porque los informes de realimentación procedentes de los clientes se suprimen en los terminales de red.

10. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 9ª, caracterizado porque la información recibida de los clientes contiene información procedente del sistema de gestión de recursos de radio.

11. Un método de acuerdo con la reivindicación 1ª, caracterizado porque la información sobre el modo de agregación incluye un número de clientes a los cuales se aplica el informe de realimentación agregado.

12. Un método de acuerdo con la reivindicación 1ª, caracterizado porque la información adicional sobre el modo de agregación comprende características de radio de una red de acceso en la cual están conectados los clientes.

13. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 12ª, caracterizado porque la información adicional sobre el modo de agregación comprende información relativa al modo de adaptación.

14. Un método de acuerdo con cualquiera de las reivindicaciones 6ª u 8ª, caracterizado porque se realiza una negociación sobre la frecuencia de los informes de realimentación procedentes de los clientes y/o del sistema de gestión de recursos de radio transmitidos al nodo intermedio.

15. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 14ª, caracterizado porque los terminales se reprimen en cuanto a enviar informes de realimentación a otros terminales que reciben el flujo de datos.

16. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 15ª, caracterizado porque el informe de realimentación agregado generado incluye una fracción de paquetes perdidos proporcionada por el nodo intermedio dependiendo de las condiciones de entrega en curso, de un número de secuencia más alto que ha recibido el nodo intermedio, y de una fluctuación entre llegadas proporcionada por el nodo intermedio.

17. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 16ª, caracterizado porque al recibir el informe de realimentación agregado la fuente de datos utiliza la información incluida en el informe considerando el porcentaje de los clientes para los que se aplica dicha información de realimentación (la reacción puede consistir en anunciar a los clientes un nuevo canal o adaptar la cadena de datos, por ejemplo para reducir la tasa de transferencia de bits o para conmutar a un programa de codificación decodificación más fiable.

18. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 14ª, caracterizado porque la generación del informe de realimentación agregado y la determinación de características de distribución asociadas con los clientes se realizan indistintamente en un mismo nodo que corresponde a la parte de red intermedia, o bien se divide entre diferentes nodos que forman la parte de red intermedia.

19. Un método de acuerdo con cualquiera de las reivindicaciones 1ª a 18ª, caracterizado porque la transmisión de la cadena de datos se realiza por medio del protocolo RTP que tiene un protocolo RTCP de control para enviar informes de realimenta-
ción.

20. Una parte de red intermedia destinada a realizar una adaptación de una cadena de flujo de datos multiusuario en un sistema de comunicaciones con un servidor que proporciona el flujo de datos multiusuario a clientes, caracterizado porque dicha parte de red intermedia está dispuesta para proporcionar información relativa a la comunicación entre el servidor y los clientes, y en donde dicha parte de red intermedia comprende: medios para cursar cadenas de datos de flujo desde el servidor hacia los clientes; medios para la determinación de características de distribución asociadas con los clientes; medios para generar un informe de realimentación agregado sobre las condiciones de recepción de los clientes del flujo de datos considerando características de distribución, donde dichos informes de realimentación incluyen información adicional sobre el modo de agregación; y medios para enviar el informe de realimentación agregado al servidor.

21. Una parte de red intermedia de acuerdo con la reivindicación 20ª, que tiene todos los medios implementados en un mismo nodo de red.

22. Una parte de red intermedia de acuerdo con la reivindicación 20ª, que tiene los medios para la determinación de las características de distribución asociadas con los clientes y los medios para generar un informe de realimentación agregado que se divide entre nodos diferentes.

23. Una parte de red intermedia de acuerdo con la reivindicación 22ª, que tiene medios para recibir características de distribución de determinación externa asociadas con los clientes.