MXPA06002026A - Metrica de calidad de experiencia (qoe) para redes de comunicacion inalambrica. - Google Patents

Abstract

Una estructura de calidad de experiencia (QoE) proporciona una tecnica para evaluar la experiencia del usuario final en un entorno de comunicacion inalambrica movil, tal como redes 2.5G o 3G, o en cualquier otro entorno de comunicacion inalambrica o de cableado; la estructura es utilizable en conjunto con aplicaciones de canalizacion de medios y permite una combinacion de una capa de red, capa de transporte, capa de codec, y mediciones de capa de aplicacion para extraer resultados; los resultados extraidos pueden utilizarse para monitorear y mejorar, si es necesario, la experiencia del usuario final sobre condiciones de red severamente variables.

Description

MÉTRICA DE CALIDAD DE EXPERIENCIA ÍQOEi PARA REDES DE COMUNICACIÓN INALÁMBRICA REFERENCIA CRUZADA CON SOLICITUDES RELACIONADAS Esta solicitud reclama el beneficio de la Solicitud de la Patente Provisional de E. U. A. No. 60/497,447 presentada el 21 de agosto, 2003; y la Solicitud de Patente Provisional de E. U. A. No. 60/539,536 presentada el 26 de enero, 2004, en donde estas dos solicitudes provisionales son asignadas al mismo apoderado que la solicitud actual y se incorporan aquí por referencia en sus totalidades.

CAMPO TÉCNICO La presente descripción se refiere generalmente a redes de comunicación, y en particular pero no exclusivamente, se refiere a técnicas que evalúan la experiencia de usuario final o Calidad de Experiencia (QoE) en un ambiente de comunicación inalámbrica móvil y/o cableada.

ANTECEDENTES DE LA INVENCIÓN Con los desarrollos en la compresión de medios e infraestructuras de redes inalámbricas, el flujo de medios se ha hecho un área prometedora de la tecnología para los usuarios finales, proveedores de contenido, operadores inalámbricos, y otras entidades. Aunque existirá más ancho de banda disponible para las tecnologías inalámbricas tal como 2.5 G o 3 G y a pesar del hecho de que algunas de las técnicas de compresión avanzadas permiten el flujo muy bajo de la velocidad de bit, hay problemas inherentes cuando se llega al ambiente inalámbrico. Las áreas de las aplicaciones de flujo inalámbricas en donde se encuentran tales problemas incluyen aplicaciones de medios en tiempo real (incluyendo tanto flujo de audio como de video), aplicaciones de audio en tiempo real (tal como música en vivo o transmisiones deportivas), aplicaciones de medios fuera de línea, y aplicaciones de audio fuera de línea. A diferencia de las redes cableadas, las redes inalámbricas sufren de altas velocidades de pérdida de paquete efectivo y retrasos de paquete intermitentes. La pérdida y retrasos de paquetes pueden ser ocasionados por factores tal como congestión de red, proporciones de error de bits, o sobrecarga de datos en el dispositivo del usuario además de los efectos, tal como desvanecimiento, que es una característica inherente de las redes inalámbricas. Además de la pérdida de paquete, existen otros factores que adversamente afectan los medios recibidos por el usuario final. El efecto de cualquiera de estos factores en la experiencia del usuario puede variar ampliamente dependiendo de las condiciones del canal de comunicación, características del dispositivo de usuario, condiciones ambientales, eventos voluntarios o involuntarios que ocurren durante la comunicación, y otras influencias. Todos los factores antes descritos y otros finalmente afectan de forma adversa la Calidad de Experiencia QoE para el usuario final en un ambiente de comunicación inalámbrica móvil en el contexto de entrega y consumo de medios, en donde el flujo sólo es un ejemplo de la entrega de medios. Estos mismos u otros factores también pueden afectar la QoE para el usuario final en un ambiente de comunicación cableada.

BREVE DESCRIPCIÓN DE LA INVENCIÓN Un aspecto proporciona un método utilizable en un ambiente de comunicación inalámbrico. El método incluye definir al menos una métrica de calidad de experiencia (QoE) que indica una característica que afecta la calidad en el ambiente de comunicación inalámbrica. Se realiza una negociación entre un cliente y un servidor para determinar cuál de al menos una métrica de QoE se va a utilizar durante una sesión entre el cliente y el servidor, y tal métrica de QoE está designada como una métrica de QoE aceptada. Los datos para una o más métricas de QoE aceptadas son recolectados durante la sesión, y los datos de métrica se comunican entre el cliente y el servidor.

BREVE DESCRIPCIÓN DE LAS DIFERENTES VISTAS DE LOS DIBUJOS Se describen modalidades no limitantes y no exhaustivas con referencia a las siguientes figuras, en donde números de referencia similares se refieren a partes similares a través de las varias vistas a menos que se especifique de otra forma. La Figura 1 es un diagrama de bloques funcional que ilustra los componentes de estructura de QoE y operación de los mismos de acuerdo con una modalidad. La Figura 2 ilustra una primera modalidad de negociación de QoE. La Figura 3 ilustra una segunda modalidad de negociación de QoE. Las Figuras 4A y 4B son diagramas de bloques de una modalidad de un módulo de QoE para la estructura de QoE de la Figura 1 mostrada con mayor detalle.

DESCRIPCIÓN DETALLADA En la siguiente descripción, se proporcionan numerosos detalles específicos para proporcionar un entendimiento completo de las modalidades. Un experto en la técnica, sin embargo, reconocerá que la invención se puede practicar sin uno o más de los detalles específicos, o con otros métodos, componentes, materiales, etc. En otros casos, las estructuras, materiales, u operaciones bien conocidas no se muestran o describen en detalle para evitar aspectos que obstaculizan la invención. La referencia a través de esta especificación a "una modalidad" significa que un aspecto, estructura, o característica particular descrita en conexión con la modalidad está incluida al menos en una modalidad. De esa forma, las apariciones de las frases "en una modalidad" en varios lugares a través de esta especificación no necesariamente se refieren a la misma modalidad. Además, los aspectos, estructuras, o características particulares se pueden combinar en cualquier forma adecuada en una o más modalidades. A menos que el contexto lo requiera de otra forma, a través de la especificación y las reivindicaciones que siguen, la palabra "comprenden" y variaciones de la misma, tal como, "comprende" y "que comprende" se van a interpretar en un sentido abierto inclusivo, es decir como "incluyendo, pero no limitándose a". Los encabezados proporcionados aquí son sólo para conveniencia y no para interpretar el alcance o significado de la invención reclamada. Como una perspectiva general, una modalidad de la estructura de QoE proporciona una técnica para monitorear y tratar aspectos de QoE que pueden surgir durante las comunicaciones entre los componentes de red.

Por ejemplo, puede haber aspectos de QoE que pueden surgir durante comunicaciones entre un servidor y un cliente (por ejemplo, dispositivo de usuario final) cuando los medios se están comunicando desde el servidor al cliente. Los componentes de la estructura de QoE de una modalidad incluyen los procedimientos de iniciación y término que respectivamente definen el inicio y fin de una sesión; un procedimiento de negociación en donde el servidor y el cliente negocian qué métrica(s) utilizar durante la sesión; una o más métricas que se definen e ¡mplementan (por ejemplo, recolección/medición de valores de métrica), transportación durante la sesión de los valores de métrica que pertenecen a métricas en una frecuencia predefinida y para una escala predefinida de la sesión de los cuales todos han sido aceptados durante la negociación; y análisis/aplicación de los valores de métrica para evaluar la QoE y ajustar las condiciones para que la QoE se pueda mejorar, si es necesario. Se describirán varias modalidades en el contexto de la estructura de QoE en redes de comunicación inalámbrica. Se aprecia que la invención no está limitada al ambiente inalámbrico. Las modalidades de la estructura de QoE se pueden aplicar a las redes de comunicación cableadas (incluyendo redes de comunicación que comprenden tanto elementos cableados como inalámbricos) o cualquier otra red que puede experimentar aspectos de QoE. Simplemente para efectos de ilustración y explicación, se describen aquí varias modalidades que utilizan estándares y/o terminología específica de protocolo, procedimientos, formatos, u otras implementaciones específicas de protocolo. Por ejemplo, se describen ciertas modalidades con respecto a Protocolo de Descripción de Sesión (SDP), Protocolo de Flujo en Tiempo Real (RTSP), y otros estándares/protocolos. Estas implementaciones específicamente descritas no pretenden limitar la invención. Más que eso, tales estándares/descripciones específicas de protocolo simplemente pretenden ayudar al lector (o a una persona experta en la técnica) a entender la operación y características de ciertas modalidades ilustrativas cuando se impiementan en conjunto con los estándares/protocolos bien conocidos. A partir de estas descripciones específicas en la presente, un experto en la técnica será capaz de adquirir el conocimiento con respecto a cómo hacer y utilizar otras modalidades de la invención para otros estándares/protocolos (actualmente existentes o a ser desarrollados en el futuro) o para otras aplicaciones en donde surjan aspectos de QoE. Una de tales modalidades ilustrativas específicas pero no limitantes de la estructura de QoE aprovecha los protocolos de descripción y control de flujo existentes tales como SDP (ver, por ejemplo, RFC 2327:SDP: Session Description Protocol, Handley M. y Jacobson V., abril de 1998) [2] y RTSP (ver, por ejemplo, RFC 2326: Real Time Streaming Protocols (RTSP), Schulzrinne H., Rao A. y Lanphier R., abril de 1998) [3] al proporcionarles extensiones para el cumplimiento de estándares. Una modalidad también permite que se incorporen mecanismos de reporte a base de estándares existentes, tal como RTCP (ver, por ejemplo, RFC 3550: RTP: A Transport Protocol for Real-Time Applications, Schulzrinne H. y otros, julio de 2003) [4] y RTCP XR (ver, por ejemplo, RFC 3611 : RTP Control Protocol Extended Reports (RTCP XR), T. Friedman y otros, noviembre de 2003) [5]. Los números entre corchetes Q asignados a cada una de estas referencias se utilizarán subsecuentemente a través de esta descripción como una técnica abreviada para citar estas referencias. Una modalidad de la estructura de QoE también define un grupo de parámetros (métricas) de QoE, tal como duración de corrupción, duración de volver a guardar en memoria intermedia, duración del guardado en memoria intermedia inicial, pérdida sucesiva, desviación de velocidad de marco, y/o duración oscilante. Estas y otras métricas definidas adecuadamente se pueden utilizar de forma individual o en cualquier combinación práctica. La Figura 1 muestra un diagrama de los componentes involucrados en la estructura de QoE de acuerdo con una modalidad. Un servidor 100 y un cliente 102 se muestran comunicándose uno con otro a través de un protocolo de QoE y calidad de servicio (QoS). Un ejemplo adecuado pero no limitante del cliente 102 es cualquier microteléfono/reproductor que se atiene a la norma de liberación 6 3GPP que soporta el protocolo de QoE y el grupo mínimo de métricas definidas (por ejemplo, definidas en S4-040308 Working Draft 25234-050, 3GPP TSG-SA4 Meeting #31 , Montreal, Canadá, mayo 17-21 , 2004) [1] puede comunicarse con el servidor 100 o el componente de red. Una modalidad del cliente 102 incluye un Módulo de cliente QoE 118, que será descrito a detalle más adelante.

Una modalidad del servidor 100 incorpora un módulo de Adaptación de Ancho de Banda Dinámica (DBA) 104, un módulo de Calidad de Servicio (QoS) 106, y un Módulo de Servidor QoE 108. El módulo de QoS 106 aprovecha la velocidad de bit máxima negociada, la velocidad de bit garantizada, y los parámetros de retraso de transferencia mínimos entre el cliente 102 y la red. También aprovecha cualquier dato de capa de red adicional tal como pérdida, retraso, y otros. Las modalidades ilustrativas del módulo de DBA 104 se describen en más detalle en la Solicitud de E. U. A. Serie No. 10/452,035, titulada "METHOD AND APPARATUS FOR DYNAMIC BANDWIDTH ADAPTATION", presentada el 30 de mayo, 2003, asignada al mismo apoderado que la presente solicitud, e incorporada aquí por referencia en su totalidad. Todos estos módulos cooperativamente aseguran que la experiencia de usuario es como se esperó y se monitorea a través de la sesión de flujo incluso sobre condiciones de red severamente variables. Un proveedor/operador de servicio 110 puede alimentar las salidas del Módulo de Servidor QoE 108 para un módulo de monitoreo de sistema 112, para un módulo de facturación 114 (siempre que el microteléfono esté autentificado), o cualquier otro módulo. El Módulo de Servidor QoE 108 de una modalidad puede ser adaptable a las necesidades del componente al que se conecta, y puede proporcionar análisis estadístico de las métricas de QoE, y los parámetros de QoS.

Aunque el Módulo de Servidor de QoE 108 de la modalidad ilustrada se muestra como residente en el servidor 100, se aprecia que el módulo de QoE (o cualquiera de los otros módulos) se puede localizar adecuadamente en cualquier otra parte en la red inalámbrica o cableada. Por ejemplo, el Módulo de Servidor de QoE 108 se puede localizar en un dispositivo de interfase de comunicaciones (proxy), enrutador, interruptor, u otro componente de red, incluyendo en el(los) cliente(s) 102 en algunas modalidades. Una de las características de la estructura de QoE es ofrecer a los proveedores de servicio 110 un medio para evaluar la experiencia de usuario final. La estructura de QoE de una modalidad se puede utilizar para propósitos de facturación o de punto de referencia de microteléfono/reproductor. Tal uso se puede mejorar siempre y cuando se asegure sustancialmente esa interacción de métricas confiables. La descripción más adelante está organizada como sigue. La Sección I describe los aspectos del protocolo de QOE. La Sección II describe los aspectos de las métricas de QOE. La Sección III describe los aspectos del Módulo de Servidor de QOE. La Sección IV describe los aspectos del Módulo de Cliente de QOE.

I. Protocolo de QoE En una modalidad específica pero no limitante, las extensiones de protocolo a base de RTSP y SDP se utilizan para la transportación y negociación de las métricas de QoE entre el cliente del servicio de flujo conmutado por paquetes (PSS) 102 y el servidor de PSS 100, por ejemplo. Por supuesto, el transporte y la negociación de las métricas de QoE pueden utilizar otros mecanismos alternativa o adicionalmente a RTSP y SDP. Una modalidad ilustrativa de los procedimientos de la negociación y transporte de un protocolo de QoE 116 se ¡lustra en la Figura 1. La negociación de métricas de QoE inicia con la respuesta de la solicitud de DESCRIBIR enviada del cliente 102, si la información de métrica está insertada en los datos SDP. Para el caso de SDP localmente almacenado que contiene el atributo de Métricas de QoE, la negociación inicia con ia solicitud de CONFIGURACIÓN del Cliente 102. Si el cliente PSS 102 soporta las métricas de QoE, entonces el cliente 102 envía una solicitud de CONFIGURACIÓN que contiene las métricas de QoE seleccionadas (es decir, aceptadas por el cliente 102)/modificadas (para la renegociación) para cualquier nivel de sesión, o el nivel de medios, que está siendo configurado. Al recibir esta solicitud de CONFIGURACIÓN, el servidor 100 regresa la Respuesta de RTSP con las métricas de QoE "aceptadas" (es decir, métricas y valores de métricas que son idénticos a los que están en la solicitud del cliente 102 y aceptados por el servidor 100) y las métricas de QoE de "renegociación" (es decir, métricas y valores de métricas que no son idénticos a los que están en la solicitud del cliente 102 y modificados para la renegociación por el servidor 100). La repetición de las métricas de QoE "aceptadas" es para volver a reconocer al cliente 102. El servidor 100 también puede rechazar los cambios hechos por el cliente 102 (es decir, rechazar las métricas de QoE de "renegociación"). Si el servidor 100 rechaza los cambios, el servidor 100 establece nuevos valores y reenvía las métricas modificadas de regreso al cliente 102, o el servidor 100 ignora las métricas de "renegociación" y no las reconoce nuevamente. Cualquier métrica de QoE que ha sido reconocida como "aceptada" por el servidor 100 no es renegociada (es decir, no necesita ser reenviada en el encabezado de "métricas-QoE-3GPP" en la siguiente solicitud de RTSP y no necesita ser reconocida nuevamente en la siguiente respuesta de RTSP). Si el servidor 100 no aprueba las modificaciones hechas por el cliente 102, el servidor 100 y el cliente 102 continúan renegociando hasta que la solicitud de REPRODUCIR RTSP y el servidor 100 repiten las métricas de QoE "aceptadas" en la respuesta de REPRODUCIR RTSP. El cliente 102 puede terminar el procedimiento de negociación al emitir una solicitud de REPRODUCIR RTSP. Cabe señalar que cada vez que el campo de encabezado de "métricas de QoE" se envía en una solicitud de RTSP, también está presente en la respuesta correspondiente a esa solicitud particular. De otra forma, el receptor de la respuesta asume que el otro extremo NO soporta las métricas de QoE. Si no hay un envío de par de respuesta de DESCRIBIR - RTSP al inicio del señalamiento de RTSP (ver, por ejemplo, Figura 2), significa que la descripción de SDP es recibida por otros medios. Si tal SDP contiene el atributo de "Métricas-QoE-3GPP", la negociación sucede de la misma forma como se describió anteriormente (es decir, inicia con la solicitud de CONFIGURACIÓN que contiene el encabezado de "Métrlcas-QoE-3GPP"). Si el SDP no contiene el atributo de "Métricas-QoE-3GPP" y el servidor 100 aún desea revisar si el cliente 102 soporta o no el Protocolo de QoE, el servidor 100 incluye el encabezado de "Métricas-QoE-3GPP" que contiene las métricas de QoE iniciales en la respuesta de CONFIGURACIÓN. Si el cliente PSS 102 envía la información de métricas de QoE en la siguiente solicitud (indicando que soporta el protocolo de QoE), la negociación continúa hasta que se alcanza el acuerdo mutuo o se emite el par de mensajes de solicitud y respuesta de REPRODUCIR RTSP. Si el cliente 102 no envía la información de métricas de QoE en la siguiente solicitud para la respuesta de CONFIGURAR, entonces el servidor 100 asume que el cliente 102 no soporta métricas de QoE. Para razones de desempeño y complejidad, la renegociación de las métricas de QoE durante el flujo no necesita ser hecha en una modalidad. Sin embargo es posible apagar las métricas durante una sesión de flujo. Las métricas se pueden establecer como "apagado" en el nivel de sesión o en el nivel de medios, por ejemplo. El localizador de recurso uniforme de solicitud (URL) indica qué nivel se utiliza. Si no se utiliza URL, entonces "apagado" se aplica al nivel de sesión. El servidor 100 puede utilizar OPCIONES (con ID de sesión) o métodos RTSP ESTABLECER_PARAMETRO para apagar la interacción de QoE.

El cliente 102 no envía interacción de QoE durante el estado preparado de RTSP. Después de que termina el estado preparado (es decir, estado de RTSP = reproducción), la interacción periódica y las operaciones normales continúan. Esto reduce la carga de red en las direcciones de enlace hacia arriba y enlace hacia abajo, y procesamiento superior para el cliente de PSS 102. Cuando el cliente PSS 102 envía una solicitud de REPRODUCIR RTSP después de una PAUSA, el reloj para medir el periodo de reporte (basándose en la "Velocidad de Envío" definida) se reinicia. Si existen múltiples sesiones no agregadas (es decir, cada entrega de medios se inicia a través de una solicitud de REPRODUCCIÓN diferente), las métricas de QoE son negociadas y reportadas para cada sesión de forma separada. De nuevo, se debe enfatizar que la(s) modalidad(es) antes descrita(s) (y también subsecuentemente descrita(s) en las secciones I.A-I.F más adelante) específica(s) y céntrica(s) de implementación de la(s) porción(es) del protocolo de QoE es(son) solamente para propósitos ilustrativos y no pretende(n) ser limitante(s) de la invención. Se puede resumir una descripción más general de protocolo como sigue: se inicia una sesión entre el servidor 100 y el cliente 102; algunas métricas pueden o no ser soportadas por cualquiera o ambos del servidor 100 y el cliente102; también, el cliente 102 puede elegir incluir un subgrupo de las métricas que soporta para una sesión particular; el cliente 102 y el servidor 100 por lo tanto se involucran en un procedimiento de negociación, que puede involucrar varios intercambios hacia atrás y hacia adelante, para determinar qué métricas se soportan y deben ser enviadas por el cliente 102, qué tan frecuentemente se deben enviar las métricas soportadas/aceptadas, cómo activar y/o desactivar las métricas, el contenido o valor(es) que las métricas aceptadas van a contener, y otros factores relacionados con métricas; medición y recolección de valores de métrica por el cliente 102; transportar los valores de métrica del cliente 102 al servidor 100; y terminación de la sesión. Los valores de métrica transportados se pueden evaluar para determinar si la QoE puede o debe ser mejorada durante la sesión de flujo y/o durante sesiones subsecuentes. Las descripciones más detallas y no limitantes de las modalidades de las características de iniciación/término, negociación y transporte (interacción) del protocolo de QoE, en el contexto de estándares definidos, se detallan más adelante.

A. Iniciación/Término: RTSP En una modalidad ilustrativa y no limitante, se define un nuevo encabezado de RTSP para permitir al cliente PSS 102 y el servidor 100 negociar qué métricas de Calidad de Experiencia (QoE) el cliente PSS 102 debe enviar, qué tan frecuentemente se deben enviar las métricas, y cómo apagar la transmisión de métricas. Este encabezado puede estar presente en la solicitudes y respuestas CONFIGURACIÓN de los métodos de RTSP, ESTABLECER_PARAMETRO, OPCIONES (con ID de Sesión) y REPRODUCIR, por ejemplo en una implementación de RTSP. El encabezado o datos en el mismo se puede transmitir utilizando otros medios en implementaciones de no RTSP. Un encabezado ilustrativo se define en ABNF [3] como sigue: QoE-Header = "3GPP-QoE-Metrics"":"("OffVMeasure-Spec *(","Measure-Spec)) CRLF Measure-Spec = Stream-URL";"((Métricas";"Sending-rate ["¡"Measure-Range]"([";" Parameter_Ext])) / OfT) StreamJJRL = "url" "=" <">Rtsp_URL <"> Metrics = "metrics" "=" "{"Metrics-Name *(","Metrics-Name)"}" Metrics-Name = 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e): VCHAR except ";", ",", "{"or"}" Sending-Rate = "rate" "=" 1 *DIGIT/"End" Measure-Range = "range" "=" Ranges-Specifier Parameter_Ext = "On"/"Off7/1"DIGIT ["." 1*DIGi?) / (1*((0c21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c/ 0x7e)) Ranges-Specifier = as defined in RFC 2326 Rtsp_URL = as defined in RFC 2326 Hay dos formas de utilizar este encabezado para esta modalidad no limitante específica, el encabezado se puede utilizar en otras formas con otras modalidades: Utilizar sólo el parámetro "Apagado" es una indicación que el servidor 100 o el cliente 102 desea cancelar el reporte de métricas. - Utilizar otros parámetros indica una solicitud para iniciar la transmisión de métricas. Si "Corriente-URL" es un URL de Control de Sesión de RTSP, entonces "Métricas" aplican a la sesión de RTSP. Si "Corriente-URL" es un URL de control de medios de RTSP, entonces "Métricas" aplican sólo al componente de medios indicado de la sesión. Las métricas de QoE con el mismo "Corriente-URL", "Velocidad-envío" y "Medición-rango" se agregan dentro de una declaración de "Medición-Spec" individual. De otra forma, se utilizan múltiples declaraciones de "Corriente-URL". El campo de "Métricas" contiene la lista de nombres que describe las métricas/mediciones que se van a reportar en una sesión de PSS. Los nombres que no están incluidos en el campo de "Métricas" no se reportan durante la sesión.

Se establece "Velocidad-envío", y expresa el periodo máximo en segundos entre dos reportes de QoE sucesivos. Si el valor de "Velocidad-envío" es 0, entonces el cliente 102 decide el tiempo de envío de los reportes dependiendo en los eventos ocurridos en el cliente 102. Los valores > 1 indican un intervalo de reporte preciso. El intervalo más corto es un segundo y el intervalo más grande es indefinido. El intervalo de reporte puede ser diferente para medios diferentes, pero se puede mantener un grado de sincronización con el fin de evitar tráfico extra en la dirección de enlace hacia arriba. El valor "Fin" indica que sólo un reporte se envía al final de la sesión. El campo "Medición-Rango" opcional, si se utiliza, define la escala de tiempo en la corriente para la cual se reportarán las métricas de QoE. Sólo existe una escala por especificación de medición en una modalidad ilustrativa. El formato de escala puede ser cualquiera de los formatos permitidos por los medios. Si el campo de "Medición-Rango" no está presente, se utiliza el atributo de escala correspondiente (nivel de medios o de sesión) en SDP. Si la información de SDP no está presente, la escala de métricas es la duración de sesión completa. Sólo existe un encabezado de "Métricas-QoE-3GPP" en una solicitud o respuesta de RTSP en una modalidad.

B. Transporte/Interacción: RTSP En una modalidad, se puede transportar la interacción de métricas de QoE en solicitudes para el servidor PSS 100 que utiliza los métodos de ESTABLECER_PARAMETRO, PAUSA o DESTRUIR a través del encabezado de "lnteracción-QoE-3GPP". Un ejemplo posible del encabezado (enviado del cliente 102 al servidor 100) se define en ABNF [3] como sigue: Feedbackheader = "3GPP-QoE-Feedback"" ":" Feedback-Spec *("," Feedback-Spec) CRLF Feedback-Spec = Stream-URL1*(";" Parametrers) [";" Measure-Range] Stream-URL = as specified in [1] Parameters = Metrics-Name "=" "{" SP / (Measure *(","Measure)) "}" Metrics-Name = as defined in [1] Measure = Valué [SP Timestamp] Measure-Range = as defined in [1] Valué = (1*DIGIT ["." *DIGIT) / 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3x..0x7a) / 0x7c / Ox 7e); VCHAR except ";", ",", "{"or")" Timestamp = NPT-Time NPT-Time = as defined ¡n RFC 2326 "Corriente-URL" es la sesión de RTSP o URL de control de medios que identifica los medios a los que aplica el parámetro de interacción. El campo de "Métricas-Nombre" en la definición de "Parámetros" contiene el nombre de las métricas/mediciones y utiliza los mismos identificadores que el encabezado de "Métricas-QoE-3GPP"). El campo de "Valor" indica los resultados. Existe la posibilidad que el mismo evento ocurra más de una vez durante un periodo de monitoreo.

En ese caso, los valores de métricas pueden ocurrir más de una vez indicando el número de eventos al servidor 100. La "Fecha de registro" opcional (definido en tiempo NPT) indica el tiempo cuando el evento ocurrió o cuando se calculó la métrica. Si no ha ocurrido ningún evento, se reporta con un grupo vacío (sólo conteniendo un espacio). La "Medición-Rango" opcional indica el periodo de reporte real, para el cual este reporte es válido. El reporte de métricas de QoE es hecho por el cliente PSS 102 al utilizar el método de ESTABLECER_PARAMETRO, por ejemplo. Sin embargo, para más eficiencia, los métodos de PAUSA y DESTRUIR de RTSP se pueden utilizar también en casos particulares, tales como: CASO 1 : Cuando se envía el reporte de QoE último, el cliente 102 inserta la información de QoE en un mensaje de DESTRUIR. CASO 2: Cuando el cliente 102 desea poner pausa al flujo de corriente, la información de QoE se debe insertar en un método de PAUSA. El cliente PSS 102 no debe enviar ninguno de los reportes de QoE al servidor PSS 100 cuando el sistema está pausado, ya que no hay flujo de medios.

C. Iniciación/Término: SDP En una modalidad, se puede utilizar el SDP para iniciar la negociación de QoE. La razón por la cual se utiliza el SDP es para soportar los casos de uso en donde se distribuye el SDP a través de otros métodos diferentes a DESCRIBIR RTSP (por ejemplo, WAP, HTTP, o correo electrónico). Un nuevo atributo de SDP ilustrativo, que se puede utilizar ya sea a nivel de sesión o de medios, es definido más adelante en ABNF con base en RFC 2327: QoE-Metrlcs-line = "a" "=" "3GPP-QoE-Metrics": att_measure_spec *("," att-measure-spec)) CRLF att-measure-spec = Metrics ";" Sending-rate [";" Measure-Range] *([";" ParameterJ?xt]) Metrics = as defined in [1] Sending-Rate = as defined in [1] Measure-Range = as defined in [1] ParameteM?xt = as defined in [1] El servidor 100 utiliza este atributo para indicar que las métricas de QoE son soportadas y se utilizan si también están soportadas por el cliente 102. Cuando está presente en el nivel de sesión, sólo contiene métricas que aplican a la sesión completa. Cuando está presente en el nivel de medios, sólo contiene métricas que son aplicables a medios individuales. El URI que se utiliza en la especificación del encabezado de RTSP "Métricas-QoE-3GPP": está implícito por el URI de control de RTSP (a = control).

D. Iniciación/Término: SDP (Ejemplo) Este siguiente ejemplo no limitante muestra la sintaxis del atributo de SDP para métricas de QoE. La descripción de métricas de QoE del nivel de sesión (duración del guardado en memoria intermedia inicial y volver a guardar en memoria intermedia) se monitorea y reporta una vez al final de la sesión. También, la descripción específica de video de las métricas (corrupciones y bytes decodificados) se monitorea y reporta cada 15 segundos desde el inicio de la corriente hasta los 40s, por ejemplo, pero este cronometraje se puede variar como se desee de una modalidad a otra. La descripción específica de audio de métricas (corrupciones) se monitorea y reporta cada 20 segundos, por ejemplo, desde el inicio hasta el fin de la corriente.

EJEMPLO 1 Server->Client RTSP/1.0 200 OK Cseq: 1 Content-Type: application/sdp Content-Base: rtsp://example.com/foo/bar/baz.3gp/ Content-Length: 800 Server: PSSR6 Server v=0 o=-3268077682 433392265 IN OP 63.108.142.6 s=QoE Enables Session Description Example e=support@foo.com c=IN IP4 0.0.0.0 t=0 0 a=rangenpt=0-83.660000 a=3GPP-QoE-Metrics:{lnitial_Buffering_Duration, Rebuffering_Duration} rate=End a=control:* m=video 0 RTP/AVP 96 b=AS:28 a=3GPP-QoE-Metrics:{Corruption_Duration,Decoded_Bytes}; rate=15; range:npt=0-40 a=control:tracklD=3 a=rtpmap:96 MP4V-ES/1000 a=rangenpt=0-83.666000 a=fmtp:96 profile-level-id=8; config= 000001 b00800000150900012000 m=audio 0 RTP/AVP 98 b=AS:13 a= 3GPP-QoE-Metrics:{Corruption_Duration}; rate=20 a=control:tracklD=5 a=rtpmap:98 AMR/8000 a=rango:npt=0-83.660000 a=fmtp:98 octet-align=1 a=maxptime:200 E. Iniciación/Término: RTSP (Ejemplo) En el ejemplo de la Figura 2, se muestra cómo negociar métricas de QoE durante la configuración de la sesión de RTSP. Después de la negociación, el cliente 102 puede proporcionar valores medidos/recolectados de métricas aceptadas para el servidor 100 como interacción.

Client->Server SETUP rtsp://example.com/foo/bar/baz.3gp/tracklD=3 RTSP/1.0 Cseq:2 3GPP-QoE-Metrics:url= "rtsp://example.com/foo/bar/baz.3gp/tracklD =3"; metrics={Corruption_Duration, Decoded_Bytes}; rate=10; Range: npt=0-40, url="rstp://example.com/foo/bar/baz.3gp"; metrics={lnitia Buffering_Duration, Rebuffering_Duration}; rate=End En la solicitud de CONFIGURACIÓN ilustrativa anterior, el cliente 102 modifica la velocidad de envío de las métricas de QoE para el URL de control rstp://exampIe.com/foo/bar/baz.3gp/tracklD=3" de 15 a 10 (comparado con la descripción SDP inicial). Asumiendo que el servidor 100 reconoce los cambios, el servidor 100 enviará de regreso una respuesta de CONFIGURACIÓN como sigue: Server->Client RTSP/1.0 2000 OK Cseq:2 Session: 17903320 Transport: RTP/AVP; unicast; client_port=7000-700; server_port=6970-6971 3GPP-QoE-Metrics:url= "rtsp://example.com/foo/bar/baz.3gp/tracklD =3"; metrics={Corruption_Duration, Decoded_Bytes}; rate=10; Range: npt=0-40, url="rstp://example.com/foo/bar/baz.3gp"; metr¡cs={lnitial_Buffering_Duration, Rebuffering_Duration}; rate=End La Figura 3 muestra una negociación de métricas de QoE ilustrativa cuando no hay DESCRIBIR-200/Aceptar. En el ejemplo posterior, las métricas se apagan en el nivel de sesión (para todos los medios): Client->Server, Server->Client SET_PARAMETER rstp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq:302 Session: 17903320 3GPP-QoE-Metrics: Off Content-length: 0 Una respuesta ilustrativa para establecer las métricas sería: Server->Client->, Server->Client RTSP/1.0 2000 OK Cseq: 302 Session: 17903320 3GPP-QoE-Metrics: Off F. Transporte/Interacción: RTSP (Ejemplo) La interacción de métricas (que comprende valores/datos de métrica) se puede transportar o de otra forma llevar desde el cliente 102 al servidor 100 utilizando cualquier técnica de comunicación adecuada. Una técnica posible y no limitante es utilizar el método de ESTABLECER_PARAMETRO para transportar la interacción al servidor 100.

El siguiente ejemplo muestra que durante el tiempo de monitoreo, han ocurrido dos (2) periodos de corrupción. Cada valor indica la duración (en milisegundos) de cada periodo de corrupción.

EJEMPLO 5 (Interacción): Client->Server SET_PARAMETER rstp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq: 302 Session: 17903320 3GPP-QoE-Feedback url= "rstp://example.com/foo/bar/baz.3gp/tracklD=3"; Corruption_Duration={200, 1300} Content-Iength:0 El siguiente ejemplo muestra que durante el tiempo de monitoreo, han ocurrido dos (2) periodos de corrupción. Cada par de valores Indica la duración (en milisegundos) de cada periodo de corrupción y la fecha de registro de la corrupción (por ejemplo, la primera corrupción ocurrida en el segundo 12 y que duró 200 milisegundos).

EJEMPLO 6 (interacción con fechas de registro y escala): Client->Server SET_PARAMETER rstp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq:302 Session: 17903320 3GPP-QoE-Feedback: url= "rstp://example.com/foo/bar/baz.3gp/tracklD=3"; Corruption_Duration={200 12. 1300 16}; Range:npt=10-20 Content-Iength:0 En el siguiente ejemplo no hay eventos que reportar.

EJEMPLO 7 (Interacción sin eventos): Client->Server SET_PARAMETER rstp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq:302 Session: 17903320 3GPP-QoE-Feedback: url= "rstp://example.com/foo/bar/baz.3gp/tracklD=3"; Corruption_Duration={ } Content-Iength:0 Las Métricas de QoE En una modalidad, ei cliente PSS 102 mide las métricas en la capa de transporte, pero también puede hacerlo en la capa de aplicación para mejor precisión. El periodo de reporte para las métricas es el periodo sobre el cual se calcula un grupo de métricas. El valor máximo de periodo de reporte es negociado a través del protocolo de QoE. El periodo de reporte no incluye ningún evento voluntario que impacta la reproducción real, tal como pausa o rebobinado, o cualquier guardado en memoria intermedia o congelamientos/espacios causados por ellos. En otras modalidades, una o más métricas se pueden medir a través de elementos adicional o alternativamente para el cliente 102, y después transportados al servidor 100 y/o al cliente 102. En una modalidad, al menos algunas de las métricas son indicativas de una característica que afecta la calidad en el ambiente de comunicación, o son alguna otra indicación o resultado del canal de comunicación. Tales métricas de QoE se pueden medir en el grupo de protocolo del cliente 102, aplicación(es) del cliente 102, memorias intermedias del cliente 102, codificador/decodificador del cliente 102, u otra característica del cliente que puede estar relacionada a QoE o cualquier combinación de los anteriores. Se pueden utilizar las métricas para ajustar el comportamiento en cualquiera de estas capas en el servidor 100 y/o en el cliente 102. Las métricas ilustrativas siguientes se pueden derivar por el cliente PSS 102 que implementa la QoE. Se debe apreciar que estas métricas no son las únicas métricas que se pueden utilizar para propósitos de QoE. Estas métricas se pueden suplementar con otras métricas, reemplazar por otras métricas, modificar, combinar, etc. Las métricas más adelante son descritas aquí para proporcionar un mejor entendimiento de operación y características de las modalidades de la invención. Todas las métricas definidas más adelante son aplicables al menos a un audio, video, discursos y tipos de medios de texto cronometrados, y no necesariamente son aplicables a otros tipos de medios tal como audio sintético, imágenes fijas, gráficos de mapa de bits, gráficos de vector, y texto. Sin embargo, se aprecia que otras métricas se pueden proporcionar para estos otros tipos de medios. Cualquiera de las métricas desconocidas se puede ignorar por el cliente 102 y no incluirse en ningún reporte de QoE, en una modalidad.

A. Métrica de Duración de Corrupción La duración de corrupción, M, es el periodo del tiempo NPT del último marco bueno antes de la corrupción, al tiempo de NPT del primer marco bueno subsecuente o el final del periodo de reporte (lo que ocurra más rápido). Un marco corrupto puede ser un marco perdido completamente, o un marco de medios que tiene degradación de calidad y el marco decodificado no es el mismo que en la decodificación libre de error. Un marco bueno es un marco "completamente recibido" X que: - ya sea que sea un marco de renovación (que no hace referencia a ninguno de los marcos decodificados previamente Y en donde ninguno de los marcos recibidos subsecuentes hacen referencia a ninguno de los marcos decodificados antes de X); o no hacen referencia a ninguno de los marcos previamente decodificados; o hacen referencia a "marcos buenos" decodificados previamente. "Completamente recibidos" significa que todos los bits se recibieron y que no ha ocurrido ningún error de bit. La duración de la corrupción, M, en milisegundos se puede calcular según lo siguiente en una modalidad: a) M se puede derivar por el cliente 102 que utiliza la capa de codificador/decodificador, en cuyo caso la capa de codificador/decodificador señala la decodificación del marco bueno al cliente 102. Un marco bueno también se podría derivar por métodos de rastreo de error, pero no se utilizan los métodos de evaluación de calidad de decodificación en una modalidad pero se pueden utilizar en otra modalidad. b) En la ausencia de información desde la capa de codificador/decodificador, M, se deriva del tiempo NPT del último marco antes de la corrupción y N, en donde N está opcionalmente señalada del servidor 100 al cliente 102, y representa la duración máxima entre dos marcos de renovación subsecuentes en milisegundos. c) En la ausencia de información de la capa de codificador/decodificador y si N no está señalada, entonces M se predetermina a 8 (para el video) o a una duración de marco (para audio), o al final del periodo de reporte (lo que ocurra más rápido). El parámetro opcional N como se definió en el punto b se utiliza con el parámetro de "Corrupción_Duración" en el encabezado de "Métricas-QoE-3GPP". Otro parámetro opcional T se define para indicar si el cliente 102 utiliza o no el rastreo de error. El valor de T se establece por el cliente. Una sintaxis ilustrativa y no limitante para N y T que se puede incluir en la "Medición-Spec" (cláusula 5.3.2.3.1 de [1]) es como sigue: N = "N" "=" 1*DIGITO T = "T" "=" "Encendido" / "Apagado" Una sintaxis ilustrativa y no limitante para la "Corrupción_Duración de Métricas-Nombre" para el encabezado de interacción de QoE es como se define en la cláusula 5.3.2.3.2 de [1]. La ausencia de un evento se puede reportar utilizando el espacio (SP).

Para "Corrupción_Duración de Métricas-Nombre", el campo de "Valor" en la cláusula 5.3.2.3.2 indica la duración de la corrupción. La unidad de estas métricas se expresa en milisegundos. Existe la posibilidad de que la corrupción ocurra más de una vez durante el periodo de reporte. En ese caso el valor puede ocurrir más de una vez indicando el número de eventos de corrupción. El valor de "Fecha de registro" es igual al tiempo NPT del último marco bueno dentro del periodo de reporte, en orden de reproducción, antes de la ocurrencia de la corrupción, relativa al tiempo de inicio del periodo de reporte. Si no hay marco bueno dentro del periodo de reporte y antes de la corrupción, la fecha de registro se establece en el tiempo de inicio del periodo de reporte.

B. Métrica de Duración de Volver a Guardar en Memoria Intermedia Volver a guardar en memoria intermedia se describe como cualquier suspensión en el tiempo de reproducción debido a cualquier evento involuntario en el lado del cliente. Una sintaxis ilustrativa no limitante para "Volver a Guardar en Memoria lntermedia_Duración de Métricas-Nombre" para el encabezado de interacción de QoE es como se define en la cláusula 5.2.3.2.3 de [1]. La ausencia de un evento se puede reportar utilizando el espacio (SP).

Para "Volver a Guardar en Memoria lntermedia_Duración de las Métricas-Nombre", el campo de "Valor" en la cláusula 5.3.2.3.2 indica la duración de volver a guardar en memoria intermedia. La unidad de estas métricas se expresa en segundos, y puede ser un valor fracciona!. Existe la posibilidad que ocurra volver a guardar en memoria intermedia más de una vez durante un periodo de reporte. En ese caso el valor de métricas puede ocurrir más de una vez indicando el número de eventos de volver a guardar en memoria intermedia. La "Fecha de registro" opcional indica el tiempo cuando volver a guardar en memoria intermedia ocurrió desde el inicio del periodo de reporte. El valor de la "Fecha de registro" es igual al tiempo de NPT del último marco reproducido dentro del periodo de reporte y antes de la ocurrencia de volver a guardar en memoria intermedia, relativa al tiempo de inicio del periodo de reporte. Si no hay ningún marco reproducido dentro del periodo de reporte, la fecha de registro se establece al tiempo de inicio del periodo de reporte.

C. Métrica de Duración de Guardado en Memoria Intermedia Inicial La duración de guardado de memoria intermedia inicial es el tiempo desde que se recibió el primer paquete de RTP hasta que inicia la reproducción. Una sintaxis ilustrativa y no limitante para "IniciaI_Volver a Guardar en Memoria intermedia _Duración de Métricas-Nombre" para el encabezado de interacción QoE es como se define en la cláusula 5.3.2.3.2 con la excepción que la "Fecha de registro" en la "Medición" no está definida para esta métrica. Si el periodo de reporte es más corto que "Inicial_Guardado en Memoria intermedia_Duración" entonces el cliente debe enviar este parámetro para cada periodo de reporte mientras lo observa. El campo de "Valor" indica la duración del guardado en memoria intermedia inicial en donde la unidad de estas métricas se expresa en segundos, y puede ser un valor fracclonal. Puede existir sólo una "medición" y sólo puede tomar un "valor". La ausencia de un evento se puede reportar utilizando el espacio (SP). "lnicial_Guardado en Memoria intermedia _Duración" es un parámetro del nivel de sesión.

D. Pérdida Sucesiva de Paquetes de RTP Este parámetro indica el número de paquetes de RTP perdidos en sucesión por canal de medios. Una sintaxis ilustrativa y no limitante para la "Sucesiva_Pérdida de Métricas-Nombre" para el encabezado de interacción de QoE es como se define en la cláusula 5.3.2.3.2 de [1]. La ausencia de un evento se puede reportar utilizando el espacio (SP). Para "Sucesiva_Pérdida de Métricas-Nombre", el campo de "Valor" indica el número de paquetes de RTP perdidos en sucesión. La unidad de esta métrica se expresa como un entero igual a o mayor que 1. Existe la posibilidad que la pérdida sucesiva ocurra más de una vez durante un periodo de repote. En ese caso el valor de métricas puede ocurrir más de una vez indicando el número de pérdidas sucesivas. La "Fecha de registro" opcional indica el tiempo cuando la sucesión de los paquetes perdidos ha ocurrido. El valor del "Fecha de registro" es igual al tiempo de NPT del paquete de RTP recibido por última vez dentro del periodo de reporte, el orden de reproducción, antes de la ocurrencia de la sucesión de los paquetes perdidos, relativo al tiempo de inicio del periodo de reporte. Si no hay ningún paquete de RTP recibido dentro del periodo de reporte y antes de la sucesión de pérdida, la fecha de registro se establece al tiempo de inicio del periodo de reporte. Si se desea una codificación de longitud de funcionamiento completa de pérdidas de RTP con información de número de secuencia, se deben utilizar los Bloques de Reporte de RLE de pérdida de RTCP XR [5] en vez de la métrica de pérdida sucesiva.

E. Desviación de Velocidad de Marco La desviación de velocidad de marco indica la información de velocidad de marco de reproducción. La desviación de velocidad de marco sucede cuando la velocidad de marco de reproducción real durante un periodo de reporte se desvía de un valor predefinido.

La velocidad de marco de reproducción real es igual al número de marcos reproducidos durante del periodo de reporte dividido entre la duración, en segundos, del periodo de reporte. El parámetro FR que denota el valor de velocidad de marco predefinido se utiliza como el parámetro de "Velocidad de Marco_Desviación" en el encabezado de "Métricas-QoE-3GPP". El valor de FR se puede establecer por el servidor 100. Una sintaxis ilustrativa y no limitante para FR para incluirse en la "Medición-Spec" (cláusula 5.3.2.3.1 de [1] es como sigue: FR = "FR" "=" 1*DIGITO "." 1*DIGITO Una sintaxis ilustrativa y no limitante para las Métricas-Nombre "Velocidad de Marco_Desviación" para el encabezado de interacción de QoE es como se define en la cláusula 5.3.2.3.2 con la excepción que la "Fecha de registro" en la "Medición" es indefinida para esta métrica. La ausencia de un evento se puede reportar utilizando el espacio (SP). Para las Métricas-Nombre "Velocidad de Marco_Desviación", el campo de "Valor" indica el valor de desviación de velocidad de marco que es igual a la velocidad de marco predefinida menos la velocidad de marco de reproducción real. Esta métrica se puede expresar en marcos por segundo, y puede ser un valor fraccional, y puede ser negativo. El valor de métrica puede ocurrir sólo una vez para esta métrica en una modalidad ilustrativa y no limitante.

F. Duración de Variación La variación sucede cuando la diferencia absoluta entre el tiempo de reproducción real y el tiempo de reproducción esperado es mayor que un valor predefinido, que es 100 millsegundos. El tiempo esperado de un marco es igual al tiempo de reproducción real del marco reproducido por última vez más la diferencia entre el tiempo de NPT del marco y el tiempo de NPT del marco reproducido por última vez, en una modalidad ilustrativa. Una sintaxis ilustrativa y no limitante para las Métricas-Nombre "Variación_Duración" para el encabezado de interacción de QoE es como se define en la cláusula 5.3.2.3.2 de [1]. La ausencia de un evento se puede reportar utilizando el espacio (SP). Para las métricas-Nombre "Variación_Duración", el campo de "Valor" en 5.3.2.3.2 indica la duración de la variación de reproducción. La unidad de estas métricas se expresa en segundos, y puede ser un valor fraccional. Existe la posibilidad que la variación ocurra más de una vez durante un periodo de reporte. En ese caso el valor de métrica puede ocurrir más de una vez indicando el número de eventos de la variación. El campo de "Fecha de registro" opcional indica el tiempo cuando ocurrió la variación desde el inicio del periodo de reporte. El valor de la "Fecha de registro" es igual al tiempo de NPT del marco reproducido por primera vez en la variación de reproducción, relativo al tiempo de inicio del periodo de reporte.

III. El Módulo de Servidor de QoE Las Figuras 4A y 4B muestran el módulo de servidor de QoE 108 dentro del servidor 100 de acuerdo con una modalidad. El Módulo de Servidor de QoE 108 es responsable de cuantificar el impacto de varios factores, incluyendo condiciones de red, características de cliente, etc., en los medios que son comunicados. El Módulo de Servidor de QoE 108 hace esto al recopilar la interacción desde el cliente 102. Las características y configuraciones de varias modalidades del Módulo de Servidor de QoE 108 se pueden describir como sigue: 1. El Módulo de Servidor QoE 108 puede residir en un servidor de flujo (por ejemplo, el servidor 100). 2. El Módulo de Servidor QoE 108 puede residir en una interfase de comunicaciones de RTSP o en cualquier otro dispositivo de red adecuado. 3. El Módulo de Servidor de QoE 108 puede aceptar el ingreso de varios protocolos 412 tales como: o Métricas de QoE a través del protocolo de QoE (como se explicó anteriormente en [1]) o Métricas de RTCP [4] o Características de enlace de 3GPP [1] o RTCP XR [5] 4. La configuración del Módulo de Servidor de QoE 108 se puede almacenar en un archivo de SDP o generar por el Servidor/lnterfase de comunicaciones. Los parámetros de configuración ilustrativos se muestran en 410 en las Figuras 4A y 4B. 5. El Módulo de Servidor de QoE 108 interactúa con el módulo de DBA 104: o Para impactar las decisiones para aumentar la velocidad de bit basándose en el resultado de QoE estadístico. o Para impactar las decisiones para aumentar la velocidad de bit basándose en resultado de QoE subjetivo. o Para impactar las decisiones para disminuir la velocidad de bit basándose en resultados de QoE estadísticos. o Para impactar las decisiones para disminuir la velocidad de bit basándose en resultados de QoE subjetivos. o Las siguientes características también se pueden aumentar/disminuir o de otra forma influenciar/cambiar basándose en resultados de QoE sujetivos y/o estadísticos: velocidad de marco, intervalo y comportamiento de renovación, resiliencia de error, comportamiento de memoria intermedia, tamaño de marco máximo, velocidad de bit pico, fragmentación, retransmisión, y/u otras características. o Si el módulo de DBA 104 está encendido: » QoE puede tener un impacto en la adaptación de velocidad (configurable). » El reporte se controla a través del módulo de DBA 104, en una modalidad. o Si el módulo de DBA 104 se apaga: • El Servidor de QoE 108 no tiene un impacto en la adaptación de velocidad, en una modalidad, pero puede tener un impacto en la adaptación de velocidad en otra modalidad. " El reporte se controla a través del servidor de QoE 108 en una modalidad, y se controla por otros módulos o componentes en otra modalidad. o Si tanto los módulos de DBA y QoE 104 y 108 se apagan, el reporte es controlado por el módulo de QoS 106, en una modalidad. 6. El Módulo de Servidor de QoE 108 puede operar en uno o ambos de los siguientes modos. o Modo de estadística. o Modo subjetivo. o Detalles: Métricas que llegan de nuevo al servidor 100 desde el cliente 102 se pueden utilizar organizadas dentro del Módulo de Servidor de QOE 108 en muchas formas. Una forma es el "Modo de Estadística". Aquí, el Módulo de Servidor de QOE 108 está organizando la estadística de las métricas en la forma de mínimo, máximo, etc. Una segunda forma es el "Modo Sujetivo". Aquí, el Módulo de Servidor de QOE 108 está organizando las métricas que recibió al delinearlas a una clase de Calidad de Servicio. Por lo tanto, por ejemplo, después de observar las métricas, el Módulo de Servidor de QOE 108 puede determinar que una métrica particular pertenece a la clase de calidad MEDIA. Como tal, esta información se puede utilizar para propósitos de validación. Por ejemplo, si el cliente 102 está suscrito a una clase de calidad ALTA pero para esta sesión particular basándose en las métricas que el servidor 100 recibió, se determinó que esta sesión sólo pertenecía a la clase de calidad MEDIA, entonces tal información es útil para un número de propósitos. Potencialmente puede haber un número de otros análisis de las métricas que el Módulo de Servidor de QOE 108 recibe. 7. El Modo de Estadística de QoE: o Calculado en nivel de medios o de sesión. o Medido sobre un periodo individual o la sesión completa. o Calcula mínimo, máximo, promedio y desviación estándar de al menos: » Duración de corrupción (como se explicó anteriormente y en [1]) » Duración de volver a guardar en memoria intermedia (como se explicó anteriormente y en [1]) • Duración de guardado en memoria intermedia inicial (como se explicó anteriormente y en [1]) « Pérdida sucesiva (como se explicó anteriormente y en [1]) 8. El Modo Subjetivo de QoE: o Calculado en nivel de medios o de sesión. o Medidos sobre la sesión completa (ningún reporte de periodo individual). o Proporciona un delineado para una clase de QoS predefinida.

• Mejor esfuerzo o Clase de Flujo, • Clase de QoE Baja, Media, o Alta. o Proporciona una separación de la ubicación posible del problema: • Capa de enlace. » Grupo de protocolo de red. • Problema de grupo de codificador/decodificador. " Problema de aplicación de cliente. • Problema de sujetador. - Otro. 9. Los reportes de QoE se pueden integrar a un: o Sistema de monitoreo o Sistema de facturación (si se autentifica el microteléfono).

En una modalidad, el módulo de DBA 104, módulo de QoS 106, y Módulo de Servidor de QoE 108 juntos pueden comprender parte de un módulo de reporte 400. Pueden existir módulos adicionales localizados en el servidor 100, tales como un módulo de cambio de velocidad 402. Por cuestiones de brevedad, no se ha proporcionado aquí la descripción detallada de tales módulos adicionales. Al menos algunas de las operaciones relacionadas con QoE y otras descritas anteriormente se pueden modalizar en software u otra instrucción legible por máquina 404 almacenada en uno o más medios legibles por máquina 406. Tales medios legibles por máquina 406 se pueden localizar en el servidor 100, en el cliente 102, y/o en alguna otra ubicación de red adecuada. Uno o más procesadores 408 están acoplados al medio de almacenamiento 406 para permitir al procesador 408 ejecutar el software 404 almacenado en el mismo.

IV. El Módulo de Cliente de QoE El Módulo de cliente QoE 118 de una modalidad está basado en el cliente 102. El Módulo de cliente de QoE 118 puede decidir cambiar las métricas de QoE a ENCENDIDO/APAGADO para una sesión basándose en cualquier número de consideraciones. En tales consideraciones, por ejemplo, está la energía de batería baja que puede impedir su operación regular. El Módulo de Cliente de QoE 118 puede APAGAR las métricas a la mitad de la sesión después de que ha decidido ENCENDERLA en el inicio de la sesión. Esta decisión se puede influenciar a través de un número de razones, incluyendo las ineficiencias de las métricas que está recolectando o por otras razones. El Módulo de Cliente QoE 118 puede seleccionar y elegir, del grupo de métricas que soporta, cuáles soporta para una sesión particular. Esta decisión puede estar influenciada por la complejidad de cálculo de las métricas, experiencia pasada, u otras consideraciones. Tal selección de métrica se puede utilizar para la negociación con el servidor 100.

El Módulo de Cliente de QoE 118 puede elegir APAGAR selectivamente ciertas métricas a la mitad de la sesión después de que ha acordado medirlas al inicio de la sesión. El Módulo de Cliente QoE 118 también puede seleccionar la frecuencia de reporte de tales métricas. La selección de frecuencia se puede utilizar para la negociación con el servidor 100. El Módulo de Cliente QoE 118 puede seleccionar la escala de la sesión en la cual se deben medir las métricas. La selección de escala se puede utilizar para la negociación con el servidor 100. El Módulo de Servidor QoE 108 y/o el Módulo de Cliente QoE 118 de una modalidad puede cambiar la lista de métricas, el nivel de métricas (medios/sesión), la frecuencia de las métricas, y la escala de las métricas durante la sesión. El Módulo de Cliente QoE 118 puede medir dinámicamente u obtener de otra forma valores de métrica "sobre la marcha" mientras decodifica o procesa medios recibidos desde el servidor 100. Los resultados de los ciclos de decodificación y/o procesamiento se pueden utilizar durante el procedimiento de recopilación de métricas. El Módulo de Cliente QoE 118 puede recopilar datos en varios niveles (por ejemplo, aplicación, red, codificador/decodificador, u otros). El Módulo de Cliente QoE 118 después puede utilizar tales datos colectivamente para determinar algunas de las métricas. El Módulo de Cliente QoE 118 puede distinguir entre acción voluntaria e involuntaria del cliente 102 que toma en cuenta la Calidad de Experiencia. El Módulo de Cliente QoE 118 puede mantener la integridad de las métricas que ha medido. El Módulo de Cliente QoE 118 puede seleccionar los medios de transporte de estas métricas si tal elección está disponible. En una modalidad, el Módulo de Cliente QoE 118 puede cambiar la configuración de las métricas mientras aún las recolecta (por ejemplo, frecuencia y la escala de las métricas). Las métricas también pueden ser aplicables al nivel de sesión, medios de nivel de corriente (por ejemplo, audio, video, separada o conjuntamente). Al menos algunas de las operaciones relacionadas con QoE u otras descritas anteriormente se pueden modalizar en software u otra instrucción legible por máquina 404 almacenada en uno o más medios legibles por máquina 404. Tales medios legibles por máquina 404 pueden estar localizados en el servidor 100, en el cliente 102, y/o en alguna otra ubicación de red adecuada. Uno o más procesadores 408 están acoplados al medio de almacenamiento 406 para permitir al procesador 408 ejecutar el software 404 almacenado en el mismo. Varios componentes, tal como los módulos en el servidor 100 y/o cliente 102 se pueden modalizar en software (u otra instrucción legible por máquina), hardware, y/o una combinación de ambos. Todas las patentes de E. U. A., publicaciones de solicitud de patente de E. U. A., solicitudes de patente de E. U. A., patentes extranjeras, solicitudes de patente extranjeras y publicaciones de no patente anteriores referidas en esta especificación y/o enlistadas en la Hoja de Datos de Solicitud, se incorporan aquí por referencia, en su totalidad.

La descripción anterior de las modalidades ilustradas, incluyendo lo que se describió en el Resumen, no pretende ser exhaustiva o limitar la invención a las formas precisas descritas. Mientras las modalidades y ejemplos específicos se describen aquí para propósitos ilustrativos, varias modificaciones equivalentes son posibles dentro del alcance de la ¡nvención y se pueden hacer sin desviarse del espíritu y alcance de la invención. Por ejemplo, aunque se han descrito varias modalidades aquí en el contexto de ciertos protocolos de comunicación específicos, estándares, formatos, sintaxis, y similares, se pueden proporcionar otras modalidades para otros tipos de protocolos de comunicación, estándares, formatos, sintaxis, y similares. La invención no está limitada a protocolos de comunicación específicos, estándares, formatos, sintaxis y similares que se describen aquí. Las modalidades no son sólo aplicables a flujo de medios de audio y video, sino también a otras formas de entrega de medios y consumo. Estas y otras modificaciones se pueden hacer a la invención en vista de la descripción detallada anterior. Los términos utilizados en las siguientes reivindicaciones no deben ser interpretados para limitar la invención a las modalidades específicas descritas en la especificación y las reivindicaciones. Más bien, el alcance de la invención se va a determinar completamente a través de las siguientes reivindicaciones, que van a ser interpretadas de acuerdo con las enseñanzas establecidas de la interpretación de reivindicaciones.

Claims (28)

NOVEDAD DE LA INVENCIÓN REIVINDICACIONES

1.- Un método utilizable en un ambiente de comunicación, el método comprende: definir al menos una métrica de calidad de experiencia (QoE) indicativa de una característica que afecta la calidad en el ambiente de comunicación; realizar una negociación entre un cliente y un servidor para determinar cuál de al menos una métrica de QoE se va utilizar durante una sesión entre el cliente y el servidor, y designar tal métrica de QoE como una métrica de QoE aceptada; recolectar datos de una o más métricas de QoE aceptadas durante la sesión, que incluye recolectar datos de métrica de una combinación de mediciones de una capa de red, una capa de transporte, una capa de aplicación, características de cliente, un nivel de medios, un nivel de sesión, y protocolos diferentes; y comunicar los datos de métrica entre el cliente y el servidor.

2.- El método de conformidad con la reivindicación 1 , caracterizado además porque definir la al menos una métrica de QoE incluye definir una métrica de QoE que afecta la calidad en un ambiente de comunicación inalámbrica.

3.- El método de conformidad con la reivindicación 1 , caracterizado además porque definir la al menos una métrica de QoE incluye definir una métrica de QoE que afecta la calidad en un ambiente de comunicación cableada.

4.- El método de conformidad con la reivindicación 1 , caracterizado además porque recolectar datos para una o más métricas de QoE aceptadas durante la sesión incluye recolectar dinámicamente los datos en el dispositivo de cliente durante la sesión mientras el dispositivo de cliente decodifica o procesa medios recibidos desde el servidor.

5.- El método de conformidad con la reivindicación 1 , caracterizado además porque definir al menos una métrica de QoE incluye definir una o más métricas de QoE: duración de corrupción, duración de volver a guardar en memoria intermedia, duración de guardado en memoria intermedia inicial, pérdida de paquete sucesiva, desviación de velocidad de marco y duración de variación.

6.- El método de conformidad con la reivindicación 1 , caracterizado además porque comunicar los datos de métrica entre el cliente y el servidor incluye transportar los datos de métrica en uno o más paquetes desde el cliente al servidor.

7.- El método de conformidad con la reivindicación 1 , caracterizado además porque realizar la negociación entre el cliente y el servidor incluye determinar qué métrica de QoE soportada utilizar, determinar la frecuencia de comunicación de una métrica de QoE durante la sesión, determinar una escala de una métrica de QoE, determinar condiciones bajo las cuales desactivar una métrica de QoE durante la sesión, y además incluir cualquiera o más de: iniciar la negociación; determinar qué métrica es soportada por el servidor o por el cliente, o ambos; reconocer el recibo de una métrica de QoE propuesta durante la negociación; modificar una métrica de QoE y renegociar la métrica de QoE modificada para determinar si tal métrica de QoE modificada se puede aceptar; aceptar o rechazar cualquier métrica de QoE inicial o modificada; determinar una forma en la cual se va a comunicar una métrica de QoE durante la sesión; determinar el nivel de una métrica de QoE; determinar una configuración de una métrica de QoE; determinar parámetros de valores de métrica; y terminar la negociación si se satisfacen ciertas condiciones, que incluyen el acuerdo mutuo sobre una o más métricas de QoE finales aceptadas.

8.- El método de conformidad con la reivindicación 1 , caracterizado además porque comprende adicionalmente evaluar los datos de métrica y aplicar los datos de métrica.

9.- El método de conformidad con la reivindicación 8, caracterizado además porque evaluar los datos de métrica incluye organizar los datos de métrica de acuerdo con los modos de estadística y subjetivo.

10.- El método de conformidad con la reivindicación 1 , caracterizado además porque definir al menos una métrica de QoE incluye definir una métrica de QoE asociada con una característica del cliente.

11.- Un sistema utilizable en un ambiente de comunicación, el sistema comprende: medios para definir al menos una métrica de calidad de experiencia (QoE) indicativa de una característica que afecta la calidad en el ambiente de comunicación, que incluye una característica de cliente; medios para obtener datos de la métrica de QoE, que incluye medios para recolectar datos de métrica de una combinación de mediciones de una capa de red, una capa de transporte, una capa de aplicación, características de cliente, un nivel de medios, un nivel de sesión, y protocolos diferentes; medios para realizar una negociación entre un cliente y un dispositivo de red para comunicar los datos de métrica; y medios para comunicar los datos de métrica entre el cliente y el dispositivo de red.

12.- El sistema de conformidad con la reivindicación 11 , caracterizado además porque el ambiente de comunicación incluye un ambiente de comunicación inalámbrica.

13.- El sistema de conformidad con la reivindicación 11 , caracterizado además porque el dispositivo de red incluye un servidor.

14.- El sistema de conformidad con la reivindicación 11 , caracterizado además porque los medios para definir al menos una métrica de QoE incluyen medios para definir una o más métricas de QoE: duración de corrupción, duración de volver a guardar en memoria intermedia, duración de guardado en memoria intermedia inicial, pérdida de paquete sucesiva, desviación de velocidad de marco, y duración de variación.

15.- El sistema de conformidad con la reivindicación 11 , caracterizado además porque los medios para realizar la negociación incluyen un medio de módulo de QoE para analizar los datos de métrica que forman parte de un medio de módulo de reporte, el sistema además comprende: un medio de módulo de adaptación de ancho de banda dinámica (DBA) que forma parte del medio de módulo de reporte para interactuar con el medio de módulo de QoE para tomar decisiones relacionadas con la calidad basándose en los datos de métrica; un medio de módulo de calidad de servicio (QoS) que forma parte del medio de módulo de reporte para realizar el reporte alternativa o adicionalmente a los medios de QoE; y medios de módulo de monitoreo y facturación para interactuar con los medios de módulo de reporte para evaluar los datos de métrica.

16.- El sistema de conformidad con la reivindicación 11 , caracterizado además porque comprende adicionalmente medios de módulo de QoE del lado de cliente para determinar el cambio de las métricas de QoE a ENCENDIDO/APAGADO para una sesión basándose al menos en una consideración, para APAGAR una métrica de QoE durante la sesión después de haber ENCENDIDO esa QoE al inicio de la sesión, para seleccionar de un grupo de métricas de QoE cuáles soportar para una sesión particular, para seleccionar una frecuencia de datos de métrica de reporte, para seleccionar una escala de una sesión en la cual se van a medir las métricas de QoE, y además comprende medios para cualquiera o combinación de: seleccionar un nivel de métricas de QoE, que incluyen niveles de medios y de sesión; obtener dinámicamente datos de métrica mientras se decodifican o procesan medios recibidos desde el dispositivo de red; obtener datos de métrica en varios niveles, que incluyen los niveles de aplicación, red, y de codificador/decodificador; distinguir entre acción voluntaria e involuntaria del cliente que tenga un efecto sobre QoE; mantener una integridad de las métricas de QoE que se han obtenido; seleccionar un medio para transportar datos de métrica; y cambiar una configuración de las métricas de QoE mientras aún se recolectan sus datos.

17.- Un artículo de fabricación utilizable en un ambiente de comunicación inalámbrica, el artículo de fabricación comprende: un medio legible por máquina que tiene instrucciones almacenadas en él que son ejecutables a través de un procesador para: definir al menos una métrica de calidad de experiencia (QoE) indicativa de una característica asociada con el ambiente de comunicación, incluyendo una característica de cliente; realizar una negociación entre un cliente y un servidor para determinar cuál de la al menos una métrica de QoE se va a utilizar durante una sesión entre el cliente y el servidor, y designar tal métrica de QoE como una métrica de QoE aceptada; y obtener datos para una o más métricas de QoE aceptadas durante la sesión, que incluyen instrucciones para recolectar datos de métrica de una combinación de mediciones de una capa de red, una capa de transporte, una capa de aplicación, características de cliente, un nivel de medios, un nivel de sesión, y diferentes protocolos.

18.- El artículo de fabricación de conformidad con la reivindicación 17, caracterizado además porque las instrucciones para obtener los datos de métrica incluyen instrucciones para recibir los datos de métrica como parte de los paquetes comunicados desde el dispositivo de cliente.

19.- El artículo de fabricación de conformidad con la reivindicación 17, caracterizado además porque el medio legible por máquina está localizado en el servidor.

20.- El artículo de fabricación de conformidad con la reivindicación 17, caracterizado además porque las instrucciones para realizar la negociación incluyen instrucciones para determinar qué métrica de QoE soportada utilizar, determinar la frecuencia de comunicación de una métrica de QoE durante la sesión, determinar una escala de una métrica de QoE, determinar condiciones bajo las cuales desactivar una métrica de QoE durante la sesión, y además incluye instrucciones para realizar cualquiera o más de: iniciar la negociación; determinar qué métrica de QoE está soportada por el servidor o por el cliente, o ambos; reconocer el recibo de una métrica de QoE propuesta durante la negociación; modificar una métrica de QoE y renegociar la métrica modificada para determinar si tal métrica de QoE modificada se puede aceptar; aceptar o rechazar cualquier métrica de QoE inicial o modificada; determinar una forma en la cual se va a comunicar una métrica durante la sesión; determinar el nivel de una métrica de QoE; determinar una configuración de una métrica de QoE; determinar parámetros de valores de métrica; y terminar la negociación si se satisfacen ciertas condiciones, que incluyen acuerdo mutuo sobre una o más métricas de QoE finales aceptadas.

21.- El artículo de fabricación de conformidad con la reivindicación 17, caracterizado además porque las instrucciones para obtener datos para una más métricas de QoE aceptadas durante la sesión incluyen instrucciones para obtener datos de métrica relacionados con cualquiera o más de estas métricas de QoE: duración de corrupción, duración de volver a guardar en memoria intermedia, duración del guardado en memoria intermedia inicial, pérdida de paquete sucesiva, desviación de velocidad de marco, y duración de variación.

22.- El artículo de fabricación de conformidad con la reivindicación 17, caracterizado además porque el medio legible por máquina también incluye instrucciones almacenadas en él para evaluar los datos de métrica y para aplicar los datos de métrica.

23.- El artículo de fabricación de conformidad con la reivindicación 22, caracterizado además porque las instrucciones para aplicar los datos de métrica incluyen instrucciones para cambiar cualquiera o más de: velocidad de bit, velocidad de marco, intervalo y comportamiento de renovación, resiliencia de error, comportamiento de memoria intermedia, tamaño de marco máximo, velocidad de bit pico, fragmentación, retransmisión, y otras características de QoE.

24.- El artículo de fabricación de conformidad con la reivindicación 22, caracterizado además porque las instrucciones para aplicar los datos de métrica incluyen instrucciones para: cambiar una característica de cualquiera o más del servidor, el cliente, y el ambiente de red; utilizar los datos de métrica para facturación; utilizar los datos de métrica para reporte y monitoreo; o utilizar los datos de métrica de acuerdo con un modo subjetivo.

25.- Un aparato utilizable en un ambiente de comunicación, el aparato comprende: un módulo de calidad de experiencia (QoE) para realizar una negociación entre un cliente y un servidor para determinar qué métrica de QoE se va utilizar durante una sesión entre el cliente y el servidor, tal métrica de QoE determinada es designada como una métrica de QoE aceptada, el módulo de QoE además es capaz de comunicar datos de métrica recolectados, que corresponden a la métrica de QoE aceptada, entre el cliente y el servidor durante la sesión, en donde los datos de métrica recolectados incluyen datos de una combinación de mediciones de una capa de red, una capa de transporte, una capa de aplicación, características de cliente, un nivel de medios, un nivel de sesión, y diferentes protocolos.

26.- El aparato de conformidad con la reivindicación 25, caracterizado además porque el módulo de QoE está localizado en el cliente y además es capaz de recolectar los datos de métrica mientras los medios recibidos desde el servidor están siendo decodificados o procesados.

27.- El aparato de conformidad con la reivindicación 25, caracterizado además porque el módulo de QoE está localizado en el servidor, el aparato además comprende al menos otro módulo para cooperar con el módulo de QoE para aplicar los datos de métrica para al menos un propósito.

28.- El aparato de conformidad con la reivindicación 25, caracterizado además porque el módulo de QoE incluye un medio de negociación para determinar qué métrica de QoE soportada utilizar, para determinar una frecuencia de comunicación de una métrica de QoE durante la sesión, predeterminar una escala de una métrica de QoE, para determinar una condición bajo la cual desactivar una métrica de QoE durante la sesión, y además incluye medios para cualquiera o más de: iniciar la negociación; determinar qué métrica es soportada por el servidor o por el cliente, o ambos; reconocer el recibo de una métrica de QoE propuesta durante la negociación; modificar una métrica de QoE y renegociar la métrica de QoE modificada para determinar si tal métrica de QoE modificada se puede aceptar; aceptar o rechazar cualquier métrica de QoE inicial o modificada; determinar una forma en la cual se va a comunicar una métrica de QoE durante la sesión; determinar el nivel de una métrica de QoE; determinar una configuración de una métrica de QoE; determinar parámetros de valores de métrica; y terminar la negociación si se satisfacen ciertas condiciones, que incluyen el acuerdo mutuo sobre una o más métricas de QoE finales aceptadas.