ES2905831T3 - Concepto de gestión de recursos - Google Patents

Abstract

Entidad de usuario para comunicarse con una estación base de recursos de radio (32), en la que está operativo un cliente (40) o un servidor (32), en la que la entidad de usuario está configurada para vigilar un tráfico de datos hacia/desde el cliente (40) o el servidor (32) para derivar una descripción de presentación multimedia (46) que describe versiones de diferentes anchos de banda de un contenido multimedia (44), y reenviar, al menos parcialmente, la descripción de presentación multimedia a un gestor de recursos de radio (30) responsable de asignar los recursos de comunicación de la estación base de recursos de radio (32) a entidades de usuario a las que pertenece la entidad de usuario.

Description

ES 2 905 831 T3

DESCRIPCIÓN

Concepto de gestión de recursos

La presente invención se refiere a la gestión de recursos tal como gestión de recursos de radio de red en redes inalámbricas.

En los últimos años el suministro multimedia a través de Internet ha aumentado de manera pronunciada pasando a ser el principal consumidor de ancho de banda dentro de la red. En paralelo a este aumento, mejoras significativas en redes móviles han conducido a la aparición de redes de acceso de alta velocidad tales como acceso a paquetes de enlace descendente de alta velocidad (HSDPA) de 3GPP y las redes emergentes de evolución a largo plazo (LTE).

Con las mejoras en las redes móviles, se espera que los servicios de IP sean un hecho ubicuo de la vida diaria. Estudios recientes esperan que el consumo de contenido multimedia, especialmente transmisión en continuo de vídeo, va a seguir aumentando [1], lo cual también puede ser un resultado de los avances en las redes móviles. De hecho, en [2] se ha notificado que aproximadamente el 50% del tráfico de datos en redes móviles son datos de vídeo y se espera que dos tercios del tráfico de datos móviles mundial será vídeo en 2015.

La transmisión en continuo de HTTP es una de las aplicaciones multimedia prometedoras que ha surgido en los últimos años y ha tenido una increíble aceptación en el mercado, lo cual resulta evidente por las actividades de normalización sobre transmisión en continuo de HTTP adaptiva llevadas a cabo por diferentes organismos de normalización, tales como MPEG [3] y 3GPP [4] o soluciones patentadas tales como IIS Smooth Streaming (transmisión en continuo fluida de IIS) [5] y HTTP Live Streaming (transmisión en continuo en directo de HTTP) [6]. En el documento WO 2011/015243 A1 se proporciona un ejemplo adicional de transmisión en continuo.

Aunque la transmisión en continuo de medios se ha asociado anteriormente con RTP/UDP debido a su latencia inferior, se ha mostrado que basarse en HTTP/TCP para el suministro multimedia es una solución muy valiosa para situaciones en las que no se consideran restricciones de retardo extremadamente rigurosas, dado que no están presentes problemas traversales dentro de NAT y cortafuegos, típicos con RTP/UDP. La transmisión en continuo dinámica adaptativa sobre HTTP (DASH) [3] es una norma de MPEG emergente, que define un formato para el suministro multimedia sobre HTTP. Básicamente consiste en dos elementos: el formato de los medios que van a descargarse y la descripción de los medios que van a descargarse. Soluciones patentadas existentes se basan en un enfoque similar.

El formato multimedia está estructurado básicamente en intervalos de tiempo normalmente pequeños de vídeo, denominados segmentos, que, si se descargan de manera continua, permiten una representación continua de los medios. Además, habitualmente están disponibles diferentes representaciones, por ejemplo codificaciones, de los medios a diferentes tasas de transmisión de bits en el servidor que permiten una adaptación impulsada por usuario, en la que los usuarios seleccionan representaciones basándose en el rendimiento de red observado. Se permite la descarga de segmentos de diferentes representaciones para diferentes intervalos de tiempo dando como resultado unos medios perfectamente reproducibles, si se siguen todas las restricciones de conmutación presentadas en la descripción de presentación multimedia (MPD), descritas a continuación.

En DASH, la descripción del formato viene dada por la MPD. La MPD es un documento XML, que describe los datos y especialmente los segmentos disponibles en el servidor. Usando la MPD los clientes tienen la información necesaria para realizar peticiones que se ajustan a su rendimiento de red o sus requisitos.

En DASH los clientes son responsables de realizar la adaptación. Basándose en los intereses de los usuarios, las capacidades de equipos y el estado actual de la red, los clientes de DASH tienen que seleccionar la(s) representación/representaciones descrita(s) en la MPD que mejor corresponde(n) a las necesidades/capacidades de los clientes. En la figura 1 se muestra un ejemplo de arquitectura de DASH.

Tal como puede observarse a partir de la figura 1, las entidades participantes en un entorno de DASH son: el servidor de DASH 10 que recibe su contenido multimedia que va a distribuirse a clientes de DASH 12 respectivos a partir de alguna fase de preparación de contenido de DASH 14, el propio cliente de DASH 12 y la red que interconecta el servidor de DASH 10 y el cliente de DASH 12, denominándose la red 16 “caché de HTTP”. Tal como se representa en la figura 3, el cliente de DASH puede ejecutarse en un terminal de usuario adecuado tal como un dispositivo de televisión o un ordenador o similar, cuando el cliente de DASH recibe a partir del servidor de DASH 10 la descripción de presentación multimedia MPD 18 que, a su vez, se ha generado junto con las versiones del contenido multimedia por la fase de preparación de contenido de DASH 14 para describir las diversas versiones del contenido multimedia disponibles en el servidor de DASH 10.

La figura 2 muestra el estado de la técnica de la arquitectura de despliegue de DASH en redes de LTE que usa entidades a partir de la norma de DASH [ISO/IEC 23009-1]. Los recuadros blancos especifican el sistema de DASH, mientras que los recuadros sombreados especifican el sistema de LTE. De manera más precisa, al transferir la

ES 2 905 831 T3

infraestructura de DASH a redes de LTE, se muestra que el cliente de DASH 12 está conectado al CASH de HTTP 16 a través de una concatenación de una estación base de LTE 20, un canal de radio 22 y una entidad de usuario 24, en la que se muestra que un gestor de recursos de radio 26 está comprendido por la estación base 20 y la entidad de usuario 24 puede ser un terminal móvil tal como un teléfono móvil o similar en el que el cliente de DASH 12 está funcionando en forma, por ejemplo, de un software que se ejecuta en el procesador de la entidad de usuario. Se supone que el cliente de DASH 12 así como el eNB de LTE 20 tienen acceso a la descripción de presentación multimedia (MPD 18). La MPD 18 proporciona información suficiente sobre la representación de vídeo en el servidor 10 como para proporcionar un servicio de transmisión en continuo al usuario 12 al pedir el usuario segmentos a partir del servidor de HTTP 10 usando TCP/IP como protocolo de transporte. Inicialmente, el cliente de DASH 12 transmite una petición de tipo HTTP get al servidor de HTTP 10. Tras el establecimiento de comunicación de HTTP se establece un túnel de TCP entre el servidor 10 y el cliente 12. Este túnel de TCP es transparente para la capa de transporte física subyacente. Dependiendo de la información proporcionada por la MPD 18, el cliente de DASH 12 tiene suficiente información para demultiplexar, decodificar y representar los datos multimedia incluidos de manera apropiada.

El problema implicado con la situación representada en la figura 2 es el comportamiento habitual del cliente de DASH 12 según el cual cada cliente de DASH 12 busca proporcionar a su usuario la versión del contenido multimedia que reside en el servidor 10 respectivo que tiene la mayor calidad y/o contenido de información posible con los recursos de comunicación actualmente asignados, asignados por el gestor de recursos de radio 26 a la entidad de usuario 24 del cliente de DASH 12 respectivo. La “mayor calidad/contenido de información posible” puede ser entonces uno que tiene la máxima resolución espacial, máximo número de visualizaciones, máxima profundidad de anchura y similares, necesitando por tanto el ancho de banda más alto. A su vez, esto significa que cada cliente de DASH 12 impone un esfuerzo máximo en los recursos de radio disponibles de la estación base 26 y la estación base y el gestor de recursos de radio 26, respectivamente, tiene que lidiar con pedir constantemente un aumento de los recursos de comunicación asignados con el fin de obtener una de las versiones de nivel superior disponibles del contenido multimedia que el cliente de DASH respectivo de la entidad de usuario respectiva desea obtener. Naturalmente, esto conduce a una distribución inferior a la óptima de los recursos de comunicación de radio a las entidades de usuario, distribución o planificación que se realiza basándose en una situación de canal actual y perfiles de usuario asignados a las entidades de usuario individuales 24.

Por consiguiente, un objetivo de la presente invención es proporcionar un concepto de gestión de recursos que permita un uso más eficiente de los recursos de comunicación disponibles con el fin, por ejemplo, de maximizar el número de usuarios satisfechos.

Este objetivo se logra mediante el objeto de las reivindicaciones independientes.

A continuación se describen realizaciones preferidas de la presente invención con respecto a las figuras, entre las cuales

la figura 1 muestra un diagrama de bloques de un ejemplo de arquitectura de DASH;

la figura 2 muestra un diagrama de bloques que ilustra la arquitectura de despliegue actual para DASH en redes de LTE, en el que los recuadros blancos en líneas continuas indican dispositivos especificados en la norma de DASH, mientras que los recuadros blancos en líneas de rayas son conceptuales o transparentes;

la figura 3 muestra un diagrama de bloques de un entorno de recursos de radio a modo de ejemplo que incluye un gestor de recursos de radio, basándose en el cual se describen diferentes realizaciones del gestor de recursos de radio según la presente invención;

la figura 4 muestra un gráfico de la tasa de transmisión multimedia frente a tasa de transmisión instantánea frente a tasa de descarga de segmentos;

la figura 5 muestra un diagrama de una posible implementación de una primera realización del gestor de recursos de radio de la figura 3;

la figura 6 muestra un diagrama de bloques de un entorno de recursos de radio a modo de ejemplo adicional que incluye un gestor de recursos de radio, basándose en el cual se describen diferentes realizaciones del gestor de recursos de radio según la presente invención;

la figura 7 muestra un diagrama de bloques de una entidad de usuario que incluye un gestor de recursos, basándose en el cual se describen diferentes realizaciones del gestor de recursos según la presente invención;

la figura 8 muestra un diagrama de una posible implementación de una realización del gestor de recursos de radio de la figura 6;

ES 2 905 831 T3

la figura 9 muestra un diagrama de una posible implementación de una realización del gestor de recursos de radio de las figuras 3 y 6;

la figura 10 muestra un diagrama de una posible implementación de un cliente adecuado para usarse en la realización de la figura 7;

la figura 11 muestra un diagrama de bloques de un entorno de recursos de radio a modo de ejemplo que incluye un gestor de recursos de la figura 10;

la figura 12 muestra un diagrama de bloques de otro entorno de recursos de radio a modo de ejemplo que incluye un gestor de recursos de radio según las figuras 3 o 6;

la figura 13 muestra un diagrama de bloques de una posible implementación de una porción del trayecto de datos entre el cliente y el servidor, que incluye una posible implementación del cliente;

la figura 14 muestra una secuencia de etapas realizadas en una situación con un servidor que funciona en una entidad de usuario y el cliente correspondiente que funciona en otra entidad de usuario según una realización;

la figura 15 muestra una secuencia de etapas realizadas en una situación en la que un gestor de recursos de la entidad de usuario en la que funciona un cliente, ayuda al gestor de recursos de radio con el análisis sintáctico de MPD;

la figura 16 muestra un diagrama de bloques de un entorno de recursos de radio a modo de ejemplo que incluye un gestor de recursos de radio que asigna recursos de comunicación de enlace ascendente según una realización; y

la figura 17 muestra un sistema de gestores de recursos de radio según otra realización.

La figura 3 muestra una primera realización, no reivindicada, de un gestor de recursos de radio según la presente solicitud. El gestor de recursos de radio de la figura 3 se indica generalmente con el signo de referencia 30 y está configurado para asignar recursos de comunicación de una estación base 32 a entidades de usuario de las cuales se muestra una de manera representativa en 34. La entidad de usuario 34 es, por ejemplo, un terminal móvil tal como un teléfono móvil, un ordenador portátil o similar, pero también puede ser un dispositivo estacionario. La entidad de usuario 34 puede comunicarse con la estación base 32 a través de un canal inalámbrico 36 mediante su antena o antenas (no mostradas). La estación base 32 gestiona de manera apropiada la multiplexación de datos de comunicación, es decir datos de enlace descendente y de enlace ascendente en el canal de comunicación 36, y también puede tener una o más antenas (no mostradas). En particular, la estación base 32 multiplexa de manera apropiada datos de enlace descendente para las diversas entidades de usuario 34 en la señal de transmisión emitida por la estación base 32. Para ello pueden usarse diferentes esquemas de multiplexación. Por ejemplo, la estación base 32 puede usar OFDM y, en particular, LTE. En cualquier caso, la estación base 32 puede distribuir o asignar los recursos de comunicación del canal de comunicación a las entidades de usuario, incluyendo la entidad de usuario 34, de una manera variable en el tiempo para adaptar la asignación de los recursos de comunicación de la estación base 32 a las entidades de usuario (denominado, entre otras cosas, planificación) a la situación de recursos actual. Por ejemplo, la estación base 32 puede basarse en cualquier combinación de los siguientes parámetros con el fin de realizar la planificación:

1) El número de entidades de usuario 34 a las que da servicio la estación base 32, es decir, el número de entidades de usuario 34 que han realizado un registro en la estación base 32 y, por tanto, el número de entidades de usuario 34 entre las cuales tienen que distribuirse los recursos de comunicación de la estación base.

2) La clase de los datos de comunicación que van a intercambiarse con las entidades de usuario individuales, distinguiendo la clase de datos de comunicación, por ejemplo, datos multimedia en tiempo real (bajo retardo) tales como señales de voz, con respecto a datos pedidos por HTTP y similares.

3) Perfiles de usuario asignados a las entidades de usuario a las que se da servicio, asignándose a los perfiles, por ejemplo, diferentes tasas de transmisión de bits máximas y/o tasas de transmisión de bits mínimas para enlace descendente y/o enlace ascendente, o definiendo una prioridad entre las entidades de usuario favoreciendo el RRM 30, en la asignación de los recursos de comunicación, a entidades de usuario que tienen una prioridad superior con respecto a entidades de usuario que tienen una prioridad inferior.

4) Retroalimentación de calidad de canal a partir de las entidades de usuario, que indica la situación de calidad de recepción actual de las entidades de usuario, es decir, la calidad de canal entre la estación base 32 por un lado y las entidades de usuario a las que se da servicio individuales 34 por otro lado, en la que la estación base 32 mide la calidad de canal, por ejemplo, mediante señales de retroalimentación de canal respectivas a partir de las entidades de usuario.

ES 2 905 831 T3

5) Peticiones de tasas de transmisión de canal a partir de las entidades de usuario, que indican los deseos de las entidades de usuario para la asignación de ancho de banda adicional.

En el caso en el que más de una estación base 32 y 38 puede dar servicio a una entidad de usuario, entonces el número se refiere al número de entidades de usuario a las que dan servicio todas las estaciones base que dan servicio actualmente, o al menos que están actualmente disponibles para dar servicio, a las entidades de usuario en alguna zona. La interacción entre estas estaciones base también puede tenerse en cuenta cuando se determina la asignación de los recursos de comunicación. En esa situación, información tal como subportadoras agregadas por el RRM 30 o información derivada por el RRM 30 sobre las entidades de usuario 34 tal como traspaso entre células, puede compartirse adicionalmente entre las estaciones base 32 y 38 y recopilarse y usarse por un RRM de nivel superior 30.

La estación base 32 puede tener diferentes opciones/parámetros con el fin de asignar de manera diferente los recursos de comunicación a las entidades de usuario. Esto es cierto para la comunicación tanto en enlace descendente como en enlace ascendente. Por ejemplo, la estación base 32 puede implementar una planificación mediante cualquier combinación de los siguientes ajustes:

1) La asociación de subportadoras a las entidades de usuario a las que se da servicio, tales como las subportadoras de OFDM. Normalmente, el número máximo de subportadoras usadas en LTE es un ancho de banda de 20 MHz. Naturalmente, esto puede modificarse. Para el sucesor de LTE, denominado LTE avanzada, están comentándose portadoras múltiples de 20 MHz hasta 100 MHz. Esto se denomina agregación de portadoras. Es decir, las subportadoras también pueden ser subportadoras agregadas.

2) La asociación o distribución de ranuras de tiempo a las entidades de usuario a las que se da servicio.

3) La cobertura espacial de la célula de estaciones base dentro de la cual las entidades de usuario tienen que poder comunicarse con la estación base 32, cambiándose la cobertura espacial mediante el uso, por ejemplo, de técnicas de MIMO.

4) La asociación de las subportadoras individuales a constelaciones de modulación.

En el caso de no implementar la planificación mediante ninguna de las opciones de ajuste que acaban de mencionarse, la estación base 32 puede o bien no usar la característica de transmisión respectiva, o bien usar en su lugar un ajuste fijo. Por ejemplo, la estación base 32 puede no usar multiplexación por división de tiempo dentro del enlace descendente y/o no usar multiplexación por división de tiempo dentro del enlace ascendente o la multiplexación por división de tiempo respectiva puede ser fija a lo largo del tiempo. Lo mismo se aplica con respecto a la funcionalidad de MIMO de la multiplexación por división de frecuencia que implica la asignación de subportadoras.

En cualquier caso, dependiendo de los recursos de comunicación asignados, cada entidad de usuario 34 experimenta un ancho de banda de transmisión efectivo tanto para enlace descendente como para enlace ascendente.

Como nota secundaria debe observarse que el gestor de recursos de radio 30 de la figura 3 puede estar incluido en, puede formar parte de o puede estar alojado por, la estación base 32. Sin embargo, el gestor de recursos de radio 30 también puede estar dispuesto físicamente separado de la estación base 32. En particular, puede incluso ser posible que el gestor de recursos de radio 30 no esté especialmente asociado con una determinada estación base. En vez de eso, el gestor de recursos de radio 30 puede gestionar la gestión de recursos de radio para un número superior de entidades de usuario que resultan en las células de más de una estación base. La figura 3, por ejemplo, muestra una estación base 38 adicional opcional, cuyos recursos de comunicación también pueden controlarse, opcionalmente, por el gestor de recursos de radio 30. En particular, puede ser posible que las estaciones base 32 y 38 formen, junto con un gestor de recursos de radio 30, una red inalámbrica que permite dar servicio de manera simultánea a las entidades de usuario por más de una estación base. Es decir, las entidades de usuario actualmente presentes en la zona solapante de ambas células de estación base pueden tener recursos de comunicación de ambas estaciones base asignados a las mismas por el gestor de recursos de radio 30. Por consiguiente, el ancho de banda de comunicación realmente disponible de la entidad de usuario 34 será, en ese caso, la suma del ancho de banda efectivo ofrecido, o asignado a la misma, por cada una de las estaciones base que dan servicio 32 y 38. Naturalmente, el número de estaciones base que dan servicio puede aumentarse.

En cualquier caso, el problema implicado con la funcionalidad del gestor de recursos de radio 30 tal como se describió hasta ahora es que un cliente 40 que funciona en una de las entidades de usuario, tal como la entidad de usuario 34, busca obtener un contenido multimedia a partir de un servidor 42 en una versión que tiene un nivel de contenido de información lo más alto posible. El cliente puede ser, por ejemplo, una aplicación que se ejecuta en el sistema operativo de una entidad de usuario tal como un navegador, una aplicación de VoIP (voz sobre IP) o similares, aunque también existen otras posibilidades. El servidor, a su vez, puede ser un programa, tal como una aplicación de VoIP o un servidor de contenido multimedia, que se ejecuta en un anfitrión tal como un ordenador, otra entidad de usuario móvil, una estación de trabajo o una red.

ES 2 905 831 T3

Imagínese, por ejemplo, que el cliente 40 de la entidad de usuario 34 busca descargar un contenido multimedia 44 a partir del servidor 42 y que este contenido multimedia 44 está disponible en el servidor 42 en diferentes versiones tal como se describe mediante una descripción de presentación multimedia 46 que también está disponible a partir del servidor 42 para el cliente 40. Las diferentes versiones del contenido multimedia 44 pueden diferir en una combinación de cualquier subconjunto de los siguientes parámetros:

1) Resolución espacial

2) Resolución temporal

3) Número de visualizaciones

4) Profundidad de bits

5) Relación señal-ruido

6) Número de canales de audio

Es decir, el contenido multimedia 44 puede ser un vídeo. El tráfico de datos a través del cual el cliente 40 obtiene el contenido multimedia 44 a partir del servidor 42 puede al menos vigilarse por el gestor de recursos de radio 30 tal como se representa mediante la línea de puntos 48 que muestra que el tráfico de datos entre el servidor 42 y el cliente 40 conduce más allá de la estación base 32 o las estaciones base 32 y 38, respectivamente, pudiendo inspeccionarse un contenido del tráfico de datos por el gestor de recursos de radio 30 tal como se muestra con la flecha 50. Alternativamente, el tráfico de datos puede incluso conducir a través del gestor de recursos de radio 30 tal como se ilustra mediante la flecha de rayas 52 de modo que, según esta alternativa, el gestor de recursos de radio 30 incluso podrá no solo inspeccionar, sino también interceptar o influir de otro modo en porciones del tráfico de datos entre el cliente 40 y el servidor 42.

El tráfico de datos puede usar cualquier protocolo apropiado tal como HTTP. El protocolo de transporte subyacente puede ser TCP o UDP.

Sin embargo, aunque las descripciones de realizaciones se enfocan en transmisión en continuo de HTTP, la propia transferencia de datos también puede aplicarse de manera diferente, tal como mediante RTP [IETF RFC 3550]. Por tanto, una descripción de los medios en una sesión se facilita mediante un archivo de SDP [IETF RFC 4566] (protocolo de descripción de sesión). Se considera que un archivo de SDP de este tipo es una “MPD” en el sentido de la presente solicitud y permite la descripción de diferentes características multimedia tales como diferentes parámetros de codificación de los que elegir.

Debido al hecho de que las diversas versiones del contenido multimedia 44 transmiten una cantidad diferente de información sobre el contenido multimedia 44, estas versiones permiten una clasificación entre estas versiones con respecto a su ancho de banda de transmisión requerido mínimo necesario, necesario con el fin de reproducir la versión respectiva en el cliente 40 sin interrupciones.

Normalmente, un cliente 40 está configurado para proporcionar al usuario una versión que ofrece la información más alta posible sobre el contenido multimedia 44. La versión más alta posible puede definirse como la que todavía puede presentarse al usuario mediante las características disponibles por la entidad de usuario 34 tal como mediante el elemento de visualización y los altavoces disponibles en la entidad de usuario 34, o mediante el reproductor multimedia, decodificador o similar. De manera más precisa, aunque no se muestra en la figura 3, la entidad de usuario 34 puede comprender un elemento de visualización para visualizar la secuencia de tramas del contenido multimedia 44 y uno o más altavoces con el fin de reproducir una señal de audio opcional acompañada a la secuencia de tramas. En este último caso, el cliente 40 puede intentar proporcionar al usuario la versión del contenido multimedia 44 que ofrece la resolución espacial más alta que todavía puede reproducirse por el elemento de visualización de la entidad de usuario 34, por ejemplo.

Finalmente, el cliente 40 pide una versión deseada del contenido multimedia 44 a partir del servidor 42 tal como, por ejemplo, mediante una petición de HTTP. Con el fin de permitir que el cliente 40 decida sobre la versión que va a proporcionarse al usuario, se proporciona al cliente 40 la descripción de presentación multimedia 46 dentro del tráfico de datos desde el servidor 42 hasta el cliente 40. Por ejemplo, el cliente 40 pide la descripción de presentación multimedia 46 del contenido multimedia 44 a partir del servidor 42 que, a su vez, responde enviando la descripción de presentación multimedia 46 al cliente 40. Tal como se describió anteriormente, la descripción de presentación multimedia 46 indica al cliente 40 las versiones disponibles, disponibles en el servidor 42, del contenido multimedia 44 y los anchos de banda de transmisión requeridos mínimos necesarios de estas versiones. Por consiguiente, el cliente 40 evalúa el ancho de banda eficaz actualmente disponible ofrecido o asignado a la entidad de usuario 34 por el gestor

ES 2 905 831 T3

de recursos de radio 30 y selecciona, habitualmente, la versión que tiene el nivel más alto y que necesita, por consiguiente, el ancho de banda de transmisión requerido mínimo más alto que todavía está por debajo del, o es igual al, ancho de banda eficaz ofrecido por el gestor de recursos de radio de vídeo 30.

Sin embargo, tal como se describió en la porción introductora de la memoria descriptiva de la presente solicitud, dado que todos los clientes 40 que funcionan en las entidades de usuario buscan proporcionar a los usuarios la versión de ancho de banda máximo del contenido multimedia respectivo, el esfuerzo impuesto sobre los recursos de comunicación de la estación base 32 es alto aunque, por ejemplo, el esfuerzo no tendría que ser tan alto si los clientes 40 redujeran su nivel de versión pedido.

Por consiguiente, según la realización de la figura 3, el gestor de recursos de radio 30 está configurado para asignar los recursos de comunicación de la estación base 32 a las entidades de usuario incluyendo la entidad de usuario 34, dependiendo de la descripción de representación multimedia 46 dentro del tráfico de datos desde un servidor 42 respectivo hasta un cliente 40 respectivo que funciona en la entidad de usuario 34 respectiva. Tal como resultará más claro a partir de la siguiente descripción, los recursos de comunicación asignados por el RRM usando la dependencia destacada de la MPD 46, pueden referirse especialmente a recursos de comunicación de enlace ascendente y/o de enlace descendente, que representan una parte principal de los recursos de comunicación globales que, a su vez, también pueden abarcar señalización de control tal como el bucle de retroalimentación de acuse de recibo de TCP o la retroalimentación de calidad anteriormente mencionada.

De manera más precisa, el gestor de recursos de radio 30 está configurado para inspeccionar la descripción de presentación multimedia 46 que describe las versiones del contenido de vídeo 44 de diferentes anchos de banda dentro del tráfico de datos desde el servidor 42 hasta el cliente 40 y tiene en cuenta la información proporcionada por la descripción de presentación multimedia, junto con los otros parámetros de entrada, cuando asigna los recursos de comunicación de la estación base 32 a las entidades de usuario entre las cuales está la entidad de usuario 34.

Por ejemplo, si actualmente se impone un alto esfuerzo sobre los recursos de comunicación de la estación base 32 debido, por ejemplo, aun alto número de entidades de usuario 34 a las que debe darse servicio, el gestor de recursos de radio 30 puede decidir que una versión del contenido multimedia 44 actualmente pedida a partir del servidor 42 por el cliente 40 no debe estar actualmente disponible para el cliente 40 y, por consiguiente, reduce la cantidad de recursos de comunicación asignados a la entidad de usuario 34, reduciendo de ese modo realmente el ancho de banda efectivo ofrecido a la entidad de usuario 34. Dicho de otro modo, el gestor de recursos de radio 30 puede decidir que, en situaciones de alto esfuerzo, el cliente 40 debe cambiar de una versión de nivel superior del contenido multimedia 44 a una versión de nivel inferior del mismo, al menos temporalmente durante el alto esfuerzo impuesto sobre los recursos de comunicación de la estación base 32. Evidentemente, el RRM 30 puede comprobar por adelantado la existencia de una versión de ancho de banda inferior de este tipo. Naturalmente, el cliente también puede obtener por algún motivo, por ejemplo, para optimizar la calidad de vídeo visualizada por los clientes en la célula, una versión con un ancho de banda superior con el fin de obtener una cantidad de información o calidad de vídeo aceptable mínima. Dicho de otro modo, el RRM 30 no asigna necesariamente los recursos de comunicación a los clientes simplemente con el fin de optimizar el rendimiento de célula. En vez de eso, el RRM 30 también puede tener en cuenta la calidad de vídeo para todos los clientes en la célula. Dicho incluso de otro modo, evidentemente, hay casos en los que los clientes solicitan de manera conocida la máxima calidad. Un ejemplo de tales clientes son los clientes en el modo de conmutación automática descrito a modo de ejemplo más adelante.

Desde otro punto de vista, el gestor de recursos de radio 30 puede estar configurado para, si los clientes 40 de más de una de las entidades de usuario 34 a las que se asignan los recursos de comunicación, están descargando actualmente contenido multimedia 44 respectivo a través de la al menos una estación base 32, realizar la asignación de los recursos de comunicación a las más de una entidad de usuario 34 dependiendo de la descripción de presentación multimedia 46 respectiva dentro del tráfico de datos respectivo a partir del par respectivo de servidor y cliente de tal manera que se optimiza una función de coste que, al menos, depende de una medida de calidad y un ancho de banda mínimo de las versiones para cada contenido multimedia 44 de los clientes. De manera más precisa, la función de coste que va a optimizarse puede formar un compromiso entre un ancho de banda total y una medida de calidad total determinada a lo largo de las versiones para cada contenido multimedia 44 de los clientes. Esta optimización puede dar como resultado que los clientes obtengan un ancho de banda para una versión de calidad inferior de su contenido multimedia asignada a los mismos con respecto a la que solicitaron originalmente, así como que los clientes obtengan un ancho de banda para una versión de calidad superior de su contenido multimedia asignado a los mismos con respecto a lo que solicitaron originalmente. No se necesita que la “medida de calidad” para las versiones de los contenidos multimedia individuales presente una escala a intervalos. Una escala ordinal tal como la ofrecida por @qualityRanking puede ser suficiente. Es decir, la escala ordinal puede referirse únicamente a los contenidos multimedia individuales. No se necesita que el carácter de ordinal sea válido entre todos los contenidos multimedia de todos los clientes 40. Sin embargo, puede incluirse información adicional en la función de coste de optimización, tal como una medida de una complejidad de codificación del contenido multimedia respectivo, es decir, una medida de una tasa de transmisión promedio/medida de distorsión, del contenido multimedia. Esta medida de complejidad de codificación puede ser muy aproximada. Por ejemplo, @contentCharacteristic mencionado más

ES 2 905 831 T3

adelante puede ser una característica de este tipo. Toda esta información puede incluirse en la descripción de presentación multimedia 46 del contenido multimedia respectivo pedido por el cliente respectivo.

Además, el gestor de recursos de radio 30 puede mantener un registro de un historial de versiones del contenido multimedia 44 pedidas por el cliente 40 con el fin de usar el historial con el fin de volver a asignar una cantidad de recursos de comunicación superior al cliente 40 respectivo en fases en las que el esfuerzo impuesto sobre los recursos de comunicación de la estación base 30 vuelve a disminuir.

A su vez, el cliente 40 constatará, evaluando el ancho de banda efectivo actual proporcionado por el gestor de recursos de radio 30, que (en el caso en el que el RRM 30 decide reducir la cantidad de recursos de comunicación asignados) la versión actualmente pedida y descargada del contenido multimedia 44 puede presentarse al usuario simplemente con interrupciones. Dicho de otro modo, el cliente 40 constatará que la memoria intermedia multimedia del reproductor multimedia que reproduce el contenido multimedia 44 para el usuario va a vaciarse debido a la disminución del ancho de banda de transmisión disponible a través del trayecto de comunicación inalámbrico 36. Aunque el cliente 40 es libre de reaccionar ante esta situación como desee o como desee el cliente, una opción razonable del cliente 40 sería enviar una petición al servidor 42, pidiendo una versión de nivel inferior del contenido multimedia 44, es decir, una versión asociada con un ancho de banda de transmisión mínimo necesario inferior en comparación con la versión actualmente descargada del contenido multimedia 44.

En resumen, según la realización de la figura 3, el gestor de recursos de radio 30 realiza la planificación (además de dependiendo de recursos disponibles, calidad de canal tal como se indica por la retroalimentación de entidades de usuario, número de peticiones de recursos a partir de las entidades de usuario asociadas, prioridades entre las entidades de usuario y similares, tal como se mencionó anteriormente) dependiendo de la descripción de presentación multimedia 46 dentro del tráfico de datos que se extiende entre pares respectivos de servidores y clientes que funcionan en entidades de usuario respectivas.

Con respecto a la realización de la figura 3, se observa que el cliente 30 puede representar, por ejemplo, software que está ejecutándose en un procesador de entidad de usuario. Alternativamente, el cliente puede implementarse en hardware o hardware programable.

Por tanto, la figura 3 revela un gestor de recursos de radio configurado para asignar recursos de comunicación de una estación base 32 a entidades de usuario 34 dependiendo de una descripción de presentación multimedia 46 dentro de un tráfico de datos desde un servidor 42 hasta un cliente 40 que funciona en una de las entidades de usuario 32.

A continuación, se explica una posible implementación de la realización de la figura 3. Según esta posible implementación, el cliente 30 usa transmisión en continuo de vídeo sobre HTTP con el fin de obtener el contenido multimedia 44 a partir del servidor 42. En particular, el protocolo de transporte subyacente usado para la transmisión en continuo de vídeo sobre HTTP puede ser TCP [RFC 793].

De hecho, las implicaciones indicadas en este caso son válidas para todos los protocolos que comparten las propiedades descritas a continuación. Los protocolos considerados en este caso son protocolos orientados a conexión con un mecanismo de control de congestión basado en recepción de ACK (acuse de recibo) / NACK (acuse de recibo negativo) o cualquier otro tipo de acuse de recibo tal como SACK (acuse de recibo selectivo) usado para TCP. Posiblemente, estos protocolos pueden usar mecanismos de retransmisión adicionales para lidiar con pérdidas de paquetes en paralelo al resultado de adaptación de rendimiento del mecanismo de control de congestión. Un ejemplo de un protocolo de este tipo sería cuando el protocolo de transporte subyacente usado para la transmisión en continuo de vídeo sobre HTTP es el TCP [RFC 793]. TCP proporciona transferencia de datos de transmisión en continuo con características potenciadas para proporcionar fiabilidad, por ejemplo usando mensajes de acuse de recibo (ACK) y mecanismos de control de flujo, por ejemplo control de congestión mediante inicio lento, evitación de congestión, retransmisión rápida y recuperación rápida. El control de flujo indica al transmisor cuántos bytes pueden recibirse sin desbordar las memorias intermedias internas. Las tasas de transmisión multimedia y de estado relevantes se representan en la figura 4 y la tabla 1. Tal como puede observarse en la figura 4, la pérdida de paquetes tiene una influencia sobre el rendimiento de TCP recibido y se espera lo mismo para cualquier otro protocolo con las características anteriormente mencionadas. Además, la siguiente ecuación muestra una estimación muy buena del rendimiento de TCP basándose en la pérdida de paquetes (p), tiempo de ida y vuelta (RTT) y unidad de transmisión máxima (MTU) [18]. Por tanto, realizar un seguimiento de pérdidas de paquetes de capa de red en la transmisión es una técnica muy eficaz para permitir que el gestor de recursos de radio asigne recursos de comunicación de una estación base 32 de manera apropiada. Por tanto, 32 puede derivar a partir de la información de capa PHY, tal como tramas de radio perdidas/unidades de datos de paquetes de capa de MAC y el tamaño de MTU de capa superior así como la pérdida de paquetes de TCP en las memorias intermedias de MAC 100 de 30 (véase la figura 13) para derivar la tasa de pérdida de paquetes real en la capa de red superior tal como la capa de transporte, por ejemplo para TCP.

ES 2 905 831 T3

1,22 * MTU

r ~ RTT*4p

Tabla 1, tasas de transmisión y tiempos disponibles

Con respecto a la figura 3, por ejemplo, el gestor de recursos de radio 30 tiene diferentes posibilidades para comprobar qué versión de un contenido multimedia de la MPD 46 está descargando actualmente el cliente 40. Por ejemplo, el RRM 30 puede determinar la versión del contenido multimedia 44 actualmente descargada por el cliente 44 a través de la estación base 32 inspeccionando una petición multimedia desde el cliente 40 hasta el servidor 42. Sin embargo, puede lograrse un procesamiento más sencillo en el RRM 30 con menos operaciones de seguimiento cuando el RRM 30 determina una medida de rendimiento para un rendimiento multimedia recibido del cliente y predice a partir de la medida de rendimiento determinada qué versión de un contenido multimedia 44 de la descripción de presentación multimedia 46 está descargando actualmente el cliente 44 a través de la al menos una estación base 32. Como medida de rendimiento, puede usarse el propio ancho de banda asignado. Alternativamente, el RRM 30 puede intentar estimar la desviación/disminución del ancho de banda de contenido multimedia realmente recibido del cliente 40 respectivo con respecto al ancho de banda originalmente asignado a la entidad de usuario respectiva, a modo de una evaluación de la retroalimentación de calidad enviada desde la entidad de usuario 34 respectiva hasta la estación base 32, tal como acaba de describirse. De manera incluso alternativa, una funcionalidad adicional de la entidad de usuario puede informar al RRM 30 sobre la tasa de rendimiento de contenido multimedia realmente recibido.

Aunque la descripción anterior suponía que el gestor de recursos de radio vigila el tráfico de datos desde el servidor 42 hasta el cliente 40 para obtener la descripción de presentación multimedia 46, esta sobrecarga puede desplazarse alternativamente a la entidad de usuario tal como alguna entidad dentro de la entidad de usuario, que está entre una fase de transceptor de la entidad de usuario y el cliente (véase la figura 7, por ejemplo). Es decir, esta vigilancia puede asumirse por una fase de vigilancia dentro de la entidad de usuario. La fase de vigilancia reenviará la MPD 30 (de vuelta) al RRM 30, o al menos una subparte de la misma tal como un fragmento de la misma, o un conjunto de parámetros que se derivan a partir de una subparte de la MPD, en la que el fragmento o conjunto de parámetros puede ser, a su vez, suficiente con el fin de describir el contenido multimedia y sus versiones disponibles en el servidor 32. Por tanto, la entidad de usuario 34 puede estar configurada para comunicarse con la estación base de recursos de radio 32 y puede tener el cliente 40 operativo en la misma, tal como se describió anteriormente, en la que, sin embargo, la entidad de usuario 34 puede estar configurada adicionalmente para vigilar el tráfico de datos desde el servidor 42 hasta el cliente 40 para derivar la descripción de presentación multimedia 46 a partir del tráfico de datos y reenviar, al menos parcialmente, la descripción de presentación multimedia al gestor de recursos de radio 30. Después, se mostrará que la entidad de usuario puede tener un servidor que funciona en la misma en vez del cliente 40, actuando el RM, sin embargo, de la misma manera, es decir, vigilando el tráfico de datos desde ese servidor hasta cualquier cliente fuera de la entidad de usuario con el fin de derivar la MPD.

Además, en la implementación de la figura 3 descrita a continuación, el cliente 40 y el servidor 42 pueden usar DASH con el fin de transmitir en continuo el contenido multimedia 44 desde el servidor 42 hasta el cliente 40. DASH define una determinada estructura o sintaxis para la descripción de presentación multimedia. Según DASH, la MPD usa etiquetas para especificar parámetros necesarios para establecer canales lógicos entre el cliente de DASH y el servidor de HTTP de DASH. Las etiquetas pueden ser o bien opcionales, marcadas con la letra O, o bien obligatorias, marcadas con la letra M.

Para implementar la realización de la figura 3, puede usarse una combinación de etiquetas de MPD, tomadas a partir de la norma de MPEG de DASH (ISO/IEC 23009-1 [3]).

En particular, puede tenerse en cuenta la etiqueta obligatoria @bandwidth que se basa en la etiqueta @minBufferTime y que, por tanto, es casi obligatoria.

Las etiquetas con las que puede construirse la MPD comprenden:

ES 2 905 831 T3

Tabla 2, etiquetas de MPD

ES 2 905 831 T3

ES 2 905 831 T3

Es decir, la MPD 46 de la figura 3 puede tener los parámetros @bandwidth, @minBufferTime y, opcionalmente, @qualityRanking para cada versión disponible (representación).

Tal como puede observarse anteriormente, incluso sería posible que la MPD 46 comprenda simplemente los dos primeros de estos parámetros por cada versión, concretamente @bandwidth y @minBufferTim.

ES 2 905 831 T3

En la lista 1 a continuación se muestra un ejemplo de una MPD. El ejemplo puede corresponder a un perfil específico de la norma de DASH [3] tal como se identifica, por ejemplo, mediante el atributo de perfil. El tiempo de presentación multimedia se especifica en 3256 segundos, el tiempo de memoria intermedia mínimo en 1,2 segundos. Se facilitan los URL (localizador de recursos uniforme) de los segmentos de dos representaciones cuando una representación requiere un ancho de banda de 64 KB o 32 KB y cuando los URL de los segmentos se crean concatenando uno de los dos BaseURL y los SegmentURL alternativos incluidos en los elementos de SegmentList respectivos de cada representación. La duración de los segmentos viene dada por el atributo de duración en el elemento de SegmentList.

<?xml version=”1.0” encod¡ng:=”UTF-8,,?>

<MPD

mediaPresentati onDuration=”PT3256S”

minBufferTime^TT 1.2S”

profiles=”um:mpeg:mpegB:profile:dash:isoff-live”>

<BaseURL>http://cdn1.eiemplo.com/</BaseURL>

<BaseURL>http://cdn2.eiemplo.com/</BaseURL>

<Representation bandwidth=',64000,,>

<SegmentList duration=10>

<SegmentilRL media="segM.mp47 >

< SegmentilRL media=Msegl-2.mp47 >

< SegmentilRL media=ltsegl-3.mp47>

< SegmentilRL media-"seg2U.mp47>

< SegmentilRL media-,,seg2-2.mp47>

< SegmentilRL media^nseg2-3.mp47 >

</SegmentList>

</Repre sentation>

</MPD>

Además, la implementación de la realización de la figura 3 expuesta en más detalle a continuación puede incorporarse dentro de un sistema de LTE. Es decir, la estación base 32 o las estaciones base 32 y 38 y el gestor de recursos de radio 30 pueden formar parte de un sistema de LTE.

Para LTE, se han introducido diferentes mejoras. Pasar a acceso múltiple por división de frecuencia ortogonal (OFDMA) en combinación con mejoras de múltiples entradas y múltiples salidas (MIMO) y migración desde conmutación de circuito hasta redes de conmutación de paquetes ha dado como resultado una red móvil que logra rendimientos pico de hasta 150/300 Mbps para LTE, ver. 8, con 2x2/4x4 MIMO. Uno de los logros clave de LTE es el cumplimiento de los requisitos de latencia de ITU-R [15] con un retardo por debajo de 50 ms en el plano de control y por debajo de 5 ms en el plano de usuario, esencial para un bajo retardo de extremo a extremo.

LTE implementa mecanismos de retransmisión rápida: mecanismos de peticiones de repetición automáticas (ARQ) y ARQ híbridas (HARQ) en la capa física (PHY) y capas de acceso al medio (MAC), lo cual requiere una reordenación rápida en el receptor. Por tanto, puede introducirse fluctuación y retardo adicionales mediante almacenamiento en

ES 2 905 831 T3

memoria intermedia de reordenación dando como resultado degradación del rendimiento para servicios de TCP en tiempo real, especialmente si no se identifican servicios de vídeo de HTTP/TCP y se ejecutan a modo de libre transmisión como servicio de mejor esfuerzo. El rendimiento de TCP durante el traspaso en LTE se evalúa en [12] y se muestra que se necesitan técnicas de reenvío de paquetes especiales y reordenación de paquetes para lograr un alto rendimiento de TCP.

Además, LTE introduce planificación descentralizada y gestión de recursos de radio (RRM) de múltiples usuarios en la estación base, el NodoB evolucionado (eNB). El enfoque descentralizado requiere el diseño de nuevos algoritmos de planificación a través de capas robustos con soporte de QoS con el fin de realizar QoS de extremo a extremo para diferentes servicios de tráfico, tales como transmisión en continuo en directo de HTTP/TCP.

La entidad de RRM, es decir, 30, es responsable de la gestión de recursos de radio lo cual incluye asignar recursos a los UE, es decir, 34, en un intervalo de tiempo a corto plazo, también denominado planificación, así como asignación de recursos a largo plazo, que funciona en un intervalo de tiempo más prolongado y depende de diversos parámetros, por ejemplo retroalimentación de UE, demandas de servicio de usuario, etc. Los recursos que van a asignarse se toman de la rejilla de tiempo, frecuencia y espacio usada en LTE que se basa en OFDMA de MIMO. La cantidad de recursos depende de los parámetros de LTE ancho de banda, modo de FDD o TDD y modo de MIMO que van a usarse.

Cuando se implementa la realización de la figura 3 con el uso de DASH para transmitir en continuo el contenido multimedia e incorporar el gestor de recursos de radio 30 en un sistema de LTE, el resultado de lo mismo puede representarse tal como se muestra en la figura 5. Con el fin de facilitar la comprensión sobre cómo la realización de la figura 5 implementa las funcionalidades de los elementos mostrados en la figura 3, se han reutilizado los signos de referencia de la figura 3 en la figura 5 y las explicaciones y descripción de estos elementos presentadas anteriormente con respecto a la figura 3 se aplicarán de igual manera para la figura 5. A su vez, esto también significa que el RRM 30 no necesita estar físicamente contenido dentro de la estación base 32. Por otro lado, se han reutilizado algunos signos de referencia de la figura 2 en la figura 5 siempre que falten signos de referencia correspondientes en la figura 3. Por consiguiente, se muestra que el cliente 40 está conectado en comunicación con el servidor 42 de tal manera que el tráfico de datos discurre a través del caché de HDTP 16 tal como Internet, en lo que se refiere a la porción de tráfico de datos más allá de la estación base 32. Además, se muestra la fase de preparación de contenido de DASH 14 a partir de la cual puede proceder originalmente el contenido de la descripción de presentación multimedia 46.

En la descripción del modo de funcionamiento del ejemplo de implementación de la figura 5, puede denominarse gestión de recursos de radio usando DASH a través de LTE. Como una representación posible de las versiones del contenido multimedia, puede usarse una VC. Dado que la implementación de la figura 5 sigue la realización de la figura 3, la funcionalidad del RRM 30 de la figura 5 realiza una señalización pasiva con el fin de asignar de manera más eficiente el recurso de radio a los clientes.

En particular, el cliente de DASH 40 emite una petición de HTTP de un segmento de vídeo al servidor 42. La unidad de RRM 30 inspecciona la MPD 46 pedida por el usuario o cliente 40 particular usando inspección de paquetes profunda 50. Dependiendo de las etiquetas @bandwidth y @minBufferTime definidas dentro de la MPD 46, el planificador y el RRM a largo plazo 30 realizan el ancho de banda pedido para el @minBufferTime dado. Sin embargo, si la canalización de datos de PHY de LTE no soporta el ancho de banda pedido, el RRM 30 intenta automáticamente garantizar el siguiente ancho de banda inferior especificado para el segmento de vídeo de AVC del contenido multimedia dentro de la MPD 46 o recuadro “sidx” y MPD. El cliente de DASH 40 ajusta sus peticiones de tipo HTTP get 52 según la restricción de tasa de transmisión de datos del RRM 30 de la LTE, por ejemplo enviando una petición de tipo HTTP get 52 para un servicio con requisitos de tasa de transmisión inferiores tal como se indica en la MPD 46.

Esto garantiza:

1. Suministro de servicio garantizado del flujo de vídeo de HTTP

2. Evita aprovisionamiento excesivo de recursos a un usuario dado que intente obtener tantos recursos como sea posible

3. Por tanto 2 permite ahorrar recursos para otros usuarios dentro de la célula de LTE para una rejilla de tiempofrecuencia-espacio dada. Esto reduce la variación en el rendimiento de IP y, por tanto, permite un suministro de servicio fluido de diversas mezclas de tráfico a múltiples usuarios.

4. TCP se adaptará de manera óptima a la tasa de transmisión de datos asignada por el sistema de LTE

Dado que los recursos de radio en sistemas celulares se comparten entre todos los usuarios conectados al mismo eNB, la cantidad de recursos asignada a un usuario puede tener un impacto sobre cuántos recursos están disponibles para otros usuarios. Por tanto, el RRM 30 puede elegir reducir la cantidad de recursos para un usuario, aunque este

ES 2 905 831 T3

usuario tenga muy buenas condiciones de canal, en favor de dar soporte a otros usuarios. Teniendo en cuenta la tasa de transmisión de bits y las características de contenido (tipo de contenido, por ejemplo, película, noticias, deportes) o @qualityRanking, puede llevarse a cabo una optimización de calidad de vídeo global a lo largo de todos los usuarios en la célula.

Puede identificarse el uso de modos de control de movimiento (por ejemplo, avance rápido, retroceso rápido, salto) por el RRM 30 mediante secuencia de fragmentos pedidos por el cliente 40. Después del uso de modo de control de movimiento, el cliente tiene que realizar un nuevo almacenamiento en memoria intermedia durante @minBufferTime / nueva detección de almacenamiento en memoria intermedia mediante DPI. DPI significa inspección de paquetes profunda. Esto implica que el planificador de estación base mira el contenido de los paquetes de IP toma sus decisiones basándose en sus inspecciones. Tradicionalmente, el RRM funciona en la capa de MAC y no mira en la capa de IP, tal como se propone por el modelo de ISO-OSI.

Con respecto a la implementación que acaba de describirse de la realización de la figura 3 mediante los detalles descritos con respecto a la figura 5, se observa que los diversos aspectos en los que la figura 5 concreta la realización de la figura 3 pueden transferirse de manera individual a la figura 3. Esto es cierto, por ejemplo, para el uso del protocolo de TCP para el tráfico de datos, el uso del sistema de LTE para definir la funcionalidad respectiva del gestor 30, la estación base 32 y la entidad de usuario 34 y el entramado de transmisión en continuo de DASH que define, al menos parcialmente, el contenido de la MPD 46 y la funcionalidad del servidor 42 y el cliente 40.

Según las realizaciones de las figuras 3 a 5, el gestor de recursos de vídeo 30 dicta directamente la asignación de tasa de transmisión a las entidades de usuario individuales y a sus clientes 40, respectivamente, tal como se ilustra en la figura 5 en la “R” basándose en una evaluación de la descripción de presentación multimedia dentro del tráfico de datos desde el servidor 42 hasta el cliente 40 y asignando los recursos de comunicación de la estación base 32 a las entidades de usuario en consecuencia. Según las realizaciones descritas a continuación, esta funcionalidad del gestor de recursos 30 es opcional.

La figura 6 muestra un gestor de recursos de radio según una realización adicional, no reivindicada, de la presente invención. Tal como acaba de mencionarse, con respecto a la funcionalidad e interconexión de los elementos habitualmente mostrados en las figuras 3 y 6, la descripción presentada anteriormente con respecto a la figura 3 sigue siendo la misma. Es decir, el gestor de recursos de radio 30 asigna los recursos de comunicación de la estación base 32 a las entidades de usuario 34 de la manera tal como se describió anteriormente, excepto porque la dependencia de esta asignación de la descripción de presentación multimedia 46 es opcional. Además, según la realización de la figura 6, el gestor de recursos de radio 30 está dispuesto de tal manera que el tráfico de datos entre el cliente 40 y el servidor 42 discurre a través del gestor de recursos de radio 30 de modo que este último puede influir en este tráfico de datos tal como se describe a continuación.

En particular, según la realización de la figura 6, el gestor de recursos de radio 30 está configurado adicionalmente, es decir, además de la funcionalidad descrita anteriormente con respecto a la figura 3, para inspeccionar la descripción de presentación multimedia 46 que describe las versiones del contenido multimedia 44 de diferentes anchos de banda, dentro del tráfico de datos desde el servidor 42 hasta el cliente 40 que funciona en la entidad de usuario 34, así como una petición multimedia 60 desde el cliente 40 hasta el servidor 42, pidiendo la petición multimedia 60 una versión deseada del contenido multimedia 44. Basándose en ambas inspecciones, el gestor de recursos 30 decide, dependiendo de información que describe la situación de recursos actual al menos con respecto a la entidad de usuario 34 que envía la petición 60, y la descripción de presentación multimedia dirigida a la entidad de usuario 34: 1) reenviar la petición multimedia 60 al servidor 42 (sin modificar) o, alternativamente, 2) provocar que la petición multimedia 60 no conduzca a que se envíe la versión deseada del contenido multimedia 44 al cliente 40. Por ejemplo, el gestor de recursos 30 puede realizar la provocación mediante 2a) modificación de la petición multimedia 60 hasta el grado de que la petición multimedia modificada pide una versión del contenido multimedia 44 de menos ancho de banda o 2b) intercepción de la petición multimedia 44 y emulación o indicación al servidor 42 de que envíe de vuelta una respuesta de no disponibilidad desde el servidor 42 hasta la entidad de usuario 34 o el cliente 40. Alternativamente, puede realizarse una respuesta sobre bajo ancho de banda por el RRM 30 o puede provocarse que se realice cualquier otra retroalimentación por el servidor para indicar al cliente que cambie su petición en consecuencia.

Esto significa lo siguiente. Tal como se describió anteriormente con respecto a la figura 3, el gestor de recursos de radio 30 tiene acceso a la información de situación de recursos actual. En particular, el gestor de recursos de radio 30 tiene acceso a esta información de situación de recursos actual no solo con respecto a la entidad de usuario 34, sino para todas las entidades de usuario. Basándose en esta información, el gestor de recursos de radio 30 conoce sobre el esfuerzo actual impuesto sobre los recursos de comunicación de la estación base 32 y conoce sobre los recursos de comunicación disponibles para la entidad de usuario 34. Además, el gestor de recursos de radio 30 tiene acceso a la descripción de presentación multimedia 46 e inspeccionando la misma el gestor de recursos de radio 30 conoce sobre versiones alternativas del contenido multimedia 44 que el cliente 40 en la entidad de usuario 34 busca descargar.

Basándose en la información global, es decir, la información de situación de recursos actual y la descripción de

ES 2 905 831 T3

presentación multimedia 46, el gestor de recursos de radio 30 puede decidir sobre si la carga actual a la que se enfrenta la estación base 32 es lo suficientemente baja como para justificar reenviar simplemente la petición multimedia 60 al servidor 42 en una versión sin modificar. Sin embargo, si el gestor de recursos de radio 30 determina, a partir de la información de situación de recursos actual y la descripción de presentación multimedia, que parte del ancho de banda necesario para la versión actualmente pedida de contenido multimedia 44 no debe transferirse a partir de las otras entidades de usuario, porque, por ejemplo, el ancho de banda restante no es ni siquiera suficiente para proporcionar a todos estos otros clientes de las entidades de usuario la versión de ancho de banda más bajo de su contenido multimedia pedido, el gestor de recursos de radio 30 decide modificar la petición multimedia 60 hasta el grado de que la petición multimedia modificada pide una versión de ancho de banda inferior. Por consiguiente, el servidor 42 responderá a esta petición modificada enviando la versión de ancho de banda inferior al cliente 40 que puede gestionar el caso de que la respuesta a su petición es realmente la respuesta a una petición de una versión de ancho de banda inferior. Por ejemplo, la versión de ancho de banda inferior difiere de la versión originalmente deseada del contenido multimedia 44 simplemente por la omisión de determinadas partes de flujo multimedia, la omisión de las cuales no altera al decodificador multimedia en la entidad de usuario 34 responsable de reproducir el contenido multimedia. Es decir, la versión de ancho de banda inferior puede ser un nivel de información inferior de un contenido multimedia ajustable a escala, o la versión de ancho de banda inferior puede ser otro archivo multimedia, que, sin embargo, se codifica usando el mismo esquema de codificación.

En vez de modificar la petición multimedia 60, puede ser posible que el servidor 42 intercepte la petición multimedia 60 y emule o indique al servidor que envíe de vuelta una respuesta de no disponibilidad desde el servidor 42 hasta el cliente 40. En ambos casos, el cliente 40 recibirá una respuesta a partir del servidor 42 según la cual la versión deseada no está disponible en el servidor aunque se indique en la descripción de presentación multimedia 46. Aunque el cliente 40 es libre de reaccionar a esta respuesta de cualquier manera, una manera razonable de reacción implicaría que el cliente 40 envíe de nuevo otra petición al servidor 42 con una nueva petición que pide, sin embargo, una versión de ancho de banda inferior del contenido multimedia 44 a partir del servidor 42, dando de ese modo como resultado en realidad la misma situación que la resultante de la modificación anteriormente mencionada de la petición multimedia, concretamente que el servidor 42 envíe de vuelta al cliente 40 la versión de ancho de banda inferior.

Por tanto, una primera etapa que puede estar implicada en la decisión del gestor de recursos de radio entre las tres opciones de decisión anteriormente identificadas de 1) a 2b) puede ser comprobar si hay cualquier versión de ancho de banda inferior del contenido multimedia 44 disponible o no. Esta comprobación se realiza basándose en la descripción de presentación multimedia 46. Una segunda etapa puede implicar comprobar la información de situación de recursos actual, en cuanto a si cualquiera de las opciones 2a) o 2b) es aconsejable o no.

A continuación se describe, con respecto a la figura 7, una extensión o abstracción adicional de la realización de la figura 6. La figura 7 muestra una realización de la entidad de usuario 34 en más detalle. Según la realización descrita a continuación con respecto a la figura 7, la funcionalidad adicional de gestores de recursos de radio con respecto a la gestión, es decir, reenvío, modificación y/o intercepción, de la petición multimedia 60, se desplaza desde el gestor de recursos de radio 30 a lo largo del tráfico de datos entre el servidor 42 y el cliente 40 hasta el dominio de entidades de usuario 34 y, en particular, alguna parte entre una fase de transmisión de entidades de usuario 70 y el cliente 40. Sin embargo, debe entenderse que esto también es simplemente un ejemplo y que esta funcionalidad también puede asumirse por otra entidad, posicionada en otra parte.

En particular, la figura 7 muestra la entidad de usuario 34 como que comprende una o varias antenas 72, una fase de transceptor 70, un gestor de recursos 74, el cliente 40, un reproductor multimedia 76 y hardware para presentar realmente los medios al usuario incluyendo, por ejemplo, un elemento de visualización 78 y uno o varios altavoces 80. Todos estos elementos están conectados en serie entre sí en el orden en el que se mencionan. La fase de transmisión 70 es responsable de realizar la comunicación con la estación base 32 de modo que el trayecto de datos respectivo es transparente para las aplicaciones de capa posterior o superior tales como las representadas por el cliente 40. La fase de transceptor 70 realiza, por ejemplo, la (de)multiplexación tal como (de)multiplexación de OFDM, (de)multiplexación por división de tiempo, retroalimentación de calidad de recepción a la estación base 32, estimación de canal y así sucesivamente. Además, la fase de transceptor 70 puede enviar peticiones a la estación base 32 que piden que se asigne un aumento de ancho de banda a la entidad de usuario 34 respectiva activándose el envío de tales peticiones, por ejemplo, mediante cualquiera de los módulos posteriores tales como el cliente 40. La fase de transceptor 70 puede implementarse en hardware o una combinación de hardware, hardware programable y/o software o cualquier combinación de los mismos.

El gestor de recursos 74 está conectado entre la fase de transceptor 70 y el cliente 40 y, por consiguiente, puede realizar la funcionalidad del gestor de recursos de radio anteriormente explicada con respecto a la modificación, reenvío y/o intercepción de peticiones multimedia desde el cliente 40 hasta el servidor 42 a través de la interfaz inalámbrica representada por la fase de transceptor 70 y la antena 72, respectivamente. Es decir, el gestor de recursos 74 tiene acceso a información de situación de recursos actual a través de la fase de transceptor 70. En particular, la fase de transceptor 70 puede informar al gestor de recursos 74 sobre una tasa de transmisión actualmente disponible resultante de la asignación actual de recursos de comunicación a las entidades de usuario por el gestor de recursos

ES 2 905 831 T3

de radio 30 (véase la figura 6). Además, el gestor de recursos 74 puede inspeccionar la descripción de presentación multimedia 46 dentro del tráfico de datos desde el servidor 42 hasta el cliente 40. Al inspeccionar la petición multimedia 60 desde el cliente 40 hasta el servidor 42, el gestor de recursos 74 puede, por tanto, realizar la misma decisión tal como se describió anteriormente con respecto a la figura 6, concretamente la decisión entre las opciones de decisión anteriormente comentadas de reenviar la petición multimedia o, alternativamente, modificar la petición multimedia o interceptar la petición multimedia con emulación o indicación al servidor 42 de que envíe una respuesta de no disponibilidad. Naturalmente, el gestor de recursos 74 simplemente tiene acceso a un subconjunto apropiado de la información de situación de recursos actual en comparación con el gestor de recursos de radio 30. Sin embargo, no obstante, el gestor de recursos 74 puede evitar que el cliente 40 pida versiones de contenido multimedia 44 que, cuando se considera la situación de recursos en la estación base 32 en su totalidad, no es justa con respecto a la estación base 32 de servidor de otros usuarios o puede no poder transmitirse en continuo de manera frecuente por el cliente 40.

Con respecto a las realizaciones de las figuras 6 y 7, debe observarse que el gestor de recursos 30 y 74, respectivamente, puede estar configurado para conmutar simplemente entre las opciones 1) y 2) o 1) y 3). Además, con respecto al gestor de recursos 74, se observa que el mismo puede estar configurado para aprovechar, como parte de la información de situación de recursos actual, garantías de recursos de comunicación a largo plazo enviadas por el gestor de recursos de radio 30 a la entidad de usuario 34.

Por tanto, las figuras 6 y 7 revelan un gestor de recursos configurado para inspeccionar una descripción de presentación multimedia 46 que describe versiones de un contenido multimedia 44 de diferentes anchos de banda, dentro de un tráfico de datos desde un servidor 42 hasta un cliente 40 que funciona en una entidad de usuario 34; inspeccionar una petición multimedia 60 desde el cliente 40 hasta el servidor 42, que pide una versión deseada del contenido multimedia 44; y decidir, dependiendo de una información de situación de recursos actual y la descripción de presentación multimedia 46, (1) reenviar la petición multimedia 60 al servidor o, alternativamente, (2) modificar la petición multimedia 60 hasta el grado de que la petición multimedia modificada pide una versión del contenido multimedia 44 de menos ancho de banda, o interceptar la petición multimedia 60 y emular o indicar al servidor 42 que envíe de vuelta una respuesta de no disponibilidad desde el servidor 42 hasta el cliente 40.

De manera similar a la realización descrita anteriormente con respecto a las figuras 3 a 5, a continuación se describen posibles implementaciones de las realizaciones de las figuras 6 y 7. Es decir, estas posibles implementaciones suponen que el sistema de comunicación inalámbrica es un sistema de LTE y la transmisión en continuo del contenido multimedia usa DASH. De la misma manera que la figura 5 con respecto a la figura 3, la figura 8 vuelve a usar los signos de referencia anteriormente usados y, por consiguiente, la descripción de la funcionalidad de los elementos de las figuras 6 y 7 se aplicará de igual manera a los elementos mostrados en la figura 8 con los mismos signos de referencia.

En combinación con DASH, el RRM de LTE 30 puede inspeccionar la MPD 46 pedida por todos los UE 34 conectados. Si un UE dado tiene un buen canal de radio y emite una petición de alto ancho de banda 60, el RRM de LTE 30 puede enviar un desencadenador de código de estado, unas denominadas inyecciones de código de estado, de tal manera que el servidor de HTTP de DASH 42 transmite un código de estado de HTTP de W3C 80 para indicar que este ancho de banda no está disponible. A continuación se indican posibles códigos de estado de HTTP de W3C. Por tanto, el RRM de LTE 30 puede forzar un UE 34 a pedir una tasa de transmisión de datos inferior sin señalizar directamente al UE 34. Esto ahorra recursos usados para señalización que pueden usarse en vez de eso para datos, por ejemplo estos recursos pueden planificarse para otros UE 34. El servicio de TCP/IP del UE adapta automáticamente la tasa de transmisión asignada mediante los algoritmos de RRM de eNB, que puede tomarse a partir de la etiqueta @bandwidth de MPD.

La unidad de RRM de eNB 30 inspecciona la MPD 46 pedida por un UE 34. Además, puede tomar información a partir de la entidad de gestión de movilidad (MME) no mostrada en la figura 8. Dependiendo del perfil de usuario, por ejemplo velocidad de movimiento, datos estadísticos de traspaso y MPD pedida, la entidad de RRM 30 puede implementar una calidad de vídeo superior o inferior mediante señalización indirecta 80 a través de códigos de estado de HTTP de W3C (véase, por ejemplo, http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html).

En la descripción anterior de la figura 8, se supuso que las versiones del contenido multimedia 44 disponibles en el servidor 42 están disponibles de manera independiente, es decir, en versiones no ajustables a escala, sin embargo, en contenido de información diferente. Sin embargo, la descripción anterior de la figura 8 puede transferirse fácilmente al caso en el que las diferentes versiones de ancho de banda disponibles del contenido multimedia 44 están disponibles en forma de un flujo multimedia que, sin embargo, está codificado de una manera ajustable a escala tal como un flujo de SVC o MVC. En este caso, el modo de funcionamiento del gestor de recursos de radio 30 de la figura 8 puede describirse de la siguiente manera.

La entidad de RRM de LTE 30 inspecciona la MPD 46 pedida por el usuario particular usando inspección de paquetes profunda 50. Dependiendo de los recursos de radio disponibles, el planificador de LTE 30 evalúa la cantidad de ancho

ES 2 905 831 T3

de banda pedida por un usuario dado. Si el ancho de banda pedido supera el ancho de banda disponible para una capa de SVC o MVC dada, la entidad de RRM de LTE 30 puede desencadenar el servidor de HTTP de DASH 42 para que envíe un código de estado de HTTP de W3C a ese usuario 40. El decodificador de SVC/MVC 70 dentro del cliente de DASH 40 recibe el código de estado de error y pide automáticamente una capa de SVC o MVC inferior que requiere menos ancho de banda y, por tanto, ahorra recursos de radio en el sistema de LTE.

Los recursos de radio pueden limitarse debido a mala calidad de canal de un usuario dado o debido a la cantidad de otros usuarios que piden recursos. El RRM de LTE 30 puede forzar a usuarios con buena calidad de canal a sacrificar recursos que entonces pueden asignarse a usuarios que presentan una calidad de canal peor.

Dependiendo de la política de prioridad dentro del RRM de LTE 30, el RRM 30 puede usar la MPD 46 para garantizar el suministro de servicio a la capa de SVC/MVC más baja, la capa de base, antes de permitir peticiones de HTTP de capas de SVC/MVC superiores mediante desencadenamiento de códigos de estado de HTTP de W3C 80.

El servidor de HTTP de DASH 42 puede transmitir uno de los siguientes códigos de estado de HTTP de W3C:

ñ 404 No encontrado

ñ 466 Tasa de transmisión en continuo excedida (tbs. en RFC)

ñ 503 Servicio no disponible

ñ 509 Límite de ancho de banda excedido

Antes de pasar a describir la siguiente realización de la presente solicitud, debe observarse que la estructura general de una entidad de usuario 34 tal como se muestra en la figura 7 también es aplicable, generalmente, a todas las demás realizaciones cuando se retira el gestor de recursos 74. El reproductor multimedia 76 puede ser un decodificador multimedia que puede decodificar el contenido multimedia 44 recibido a partir del servidor 42. El cliente 40 y el reproductor multimedia 76 pueden estar acoplados entre sí y comunicarse entre sí. El reproductor multimedia puede incluso estar parcialmente integrado dentro del cliente 40.

Según la realización de las figuras 3 a 5, los recursos de comunicación asignados a las entidades de usuario individuales y, en particular, la propia asignación se adaptó dependiendo de un resultado de la inspección de la descripción de presentación multimedia. Según las realizaciones posteriores de las figuras 6 a 8, se ha influido en la parte del tráfico de datos entre el cliente y el servidor, que se refiere a las peticiones multimedia enviadas desde el cliente hasta el servidor, con el fin de lograr un aprovechamiento más eficiente de las estaciones base, los recursos de comunicación o para obtener una distribución más justa de los recursos de comunicación de estaciones base para las entidades de usuario. Según ambas realizaciones, el gestor de recursos de radio 30 también puede tener en cuenta la retroalimentación en bucle cerrado de LTE en la capa física según el ejemplo de implementación explicado a continuación. Es decir, se pretende que la siguiente posibilidad de implementación designe una explicación más detallada de los ejemplos de implementación de las figuras 5 y 8. Es decir, según la presente posibilidad de implementación, el planificador de gestión de recursos de radio (RRM) 30 tiene en cuenta la retroalimentación en bucle cerrado de LTE a partir de la capa física de LTE para la decisión en el EMB de LTE 32 para decidir qué representación de vídeo o versión del contenido multimedia 44 es la más adecuada para el cliente de DASH. De nuevo, según la realización de la figura 3 y la implementación de la figura 5, el gestor de recursos 30 busca obtener la descarga de la representación o versión más adecuada indirectamente asignando en consecuencia los recursos de comunicación a los clientes 40 respectivos para los que está dedicada la representación respectiva. Mientras tanto, según la realización de la figura 6 y la implementación de la figura 8, el gestor de recursos de radio 30 busca obtener la descarga de la representación más adecuada por el cliente influyendo de manera apropiada en las peticiones multimedia de los clientes tal como se describió anteriormente.

La unidad de RRM 30 tiene en cuenta, por ejemplo, la retroalimentación en bucle cerrado de LTE cuando selecciona entre diferentes representaciones de segmentos de AVC de contenido multimedia 44, capas (H.264/)SVC o cuando se decide entre el suministro de vídeo en 2D o 3D en el caso de (H.264/)MVC. El eNB de RRM de LTE 30 puede inspeccionar la MPD 46 para ajustar parámetros de RRM a los parámetros especificados para los segmentos de vídeo particulares en el caso de las figuras 3 y 5 y para influir en las peticiones de conjuntos de HTTP en el caso de las figuras 6 y 8.

El UE 40 puede señalizar métricas de calidad del canal de radio, denominadas retroalimentación de calidad de canal (CQI), así como niveles de memoria intermedia de la memoria intermedia de vídeo, véase la tabla 3, a la entidad de RRM de eNB 30. La información de retroalimentación puede reducirse enviando un indicador de relación picopromedio (PAR), por ejemplo de relación de tasa de transmisión pico-promedio (PARR), con una base temporal periódica o aperiódica. Con esta información, la entidad de RRM de eNB 30 puede realizar planificación de múltiples usuarios con conocimiento de memoria intermedia para servicios de transmisión en continuo de HTTP.

ES 2 905 831 T3

La métrica de calidad de canal de los datos de capa física (PHY) que van a usarse para el cálculo de la PAR y/o PARR puede implicar uno o cualquier combinación de los siguientes parámetros tal como se definen dentro de la norma de LTE:

ñ CQI: indicación de calidad de canal

ñ RI: indicador de rango

ñ Tasa de transmisión de datos de capa PHY

ñ Fluctuación y retardo de capa PHY

ñ RSRP: potencia recibida de señal de referencia

ñ RSSI: indicador de intensidad de señal recibida

ñ RSRQ: calidad de recepción de señal de referencia

En este caso, RSRQ se define mediante:

RSRQ=N x ^RP/rssj,

donde N es el número de bloques de recurso a través de los cuales se midió el valor de RSSI.

Tal como queda claro a partir del detalle de implementación expuesto anteriormente, los gestores de recursos de radio 30 de las figuras 3 y 6 pueden emplear retroalimentación en bucle cerrado en la capa física tal como se envía por las entidades de usuario del cliente a la estación base, respectivamente. Esto significa que el sistema, en el lado de dispositivo de envío, puede basarse en información a través de capas con el fin de mejorar el transporte de vídeo, mientras que el lado de receptor no necesita ninguna interfaz a través de capas. Además, el RRM puede estimar, basándose en el canal, cuánto ancho de banda más puede asignarse a uno o más clientes con el fin de mejorar su calidad de vídeo.

Por ejemplo, el RRM 30 de la figura 3 y 6 puede estar configurado para determinar un ancho de banda promedio asignado a las entidades de usuario y predecir, a partir del ancho de banda promedio determinado, en cuanto a qué versión de un contenido multimedia 44 de la descripción de presentación multimedia 46 se descarga realmente por los clientes respectivos tales como 44. Esto forma una manera sencilla de encontrar el estado del cliente. Para cada cliente, el RRM 30 simplemente tiene que identificar el ancho de banda promedio que está recibiendo el cliente 40 respectivo y predecir a partir de eso qué tasa de transmisión multimedia puede haber seleccionado.

Además, tal como se expuso anteriormente, puede ser posible que el gestor de recursos de radio 30 intente derivar información de estado de almacenamiento en memoria intermedia multimedia, es decir, información que indica una clase de estado de almacenamiento en memoria intermedia del cliente que funciona en la entidad de usuario respectiva. Dicho de otro modo, el gestor de recursos de radio 30 puede aprovechar la información referente a la condición de recepción de las entidades de usuario 34 con el fin de determinar si la entidad de usuario respectiva puede realmente recibir de manera correcta y eficaz el ancho de banda asignado. Usando esta información, el gestor de recursos de radio 30 puede emular el estado de almacenamiento en memoria intermedia de los clientes que funcionan en las entidades de usuario teniendo en cuenta la información de ancho de banda mínimo a la que puede acceder el gestor de recursos de radio 30 a partir de la descripción de presentación multimedia 46 tal como se describió anteriormente. Mediante esta medida, el gestor de recursos de radio 30 puede emular o simular los estados de almacenamiento en memoria intermedia de los clientes 40 que se ejecutan en las entidades de usuario 34 y deducir el comportamiento del cliente y las prioridades del cliente a partir de los mismos. Por ejemplo, a los clientes 40 para los que la simulación revela que la memoria intermedia se queda sin datos multimedia se les puede asignar una prioridad superior que a los clientes 40 para los que la simulación revela que la memoria intermedia está llena.

Naturalmente, la posibilidad anteriormente descrita de simular el estado de almacenamiento en memoria intermedia o derivar la información de estado de almacenamiento en memoria intermedia multimedia a partir de tráfico de datos entre el cliente 40 y el servidor respectivo es bastante compleja desde el punto de vista computacional y la precisión obtenida puede ser baja.

Por tanto, la realización de la figura 3 puede extenderse de una manera según la cual el gestor de recursos de radio 30 también puede estar configurado para asignar los recursos de comunicación de la estación base 32 a las entidades

ES 2 905 831 T3

de usuario no solo dependiendo de la descripción de presentación multimedia 46 (además de la información de situación de recursos actual), sino también dependiendo de información de estado de almacenamiento en memoria intermedia multimedia derivada a partir de retroalimentación de calidad de canal a partir de las entidades de usuario respectivas en las que funciona el cliente o los clientes 40 respectivos. En particular, la información de estado de almacenamiento en memoria intermedia multimedia derivada puede haberse derivado mediante la simulación anteriormente descrita que simula una memoria intermedia del cliente 40 de entidades de usuario respectivo que se llena usando la tasa de transmisión de bits efectiva estimada de la entidad de usuario 34 respectiva y se introduce al ancho de banda de presentación indicado en la descripción de presentación multimedia 46.

Evidentemente, puede decirse lo mismo puede con respecto al gestor de recursos de radio 30 de la figura 6. Es decir, el resultado de simulación puede usarse por el gestor de recursos de radio 30 con el fin de decidir sobre la influencia de las peticiones multimedia de los clientes 40 de las entidades de usuario.

Además, la realización de la figura 7 también puede extenderse en este sentido. Es decir, el gestor de recursos 74 de la figura 7 puede usar la información de situación de recursos actual con el fin de simular el estado de memoria intermedia multimedia del cliente y actuar en consecuencia con el fin de proteger, como parte de la comunidad de comunicación inalámbrica, los recursos de comunicación de estaciones base contra dos clientes 40 codiciosos.

Sin embargo, tal como acaba de describirse, la “simulación” del estado de almacenamiento en memoria intermedia del cliente puede estar sujeta a un alto grado de incertidumbre y, por consiguiente, las realizaciones de las figuras 3 y 6 pueden modificarse de una manera de modo que el gestor de recursos de radio 30 no tenga que derivar o simular el estado de almacenamiento en memoria intermedia del cliente de las entidades de usuario sino que, en vez de eso, el gestor de recursos de radio 30 aprovecha información de estado de almacenamiento en memoria intermedia multimedia explícita dentro de un tráfico de datos a partir del cliente 40. Basándose en la descripción de presentación multimedia 46 y la información de estado de almacenamiento en memoria intermedia multimedia dentro del tráfico de datos desde el cliente 40 hasta el servidor 42, el gestor de recursos de radio 30 puede realizar la asignación de recursos de comunicación de manera más precisa debido a una estimación de estado de almacenamiento en memoria intermedia más precisa. En la información de estado de almacenamiento en memoria intermedia multimedia dentro del tráfico de datos a partir del cliente 40, este último indicará explícitamente el estado de almacenamiento en memoria intermedia multimedia actual, es decir el nivel de llenado de la memoria intermedia multimedia actual. A continuación se describe en más detalle una posibilidad de implementación específica.

Sin embargo, según una realización alternativa, el gestor de recursos de radio 30 de la figura 3 puede realizar alternativamente la asignación de los recursos de comunicación de la estación base 32 a las entidades de usuario dependiendo de la información de estado de almacenamiento en memoria intermedia multimedia dentro del tráfico de datos a partir del cliente 40, pero sin dependencia de la descripción de presentación multimedia 46. Simplemente vigilar los estados de almacenamiento en memoria intermedia multimedia de varios clientes 40 de las entidades de usuario permitirá que el gestor de recursos de radio 30 obtenga una distribución más justa de los recursos de comunicación de estaciones base disponibles para las entidades de usuario.

Por tanto, la figura 3 también se refiere a un gestor de recursos de radio 30 configurado para asignar recursos de comunicación de una estación base 32 a entidades de usuario 34 dependiendo de información de estado de almacenamiento en memoria intermedia multimedia de un cliente que funciona en una de las entidades de usuario. La asignación de los recursos de comunicación a las entidades de usuario puede realizarse adicionalmente basándose en una o más de las posibilidades mencionadas anteriormente tales como el número de entidades de usuario 34 a las que tienen que asignarse los recursos de comunicación de la estación base (32) a una razón apropiada, la clase de datos de comunicación que van a intercambiarse entre las entidades de usuario y la estación base, y así sucesivamente. Además, al asignar los recursos de comunicación a las entidades de usuario, los ajustes anteriormente mencionados pueden ajustarse dependiendo de la información de estado de almacenamiento en memoria intermedia multimedia, concretamente una o más de subportadoras, ranuras de tiempo y una cobertura espacial de las estaciones base célula. Tal como acaba de describirse, la información de estado de almacenamiento en memoria intermedia multimedia puede extraerse a partir de una señalización explícita dentro de un tráfico de datos desde el cliente 40 hasta el servidor 42, o la información de estado de almacenamiento en memoria intermedia multimedia puede derivarse simulando el estado de almacenamiento en memoria intermedia de una entidad de usuario basándose en retroalimentación de calidad de canal desde la entidad de usuario 34 hasta la estación base 32.

Esta última posibilidad también se refiere a las realizaciones de las figuras 6 y 7. En vez de usar la información de situación de recursos actual y la descripción de presentación multimedia 46, el gestor de recursos de radio 30 y el gestor de recursos 74 de las figuras 6 y 8, respectivamente, pueden estar configurados para realizar la decisión con respecto a la manera de gestionar la petición multimedia 60 dependiendo de la información de estado de almacenamiento en memoria intermedia multimedia dentro del tráfico de datos a partir del cliente 40.

Por tanto, las realizaciones anteriores también revelan un gestor de recursos configurado para inspeccionar una descripción de presentación multimedia 46 que describe versiones de un contenido multimedia 44 de diferentes anchos

ES 2 905 831 T3

de banda, dentro de un tráfico de datos desde un servidor 42 hasta un cliente 40 que funciona en una entidad de usuario 34; inspeccionar una petición multimedia 60 desde el cliente 40 hasta el servidor 42, que pide una versión deseada del contenido multimedia 44; recibir información de estado de almacenamiento en memoria intermedia multimedia a partir del cliente 40; y decidir, dependiendo de la información de estado de almacenamiento en memoria intermedia multimedia y la descripción de presentación multimedia 46, (1) reenviar la petición multimedia 60 al servidor o, alternativamente, (2) modificar la petición multimedia 60 hasta el grado de que la petición multimedia modificada pide una versión del contenido multimedia 44 de menos ancho de banda, o interceptar la petición multimedia 60 y emular o indicar al servidor 42 que envíe de vuelta una respuesta de no disponibilidad desde el servidor 42 hasta el cliente 40.

A continuación se describe una posible implementación para la realización que acaba de describirse como descripción alternativa de las figuras 3, 6 y 7. Esta implementación más detallada puede titularse “DASH sobre LTE con retroalimentación en bucle cerrado en libre transmisión (OTT)”. Según esta posibilidad de implementación, se realiza un seguimiento más preciso del nivel de memoria intermedia del cliente en el planificador de DPI 30 del sistema de LTE usando retroalimentación de cliente directa en libre transmisión, por ejemplo una métrica de calidad tal como el nivel de memoria intermedia como se define en la tabla 3.

Tabla 3: métricas de calidad para niveles de memoria intermedia

En la figura 9 se muestra una posible implementación resultante. Comparando la implementación de la figura 9 con la posibilidad de implementación de la figura 5, queda claro que la implementación de la figura 5 se ha extendido mediante la retroalimentación de LTE 90 desde la entidad de usuario 34 hasta el RRM 30 en la que este último, es decir, el RRM 30, usa la retroalimentación de LTE, es decir, la retroalimentación de calidad de canal a partir de la entidad de usuario 34, con el fin de realizar una mejor asignación de tasa de recursos de comunicación R.

A continuación, con respecto a las realizaciones anteriores, se describen algunos detalles de posible implementación con respecto al cliente 40 de la realización. Tal como se indicó anteriormente, el comportamiento del cliente es libre de establecerse por el proveedor de cliente respectivo y, por consiguiente, las realizaciones anteriores no se centraron mucho en la descripción del comportamiento del cliente. Por otro lado, con el fin de aumentar una comprensión exhaustiva de las realizaciones expuestas anteriormente, a continuación en el presente documento se describe un posible comportamiento de cliente suponiendo que el cliente es un cliente de DASH.

DASH, tal como se define en la norma [ISO/IEC 23009-1], es una tecnología de adaptación impulsada por cliente, pero no especifica el comportamiento de cliente y deja una completa libertad para diferentes implementaciones. Sin embargo, la MPD y QM notificadas por los clientes contienen algo de información importante a partir de la cual puede predecirse el comportamiento de cliente. Esta información importante se refiere a la señalizada en:

ñ @minBufferTime

ñ @bandwidth

ñ tasa de transmisión de cliente de LTE asignada de manera implícita, que puede medirse por el cliente como rendimiento de TCP, si están disponibles datos suficientes

ñ el cliente se adapta al rendimiento de TCP dependiendo del retardo de reproducción pretendido / posibles interrupciones

ñ QM, notificada por el cliente

ñ indicador de conmutación de flujo de bits

ES 2 905 831 T3

El objetivo del cliente de DASH es reproducir de manera continua el contenido transmitido en continuo a la calidad más alta que puede soportar basándose en sus características de equipo. Con el fin de reproducir de manera continua, la memoria intermedia en los clientes no deberá vaciarse en ningún momento. El @minBufferTime en la MPD promete a los clientes que, si se almacena tal cantidad de datos en sus memorias intermedias al comienzo de la sesión, pueden reproducir una versión de vídeo que se señaliza que tiene @bandwidth si descargan a una tasa de transmisión al menos tan alta como el valor indicado en @bandwidth. Por tanto, se espera que los clientes almacenen previamente en memoria intermedia al menos esa cantidad de datos antes de empezar la reproducción del vídeo y conmutar a una versión diferente del vídeo con un @bandwidth diferente cuando se producen variaciones en el llenado de su memoria intermedia basándose en su magnitud con respecto a @minBufferTime. Dado que el llenado de la memoria intermedia de los clientes se desconoce por la estación base y estimarlo puede ser difícil o impreciso, por ejemplo, cuando se usan modos de control de movimiento, informes de QM a partir de los usuarios (especialmente, la QM mencionada anteriormente) pueden ser una herramienta útil para predecir el comportamiento de usuario.

Además, un cliente de DASH está dividido de manera lógica en dos componentes tal como se muestra en la figura 10: el cliente de acceso de DASH 40a y el motor multimedia de MPEG 40b, tal como se muestra en la figura 7.

ñ Cliente de acceso de DASH 40a: esta entidad es responsable de analizar sintácticamente la MPD 46, realizar el algoritmo de planificación y pasar los medios 64 al motor multimedia de MPEG 40b en el formato 92

ñ Motor multimedia de MPEG 40b: esta entidad es responsable de procesar los datos multimedia 92, es decir, decodificar, reconstruir, etc.

Haciendo referencia a la descripción anterior de la figura 7, hay dos opciones posibles para implementar un cliente de DASH potenciado que aprovecha cualquiera de las funcionalidades favorables anteriormente descritas de la entidad de usuario y/o el cliente. Estas posibilidades son:

ñ Tener un cliente de acceso de DASH a través de capas: el cliente de acceso a través de capas toma medidas de la capa física y posiblemente recibe señalización adicional a partir de la red de LTE. Usando esta inteligencia adicional puede realizarse una mejor estimación del canal y una planificación de adaptación potenciada.

ñ Sin embargo, normalmente se prevén clientes de DASH ya implementados, en los que la adaptación se produce en capas superiores mediante monitorización, por ejemplo, de niveles de memoria intermedia de cliente o tiempo necesario para descargar una cantidad de datos dada, tal como, por ejemplo, para implementación de clientes de DASH en navegador, etc. En este caso, una posibilidad es tener un componente de “gestor multimedia” externo (véanse las figuras 8 y 9) que se ocupa de la adaptación. De manera similar al descrito anteriormente, pero el cliente de DASH no será consciente de esto. Con el fin de evitar este cliente de acceso de DASH “duplicado” (el del cliente de acceso de DASH también realiza la adaptación) se necesita señalización adicional a nivel de MPD: puede añadirse un nuevo atributo, por ejemplo @automaticSwitching, que indicará al cliente de acceso de DASH que la adaptación se realiza fuera del cliente de DASH, es decir, en el dispositivo receptor, por el “gestor de recursos” 74. El @automaticSwitching contenido en una MPD indica al cliente que el servidor o cualquier dispositivo entre medias puede ajustar la tasa de transmisión de vídeo de acuerdo con el perfil del vídeo y el nivel según la representación seleccionada y pedida, por tanto el cliente no realizará ninguna adaptación de tasa de transmisión multimedia.

El segundo caso, es decir con el “gestor de recursos”, se representa en la figura 11. Tal como puede observarse a partir de la figura 11, el gestor de recursos 74 usa los datos 100 en una capa de OSI inferior en comparación con el tráfico de datos de cliente/servidor con el fin de actuar como gestor de recursos tal como se describió anteriormente.

En particular, el gestor de recursos 74 puede realizar o bien la adaptación y peticiones de medios, o bien también puede realizar DPI o modificar las peticiones de los usuarios, etc. Además, el “gestor multimedia” puede intercambiar algunos mensajes de señalización adicionales con el RRM sobre información de capa física y asignación de recursos con el fin de realizar una adaptación más inteligente que la que puede realizarse en un cliente de DASH normal, en el que solo se usa información de capas superiores.

Con respecto a la realización de las figuras 6 y 7 y las implementaciones correspondientes tales como la figura 8, debe observarse que las realizaciones representadas en estas figuras pueden implementarse de cualquier manera alternativa para dar como resultado una realización alternativa según la cual se sustituye la influencia de petición multimedia por una influencia de presentación de descripción multimedia con el fin de producir una mejor gestión de recursos. Sin embargo, puede usarse incluso una combinación de la funcionalidad anteriormente descrita con respecto a estas figuras y la funcionalidad expuesta a continuación.

En particular, según la realización alternativa de la figura 6 tal como se describe, el gestor de recursos de radio 30 está configurado para inspeccionar una petición de descripción de presentación multimedia desde el cliente que funciona en la entidad de usuario 34 hasta el servidor 42, pidiendo la petición de descripción de presentación

ES 2 905 831 T3

multimedia la descripción de presentación multimedia 46 a partir del servidor 42. Después, el gestor de recursos 30 inspecciona la descripción de presentación multimedia 46 dentro del tráfico de datos desde el servidor 42 hasta el cliente 40 y decide, basándose en la información de situación de recursos actual y la descripción de presentación multimedia 46, qué opción de esta última debe usarse: 1) reenviar la descripción de presentación multimedia 46 al cliente 40 como respuesta a la petición de descripción de presentación multimedia, es decir, dejando la descripción de presentación multimedia 46 sin modificar, o 2) interceptar la descripción de presentación multimedia 46, reducir la descripción de presentación multimedia 46 para describir simplemente un subconjunto apropiado de las versiones del contenido multimedia 44 de diferentes anchos de banda y enviar la descripción de presentación multimedia 46 reducida al cliente 40 como respuesta a la petición de descripción de presentación multimedia. De nuevo, aunque el gestor de recursos de radio 30 no indica directamente al cliente 40 que cambie la versión pedida del contenido multimedia a una versión de ancho de banda inferior de la misma, es muy probable que el cliente 40 cambie peticiones multimedia adicionales del contenido multimedia 44 para hacer referencia a una versión de ancho de banda inferior de este tipo debido a la reducción de la descripción de presentación multimedia 46.

De nuevo, la funcionalidad anteriormente descrita es válida no solo para el gestor de recursos de radio 30 resultante más allá de la estación base desde el punto de vista de entidades de usuario sino también para el gestor de recursos 74 de la figura 7 resultante dentro de la propia entidad de usuario. Todos los detalles de implementación posibles anteriores mencionados anteriormente con respecto a la figura 7 también pueden aplicarse a la realización alternativa expuesta anteriormente de las figuras 6 y 7, respectivamente.

Por tanto, las figuras 6 y 7 también revelan un gestor de recursos configurado para inspeccionar una petición de descripción de presentación multimedia desde un cliente 40 que funciona en una entidad de usuario 34 hasta un servidor 42, pidiendo la petición de descripción de presentación multimedia una descripción de presentación multimedia 46 a partir del servidor 42, describiendo la descripción de presentación multimedia 46 versiones de un contenido multimedia 44 de diferentes anchos de banda; inspeccionar la descripción de presentación multimedia 46 dentro de un tráfico de datos desde el servidor 42 hasta el cliente 40; decidir, basándose en una información de situación de recursos actual y la descripción de presentación multimedia 46, (1) reenviar la descripción de presentación multimedia 46 al cliente 40 como respuesta a la petición de descripción de presentación multimedia, o (2) interceptar la descripción de presentación multimedia 46 y modificar la misma.

Por ejemplo, la intercepción y modificación pueden implicar que el gestor de recursos reduzca la descripción de presentación multimedia 46 para describir simplemente un subconjunto apropiado de las versiones del contenido multimedia 44 de diferentes anchos de banda, y envíe la descripción de presentación multimedia reducida al cliente 40 como respuesta a la petición de descripción de presentación multimedia. También puede ser posible añadir información a la MPD 46 que va a usarse como retroalimentación para el cliente 40: con el fin de indicar al cliente 40, por ejemplo, que envíe las métricas de calidad tales como información de estado de memoria intermedia explícita mencionada anteriormente, al RRM 30 en vez de al servidor 32, o indicar un cambio de protocolo, concretamente de unidifusión a multidifusión tal como también se describe en más detalle a continuación; o hacer que el cliente 40 sepa que un dispositivo, concretamente el propio gestor de recursos, entre medias puede realizar ajustes de los medios 44 pedidos por el cliente 40 de modo que el cliente 40 no debe ajustar la tasa de transmisión. Naturalmente, la indicación de cambio de protocolo puede llevarse a cabo por el RRM 30 realizando, o haciendo que otra parte tal como el servidor 32 realice, una traducción de protocolo correspondiente al cambio de protocolo indicado.

Como en el caso de influir en las peticiones multimedia, el gestor de recursos puede estar configurado para inspeccionar la descripción de presentación multimedia 46 para identificar dentro de la descripción de presentación multimedia 46 una versión de un contenido multimedia 44, que tiene un ancho de banda mínimo inferior asociado con la misma como la versión deseada del contenido multimedia 44, en el que el gestor de recursos de radio está configurado para, si está presente una versión de este tipo que tiene un ancho de banda mínimo inferior asociado con la misma, realizar la decisión dependiendo de la información de situación de recursos actual. El gestor de recursos puede ser un gestor de recursos de radio y está configurado además para realizar una asignación de recursos de comunicación de una estación base para entidades de usuario a las que pertenece la entidad de usuario en la que funciona el cliente. Sin embargo, el gestor de recursos puede estar dispuesto alternativamente dentro de la entidad de usuario entre una fase de transceptor 70 de la misma y el cliente 40, en el que el gestor de recursos está configurado para obtener la información de situación de recursos actual a partir de la fase de transceptor 70. Además, el gestor de recursos puede estar configurado para simular un estado de almacenamiento en memoria intermedia de la entidad de usuario basándose en retroalimentación de calidad de canal desde la entidad de usuario hasta la estación base, que está comprendida por la información de situación de recursos actual, y para realizar la decisión dependiendo del estado de almacenamiento en memoria intermedia de la entidad de usuario.

A continuación, se describen detalles de implementación posibles referentes a las realizaciones anteriormente expuestas, refiriéndose esos detalles a la posibilidad de realizar la transmisión en continuo de los datos multimedia en forma de un servicio de inserción de DASH.

Los servicios de DASH a través de LTE pueden potenciarse mediante los denominados servicios de inserción. Véase

ES 2 905 831 T3

la figura 12, por ejemplo. Hay dos enfoques posibles:

1. Inserción de servidor de HTTP

o El cliente de DASH 46 se conecta al servidor de HTTP 42 que, a su vez, realiza TCP/establecimiento de comunicación de servicio y establecimiento de túnel

o Entonces el servidor 42 inserta datos de vídeo al cliente de DASH 40

2. Inserción de proxy de LTE

o El cliente de DASH 40 se conecta al servidor de proxy de LTE dentro del eNB de LTE que realiza TCP/establecimiento de comunicación de servicio y establecimiento de túnel

o La entidad de RRM de LTE 30 usa la petición de tipo HTTP get para recuperar los datos de representación de vídeo a partir del servidor de HTTP 42

o El RRM de LTE 30 inserta datos de vídeo al cliente de DASH 12

Puede especificarse información de inserción dentro de la MPD, que se refiere a la representación de inserción. En el caso de SVC o MVC, esta información puede incluir las capas que van a insertarse al cliente de DASH. En este caso, la MPD 46 informa al RRM de eNB 30 sobre una posible conmutación de tasa de transmisión, de modo que también puede optimizarse el uso de recursos de radio para otros usuarios. Por ejemplo, en el caso de la inserción de Proxy de LTE, el RRM de LTE 30 puede decidir insertar un servicio con una calidad inferior y requisito de tasa de transmisión inferior para ahorrar recursos para otros usuarios.

Dicho de otro modo, la estación base puede servir como sitio para realizar procesamiento de inserción de proxy en todas las realizaciones anteriores. De manera más precisa, el gestor de recursos de radio puede servir como sitio de este tipo.

Se presenta una descripción alternativa adicional de la realización de la figura 6, en la que la siguiente descripción alternativa deberá entenderse de tal manera que la funcionalidad del gestor de recursos de radio descrita a continuación puede sustituir a la funcionalidad espacial descrita anteriormente del gestor de recursos de radio 30 según la cual la misma influye en el tráfico de datos entre cliente y servidor o puede representar una funcionalidad adicional del gestor de recursos de radio 30.

En cualquier caso, según la realización descrita a continuación, el gestor de recursos de radio 30 de la figura 6, además de asignar los recursos de comunicación de la estación base 32 a las entidades de usuario 34, está configurado adicionalmente para vigilar el tráfico de datos entre los clientes 40 que funcionan en las diversas entidades de usuario 34 y uno o varios servidores 42 con el fin de comprobar si hay descripciones de presentación multimedia 46 dentro del tráfico de datos que se refieren a un contenido multimedia común. Dependiendo de la comprobación, el gestor de recursos de radio decide entonces: (1) ofrecer a los clientes 40 una versión de multidifusión del contenido multimedia común, además de versiones de unidifusión del contenido multimedia 44 o (2) provocar un cambio de un protocolo para los clientes 40 que descargan el contenido multimedia común 44 de un protocolo de unidifusión a un protocolo de multidifusión.

Sin embargo, la funcionalidad anteriormente descrita también puede realizarse dentro de un gestor de recursos de radio que es externo, o independiente, con respecto al gestor de recursos de radio 30 mostrado en la figura 6 que es responsable de realizar la asignación de los recursos de comunicación de estaciones base para las entidades de usuario. La vigilancia del tráfico de datos entre clientes y servidores y la comprobación de si hay descripciones de presentación multimedia solicitadas de manera común por más de uno de los clientes a modo de peticiones de descripción de presentación multimedia respectivas, pueden realizarse independientemente del procesamiento de asignación. La ventaja resultante puede entenderse fácilmente cuando se considera que resultado de que los clientes 40 respectivos conmuten de una versión de unidifusión que va a recibirse a versiones de multidifusión del mismo contenido. La conmutación produce más tasa de transmisión de bits disponible para otros clientes debido al hecho de que la tasa de transmisión de bits necesaria para esos clientes puede contraerse a simplemente una transmisión en continuo.

No hace falta mencionar que la mención alternativa de las opciones (1) y (2) no deberá entenderse como que el gestor de recursos de radio según la presente realización está realmente configurado para, o puede, realizar ambas opciones. En vez de eso, el gestor de recursos de radio decide, basándose en el resultado de la comprobación, sobre si debe desencadenarse o no cualquiera de las opciones 1 o 2. De manera más precisa, el gestor de recursos de radio deja el tráfico de datos entre los clientes 40 y los servidores 42 sin cambiar en un caso en el que no hay ninguna descripción de presentación multimedia dentro del tráfico de datos desde el uno o varios servidores hasta uno diferente de los

ES 2 905 831 T3

clientes que se refiera a un contenido multimedia común 44. En este caso, no se realiza ni la opción 1 ni la opción 2 por el gestor de recursos de radio. De manera incluso más precisa, el gestor de recursos de radio deja el tráfico de datos respectivo sin cambiar en un caso en el que una manipulación de cualquiera del tráfico de datos no promete grandes ahorros de tasa de transmisión de bits. Sin embargo, imagínese el caso en el que varios usuarios deciden conmutar a una transmisión en continuo en directo tal como un partido de fútbol o cualquier otra noticia en directo, respectivamente. En este caso, sería favorable poder conmutar de transmisión en continuo de unidifusión para todos estos clientes a una transmisión en continuo de multidifusión. Según la primera opción, el gestor de recursos de radio, cuando constata la descripción de presentación multimedia solapante dentro del tráfico de datos, está configurado para manipular descripciones de presentación multimedia para los clientes 40 que pidieron una descripción de presentación multimedia referente a la transmisión en continuo en directo multimedia mediante una petición respectiva de descripción de presentación multimedia. La modificación cambia la descripción de presentación multimedia original hasta el grado de que, además o en vez de que esté disponible la versión de unidifusión del contenido multimedia 44, solo está disponible la versión de multidifusión. Por consiguiente, al menos los clientes 40 que se unan recientemente considerarán, o tendrán que considerar, la versión de multidifusión. Según la segunda alternativa, el gestor de recursos de radio 30 estará configurado para cambiar, en caso de constatar descripciones de presentación multimedia solapantes dentro del tráfico de datos, por ejemplo, peticiones multimedia respectivas a partir de los clientes que piden el contenido multimedia común 44 para cambiarse de pedir una versión de unidifusión a una versión de multidifusión. También son viables modificaciones alternativas.

Por tanto, la figura 6 también revela un gestor de recursos de radio configurado para vigilar tráfico de datos entre clientes 40 que funcionan en entidades de usuario 34, y uno o varios servidores 32, y comprobar si hay descripciones de presentación multimedia dentro del tráfico de datos desde el uno o varios servidores 32 hasta unos diferentes de los clientes 40, que se refieran a un contenido multimedia común 44, en el que el gestor de recursos de radio está configurado, dependiendo de la comprobación, para ofrecer a los clientes 40 una versión de multidifusión del contenido multimedia común 44, además de versiones de unidifusión del contenido multimedia 44; o el gestor de recursos de radio está configurado, dependiendo de la comprobación, para provocar un cambio de un protocolo para los clientes 40 que descargan el contenido multimedia común desde un protocolo de unidifusión hasta un protocolo de multidifusión. Este gestor de recursos de radio también puede ser responsable de la asignación de recursos de comunicación de la estación base 32 a las entidades de usuario 34. La realización que acaba de exponerse puede combinarse con cualquiera de las otras realizaciones.

A continuación se describe una implementación más concreta de la realización anteriormente expuesta. Según esta implementación concreta, se realiza una conmutación de unidifusión de DASH y radiodifusión/multidifusión. Tal como se describió anteriormente, una conmutación de este tipo es ventajosa para servicios en directo para reducir el uso de célula. Con respecto a esto, se observa que la realización que acaba de mencionarse no solo puede usarse cuando se consideran usuarios asociados con, o bloqueados en, una o varias estaciones base comunes 32. En vez de eso, la red inalámbrica en general, incluyendo todas sus células y la red básica que interconecta la propia estación base, se verá sometida inadvertidamente a un esfuerzo por un número excesivamente alto de clientes que piden una transmisión en continuo de contenido multimedia usando un protocolo de unidifusión, transmisión en continuo que, alternativamente, también podría realizarse mediante un protocolo de multidifusión.

Por consiguiente, una estación base/red de LTE suministra servicios en directo a un usuario de unidifusión. Si aumenta el número de peticiones de usuario del servicio, el servicio debe conmutarse a un servicio de multidifusión/radiodifusión con el fin de reducir demandas de tasa de transmisión de datos en la red básica y el enlace de radio de la infraestructura de red móvil.

• Por ejemplo, de HTTP a FLUTE (protocolo de descarga de archivo de radiodifusión a través de UDP)

El usuario pide servicio de datos para servicio de HTTP. El servidor de Http devuelve petición de tipo HTTP get mediante protocolo FLUTE.

<RedundantURL>http://cdn1.eiemplo.com/</RedundantURL> <RedundantURL>flute://cdn2.ejemplo.com/session-description.sdp</RedundantURL>

Puede aplicarse un cambio de protocolo, basándose en una indicación en la MPD, por ejemplo tal como una “Redundant URL” (URL redundante) que contiene un enlace a una descripción de una sesión de FLUTE (FLUTE, suministro de archivos por transporte unidireccional) [IETF RFC 3926], por ejemplo, en el protocolo de descripción de sesión, SDP [IETF RFC 4566]. Una URL redundante indica una ubicación de medios alternativa con características de transmisión alternativas, tal como un cambio de protocolo de HTTP a FLUTE. Además, el cambio de protocolo también puede incluir un cambio de la ubicación de origen, de una dirección de unidifusión a una de multidifusión.

De nuevo, se indica explícitamente con respecto a la figura 3 y 6 y los ejemplos de implementación correspondientes, que es posible que a una entidad de usuario le de servicio más de una estación base 32, actualmente. Es decir, es posible que la entidad de usuario reciba la MPD a través de otra estación base distinta de aquella para la que el

ES 2 905 831 T3

planificador de RRM realiza RRM. El terminal necesita conectividad de IP básica con el fin de recibir la MPD, que, en este caso, se establece a través de un sistema inalámbrico, por ejemplo LTE, usando la unidad de RRM del LTE. Por tanto, con el fin de recibir la MPD, el UE necesita tener algunos recursos asignados por el RRM. En LTE, ver. 8/9, actual, un terminal se conecta a una única estación base (que funciona en una determinada frecuencia, por ejemplo 2,6 GHz con un ancho de banda de 10 o 20 Mhz) que tiene un único identificador de célula (Cell-ID). En este caso, el UE solo puede obtener la MPD usando la red de LTE subyacente. En una siguiente etapa, pueden usarse técnicas multibanda, ya con la LTE existente. Multibanda significa que, por ejemplo, hay 1 estación base que funciona a 800 MHz y otra que funciona a 2,6 GHz. Un terminal puede conectarse a ambas estaciones base al mismo tiempo, dado que cada una tiene su propio ID de célula. Por tanto, un terminal puede tener más de 1 punto de entrada de IP, en este caso, en el ejemplo, tiene 2, y puede usar una estación base para recuperar la MPD y la otra para recuperar realmente los datos. En este caso, usará independientemente ambas unidades de RRM. Esto también puede extenderse a otras tecnologías, por ejemplo usando LTE para distribuir la MPD, y Wifi para obtener los datos. Un enfoque multibanda de este tipo requerirá alguna clase de inteligencia dentro del cliente, que decide qué tecnología usar basándose en la carga de red actual o la calidad de canal, etc.

Con respecto a la descripción anterior referente a la simulación del estado de memoria intermedia asociado con el cliente 40, se observa que el estado de memoria intermedia simulado también puede ser otra memoria intermedia posicionada en otra parte dentro de la entidad de usuario 34. Por ejemplo, el estado de almacenamiento en memoria intermedia simulado también puede referirse realmente a una memoria intermedia de capa de MAC dentro de la fase de transceptor de la entidad de usuario. Véase, por ejemplo, la figura 13, que muestra un pedante de la memoria intermedia de capa de MAC que acaba de mencionarse dentro de la fase de transceptor 70, concretamente la memoria intermedia 100. La memoria intermedia 100 también puede estar posicionada dentro de la estación base 32. Dicho de otro modo, la figura 13 muestra una posible implementación de una porción del trayecto de datos entre el cliente 40 y el servidor 32, incluyendo una posible implementación del cliente 40. De manera diferente de todas las figuras anteriores, la figura 13 también muestra entidades de capa de MAC tales como la memoria intermedia de capa de MAC 100, es decir una memoria intermedia de red posicionada en el otro lado, es decir más allá, del RRM 30 con respecto al cliente 40. La fase de transceptor de la estación base 102 correspondiente a la fase de transceptor de la entidad de usuario 70 también se muestra por motivos de completitud. La fase de transceptor 70 también alberga entidades de capa de MAC tales como, entre otras, otra memoria intermedia de capa de MAC que, sin embargo, no se muestra en la figura 13. Con respecto a esto, el RRM 30 de la figura 3 también puede monitorizar esta última memoria intermedia con respecto a su cantidad de contenido multimedia para el cliente 40 almacenada en caché, con el fin de simular el estado de memoria intermedia de la entidad de usuario.

Se menciona además que, adicional o alternativamente a las funcionalidades descritas anteriormente, el RM 74 en las figuras 7 o 13 puede ayudar al RRM 30 de la figura 3 con la vigilancia del tráfico de datos entre servidor y cliente para derivar la MPD. Por tanto, el gestor de recursos 74 puede usarse para analizar sintácticamente de manera completa e inspeccionar la descripción de presentación multimedia y traducirla a un subconjunto de descripción de presentación multimedia que solo incluye los posibles puntos de funcionamiento de tasa de transmisión de bits soportados por el cliente para el servicio multimedia pedido, tales como una sesión de transmisión en continuo de HTTP particular. Es decir, la descripción de presentación multimedia traducida puede representar una descripción rudimentaria de las versiones del contenido multimedia 44 disponibles en el servidor respectivo, es decir una clase de descripción de presentación multimedia en el sentido de la descripción anterior con respecto a la figura 3. Tal como se describió anteriormente, puede señalizarse simplemente una clasificación entre la información densidad de las versiones individuales dentro de la descripción de presentación multimedia traducida, es decir una medida muy aproximada de la calidad de la versión respectiva. Alternativamente, tal como acaba de mencionarse, para cada versión, puede señalizarse el ancho de banda mínimo necesario para presentar la versión respectiva al usuario dentro de la descripción de presentación multimedia traducida para cada versión de contenido multimedia relevante, es decir para aquellas versiones de contenido multimedia que pueden presentarse al usuario en la entidad de usuario según las características de la entidad de usuario. Después, puede reenviarse esta MPD traducida al gestor de recursos de radio 30, por ejemplo en la capa PHY/de MAC, con el fin de dejar que use estos puntos de funcionamiento de tasa de transmisión de bits para decisiones de planificación y asignación de recursos de radio adicionales para el cliente particular así como otros clientes bajo su control. El tipo de un servicio de vídeo que permite capacidad de adaptación, es decir el servicio permite el soporte de diferentes tasas de transmisión de bits, respectivamente puntos de funcionamiento, puede indicarse usando señalización de parámetros de calidad de servicio, tal como se define en [19]. Por tanto, pueden añadirse nuevas clases de tráfico, tales como “vídeo no conversacional adaptativo y vídeo adaptativo”, a la tabla 6 para indicar las características del servicio. Estas nuevas clases pueden requerir adicionalmente la indicación de un conjunto de tasas de transmisión a partir de las cuales elegir para la asignación de recursos en el gestor de recursos de radio, es decir la indicación de la MPD traducida. Se necesita extender la señalización de una tasa de transmisión de bits mínima garantizada (GBR) para permitir la señalización de la tasa de transmisión mínima y/u otros puntos de funcionamiento significativos para el servicio. En lo que se refiere a la tasa de transmisión de bits mínima, debe observarse que una descripción de presentación multimedia traducida puede indicar esta tasa de transmisión de bits mínima en cuanto a una tasa de transmisión de bits medida a nivel de tráfico de datos de OSI alto, tal como el nivel de TCP, o en algún nivel de capa de OSI inferior, tal como en cuanto a la tasa de transmisión de bits mínima que va a asignarse por la estación base o el gestor de recursos de radio 30. Se hace

ES 2 905 831 T3

referencia a la discusión anterior de la discrepancia entre la tasa de transmisión de bits realmente asignada y transmitida y la tasa de transmisión de bits realmente efectiva en la transmisión de contenido multimedia, resultando la discrepancia, por ejemplo, de pérdida de paquetes y retransmisión tras NACK o ACK.

Tal como acaba de mencionarse, la transmisión de una descripción de presentación multimedia traducida derivada a partir de la descripción de presentación multimedia real 46 por el gestor de recursos 74 que reside dentro de la entidad de usuario 34, puede integrarse en cualquier red de recursos de radio existente tal como LTE introduciendo un nuevo tipo o clase de datos de comunicación que van a intercambiarse entre la entidad de usuario, respectivamente, y la estación base tal como la “comunicación no conversacional adaptativa” anteriormente mencionada, y transmitiendo la MPD traducida dentro del procedimiento de protocolo de la activación de este nuevo tipo de datos de comunicación, es decir esta portadora dedicada. La figura 15 muestra en más detalle esta posible integración a modo de ejemplo. En este caso se usó LTE a modo de ejemplo como representativa de una red de recursos de radio, pero en principio la descripción de la figura 15 puede transferirse fácilmente a otras redes de recursos de radio. En particular, la figura 15 muestra etapas consecutivas realizadas en la creación de una portadora a modo de ejemplo de este tipo, es decir “comunicación no conversacional adaptativa”, y la transmisión de una descripción de presentación multimedia traducida al gestor de recursos de radio 30. En particular, la figura 15 muestra todas estas etapas en su orden temporal a lo largo del eje de tiempo 110 mediante bloques respectivos y flechas asociadas expuestas en más detalle a continuación, en la que estos bloques y flechas asociadas están dibujados en una dirección horizontal para extenderse sobre las entidades respectivas que participan en la etapa respectiva, concretamente las entidades de la cadena de tráfico de datos: entidad de usuario 40, estación base 32, gestor de recursos de radio 30, entidad de gestión de movilidad 112, pasarela de paquetes 114 y servidor multimedia 42. Tal como ya se indicó anteriormente, la entidad de gestión de movilidad 112 también está conectada a todas las estaciones base de la red de recursos de radio y puede incluso implementarse, al menos parcialmente, en el mismo hardware que el gestor de recursos de radio 30. Tal como ya se mencionó también anteriormente, la entidad de gestión de movilidad 112 es responsable de gestionar los datos de acceso del usuario tales como cargar a la cuenta de pago del usuario, gestionar los perfiles de los usuarios, perfiles que a su vez indican determinados derechos de usuario tales como ancho de banda máximo que puede asignarse al usuario respectivo, restricción con respecto a determinados tipos/clases de datos de comunicación y similares. Además, la entidad de gestión de movilidad 112 puede ser responsable de gestionar los traspasos de entidades de usuario que pasan de la célula de una estación base a la célula de otra estación base. A su vez, la pasarela de paquetes 114 asume la responsabilidad de interconectar la red de recursos de radio, a la que pertenecen las entidades 40, 32, 30 y 112, con el exterior, concretamente con Internet o similar. La posible integración del gestor de recursos de radio 30 y la entidad de gestión de movilidad 112 en una unidad se ilustra a modo de ejemplo por la línea de rayas 116, mientras que la línea de puntos 118 indica la posibilidad de que el gestor de recursos de radio 30 puede estar posicionado dentro de la estación base 32.

Tal como puede deducirse a partir de la figura 15, se supone que la entidad de usuario 40 puede haberse conectado ya a la red de recursos de radio y puede haberse activado ya una portadora por defecto de modo que la entidad de usuario 40 puede realizar tareas mínimas a través de la red de recursos de radio tales como, por ejemplo, realizar acceso de baja complejidad a Internet. La etapa de conexión y activación de portadora por defecto se muestra en 116. De manera más precisa, la etapa 116 se realiza por la fase de transceptor 70 en lo que se refiere al dominio de la entidad de usuario. Después, se supone que el usuario, o el cliente 40 en la entidad de usuario 34, envía la petición de MPD 118 al servidor multimedia 42 usando, en el presente ejemplo, la sesión de portadora por defecto. El servidor multimedia 42 envía de vuelta la MPD en la etapa 120 en la que el gestor de recursos 74 dentro de la entidad de usuario 34 analiza sintácticamente esta MPD en la etapa 122 con el fin de traducir, tal como se describió anteriormente, la MPD de la etapa 120 para dar una MPD traducida. Después, se desencadena una activación de portadora dedicada en 124 tal como, por ejemplo, la activación de “comunicación no conversacional adaptativa”. Por ejemplo, el desencadenador 124 puede haberse provocado al pedir usuario de, o el cliente 40 en, la entidad de usuario 34, contenido multimedia al que se refiere la MPD analizada sintácticamente en la etapa 122. En respuesta al desencadenador 124, el gestor de recursos 74 y la fase de transceptor 70 actúan conjuntamente con el fin de enviar una petición de asignación de recursos de portadora en la etapa 126 a la estación base 32, a la que a su vez se le indica por la misma que reenvíe la petición de asignación respectiva al gestor de recursos de radio 30 y a la entidad de gestión de movilidad 112 en la etapa 128, respectivamente. La petición de asignación comprende la descripción de presentación multimedia traducida anteriormente mencionada usando, por ejemplo, la sintaxis descrita en más detalle a continuación. Después de eso, la entidad de gestión de movilidad 112 informa a la pasarela de paquetes 114 de que tiene que crearse un recurso de portadora respectivo en la etapa 130 usando el comando de recursos de portadora, en el que la propia creación se realiza en la etapa 132. Por consiguiente, desde la etapa 128 en adelante, el gestor de recursos de radio 30 conoce el contenido de la descripción de presentación multimedia traducida, pero aún no se ha confirmado la activación de la portadora dedicada. Por consiguiente, la entidad de gestión de movilidad 112 empieza otra rutina de acuse de recibo enviando una petición de activación de portadora dedicada en la etapa 134 a la estación base 32, que a su vez reenvía la misma en la etapa 136 a la entidad de usuario 34, y, en particular, a la fase de transceptor 70. Después, en la etapa 140, la fase de transceptor 70 señaliza la aceptación de la activación de portadora dedicada a la estación base 32, que a su vez informa en la etapa 142 al gestor de recursos de radio 30 y a la entidad de gestión de movilidad 112 en consecuencia. A partir de ese momento, el gestor de recursos de radio 30 puede realizar la asignación de recursos de radio anteriormente descrita, es decir la planificación, usando la descripción de

ES 2 905 831 T3

presentación multimedia traducida tal como se señaliza desde el gestor de recursos 74 hasta el gestor de recursos 30 mediante las etapas 120 a 128. Por consiguiente, la sesión de transmisión multimedia 144 entre el cliente 40 en la entidad de usuario 34 y el servidor multimedia 42 puede controlarse por el gestor de recursos de radio 30 de una manera eficiente cuando se considera la asignación de los recursos de radio a todas las entidades de usuario a las que da servicio la estación base 32 y la red de recursos de radio, respectivamente.

Con respecto a la figura 15, se observa que, generalmente, hay dos posibilidades para configurar portadoras de radio dedicadas. El primer método está impulsado por el cliente. En este caso, el UE 34 se conecta a través de una portadora por defecto a Internet tal como se muestra en la figura 15. Basándose en una respuesta 120 de una petición de MPD 118 anteriormente emitida por el cliente 40, el RM 74 de la entidad de usuario recibe el archivo de MPD correspondiente para su inspección y desencadena 124 la portadora de radio dedicada en consecuencia. Esto se realiza desencadenando una activación de portadora dedicada emitiendo 126 una petición de asignación de recursos de portadora de ESM a la entidad de gestión de movilidad 112 (MME) (véase la sección 8.3.8 en [20]). Este mensaje 126 contiene un elemento de información (IE) que define la información de calidad de servicio de sistema de paquetes evolucionado (EPS) requerida, es decir, la MPD traducida.

Una posibilidad alternativa está impulsada por la red. En este caso, la P-GW 114 desencadena la configuración de la portadora de radio que es necesaria para mantener la portadora de QoS requerida durante el procedimiento de traspaso. En ambos casos, se envían mensajes de petición de activar portadora dedicada de ESM, (véase la sección 8.3.3 en [20]) que contienen información de calidad de servicio de EPS (véase la sección 9.9.4.3 en [20]) mostrada en la siguiente tabla. Esta tabla (en comparación con [20]) está extendida o modificada para contener señalización para GBR con tasas de transmisión de bits solo mínima y superior alternativa así como para sin GBR con tasas de transmisión de bits alternativas, es decir la MPD traducida. En el caso en el que el UE desencadena la portadora dedicada tal como se ilustra en la figura 15, proporciona los elementos de información tales como las tasas de transmisión de bits alternativas encontradas en la MPD. En el caso en el que la red desencadena la portadora dedicada, se proporcionarán las tasas de transmisión de bits alternativas y la MPD traducida, respectivamente, por la P-GW correspondiente en el caso de traspaso, o a partir del gestor de recursos (74) tras inspeccionar la MPD. Por tanto, la P-GW necesita informar al RRM sobre la ubicación de las MPD o su contenido. En [20] otros mensajes, es decir, petición de modificación de recursos de portadora (sección 8.3.10) y petición de activar portadora de EPS por defecto (sección 8.3.6) también contienen el mensaje de información de calidad de servicio de EPS mostrado en la tabla 3 y pueden usarse para proporcionar las tasas de transmisión de bits alternativas mencionadas anteriormente.

La tabla 3 muestra un elemento de calidad de servicio de EPS tal como se define actualmente.

Una posibilidad es añadir más octetos tal como se muestra en la tabla 4. La tasa de transmisión indicada en las tasas de transmisión de bits garantizadas corresponderá al ancho de banda mínimo que tiene que garantizarse, tal como para la región de calidad más baja/densidad de información más baja, mientras que las tasas de transmisión de bits alternativas para enlace descendente y enlace ascendente describen las tasas de transmisión de bits que están disponibles para descargar encontradas en la MPD original 46. Los campos de tasas de transmisión de bits alternativas están presentes dependiendo del valor del campo de QCI. Si se usan los nuevos valores de QCI definidos en la tabla 5, por ejemplo, deberán estar presentes las tasas de transmisión de bits alternativas para enlace descendente o enlace ascendente. Este mecanismo permite retrocompatibilidad. Si no se entiende el valor de QCI, se selecciona otra QCI de GBR o sin GBR dependiendo de si la tasa de transmisión de bits garantizada está presente o no.

Tabla 4, elemento de información de calidad de servicio de EPS extendida mediante tasas de transmisión de bits alternativas

ES 2 905 831 T3

Otra posibilidad sería añadir un mensaje adicional al mensaje de información de calidad de servicio de EPS, que se añadirá a los mensajes anteriormente mencionados en los que se usa el mensaje de información de calidad de servicio de EPS (petición de asignación de recursos de portadora de ESM, petición de activar portadora dedicada de ESM, petición de modificación de recursos de portadora y petición de activar portadora de EPS por defecto). Esto permitirá dejar el mensaje de calidad de servicio de EPS tal cual. El contenido de la extensión puede ser tal como sigue en la tabla 5. En este caso, los valores de tasa de transmisión de bits garantizada deben tomarse tal como en el mensaje de información de calidad de servicio de EPS, pero el valor de QCI se sobrescribirá por el mensaje de extensión. Las tasas de transmisión de bits alternativas también se describirán en este mensaje de extensión.

Tabla 5, mensaje adicional que porta las alternativas de tasa de transmisión de bits para un elemento de información de calidad de servicio de EPS

Tal como se muestra en la figura 15, la MME 112 tiene que intercambiar mensajes con el resto de la red principal, es decir, con la S-GW y P-GW 114 para configurar una portadora con una QoS dada para un servicio. La S-GW es la pasarela entre la estación base (eNB) y otras entidades de EPC (núcleo de paquetes evolucionado), por ejemplo la P-GW. La P-GW (también especificada algunas veces como PDN-GW = pasarela de red de datos en paquetes) es la interfaz entre EPC e Internet/red básica. Por tanto, todos los datos en las redes de LTE se enrutan desde: UE (terminal) <-> eNB <-> S-GW <-> P-GW <-> Internet / red básica.

El intercambio de mensajes adicionales incluye un comando de recursos de portadora de GTP-C (véase la sección 7.2.5 en [21]) desde la MME hasta la S-GW y desde la S-GW hasta la P-GW, una petición de crear portadora de GTP-C (véase la sección 7.2.3 en [21]) desde la P-GW 114 hasta la S-GW y desde la S-GW hasta la MME 112 y una petición/respuesta de configuración de E-RAB (véase la sección 8.2.1.1 y la sección 8.2.1.2 en [22]), que informa al gestor de recursos de radio 30 sobre las características de QoS que tienen que proporcionarse. Estos mensajes mencionados anteriormente tienen que extenderse en consecuencia a las extensiones presentadas en la tabla 4 y la tabla 5. Por ejemplo, para el comando de recursos de portadora de GTP-C debe extenderse el IE de QoS de flujo en la sección 8.16 en [21] con las tasas de transmisión de bits alternativas definidas en este caso, tal como se muestra, por ejemplo, en la tabla 6. Para la petición de crear portadora de GTP-C debe extenderse el IE de QoS de portadora en la sección 8.15 en [21 ] con las tasas de transmisión de bits alternativas definidas en este caso, tal como se muestra, por ejemplo, en la tabla 7. Para la petición de configuración de E-RAB, la MME 112 debe insertar las tasas de transmisión de bits alternativas negociadas en los parámetros de QoS de nivel de E-RAB en la sección 9.2.1.15 en [22]. Para ello, la QoS de nivel de E-RAB debe extenderse añadiendo las tasas de transmisión de bits alternativas

ES 2 905 831 T3

adicionales definidas anteriormente, tal como se muestra, por ejemplo, en la tabla 8 y la tabla 9.

Tabla 6: calidad de servicio de flujo (QoS de flujo)

Tabla 7: calidad de servicio de nivel de portadora (QoS de portadora) Tabla 8: petición de configuración de E-RAB o parámetros de QoS de nivel de E-RAB

ES 2 905 831 T3

Tabla 8: ABR - QoS: tasas de transmisión de bits alternativas para QoS de tasa de transmisión de bits adaptativa

(ABR)

De manera similar al procedimiento descrito anteriormente, puede iniciarse un traspaso por un eNodoB tal como se describe en [23]. En tal caso, la configuración de portadora o el mantenimiento de portadora (con las mismas características de QoS) no se inicia ni por la MME ni por la P-GW, emitiendo una petición de asignación de recursos de portadora de ESM, sino que se realiza dentro de la interfaz X2 definida en 3GPP [24]. En tal caso, la sintaxis extendida, propuesta anteriormente, con tasas de transmisión de bits alternativas tiene que incluirse en los mensajes apropiados. En concreto, para la interfaz X2, se define el mensaje de petición de traspaso (véase la sección 9.1.1.1 [23]), que contiene un IE/nombre de grupo de parámetro de QoS de nivel de E-RAB. Este IE se define en la sección 9.2.9 en [23] y debe extenderse tal como se muestra en la tabla 8. La sintaxis de este mensaje será la misma que la petición de configuración de E-RAB descrita anteriormente.

Además, adicional o alternativamente a las funcionalidades descritas anteriormente, el gestor de recursos 74 puede reenviar el rendimiento recibido real, tal como se observa mediante una sesión de TCP de nivel superior, como información al gestor de recursos de radio 30, con el fin de dejar que identifique el rendimiento de aplicación resultante real para decisiones de planificación y asignación de recursos de radio adicionales para el cliente particular así como otros clientes bajo su control. Más generalmente, la entidad de usuario 34 puede ser para comunicarse con la estación base de recursos de radio 32, en la que está operativo el cliente 40, en la que la entidad de usuario 34 puede estar configurada para determinar el rendimiento de contenido multimedia realmente recibido o el estado de memoria intermedia de un contenido multimedia recuperado por el cliente 40 a partir del servidor 42 e informar al gestor de recursos de radio 30 sobre el rendimiento de contenido multimedia determinado o estado de memoria intermedia. La determinación puede implicar enviar el cliente 40 la información respectiva al gestor de recursos 74 que asume la responsabilidad de la tarea respectiva dentro de la entidad de usuario. Con respecto a la realización de las figuras 3 a 5, debe mencionarse que la descripción anterior se refería principalmente al caso de enlace descendente, es decir al caso en el que el gestor de recursos de radio asignaba los recursos de comunicación de enlace descendente a las

ES 2 905 831 T3

entidades de usuario 34, aunque las realizaciones anteriores también pueden transferirse al caso de enlace ascendente. Desde un punto de vista más general, por ejemplo, las figuras 3 a 5 y todas las otras realizaciones referentes a la funcionalidad del gestor de recursos de radio 30 según la cual se realiza la asignación de recursos de comunicación, el gestor de recursos de radio puede estar configurado más generalmente para asignar recursos de comunicación, es decir recursos de comunicación de enlace descendente y/o de enlace ascendente de la al menos una estación base 32 a las entidades de usuario 34 dependiendo de una descripción de presentación multimedia dentro de un tráfico de datos desde un servidor hasta un cliente, en el que uno del servidor y el cliente funciona en una de las entidades de usuario 34 no siendo este, sin embargo, necesariamente el cliente. Esto se expondrá explícitamente en más detalle a continuación. Véase, por ejemplo, la figura 16. Como nota secundaria, se menciona que el servidor y el cliente pueden incluso estar ambos funcionado en una entidad de usuario común y, por consiguiente, “uno del servidor y el cliente” debe entenderse como “al menos uno de”.

La figura 16 corresponde a la figura 3 excepto porque se conmutan el cliente 40 y el servidor 42: el servidor 42 funciona en la entidad de usuario 34, mientras que el cliente 40 está posicionado en el otro lado de la estación base 32 con respecto a la entidad de usuario 34. Cuando se considera la explicación más detallada de una posible estructura interna de la entidad de usuario tal como se muestra en la figura 7, puede considerarse que el servidor 32 sustituye al cliente 40 en la figura 7. Esto significa lo siguiente. El gestor de recursos de radio 30 puede vigilar el tráfico de datos entre el servidor 42 y 40. En particular, el gestor de recursos de radio 30 puede inspeccionar la descripción de presentación multimedia 46 a partir de lo mismo. Basándose en lo mismo, el gestor de recursos de radio 30 puede asignar los recursos de comunicación de enlace ascendente de la estación base 32 a las entidades de usuario entre las cuales está la entidad de usuario 34 en la que funciona el servidor 42. En principio, toda la discusión anterior con respecto a posibles comportamientos del gestor de recursos 30 permanece igual. Es decir, el gestor de recursos 30 también puede inspeccionar y mantener un registro de las peticiones multimedia desde el cliente 40 hasta el servidor 42 y realizar la asignación de los recursos de comunicación de enlace ascendente dependiendo de una evaluación de los mismos y así sucesivamente.

La concordancia entre la realización de las figuras 3 a 5 por un lado y la figura 16 por el otro lado sigue siendo válida incluso cuando se considera la extensión anteriormente expuesta de la realización de las figuras 3 a 5 según la cual parte de la funcionalidad del gestor de recursos de radio 30 se transfiere desde el RRM 30 hasta el gestor de recursos 74 posicionado entre el servidor 42 por un lado y la fase de transceptor 70 por el otro lado (véase la figura 7, por ejemplo). Es decir, también es cierto para el caso de la figura 16: el gestor de recursos 74 puede estar configurado para ayudar al RRM 30 con la vigilancia del tráfico de datos entre el servidor 42 en la entidad de usuario 34 y el cliente 40. Es decir, incluso en ese caso, es decir en el que el servidor 42 está ejecutándose en la entidad de usuario 34, los recursos del ancho de banda de enlace ascendente también pueden gestionarse de manera análoga, concretamente indicando el gestor de recursos 74 al gestor de recursos de radio 30 las alternativas de tasa de transmisión de bits, es decir la MPD traducida, y usando el RRM 30 la MPD traducida para realizar la asignación de recursos de enlace ascendente dependiendo de la misma. El gestor de recursos 74 puede indicar las tasas de transmisión de bits alternativas para el enlace ascendente en los mensajes de ESM anteriormente mencionados, que contienen el mensaje de calidad de servicio de EPS extendido, tal como se muestra en la tabla 4.

Véase, por ejemplo, la figura 14. En el lado izquierdo, la figura 14 muestra un diagrama de flujo similar a la figura 15, es decir que usa un eje de tiempo 110 y que distingue las entidades implicadas en las etapas respectivas mostradas en los bloques dispersando las entidades a lo largo de la dirección horizontal y mostrando, mediante las flechas asociadas con los bloques respectivos, entre qué entidades tiene lugar la etapa respectiva. En el lado derecho de la figura 14, se ilustra de nuevo el caso de la figura 15, es decir el caso en el que el cliente reside en la entidad de usuario. En el lado izquierdo, se muestra el caso en el que un servidor 42 funciona en una entidad de usuario 34. De hecho, el cliente que funciona en una entidad de usuario y el servidor que funciona en la otra entidad de usuario pueden formar un par entre el cual se transfiere contenido multimedia. Una situación de este tipo puede tener lugar, por ejemplo, dentro de una videoconferencia en la que el servidor que funciona en la entidad de usuario 34’ transmite al cliente que funciona en la entidad de usuario 34” un vídeo referente al participante de la videoconferencia en la entidad de usuario 34’ captado, por ejemplo, por medio de una cámara respectiva de la entidad de usuario. Sin embargo, también son posibles otros casos de uso. Por ejemplo, el cliente puede descargar un archivo a partir del servidor multimedia en la entidad de usuario 34’ de otra persona. En ese caso, las entidades participantes en el tráfico de datos entre el servidor en la entidad de usuario 34’ por un lado y el cliente en la entidad de usuario 34” por el otro lado, son, mostrados en el orden en el que se mencionan de izquierda a derecha en la figura 14: la entidad de usuario 34’, la estación base 32’ a la que está actualmente conectada la entidad de usuario 34’, la gestión de recursos de radio 30’ responsable de asignar los recursos de comunicación de la estación base 32’, la entidad de gestión de movilidad 112’ responsable de controlar la red de recursos de radio a la que pertenecen la estación base 32’ y el gestor de recursos de radio 30’, la pasarela de paquetes 114’ que pertenece a la misma red de recursos de radio, la pasarela de paquetes 114” y la entidad de gestión de movilidad 112” que pertenecen ambas a la red de recursos de radio a la que pertenece la estación base 32”, a la que está conectado cliente 34”, el gestor de recursos de radio 30” responsable de asignar los recursos de comunicación de la estación base 32”, la propia estación base 32”, y la entidad de usuario 34”. Tal como se muestra en la figura 14, la entidad de usuario 34” realizará la conexión y la activación de portadora por defecto en la etapa 116’ de la misma manera que lo hace la entidad de usuario 34” en la etapa 116. Tal como se describió

ES 2 905 831 T3

anteriormente con respecto a la figura 15, el cliente que reside en la entidad de usuario 34” puede enviar en la etapa 118 una petición de MPD al servidor que reside en la entidad de usuario 34’, tras lo cual este último envía de vuelta la MPD en la etapa 120 a la entidad de usuario 34”. Después de eso, en la etapa 122, el gestor de recursos 74 que reside en la entidad de usuario 34” analiza sintácticamente la MPD y después provoca la activación de la portadora dedicada a lo largo de la línea de la descripción anterior de las etapas 126 a 142, tras lo cual el gestor de recursos 30 asigna los recursos de comunicación de enlace descendente de la estación base 32” según una MPD traducida reenviada por el gestor de recursos 74 de la entidad de usuario 34” dentro de la sesión de transmisión multimedia 144 que entonces tiene lugar entre el cliente y el servidor. En el lado de dominio de enlace ascendente se emprenden etapas similares. El servidor 42 que reside en la entidad de usuario 34’ provoca la activación de la portadora dedicada, es decir, en este caso, una sesión de tipo de comunicación conversacional o no conversacional adaptiva, de manera análoga a las etapas 126 a 142 descritas anteriormente con respecto a la figura 15, tras lo cual, dentro de la sesión de transmisión multimedia 144, el gestor de recursos de radio 30’ asigna los recursos de enlace ascendente de la estación base 32’ según la descripción de presentación multimedia traducida tal como se reenvía por el servidor en la entidad de usuario 34’ dentro de la petición de asignación de recursos de portadora 126.

Debe mencionarse que la figura 14 mostró simplemente a modo de ejemplo el caso en el que el servidor y el cliente residen ambos en entidades de usuario conectados a redes de recursos de radio respectivas. El ejemplo de la figura 14 puede transferirse fácilmente a un caso en el que el cliente no está funcionando en una entidad de usuario, sino, por ejemplo, en un ordenador estacionario, por ejemplo. Además, debe mencionarse que la situación mostrada también puede tener lugar dentro de una red de recursos de radio común y que el RRM’ y el RRM” y/o la MME’ y la MME” y/o son los mismos.

Con respecto a esto, se observa que para todas las realizaciones anteriores, puede suceder que el servidor, en el que reside el contenido multimedia 44, puede estar separado de la entidad que actúa como servidor para proporcionar la descripción de presentación multimedia. Más generalmente, la MPD 46 puede surgir de otra entidad o servidor distinto del servidor que proporciona el propio contenido multimedia 44. Esta posibilidad se ilustra, por ejemplo, en la figura 14 con líneas de puntos referentes al origen y al objetivo de las flechas correspondientes a las etapas 120 y 118, respectivamente. En particular, este posible origen de MPD se muestra en 150 con líneas de puntos. No obstante, en el caso de este origen de MPD adicional 150, al gestor de recursos de radio 30’ le puede informar el gestor de recursos 74 sobre la descripción de presentación multimedia traducida. Sin embargo, en este caso, el gestor de recursos 74, en vez de inspeccionar el tráfico de datos entre el cliente en la entidad de usuario 34” y el servidor en la entidad de usuario 34’, le indica al servidor en la entidad de usuario 34’ que proporcione al gestor de recursos 74 en la entidad de usuario 34” la descripción de presentación multimedia traducida.

Por tanto, dicho de otro modo, la entidad de usuario 34 en la izquierda en la figura 14 se establece como servidor multimedia y la entidad de usuario 34 en la derecha se establece como cliente 40. El cliente pide la MPD a partir del origen de MPD 150, que puede ser cualquier servidor en la red (un caso especial es cuando el servidor con la MPD es el servidor multimedia en la entidad de usuario 34’). Dado que el servidor multimedia conoce las características de los medios, que se anuncian en la MPD, usa esta información para indicar las tasas de transmisión de bits alternativas en los mensajes de ESM mencionados y configura la portadora, para lo que la tasa de transmisión de bits de enlace ascendente es especialmente importante (el servidor necesita subir los datos). Sin embargo, el cliente necesita analizar sintácticamente la MPD recibida y usa la información descrita para la asignación de portadora, en la que la tasa de transmisión de bits de enlace descendente tiene especial importancia (el cliente 40 necesita descargar los datos). Sin embargo, dado que puede usarse TCP, la tasa de transmisión de bits de enlace descendente también es importante para el servidor, así como la tasa de transmisión de bits de enlace ascendente para el cliente.

Hay un caso especial, por ejemplo en situaciones conversacionales, en el que cada una de las entidades de usuario 34 tiene un servidor multimedia y un cliente funcionando simultáneamente en las mismas. En este caso, ambas entidades de usuario 34 pedirán la descripción de presentación multimedia (por ejemplo, MPD o SDP) y usarán esta información para describir las tasas de transmisión de bits alternativas tanto para enlace ascendente como para enlace descendente, basándose en las características multimedia ofrecidas en sus servidores respectivos y en las características multimedia que se supone que reciben como clientes 40.

En tal situación, en la que las entidades de usuario 34 tienen un servidor multimedia y un cliente simultáneamente, puede suceder que dos eNodoB diferentes se ocupan de las diferentes entidades de usuario 34 que participan en la conversación. El gestor de recursos de radio 30 que funciona para cada uno de los eNodoB y que se ocupa de las entidades de usuario 34 funciona optimizando independientemente cada una de las interfaces aéreas para los diferentes usuarios. El problema de tal situación es que no se tiene en cuenta la interfaz aérea de una entidad de usuario 34 para la optimización de los recursos de radio de la otra entidad de usuario 34. Por tanto, puede tomarse una decisión inferior a la óptima. Por ejemplo, si se suben más datos a partir de una entidad de usuario 34 que la cantidad de datos que pueden descargarse en la otra entidad de usuario 34, con la que está comunicándose la primera entidad de usuario 34, algunos datos se abandonarán en el gestor de recursos de radio 30 que funciona con la entidad de usuario 34 con “problemas de descarga”. Una solución será extender los mensajes definidos en la interfaz X2 [23] y añadir un mensaje que proporciona información concreta sobre los recursos que se garantizarán para cada uno de

ES 2 905 831 T3

los usuarios, basándose en la información definida en la MPD o SDP. De tal manera, ambos eNB realizan una asignación de recursos colaborativa teniendo en cuenta la información en la SDP o la MPD, tal como se define a lo largo de este documento. El nuevo mensaje puede ser, por ejemplo, informe de estado de recursos de UE y contener un IE de asignación de recursos, tal como se muestra en la tabla 9, la tabla 10 y la tabla 11.

Esta última realización revela una asignación de recursos colaborativa sin conocimiento multimedia en el sentido descrito ahora. Es decir, véase, por ejemplo, la figura 3. La figura 3 muestra simplemente un gestor de recursos de radio 30 pero, tal como ya se indicó anteriormente, un sistema de varios gestores de recursos de radio puede formar un sistema de radio con todos los gestores de recursos de radio 30 funcionando de manera independiente unos de otros en el sentido de que cada gestor de recursos de radio 30 asigna, mediante optimización, sus recursos de comunicación de su al menos una estación base 32 a las entidades de usuario 34 que están dentro del alcance de sus estaciones base 32 basándose simplemente en información que se desplaza por su(s) propia(s) estación/estaciones base 32, tal como retroalimentación de calidad a partir de las entidades de usuario 34 tal como se expuso anteriormente, el número de entidades de usuario 34 a las que va a darse servicio y así sucesivamente. Se hace referencia a la discusión anterior. Es decir, cada RRM realiza su propia planificación independientemente unos de otros. Sin embargo, la independencia de la planificación se rompe, según la presente realización, en el sentido de que los RRM también distribuyen información sobre su distribución de recursos de radio actual a sus UE, al exterior para su uso en los otros RRM. En el ejemplo que acaba de describirse, no es necesario que los gestores de recursos de radio aprovechen información que reside dentro de descripciones de presentación multimedia si hay alguna. Pero, no obstante, según la realización descrita ahora, puede evitarse que los gestores de recursos de radio 30 que funcionan de manera independiente asignen de manera desventajosa recursos de comunicación no coincidentes a entidades de usuario que, por accidente, tienen un par de comunicación de cliente y servidor que funciona en las mismas. Esto se logra de la siguiente manera.

En particular, el gestor de recursos de radio vigila el tráfico de datos hacia un servidor o un cliente que funciona en una de las entidades de usuario 34 o algunos mensajes de control intercambiados entre gestores de recursos de radio para obtener información sobre i) recursos de comunicación garantizados actualmente asignados al otro del servidor y el cliente, o un estado de memoria intermedia del otro del servidor y el cliente. En el caso del servidor que funciona en la entidad de usuario 34 a la que da servicio el gestor de recursos de radio 30 actual, el estado de memoria intermedia de este servidor puede formar, por ejemplo, un estado de memoria intermedia de salida, es decir el nivel de llenado de una memoria intermedia de salida. Esto puede ser interesante, por ejemplo, en el caso de transmisión en continuo en directo o videoconferencias. En el caso del cliente 40 que funciona en la entidad de usuario 34, el estado de memoria intermedia será el nivel de llenado de una memoria intermedia de entrada del cliente. Debe enfatizarse que, según la presente realización, el gestor de recursos de radio 30 (véase la figura 3) obtiene esta información referente a un servidor o cliente al que da servicio otro gestor de recursos de radio 30. Simplemente, el homólogo del par de cliente/servidor está funcionando en la entidad de usuario 34 a la que da servicio el propio gestor de recursos de radio 30. Según la presente realización, el gestor de recursos de radio 30 usa esta información referente a un homólogo de cliente/servidor que funciona en una entidad de usuario a la que se da servicio en otra parte, con el fin de realizar la asignación de recursos de comunicación de la al menos una estación base 32 por la que se da servicio a la entidad de usuario 34. Mediante esta medida, es posible evitar que el gestor de recursos de radio 30 asigne a alguna entidad de usuario 34 recursos de comunicación aumentados de manera innecesaria aunque, por ejemplo, el estado de memoria intermedia del homólogo de cliente/servidor sea alto, o los recursos de comunicación garantizados actualmente asignados a una entidad de usuario externa en la que funciona el homólogo de servidor/cliente sean bajos. Con el fin de aclarar esto, se hace referencia a la figura 17, que muestra un sistema de este tipo que comprende varios gestores de recursos de radio. En el entramado de LTE, los RRM formarán los eNodoB anteriormente mencionados. Uno de los gestores de recursos de radio se designa a modo de ejemplo con 30, el otro con 30’. El hecho de que simplemente se muestran dos gestores es a modo de ejemplo. Ambos gestores 30 y 30’ asignan sus recursos de comunicación de su al menos una estación base 32 y 32’ respectiva, respectivamente. La asignación o planificación se realiza independientemente uno de otro excepto por las interacciones que implican las señales de control o inserciones de tráfico de datos descritas a ahora.

En la figura 17, se muestra a modo de ejemplo que a una entidad de usuario 34 le da servicio una estación base 32 que pertenece al gestor de recursos de radio 30 y se muestra que a otra entidad de usuario 34’ le da servicio la estación base 32’ que pertenece al gestor de recursos de radio 30’. En la entidad de usuario 34, funciona un cliente 40, y se muestra a modo de ejemplo que un servidor 42 funciona en la entidad de usuario 34’. Ambos se comunican entre sí mediante un tráfico de datos que se ilustra mediante una línea de rayas en la figura 17. El tráfico de datos puede ser del tipo de telecomunicaciones, tipo de descarga o similar. Tal como ya se indicó con respecto a la figura 3, no es necesario que los gestores de recursos de radio 30 y 30’ se atraviesen por el tráfico de datos. Será suficiente si ambos gestores de recursos de radio 30 y 30’ simplemente tienen acceso al tráfico de datos con el fin de vigilar e inspeccionar el mismo.

Con el fin de evitar una optimización errónea entre los RRM 30 y 30’, ambos informan sobre estados de memoria intermedia de UE actuales y tasas de transmisión de bits actualmente garantizadas al otro RRM respectivo.

ES 2 905 831 T3

Según una primera alternativa, ambos RRM pueden mantenerse agnósticos uno con respecto al otro. La información respectiva se inserta en el flujo de datos de cliente/servidor de modo que puede evitarse una optimización errónea incluso en el caso de que al servidor o al cliente se le dé servicio fuera del sistema de radio en Internet, por ejemplo.

El gestor de recursos de radio 30’ puede, por ejemplo, vigilar el tráfico de datos desde el servidor 32 hacia el cliente 40 con el fin de obtener información sobre recursos de comunicación garantizados actualmente asignados a la entidad de usuario 34 en la que funciona el cliente 40, o el estado de memoria intermedia de este cliente 40. Mediante esta medida, el gestor de recursos de radio 30’ puede evitar gastar demasiados recursos de comunicación para el servidor 42 aunque, por ejemplo, el estado de memoria intermedia de cliente 40 ya sea alto, o los recursos de comunicación garantizados actualmente asignados a la entidad de usuario 34 sean bajos. Por otro lado, el gestor de recursos de radio 30 puede vigilar el tráfico de datos desde el cliente 40 hacia el servidor 42 con el fin de obtener información de los recursos de información garantizados actualmente asignados a la entidad de usuario 34’ o el estado de memoria intermedia de servidor 42. De la misma manera, el gestor de recursos de radio 30, usando esta información, puede evitar asignar demasiados recursos de comunicación a la entidad de usuario 34 aunque, por ejemplo, el estado de memoria intermedia de servidor 42 se aproxime a un estado vacío de nivel de llenado, o aunque los recursos de comunicación garantizados actualmente asignados a la entidad de usuario 34’ sean bajos.

Tal como ya se indicó anteriormente, el recurso de comunicación garantizado puede ser algo que los gestores de recursos de radio 30 y 30’ determinan dentro de la asignación de recursos de comunicación de su(s) estación/estaciones base 32 a sus entidades de usuario 34 a las que dan servicio. Es decir, los gestores de recursos de radio 30 y 30’, respectivamente, asignan recursos de comunicación garantizados a las entidades de usuario 34 y 34’ en unidades de algunos intervalos de tiempo, tales como, por ejemplo, intervalos de tiempo de 3 a 10 segundos. También obedecen los recursos de comunicación garantizados en la asignación de los recursos de comunicación dentro de esos intervalos de tiempo. O bien los gestores de recursos de radio 30 y 30’ usan los recursos de comunicación garantizados de manera fija a través de los intervalos de tiempo, o bien hacen variar los recursos de comunicación asignados a las entidades de usuario, pero simplemente dentro de los límites impuestos por los recursos de comunicación garantizados.

Hay diferentes posibilidades sobre cómo la información del estado de memoria intermedia o los recursos de comunicación garantizados a partir de un dominio externo del gestor de recursos de radio entran en el dominio del gestor de recursos de radio de un gestor de recursos de radio que da servicio a un homólogo de cliente/servidor a través del tráfico de datos. Por ejemplo, los gestores de recursos de radio 30 y 30’ pueden estar configurados para insertar información sobre los recursos de comunicación garantizados asignados a su entidad de usuario a la que dan servicio en el tráfico de datos a partir del cliente 40 o el servidor 42 que funciona en su entidad de usuario a la que da servicio. El gestor de recursos de radio 30’, por ejemplo, puede insertar en el flujo de datos desde el servidor 42 hasta el cliente 40 la información referente a los recursos de comunicación garantizados asignados a la entidad de usuario 34’, y el gestor de recursos de radio 30, a su vez, puede insertar en el tráfico de datos desde el cliente 40 hasta el servidor 42 la información referente a los recursos de comunicación garantizados asignados a la entidad de usuario 34. Además, la inserción no tiene que realizarse necesariamente por los propios gestores de recursos de radio 30 y 30’. Tal como ya se expuso anteriormente con respecto a la realización anterior, una inserción de este tipo también puede realizarse por los gestores de recursos 74 que se ejecutan en las entidades de usuario 34 y 34’, respectivamente. En este caso, los gestores de recursos de radio 30 y 30’ informarán a las entidades de usuario 34 y 34’, respectivamente, sobre sus recursos de comunicación garantizados, es decir los recursos de comunicación garantizados asignados a las entidades de usuario 34 y 34’ en las que están funcionando, y esta información se vigilará e inspeccionará por los gestores de recursos 74 que, a su vez, realizan la inserción que acaba de mencionarse en vez del gestor de recursos de radio.

Según una segunda alternativa, ambos RRM 30 y 30’ informan sobre los estados de memoria intermedia de UE actuales y tasas de transmisión de bits actualmente garantizadas referentes a los UE a los que dan servicio al otro RRM respectivo mediante señales de control 199. En la arquitectura de LTE, por ejemplo, tales señales de control pueden intercambiarse entre los RRM, por ejemplo, a través de la interfaz X2, S-GW o similar, usando, por ejemplo, el HSS como operador que guía el trayecto de intercambio de señales de control en consecuencia. Según este ejemplo, los gestores de recursos de radio 30 y 30’ realizarán, por ejemplo, las siguientes etapas: 1) constatar que el cliente o servidor que funciona en la entidad de usuario a la que dan servicio busca establecer una sesión de transmisión inmediata, es decir, comienza una sesión de transmisión multimedia que implica a este cliente o servidor; 2) comprobar si al homólogo, es decir al servidor o cliente, con el que se establece una sesión de transmisión multimedia, le da servicio cualquiera de los otros RRM del sistema de radio; 3) si es así, acompañar la sesión de transmisión multimedia con señales de control 199. El trayecto para las señales de control se guía mediante e1HSS, por ejemplo. Por ejemplo, el gestor de recursos de radio 30 informa al gestor de recursos de radio 30’ mediante las señales de control 199 del estado de memoria intermedia del cliente en el que el gestor de recursos de radio 30 puede haber obtenido esta información tal como se explicó anteriormente, es decir mediante simulación o retroalimentación a partir de una gestión de recursos 74 dentro de la entidad de usuario 34. O el gestor de recursos de radio 30 puede informar al gestor de recursos de radio 30’ mediante las señales de control 199 sobre los recursos de radio garantizados asignados a la entidad de usuario 34. El gestor de recursos de radio 30’ hace lo mismo en el sentido

ES 2 905 831 T3

inverso durante la sesión de transmisión multimedia. Es decir, el gestor de recursos de radio 30’ informa al gestor de recursos de radio 30 mediante las señales de control 199 del estado de memoria intermedia del servidor y/o los recursos de radio garantizados para la entidad de usuario 34’.

Naturalmente, la realización que acaba de describirse también podrá combinarse con cualquiera de las realizaciones anteriormente mencionadas. Esto es cierto, por ejemplo, en lo que se refiere a las realizaciones según las cuales el estado de memoria intermedia del cliente o servidor, que funciona en la entidad de usuario a la que da servicio el propio gestor de recursos de radio, se usa por el gestor de recursos de radio con el fin de realizar la asignación de recursos de comunicación.

La tabla 9 extiende la tabla de tipos de mensaje en la sección 9.2.13 en [23] de la siguiente manera:

Tabla 9: nuevo tipo de mensaje, informe de estado de recursos de UE

La tabla 10 muestra la sintaxis del informe de estado de recursos de UE.

Tabla 10: sintaxis de informe de estado de recursos de UE

La tabla 11 muestra la sintaxis del IE de información de recursos asignados de UE.

Tabla 11: información de recursos asignados de UE (versión 1)

ES 2 905 831 T3

Alternativamente, puede proporcionarse una variedad de tasas de transmisión de bits basándose en SDP o MPD (basándose en características multimedia) con una tasa de transmisión de bits soportada máxima tal como se muestra en la siguiente tabla:

Tabla 11: información de recursos asignados de UE (versión 2)

ES 2 905 831 T3

Tabla 6: características de QCI normalizadas [véase 19]

ES 2 905 831 T3

Tal como también se describió anteriormente, las realizaciones anteriores, entre otras cosas, también revelaron un cliente (tal como software, hardware o hardware programable) para este operativo en una entidad de usuario 34 para la comunicación con una estación base de recursos de radio 32, estando el cliente 40 configurado para recuperar, a partir de un servidor 42, una descripción de presentación multimedia y un contenido multimedia 44, describiendo la descripción de presentación multimedia 46 versiones de diferentes anchos de banda del contenido multimedia 44, estando el cliente configurado para poder conmutarse de un modo normal a un modo esclavo por medio de una señalización a partir de un gestor de recursos de radio 30 responsable de asignar los recursos de comunicación de la estación base 32 a la entidad de usuario, en el que el cliente está configurado para, en el modo normal, pedir el contenido multimedia 44 a partir del servidor 42 en una versión determinada por el cliente basándose en los recursos de comunicación asignados a la entidad de usuario, y, en el modo esclavo, pedir el contenido multimedia 44 a partir del servidor 42 en una versión determinada por el cliente independientemente de los recursos de comunicación asignados a la entidad de usuario. El cliente puede estar configurado además para, en el modo normal, pedir el contenido multimedia 44 a partir del servidor 42 en una versión determinada por el cliente basándose en los recursos de comunicación asignados a la entidad de usuario y un estado de memoria intermedia del contenido multimedia. El cliente también puede estar configurado además para, en el modo esclavo, pedir el contenido multimedia 44 a partir del servidor 42 de manera continua en una versión que corresponde a la versión de ancho de banda más alto entre las versiones de diferente ancho de banda en la descripción de presentación multimedia 46. Es decir, un comportamiento de cliente puede controlarse, por ejemplo, mediante el indicador @automaticSwitching en la MPD: puede informarse al cliente de que un dispositivo entre medias puede ajustar la tasa de transmisión de bits de los segmentos seleccionados entre medias para optimizar los recursos de célula, de modo que el cliente no reaccionará por sí mismo sobre cambios de tasa de transmisión de bits.

ES 2 905 831 T3

Aunque se han descrito algunos aspectos en el contexto de un aparato, queda claro que estos aspectos también representan una descripción del método correspondiente, en el que un bloque o dispositivo corresponde a una etapa de método o una característica de una etapa de método. De manera análoga, aspectos descritos en el contexto de una etapa de método también representan una descripción de un bloque o elemento o característica correspondiente de un aparato correspondiente. Algunas o todas de las etapas de método pueden ejecutarse por (o usando) un aparato de hardware, tal como, por ejemplo, un microprocesador, un ordenador programable o un circuito electrónico. En algunas realizaciones, alguna o más de las etapas de método más importantes pueden ejecutarse por un aparato de este tipo.

Dependiendo de determinados requisitos de implementación, realizaciones de la invención pueden implementarse en hardware o en software. La implementación puede realizarse usando un medio de almacenamiento digital, por ejemplo un disco flexible, un DVD, un Blu-Ray, un CD, una ROM, una PROM, una EPROM, una EEPROM o una memoria FLASH, que tiene señales de control electrónicamente legibles almacenadas en el mismo, que actúan conjuntamente (o pueden actuar conjuntamente) con un sistema informático programable de tal manera que se realiza el método respectivo. Por tanto, el medio de almacenamiento digital puede ser legible por ordenador.

Algunas realizaciones según la invención, no reivindicadas, comprenden un soporte de datos que tiene señales de control electrónicamente legibles, que pueden actuar conjuntamente con un sistema informático programable, de tal manera que se realiza uno de los métodos descritos en el presente documento.

Generalmente, realizaciones de la presente invención pueden implementarse como un producto de programa informático con un código de programa, siendo el código de programa operativo para realizar uno de los métodos cuando se ejecuta el producto de programa informático en un ordenador. El código de programa puede estar almacenado, por ejemplo, en un soporte legible por máquina.

Otras realizaciones comprenden el programa informático para realizar uno de los métodos descritos en el presente documento, almacenado en un soporte legible por máquina.

Dicho de otro modo, una realización del método de la invención es, por tanto, un programa informático que tiene un código de programa para realizar uno de los métodos descritos en el presente documento, cuando se ejecuta el programa informático en un ordenador. Las siguientes realizaciones no forman parte de las reivindicaciones.

Una realización adicional de los métodos de la invención es, por tanto, un soporte de datos (o un medio de almacenamiento digital o un medio legible por ordenador) que comprende, grabado en el mismo, el programa informático para realizar uno de los métodos descritos en el presente documento. El soporte de datos, el medio de almacenamiento digital o el medio grabado son normalmente tangibles y/o no transitorios.

Una realización adicional del método de la invención es, por tanto, un flujo de datos o una secuencia de señales que representa el programa informático para realizar uno de los métodos descritos en el presente documento. El flujo de datos o la secuencia de señales puede estar configurado, por ejemplo, para transferirse a través de una conexión de comunicación de datos, por ejemplo a través de Internet.

Una realización adicional comprende unos medios de procesamiento, por ejemplo un ordenador, o un dispositivo lógico programable, configurado o adaptado para realizar uno de los métodos descritos en el presente documento.

Una realización adicional comprende un ordenador que tiene instalado en el mismo el programa informático para realizar uno de los métodos descritos en el presente documento.

Una realización adicional según la invención comprende un aparato o un sistema configurado para transferir (por ejemplo, de manera electrónica u óptica) un programa informático para realizar uno de los métodos descritos en el presente documento a un receptor. El receptor puede ser, por ejemplo, un ordenador, un dispositivo móvil, un dispositivo de memoria o similar. El aparato o sistema puede comprender, por ejemplo, un servidor de archivos para transferir el programa informático al receptor.

En algunas realizaciones, puede usarse un dispositivo lógico programable (por ejemplo, una matriz de puertas programable en el campo) para realizar algunas o todas de las funcionalidades de los métodos descritos en el presente documento. En algunas realizaciones, una matriz de puertas programable en el campo puede actuar conjuntamente con un microprocesador con el fin de realizar uno de los métodos descritos en el presente documento. Generalmente, los métodos se realizan preferiblemente mediante cualquier aparato de hardware.

Las realizaciones anteriormente descritas son simplemente ilustrativas de los principios de la presente invención. Se entiende que modificaciones y variaciones de las disposiciones y los detalles descritos en el presente documento resultarán evidentes para otros expertos en la técnica. Por tanto, la intención es limitarse únicamente por el alcance

ES 2 905 831 T3

de las siguientes reivindicaciones de patente y no por los detalles específicos presentados a modo de descripción y explicación de las realizaciones en el presente documento.

Lista de acrónimos y símbolos

Lista de referencias

[1] Libro blanco de Cisco, “Cisco Visual Networking Index: Forecast and Methodology, 2009-2014”, junio de 2010.

[2] Libro blanco de Cisco, “Cisco Visual Networking Index: Global Mobile Data-Traffic Forecast Update”, 2010 2015.

[3] Information technology Dynamic adaptive streaming over HTTP (DASH) Part 1, “Media presentation description and segment formats, ISO/IEC DiS 23009-1”, agosto de 2011.

[4] 3GPP, “Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (Release 9); 3GPP TS 26.234 V9.3.0 (2010-06): Adaptive HTTP Streaming”.

[5] A. Zambelli, ““IIS smooth streaming technical overview”. Microsoft Corporation, 2009.

[6] HTTP Live Streaming Architecture, “Technical report, Apple Inc.”, 2010.

[7] T. Wiegand, G. J. Sullivan, G. Bjontegaard y A. Luthra, “Overview of the H.264/AVC Video Coding Standard”, en IEEE Transactions on Circuits and Systems for Video Technology, 2003.

[8] A. Tacz, A. Temesvary y N. Reider, “Handover Performance in 3GPP Long Term Evolution (LTE) Systems”, en Mobile and wireless Communications Summit, 2007.

[9] T. Stockhammer, M. Walter y G. Liebl, “Optimized H.264-Based Bitstream Switching for Wireless”, en ICME, 2005.

[10] S. Sharma, D. Gillies y W. Feng, “On the Goodput of TCP NewReno in Mobile Networks”, en ICCCN, 2010.

[11] H. Schwarz, D. Marpe y T. Wiegand, “Overview of the scalable video coding extension of the H.264/AVC standard”, en IEEE Transactions on Circuits and Systems for Video Technology, 2007.

[12] T. Schierl, Y. Sanchez, R. Globisch, C. Hellge y T. Wiegand, “Priority-based Media Delivery using SVC with RTP and HTTP streaming”, en Springer Multimedia Tools and Application, septiembre de 2010.

[13] W. Mulder y T. Wirth, “Are we ready for the femtolution?”, en IEEE COMSOC MMTC E-letter, septiembre de 2010.

[14] ITU-R, informe M.2134, “Requirements related to technical performance for IMT-Advanced radio interface(s),

ES 2 905 831 T3

Approved in Nov 2008”.

[15] 3GPP, “Physical layer; General description (Release 8); 3GPP TS 25.201 V8.1.0 (2008-05): Adaptive HTTP Streaming”.

[16] 3GPP, “Evolved Universal Terrestrial Radio Access (E-UTRA) and evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description (Release 8); 3GPP TS 36.300 V8.12.0 (2010-03): Adaptive HTTP Streaming”.

[17] Leekwijck, Y. Sánchez, T. Schierl, C. Hellge, T. Wiegand, D. Hong, D. De Vleeschauwer y W. Van, “iDASH: improved Dynamic Adaptive Streaming over HTTP using Scalable Video Coding”, en ACM Mmsys, 2011.

[18] J. Mahdavi y S. Floyd. TCP-friendly unicast rate-based flow control. Enero de 1997

[19] 3GPP TS 23202, Policy and charging control architecture, versión 113GPP TS

[20] 24301, Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)

[21] 3GPP TS 29274, Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3

[22] 3GPP TS 36413, Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) [23] 3GPP TS 36423, proyecto de asociación de 33 generación; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 application protocol (X2AP) (versión 11)

[24] 3GPP TS 36420, proyecto de asociación de 33 generación; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 general aspects and principles (versión 11)

Claims (4)

ES 2 905 831 T3REIVINDICACIONES

1. Entidad de usuario para comunicarse con una estación base de recursos de radio (32), en la que está operativo un cliente (40) o un servidor (32), en la que la entidad de usuario está configurada para vigilar un tráfico de datos hacia/desde el cliente (40) o el servidor (32) para derivar una descripción de presentación multimedia (46) que describe versiones de diferentes anchos de banda de un contenido multimedia (44), y reenviar, al menos parcialmente, la descripción de presentación multimedia a un gestor de recursos de radio (30) responsable de asignar los recursos de comunicación de la estación base de recursos de radio (32) a entidades de usuario a las que pertenece la entidad de usuario.

2. Entidad de usuario según la reivindicación 1, en la que la entidad de usuario está configurada para realizar el reenvío en una capa de OSI inferior a una capa de OSI a través de la cual se transmite el tráfico de datos.

3. Método para realizarse en una entidad de usuario en la que está operativo un cliente (40) o un servidor (32), comunicándose la entidad de usuario con una estación base de recursos de radio (32), comprendiendo el método

vigilar un tráfico de datos hacia/desde el cliente (40) o el servidor (32) para derivar una descripción de presentación multimedia (46) que describe versiones de diferentes anchos de banda de un contenido multimedia (44), y

reenviar, al menos parcialmente, la descripción de presentación multimedia a un gestor de recursos de radio (30) responsable de asignar los recursos de comunicación de la estación base de recursos de radio (32) a entidades de usuario a las que pertenece la entidad de usuario.

4. Programa informático que tiene un código de programa para realizar, cuando se ejecuta en un ordenador, un método según la reivindicación 3.