ES2347943T3 - Método y aparato para informar sobre la calidad de medios de transmisión en tiempo real. - Google Patents

Método y aparato para informar sobre la calidad de medios de transmisión en tiempo real. Download PDF

Info

Publication number
ES2347943T3
ES2347943T3 ES07857690T ES07857690T ES2347943T3 ES 2347943 T3 ES2347943 T3 ES 2347943T3 ES 07857690 T ES07857690 T ES 07857690T ES 07857690 T ES07857690 T ES 07857690T ES 2347943 T3 ES2347943 T3 ES 2347943T3
Authority
ES
Spain
Prior art keywords
client
quality metrics
session
information parameter
real
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES07857690T
Other languages
English (en)
Inventor
Mattias Petterson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2347943T3 publication Critical patent/ES2347943T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)

Abstract

Un método de indicar la calidad de una sesión de medios de transmisión en tiempo real establecida entre un cliente y un servidor, teniendo la sesión de medios de transmisión en tiempo real un nivel de sesión y al menos un nivel de medios, estando el método caracterizado porque comprende: negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real; y proporcionar las métricas de calidad aceptadas por el cliente y el servidor durante la negociación de acuerdo con el valor de parámetro de información negociado.

Description

ANTECEDENTES
La presente invención se refiere generalmente a contenido de medios de transmisión en tiempo real, y particularmente se refiere a informar acerca de la calidad del contenido de medios de transmisión en tiempo real.
Medios de transmisión en tiempo real es el contenido de multimedios que es recibido de manera continua por, y normalmente mostrado a, un cliente mientras está siendo entregado por un servidor de contenido. “Transmisión en tiempo real” se refiere a la capacidad de una aplicación para reproducir flujos de medios sincronizados como flujos de audio y video de una manera continua mientras los flujos están siendo transmitidos al cliente sobre una red. Medios de transmisión en tiempo real están disponibles sobre redes de IP fija tales como la Internet y más en último lugar sobre redes de acceso por radio por medio de protocolo TS 26.234 para Packet-switched Streaming Services (PSS – Servicios de Transmisión en Tiempo Real con Conmutación de Paquetes) de 3GPP.
El Internet Engineering Task Force (IETF – Grupo de Trabajo de Ingeniería de Internet) mantiene el estándar RFC 2326 de Real-Time Transport Protocol (RTSP – Protocolo de Transmisión en Tiempo Real), el estándar RFC 1889 de Real-Time Transport Protocol (RTP – Protocolo de Transporte en Tiempo Real) y el estándar RFC 4585 de Real-Time Transport Control Protocol (RTCP – Protocolo de Control de Transporte en Tiempo Real). Estos estándares permiten servicios de medios de transmisión en tiempo real. El RTSP permite a un cliente controlar remotamente un servidor de transmisión de medios de transmisión en tiempo real, por ejemplo transmitiendo órdenes del tipo de VCR tales como “reproducir” y “pausar”. Una sesión de medios de transmisión en tiempo real se inicia cuando un cliente transmite una orden de ‘DESCRIBIR’ de RTSP que incluye un Uniform Resource Identifier (URI – Identificador de Recurso Uniforme) que identifica a un servidor de medios de transmisión en tiempo real (rtsp://…) La petición de DESCRIBIR identifica también el tipo de datos de respuesta que pueden ser manejados por el cliente. La respuesta enviada por el servidor de medios de transmisión en tiempo real incluye una descripción de presentación, típicamente en formato de Session Description Protocol (SDP – Protocolo de Descripción de Sesión).
Actualmente, la información de SDP puede ser obtenida por medio de una petición de DESCRIBIR de RTSP o yendo a buscar un fichero de SDP por medio de HTTP, por ejemplo en aplicaciones de Wireless Access Protocol (WAP – Protocolo de Acceso Inalámbrico). Cuando se obtiene por medio de HTTP, el cliente ya empieza con un fichero de SDP descargado. De cualquier manera, la descripción de presentación de SDP declara los tipos de medios que se van a usar en la sesión utilizando un tipo de medios de MIME de códec-específico para cada componente de los medios. Cada tipo de medio está asociado con un URI que identifica la situación del correspondiente contenido de medios.
El cliente envía una petición de RTSP de ‘ESTABLECER’ al servidor de contenido en respuesta a la petición de DESCRIBIR. La petición de ‘ESTABLECER’ especifica cómo va a ser transportado cada flujo de medios. La petición contiene los URIs del flujo de medios y un especificador de transporte. El especificador de transporte típicamente incluye un puerto local para recibir los datos de RTP (por ejemplo, audio, video o texto), y otro para datos de RTCP (meta información). La respuesta del servidor confirma los parámetros elegidos y rellena partes faltantes, tales como los puertos elegidos del servidor. Cada flujo de medios es configurado utilizando un mensaje de ESTABLECER de RTSP antes de que una petición de reproducción pueda ser enviada desde el cliente al servidor.
Después de que cada flujo de medios sea configurado, el cliente envía una petición de ‘REPRODUCIR’ al servidor que hace que uno o más flujos de medios sean reproducidos. El URI especificado en la petición de REPRODUCIR puede ser un URI agregado (para reproducir todos los flujos de medios) o un URI de un solo flujo de medios (para reproducir sólo ese flujo). Uno o más de los flujos de medios pueden ser detenidos por el cliente enviando una petición de ‘PAUSAR’. El cliente envía una petición de ‘CORTAR’ al cliente para finalizar la sesión de medios de transmisión en tiempo real. La petición de ‘CORTAR’ detiene todos los flujos de medios y libera todos los datos relativos a la sesión en el servidor.
Los servidores de medios de transmisión en tiempo real convencionalmente piden a los clientes que envíen informes de Quality of Service (QoS) o Quality of Experience (Calidad de la Experiencia), para indicar la calidad de una sesión de transmisión de medios en tiempo real particular e incluye datos medidos por un cliente en la capa de transporte, la capa de aplicación o ambas para que la métrica sea comunicada. Aunque el servidor pide al cliente que genere los informes de calidad, es el cliente el que determina qué métricas de calidad son comunicadas al servidor y cuándo. Actualmente, están definidas seis métricas de QoS/QoE, aunque se han propuesto otras. Dos métricas de calidad pueden ser aplicadas al nivel de sesión -las métricas de duración del almacenamiento temporal inicial y de duración del nuevo almacenamiento temporal. Las sucesivas métricas de pérdida de paquetes de RTP, duración de la corrupción, desviación de la velocidad de trama y duración de la fluctuación son aplicadas a los niveles de medios, por ejemplo nivel de audio, video, conversación o texto temporizado. Una nueva métrica de QoE en consideración por el 3GPP TSG-SA Working Group informa del tiempo que pasa entre la iniciación de una conmutación de contenido por un usuario y hasta el tiempo de recepción del primer paquete de medios desde el nuevo contenido o flujo de medios (3GPP 26.234 Change Request 0112).
El cliente especifica también uno o más parámetros de información para cada métrica de calidad soportada por el cliente. Como mínimo, un parámetro de tasa de información es acordado para cada una de las métricas soportadas. El parámetro de tasa de información expresa el máximo periodo de tiempo en segundos entre dos informes de QoS/QoE sucesivos para la correspondiente métrica. Opcionalmente, puede también especificarse un parámetro de intervalo de información. El parámetro intervalo de información define el intervalo de tiempo en un flujo de medios para el cual se proporcionan métricas de calidad, por ejemplo, los primeros 40 segundos de un tiempo de reproducción de medios. Un nuevo parámetro de información relativo a la conmutación de contexto está en consideración por el 3GPP TSG-SA Working Group (3GPP 26.234 Change Request 0112). El nuevo parámetro de información sobre conmutación de contexto en consideración mide la duración de una conmutación de contexto. El cliente y el servidor negocian las métricas de calidad y los parámetros de información que deben ser proporcionados por el cliente. Por ejemplo, el servidor puede proponer un conjunto inicial de métricas como parte de la descripción de SDP proporcionada al cliente en respuesta a una petición de DESCRIBIR de RTSP. En otro ejemplo, el servidor en primer lugar hace la proposición a un último estado, por ejemplo, como parte de la respuesta de ESTABLECER.
No obstante, el cliente determina el último lugar sobre qué métricas informará y de acuerdo con qué parámetros. El cliente es libre para negociar las métricas y proporcionar los parámetros con el servidor, por ejemplo, incluyendo propuestas de métricas en un método de petición de ESTABLECER o REPRODUCIR de RTSP u OPCIONES. El proceso de negociación de métricas continúa hasta que el cliente recibe una respuesta de REPRODUCIR del servidor de contenido. Alternativamente, la negociación puede ser restringida a un número de ofertas y contraofertas. De cualquier manera, el cliente informa sobre las métricas y parámetros aceptados tanto por el cliente como por el servidor después de que el proceso de negociación termina. Una métrica y un parámetro se consideran aceptados tanto por el cliente como por el servidor cuando el reconocimiento es aceptado por el servidor, es decir el servidor se hace eco de la propuesta del cliente, por ejemplo como parte de una respuesta de ESTABLECIMINETO o de REPRODUCCIÓN de RTSP. Una vez que una métrica reconocida como aceptada por el servidor, el cliente ya no incluye la misma métrica en las subsiguientes peticiones al servidor. Por ejemplo, el cliente puede proponer una tasa de información de 10 segundos para una duración de corrupción y de 20 segundos para desviación de velocidad de trama como se aplica a un flujo de medios de video.
El servidor puede reconocer la tasa de información de 10 segundos para duración de la corrupción pero puede contra-proponer una tasa de información de 15 segundos para la desviación de velocidad de trama. El cliente no incluye la métrica de duración de la corrupción en subsiguientes negociaciones que implican al flujo de medios de video puesto que ha sido reconocida como aceptada por el servidor. No obstante, el cliente puede proponer una tasa de información diferente para la desviación de velocidad de trama o aceptar la velocidad propuesta por el servidor. Puesto que la métrica de desviación de velocidad de trama todavía no ha sido acordada, el cliente envía una nueva petición al servidor con la misma propuesta (por ejemplo velocidad=15) o una nueva propuesta (por ejemplo velocidad=10) o por el contrario rechaza la métrica. El servidor reconoce entonces la propuesta en la respuesta. La métrica y el parámetro de información son acordados cuando son reconocidos como aceptados por el servidor de contenido.
El rendimiento del cliente disminuye a medida que las métricas de calidad negociadas por el cliente aumentan. En un escenario de caso peor, un cliente puede intentar negociar dos métricas de calidad diferentes para el nivel de sesión de una sesión de medios de transmisión en tiempo real y cuatro métricas de calidad diferentes para hasta cuatro niveles de medios diferentes de la sesión. El rendimiento del cliente disminuye más si el cliente intenta negociar un parámetro de información diferente para cada métrica de calidad propuesta. Tales negociaciones de métrica extensivas degradan el rendimiento del cliente, que es particularmente una preocupación para los dispositivos de recursos restringidos tales como los teléfonos móviles. Además, el ancho de banda consumido negociando un gran número de métricas de calidad y de valores de parámetros de información diferentes puede ser bastante elevado.
Un consumo de ancho de banda excesivo es incluso una preocupación mayor cuando el cliente subsiguientemente informa acerca de las métricas de calidad acordadas De acuerdo con las diferentes tasas/intervalos de información. Por ejemplo, se requieren aproximadamente 200 bytes para generar un informe de QoS/QoE y se necesitan otros 80 bytes para el correspondiente mensaje de respuesta del servidor. Se consume un ancho de banda excesivo si cada métrica de calidad soportada es proporcionada individualmente, por ejemplo debido a que cada métrica de calidad soportada tiene una tasa y/o intervalo de información diferente. Por encima de un 5% o más de un enlace de 70 kbps puede ser consumido proporcionando métricas de calidad individuales a diferentes intervalos de información. El elevado ancho de banda que se necesita para informar acerca de la QoS/QoE reduce el ancho de banda disponible para transmitir datos reales, lo cual es un problema importante para dispositivos de ancho de banda restringido tales como los teléfonos móviles. Además, la implementación de la fase de información es más compleja cuando se seleccionan múltiples valores de parámetros de información porque las métricas de calidad son proporcionadas a tasas e intervalos de información dispares.
RESUMEN
De acuerdo con los métodos y aparatos enseñados aquí, un cliente de medios de transmisión en tiempo real negocia un único valor para cada parámetro de información asociado con todas las métricas de calidad aplicadas al mismo nivel de una sesión de medios de transmisión en tiempo real o incluso a través de múltiples niveles. Por ejemplo, el cliente puede negociar una única tasa de información para todas las métricas de calidad aplicadas al nivel de sesión de la sesión de medios de transmisión en tiempo real. De esta manera, cada métrica de calidad aplicada al mismo nivel o a múltiples niveles de una sesión de medios de transmisión en tiempo real es proporcionada con la misma velocidad y opcionalmente el mismo intervalo, reduciendo así el número de informes de QoS/QoE generados por el cliente.
De acuerdo con esto, el consumo de ancho de banda se reduce y el rendimiento del cliente se mejora. Además, la implementación de la fase de información resulta más simple cuando se selecciona un único valor de parámetro de información porque se manejan menos parámetros. Aunque la fase de negociación se hace más compleja, la negociación sólo se lleva a cabo una vez por sesión, mientras que la información se lleva a cabo de manera continua. Además, la información se lleva a cabo mientras que la plataforma del teléfono móvil está llevando a cabo la descodificación y la visualización de medios, que con toda probabilidad está optimizada en rendimiento. Por supuesto, dado que los estándares avanzan con el tiempo, el cliente puede negociar un único valor para otros tipos de parámetros de información tales como un parámetro asociado con la conmutación del contenido o con otros aspectos del PSS.
De acuerdo con una realización, la calidad de la sesión de medios de transmisión en tiempo real establecida entre un cliente y un servidor es indicada negociando un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real. El nivel puede ser el nivel de sesión o un nivel de medios. Las métricas de calidad aceptadas por el cliente y por el servidor durante la negociación son proporcionadas de acuerdo con el valor del parámetro de información negociado.
Por consiguiente, la presente invención no está limitada a las características y ventajas anteriores. Los expertos reconocerán características y ventajas adicionales con la lectura de la descripción detallada siguiente, y a la vista de los dibujos que se acompañan.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Figura 1 es un diagrama de bloques de una realización de una red que incluye un servidor de contenido de medios de transmisión en tiempo real y clientes de medios de transmisión en tiempo real.
La Figura 2 ilustra una realización de lógica de tratamiento para negociar un único valor para un parámetro de información con una pluralidad de métricas de calidad aplicadas al mismo nivel de una sesión de medios de transmisión en tiempo real.
La Figura 3 ilustra una realización de secuencia de peticiones y respuestas de RTSP intercambiadas entre un servidor de contenido de medios de transmisión en tiempo real y un cliente.
La Figura 4 ilustra una realización de una respuesta de ESTABLECER de RTSP enviada por un servidor de contenido de medios de transmisión en tiempo real.
La Figura 5 ilustra una realización de una petición de RTSP enviada por un cliente de medios de transmisión en tiempo real para negociar una única tasa de información para múltiples métricas de calidad aplicadas al mismo nivel de una sesión de medios de transmisión en tiempo real.
La Figura 6 ilustra una realización de un informe de QoS/QoE enviado por un cliente de medios de transmisión en tiempo real.
La Figura 7 ilustra otra realización de lógica de tratamiento para negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad aplicadas al mismo nivel de una sesión de medios de transmisión en tiempo real.
DESCRIPCIÓN DETALLADA
La Figura 1 ilustra una realización de un entorno de red 100 que incluye un servidor 102 de contenido de medios de transmisión en tiempo real y una pluralidad de clientes 104, 106, 108 de medios de transmisión en tiempo real. El servidor 102 de contenido proporciona medios de transmisión en tiempo real tales como video, audio, conversación y texto temporizado a los clientes 104, 106, 108 tras una petición. Algunos de los clientes pueden ser un cliente “fijo” o de ancho de banda 104 acoplados al servidor 102 de medios por medio de una red de IP 110 tal como la Internet. Otros clientes son teléfonos móviles 106, 108 acoplados al servidor 102 por medio de una red de acceso por radio 112, 114 u opcionalmente por medio de la red de IP 110. Cada cliente 104, 106, 108 tiene un procesador 116 para llevar a cabo tareas relativas al cliente que incluyen, pero no están limitadas a, gestión de pila de protocolo tal como gestionar pilas de protocolo de medios de transmisión en tiempo real. Los procesadores 116 del cliente permiten la generación y el tratamiento de mensajes basados en RTSP, RTP y RTCP entre otras funciones. Por ejemplo, los procesadores 116 incluidos en los clientes 106, 108 de teléfono móvil pueden implementar el protocolo PSS para establecer sesiones de medios de transmisión en tiempo real con el servidor 102 de contenido sobre una red de acceso por radio 112,
114. Los clientes 104, 106, 108 tienen también memoria 118 para almacenar temporalmente contenido de flujo de medios de transmisión en tiempo real recibido del servidor 102 y uno o más códecs 120 para descodificar el contenido de medios de transmisión en tiempo real.
Una sesión de medios de transmisión en tiempo real es establecida entre el cliente 104, 106, 108 y el servidor 102 de contenido para el contenido de medios de transmisión en tiempo real del servidor 102 al cliente 104, 106, 108. La parte de establecer una sesión de medios de transmisión en tiempo real implica negociar métricas de QoS/QoE para ser proporcionadas por el cliente 104, 106, 108 acerca de la sesión. Por ejemplo, el cliente 104, 106, 108 puede acordar informar acerca de las métricas de calidad de la duración del almacenamiento temporal inicial y/o la duración del re-almacenamiento temporal para el nivel de sesión de la sesión de medios de transmisión en tiempo real. El cliente 104, 106, 108 puede también acordar informar acerca de sucesivas pérdidas de paquetes de RTP, duración de la corrupción, desviación de velocidad de trama, y/o métricas de calidad de duración de la fluctuación para cada uno de los niveles de medios asociados con la sesión de medios de transmisión en tiempo real, por ejemplo niveles de audio, video, conversación y/o texto temporizado. El servidor 102 de contenido u otra entidad (no mostrada) procesa los informes de QoS/QoE recibidos para determinar la calidad de las sesiones de medios de transmisión en tiempo real tal como son medidos por el cliente 104, 106, 108.
Durante el proceso de negociación de métricas de calidad, un cliente 104, 106, 108 determina qué métricas de calidad puede soportar. Cada métrica de calidad soportada por el cliente 104, 106, 108 tiene un parámetro de información (por ejemplo, tasa) o más (por ejemplo, tasa e intervalo). Los parámetros de información determinan la frecuencia mediante la cual el cliente 104, 106, 108 genera los informes de QoS/QoE y opcionalmente el intervalo de tiempo en un particular flujo de medios para el cual las métricas de calidad son proporcionadas. El cliente 104, 106, 108 negocia un único valor para cada parámetro de información asociado con todas las métricas de calidad aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real, por ejemplo como se ilustra en la Etapa 200 de la Figura 2. Por ejemplo, el cliente 104, 106, 108 puede negociar una única tasa de información y opcionalmente un único intervalo de información para todas las métricas de calidad soportadas aplicadas al nivel de video de una sesión de medios de transmisión en tiempo real. De esta manera, cada métrica de calidad aplicada al mismo nivel de una sesión de medios de transmisión en tiempo real es proporcionada con la misma tasa y opcionalmente el mismo intervalo, reduciendo así el número de informes de QoS/QoE generados por el cliente 104, 106, 108, por ejemplo como se ilustra en la Etapa 202 de la Figura 2.
De acuerdo con esto, el consumo de ancho de banda se reduce y el rendimiento del cliente mejora. Por supuesto, como los estándares avanzan con el tiempo, el cliente puede negociar un único valor para otros tipos de parámetros de información distintos de la tasa y el intervalo tal como un parámetro asociado con la conmutación de contenido o con otros aspectos del PSS.
La Figura 3 ilustra una secuencia de valor de RTSP de ejemplo y los correspondientes mensajes de respuesta intercambiados ente un cliente de medios de transmisión en tiempo real 300 y un servidor 302 de contenido para establecer y mantener una sesión de medios de transmisión en tiempo real. En una realización, la sesión de medios de transmisión en tiempo real se inicia basándose en un fichero de SDP descargado por el cliente 300 por medio de HTTP, por ejemplo, en una aplicación de WAP. De esta manera, el cliente 300 tiene un fichero de SDP almacenado localmente obtenido por medio de HTTP. En otra realización, la sesión de medios de transmisión en tiempo real se inicia cuando el cliente 300 transmite una petición de DESCRIBIR de RTSP identificando el URI del contenido de medios de transmisión en tiempo real deseado (por ejemplo, rtsp://server.com/content/baz.3gp en la Figura 3). Para clientes de telefonía móvil, la petición de DESCRIBIR se propaga a través de una red de acceso por radio tal como una GSM/EDGE Radio Access Network (GERAN – Red de Acceso por Radio de GSM/EDGE) 112 o una UMTS Terrestrial Radio Access Network (UTRAN – Red de Acceso por Radio Terrestre de UMTS) 114 a una red de radio de núcleo 122. La petición de DESCRIBIR es procesada por la red de radio de núcleo 122, por ejemplo por un Serving GPRS Support Node (SGSN – Nodo de Soporte de GPRS de Servicio) 124 que controla las conexiones entre las RANs 112, 114 y los clientes de telefonía móvil 106, 108 y un Gateway GPRS Support Node (GGSN – Nodo de Soporte de GPRS de Puerta de Enlace) 126 que proporciona una puerta de enlace entre las RANs 112, 114 y la red de IP 110. Después de que la petición de DESCRIBIR entra en la red de IP 110, es encaminada al servidor 302 de contenido identificado en la petición.
En respuesta a la petición de DESCRIBIR, el servidor 302 de contenido envía una respuesta de DESCRIBIR de RTSP al cliente 300 que incluye una descripción de presentación, por ejemplo en formato SDP. La descripción de presentación declara los tipos de medios que van a ser usados en la sesión utilizando un tipo de medio MIME de códec específico para cada flujo de medios. Parte de la descripción de presentación puede incluir un conjunto inicial propuesto de métricas de calidad y los parámetros de información correspondientes. Alternativamente, el servidor 302 de contenido propone más tarde métricas de calidad iniciales, por ejemplo, como parte de una respuesta de ESTABLECER de RTSP. De cualquier manera, una secuencia de una o más peticiones de ESTABLECER de RTSP y los correspondientes mensajes de respuesta con intercambiados entre el cliente 300 y el servidor 302 o el cliente descarga un fichero de SDP por medio de HTTP para finalizar los detalles relativos a la sesión de medios de transmisión en tiempo real y al contenido de medios como es bien conocido en el sector.
Cuando el cliente 300 recibe un conjunto de métricas de calidad propuesto desde el servidor 302 de contenido, el cliente 300 determina qué métricas son soportadas por el cliente 300 y cuáles no lo son. El cliente 300 determina también si se han propuesto múltiples métricas de calidad para el mismo nivel de sesión de medios de transmisión en tiempo real. Es decir, el cliente 300 determina si se han propuesto múltiples métricas de calidad para el nivel de sesión y los niveles de flujo de medios (video, audio, conversación y/o texto temporizado) de la sesión de medios de transmisión en tiempo real. Métricas de calidad a nivel de sesión son aplicadas a la sesión de medios de transmisión en tiempo real y métricas de calidad de nivel de medios son aplicadas al componente de medios indicado de la sesión de medios de transmisión en tiempo real. Si se han propuesto múltiples métricas de calidad para el mismo nivel, el cliente 300 propone un único valor para cada parámetro de información asociado con las métricas de calidad propuestas. De esta manera, el nivel de sesión de una sesión de medios de transmisión en tiempo real tendrá sólo una única tasa de información y un único intervalo de información opcional para todas las métricas de calidad aceptadas por el cliente 300 y por el servidor 302 de contenido para el nivel de la sesión. Asimismo, a cada nivel de medios se le asigna también una única tasa de información y un único intervalo de información opcional para todas las métricas de calidad aceptadas para los niveles de medios.
La Figura 4 ilustra también una realización de una respuesta de ESTABLECER de RTSP recibida por el cliente 300 desde el servidor 302 de contenido que incluye un conjunto de métricas de calidad propuesto. Una cabecera de negociación de métrica de calidad (3GPP-QoE-Metrics) incluida en el mensaje de respuesta de ESTABLECER indica las métricas de calidad propuestas. En el presenta ejemplo, una métrica de calidad (Initial_Buffering_Duration – Duración de Almacenamiento Temporal Inicial) y el parámetro de QoS/QoE (tasa) son aplicados al nivel de sesión (rtsp://server.com/content/baz.3gp) de una sesión de medios de transmisión en tiempo real (rtsp://server.com/content/baz.3gp). Una métrica de calidad (Corruption_Duration
– Duración de la Corrupción) y parámetro de información (velocidad) son aplicados al nivel de audio(rtsp://server.com/content/baz.3gp/audiotrack) de la sesión de medios de transmisión en tiempo real. No obstante, dos métricas de calidad (Corruption_Duration y Framerate_Deviation – Duración de la corrupción y Desviación de la Velocidad de trama) y dos parámetros de información (velocidad e intervalo) son aplicados al nivel de video (rtsp://server.com/content/baz/videotrack) de la sesión de medios de transmisión en tiempo real.
De acuerdo con esto, el cliente 300 determina si puede soportar las métricas y los parámetros propuestos para los niveles identificados. Si el cliente 300 soporta todas las métricas de calidad propuestas, el cliente 300 negocia entonces un único valor para los parámetros de tasa de información e intervalo asociados con las métricas de calidad de la duración de la corrupción y la desviación n de la velocidad de trama aplicada al nivel de video. En este ejemplo, ambas métricas tienen el mismo intervalo de información (0-40 npt). Preferiblemente, el cliente 300 acepta el valor del intervalo de información propuesto para las dos métricas de calidad del nivel de video si el cliente 300 puede soportar el valor de intervalo específico. No obstante, el cliente 300 puede alternativamente proponer un valor de intervalo de información diferente para las métricas de calidad del nivel de video.
De cualquier manera, el cliente 300 propone un único valor de tasa de información para las métricas de calidad del nivel de video puesto que las métricas tienen diferentes velocidades propuestas (20 segundos para Duración de la Corrupción y 20 segundos para Desviación de Velocidad de Trama). De otro modo, el cliente 300 generará un informe de QoS/QoE dos veces como ocurre a menudo para la métrica de calidad de la duración de la corrupción si el cliente 300 aceptó los diferentes valores de parámetro propuestos por el servidor de contenido 302 para el nivel de video, consumiendo de este modo un ancho de banda adicional y reduciendo el rendimiento del cliente. En una realización, el cliente 300 selecciona la primera tasa de información identificada en la respuesta a ESTABLECER (10 segundos). En otra realización, el cliente 300 selecciona la tasa de información teniendo el menor impacto en el consumo de ancho de banda (20 segundos en la Figura 4). En otra realización más, el cliente 300 selecciona una última tasa de información independientemente de las tasas de información propuestas por el servidor 302 de contenido. En otra realización más, el cliente 300 utiliza una tasa de información identificada anteriormente en la fase de negociación, tal como la incluida en un fichero de SDP descargado, o una tasa de información que fue ya reconocida como aceptada por el servidor 302 para otras métricas al mismo nivel.
Independientemente de ello, el cliente 300 envía bien otra petición de ESTABLECER o una petición de REPRODUCIR al servidor 302 de contenido o utiliza el método de SET_PARAMETER -Establecer Parámetro u OPTIONS – Opciones para identificar la única tasa de información propuesta en último lugar (por ejemplo, 20 segundos) para las dos métricas de calidad de nivel de video como se muestra en la Figura 5. La respuesta indica también que el cliente 300 aceptó el único intervalo de información de 0-40 npt para las métricas de calidad de nivel de video. Alternativamente, el cliente 300 puede proponer un intervalo de información diferente para las métricas de calidad de nivel de video como se ha descrito previamente. La tasa de información para la métrica de calidad del nivel de audio está también identificada en la respuesta para indicar la aceptación por el cliente 300.
El servidor 302 de contenido bien reconoce la aceptación de una o más de las métricas de calidad propuestas y de los correspondientes valores de parámetro de información o propone otras diferentes. El servidor 302 de contenido acepta una métrica de calidad particular y un valor de parámetro de información, por ejemplo por medio del método de SET_PARAMETER u OPCIONES o enviando una respuesta al cliente 300 tal como una respuesta a ESTABLECER o REPRODUCIR indicando un reconocimiento. Si se envía una respuesta, la respuesta incluye la métrica de calidad y el valor de parámetro de información proporcionados por el cliente 300 en la petición previa para la cual el servidor 302 está reconociendo la aceptación. Las métricas de calidad reconocidas aceptadas por el servidor 302 no están incluidas en subsiguientes peticiones enviadas por el cliente 300 puesto que han sido acordadas tanto por el cliente 300 como por el servidor 302 de contenido.
El servidor 302 de contenido puede proponer un valor de parámetro diferente identificando el valor diferente y la correspondiente métrica en la respuesta. El cliente 300 puede aceptar el valor diferente o proponer un nuevo valor en una petición subsiguiente. De cualquier manera, la negociación de la métrica de calidad continúa hasta que todas las métricas son reconocidas como aceptadas por el servidor 302 de contenido o cuando el servidor 302 envía una respuesta a REPRODUCIR al cliente
300. Una respuesta de REPRODUCIR indica que la negociación sobre la métrica de calidad está completa y que el envío de contenido de medios de transmisión en tiempo real va a empezar. Alternativamente, la negociación de métrica de calidad puede terminar cuando un número particular de ofertas y contraofertas en las negociaciones entre el cliente 300 y el servidor 302 se ha alcanzado. Independientemente, sólo las métricas de calidad reconocidas como aceptadas por el servidor 302 de contenido se ha alcanzado. Independientemente, sólo las métricas de calidad reconocidas como aceptadas por el servidor 302 de contenido y el cliente 300 son proporcionadas por el cliente 300 basándose en el parámetro o los parámetros de información. Puesto que el cliente 300 negocia una única tasa de información y un único intervalo de información opcional para todas las métricas de calidad aceptadas para el mismo nivel de una sesión de medios de transmisión en tiempo real, el número de informes de QoS/QoE que el cliente 300 envía se reduce significativamente, reduciendo por ello el consumo de ancho de banda y mejorando el rendimiento del cliente.
Después de que una negociación de métrica finaliza, el cliente 300 envía informes de QoS/QoE indicando la calidad del contenido de medios de transmisión en tiempo real recibida. La velocidad a la cual son enviados los informes de QoS/QoE para cada nivel de la sesión de medios de transmisión en tiempo real depende de un único valor de tasa de información negociado por el cliente 300 para cada nivel. El cliente 300 puede enviar un informe de QoS/QoE como parte de unos mensajes de ESTABLECER_PARÁMETRO, PAUSAR o CORTAR de RTSP. Para clientes de telefonía móvil 106, 108, los informes de QoS/QoE son enviados al servidor 302 de contenido sobre la red de acceso por radio 112, 114. La Figura 6 ilustra un mensaje de ESTABLECER_PARÁMETRO de ejemplo que incluye un informe de QoS/QoE. El mensaje incluye dos mediciones obtenidas por el cliente 300 (200 y 1300) para la métrica de duración de la corrupción (Corruption_Duration) proporcionadas para el nivel de audio de una sesión de medios de transmisión en tiempo real. La sesión de medios de transmisión en tiempo real referenciada en este ejemplo fue establecida basándose en el mensaje de petición de ESTABLECER ilustrado en la Figura 4. Una cabecera de información de métrica de calidad (3GPP-QoE-Feedback) incluida en el mensaje de ESTABLECER_PARÁMETRO indica que los datos de la métrica de sesión están incluidos en el mensaje.
De acuerdo con la Figura 6, la métrica de calidad de duración de la corrupción para el nivel de audio de la sesión de medios de transmisión en tiempo real es proporcionada. A grandes rasgos, el cliente 300 genera un único informe de QoS/QoE para cada nivel de una sesión de medios de transmisión en tiempo real basándose en la única tasa de información negociada para cada nivel. De esta manera, el cliente no genera múltiples informes a diferentes velocidades para el mismo nivel de la sesión de medios de transmisión en tiempo real.
La Figura 7 ilustra una realización de lógica de tratamiento de ejemplo para negociar un único valor para cada parámetro asociado a la información, estando todas las métricas de calidad aceptadas aplicada al mismo nivel de una sesión de medios de transmisión en tiempo real. La lógica de tratamiento empieza cuando un cliente 104, 106, 108 recibe propuestas de métrica de calidad desde el servidor 102 de contenido, por ejemplo, como parte de un mensaje de respuesta de DESCRIBIR O ESTABLECER de RTSP o un fichero de DSP (Etapa 700). Las métricas de calidad pueden ser un conjunto inicial de propuestas de métrica de calidad recibidas del servidor 102 de contenido, por ejemplo incluido en una respuesta de DESCRIBIR o una respuesta de ESTABLECER de RTSP o un fichero de SDP enviado por el servidor
102. Alternativamente, las métricas de calidad pueden ser un conjunto re-negociado de propuestas de métrica recibidas desde el servidor 102 de contenido más tarde durante el proceso de negociación de métrica de calidad, por ejemplo, como parte de una respuesta de ESTABLECER o REPRODUCIR de RTSP recibida desde el servidor 102 o por medio del método de ESTABLECER_PARÁMETRO u OPCIONES. De cualquier manera, el cliente 104, 106, 108 rechaza métricas y parámetros de calidad no soportados (Etapa 702). El cliente 104, 106, 108 intenta negociar una única tasa de información y opcionalmente un único intervalo de información para todas las métricas de calidad soportadas que son aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real a menos que la negociación de la métrica de calidad haya finalizado (Etapa 704). En una realización, el cliente 300 incluye en peticiones enviadas al servidor 302 sólo las métricas que todavía deben ser aceptadas tanto por el cliente 300 como por el servidor 302.
El cliente 104, 106, 108 determina si todas las métricas de calidad soportadas han sido reconocidas como aceptadas por el servidor 102 de contenido para cada nivel de la sesión de medios de transmisión en tiempo real (Etapa 706). El cliente 104, 106, 108 negocia una única tasa de información y opcionalmente un único intervalo de información para todas las métricas de calidad soportadas aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real. De esta manera, si el servidor 102 de contenido reconoce como aceptadas todas las propuestas de métrica de calidad hechas por el cliente 104, 106, 108, el cliente 104, 106, 108 acepta entonces todas las métricas (Etapa 708). El cliente 104, 106, 108 proporciona subsiguientemente las métricas de calidad aceptadas basándose en lo acordado sobre la tasa de información y el opcional intervalo de información para cada nivel de la sesión de medios de transmisión en tiempo real (710).
No obstante, si el servidor 102 de contenido no reconoce la aceptación de todas las métricas de calidad soportadas, el cliente 104, 106, 108 determina si las métricas de calidad aplicadas a un nivel particular de la sesión de medios de transmisión en tiempo real han sido reconocidas como aceptadas por el servidor 102 (Etapa 712). El cliente 104, 106, 108 acepta todas las métricas de calidad reconocidas como aceptadas para un nivel particular de la sesión de medios de transmisión en tiempo real puesto que las métricas tienen al menos la misma tasa de información (Etapa 714). El cliente 104, 106, 108 propone entonces la misma única tasa de información y el mismo único intervalo de información opcional para las métricas de calidad que no han sido reconocidas como aceptadas por el servidor 102 de contenido. En una realización, el servidor 102 de contenido reconoce la aceptación de una tasa de información propuesta previamente para un primer subconjunto de métricas de calidad aplicadas a un nivel particular de la sesión de medios de transmisión en tiempo real, pero propone una tasa de información diferente para las otras métricas de calidad.
Por ejemplo, el cliente 104, 106, 108 puede proponer una tasa de información de 20 segundos para las métricas de duración de la corrupción, duración de la fluctuación y desviación de velocidad de trama aplicadas al nivel de video de una sesión de medios de transmisión en tiempo real. El servidor 102 de contenido reconoce la aceptación de una tasa de información de 20 segundos para las métricas de duración de la corrupción y de duración de la fluctuación, pero propone una tasa de información de 10 segundos para la métrica de desviación de velocidad de trama. De acuerdo con esta realización, el cliente 104, 106, 108 acepta la tasa de información de 20 segundos para las métricas de duración de la corrupción y de duración de la fluctuación, pero rechaza la tasa de información de 10 segundos para la métrica de desviación de velocidad de trama porque es diferente de la velocidad propuesta previamente por el cliente 104, 106, 108. De acuerdo con esto, el cliente 104, 106, 108 propone una única tasa de información para todas las métricas de calidad aplicadas al nivel de video de la sesión de medios de transmisión en tiempo real, por ejemplo, como parte de una petición de ESTABLECER o REPRODUCIR de RTSP o por medio del método de ESTABLECER_PARÁMETRO u OPCIONES (Etapa 716). Preferiblemente, el cliente 104, 106, 108 propone una tasa de información de 20 segundos en este ejemplo porque la velocidad de 20 segundos fue previamente reconocida como aceptada por el servidor 102 de contenido para las métricas de duración de la corrupción y duración de la fluctuación. De esta manera, el cliente 104, 106, 108 sólo necesita proponer una tasa de información de 20 segundos para la métrica de desviación de velocidad de trama.
En otra realización, el servidor 102 de contenido propone una tasa de información diferente para todas las métricas de calidad soportadas aplicadas a un nivel particular de la sesión de medios de transmisión en tiempo real. Por ejemplo, el cliente 104, 106, 108 puede proponer una tasa de información de 20 segundos para las métricas de duración de la corrupción, duración de la fluctuación y desviación de la velocidad de trama, aplicadas al nivel de video de una sesión de medios de transmisión en tiempo real. El servidor 102 de contenido contra propone una tasa de información de 10 segundos para cada una de las métricas de calidad aplicadas al nivel de video. De acuerdo con esta realización, el cliente 104, 106, 108 acepta la tasa de información de 10 segundos para las métricas de duración de la corrupción, duración de la fluctuación y desviación de la velocidad de trama porque el servidor 102 de contenido propuso una única tasa de información, aunque diferente de la tasa original propuesta por el cliente 104, 106, 108. De acuerdo con esto, el cliente 104, 106, 108 propone una tasa de información de 10 segundos para todas las métricas de calidad aplicadas al nivel de video de la sesión de medios de transmisión en tiempo real, por ejemplo, como parte de una petición de ESTABLECER O REPRODUCIR de RTSP o por medio del método de ESTABLECER_PARÁMETRO u OPCIONES (Etapa 716).
De acuerdo con cualquier realización, el cliente 104, 106, 108 negocia una única tasa de información y opcionalmente un único intervalo de información (u otro parámetro de información) para todas las métricas de calidad soportadas aplicadas al mismo nivel de una sesión de medios de transmisión en tiempo real. Las propuestas de métrica recibidas del servidor 102 de contenido pueden no estar adecuadamente organizadas por nivel. Es decir, el servidor 102 de contenido puede asociar métricas tanto a nivel de sesión como a nivel de medios con un nivel de la sesión de medios de transmisión en tiempo real, por ejemplo, el nivel de sesión. Cuando esto ocurre, el cliente 104, 106, 108 puede aplicar de nuevo las métricas de calidad al nivel apropiado de la sesión de medios de transmisión en tiempo real. Por ejemplo, el servidor 102 de contenido puede aplicar métricas de calidad tanto de nivel (por ejemplo, duración de almacenamiento temporal inicial y/o duración del nuevo almacenamiento temporal) como métricas de calidad de nivel de medios (por ejemplo, sucesivas pérdidas de paquetes de RTP, duración de la corrupción, desviación de la velocidad de trama y/o duración de la fluctuación) al nivel de sesión de una sesión de medios de transmisión en tiempo real. De acuerdo con esto, el cliente 104, 106, 108 aplica de nuevo las métricas de nivel de medios a los niveles de medios apropiados. En una realización, el cliente 104, 106, 108 aplica de nuevo las métricas de nivel de medios a un nivel de medios apropiado asociando las métricas de calidad de nivel de medios con los correspondientes URIs que identifican los componentes de medios apropiados de la sesión de medios de transmisión en tiempo real, por ejemplo como parte de una
5 petición de ESTABLECER o REPRODUCIR de RTSP o por medio del método de ESTABLECER_PARÁMETRO u OPCIONES. El cliente 104, 106, 108 negocia entonces un único valor para cada parámetro de información asociado con las métricas de calidad aplicadas al nivel de sesión y a cada nivel de medios.
Cuando las variaciones de intervalo anteriores en mente, debe entenderse que
10 la presente invención no está limitada a la descripción anterior, ni está limitada por los dibujos que se acompañan. Por el contrario, la presente invención está limitada sólo por las reivindicaciones siguientes, y sus equivalentes legales.

Claims (14)

  1. REIVINDICACIONES
    1. Un método de indicar la calidad de una sesión de medios de transmisión en tiempo real establecida entre un cliente y un servidor, teniendo la sesión de medios de transmisión en tiempo real un nivel de sesión y al menos un nivel de medios, estando el método caracterizado porque comprende:
    negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real; y
    proporcionar las métricas de calidad aceptadas por el cliente y el servidor durante la negociación
    de acuerdo con el valor de parámetro de información negociado.
  2. 2. El método de la reivindicación 1, en el que negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real comprende negociar una única tasa de información.
  3. 3. El método de la reivindicación 1, que comprende también:
    negociar un único valor para un parámetro de información asociado con la pluralidad de métricas de calidad aceptadas durante la negociación por el cliente y el servidor
    de acuerdo con ambos valores del parámetro de información negociados.
  4. 4.
    El método de la reivindicación 3, en el que negociar un único valor para el segundo parámetro de información comprende negociar un único intervalo de información.
  5. 5.
    El método de la reivindicación 1, en el que negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real comprende:
    seleccionar un único valor del parámetro de información de una pluralidad de valores del parámetro de información en una respuesta recibida del servidor; y
    enviar una petición al servidor proponiendo el valor de parámetro de información seleccionado para cada una de las métricas de calidad soportadas por el cliente.
  6. 6. El método de la reivindicación 5, que comprende también:
    procesar una respuesta subsiguiente recibida del servidor proponiendo un nuevo valor para el parámetro de información asociado con cada una de las métricas de calidad soportadas por el cliente; y
    sustituir el valor del parámetro de información propuesto previamente con el valor de parámetro de información propuesto en último lugar para cada una de las métricas de calidad soportadas por el cliente.
  7. 7. El método de la reivindicación 6, que comprende también enviar una petición subsiguiente al servidor indicando que el cliente aceptó el valor del parámetro de información en último lugar propuesto para cada una de las métricas de calidad soportadas por el cliente.
  8. 8. El método de la reivindicación 5, que comprende también:
    procesar una respuesta subsiguiente recibida del servidor reconociendo como aceptado el valor del parámetro de información propuesto previamente para un primer subconjunto de las métricas de calidad soportadas por el cliente y proponiendo un nuevo valor del parámetro de información para un segundo subconjunto de las métricas de calidad soportadas por el cliente;
    aceptar el valor del parámetro de información propuesto previamente para el primer subconjunto de las métricas de calidad soportadas por el cliente; y
    rechazar el valor del parámetro de información propuesto en último lugar para el segundo subconjunto de las métricas de sesión soportadas por el cliente.
  9. 9.
    El método de la reivindicación 8, que comprende también enviar una petición subsiguiente al servidor proponiendo de nuevo el valor del parámetro de información
    seleccionado previamente para el segundo subconjunto de las métricas de calidad soportadas por el cliente.
  10. 10.
    El método de la reivindicación 1, en el que negociar un único valor para el parámetro de información asociado con una pluralidad de métricas de calidad aplicadas al mismo de la sesión de medios de transmisión en tiempo real comprende:
    negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad de sesión aplicadas al nivel de sesión de una sesión de medios de transmisión en tiempo real; y
    negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad de medios aplicadas al menos a un nivel de medios de video, audio, conversación o texto temporizado de la sesión de medios de transmisión en tiempo real.
  11. 11. El método de la reivindicación 1, en el que negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de sesión aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real comprende:
    recibir una respuesta desde el servidor que aplica las métricas de calidad de la sesión y las métricas de calidad de medios al nivel de sesión de la sesión de medios de transmisión en tiempo real;
    aplicar de nuevo las métricas de calidad de medios a uno de los niveles de medios de la sesión de medios de transmisión en tiempo real;
    negociar un único valor para un parámetro de información asociado con las métricas de calidad de sesión aplicadas al nivel de sesión; y
    negociar un último valor para un parámetro de información asociado con las métricas de calidad de medios aplicados a uno de los niveles de medios.
  12. 12.
    El método de la reivindicación 11, en el que aplicar de nuevo las métricas de calidad de medios a uno de los niveles de medios de la sesión de medios de transmisión en tiempo real comprende asociar las métricas de calidad de medios con un identificador de recurso uniforme que identifica el componente de medios de la sesión de medios de transmisión en tiempo real.
  13. 13.
    El método de la reivindicación 1, en el que proporcionar las métricas de calidad comprende enviar un informe que incluye mediciones obtenidas por el cliente basándose en las métricas de calidad al servidor sobre una red de acceso por radio con conmutación de paquetes.
    5 14. Un cliente de medios de transmisión en tiempo real para indicar la calidad de una sesión de medios de transmisión en tiempo real establecida entre el cliente y un servidor, teniendo la sesión de medios de transmisión en tiempo real un nivel de sesión y al menos un nivel de medios, estando el cliente caracterizado porque comprende un procesador configurado para:
    10 negociar un único valor para un parámetro de información asociado con una pluralidad de métricas de calidad aplicadas al mismo nivel de la sesión de medios de transmisión en tiempo real; y
    proporcionar las métricas de calidad aceptadas por el cliente y el servidor durante una negociación de acuerdo con el valor del parámetro de información 15 negociado.
  14. 15. El cliente de medios de transmisión en tiempo real de la reivindicación 14, en el que el procesador está configurado para llevar a cabo las etapas del método de acuerdo con cualquiera de las reivindicaciones 2 a 13.
ES07857690T 2006-12-29 2007-12-17 Método y aparato para informar sobre la calidad de medios de transmisión en tiempo real. Active ES2347943T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US764476 1977-01-31
US88271106P 2006-12-29 2006-12-29
US882711P 2006-12-29

Publications (1)

Publication Number Publication Date
ES2347943T3 true ES2347943T3 (es) 2010-11-26

Family

ID=38282840

Family Applications (1)

Application Number Title Priority Date Filing Date
ES07857690T Active ES2347943T3 (es) 2006-12-29 2007-12-17 Método y aparato para informar sobre la calidad de medios de transmisión en tiempo real.

Country Status (11)

Country Link
US (1) US8959239B2 (es)
EP (1) EP2098033B1 (es)
KR (1) KR20090097204A (es)
CN (1) CN101573941B (es)
AT (1) ATE472887T1 (es)
CA (1) CA2673661A1 (es)
DE (1) DE602007007517D1 (es)
ES (1) ES2347943T3 (es)
PL (1) PL2098033T3 (es)
TW (1) TW200835264A (es)
WO (1) WO2008080815A1 (es)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7873727B2 (en) * 2008-03-13 2011-01-18 Board Of Regents, The University Of Texas Systems System and method for evaluating streaming multimedia quality
US20100121973A1 (en) * 2008-11-12 2010-05-13 Yuliya Lobacheva Augmentation of streaming media
US8201220B2 (en) 2008-12-23 2012-06-12 Qwest Communications International Inc. Network user usage profiling
US7916635B2 (en) * 2008-12-23 2011-03-29 Qwest Communications International, Inc. Transparent network traffic inspection
EP2355453B1 (en) * 2010-02-01 2012-08-29 Alcatel Lucent Quality parameters negotiation by specific URI
US20110202593A1 (en) * 2010-02-17 2011-08-18 Peter Vaderna Focused sampling of terminal reports in a wireless communication network
EP2583432B1 (en) * 2010-06-18 2019-02-20 Nokia Technologies Oy Method and apparatus for generating and handling streaming media quality-of-experience metrics
US20120192216A1 (en) * 2011-01-24 2012-07-26 Huawei Technologies Co., Ltd. Qoe ensuring method and apparatus
US8156239B1 (en) * 2011-03-09 2012-04-10 Metropcs Wireless, Inc. Adaptive multimedia renderer
WO2013004309A2 (en) * 2011-07-07 2013-01-10 Telefonaktiebolaget L M Ericsson (Publ) Media stream grouping in multimedia communication networks
CN102868666B (zh) * 2011-07-07 2015-09-23 北京东方文骏软件科技有限责任公司 基于用户体验交互的流媒体质量监测报告的实现方法
US20130304934A1 (en) * 2011-09-29 2013-11-14 Avvasi Inc. Methods and systems for controlling quality of a media session
US9356917B2 (en) 2012-03-23 2016-05-31 Avaya Inc. System and method for end-to-end encryption and security indication at an endpoint
US9178778B2 (en) 2012-03-23 2015-11-03 Avaya Inc. System and method for end-to-end RTCP
US9860296B2 (en) * 2012-03-23 2018-01-02 Avaya Inc. System and method for end-to-end call quality indication
US8923880B2 (en) * 2012-09-28 2014-12-30 Intel Corporation Selective joinder of user equipment with wireless cell
US8539286B1 (en) * 2013-02-26 2013-09-17 Roku, Inc. Method and apparatus of error reporting
US9986044B2 (en) * 2013-10-21 2018-05-29 Huawei Technologies Co., Ltd. Multi-screen interaction method, devices, and system
US20160373509A1 (en) * 2015-06-16 2016-12-22 Sk Telecom Co., Ltd. APPARATUS AND METHOD FOR REPORTING QoS/QoE IN MOBILE ENVIRONMENT
US20170111424A1 (en) * 2015-07-08 2017-04-20 Telefonaktiebolaget Lm Ericsson (Publ) A method and apparatus for reporting data from a wireless device to a network node of a communication network
WO2017184008A1 (en) * 2016-04-19 2017-10-26 Ringcentral, Inc Systems and methods for improving media data communications over a network
KR102540459B1 (ko) * 2016-12-22 2023-06-05 한화비전 주식회사 Rtp/rtsp 표준을 따르는 서버와 클라이언트에서 실시간 영상 스트리밍 방법
US10484308B2 (en) 2017-03-31 2019-11-19 At&T Intellectual Property I, L.P. Apparatus and method of managing resources for video services
US10819763B2 (en) 2017-03-31 2020-10-27 At&T Intellectual Property I, L.P. Apparatus and method of video streaming
US10673955B2 (en) * 2017-04-04 2020-06-02 Microsoft Technology Licensing, Llc Systems and methods for negotiation of structured configuration parameters for stateful server/client systems
US11044185B2 (en) 2018-12-14 2021-06-22 At&T Intellectual Property I, L.P. Latency prediction and guidance in wireless communication systems
CN113839906B (zh) * 2020-06-08 2022-12-30 华为技术有限公司 音视频流质量的确定方法、装置、设备及可读存储介质

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6621793B2 (en) * 2000-05-22 2003-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Application influenced policy
US6763392B1 (en) * 2000-09-29 2004-07-13 Microsoft Corporation Media streaming methods and arrangements
US7054945B2 (en) * 2001-04-09 2006-05-30 Nokia Corporation Technique for providing announcements in mobile-originated calls
FI112140B (fi) * 2001-05-23 2003-10-31 Nokia Corp Informaation kommunikointi
US7609673B2 (en) * 2002-02-08 2009-10-27 Telefonaktiebolaget Lm Ericsson (Publ) Packet-based conversational service for a multimedia session in a mobile communications system
EP1331785B1 (en) * 2002-01-23 2005-04-20 Sony International (Europe) GmbH A method for enabling the negotiation of end-to-end QoS by using the end-to-end negotiation protocol (E2ENP)
US6888821B2 (en) 2003-02-10 2005-05-03 Nokia Corporation Dynamic media authorization in mobile networks
CN1751304A (zh) * 2003-02-13 2006-03-22 诺基亚有限公司 在多媒体流中用于信号指示流质量匹配和控制机制的方法
EP1593046A2 (en) * 2003-02-13 2005-11-09 Nokia Corporation Rate adaptation method and device in multimedia streaming
EP1453269A1 (en) * 2003-02-25 2004-09-01 Matsushita Electric Industrial Co., Ltd. A method of reporting quality metrics for packet switched streaming
US9350566B2 (en) * 2003-04-30 2016-05-24 Nokia Technologies Oy Handling traffic flows in a mobile communications network
CN1839597B (zh) * 2003-08-21 2010-07-21 维迪亚特企业公司 对无线通信网络的质量体验(qoe)度量
ATE458343T1 (de) * 2003-09-02 2010-03-15 Nokia Corp Übertragung eingebetteter informationen bezüglich einer dienstqualität
EP1668939B1 (en) 2003-09-30 2010-09-01 TELEFONAKTIEBOLAGET LM ERICSSON (publ) System and method for reporting measurements in a communication system
BRPI0418527A (pt) * 2004-02-12 2007-05-15 Nokia Corp método para relatar uma qualidade de transmissão em fluxo, programa de computação com instruções operáveis, produto de programa de computação, sistema de transmissão em fluxo, cliente em um sistema de transmissão em fluxo, servidor em um sistema de transmissão em fluxo, e, protocolo para um sistema de transmissão em fluxo
AU2004317111B2 (en) * 2004-02-13 2009-01-08 Nokia Corporation Timing of quality of experience metrics
US20050201296A1 (en) * 2004-03-15 2005-09-15 Telefonaktiebolaget Lm Ericsson (Pu Reduced channel quality feedback
US8010652B2 (en) * 2004-05-07 2011-08-30 Nokia Corporation Refined quality feedback in streaming services
ATE413044T1 (de) * 2004-06-30 2008-11-15 Huawei Tech Co Ltd Verfahren zum periodischen akquirieren einer dienstqualität (qos) eines multimedia-streams
US7272190B2 (en) * 2004-07-07 2007-09-18 Motorola, Inc. Method and apparatus for determining channel quality and performing adaptive modulation/coding within a multicarrier communication system
US9130706B2 (en) * 2005-05-26 2015-09-08 Unwired Planet, Llc Method and apparatus for signal quality loss compensation in multiplexing transmission systems
CN100456834C (zh) * 2005-10-17 2009-01-28 华为技术有限公司 H.264多媒体通信的服务质量监测方法
US20080049648A1 (en) * 2006-08-28 2008-02-28 Motorola, Inc. Method and apparatus for policy management for an internet protocol multimedia subsystem based wireless communication system

Also Published As

Publication number Publication date
US20080162714A1 (en) 2008-07-03
CN101573941A (zh) 2009-11-04
TW200835264A (en) 2008-08-16
DE602007007517D1 (de) 2010-08-12
EP2098033A1 (en) 2009-09-09
US8959239B2 (en) 2015-02-17
EP2098033B1 (en) 2010-06-30
WO2008080815A1 (en) 2008-07-10
CA2673661A1 (en) 2008-07-10
KR20090097204A (ko) 2009-09-15
PL2098033T3 (pl) 2010-10-29
CN101573941B (zh) 2013-02-06
ATE472887T1 (de) 2010-07-15

Similar Documents

Publication Publication Date Title
ES2347943T3 (es) Método y aparato para informar sobre la calidad de medios de transmisión en tiempo real.
ES2654333T3 (es) Control de sesión para la transmisión de flujos de medios
US7898995B2 (en) Dynamic adjustment of inactivity timer threshold for call control transactions
EP2060077B1 (en) Indicating or remarking of a dscp
US8059656B1 (en) Expedited resource negotiation in SIP
TWI239172B (en) Method and system for group communications
US7768998B1 (en) Dynamic VoIP codec selection based on link attributes at call setup
KR100759954B1 (ko) 멀티미디어 스트리밍에서 클라이언트 레이트 능력을시그널링하는 방법
US7944880B2 (en) Method and arrangement for establishing a communication session for multimedia
US8589563B2 (en) System, method, and apparatus for maintaining call state information for real-time call sessions
US20080228912A1 (en) Enhanced Quality Reporting for Transmission Sessions
TW200833144A (en) Registration timer adjustment based on wireless network quality
EP2412139A1 (en) Method and arrangement for providing relevant service levels
US8639279B2 (en) Method of requesting a communication session using segmented signaling messages
JP2013013105A (ja) 最大パケットサイズ属性を規定する、回線交換マルチメディアサービスとパケット交換マルチメディアサービスとの間の効率的なインターワーキング
US20120005351A1 (en) Method and apparatus for transmitting an application identifier across application elements
JP5729222B2 (ja) 電話端末
KR20080037950A (ko) 데이터를 송수신하는 방법 및 장치
KR100652768B1 (ko) Ｉｍｓ 네트워크에서의 단말 사이의 ｉｐ 연결 종료 방법
Goulart et al. On overlapping resource management and call setup signaling: a new signaling approach for internet multimedia applications
Bilbao et al. PQoS-driven VoIP service adaptation in UMTS networks
Cuny et al. Mobile Service Applications and Performance in UMTS
Eggert et al. AVT Core Working Group V. Singh Internet-Draft T. Karkkainen Intended status: Experimental J. Ott Expires: September 15, 2011 S. Ahsan Aalto University