Un procedimiento de transmisión de información relacionada con una calidad de servicio,

información que va a transmitirse en al menos un sentido entre un primer dispositivo (30) y un segundo dispositivo (20), comprendiendo dicho procedimiento en al menos en uno de dichos dispositivos (20, 30):

ensamblar un mensaje de protocolo para otra finalidad que la transmisión de información relacionada con una calidad de servicio;

incluir dicha información relacionada con una calidad de servicio en dicho mensaje de protocolo; y

transmitir dicho mensaje de protocolo al otro dispositivo respectivo de entre dicho primer dispositivo (30) y dicho segundo dispositivo (20),

caracterizado porque

dicha información relacionada con una calidad de servicio comprende información que indica una frecuencia que va a utilizar dicho primer dispositivo (30) para notificar una calidad de servicio conseguida a dicho segundo dispositivo (20)

Transmisión de información integrada relacionada con una calidad de servicio.

Campo de la invención

La invención se refiere a procedimientos de transmisión de información relacionada con una calidad de servicio, información que va a transmitirse en al menos un sentido entre un primer dispositivo y un segundo dispositivo. La invención también se refiere a dispositivos correspondientes, a elementos de red correspondientes y a sistemas correspondientes.

Antecedentes de la invención

Un servicio de una variedad de servicios para el que puede transmitirse información relacionada con una calidad de este servicio es un servicio de clase de flujo continuo de datos (streaming).

Para un servicio de clase de flujo continuo de datos, un servidor de flujo continuo de datos envía datos multimedia a través de una red a un cliente de flujo continuo de datos de manera que los datos multimedia puedan procesarse en el lado del cliente como un flujo estable y continuo. Un ejemplo de una aplicación de flujo continuo de datos es un producto de vídeo por Internet. El servidor de flujo continuo de datos también puede residir dentro de la red.

Los operadores de la red o los proveedores de servicio están interesados en poder evaluar la calidad de servicio (QoS) percibida por el usuario de un cliente de flujo continuo de datos. Actualmente, una sesión de flujo continuo de datos definida utilizando los protocolos normalizados en 3GPP TS 26.234 ofrece la posibilidad de conocer una cantidad de información limitada acerca de la calidad percibida por el usuario final. Los informes del receptor de protocolo de control de transporte en tiempo real (RTCP) se transmiten por el cliente al servidor para notificar la información relacionada con el comportamiento de la red, por ejemplo información acerca de las pérdidas de paquetes, variaciones de retardo, el mayor número de secuencia acumulativo recibido y otra información acerca de los paquetes del protocolo de transporte en tiempo real (RTP). Además, los informes del emisor RTCP se transmiten por el servidor al cliente, los cuales contienen información relacionada con el emisor.

Sin embargo, estos informes no permiten que un servidor de flujo continuo de datos, o que el operador a través de un servidor de flujo continuo de datos, obtenga alguna información adicional referente a la QoS percibida por el cliente de flujo continuo de datos, por ejemplo, referente al número de tramas de vídeo corruptas, la duración de almacenamientos repetidos en memoria intermedia (rebufferings), la duración de los intervalos sin audio, etc. Tal información puede transmitirse desde un cliente de flujo continuo de datos a un servidor de flujo continuo de datos simplemente ampliando la información actual transportada por los informes del protocolo de control de transporte en tiempo real (RTCP), los informes ampliados RTCP o los paquetes XR RTCP. Esta ampliación comprende un conjunto de métricas QoS que incluye información referente al establecimiento y desconexión de una sesión, intervalos sin voz ni audio, tramas de vídeo corruptas, el almacenamiento repetido en memoria intermedia y el almacenamiento inicial en memoria intermedia, pérdida de paquetes en una sucesión y posiblemente otra información relacionada con la sesión y la transmisión multimedia.

La IETF RFC 2328 (especificación RTSP, abril de 1998), la IETF RFC 3550 (especificación RTP, julio 2003) y el borrador de informes ampliados del protocolo de control RTP (XR RTCP, mayo de 2003), por ejemplo, permiten que un cliente de flujo continuo de datos notifique información referente a los paquetes RTP recibidos, incluyendo fracciones de pérdida de paquetes, variaciones de retardo, el mayor número de secuencia recibido y la secuencia de pérdidas de paquetes.

Los dos documentos del borrador Rel-6 "PSS Quality Metrics Permanent Document", reunión #27 TSG-S4 del 3GPP, del 7 al 11 de julio de 2003, Tdoc S4-030562 y "Stream Quality Metrics - Client metrics", reunión #26 TSG-S4 del 3GPP, del 5 al 9 de mayo de 2003, Tdoc S4- 030353 describen cuestiones generales adicionales de las métricas de QoS en el 3GPP (proyecto de colaboración de tercera generación). El primer documento describe qué información debe enviarse utilizando 25 parámetros diferentes de métrica de voz, audio, vídeo, reproductor y red, y qué tipo de protocolo debe usarse. Además, el segundo documento define consideraciones técnicas y requisitos de alto nivel. Los documentos definen un procedimiento en el que el cliente calcula la información y la envía al servidor cuando se solicite. Para fines de transporte, se propone utilizar un mensaje GET_PARAMETER del protocolo de flujo continuo de datos en tiempo real (RTSP) enviado desde el servidor al cliente y un mensaje SET_PARAMETER RTSP enviado desde el cliente al servidor.

Estos mensajes están definidos en mayor detalle en el documento "Streaming quality Metrics - Transport", reunión #28 TSG-S4 del 3GPP, del 1 al 5 de septiembre de 2003, Tdoc S4- 030629. Se propone la transmisión de un mensaje SET_PARAMETER RTSP desde el servidor al cliente para iniciar la métrica de QoS. El cliente puede responder con un mensaje 200 OK RTSP si acepta enviar métricas de QoS. Después, el servidor puede enviar una descripción de la sesión de métrica de QoS con un mensaje SET_PARAMETER adicional que incluye una descripción de sesión de métrica METRICS-SETUP que contiene un parámetro de intervalo, de periodo y de emisor. Además, este mensaje tiene que aceptarse por el cliente con un mensaje 200 OK RTSP. Como alternativa, el servidor puede pedir al cliente que proporcione una descripción de la sesión de métrica de QoS con un mensaje GET_PARAMETER. Una vez que la sesión de métrica de QoS se haya descrito y acordado, o bien un cliente puede enviar la métrica de QoS con un mensaje SET_PARAMETER, o bien el servidor puede obtener la métrica de QoS con un mensaje GET_PARAMETER.

Una desventaja de este enfoque es que los tres pares de mensajes requeridos generan un retardo que puede ralentizar el establecimiento de la sesión. El enfoque propuesto puede incluso establecer de manera errónea la sesión, ya que el cliente puede estar ya enviando el primer mensaje para adquirir los datos del servidor antes de recibir el segundo mensaje SET_PARAMETER.

Adrew S. Tanenbaum sugiere en el documento "Computer Networks", 31 de agosto de 2002 (31/08/2002), Pearson Education Inc., Upper Saddle River, NJ, USA, que se ofrezcan servicios diferenciados (DS) mediante un conjunto de encaminadores que formen un dominio administrativo. La administración define un conjunto de clases de servicio con reglas de reenvío correspondientes. Si un consumidor contrata DS, los paquetes del consumidor que entren en el dominio pueden transportar un campo de tipo de servicio, proporcionándose un mejor servicio a algunas clases que a otras.

Resumen de la invención

Un objeto de la invención es mejorar el suministro de información de calidad de servicio a un dispositivo, por ejemplo el suministro de información referente a la calidad percibida por el usuario final de un servicio de clase de flujo continuo de datos a un servidor de flujo continuo de datos.

Un objeto adicional de la invención es acelerar el establecimiento de una sesión entre dos dispositivos y evitar un establecimiento erróneo.

Se propone un procedimiento como el presentado en la reivindicación 1 adjunta, un código de software como el presentado en la reivindicación 10 adjunta y un dispositivo como el presentado en la reivindicación 11 adjunta.

Asimismo, se propone un elemento de red de una red, que comprende características correspondientes para la transmisión de información de calidad de servicio a un dispositivo que accede a esta red.

Sin embargo, según la invención se propone un sistema que comprende al menos dos dispositivos. El primer dispositivo se corresponde con el dispositivo propuesto anteriormente. El segundo dispositivo comprende una unidad de recepción para recibir un mensaje de protocolo transmitido por el primer dispositivo y un componente de extracción para extraer la información de calidad de servicio a partir de un mensaje de protocolo recibido.

La invención se basa en la consideración de que al menos parte de la información relacionada con una QoS puede incluirse en mensajes de protocolo que se transmiten de cualquier forma entre dos dispositivos.

Como resultado, el número de mensajes se reduce ya que se evitan los pares de mensaje dedicados para la información de QoS.

En comparación...

1. Un procedimiento de transmisión de información relacionada con una calidad de servicio, información que va a transmitirse en al menos un sentido entre un primer dispositivo (30) y un segundo dispositivo (20), comprendiendo dicho procedimiento en al menos en uno de dichos dispositivos (20, 30):

2. Un procedimiento según la reivindicación 1, en el que dicho mensaje de protocolo es uno de entre un mensaje de protocolo de flujo continuo de datos en tiempo real, un mensaje de protocolo de control de transporte en tiempo real y un mensaje de protocolo de inicio de sesión.

3. Un procedimiento según la reivindicación 1, en el que dicha transmisión se lleva a cabo cuando se establece una sesión entre dicho primer dispositivo (30) y dicho segundo dispositivo (20) para un servicio particular.

4. Un procedimiento según la reivindicación 1, en el que dicha transmisión se lleva a cabo durante una sesión entre dicho primer dispositivo (30) y dicho segundo dispositivo (20) para un servicio particular.

5. Un procedimiento según la reivindicación 1, en el que dicha información relacionada con una calidad de servicio comprende información referente a una calidad de servicio conseguida que va a notificar dicho primer dispositivo (30) a dicho segundo dispositivo (20).

6. Un procedimiento según la reivindicación 5, en el que dicha información referente a una calidad de servicio conseguida comprende información referente a al menos uno de entre un evento, una medición y una métrica asociados a una calidad de servicio conseguida.

7. Un procedimiento según la reivindicación 5, en el que dicha información referente a una calidad de servicio conseguida no se transmite durante un estado de pausa de dicho servicio.

8. Un procedimiento según la reivindicación 1, en el que dicha información relacionada con una calidad de servicio comprende información para negociar entre dicho primer dispositivo (30) y dicho segundo dispositivo (20) el grado en que dicho primer dispositivo (30) notifica acerca de una calidad de servicio conseguida a dicho segundo dispositivo (20).

9. Un procedimiento según la reivindicación 1, en que dicha información relacionada con una calidad de servicio se incluye en al menos uno de entre una cabecera de dicho mensaje de protocolo y un atributo de dicho mensaje de protocolo.

10. Un programa informático para transmitir información relacionada con una calidad de servicio, información que va a transmitirse en al menos un sentido entre un primer dispositivo (30) y un segundo dispositivo (20), realizando dicho programa informático las siguientes funciones cuando se ejecuta en un componente de procesamiento de al menos uno de dichos dispositivos (20, 30):

11. Un dispositivo (20, 30), que comprende:

12. El dispositivo (20, 30) según la reivindicación 11, que comprende además un componente (22, 32) de transmisión para transmitir un mensaje de protocolo ensamblado por dicho componente (21, 31) de ensamblaje a dicho otro dispositivo (30, 20).

13. El dispositivo (20, 30) según la reivindicación 11, en el que dicho mensaje de protocolo es uno de entre un mensaje de protocolo de flujo continuo de datos en tiempo real, un mensaje de protocolo de control de transporte en tiempo real y un mensaje de protocolo de inicio de sesión.

14. El dispositivo (20, 30) según la reivindicación 11, que comprende además un componente (22, 32) de transmisión para transmitir un mensaje de protocolo ensamblado por dicho componente (21, 31) de ensamblaje a dicho otro dispositivo (30, 20) cuando se establece una sesión entre dicho primer dispositivo (30) y dicho segundo dispositivo (20) para un servicio particular.

15. El dispositivo (20, 30) según la reivindicación 11, que comprende además un componente (22, 32) de transmisión para transmitir un mensaje de protocolo ensamblado por dicho componente (21, 31) de ensamblaje a dicho otro dispositivo (30, 20) durante una sesión entre dicho primer dispositivo (30) y dicho segundo dispositivo (20) para un servicio particular.

16. El dispositivo (20, 30) según la reivindicación 11, en el que dicho componente (21, 31) de ensamblaje está configurado para incluir en dicho mensaje de protocolo ensamblado información referente a una calidad de servicio conseguida que va a notificar dicho primer dispositivo (30) a dicho segundo dispositivo (20) como dicha información relacionada con una calidad de servicio.

17. El dispositivo (20, 30) según la reivindicación 16, en el que dicha información relacionada con una calidad de servicio conseguida comprende información referente a al menos uno de entre un evento, una medición y una métrica asociados con una calidad de servicio conseguida.

18. El dispositivo (20, 30) según la reivindicación 16, que comprende además un componente (22, 32) de transmisión para transmitir un mensaje de protocolo ensamblado por dicho componente (21, 31) de ensamblaje a dicho otro dispositivo (30, 20), en el que dicho componente (22, 32) de transmisión está configurado para transmitir dicha información relacionada con una calidad de servicio conseguida fuera de un estado de pausa de dicho servicio.

19. El dispositivo (20, 30) según la reivindicación 11, en el que dicho componente (21, 31) de ensamblaje está configurado para incluir en dicho mensaje de protocolo ensamblado información para negociar entre dicho primer dispositivo (30) y dicho segundo dispositivo (20) el grado en que dicho primer dispositivo (30) notifica acerca de una calidad de servicio conseguida a dicho segundo dispositivo (20) como dicha información relacionada con una calidad de servicio.

20. El dispositivo (20, 30) según la reivindicación 11, en el que dicho componente (21, 31) de ensamblaje está configurado para incluir dicha información relacionada con una calidad de servicio en al menos uno de entre una cabecera de dicho mensaje de protocolo y un atributo de dicho mensaje de protocolo.

21. El dispositivo según la reivindicación 11, en el que dicho dispositivo es un teléfono (30) móvil.

22. El dispositivo según la reivindicación 11, en el que dicho dispositivo es un elemento (20) de red de una red.

23. Un sistema que comprende al menos un primer dispositivo (20, 30) según una de las reivindicaciones 11 a 20 y un segundo dispositivo (30, 20), comprendiendo dicho segundo dispositivo (30, 20) una unidad (34, 24) de recepción para recibir un mensaje de protocolo transmitido por dicho primer dispositivo (20, 30); y

comprendiendo dicho segundo dispositivo (30, 20) un componente (33, 23) de extracción para extraer información de calidad de servicio a partir de un mensaje de protocolo recibido.