ES2509292T3 - Calidad de medios clasificada de una experiencia - Google Patents

Abstract

Método para notificar una calidad de transmisión en flujo continuo, en el que por lo menos un flujo continuo de medios se transmite por flujo continuo a un cliente (601), y en el que dicha transmisión en flujo continuo es controlada por un protocolo (109) que se hace funcionar entre dicho cliente (601) y un servidor (600), que comprende: - notificar (603) por parte de dicho cliente a dicho servidor (600) la calidad de dicha transmisión en flujo continuo basándose en por lo menos un factor de medición de calidad seleccionado, en el que dicho por lo menos un factor de medición de calidad seleccionado es un factor de medición de la calidad de la experiencia, que se basa por lo menos parcialmente en la decisión de si por lo menos una trama de dicho por lo menos un flujo continuo de medios es una trama buena, caracterizado por que dicha notificación de dicha calidad de dicha transmisión en flujo continuo se basa además en una clase seleccionada de factores de medición de la calidad, en el que dicha clase seleccionada de factores de medición de calidad se selecciona a partir de un conjunto predefinido de por lo menos dos clases de factores de medición de calidad, en el que la selección de dicha clase de factores de medición de calidad comprende la negociación (605-609) de dicha clase de factores de medición de calidad entre dicho cliente (601) y dicho servidor (600), y en el que cada clase de factores de medición de calidad en dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad define un conjunto diferente de reglas sobre cómo decidir si una trama de dicho por lo menos un flujo continuo de medios es una trama buena.

Description

15

25

35

45

55

65 E04710443

01-10-2014

DESCRIPCIÓN

Calidad de medios clasificada de una experiencia.

Campo de la invención

La invención se refiere a un método, un programa de ordenador, un producto de programa de ordenador, un sistema, un cliente, un servidor y un protocolo para notificar una calidad de transmisión en flujo continuo (streaming) en un sistema de transmisión en flujo continuo, en el que por lo menos un flujo continuo de medios se transmite en flujo continuo a un cliente, y en el que dicha transmisión en flujo continuo se controla por medio de un protocolo que se hace funcionar entre dicho cliente y un servidor.

Antecedentes de la invención

La transmisión en flujo continuo se refiere a la capacidad de una aplicación instalada en un cliente, de reproducir flujos continuos de medios sincronizados, como flujos continuos de audio y vídeo, de una manera continua mientras dichos flujos continuos están siendo transmitidos al cliente a través de una red de datos.

Las aplicaciones que se pueden construir sobre servicios de transmisión en flujo continuo se pueden clasificar en aplicaciones de distribución de información bajo demanda y en directo. Son ejemplos de la primera categoría las aplicaciones musicales y de noticias bajo demanda. La distribución en directo de programas de radio y televisión es un ejemplo de la segunda categoría.

La transmisión en flujo continuo a través de redes del Protocolo de Internet (IP) fijo es ya una aplicación importante en la actualidad. Aunque el Grupo de Trabajo de Ingeniería de Internet (IETF) y el Consorcio de la Red Informática Mundial (W3C) han desarrollado un conjunto de protocolos usados en servicios de transmisión en flujo continuo de IP fijo, todavía no se ha definido ningún marco completo de transmisión en flujo continuo normalizada. Para sistemas de comunicaciones móviles de la Tercera Generación (3G), según las normas desarrolladas por el Proyecto de Asociación de Tercera Generación (3GPP), el Servicio de Transmisión en Flujo Continuo por Conmutación de Paquetes 3G (PSS,TS 26.233 del 3GPP) llena el hueco entre el Servicio de Mensajería Multimedia (MMS) 3G, por ejemplo la descarga de aplicaciones, y servicios conversacionales.

El PSS permite aplicaciones de transmisión en flujo continuo para móviles, en donde la complejidad de los terminales es inferior a la requerida para servicios conversacionales, ya que no se requieren dispositivos de entrada de medios y codificadores, y se pueden usar protocolos menos complejos. El PSS incluye un conjunto básico de protocolos de control de transmisión en flujo continuo, protocolos de transporte, códecs de medios y protocolos de descripción de escenas.

La figura 1 representa esquemáticamente la pila de protocolos 1 del PSS que controla la transferencia de contenido tanto transmisible como no transmisible en flujo continuo entre un servidor de contenidos o medios y un cliente.

El contenido transmisible en flujo continuo 101, tal como vídeo, audio y voz, se convierte en primer lugar al formato de la carga útil del Protocolo de Transporte en Tiempo Real (RTP) 102 en una capa de adaptación 103. Dicho RTP, según lo define el IETF, proporciona medios para enviar datos en tiempo real o de flujo continuo usando los servicios de un Protocolo de Datagrama de Usuario (UDP) 104 subyacente, el cual a su vez usa los servicios de un Protocolo de Internet (IP) 105 subyacente.

El contenido no transmisible en flujo continuo 106, como, por ejemplo, imágenes fijas, gráficos en mapas de bits y vectoriales, texto, texto sincronizado y audio sintetizado, es transferido por medio del Protocolo de Transferencia de Hipertexto (HTTP) 107, que usa los servicios del Protocolo de Control de Transporte (TCP) 108 subyacente y el IP 105 subyacente adicional.

Mientras que para el contenido no transmisible en flujo continuo 106, las capacidades incorporadas de establecimiento y control de sesiones del HTTP 107 son suficientes para transferir el contenido, en caso del contenido transmisible en flujo continuo 101, se debe invocar un protocolo avanzado de establecimiento y control de sesiones, por ejemplo para iniciar, detener y pausar un vídeo en flujo continuo que es transferido desde el servidor de contenido al cliente por medio del RTP/UDP/IP. Esta tarea la lleva a cabo el Protocolo de Flujo Continuo en Tiempo Real (RTSP) 109, el cual puede usar o bien el TCP subyacente 108 ó bien el UDP subyacente 104. El RTSP requiere una descripción de presentación 110 por lo menos para establecer una sesión de flujo continuo. Dicha descripción de presentación 110 puede estar disponible, por ejemplo, en forma de un archivo del Protocolo de Descripción de Sesión (SDP). Dicho archivo de SDP contiene la descripción de la sesión, por ejemplo nombre y autor de la sesión, el tipo de medios que se deben presentar, información para recibir dichos medios, como, por ejemplo, direcciones, puertos, formatos y otros, y la velocidad de bits de los medios.

Si se va a visionar contenido de flujo continuo en el lado del cliente, por ejemplo en un terminal móvil, al usuario de dicho terminal se le proporciona primero un Identificador Universal de Recursos (URI) para contenido específico que

10

15

20

25

30

35

40

45

50

55

60

65 E04710443

01-10-2014

se adecue a su terminal. Este URI puede provenir de un servidor de WWW, de un servidor de Protocolo de Aplicaciones Inalámbricas (WAP), o puede haber sido introducido manualmente por medio del teclado del terminal. Este URI especifica un servidor de flujo continuo o de RTSP y la dirección del contenido en ese u otro servidor de contenido. El archivo de SDP correspondiente se puede obtener a continuación de varias maneras. Se puede proporcionar en un enlace dentro de la página HTML que descarga el usuario, por ejemplo por medio de una etiqueta incrustar (embed), o también se puede obtener directamente tecleándolo como un URI. A continuación, el archivo de SDP, es decir la descripción de presentación 110, se transfiere por medio del HTTP 107, tal como se indica en la columna central de la pila de protocolos de la figura 1. Alternativamente, se puede obtener también a través de señalización de RTSP 109, por ejemplo usando el método DESCRIBE del RTSP 109, según se indica por medio de la columna derecha de la pila de protocolos de la figura 1. Obsérvese que la descripción de presentación también se puede transmitir adecuadamente mediante dicho RTP 102. No obstante, para simplificar la presentación, esta posibilidad no se incluyó en la figura 1.

El establecimiento de sucesión sucesivo es el proceso en el cual el navegador o el usuario del terminal móvil invoca a un cliente de flujo continuo para establecer la sesión con respecto al servidor de contenido. Se espera que el terminal disponga de un portador de radiocomunicaciones activo que permita la transmisión de paquetes basada en IP en el inicio de la señalización del establecimiento de la sesión.

El establecimiento posterior del servicio de transmisión en flujo continuo se realiza enviando un mensaje SETUP RTSP para cada flujo continuo de medios seleccionado por el cliente. Esto devuelve el puerto de UDP 104 y/o de TCP 108 a usar para el flujo continuo respectivo de medios. El cliente envía un mensaje PLAY RTSP al servidor de contenido que a continuación comienza a enviar uno o más flujos continuos a través de la red IP.

Para ofrecer a los proveedores de servicios en sistemas de PSS medios para evaluar la experiencia del usuario final en la transmisión en flujo continuo, en los sistemas de PSS se han introducido factores de medición de la calidad de servicio del flujo continuo, según se presenta en el Documento Técnico (Tdoc) del 3GPP S4-030860: “Draft Rel-6 PSS Quality Metrics Permanent Document v.0.10”, que remite a la 29ª reunión del 3GPP TSG-SA4 en Tampere, Finlandia, del 24 al 28 de Noviembre de 2003. El cliente de flujo continuo mide y retroalimenta información sobre la calidad de la aplicación de flujo continuo concreta a un servidor de flujo continuo, en donde dicha calidad se define en términos de dichos factores de medición de calidad. Dicho servidor de flujo continuo puede ser, por ejemplo, un servidor de RTSP, y dichos factores de medición de calidad se pueden transportar, por ejemplo, usando dicho RTSP y SDP.

Puesto que el servicio es transparente para el tipo de RAN y CN, los factores de medición de calidad de PSS únicamente tienen un impacto en el cliente de flujo continuo y el servidor de flujo continuo. Una de las consecuencias de esto es que las mediciones no se pueden fundamentar en información de capas de protocolos por debajo de la capa de RTP (por ejemplo, UDP, IP, PDCP, RLC).

El terminal en un sistema de PSS con retroalimentación de calidad es responsable de llevar a cabo las mediciones de calidad de acuerdo con la definición de las mediciones, de añadirlas en los factores de medición de calidad de los clientes de flujo continuo y de notificar los factores de medición al servidor de flujo continuo. Este requisito no excluye la posibilidad de que el cliente de flujo continuo notifique mediciones de calidad sin procesar que van a ser procesadas por el servidor de flujo continuo en factores de medición de calidad.

El servidor de flujo continuo es responsable de señalizar la activación de los informes de los factores de medición de calidad del cliente de flujo continuo y de recopilar los factores de medición de calidad del cliente de flujo continuo. El servidor de flujo continuo puede procesar los factores de medición de calidad recibidos del cliente de flujo continuo para construir factores de medición de calidad acumulados. Por ejemplo, podría recibir una notificación de paquetes perdidos sin procesar y construir la tasa de pérdida de paquetes mínima, máxima, media y estándar para un cliente de flujo continuo particular.

El objetivo de la definición de los factores de medición de calidad es obtener mediciones homogéneas en cuanto al tipo de contenido, los terminales, y los tipos de Red de Acceso de Radiocomunicaciones (RAN).

Las restricciones consisten en minimizar el tamaño del informe de factores de medición de calidad que se enviará al servidor de flujo continuo y la complejidad del terminal.

Los factores de medición de calidad se pueden dividir en 3 tipos diferentes:

Un primer conjunto de factores de medición se calcula a partir de mediciones de calidad de medios basadas en el terminal (medidas dentro del decodificador o predichas en la entrada del decodificador), por ejemplo, la duración de la alteración, que se define como el tiempo desde el inicio de la primera trama decodificada alterada de medios (audio/voz/vídeo) hasta el inicio de la primera trama buena decodificada sucesiva o el final del periodo de notificación de informes (lo que se produzca antes), sin incluir las congelaciones/espacios vacíos de almacenamiento y las congelaciones/espacios vacíos de las pausas.

E04710443

01-10-2014

Un segundo conjunto de factores de medición es calculado por el terminal sobre la base del protocolo de PSS general y el funcionamiento del reproductor que reproduce la aplicación de flujo continuo. Por ejemplo una terminación anormal de una sesión.

5 Un tercer conjunto de factores de medición de calidad se calcula basándose en características de la red medidas en el terminal, por ejemplo, el número de paquetes perdidos de forma sucesiva.

Tal como ya se ha mencionado, en sistemas de PSS se usa el RTSP para la retroalimentación de informes de calidad de acuerdo con los factores de medición de calidad. La figura 2a enumera la definición de un

10 encabezamiento de unidad de datos 2a FactoresMedición-QoE (QoE-Metrics) del protocolo RTSP para la negociación de los factores de medición de calidad entre el cliente de flujo continuo y el servidor de flujo continuo, y la figura 2b enumera la definición de un encabezamiento de unidad de datos 2b Retroalimentación-QoE (QoE-Feedback) del protocolo RTSP para la retroalimentación real de factores de medición de calidad desde el cliente de flujo continuo al servidor, en donde QoE significa “Calidad de la Experiencia”.

15 El encabezamiento de negociación 2a de la figura 2a se puede usar de dos maneras:

1. Si se usa solamente el parámetro Off, esto es una indicación de que o bien el servidor de flujo continuo o bien

el cliente de flujo continuo desea anular la monitorización y la notificación de informes de factores de 20 medición de calidad.

2. Si el encabezamiento 2a contiene otros parámetros, entonces se solicita que comience la transmisión de factores de medición de calidad (o que vuelva a comenzar en caso de una monitorización en medio de la sesión).

25 Si el encabezamiento de negociación 2a se usa con la información del url de Control de Sesión de RTSP, entonces se usa el QoE-Metrics en el nivel de la sesión. Si el url es un url de Control de Medios de RTSP, entonces se usa el QoE-Metrics en el nivel de los medios y cada uno de los medios obtiene su propia línea de QoE-Metrics.

30 Es necesario fijar la velocidad de envío. Si el valor de Velocidad-envío (Sending-rate) es 0, entonces el cliente de flujo continuo puede enviar mensajes de retroalimentación en cualquier momento en función de los acontecimientos que se produzcan en el cliente de flujo continuo. Valores ≥ 1 indican un intervalo preciso de envío de mensajes. El intervalo más corto es una vez por segundo y el intervalo más largo no está definido. El intervalo de envío de retroalimentación puede ser diferente para un medio diferente, aunque se recomienda mantener algún tipo de

35 sincronización, para evitar tráfico adicional en la dirección del enlace ascendente. El valor Fin (End) indica que solamente se envía un mensaje al final de la sesión. El campo Margen (Range) se puede usar para definir el límite de tiempo del envío de la retroalimentación. De esta manera es posible decidir el margen de tiempo de monitorización durante la fase de negociación.

40 La retroalimentación concreta de los factores de medición de calidad se puede transportar al servidor de PSS usando el método SET_PARAMETER de RTSP con el encabezamiento de retroalimentación 2b de la figura 2b.

En el encabezamiento de retroalimentación 2b de la figura 2b, url-Flujo continuo (Stream-url) es el identificador URL de control de medios o de sesión RTSP para el parámetro de retroalimentación. El campo Factores de Medición 45 (Metrics) en la definición de Parámetros (Parameters) contiene el nombre de los factores de medición/las mediciones (por ejemplo, duración de la alteración, etcétera) y será igual que el campo de Factores de Medición del encabezamiento QoE de negociación 2a (Factores de Medición-QoE). Se recomienda mantener igual el orden de los factores de medición para simplificar el análisis sintáctico. El campo Valor (Value) indica los resultados. Existe la posibilidad de que el mismo acontecimiento se produzca más de una vez durante un periodo de monitorización. En

50 ese caso, el factor de medición valor puede producirse más de una vez, lo cual indica el número de acontecimientos al servidor. La Indicación de Tiempo (Timestamp) opcional indica el momento en el que se produjo el acontecimiento (o medición) o en el que se calculó el factor de medición desde el comienzo de la sesión. Además, puede no notificarse ningún acontecimiento (usando el SP-espacio). El Margen (Range) opcional indica el periodo de notificación de informes.

55 La notificación de informes de factores de medición de la calidad la efectúa normalmente el cliente de PSS usando el método SET_PARAMETER del RTSP. No obstante, en casos particulares, resulta más eficiente usar otros métodos para transportar la información, como, por ejemplo, el mensaje TEARDOWN o el mensaje PAUSE.

60 Volviendo a la definición antes mencionada de la duración de la alteración en los factores de medición de la calidad, como ejemplo representativo de un primer conjunto de factores de medición de la calidad que se calculan a partir de mediciones de la calidad de medios basadas en el terminal, se observa fácilmente que, aparte de la dependencia de esta definición de factores de medición de la calidad con respecto a la definición adicional de una “alteración” y un “periodo de notificación de informes”, esta definición de factores de medición de la calidad depende en particular de

65 una definición de una “trama buena”.

15

25

35

45

55

65 E04710443

01-10-2014

Una trama buena es una trama decodificada de medios (audio/voz/vídeo) que no está alterada, es decir, que no contiene ningún tramo congelado/hueco vacío o deterioro de la calidad. Para declarar una trama de vídeo o audio como buena, en el Tdoc S4-030860, se introduce la siguiente definición: “una trama buena es la primera de N tramas después de la última pérdida o de una trama I completa, donde N o bien está (a) señalizado o bien (b) adopta por defecto el valor de ∞ (para vídeo) o de 1 (para audio)”.

La aplicación de esta definición no es obligatoria, lo cual da como resultado una amplia gama de interpretaciones de la definición de trama buena. De este modo, diferentes clientes de flujo continuo pueden notificar informes de diferentes calidades de la transmisión en flujo continuo, ya que, para el mismo factor de medición de la calidad (por ejemplo, duración de la alteración), se aplican definiciones diferentes para una “trama buena”. Surge una ambigüedad similar cuando terminales diferentes usan algoritmos diferentes de seguimiento de errores, de manera que, incluso cuando se usa la misma definición de “trama buena”, la calidad de flujo continuo notificada en términos del mismo factor de medición de calidad puede diferir entre los terminales. Estas ambigüedades provocan que los factores de medición de calidad notificados resulten imprecisos y efectivamente inútiles.

Sumario de la invención

A partir de los problemas mencionados anteriormente, es un objetivo, entre otros, de la presente invención proporcionar un método, un programa de ordenador, un producto de programa de ordenador, un sistema, un cliente, un servidor y un protocolo que permitan una notificación de informes mejorada, en particular más significativa, de la calidad de una transmisión en flujo continuo.

Se propone un método para notificar informes de la calidad de una transmisión en flujo continuo según la reivindicación 1.

Dicho por lo menos un flujo continuo de medios puede contener, por ejemplo, información de vídeo, audio o voz que se transmite de forma continua desde un servidor, por ejemplo un servidor de contenido, a dicho cliente y es reproducida en el terminal, en el cual está establecido dicho cliente, de una manera sincronizada. Esta transmisión en flujo continuo puede tener lugar en una sesión de flujo continuo, en donde varios flujos continuos de medios se pueden transmitir simultáneamente en flujo continuo a dicho cliente. Dicha transmisión en flujo continuo es controlada por dicho protocolo, por ejemplo, un protocolo de transmisión en flujo continuo como el RTSP, y puede permitir, por ejemplo, iniciar, detener y/o pausar la transmisión en flujo continuo. Dicho RTSP es explotado por entidades de protocolo en dicho cliente y en dicho servidor y se puede basar en un SDP. Dicho servidor puede estar ubicado conjuntamente con el servidor de contenido desde el cual proceden realmente dichos medios continuos o incluso puede ser idéntico a este último, o puede ser una instancia diferente. La calidad de dicha transmisión en flujo continuo se determina en el emplazamiento del cliente de acuerdo con dicho por lo menos un factor de medición de calidad, tal como, por ejemplo, una duración de la alteración o un acontecimiento de realmacenamiento intermedio. La clase de dichos factores de medición de la calidad define, por lo menos parcialmente, cómo debe determinarse dicho por lo menos un factor de medición de la calidad. Por ejemplo, si dicho por lo menos un factor de medición de la calidad depende de la decisión de si una trama de dicho flujo continuo de medios es una trama buena, dicha clase de factores de medición de la calidad puede definir cómo debe tomarse esta decisión. Dicho factor de medición de la calidad puede ser, por ejemplo, una duración de la alteración, en donde dicha duración de la alteración se puede definir como el tiempo entre una trama alterada y la siguiente trama buena.

Dicho conjunto de por lo menos dos clases de factores de medición de la calidad está predefinido. En dicha etapa de selección, por lo menos dicho cliente o dicho servidor seleccionan por lo menos un factor de medición de calidad, por ejemplo a partir de un conjunto predefinido de factores de medición de la calidad, y por lo menos dicho cliente o dicho servidor seleccionan una clase de factores de medición de la calidad a partir de dicho conjunto predefinido de por lo menos dos clases de factores de medición de la calidad definidas. Dichas clases de factores de medición de la calidad se pueden basar, por ejemplo, en un algoritmo de seguimiento de errores o en un algoritmo de evaluación de la calidad de codificación. Dichos conjuntos predefinidos se pueden definir, por ejemplo, dentro de un RTSP y/o un SDP. Dicha selección comprende la negociación entre dicho cliente y servidor sobre por lo menos uno de dichos factores de medición de la calidad y una clase de factores de medición de la calidad. Dicha negociación se puede realizar entre dicho cliente y servidor a través de dicho protocolo, por ejemplo el RTSP y el SDP. Sobre la base de dicho por lo menos un factor de medición de calidad seleccionado y de dicha por lo menos una clase de factores de medición de la calidad, a continuación dicho cliente notifica un informe de dicha calidad de dicha transmisión en flujo continuo a dicho servidor.

Así, según un primer aspecto de la presente invención, la incorporación de clases adicionales de factores de medición de la calidad restringe la interpretación de las definiciones de los factores de medición de la calidad y contribuye por lo tanto a hacer que los informes de calidad sean más significativos y concisos. De acuerdo con un segundo aspecto de la presente invención, la incorporación de dichas clases adicionales de factores de medición de la calidad añade un grado de libertad adicional en la definición de factores de medición de la calidad. Por ejemplo, si una duración de una alteración, que, entre otros factores, depende de la decisión de si tramas de dicho flujo continuo de medios son tramas buenas o tramas alteradas, se selecciona como factor de medición de la calidad, este factor de medición de la calidad se puede especializar adicionalmente mediante la selección de la clase del factor de

15

25

35

45

55

65 E04710443

01-10-2014

medición de la calidad, la cual puede proporcionar, por ejemplo, una variedad de definiciones de una trama buena. Así, sin perder concisión del propio factor de medición de la calidad, puesto que cada definición de una buena trama de acuerdo con la clase del factor de medición de la calidad está preestablecida de manera fija, se extiende el alcance de aplicación del factor de medición de la calidad.

Dicha negociación se puede basar en dicho protocolo que controla también dicha transmisión en flujo continuo, por ejemplo, RTSP en combinación con SDP, y puede comprender además la negociación de dicho por lo menos un factor de medición de la calidad.

De acuerdo con el método de la presente invención, puede que se prefiera que dicho protocolo defina un campo de clase de factores de medición de la calidad dentro de por lo menos una de sus unidades de datos de protocolo, en donde dicho campo de clase de factores de medición de la calidad tiene la capacidad de identificar cada clase de factores de medición de la calidad de dicho conjunto predefinido de por lo menos dos clases de factores de medición de la calidad. A cada clase de factores de medición de la calidad se le puede asignar, por ejemplo, un número exclusivo, y dicho campo de clase de factores de medición de la calidad contiene entonces el número de la clase de factores de medición de la calidad que ha sido seleccionado. De manera similar, dichas unidades de datos de protocolo pueden contener además un campo para la identificación de dicho por lo menos un factor de medición de la calidad seleccionado y un campo para transportar un valor de retroalimentación que se ha determinado de acuerdo con dicho por lo menos un factor de medición de la calidad y dicha clase de factores de medición de la calidad. Dicha unidad de datos de protocolo puede ser o bien una unidad de datos de protocolo para negociación o bien una unidad de datos de protocolo para retroalimentación. Puede ser suficiente con la señalización de dicha clase de factores de medición de calidad seleccionada durante la negociación, de manera que puede que no se requieran campos en las unidades de datos de protocolo de retroalimentación. Dicho campo puede ser un campo opcional o un campo obligatorio en dichas unidades de datos de protocolo.

De acuerdo con el método de la presente invención, puede que se prefiera que dicho campo de clase de factores de medición de la calidad esté ubicado en una sección de encabezamiento de dicha por lo menos una unidad de datos de protocolo. Alternativamente, también puede estar comprendido en la sección de carga útil de dicha por lo menos una unidad de datos de protocolo.

De acuerdo con el método de la presente invención, puede que se prefiera que dicho conjunto de reglas definido por al menos una de dichas clases de factores de medición de la calidad comprenda decidir que la primera de una trama I recibida completamente de dicho por lo menos un flujo continuo de medios o la N-ésima trama recibida completamente de dicho por lo menos un flujo continuo de medios, después del último error o pérdida, es una trama buena, en donde el entero N o bien se señaliza o bien adopta por defecto ∞ en caso de una trama de vídeo o 1 en caso de una trama de audio, y decidir que una trama de dicho por lo menos un flujo continuo de medios tras una trama buena es una trama buena, si dicha trama se recibe completamente, y, si no, que dicha trama y todas las tramas sucesivas hasta la siguiente trama nueva están alteradas. Dicha trama I puede ser, por ejemplo, una trama dentro de un flujo continuo de vídeo codificado en donde dicha trama contiene la información de píxeles completa. En el caso de los códecs H.264 o de Codificación de Vídeo Avanzada (AVC) MPEG-4, dicha trama I representa una trama IDR. Si dicho cliente puede obtener el valor realmente requerido de N a partir de información adicional, por ejemplo, información obtenida a partir del mensaje de Información de Mejora Suplementaria (SEI) del punto de recuperación de AVC, para el vídeo AVC, ese valor puede invalidar el valor señalizado o por defecto de N. Puede apreciarse que dicha trama se ha recibido completamente si todos los bits que codifican dicha trama son recibidos correctamente y no se ha producido ningún error de bit.

Según el método de la presente invención, puede que se prefiera que dicho conjunto de reglas definidas por al menos una de dichas clases de factores de medición de la calidad comprenda decidir que una trama codificada de dicho por lo menos un flujo continuo de medios es una trama buena sobre la base de un algoritmo de seguimiento de errores.

Según el método de la presente invención, puede que se prefiera que dicho conjunto de reglas definidas por al menos una de dichas clases de factores de medición de la calidad comprenda decidir que una trama intracodificada de dicho por lo menos un flujo continuo de medios es una trama buena, si la misma se recibe completamente en dicho cliente, y que, en caso contrario, es una trama alterada, o decidir que una trama con codificación predictiva de dicho por lo menos un flujo continuo de medios es una trama buena, si la misma se recibe completamente en dicho cliente y si todas sus muestras de referencia de predicción pertenecen a tramas buenas, y, en caso contrario, es una trama alterada. Dichas tramas intracodificadas, para vídeo, pueden entenderse como tramas sin predicción temporal compensada por movimiento, aunque posiblemente con eliminación de redundancia espacial dentro de la trama, y dichas tramas con codificación predictiva, para vídeo, pueden interpretarse como tramas con predicción temporal compensada por movimiento para reducir la redundancia temporal sacando provecho de la fuerte correlación entre las tramas de vídeo. Dichas muestras de referencia de predicción pueden ser, por ejemplo, píxeles de referencia de predicción en el caso del vídeo.

Según el método de la presente invención, puede que se prefiera que dicho conjunto de reglas definidas por al menos una de dichas clases de factores de medición de la calidad comprenda decidir que una trama codificada de

15

25

35

45

55

65 E04710443

01-10-2014

dicho por lo menos un medio continuo es una trama buena de acuerdo con un algoritmo de evaluación de la calidad de decodificación.

Según el método de la presente invención, puede que se prefiera que dicho conjunto de reglas definidas por al menos una de dichas clases de factores de medición de la calidad comprenda decidir que una trama intracodificada de dicho por lo menos un flujo continuo de medios es una trama buena, si la misma se recibe completamente en dicho cliente, y que, en caso contrario, es una trama alterada, o decidir que una trama con codificación predictiva de dicho por lo menos un flujo continuo de medios es una trama buena, si la misma se recibe completamente en dicho cliente y todas sus muestras de referencia de predicción pertenecen a tramas buenas, o si por lo menos una parte de dicha trama se recibe completamente, todas las muestras de referencia de predicción, por ejemplo píxeles de referencia para el vídeo, de dichas partes recibidas completamente de dicha trama pertenecen a tramas buenas, y todas las partes ocultadas de dicha trama se consideran como buenas, en donde partes ocultadas de dicha trama se obtienen aplicando un algoritmo de ocultación de errores a partes perdidas o erróneas de una versión decodificada de dicha trama, y en donde dichas partes ocultadas se consideran como buenas si una diferencia delimitadora media entre dichas partes ocultadas y partes circundantes decodificadas y recibidas completamente de dicha trama está por debajo de un umbral. Dicha ocultación puede comprender, por ejemplo, la estimación de la reconstrucción de píxeles perdidos o erróneos sobre la base de vecinos espaciales y/o temporales de dichos píxeles. Dicha diferencia delimitadora media puede cuantificar una suma de diferencias de luminancia entre píxeles en los bordes de partes ocultadas. Dicho umbral puede ser igual, por ejemplo, a 3.

Según el método de la presente invención, puede que se prefiera que dicho protocolo sea un Protocolo de Flujo Continuo en Tiempo Real RTSP en combinación con un Protocolo de Descripción de Sesión SDP en el contexto de un Servicio de Flujo Continuo por Conmutación de Paquetes PSS de un sistema de comunicaciones móviles de tercera generación. Dicho SDP puede proporcionar, por ejemplo, la descripción de la presentación que requiere el RTSP con el fin de controlar dicha transmisión en flujo continuo.

De acuerdo con el método de la presente invención, puede que se prefiera que dicho SDP comprenda por lo menos un atributo de SDP que define por lo menos un campo de clase de factores de medición de la calidad, en donde dicho campo de clase de factores de medición de la calidad tiene la capacidad de identificar cada clase de factores de medición de la calidad de dicho conjunto predefinido de por lo menos dos clases de factores de medición de la calidad. A cada clase de factores de medición de la calidad se le puede asignar, por ejemplo, un número exclusivo, y dicho campo de clase de factores de medición de la calidad contiene entonces el número de la clase de factores de medición de la calidad que ha sido seleccionada. De manera similar, dicho atributo de SDP puede contener además un campo para la identificación de dicho por lo menos un factor de medición de la calidad seleccionado.

Según el método de la presente invención, puede que se prefiera que dicho RTSP se use para negociar una clase de factores de medición de la calidad entre dicho cliente y dicho servidor por lo menos parcialmente sobre la base de dicho atributo de SDP. El SDP se puede usar, por ejemplo, para iniciar la negociación de factores de medición de la calidad y clases de factores de medición de la calidad. Resulta entonces ventajoso añadir dicho campo al atributo de SDP que se usa para la iniciación de la negociación.

Según el método de la presente invención, puede que se prefiera que dicho RTSP use un método DESCRIBE para dicha negociación. Dicha negociación puede ser, por ejemplo, iniciada mediante el uso de dicho método DESCRIBE RTSP en combinación con dicho atributo de SDP.

Se propone además un programa de ordenador con instrucciones que se pueden hacer funcionar para conseguir que un procesador lleve a cabo las etapas de método antes mencionadas. Dicho programa de ordenador se puede ejecutar, por ejemplo, en un procesador que esté integrado o bien en dicho cliente o bien en dicho servidor.

Se propone además un producto de programa de ordenador que comprende un programa de ordenador con instrucciones que se pueden hacer funcionar para conseguir que un procesador lleve a cabo las etapas de método antes mencionadas.

Se propone además un método según la reivindicación 13, un sistema de transmisión en flujo continuo según la reivindicación 16, un cliente en un sistema de transmisión en flujo continuo según la reivindicación 17, un servidor en un sistema de transmisión en flujo continuo según la reivindicación 18 y un protocolo para un sistema de transmisión en flujo continuo según la reivindicación 19.

Estos y otros aspectos de la invención se pondrán de manifiesto a partir de las formas de realización descritas en la presente memoria a continuación y haciendo referencia a las mismas.

Breve descripción de las figuras

En las figuras mostradas:

Figura 1: Una representación esquemática de una pila de protocolos del Servicio de Flujo Continuo por

15

25

35

45

55

65 E04710443

01-10-2014

Conmutación de Paquetes (PSS) según la técnica anterior,

Figura 2a: una definición de un encabezamiento de negociación del Protocolo de Flujo Continuo en Tiempo Real (RTSP) según la técnica anterior,

Figura 2b: una definición de un encabezamiento de retroalimentación del RTSP según la técnica anterior,

Figura 3: una definición de un encabezamiento modificado de negociación del RTSP según la presente invención,

Figura 4: un mapa de estados ejemplificativo de MacroBloques (MB) para un algoritmo de ocultación de errores según la presente invención,

Figura 5: una ilustración de un método para el cálculo de una diferencia delimitadora media según la presente invención,

Figura 6: un diagrama de flujo del método de la presente invención, y

Figura 7: una representación esquemática de un sistema según la presente invención.

Descripción detallada de la invención

Para la presente invención, se siguen aplicando la pila de protocolos de la figura 1 y el encabezamiento RTSP de retroalimentación que se define en la figura 2b. No obstante, se define un encabezamiento modificado de negociación RTSP 3, según se enumera en la figura 3.

El encabezamiento modificado de negociación RTSP de la figura 3 proporciona un campo RTSP adicional Metricsclass, el cual puede presentar uno de los siguientes valores “0”, “1” ó “2”.

Así, durante la negociación entre el cliente de flujo continuo y el servidor de flujo continuo, no solamente se acuerda el factor de medición de la calidad que se va a usar en la posterior retroalimentación de calidad del cliente de flujo continuo, utilizando el campo RTSP Factores de Medición (Metrics) del encabezamiento modificado de negociación RTSP 3 de la figura 3, sino que también la clase de factores de medición de la calidad se negocia utilizando el campo RTSP Metrics-class.

Si se usa el SDP para iniciar la negociación de los factores de medición de QoE, el campo Metrics-class también se puede añadir al atributo de SDP que se usa para el inicio de la negociación de QoE.

La presente invención propone tres métodos diferentes para determinar si las tramas del flujo continuo de medios que se transmite por flujo continuo al cliente de flujo continuo son tramas buenas (en caso contrario, se consideran como tramas alteradas). Cada uno de dichos métodos respectivo queda identificado de forma exclusiva por uno de los valores “0”, “1” y “2” que se puede asignar al campo RTSP Metrics-class. Suponiendo que el factor de medición de la calidad se basa al menos parcialmente en la decisión de si las tramas son tramas buenas o alteradas, por ejemplo si el factor de medición de la calidad es la duración de una alteración, el contenido de información total del factor de medición de calidad que se somete al método de determinación de acuerdo con la clase seleccionada de factores de medición de la calidad es mucho más conciso y significativo. Además, se logra una especialización del factor de medición de la calidad, puesto que cada factor de medición de la calidad basado por lo menos parcialmente en una decisión de trama buena se divide entonces en tres factores de medición de calidad, cada uno de ellos con un método diferente de determinación de tramas buenas.

A continuación en la presente memoria, se describirán los tres métodos de determinación que propone la presente invención.

Primer método de determinación

El primer método es similar al descrito en el Tdoc S4-030860, con algunas modificaciones de mejora. Se describe de la manera siguiente:

Una trama buena es la primera de 1) una trama I (para vídeo H.264 o de Codificación de Vídeo Avanzada (AVC) MPEG-4, trama IDR) completamente recibida, o 2) la N-ésima trama completamente recibida después del último error o pérdida, donde N o bien está señalizado o bien adopta por defecto el valor ∞ (para vídeo) o 1 (para audio). Si el cliente puede obtener el valor realmente requerido de N a partir de información adicional, por ejemplo, información obtenida a partir del mensaje de Información de Mejora Suplementaria (SEI) del punto de recuperación de AVC para el vídeo AVC, ese valor invalida el valor antes especificado. “Completamente recibida” significa que se reciben todos los bits y que no se produce ningún error de bit.

15

25

35

45

55

65 E04710443

01-10-2014

Si una trama que sucede a una trama buena se recibe completamente, la misma es una trama buena. En caso contrario, todas las tramas sucesivas desde la trama en cuestión (ésta incluida) hasta la siguiente trama buena (excluida) son tramas alteradas.

Segundo método de determinación

El segundo método se caracteriza por aplicar un algoritmo de seguimiento de errores. A continuación se describe una posible forma de realización del segundo método:

Para una trama intracodificada, si la misma es recibida completamente, se trata de una trama buena. En caso contrario, es una trama alterada.

Para una trama con codificación predictiva, si la misma se recibe completamente y todas sus muestras de referencia de predicción pertenecen a tramas buenas, se trata de una trama buena. En caso contrario, es una trama alterada.

Tercer método de determinación

El tercer método se caracteriza por aplicar un cierto algoritmo de evaluación de la calidad de decodificación. En la continuación se describirá una posible forma de realización del método de determinación.

La instancia del tercer método se basa por lo menos parcialmente en la ocultación de partes perdidas o erróneas de una trama con codificación predictiva. Así, un paréntesis en la estrategia aplicada de ocultación de errores de la trama con codificación predictiva debe preceder a la presentación de la instancia del tercer método.

Se supone que partes erróneas o incompletas de una trama no se decodifican sino que son descartadas antes de la decodificación, con lo cual no se lleva a cabo ninguna comprobación de integridad o detección de errores de bit. En primer lugar se decodifican todas las partes de una imagen recibidas correctamente, y a continuación se ocultan las partes perdidas. En la práctica, se mantiene un registro en un mapa de estados basado en macrobloques (MB), de la trama. El estado de un MB en el mapa de estados es “Recibido correctamente” siempre que la parte en la que reside el MB está disponible para ser decodificada, y, en caso contrario, es “Perdido”. Después de decodificar la trama, si el mapa de estados contiene MBs “Perdidos”, se inicia la ocultación.

Dada la estructura de partes recibidas correctamente y perdidas de una trama y el mapa de estados basado en MB de una trama, el algoritmo de ocultación aplicado está basado en MB. El área de trama (píxeles) ausente cubierta por MBs marcados como “Perdidos” en el mapa de estados se ocultan de MB en MB (16 x 16 píxeles Y, 8 x 8 píxeles U, V), en donde Y se refiere a luminancia y U y V se refieren a píxeles de crominancia. Después de que se haya ocultado un MB, el mismo se marca en el mapa de estados como “Ocultado”. No solamente los MBs “Recibidos correctamente” se tratan como vecinos fiables, sino también los “Ocultados”, en el proceso de ocultación siempre que no exista ningún vecino inmediato “Recibido correctamente” de un MB “Perdido”. En tal caso, un MB ocultado de manera insatisfactoria puede dar como resultado la propagación de este error de ocultación a varios MBs ocultados vecinos. Por lo tanto, el orden en el cual se ocultan MBs “Perdidos” es importante. El procesado comienza con columnas de MB en los límites de la trama y a continuación se mueve hacia dentro de columna en columna. Este orden de procesado ayuda a evitar un error de ocultación típico que se realiza en la parte central habitualmente “difícil” (áreas de movimiento discontinuo, error de predicción codificado grande) de la trama por la propagación a las partes “sencillas” (área de movimiento continuo, movimiento similar sobre varias tramas) de la trama.

La figura 4 muestra una instantánea del mapa de estados durante la fase de ocultación donde MBs ya ocultados 402 presentan el estado de “Ocultado”, MBs recibidos correctamente 403 presentan el estado de “Recibido”, MBs perdidos 400 presentan el estado “Perdido” y el MB que se está procesando en ese momento (que está siendo ocultado) 401 se marca como “MB Actual”. La figura 4 indica además un parte perdida 404, que únicamente puede estar compuesta por MBs ocultados 402 ó perdidos 400.

Solamente los MBs vecinos “Recibidos correctamente” 403 se usan para la ocultación si hay disponibles por lo menos dos de estos MBs. Si no, en la operación de promediado también se usan MBs “Ocultados” vecinos.

En lugar de actuar directamente en el dominio de los píxeles, un planteamiento más eficiente consiste en intentar “adivinar” el movimiento en el área de píxeles ausentes (MB) 400 mediante algunos esquemas de predicción a partir de información de movimiento disponible de vecinos espaciales o temporales. Este Vector de Movimiento (MV) “adivinado” se usa a continuación para la compensación del movimiento usando la trama de referencia.

Los valores de píxel copiados proporcionan los valores de píxel reconstruidos finales para la ocultación, y no se usan operaciones adicionales en el dominio de los píxeles.

En primer lugar se investiga la actividad de movimiento de las partes recibidas correctamente (grupos de MBs

15

25

35

45

55 E04710443

01-10-2014

recibidos correctamente 403) de la imagen actual. Si el MV medio es menor que un umbral predefinido (actualmente 1/4 píxeles para cada componente de MV), todas las partes perdidas 404 se ocultan mediante copia de las posiciones espacialmente correspondientes en la trama de referencia. En caso contrario, se usa una ocultación de errores compensada por movimiento, y los MVs de los MBs perdidos 400 se predicen tal como se describe en los siguientes párrafos.

El movimiento de un MB “Perdido” 400 se predice a partir del movimiento de un MB vecino espacial fundamentándose en la observación estadística de que el movimiento de áreas de trama espacialmente vecinas presenta una alta correlación. Por ejemplo, en un área de trama cubierta por un objeto de escena en primer plano en movimiento, el campo de MV es continuo, lo cual significa que es sencillo de predecir.

El MV de un MB “Perdido” 400 se predice a partir de uno de los MBs vecinos (o bloques 8 x 8). Este planteamiento supone que el MV de uno de los MBs (o bloques) vecinos modela el movimiento en el MB actual adecuadamente. Se observó en experimentos previos que la mediana o el promediado sobre MVs de todos los vecinos no proporcionaba resultados mejores. Para simplificar, en la implementación actual, el tamaño de bloque vecino más pequeño que se considera de forma independiente como predicción se fija a 8 x 8 píxeles Y. El movimiento de cualquier bloque 8 x 8 se calcula como la media del movimiento de los bloques espacialmente correspondientes de 4 x 4 o con cualquier otra forma (por ejemplo, 4 x 8).

La decisión sobre el MV de qué vecino usar como predicción para el MB actual 500 se toma basándose en la uniformidad de lo ocultado (reconstruido) y se explicará en referencia a la figura 5. Durante este procedimiento de ensayo, los valores de píxeles de ocultación de MB 500 se calculan usando el MV 501a-d de cada candidato (valores de píxel compensados por movimiento). Se selecciona el MV 501a-d que da como resultado el cambio de luminancia más pequeño cruzando los límites de bloques 502a-d cuando el bloque 500 se inserta en su lugar en la trama. Se considera siempre el caso de MV cero y esta ocultación por copia (copiar valores de píxeles del MB espacialmente correspondiente en la trama de referencia) se evalúa de manera similar a otros candidatos de MV.

El MV de predicción ganador es aquel que minimiza la distorsión por coincidencias laterales (side match distortion) dsm, que es la suma de diferencias absolutas de valores de píxel Y del IN-bloque 503 y píxeles del OUT-bloque vecino 504 en los límites 502a-d del bloque actual 500, tal como se muestra en la ec. (1):

minarg 1 N INOUTl

∑j=1 lyYj Cmvdir)-Yj 〉 (1)

dir∈{sup,inf,izq,der}〈dsm = N

INOUT

donde Yyj Cmvdir) es el j-ésimo valor ocultado de Y en los IN-bloques 503 que usan mvdir para predecir el MV, e Yj es el j-ésimo valor de Y reconstruido en los OUT-bloques 504, y N es el número total de los píxeles delimitadores calculados.

Cuando existen MBs vecinos “Recibidos correctamente” 403, la distorsión por coincidencias laterales se calcula únicamente sobre ellos. Si no, en el cálculo se incluyen MBs vecinos “ocultados” 402. A continuación puede describirse de la manera siguiente una posible forma de realización del tercer método:

Para una trama intracodificada, si la misma se recibe completamente, se trata de una trama buena. Si no, se trata de una trama alterada.

Para una trama con codificación predictiva:

a) Si la misma se recibe completamente/correctamente y todas sus muestras de referencia de predicción pertenecen a tramas buenas, se trata de una trama buena.

b) Si por lo menos parte de la trama se recibe completamente/correctamente, y las muestras de referencia de predicción de partes recibidas completamente/correctamente pertenecen a tramas buenas, la determinación sobre la trama se realiza usando la etapa c. En caso contrario, la trama está alterada.

c) La trama se decodifica y las partes perdidas o erróneas se ocultan usando el algoritmo de ocultación de errores antes descrito. Si la diferencia delimitadora media, es decir, la distorsión por coincidencias laterales de la ec. (1), entre una parte ocultada y la parte circundada decodificada y recibida completamente/correctamente es menor que un umbral, la parte ocultada se considera como buena. Si todas las partes ocultadas son buenas, la trama es una trama buena. En caso contrario, la trama está alterada.

El umbral en este método se puede escoger, por ejemplo, de manera que sea igual a 3.

La figura 6 representa un diagrama de flujo del método para notificar informes de una calidad de transmisión de flujo continuo según la presente invención. Las etapas del método se representan mediante solicitudes y acuses de recibo que se intercambian entre un servidor de flujo continuo 600 y un cliente de flujo continuo 601, en donde

15

25

35

45

55

65 E04710443

01-10-2014

dichas solicitudes y acuses de recibo están sometidos al RTSP. Además, se observa fácilmente que las etapas del método se pueden clasificar en una etapa de negociación 602 y una etapa de retroalimentación 603.

La negociación de los Factores de Medición de la Calidad comienza con una respuesta 605 del servidor de flujo continuo 600 a una solicitud DESCRIBE 604 del cliente de flujo continuo 601. En dicha respuesta 605, se inserta por medio de datos del Protocolo de Descripción de Sesión (SDP) por lo menos un factor de medición de la calidad y una clase de factores de medición de la calidad según desee el servidor de flujo continuo 600 para la futura notificación de informes de calidad. Si el cliente de flujo continuo 601 presta soporte a los factores de medición de la calidad, entonces enviará una solicitud SETUP 606 que contiene el factor de medición de calidad y la clase de factores de medición de calidad seleccionados/modificados para o bien el nivel de sesión, o bien el nivel de medios, que se esté estableciendo.

Para que el cliente de flujo continuo 601 indique que se presta soporte a los factores de medición de la calidad tanto en el nivel de la sesión como en el nivel de los medios, el cliente puede enviar todos los factores de medición de la calidad soportados/modificados que están en relación con el nivel de los medios. También puede enviar los factores de medición de la calidad seleccionados, del nivel de sesión, en por lo menos una de las solicitudes SETUP. En la anterior solicitud SETUP 606, el cliente únicamente modifica la velocidad de envío de los factores de medición de la calidad para el URL de control en comparación con la descripción de SDP inicial contenida en la respuesta 605 del servidor 600.

Al recibir esta solicitud SETUP 606, el servidor de flujo continuo 600 devuelve la respuesta 200/OK 607 que contiene los factores de medición de calidad y la clase de factores de medición de calidad aceptados devueltos por el cliente de flujo continuo 601 (para volver a acusar recibo de los cambios). También puede rechazar los cambios realizados por el cliente de flujo continuo 601. Si el servidor de flujo continuo 600 rechaza los cambios, o bien puede fijar valores nuevos y volver a enviar los factores de medición de calidad y la clase de factores de medición de calidad modificados de vuelta al cliente de flujo continuo 601, o bien simplemente puede ignorar los factores de medición de calidad y la clase de factores de medición de calidad y no acusar su recibo.

Si el servidor de flujo continuo 600 no aprueba las modificaciones realizadas por el cliente de flujo continuo 601, pueden seguir renegociando hasta que la solicitud PLAY RTSP 608 y la respuesta PLAY RTSP 609 del servidor de flujo continuo 600 devuelvan el factor de medición de calidad y la clase de factores de medición de calidad negociados finales incluyendo todos los valores de los factores de medición al nivel de la sesión y de los medios.

A continuación, en por lo menos una etapa 610, se lleva a cabo la retroalimentación real de acuerdo con el factor de medición de calidad y la clase de factores de medición de calidad negociados, por ejemplo basándose en el encabezamiento de retroalimentación RTSP 2b según se define en la figura 2b.

Debería observarse que cada vez que se envía el campo de encabezamiento QoE-Metrics en una solicitud RTSP, el mismo también estará presente en la respuesta correspondiente a esa solicitud particular. Si no, el receptor de la respuesta supone que el otro extremo NO presta soporte para Factores de Medición de Calidad. Puede aplicarse lo mismo para el campo de encabezamiento QoE-Metrics-Class.

La figura 7 representa esquemáticamente los componentes funcionales de un sistema según la presente invención. El sistema de PSS comprende un cliente de flujo continuo 601 y un servidor de flujo continuo 600, en donde tanto el cliente 601 como el servidor 600 tienen por lo menos una entidad de RTSP 701, 700 que tiene la capacidad de funcionar con el RTSP. Las entidades de RTSP 700, 701 usan los servicios de capas de protocolos subyacentes que se hacen funcionar por medio entidades de protocolo adicionales, de entre las cuales se muestran únicamente las entidades de TCP/UDP 702, 703 y las entidades de IP 704, 705. El cliente de flujo continuo 601 está conectado además a una instancia de monitorización de la calidad de flujo continuo 707, la cual monitoriza la calidad de la aplicación de flujo continuo concreta en términos de los factores de medición de calidad y la clase de los factores de medición de calidad negociados e introduce valores de calidad monitorizada en dicha entidad de RTSP 701. Dicho monitorizador de la calidad de flujo continuo puede ser proporcionado por ejemplo por el terminal en el cual está establecido dicho cliente de flujo continuo. Por medio del RTSP, dichos valores de calidad monitorizados se transfieren a la entidad par de RTSP en el servidor de flujo continuo 600, donde los mismos se introducen en una instancia de procesado de datos de calidad 706 para ser evaluados y analizados, lo cual puede tener como objetivo, por ejemplo, perfeccionar la calidad de la aplicación de flujo continuo mejorando la velocidad de datos de la aplicación de flujo continuo si se observa que los acontecimientos de realmacenamiento intermedio resultan demasiado frecuentes.

La invención se ha descrito anteriormente por medio de una forma de realización preferida. Debería observarse que existen formas y variantes alternativas que resultan evidentes para el experto en la materia y que se pueden implementar sin desviarse con respecto al alcance de las reivindicaciones adjuntas. En particular, las clases de factores de medición de calidad se pueden usar para representar de manera más precisa la definición de cualquier factor de medición de calidad que esté basado, por lo menos parcialmente, en una decisión de trama buena, y al mismo tiempo permitir una especialización de dicho factor de medición de calidad. Por ejemplo, clases de factores de medición de calidad pueden proporcionar definiciones diferentes de lo que va a interpretarse bajo condiciones de

E04710443

01-10-2014

una alteración en sí misma, o pueden proporcionar definiciones para diferentes grados de alteraciones de la trama, que a continuación, en combinación con un factor de medición de calidad que depende por lo menos parcialmente de una definición de una alteración, permiten una notificación mucho más concisa de informes de la calidad de flujo continuo. El alcance de la presente invención no queda limitado en modo alguno a la aplicación en un sistema de comunicaciones móviles de tercera generación. También puede concebirse su aplicación en diferentes sistemas de flujo continuo inalámbricos, e incluso por cable.

Claims (16)

1. E04710443

   01-10-2014

   REIVINDICACIONES

   1. Método para notificar una calidad de transmisión en flujo continuo, en el que por lo menos un flujo continuo de medios se transmite por flujo continuo a un cliente (601), y en el que dicha transmisión en flujo continuo es

   5 controlada por un protocolo (109) que se hace funcionar entre dicho cliente (601) y un servidor (600), que comprende:

   -notificar (603) por parte de dicho cliente a dicho servidor (600) la calidad de dicha transmisión en flujo continuo basándose en por lo menos un factor de medición de calidad seleccionado, en el que dicho por lo

   10 menos un factor de medición de calidad seleccionado es un factor de medición de la calidad de la experiencia, que se basa por lo menos parcialmente en la decisión de si por lo menos una trama de dicho por lo menos un flujo continuo de medios es una trama buena,

   caracterizado por que

   15 dicha notificación de dicha calidad de dicha transmisión en flujo continuo se basa además en una clase seleccionada de factores de medición de la calidad, en el que dicha clase seleccionada de factores de medición de calidad se selecciona a partir de un conjunto predefinido de por lo menos dos clases de factores de medición de calidad, en el que la selección de dicha clase de factores de medición de calidad comprende la negociación

   20 (605-609) de dicha clase de factores de medición de calidad entre dicho cliente (601) y dicho servidor (600), y en el que cada clase de factores de medición de calidad en dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad define un conjunto diferente de reglas sobre cómo decidir si una trama de dicho por lo menos un flujo continuo de medios es una trama buena.

   25 2. Método según la reivindicación 1, en el que dicho protocolo (109) define un campo de clase de factores de medición de calidad dentro de por lo menos una de sus unidades de datos de protocolo, en el que dicho campo de clase de factores de medición de calidad puede identificar cada clase de factores de medición de calidad de dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad.

   30 3. Método según la reivindicación 2, en el que dicho campo de clase de factores de medición de calidad está ubicado en una sección de encabezamiento (3) de dicha por lo menos una unidad de datos de protocolo.

2. 4. Método según la reivindicación 1, en el que dicho conjunto de reglas definidas por al menos una de dichas clases de factores de medición de calidad comprende:

   35 -decidir que la anterior de

   -una trama I recibida completamente de dicho por lo menos un flujo continuo de medios o

   40 -la N-ésima trama recibida completamente de dicho por lo menos un flujo continuo de medios, después del último error o pérdida de trama, es una trama buena, en el que el entero N o bien se señaliza o bien adopta por defecto ∞ en caso de una trama de vídeo o 1 en caso de una trama de audio, y

   -decidir que una trama de dicho por lo menos un flujo continuo de medios que sigue a una trama buena es una 45 trama buena, si dicha trama se recibe completamente, y, si no, que dicha trama y todas las tramas sucesivas hasta la siguiente trama buena están alteradas.

3. 5.

   Método según la reivindicación 1, en el que dicho conjunto de reglas definidas por al menos una de dichas clases de factores de medición de calidad comprende: 50

   - decidir que una trama codificada de dicho por lo menos un flujo continuo de medios es una trama buena de acuerdo con un algoritmo de seguimiento de errores.

4. 6.

   Método según la reivindicación 5, en el que dicho conjunto de reglas definidas por al menos una de dichas clases 55 de factores de medición de calidad comprende:

   -decidir que una trama intracodificada de dicho por lo menos un flujo continuo de medios es una trama buena, si se recibe completamente en dicho cliente, y que es una trama alterada en caso contrario, o

   60 -decidir que una trama con codificación predictiva de dicho por lo menos un flujo continuo de medios es una trama buena, si la misma se recibe completamente en dicho cliente y si todas sus muestras de referencia de predicción pertenecen a tramas buenas, y que es una trama alterada en caso contrario.
5. 7. Método según la reivindicación 1, en el que dicho conjunto de reglas definidas por al menos una de dichas clases 65 de factores de medición de calidad comprende:

   E04710443

   01-10-2014

   -decidir que una trama codificada de dicho por lo menos un flujo continuo de medios es una trama buena de acuerdo con un algoritmo de evaluación de calidad de decodificación.
6. 8. Método según la reivindicación 7, en el que dicho conjunto de reglas definidas por al menos una de dichas clases 5 de factores de medición de calidad comprende:

   -decidir que una trama intracodificada de dicho por lo menos un flujo continuo de medios es una trama buena, si se recibe completamente en dicho cliente, y que es una trama alterada en caso contrario, o

   -decidir que una trama con codificación predictiva de dicho por lo menos un flujo continuo de medios es una trama buena, si se recibe completamente en dicho cliente y todas sus muestras de referencia de predicción pertenecen a tramas buenas, o si por lo menos una parte (403) de dicha trama se recibe completamente, todas las muestras de referencia de predicción de dichas partes recibidas completamente de dicha trama pertenecen a tramas buenas, y todas las partes ocultadas (402) de dicha trama se consideran como buenas,

   15 en el que las partes ocultadas (402) de dicha trama se obtienen aplicando un algoritmo de ocultación de errores a unas partes perdidas o erróneas (400, 404) de una versión decodificada de dicha trama, y en el que dichas partes ocultadas (403) se consideran como buenas si una diferencia delimitadora media entre (502a-d) dichas partes ocultadas (402, 503) y las partes circundantes completamente recibidas (403, 504) y decodificadas de dicha trama está por debajo de un umbral.
7. 9. Método según cualquiera de las reivindicaciones 1 a 8, en el que dicho protocolo (109) es un Protocolo de Flujo Continuo en Tiempo Real RTSP (109) en combinación con un Protocolo de Descripción de Sesión SDP (110) en el contexto de un Servicio de Flujo Continuo por Conmutación de Paquetes PSS de un sistema de comunicaciones móviles de tercera generación.

   25

8. 10.

   Método según la reivindicación 9, en el que dicho SDP (110) comprende por lo menos un atributo de SDP que define por lo menos un campo de clase de factores de medición de calidad, en el que dicho campo de clase de factores de medición de calidad puede identificar cada clase de factores de medición de calidad de dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad.

9. 11.

   Método según la reivindicación 10, en el que dicho RTSP (109) se usa para negociar dicha clase de factores de medición de calidad entre dicho cliente (601) y dicho servidor (600) basándose por lo menos parcialmente en dicho atributo de SDP.

   35 12. Método según la reivindicación 11, en el que dicho RTSP (109) usa un método DESCRIBE para dicha negociación.
10. 13. Método que comprende:

    -recibir, en un servidor (600), una calidad notificada de una transmisión en flujo continuo de por lo menos un flujo continuo de medios a un cliente (601), en el que dicha transmisión en flujo continuo es controlada por un protocolo (109) que se hace funcionar entre dicho cliente (601) y dicho servidor (600), en el que dicha calidad se notifica desde dicho cliente (601) basándose en por lo menos un factor de medición de calidad seleccionado, y en el que dicho por lo menos un factor de medición de calidad seleccionado es un factor de

    45 medición de calidad de la experiencia que se basa por lo menos parcialmente en la decisión de si por lo menos una trama de dicho por lo menos un flujo continuo de medios es una trama buena,

    caracterizado por que

    dicha calidad se notifica además basándose en una clase seleccionada de factores de medición de calidad, en el que dicha clase seleccionada de factores de medición de calidad se selecciona a partir de un conjunto predefinido de por lo menos dos clases de factores de medición de calidad, en el que la selección de dicha clase de factores de medición de calidad comprende la negociación (605-609) de dicha clase de factores de medición de calidad entre dicho cliente (601) y dicho servidor (600), y en el que cada clase de factores de medición de

    55 calidad en dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad define un conjunto diferente de reglas sobre cómo decidir si una trama de dicho por lo menos un flujo continuo de medios es una trama buena.

11. 14.

    Programa de ordenador con instrucciones que, cuando se ejecutan en un procesador, hacen que el procesador lleve a cabo o bien las etapas de método según cualquiera de las reivindicaciones 1 a 12 en relación con el funcionamiento de un cliente o bien las etapas de método según la reivindicación 13 en relación con el funcionamiento de un servidor.

12. 15.

    Producto de programa de ordenador que comprende un programa de ordenador con instrucciones que, cuando

    65 se ejecutan en un procesador, hacen que el procesador lleve a cabo las etapas de método según cualquiera de las reivindicaciones 1 a 12 en relación con el funcionamiento de un cliente o las etapas de método según la

    5

    15

    25

    35

    45

    55

    65 E04710443

    01-10-2014

    reivindicación 13 en relación con el funcionamiento de un servidor.
13. 16. Sistema de transmisión en flujo continuo, que comprende:

    -por lo menos un cliente (601), y

    -por lo menos un servidor (600),

    en el que por lo menos un flujo continuo de medios se transmite en flujo continuo a dicho por lo menos un cliente (601), en el que dicha transmisión en flujo continuo es controlada por un protocolo (109) que se hace funcionar entre dicho por lo menos un cliente (601) y dicho por lo menos un servidor (600), en el que dicho por lo menos un cliente está adaptado para notificar la calidad de dicha transmisión en flujo continuo a dicho por lo menos un servidor (600) basándose en por lo menos un factor de medición de calidad seleccionado, y en el que dicho por lo menos un factor de medición de calidad seleccionado es un factor de medición de la calidad de la experiencia que se basa por lo menos parcialmente en la decisión sobre si por lo menos una trama de dicho por lo menos un flujo continuo de medios es una trama buena,

    caracterizado por que

    dicha calidad de dicha transmisión en flujo continuo se notifica además basándose en una clase seleccionada de factores de medición de calidad, en el que dicha clase seleccionada de factores de medición de calidad se selecciona a partir de un conjunto predefinido de por lo menos dos clases de factores de medición de calidad, en el que la selección de dicha clase de factores de medición de calidad comprende la negociación (605-609) de dicha clase de factores de medición de calidad entre dicho cliente (601) y dicho servidor (600), y en el que cada clase de factores de medición de calidad en dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad define un conjunto diferente de reglas sobre cómo decidir si una trama de dicho por lo menos un flujo continuo de medios es una trama buena.
14. 17. Cliente (601) en un sistema de transmisión en flujo continuo, que comprende:

    -unos medios (701) dispuestos para hacer funcionar un protocolo (109) que controla una transmisión en flujo continuo de por lo menos un flujo continuo de medios a dicho cliente (601),

    -unos medios (701) dispuestos para notificar a un servidor (600) la calidad de dicha transmisión en flujo continuo basándose en por lo menos un factor de medición de calidad seleccionado, en el que dicho por lo menos un factor de medición de calidad seleccionado es un factor de medición de la calidad de la experiencia que se basa por lo menos parcialmente en la decisión de si por lo menos una trama de dicho por lo menos un flujo continuo de medios es una trama buena,

    caracterizado por que

    dichos medios están dispuestos para notificar la calidad de dicha transmisión en flujo continuo basándose además en una clase seleccionada de factores de medición de calidad, en el que dicha clase seleccionada de factores de medición de calidad se selecciona a partir de un conjunto predefinido de por lo menos dos clases de factores de medición de calidad, en el que la selección de dicha clase de factores de medición de calidad comprende la negociación (605-609) de dicha clase de factores de medición de calidad entre dicho cliente (601) y dicho servidor (600), y en el que cada clase de factores de medición de calidad en dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad define un conjunto diferente de reglas sobre cómo decidir si una trama de dicho por lo menos un flujo continuo de medios es una trama buena
15. 18. Servidor (600) en un sistema de transmisión en flujo continuo, que comprende:

    -unos medios (700) dispuestos para hacer funcionar un protocolo (109) que controla una transmisión en flujo continuo de por lo menos un flujo continuo de medios a un cliente (601), y

    -unos medios (700, 706) dispuestos para recibir una calidad notificada de dicha transmisión en flujo continuo desde dicho cliente (601), en el que dicha calidad se notifica basándose en por lo menos un factor de medición de calidad seleccionado, y en el que dicho por lo menos un factor de medición de calidad seleccionado es un factor de medición de la calidad de la experiencia que se basa por lo menos parcialmente en la decisión de si por lo menos una trama de dicho por lo menos un flujo continuo de medios es una trama buena,

    caracterizado por que

    dicha calidad se notifica además basándose en una clase seleccionada de factores de medición de calidad, en el que dicha clase seleccionada de factores de medición de calidad se selecciona a partir de un conjunto

    E04710443

    01-10-2014

    predefinido de por lo menos dos clases de factores de medición de calidad, en el que la selección de dicha clase de factores de medición de calidad comprende la negociación (605-609) de dicha clase de factores de medición de calidad entre dicho cliente (601) y dicho servidor (600), y en el que cada clase de factores de medición de calidad en dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad define un

    5 conjunto diferente de reglas sobre cómo decidir si una trama de dicho por lo menos un flujo continuo de medios es una trama buena.
16. 19. Protocolo (109) para un sistema de transmisión en flujo continuo, que comprende:

    10 -unas reglas para el control de una transmisión en flujo continuo de por lo menos un flujo continuo de medios a un cliente (601);

    -una definición de por lo menos un factor de medición de calidad, en el que dicho por lo menos un factor de medición de calidad es un factor de medición de la calidad de la experiencia que se basa por lo menos 15 parcialmente en la decisión de si por lo menos una trama de dicho por lo menos un flujo continuo de medios

    es una trama buena;

    -unas reglas para la selección de por lo menos un factor de medición de calidad; y

    20 -unas reglas para la notificación de una calidad de dicha transmisión en flujo continuo sobre la base de dicho por lo menos un factor de medición de calidad seleccionado a un servidor (600);

    caracterizado por que dicho protocolo comprende además:

    25 -una definición de un conjunto de por lo menos dos clases de factores de medición de calidad, en el que cada clase de factores de medición de calidad en dicho conjunto predefinido de por lo menos dos clases de factores de medición de calidad define un conjunto diferente de reglas sobre cómo decidir si una trama de dicho por lo menos un flujo continuo de medios es una trama buena;

    30 -unas reglas para la selección de una clase de factores de medición de calidad a partir de dicho conjunto de por lo menos dos clases de factores de medición de calidad, en el que dicha selección de dicha clase de factores de medición de calidad comprende la negociación (605-609) de dicha clase de factores de medición de calidad entre dicho cliente (601) y dicho servidor (600); y

    35 -unas reglas para la notificación de dicha calidad de dicha transmisión en flujo continuo basándose además en dicha clase seleccionada de factores de medición de calidad.