ES2338331T3 - Transmision de informacion integrada relacionada con calidad de servicio. - Google Patents
Transmision de informacion integrada relacionada con calidad de servicio. Download PDFInfo
- Publication number
- ES2338331T3 ES2338331T3 ES04769236T ES04769236T ES2338331T3 ES 2338331 T3 ES2338331 T3 ES 2338331T3 ES 04769236 T ES04769236 T ES 04769236T ES 04769236 T ES04769236 T ES 04769236T ES 2338331 T3 ES2338331 T3 ES 2338331T3
- Authority
- ES
- Spain
- Prior art keywords
- service
- quality
- message
- information related
- protocol
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/15—Flow control; Congestion control in relation to multipoint traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/33—Flow control; Congestion control using forward notification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/801—Real time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Devices For Checking Fares Or Tickets At Control Points (AREA)
- Monitoring And Testing Of Transmission In General (AREA)
- Computer And Data Communications (AREA)
- Mobile Radio Communication Systems (AREA)
- General Factory Administration (AREA)
Abstract
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).
Description
Transmisión de información integrada relacionada
con una calidad de servicio.
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.
\vskip1.000000\baselineskip
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.
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.
\vskip1.000000\baselineskip
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 con enfoques conocidos que
utilizan mensajes dedicados para transmitir información de QoS, una
ventaja de la invención es que requiere menos sobrecarga de
señalización, el intercambio de datos se acelera, permite un
establecimiento más rápido de una sesión y permite una manera
sencilla de intercambiar una mayor cantidad de información de QoS.
Tal mayor cantidad de información de QoS puede utilizarse, por
ejemplo, para negociar lo que se considerará como datos de QoS,
para transmitir más de una vez los datos de QoS considerados, para
modificar lo que se considerará como datos de QoS durante una sesión
en curso o para finalizar una transmisión de datos de QoS durante
una sesión. Si la información de QoS está incluida en mensajes de
configuración también puede evitarse un establecimiento erróneo.
Debe entenderse que el ensamblaje del mensaje de protocolo y que la
introducción de la información de QoS en este mensaje puede llevarse
a cabo en etapas posteriores, pero no tienen que llevarse a cabo
por separado. La introducción también puede formar parte del
ensamblaje del mensaje de protocolo. La información de QoS puede
introducirse además en cualquier parte de un mensaje de protocolo,
por ejemplo en un campo de cabecera del mensaje de protocolo o como
un atributo en el cuerpo del mensaje de protocolo. Una ventaja
adicional sería la posibilidad de definir la frecuencia de
notificación.
Según una realización de la invención, el
procedimiento propuesto comprende al menos en uno de los
dispositivos generar la información relacionada con una calidad de
servicio dentro de un campo de cabecera o de un atributo de un
mensaje de protocolo y transmitir el mensaje de protocolo al otro
dispositivo respectivo de entre el primer dispositivo y el segundo
dispositivo.
Según otra realización de la invención, el
código de software propuesto también genera la información
relacionada con una calidad de servicio dentro de al menos uno de
entre un campo de cabecera y un atributo de un mensaje de
protocolo.
\newpage
Según otra realización de la invención, el
componente de ensamblaje está configurado para generar una
información relacionada con una calidad de servicio dentro de al
menos uno de entre un campo de cabecera y un atributo de un mensaje
de protocolo.
Las realizaciones presentadas se basan en el
reconocimiento de que la utilización de una cabecera o de un
atributo de un mensaje de protocolo para transmitir información de
QoS es particularmente ventajosa ya que, en este caso, puede
utilizarse un único módulo de control para analizar los mensajes de
protocolo y extraer información, incluyendo información de QoS, y
después para proporcionar la información extraída a los módulos
necesarios del
sistema.
sistema.
Por lo tanto, las realizaciones presentadas
pueden basarse, por ejemplo, en un campo de cabecera RTSP
recientemente definido que se utilizará para transmitir la
información de QoS durante un establecimiento de sesión de clase de
flujo continuo de datos o durante una transmisión de datos de clase
de flujo continuo de datos.
Las alternativas a la utilización de un nuevo
atributo o cabecera RTSP utilizan una nueva definición de mensaje
RTSP para señalizar métricas de QoS, utilizando un campo
Content-Length e insertando un cuerpo de
mensaje al final de un mensaje RTSP, o definiendo un conjunto de
parámetros relacionado con métricas de QoS para su utilización con
los mensajes SET_PARAMETER y GET_PARAMETER. Un implementador puede
elegir no utilizar un campo de cabecera RTSP para las métricas de
QoS con el fin de separar totalmente la señalización de métricas de
QoS de la señalización de nivel de sesión.
En general, el mensaje de protocolo puede ser en
particular, pero no exclusivamente, un mensaje RTSP, un mensaje
RTCP, un mensaje de protocolo de inicio de sesión (SIP) o una
descripción de protocolo de descripción de sesión (SDP). Una
ventaja específica de utilizar mensajes RTSP en los procedimientos
propuestos es que este protocolo proporciona transmisiones
flexibles que son más fiables que las transmisiones RTCP.
El servicio con el que está relacionada la
calidad de servicio puede ser, por ejemplo, aunque no
exclusivamente, un servicio de clase de flujo continuo de datos. El
RTSP y el RTCP pueden utilizarse en particular para tal servicio de
clase de flujo continuo de datos. Por consiguiente, los dispositivos
propuestos pueden ser, por ejemplo, una unidad de recepción o una
unidad de transmisión para un servicio de clase de flujo continuo de
datos, es decir, un cliente de flujo continuo de datos o un
servidor de flujo continuo de datos. La invención proporciona
maneras particularmente adecuadas que permiten a un servidor de
flujo continuo de datos descubrir cómo un cliente de flujo continuo
de datos recibe realmente los datos y tener más información acerca
de la calidad de la experiencia del usuario (QoE, calidad de
experiencia), así como acerca de los problemas que puede encontrar
una sesión de flujo continuo de
datos.
datos.
Otros servicios pueden ser, por ejemplo, voz
sobre IP, videotelefonía o vídeo conversacional unidireccional. El
protocolo SIP de conferencia puede utilizarse en particular para
tales otros servicios.
La transmisión del mensaje de protocolo puede
llevarse a cabo, por ejemplo, durante el establecimiento de una
sesión y/o durante una sesión en curso para el servicio respectivo.
La información de QoS en un mensaje de protocolo respectivo puede
comprender, por ejemplo, un informe acerca de la QoS conseguida para
un servicio actual. Este informe puede incluir, en particular,
parámetros y/o datos sin procesar proporcionados por un dispositivo
a otro. Los datos sin procesar pueden incluir, por ejemplo,
notificaciones relacionadas con eventos o datos de medición,
mientras que los parámetros, que también se denominan como métricas,
son datos procesados. Además, la información de QoS puede
comprender una solicitud desde un primer dispositivo a un segundo
dispositivo para proporcionar tal información referente a la QoS
conseguida para un servicio actual y/o datos que definen la
información referente a la QoS conseguida que va a proporcionarse.
Tales datos también pueden formar parte de una negociación entre
los dispositivos acerca del grado y frecuencia de la información
referente a la QoS conseguida que va a proporcionarse en un informe
respectivo.
En una realización ventajosa, por ejemplo, para
un servicio de clase de flujo continuo de datos, la información de
QoS está incluida en un mensaje de protocolo de descripción de
sesión (SDP) o en un campo de cabecera en un mensaje 200 OK de
respuesta DESCRIPTION RTSP, en un mensaje SETUP RTSP, en un mensaje
PLAY RTSP, en un mensaje PAUSE RTSP o en un mensaje TEARDOWN RTSP.
Preferentemente, un mensaje de "configuración de parámetros de
métrica de QoS" está incluido en un mensaje SDP dentro de la
respuesta a un mensaje DESCRIPTION RTSP. Además, preferentemente,
un mensaje de "modificación de parámetros de métrica de QoS"
está incluido en cualquier mensaje RTSP como PAUSE, generado por el
dispositivo cliente o por un usuario del dispositivo cliente. Debe
observarse que el SDP no puede utilizarse durante una sesión.
Con el fin de definir la notificación de QoS,
por ejemplo para un servicio de clase de flujo continuo de datos,
debe definirse un conjunto de requisitos mínimos. A continuación se
definen propiedades de la notificación de QoS que son adecuadas
para maximizar su utilidad y potencia para un servicio de flujo
continuo de datos. Debe entenderse que las propiedades
correspondientes son también ventajosas para otros tipos de
servicios. Resulta ventajoso si la notificación de QoS puede
negociarse al principio de un flujo continuo de datos y durante una
sesión en curso. Resulta ventajoso si la notificación de QoS siempre
se solicita por el servidor de flujo continuo de datos. Resulta
ventajoso si existe la posibilidad de agrupar un conjunto de
métricas en un único mensaje. El servidor puede solicitar al
cliente, mediante un único mensaje, que notifique un único elemento
de datos no procesados o un único parámetro o múltiples elementos de
datos no procesados y/o parámetros. Resulta ventajoso además si
existe la posibilidad adicional de negociar la notificación al nivel
de sesión o al nivel multimedia como una propiedad de granularidad,
por ejemplo, para minimizar la información enviada a través de una
interfaz inalámbrica y para elegir de manera selectiva qué notificar
y desde qué medio. También resulta ventajoso si existe la
posibilidad de activar/desactivar la notificación.
La frecuencia de notificación puede ser
periódica, activada por evento o al final de una sesión. En caso de
una notificación periódica, el servidor de flujo continuo de datos
solicita el periodo y el cliente de flujo continuo de datos lo
acepta. El cliente de flujo continuo de datos responde con los
valores acordados, que pueden ser menos óptimos que los solicitados
por el servidor. En caso de una notificación activada por evento,
el cliente de flujo continuo de datos notifica los eventos de
"mala calidad". Esto minimiza la cantidad de información
transmitida desde el cliente de flujo continuo de datos al servidor
de flujo continuo de datos. Una notificación al final de la sesión
puede crear problemas si la sesión termina de manera anormal. Si es
servicio está en un estado de pausa, el cliente no puede enviar
datos de retroalimentación de QoS con el fin de evitar la
utilización innecesaria de recursos de radio con datos ficticios. El
servidor debe poder manejar una interrupción de este tipo.
Preferentemente, la métrica de QoS se calcula en
el servidor. Es decir, el cliente de flujo continuo de datos
notifica un conjunto de eventos y/o mediciones, y el servidor lleva
a cabo los cálculos, por ejemplo la determinación del mínimo, la
media y/o el máximo de algunos valores a través de una ventana de
tiempo especificada. El servidor de flujo continuo de datos puede
aplazar el cálculo de estadísticas reales hasta el final de la
sesión o hasta momentos de una baja carga de trabajo. Como
alternativa, la métrica puede calcularse en el cliente. En este
caso, la complejidad en el cliente debe ser mínima.
Además, debe asegurarse que los diferentes
servidores calculen la métrica de QoS de la misma manera, con el
fin de garantizar la objetividad.
Puesto que las métricas de capa 3 y 4
(L3-L4) están disponibles a través de notificaciones
RTCP corrientes o de notificaciones XR RTCP, la invención es
particularmente adecuada para la transmisión de métricas de capa 5
(L5) y de datos sin procesar. El cliente debe poder almacenar en
memoria intermedia una pluralidad de informes de QoS y enviarlos en
un único informe añadiendo una especificación de intervalo de tiempo
con el fin de minimizar el número de mensajes enviados a través de
la interfaz inalámbrica. Ejemplos de información enviada son el ID
de sesión, la duración entre corrupciones, una indicación de tiempo,
etc.
Otros objetos y características de la presente
invención resultarán evidentes a partir de la siguiente descripción
detallada considerada junto con los dibujos adjuntos. Sin embargo,
debe entenderse que los dibujos están diseñados solamente para
fines ilustrativos y no como una definición de los límites de la
invención, para los cuales debe hacerse referencia a las
reivindicaciones adjuntas. Además, debe entenderse que los dibujos
no están dibujados a escala y que están destinados simplemente a
ilustrar de manera conceptual las estructuras y procedimientos
descritos en este documento.
\vskip1.000000\baselineskip
La fig. 1 muestra esquemáticamente un sistema en
el que puede implementarse la invención;
la fig. 2 es una tabla que presenta eventos y
mediciones que pueden detectarse por un cliente del sistema de la
figura 1;
la fig. 3 es una tabla que presenta un ejemplo
de métricas que pueden calcularse por un cliente del sistema de la
figura 1; y
la fig. 4 es un diagrama de señalización
esquemático que ilustra una realización del procedimiento según la
invención.
\vskip1.000000\baselineskip
La figura 1 presenta esquemáticamente un sistema
10 en el que puede utilizarse la invención.
El sistema 10 comprende un servidor 20 de flujo
continuo de datos que proporciona, a modo de ejemplo, flujo
continuo de datos de vídeo bajo demanda. El sistema 10 comprende
además un cliente 30 de flujo continuo de datos que puede
implementarse, por ejemplo, en un teléfono móvil. El cliente 30 de
flujo continuo de datos está conectado a través de una red 40 al
servidor 20 de flujo continuo de datos y puede demandar y recibir
una aplicación de flujo continuo de datos de vídeo desde el servidor
20 de flujo continuo de datos. La red 40 puede comprender, por
ejemplo, conectadas entre sí, una red móvil pública terrestre
(PLMN), a la que el teléfono móvil con el cliente 30 de flujo
continuo de datos puede acceder, y la red de Internet, a la que el
servidor 20 de flujo continuo de datos puede conectarse. Debe
entenderse que el cliente 30 de flujo continuo de datos también
puede ser parte de un elemento de red de la red 40.
El servidor 20 de flujo continuo de datos
incluye un componente 21 de ensamblaje, que ensambla mensajes RTSP,
conectado a un transmisor 22 TX, y un componente 23 de extracción,
que extrae datos de QoS, conectado a un receptor 24 RX. El cliente
30 de flujo continuo de datos también incluye un componente 31 de
ensamblaje, que ensambla mensajes RTSP, conectado a un transmisor
32 TX, y un componente 33 de extracción, que extrae datos de QoS,
conectado a un receptor 34 RX. Los componentes 21, 23, 31 y 33
pueden realizarse, en particular, mediante software pero también
mediante hardware.
El cliente 30 de flujo continuo de datos puede
proporcionar tres tipos de valores de QoS para su transmisión a un
servidor de flujo continuo de datos, concretamente eventos,
mediciones y métricas. Los eventos se definen como incidentes o
errores en el cliente 30 de flujo continuo de datos que provocan
anomalías y diferencias a partir de una hipotética fruición libre
de errores de referencia del medio y pueden comprender, por ejemplo,
la duración de un intervalo sin voz. Las mediciones se definen como
un sistema de seguimiento para supervisar una sesión de flujo
continuo de datos en condiciones normales o anormales y pueden
comprender, por ejemplo, el tiempo de establecimiento de sesión.
Las métricas son cálculos basados en eventos y mediciones y pueden
comprender, por ejemplo, la duración media y/o máxima de un
intervalo sin voz.
En el sistema 10 de la figura 1 está
implementado un procedimiento que puede controlar una transmisión de
eventos, mediciones y métricas desde el cliente 30 de flujo
continuo de datos al servidor 20 de flujo continuo de datos. Más
específicamente, todos los datos de QoS en cualquier sentido entre
el cliente 30 de flujo continuo de datos y el servidor 20 de flujo
continuo de datos, incluyendo también eventos, mediciones y métricas
como datos de negociación y de definición de QoS, se incluyen para
su transmisión mediante el componente 21, 31 de ensamblaje,
respectivamente, en un mensaje RTSP ensamblado de cualquier forma
para algún otro propósito. Después, el mensaje RTSP suplementario
se transmite por el transmisor 22, 32 de la unidad 20, 30 de
transmisión respectiva a través de la red 40 al receptor 32, 24 de
la unidad 30, 20 de recepción respectiva. En la unidad 30, 20 de
recepción respectiva, los datos de QoS se extraen para una
utilización adicional a partir del mensaje RTSP recibido en el
componente de extracción respectivo de extracción de datos 33, 23 de
QoS.
Si los eventos o mediciones se transmiten por el
cliente 30 de flujo continuo de datos, entonces el cliente de flujo
continuo de datos sólo detecta los eventos y/o mediciones y los
notifica al servidor 20 de flujo continuo de datos. Después, el
servidor 20 de flujo continuo de datos lleva a cabo el cálculo de
las métricas. Si las métricas se determinan y se transmiten por el
cliente 30 de flujo continuo de datos, el servidor 20 de flujo
continuo de datos recibe métricas precalculadas. Si el cliente 30 de
flujo continuo de datos calcula las métricas, se requiere más
potencia de procesamiento en el teléfono móvil y los datos que
tienen que transmitirse son más extensos ya que pueden calcularse
varias métricas a partir de un evento o medición.
Ejemplos de eventos y mediciones que puede
detectar el cliente 30 de flujo continuo de datos se muestran en la
tabla de figura 2, mientras que ejemplos de métricas que puede
calcular un cliente 30 de flujo continuo de datos o el servidor 20
de flujo continuo de datos se muestran en la tabla de la figura 3.
Debe entenderse que la lista de eventos, mediciones y métricas
utilizada en el sistema 10 puede ser diferente de las
presentadas.
Además, se proporcionan cuatro maneras de
definir la frecuencia de transmisión de mensajes de
retroalimentación desde el cliente 30 de flujo continuo de datos al
servidor 20 de flujo continuo de datos que comprenden eventos,
mediciones y/o métricas.
En una primera alternativa periódica, los
mensajes de retroalimentación se envían durante una sesión según
una determinada planificación. Esto brinda la posibilidad de una
acción de servidor para ajustar la QoS del (de los)
flujo(s) multimedia transmitido(s), si fuera necesario. Dependiendo de la frecuencia definida, esto puede provocar algún tráfico adicional en el sentido del enlace ascendente si el periodo de notificación es demasiado corto. En una segunda alternativa basada en eventos, los mensajes de retroalimentación se envían en base a la aparición de eventos en el cliente 30. Este procedimiento también brinda posibilidades de que el servidor 20 realice una acción durante la sesión, si fuera necesario. Si la tasa de eventos es muy elevada puede generarse mucho tráfico adicional en el sentido del enlace ascendente a menos que se añadan muchos eventos en el mismo mensaje. En una tercera alternativa, un mensaje de retroalimentación se envía una sola vez al final de la sesión. Este procedimiento es muy eficaz en lo que respecta al ancho de banda pero los eventos notificados pueden dejar de ser relevantes al final de la sesión. En una cuarta alternativa, un mensaje de retroalimentación con los eventos, mediciones o métricas de la sesión anterior se envía al principio de la siguiente sesión. Este procedimiento tiene la desventaja de que los eventos notificados pueden haberse producido varios días antes, dependiendo de la frecuencia con la que el usuario utilice el servicio, y no ser ya relevantes.
flujo(s) multimedia transmitido(s), si fuera necesario. Dependiendo de la frecuencia definida, esto puede provocar algún tráfico adicional en el sentido del enlace ascendente si el periodo de notificación es demasiado corto. En una segunda alternativa basada en eventos, los mensajes de retroalimentación se envían en base a la aparición de eventos en el cliente 30. Este procedimiento también brinda posibilidades de que el servidor 20 realice una acción durante la sesión, si fuera necesario. Si la tasa de eventos es muy elevada puede generarse mucho tráfico adicional en el sentido del enlace ascendente a menos que se añadan muchos eventos en el mismo mensaje. En una tercera alternativa, un mensaje de retroalimentación se envía una sola vez al final de la sesión. Este procedimiento es muy eficaz en lo que respecta al ancho de banda pero los eventos notificados pueden dejar de ser relevantes al final de la sesión. En una cuarta alternativa, un mensaje de retroalimentación con los eventos, mediciones o métricas de la sesión anterior se envía al principio de la siguiente sesión. Este procedimiento tiene la desventaja de que los eventos notificados pueden haberse producido varios días antes, dependiendo de la frecuencia con la que el usuario utilice el servicio, y no ser ya relevantes.
En el sistema de la figura 1, la transmisión de
datos de QoS se lleva a cabo principalmente en dos fases, una fase
de negociación durante un establecimiento de conexión de una sesión
de flujo continuo de datos y una fase de retroalimentación durante
una sesión de flujo continuo de datos en curso. Ambas fases se
describirán a continuación con referencia a la figura 4. La figura
4 es un diagrama de señalización esquemático que presenta una
señalización entre el servidor 20 de flujo continuo de datos y el
cliente 30 de flujo continuo de datos. Además, se permiten fases de
renegociación durante la sesión de flujo continuo de datos en
curso.
\newpage
En un establecimiento de conexión RTSP para una
sesión de flujo continuo de datos, el cliente 30 de flujo continuo
de datos y el servidor 20 de flujo continuo de datos negocian qué
métricas, mediciones y eventos enviar y con qué frecuencia. Para la
negociación se define la siguiente nueva cabecera
QoS-Metrics, la cual es diferente de una cabecera
definida en el documento mencionado anteriormente en la reunión #28
TSG-SA4:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Esta cabecera puede ser parte de cualquier
mensaje RTSP transmitido por el servidor 20 de flujo continuo de
datos o por el cliente 30 de flujo continuo de datos.
Hay dos modos de utilizar el campo
QoS-Metrics definido. Si solo se utiliza el
parámetro Off, esto es una indicación de que el servidor 20
o el cliente 30 desean cancelar la transmisión de eventos,
mediciones y métricas. Si, por otro lado, la cabecera contiene
otros parámetros, es decir, stream-url, Metrics,
Sending-rate y posiblemente Range,
entonces se solicita el inicio o el reinicio, respectivamente, de la
transmisión de las métricas.
El campo stream-url es un
identificador session url RTSP o un identificador media
control url RTSP. Si la cabecera se utiliza con la
información Session Control url RTSP, entonces el campo
QoS-Metrics se utiliza en el nivel de
sesión. Si el url es un Media Control url RTSP,
entonces el campo QoS-Metrics se utiliza en
el nivel multimedia y cada medio obtiene su propia línea
QoS-Metrics. Es posible hacer referencia al
mismo url más de una vez. Si la información
Sending-Rate y Range son diferentes
que la definida anteriormente, entonces los nuevos parámetros de
métrica se consideran como un conjunto de parámetros diferente, el
cual es válido para ese url particular pero para diferentes
métricas. En caso contrario, no debe hacerse referencia más de una
vez al mismo url de control RTSP para los mismos valores
Sending-Rate y Range.
El campo Metrics se utiliza para limitar
la cantidad de métricas, mediciones y eventos que van a notificarse.
Contiene la lista de nombres que describe las métricas, mediciones
y eventos requeridos que van a notificarse en una sesión. Los
nombres que no estén incluidos en el campo Metrics no se utilizan en
la sesión.
El campo Sending-Rate se
utiliza para ajustar la frecuencia de envío. Si el valor de
Sending-rate es 0, entonces el cliente 30
puede enviar mensajes de retroalimentación en cualquier momento
dependiendo de los eventos que se produzcan en el cliente 30.
Valores mayores que 1 indican un intervalo de envío de mensajes
preciso en segundos. 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 diferentes medios, pero
se recomienda mantener algún tipo sincronización para evitar
tráfico adicional. El valor End indica que sólo se envía un
mensaje de retroalimentación al final de la
sesión.
sesión.
El campo Range puede utilizarse para
definir el límite de tiempo del envío de retroalimentación. Es
similar al envío del parámetro Off pero permite decidir de
antemano el intervalo de tiempo de un estado On durante la
fase de negociación.
El campo QoS-Metrics
definido puede controlar la situación en la que los cálculos de
métrica se llevan a cabo en el servidor 20 de flujo continuo de
datos y en la que el cliente 30 de flujo continuo de datos sólo
envía eventos y/o mediciones al servidor, y también la situación en
la que el cliente 30 de flujo continuo de datos envía métricas
precalculadas al servidor 20 de flujo continuo de datos.
\newpage
Además, un nuevo atributo SDP
QoS-Metrics está definido, el cual puede
utilizarse como un atributo SDP de nivel multimedia o de sesión. La
sintaxis de definición está basada en RFC 2327, la cual se incorpora
en este documento como referencia:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Para abrir una sesión de flujo continuo de
datos, el cliente 30 de flujo continuo de datos transmite una
solicitud DESCRIBE RTSP, como el mensaje 1 de la figura 4, al
servidor 20 de flujo continuo de datos:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
La representación C->S indica una transmisión
desde el cliente 30 al servidor 20.
La negociación real del campo
QoS-Metrics puede iniciarse entonces con la
primera respuesta DESCRIBE de la siguiente manera.
Después de haber recibido la solicitud 1
DESCRIBE desde el cliente 30, el servidor 20 muestra la información
de métrica de QoS deseada en la descripción SDP utilizando el
atributo SDP QoS-Metrics. Estas métricas
pueden definirse a nivel de sesión o a nivel multimedia en el SDP.
Esto proporciona flexibilidad al proceso de QoS, de manera que
componentes multimedia importantes pueden supervisarse en mayor
detalle. El servidor 20 de flujo continuo de datos introduce la
descripción SDP en una respuesta 200 OK DESCRIBE y transmite la
respuesta como el mensaje 2 de la figura 4 al cliente 30 de flujo
continuo de datos. También es posible que el servidor muestre las
métricas de QoS en el mensaje de respuesta DESCRIBE utilizando la
cabecera QoS-Metrics en lugar de utilizando
el atributo SDP. El cliente 30 de flujo continuo de datos debe
comprobar la existencia de esta cabecera en la respuesta.
Debe observarse que en el documento mencionado
anteriormente en la reunión #28 TSG-S4 ya se
necesitan cuatro mensajes de QoS dedicados en este punto.
A continuación se presenta un ejemplo de un
mensaje de nivel de sesión correspondiente, donde los parámetros de
sesión solicitados son RTSPSetupTime e
InitialBufferingTime, donde los parámetros de vídeo
solicitados son Framegapmax y Framegap_ave y donde
los parámetros de audio solicitados son AudioGap_ave y
AudioGap_max. Debe observarse que los nombres de los
parámetros son solo ejemplos y que un nombre respectivo puede
indicar métricas, mediciones y/o eventos.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
La representación S->C indica una transmisión
desde el servidor 20 al cliente 30.
La negociación de QoS puede llevarse a cabo en
cualquier fase durante la sesión si una parte desea permitir
señalización de métrica de QoS. En el ejemplo aquí mostrado, esto se
realiza en la fase de establecimiento de sesión utilizando el
atributo SDP. También es posible enviar las métricas QoS en
cualquier otro mensaje RTSP utilizando el atributo SDP
QoS-Metrics o el campo de cabecera
QoS-Metrics según la invención.
El cliente 30 de flujo continuo de datos
selecciona las métricas QoS aceptables mostradas en el atributo SDP
del mensaje 200 OK recibido o sugiere nuevos valores en una primera
solicitud SETUP. Si el cliente 30 soporta métricas de QoS, entonces
debe enviar una solicitud SETUP o algún otro mensaje RTSP que
contenga las métricas de QoS seleccionadas/modificadas para el
nivel de sesión o para el nivel multimedia que esté configurándose.
Este mensaje de solicitud SETUP se indica en la figura 4 como el
mensaje 3. Un mensaje RTSP alternativo puede ser, por ejemplo, la
solicitud PLAY, indicada en la figura 4 como el mensaje 5. A
continuación se presenta un mensaje SETUP correspondiente a modo de
ejemplo:
\vskip1.000000\baselineskip
En el ejemplo de solicitud SETUP anterior, el
cliente 30 de flujo continuo de datos modifica la frecuencia de
envío de métricas de QoS para el URL de control
"rtsp://example.com/foo/bar/baz.3gp/trackID=3" de 15 a 10.
Con el fin de indicar que se soportan métricas
de QoS tanto de nivel de sesión como de nivel multimedia, el
cliente 30 de flujo continuo de datos debe enviar todas las métricas
de QoS soportadas y/o modificadas relacionadas con el nivel
multimedia. También debe enviar las métricas de QoS de nivel de
sesión seleccionadas en al menos una de las solicitudes SETUP.
El servidor 20 de flujo continuo de datos recibe
esta solicitud SETUP y devuelve un mensaje 200 OK con las métricas
de QoS aceptadas transmitidas por el cliente 30 incluidas para
volver a confirmar los cambios. Este mensaje 200 OK se indica en la
figura 4 como el mensaje 4. El servidor 20 de flujo continuo de
datos también puede rechazar los cambios realizados por el cliente
30 de flujo continuo de datos en el mensaje 200 OK. Para rechazar
los cambios, el servidor 20 de flujo continuo de datos puede o bien
fijar nuevos valores y devolver las métricas modificadas al cliente
30 de flujo continuo de datos incluidas en el mensaje 200 OK, o bien
puede simplemente ignorar esas métricas y no confirmarlas.
Suponiendo que el servidor 20 de flujo continuo
de datos confirma los cambios, puede devolver la siguiente
respuesta SETUP a modo de ejemplo:
\vskip1.000000\baselineskip
Cuando el cliente 30 de flujo continuo de datos
recibe este mensaje 4 200 OK como respuesta a su solicitud 3 SETUP,
entiende que el servidor 20 de flujo continuo de datos soporta
métricas de QoS. Además, el cliente 30 entiende que el servidor 20
aceptó soportar las métricas mostradas en la cabecera RTSP
QoS-Metrics.
La misma señalización se lleva a cabo para los
otros componentes multimedia en la sesión. La negociación de
métricas de QoS de nivel de sesión no puede repetirse en este
caso.
Si el servidor 20 de flujo continuo de datos no
aprueba las modificaciones realizadas por el cliente 30 de flujo
continuo de datos, el servidor 20 y el cliente 30 pueden seguir
renegociando hasta una solicitud PLAY RTSP del cliente 30, indicada
en la figura 4 como el mensaje 5. La respuesta PLAY RTSP posterior
del servidor 20, indicada en la figura 4 como el mensaje 6,
devuelve después la métrica de QoS final negociada incluyendo todos
los valores de métrica de QoS del nivel de sesión y multimedia.
Debe observarse que cada vez que se envía un
campo de cabecera QoS-Metrics en una
solicitud RTSP, también debe estar presente en la respuesta
correspondiente a esa solicitud particular. Si no, el receptor 20,
30 de la respuesta asume que el otro extremo 30, 20 respectivo no
soporta métricas de QoS.
Debe observarse además que el cliente 30 de
flujo continuo de datos puede poseer ya la descripción SDP antes de
iniciar la sesión, por ejemplo en forma de archivo. Si la
descripción SDP se recupera mediante otros medios que la respuesta
DESCRIBE del servidor 20 particular, el primer mensaje recibido por
el servidor de flujo continuo de datos es el mensaje 3 SETUP de la
figura 4. Las flechas asociadas con el mensaje 1 de solicitud
DESCRIBE y el mensaje 2 de respuesta DESCRIBE de la figura 4 se
muestran por lo tanto solamente con líneas discontinuas. El cliente
30 de flujo continuo de datos puede transmitir en este caso
información de métrica de QoS inicial para la negociación en el
mensaje 3 SETUP. Si el mensaje 3 SETUP incluye información de
métrica de QoS, el servidor 20 de flujo continuo de datos puede
aceptar las métricas o sugerir otras nuevas en la respuesta 4
SETUP, y la negociación de métrica de QoS puede continuar en los
siguientes mensajes RTSP descritos anteriormente. Si el primer
mensaje 3 SETUP no incluye la información de métricas de QoS y el
servidor 20 de flujo continuo de datos desea negociar las métricas
de QoS con el cliente 30 de flujo continuo de datos, el servidor 20
de flujo continuo de datos puede solicitar una notificación de
información de métrica de QoS del cliente 30 de flujo continuo de
datos utilizando la respuesta 4 SETUP. Si el cliente 30 de flujo
continuo de datos acepta las métricas de QoS solicitadas o desea
modificarlas, el cliente 30 de flujo continuo de datos debe incluir
la información de métrica en el siguiente mensaje RTSP. Si no hay
ninguna información de métrica de QoS en el siguiente mensaje RTSP,
entonces esto indica que el cliente 30 de flujo continuo de datos no
soporta métricas de QoS.
Después de que haya finalizado la negociación,
el cliente 30 de flujo continuo de datos puede iniciar el envío de
mensajes de retroalimentación.
Los mensajes de retroalimentación también deben
enviarse utilizando un mecanismo de transporte fiable. Es posible
utilizar para este fin cualquier par
solicitud-respuesta RTSP utilizado durante la sesión
de flujo continuo de datos. Por ejemplo, si un mensaje PAUSE RTSP
se envía de todos modos durante la sesión, un mensaje de
retroalimentación puede incluirse dentro de este mensaje PAUSE. Si
un mensaje de retroalimentación va a enviarse solamente al final de
la sesión, es posible utilizar un mensaje TEARDOWN RTSP para evitar
tráfico innecesario. Este mensaje TEARDOWN se utiliza de todos
modos para enviar el último mensaje de retroalimentación, también
en caso de notificación de retroalimentación periódica.
Para la retroalimentación, también está definida
una nueva cabecera. La siguiente cabecera puede soportar
procedimientos de envío relacionados con eventos, mediciones o
métricas. La sintaxis de definición se basa en RFC 2326, la cual
también se incorpora en este documento como referencia:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
El campo Stream-url es el
identificador session url RTSP o el identificador media
control url RTSP para el parámetro de retroalimentación. El
campo Metrics en la definición Parameters contiene el
nombre de las métricas, mediciones o eventos, y debe ser el mismo
que el campo Metrics en el campo de negociación
QoS-Metrics. Se recomienda mantener el mismo
orden de las métricas para simplificar el análisis sintáctico. El
campo Value indica los resultados de las métricas. El campo
Timestamp opcional indica el tiempo en que se produjo el
evento o medición, o cuando se calculó la métrica. La cabecera
también permite notificar cero eventos incluyendo un espacio
(SP).
Si los eventos y mediciones se utilizan en el
envío de métricas, existe la posibilidad de que el mismo evento se
produzca más de una vez durante un periodo de envío. En ese caso,
los tipos de métricas, es decir, el nombre de los eventos o
mediciones, pueden aparecer más de una vez, lo que indica el número
de eventos al servidor.
Si el protocolo para los mensajes de
retroalimentación va a ser RTCP en lugar de RTSP, es posible
utilizar paquetes APP RTCP (paquete RTCP definido por aplicación,
tipo de paquete 204), o las extensiones de paquetes RR RTCP
(informe de receptor, tipo de paquete 201). Sea cual sea el paquete
utilizado, éste debe contener al menos un campo Metrics, un
campo Value y, opcionalmente, un campo Timestamp.
Metrics es el nombre de las métricas o la indicación de un
mensaje vacío (ASCII o número). Value es el resultado de las
métricas (número). Timestamp es el tiempo en que se produjo
el evento o en que se calcularon las métricas (número), y solo se
proporciona opcionalmente. Las cabeceras RTCP contienen información
sobre el medio particular, de manera que no hay necesidad de
repetir esa información con campos adicionales.
En los mensajes de retroalimentación, la
cabecera QoS-Feedback solo contiene las
métricas QoS-Metrics actualizadas. Si un
parámetro métrico no está presente, pero se negoció durante la fase
de configuración, entonces se supone que ese parámetro métrico no
se ha modificado/actualizado. El cliente 30 de flujo continuo de
datos puede utilizar el siguiente mensaje en cualquier mensaje RTSP
después de la solicitud PLAY. Este mensaje se indica en la figura 4
como el mensaje 7. Debe observarse que los nombres de los parámetros
son solo ejemplos.
\vskip1.000000\baselineskip
También es posible concatenar mensajes de
retroalimentación RTSP con el fin de evitar una tasa de envío de
mensajes demasiado alta, por ejemplo debido a un envío basado en
eventos.
Como alternativa a un mensaje de
retroalimentación RTSP, el cliente 30 de flujo continuo de datos
puede utilizar, por ejemplo, el siguiente mensaje RR RTCP para
notificar datos de QoS:
\vskip1.000000\baselineskip
Además, como alternativa, el cliente puede
utilizar, por ejemplo, el siguiente mensaje APP RTCP:
\vskip1.000000\baselineskip
Si se están notificando mediciones o eventos en
lugar de métricas calculadas, la descripción de evento puede
incluir más de un valor. Esto puede resultar interesante, por
ejemplo, si durante el periodo de notificación hay dos eventos
distintos en los que se pierden paquetes RTP.
\newpage
El siguiente ejemplo para su utilización en un
mensaje RTSP incluye además la información Timestamp
adicional:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
El siguiente ejemplo para su utilización en un
mensaje RR RTCP también incluye la información Timestamp
opcional:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
El siguiente ejemplo para su utilización en un
mensaje APP RTCP también incluye la información Timestamp
opcional:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Es posible que o bien el servidor 20 de flujo
continuo de datos o bien el cliente 30 desee modificar los
parámetros negociados durante una sesión. El servidor 20 puede
desear, por ejemplo, alguna información más a menudo, mientras que
el cliente 30 puede percatarse de que no puede proporcionar tantos
parámetros como los que se acordaron. También es posible desactivar
todo el envío de métricas de QoS. Para iniciarlo de nuevo
posteriormente, el cliente 30 de flujo continuo de datos o el
servidor 20 de flujo continuo de datos puede enviar una nueva
solicitud. Durante una sesión de flujo continuo de datos en curso,
es posible utilizar cualquier mensaje RTSP para renegociar los
parámetros métricos de QoS. Cualquier cambio de una notificación
negociada inicialmente también queda incluido en el mensaje 7 de la
figura 4.
\newpage
A continuación se muestra un ejemplo de una
solicitud de modificación por parte del cliente 30 o por parte del
servidor 20 durante una sesión, o una solicitud de reinicio por
parte del cliente 30 o por parte del servidor 20 durante una sesión
después de que las métricas de QoS se hayan desactivado:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Una respuesta a la solicitud de modificación que
indica una aceptación de la solicitud se define para ambos sentidos
por ejemplo de la siguiente manera:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Una respuesta a la solicitud de modificación que
indica un rechazo de la solicitud se define para ambos sentidos por
ejemplo de la siguiente manera:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Si no se aceptan los nuevos valores, los
parámetros utilizados anteriormente se repiten indicando que la
situación negociada anteriormente permanece invariable. La lista de
métricas es siempre absoluta. No hay modo de ampliar o reducir la
lista actual, sino que la nueva lista de métricas sustituye a la
anterior lista.
A continuación se muestra un ejemplo de un
mensaje del cliente 30 o del servidor 20 durante una sesión para
desactivar las métricas:
\vskip1.000000\baselineskip
Debe observarse que las métricas pueden
desactivarse a nivel de sesión o a nivel multimedia. El url indica
qué nivel utilizar. En el ejemplo anterior, las métricas se
desactivan a nivel de sesión para todos los medios.
\newpage
Si se acepta la solicitud para desactivar las
métricas, la respuesta se define para ambos sentidos por ejemplo de
la siguiente manera:
Si la se rechaza solicitud para desactivar las
métricas, la respuesta se define para ambos sentidos por ejemplo de
la siguiente manera:
Es decir, si la desactivación no se acepta, los
parámetros utilizados anteriormente se repiten indicando que la
situación negociada anteriormente permanece invariable. Es posible
renegociar los parámetros de envío si fuera necesario.
La implementación del cliente 30 de flujo
continuo de datos es más sencilla si solo se requiere detección de
eventos.
Una ventaja del procedimiento presentado es que
los mensajes pueden enviarse periódicamente, y que los mensajes
están diseñados para que sean lo más pequeño posible.
El procedimiento descrito permite transmitir más
información que el del documento mencionado anteriormente en la
reunión #28 TSG-S4 del 3GPP. Además, el
procedimiento presentado hace más rápida la configuración ya que se
requieren menos mensajes. El procedimiento propuesto también tiene
la ventaja de que permite negociar cada una de las métricas
utilizadas. Además, brinda la posibilidad de renegociar el envío de
métricas en mitad de una sesión, si fuera necesario, y también de
desactivar todo el envío de métricas si fuera necesario.
El procedimiento presentado proporciona además
una indicación de tiempo para las métricas, describiendo de manera
más precisa el tiempo del evento que el intervalo utilizado en otras
soluciones. Un mensaje vacío se define para el caso en que no haya
eventos que describir en un envío de mensajes periódico. También es
posible concatenar varios mensajes con el fin de optimizar el envío
de mensajes.
Claims (23)
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):
- 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).
\vskip1.000000\baselineskip
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):
- ensamblar un mensaje de protocolo para otra finalidad que la transmisión de dicha información relacionada con una calidad de servicio; e
- incluir dicha información relacionada con una calidad de servicio en dicho mensaje de protocolo;
- 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).
11. Un dispositivo (20, 30), que comprende:
- un componente (21, 31) de ensamblaje adaptado para ensamblar un mensaje de protocolo para otra finalidad que la transmisión de información relacionada con una calidad de servicio y adaptado para incluir información relacionada con una calidad de servicio en dicho mensaje, información de calidad de servicio que va a transmitirse a un segundo dispositivo (30, 20),
- caracterizado porque
- dicha información relacionada con una calidad de servicio comprende información que indica una frecuencia que va a utilizar uno de entre dicho dispositivo (20, 30) y dicho segundo dispositivo (30, 20) para notificar una calidad de servicio conseguida al otro dispositivo respectivo de entre dicho dispositivo (30, 20) y dicho segundo dispositivo (20, 30).
\vskip1.000000\baselineskip
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.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US49963803P | 2003-09-02 | 2003-09-02 | |
| US499638P | 2003-09-02 | ||
| US51346003P | 2003-10-21 | 2003-10-21 | |
| US513460P | 2003-10-21 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2338331T3 true ES2338331T3 (es) | 2010-05-06 |
Family
ID=34278668
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04769236T Expired - Lifetime ES2338331T3 (es) | 2003-09-02 | 2004-09-01 | Transmision de informacion integrada relacionada con calidad de servicio. |
Country Status (11)
| Country | Link |
|---|---|
| US (3) | US8239521B2 (es) |
| EP (2) | EP1661366B1 (es) |
| JP (2) | JP4456115B2 (es) |
| CN (1) | CN1846420B (es) |
| AT (2) | ATE522068T1 (es) |
| DE (1) | DE602004025590D1 (es) |
| ES (1) | ES2338331T3 (es) |
| IL (1) | IL173303A (es) |
| NO (1) | NO338788B1 (es) |
| RU (1) | RU2363111C2 (es) |
| WO (1) | WO2005022865A1 (es) |
Families Citing this family (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2363111C2 (ru) * | 2003-09-02 | 2009-07-27 | Нокиа Корпорейшн | Передача информации, относящейся к качеству обслуживания |
| WO2005088929A1 (en) * | 2004-02-12 | 2005-09-22 | Nokia Corporation | Classified media quality of experience |
| US8010652B2 (en) * | 2004-05-07 | 2011-08-30 | Nokia Corporation | Refined quality feedback in streaming services |
| KR100640862B1 (ko) * | 2004-08-03 | 2006-11-02 | 엘지전자 주식회사 | 순방향 메시지 전송 중 타임아웃의 동적 제어방법 |
| US8966551B2 (en) | 2007-11-01 | 2015-02-24 | Cisco Technology, Inc. | Locating points of interest using references to media frames within a packet flow |
| US9197857B2 (en) | 2004-09-24 | 2015-11-24 | Cisco Technology, Inc. | IP-based stream splicing with content-specific splice points |
| US7783635B2 (en) | 2005-05-25 | 2010-08-24 | Oracle International Corporation | Personalization and recommendations of aggregated data not owned by the aggregator |
| US8365306B2 (en) * | 2005-05-25 | 2013-01-29 | Oracle International Corporation | Platform and service for management and multi-channel delivery of multi-types of contents |
| US7917612B2 (en) * | 2005-05-25 | 2011-03-29 | Oracle International Corporation | Techniques for analyzing commands during streaming media to confirm delivery |
| CN100456834C (zh) * | 2005-10-17 | 2009-01-28 | 华为技术有限公司 | H.264多媒体通信的服务质量监测方法 |
| US20070239820A1 (en) * | 2005-11-23 | 2007-10-11 | Nokia Corporation | System and method for providing quality feedback metrics for data transmission in rich media services |
| US20070130358A1 (en) * | 2005-12-02 | 2007-06-07 | Mike Severa | Faster Than Real Time Streaming in a Playlist Context |
| KR100848128B1 (ko) * | 2006-04-24 | 2008-07-24 | 한국전자통신연구원 | 실시간 스트리밍 프로토콜을 이용한 프로그래시브 스트리밍방법 |
| US20070271590A1 (en) * | 2006-05-10 | 2007-11-22 | Clarestow Corporation | Method and system for detecting of errors within streaming audio/video data |
| US8521843B2 (en) * | 2006-05-25 | 2013-08-27 | Qualcomm Incorporated | Methods and apparatus for sampling usage information from a pool of terminals in a data network |
| US8560672B2 (en) * | 2006-05-25 | 2013-10-15 | Qualcomm Incorporated | Methods and apparatus for bandwidth efficient transmission of usage information from a pool of terminals in a data network |
| US8560463B2 (en) | 2006-06-26 | 2013-10-15 | Oracle International Corporation | Techniques for correlation of charges in multiple layers for content and service delivery |
| PL2615833T3 (pl) * | 2006-10-19 | 2014-10-31 | Ericsson Telefon Ab L M | Sposób określania jakości obrazu video |
| US8959239B2 (en) * | 2006-12-29 | 2015-02-17 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for reporting streaming media quality |
| US8010093B2 (en) | 2007-03-08 | 2011-08-30 | Infineon Technologies Ag | Communication network unit and method for exchanging capability information |
| US7936695B2 (en) * | 2007-05-14 | 2011-05-03 | Cisco Technology, Inc. | Tunneling reports for real-time internet protocol media streams |
| CN101335908B (zh) * | 2007-06-26 | 2012-11-07 | 华为技术有限公司 | 传输媒体内容的方法以及网络侧设备 |
| CN101350741A (zh) * | 2007-07-20 | 2009-01-21 | 华为技术有限公司 | 实时流协议事件通知方法、装置及系统 |
| US8526315B2 (en) * | 2007-08-23 | 2013-09-03 | Cisco Technology, Inc. | Flow state attributes for producing media flow statistics at a network node |
| CN102075905B (zh) * | 2009-11-19 | 2014-11-05 | 中兴通讯股份有限公司 | 通话链路质量统计信息上报的方法及系统 |
| EP2532133A1 (en) * | 2010-02-05 | 2012-12-12 | Telefonaktiebolaget L M Ericsson (PUBL) | Method and network node for monitoring a quality of media transfer in a session initiation protocol based voice over internet protocol communications network |
| JP5523130B2 (ja) * | 2010-02-08 | 2014-06-18 | キヤノン株式会社 | 通信装置、通信方法、及びプログラム |
| US10015543B1 (en) * | 2010-03-08 | 2018-07-03 | Citrix Systems, Inc. | Video traffic, quality of service and engagement analytics system and method |
| US20110252152A1 (en) * | 2010-04-09 | 2011-10-13 | Marcus Sherry | Reliable messaging system and method |
| US9247404B2 (en) * | 2011-02-09 | 2016-01-26 | PlatinumTel Communications, LLC | Delivery of advertisements over voice network |
| US20130195119A1 (en) * | 2011-10-14 | 2013-08-01 | Qualcomm Incorporated | Feedback channel for wireless display devices |
| US8842840B2 (en) | 2011-11-03 | 2014-09-23 | Arvind Gidwani | Demand based encryption and key generation and distribution systems and methods |
| US20130138829A1 (en) * | 2011-11-30 | 2013-05-30 | Rovi Technologies Corporation | Scalable video coding over real-time transport protocol |
| US9553756B2 (en) * | 2012-06-01 | 2017-01-24 | Koninklijke Kpn N.V. | Fingerprint-based inter-destination media synchronization |
| US9565622B2 (en) * | 2012-07-05 | 2017-02-07 | Qualcomm Incorporated | Detecting services provided by a wireless node before device discovery and connection establishment |
| CN102866777A (zh) * | 2012-09-12 | 2013-01-09 | 中兴通讯股份有限公司 | 一种数字媒体内容播放转移的方法及播放设备及系统 |
| US9077631B2 (en) * | 2012-10-04 | 2015-07-07 | Verizon Patent And Licensing Inc. | Network capacity planning |
| US9438652B2 (en) | 2013-04-15 | 2016-09-06 | Opentv, Inc. | Tiered content streaming |
| US20150146012A1 (en) * | 2013-11-27 | 2015-05-28 | Sprint Communications Company L.P. | Video presentation quality display in a wireless communication device |
| WO2015192311A1 (en) * | 2014-06-17 | 2015-12-23 | Telefonaktiebolaget L M Ericsson(Publ) | Reporting quality of experience of receiving digital content |
| EP3281328B1 (en) * | 2015-04-09 | 2020-06-03 | Telefonaktiebolaget LM Ericsson (PUBL) | Method and device for scheduling of feedback |
| US9693063B2 (en) * | 2015-09-21 | 2017-06-27 | Sling Media Pvt Ltd. | Video analyzer |
| US9749686B2 (en) | 2015-09-21 | 2017-08-29 | Sling Media Pvt Ltd. | Video analyzer |
| US10419580B2 (en) | 2015-09-28 | 2019-09-17 | Evenroute, Llc | Automatic QoS optimization in network equipment |
| US11303513B2 (en) | 2015-09-28 | 2022-04-12 | Evenroute, Llc | Automatic QoS optimization in network equipment |
| US11310298B2 (en) | 2016-03-07 | 2022-04-19 | Intel Corporation | Technologies for providing hints usable to adjust properties of digital media |
| RU172333U1 (ru) * | 2016-07-26 | 2017-07-04 | федеральное государственное автономное образовательное учреждение высшего образования "Самарский национальный исследовательский университет имени академика С.П. Королева" | Программно-аппаратный комплекс для измерения метрик производительности IP-сетей |
| WO2018231693A1 (en) * | 2017-06-12 | 2018-12-20 | Evenroute, Llc | Automatic qos optimization in network equipment |
| CN111586886B (zh) * | 2019-02-15 | 2022-05-13 | 华为技术有限公司 | 一种无线回传链路的控制方法及装置 |
Family Cites Families (84)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5799317A (en) * | 1995-11-08 | 1998-08-25 | Mci Communications Corporation | Data management system for a telecommunications signaling system 7(SS#7) |
| RU2189072C2 (ru) * | 1996-01-31 | 2002-09-10 | Ипсилон Нетуоркс, Инк. | Усовершенствованный способ и устройство для динамического смещения между пакетами маршрутизации и коммутации в сети передачи данных |
| US5867495A (en) | 1996-11-18 | 1999-02-02 | Mci Communications Corporations | System, method and article of manufacture for communications utilizing calling, plans in a hybrid network |
| US6909708B1 (en) | 1996-11-18 | 2005-06-21 | Mci Communications Corporation | System, method and article of manufacture for a communication system architecture including video conferencing |
| US6690654B2 (en) | 1996-11-18 | 2004-02-10 | Mci Communications Corporation | Method and system for multi-media collaboration between remote parties |
| US5867494A (en) | 1996-11-18 | 1999-02-02 | Mci Communication Corporation | System, method and article of manufacture with integrated video conferencing billing in a communication system architecture |
| WO1998023080A2 (en) | 1996-11-18 | 1998-05-28 | Mci Worldcom, Inc. | A communication system architecture |
| US5958009A (en) * | 1997-02-27 | 1999-09-28 | Hewlett-Packard Company | System and method for efficiently monitoring quality of service in a distributed processing environment |
| JP4114970B2 (ja) * | 1997-03-24 | 2008-07-09 | ソニー株式会社 | 情報信号伝送装置 |
| JP3022478B2 (ja) * | 1998-04-22 | 2000-03-21 | 松下電器産業株式会社 | 洗濯機 |
| US6567425B1 (en) | 1998-04-23 | 2003-05-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Bearer independent signaling protocol |
| JP3225924B2 (ja) * | 1998-07-09 | 2001-11-05 | 日本電気株式会社 | 通信品質制御装置 |
| US6434134B1 (en) * | 1998-12-11 | 2002-08-13 | Lucent Technologies, Inc. | Dynamic address assignment for wireless devices accessing packet-based wired networks |
| US6654359B1 (en) * | 1998-12-11 | 2003-11-25 | Lucent Technologies Inc. | Wireless access to packet-based networks |
| US6405250B1 (en) * | 1999-01-25 | 2002-06-11 | Lucent Technologies Inc. | Network management system based on passive monitoring and proactive management for formulation behavior state transition models |
| EP1033848B1 (en) * | 1999-02-26 | 2008-12-03 | Lucent Technologies Inc. | Proxy server supporting IP quality of service |
| JP2000295276A (ja) | 1999-04-02 | 2000-10-20 | Hitachi Ltd | 通信制御システム |
| US6957255B1 (en) * | 1999-06-28 | 2005-10-18 | Amdocs (Israel) Ltd. | Method and apparatus for session reconstruction and accounting involving VoIP calls |
| US6839751B1 (en) * | 1999-06-30 | 2005-01-04 | Hi/Fn, Inc. | Re-using information from data transactions for maintaining statistics in network monitoring |
| US6553515B1 (en) * | 1999-09-10 | 2003-04-22 | Comdial Corporation | System, method and computer program product for diagnostic supervision of internet connections |
| US6970930B1 (en) * | 1999-11-05 | 2005-11-29 | Mci, Inc. | Method and system of providing differentiated services |
| US7054268B1 (en) | 2000-02-04 | 2006-05-30 | Nokia Mobile Phones, Inc. | Method and arrangement for transferring information in a packet radio service with application-based choice of release mode |
| FI113827B (fi) * | 2000-02-17 | 2004-06-15 | Wicom Comm Oy | Pakettiverkkopuhelinjärjestelmä |
| AU773636B2 (en) | 2000-02-22 | 2004-05-27 | Blackberry Limited | System and method for controlling a wireless packet switched voice call |
| US20020174227A1 (en) * | 2000-03-03 | 2002-11-21 | Hartsell Neal D. | Systems and methods for prioritization in information management environments |
| US20020152305A1 (en) * | 2000-03-03 | 2002-10-17 | Jackson Gregory J. | Systems and methods for resource utilization analysis in information management environments |
| US6757732B1 (en) * | 2000-03-16 | 2004-06-29 | Nortel Networks Limited | Text-based communications over a data network |
| US6941551B1 (en) * | 2000-04-11 | 2005-09-06 | Microsoft Corporation | Method and system for creating a quality of service message |
| US20020119821A1 (en) * | 2000-05-12 | 2002-08-29 | Sanjoy Sen | System and method for joining a broadband multi-user communication session |
| US6845389B1 (en) * | 2000-05-12 | 2005-01-18 | Nortel Networks Limited | System and method for broadband multi-user communication sessions |
| US20010049732A1 (en) * | 2000-06-01 | 2001-12-06 | Raciborski Nathan F. | Content exchange apparatus |
| US7688745B1 (en) * | 2000-08-14 | 2010-03-30 | Nokia Siemens Networks Oy | Communication system and method providing a mode selection procedure |
| JP2002077257A (ja) | 2000-08-31 | 2002-03-15 | Nippon Telegr & Teleph Corp <Ntt> | ストリーム配信ネットワークサービス方法およびシステム |
| CA2419609C (en) | 2000-09-01 | 2011-11-29 | Ncube Corporation | Dynamic quality adjustment based on changing streaming constraints |
| US20020114274A1 (en) * | 2000-09-19 | 2002-08-22 | Sturges James H. | Packet based network for supporting real time applications |
| US6763392B1 (en) * | 2000-09-29 | 2004-07-13 | Microsoft Corporation | Media streaming methods and arrangements |
| JP3478259B2 (ja) | 2000-10-23 | 2003-12-15 | 日本電信電話株式会社 | ストリーム中継制御装置、ストリーム中継制御システム、ストリーム中継制御方法，ならびに該方法を記録した記録媒体 |
| US20020059432A1 (en) * | 2000-10-26 | 2002-05-16 | Shigeto Masuda | Integrated service network system |
| US7028092B2 (en) * | 2000-12-11 | 2006-04-11 | Acme Packet, Inc. | System and method for assisting in controlling real-time transport protocol flow through multiple networks via media flow routing |
| JP2002217972A (ja) | 2001-01-12 | 2002-08-02 | Nec Corp | 輻輳状況対応型ＶｏＩＰシステム、及び、ＶｏＩＰシステムの輻輳回避方法 |
| US6965592B2 (en) * | 2001-01-24 | 2005-11-15 | Tekelec | Distributed signaling system 7 (SS7) message routing gateway |
| JP2002271373A (ja) | 2001-03-07 | 2002-09-20 | Hitachi Ltd | Ｍｐｌｓポリシールーティング機能を有するインタネットワーク装置 |
| US20020131395A1 (en) * | 2001-03-19 | 2002-09-19 | Chenghui Wang | Session initiation protocol (SIP) user agent in a serving GPRS support node (SGSN) |
| JP2002300274A (ja) | 2001-03-30 | 2002-10-11 | Fujitsu Ltd | ゲートウェイ装置及び音声データ転送方法 |
| US7213071B2 (en) * | 2001-04-03 | 2007-05-01 | International Business Machines Corporation | Quality of service improvements for network transactions |
| JP3872311B2 (ja) * | 2001-04-03 | 2007-01-24 | 日本電信電話株式会社 | ネットワーク品質管理方法、その装置、そのプログラム及びそのプログラムを記録した媒体 |
| US7454527B2 (en) * | 2001-05-02 | 2008-11-18 | Microsoft Corporation | Architecture and related methods for streaming media content through heterogeneous networks |
| US7197557B1 (en) * | 2001-05-29 | 2007-03-27 | Keynote Systems, Inc. | Method and system for evaluating quality of service for streaming audio and video |
| ES2329442T3 (es) * | 2001-07-10 | 2009-11-26 | NOKIA SIEMENS NETWORKS GMBH & CO. KG | Procedimiento para realizar una transferencia (handoff) orientada a la qos entre una primera y una segunda ruta de comunicacion basada en ip, en particular movil y basada en ipv6, entre un nodo movil (mn) y un nodo corresponsal (cn). |
| JP2003037623A (ja) * | 2001-07-23 | 2003-02-07 | Philips Japan Ltd | Ｍｐｅｇネットワーク上におけるダイレクトｒｔｐ伝送方法及びシステム |
| JP2003070059A (ja) | 2001-08-23 | 2003-03-07 | Ntt Docomo Inc | 移動パケット通信システム、及び、移動パケット通信網における通信規制方法 |
| JP2003069632A (ja) | 2001-08-28 | 2003-03-07 | Nippon Telegr & Teleph Corp <Ntt> | 複数フロー識別型コンテンツ配信品質制御システム及びその処理プログラムと記録媒体 |
| US7272651B1 (en) * | 2001-08-28 | 2007-09-18 | Cisco Technology, Inc. | RSVP transmitter proxy |
| US6996393B2 (en) * | 2001-08-31 | 2006-02-07 | Nokia Corporation | Mobile content delivery system |
| US7490146B1 (en) * | 2001-09-17 | 2009-02-10 | Ricoh Company, Ltd. | System, method, and computer program product for collecting and sending various types of information to a monitor using e-mail |
| JP2003110558A (ja) | 2001-09-28 | 2003-04-11 | Oki Electric Ind Co Ltd | 通信品質監視システム |
| US20030074452A1 (en) * | 2001-10-11 | 2003-04-17 | Nokia Corporation | System and method of determining QoS establishment mode |
| KR100547852B1 (ko) * | 2002-01-09 | 2006-02-01 | 삼성전자주식회사 | 이동통신 시스템에서 호 수락 방법 |
| US7570766B2 (en) * | 2002-03-01 | 2009-08-04 | Intel Corporation | Transparently embedding non-compliant data in a data stream |
| US7453851B2 (en) * | 2002-06-20 | 2008-11-18 | Spyder Navigations L.L.C. | QoS signaling for mobile IP |
| US7725557B2 (en) * | 2002-06-24 | 2010-05-25 | Microsoft Corporation | Client-side caching of streaming media content |
| US20040003101A1 (en) * | 2002-06-26 | 2004-01-01 | Roth David J. | Caching control for streaming media |
| US7337236B2 (en) * | 2002-07-02 | 2008-02-26 | International Business Machines Corporation | Application prioritization in a stateless protocol |
| US7301951B2 (en) * | 2002-07-31 | 2007-11-27 | At&T Knowledge Ventures, L.P. | Resource reservation protocol based guaranteed quality of service internet protocol connections over a switched network |
| JP4520705B2 (ja) * | 2003-04-11 | 2010-08-11 | パナソニック株式会社 | 通信システム及び通信方法 |
| US7536460B2 (en) * | 2003-05-15 | 2009-05-19 | At&T Intellectual Property I, L.P. | Session and application level bandwidth and/or QoS modification |
| CA2528871C (en) * | 2003-06-12 | 2014-01-21 | Camiant, Inc. | Pcmm application manager |
| MXPA06002026A (es) | 2003-08-21 | 2006-08-31 | Vidiator Entpr Inc | Metrica de calidad de experiencia (qoe) para redes de comunicacion inalambrica. |
| RU2363111C2 (ru) * | 2003-09-02 | 2009-07-27 | Нокиа Корпорейшн | Передача информации, относящейся к качеству обслуживания |
| US7707511B2 (en) * | 2003-11-18 | 2010-04-27 | Gary Edward Peterson | Interactive risk management system and method |
| US8176117B2 (en) * | 2003-12-19 | 2012-05-08 | Stmicroelectronics, Inc. | Accelerator for object-oriented communications and method |
| US7263095B1 (en) * | 2004-02-12 | 2007-08-28 | Cingular Wireless Ii Llc | Method and apparatus for providing quality of service through multiple carrier IP networks |
| US7483385B2 (en) * | 2004-03-26 | 2009-01-27 | Hewlett-Packard Development Company, L.P. | Process for monitoring the quality of service in a telecommunication network and apparatus for the same |
| US7792275B2 (en) * | 2005-07-29 | 2010-09-07 | Verizon Patent And Licensing Inc. | Application service invocation |
| EP1758334A1 (en) * | 2005-08-26 | 2007-02-28 | Matsushita Electric Industrial Co., Ltd. | Establishment of media sessions with media adaptation |
| US7580423B2 (en) * | 2005-09-30 | 2009-08-25 | Intel Corporation | Integrated message publisher and subscriber system in multiple technology facilities |
| US8982713B2 (en) * | 2006-03-24 | 2015-03-17 | Qualcomm Incorporated | Quality of service configuration for wireless communication |
| FR2900528B1 (fr) * | 2006-04-27 | 2008-06-20 | Radiotelephone Sfr | Procede et systeme pour accelerer l'acces a un contenu a partir d'un terminal mobile |
| US8929360B2 (en) * | 2006-12-07 | 2015-01-06 | Cisco Technology, Inc. | Systems, methods, media, and means for hiding network topology |
| US20080228912A1 (en) * | 2007-03-16 | 2008-09-18 | Ramakrishna Vedantham | Enhanced Quality Reporting for Transmission Sessions |
| US7908362B2 (en) * | 2007-12-03 | 2011-03-15 | Velocix Ltd. | Method and apparatus for the delivery of digital data |
| US8140089B2 (en) * | 2008-05-19 | 2012-03-20 | Intel Corporation | Network selection for multiple network platforms |
| CN101299881A (zh) * | 2008-06-06 | 2008-11-05 | 中兴通讯股份有限公司 | 一种资源接纳控制方法及系统 |
| US7953883B2 (en) * | 2009-01-27 | 2011-05-31 | Cisco Technology, Inc. | Failover mechanism for real-time packet streaming sessions |
-
2004
- 2004-09-01 RU RU2006110511/09A patent/RU2363111C2/ru not_active IP Right Cessation
- 2004-09-01 AT AT09170714T patent/ATE522068T1/de not_active IP Right Cessation
- 2004-09-01 EP EP04769236A patent/EP1661366B1/en not_active Expired - Lifetime
- 2004-09-01 JP JP2006525204A patent/JP4456115B2/ja not_active Expired - Fee Related
- 2004-09-01 ES ES04769236T patent/ES2338331T3/es not_active Expired - Lifetime
- 2004-09-01 CN CN2004800248764A patent/CN1846420B/zh not_active Expired - Fee Related
- 2004-09-01 AT AT04769236T patent/ATE458343T1/de not_active IP Right Cessation
- 2004-09-01 WO PCT/IB2004/002826 patent/WO2005022865A1/en not_active Ceased
- 2004-09-01 DE DE602004025590T patent/DE602004025590D1/de not_active Expired - Lifetime
- 2004-09-01 US US11/793,077 patent/US8239521B2/en not_active Expired - Fee Related
- 2004-09-01 EP EP09170714A patent/EP2129073B1/en not_active Expired - Lifetime
-
2006
- 2006-01-23 IL IL173303A patent/IL173303A/en active IP Right Grant
- 2006-01-26 NO NO20060432A patent/NO338788B1/no not_active IP Right Cessation
-
2008
- 2008-12-18 JP JP2008322231A patent/JP2009118498A/ja active Pending
-
2012
- 2012-07-02 US US13/540,161 patent/US8380848B2/en not_active Expired - Fee Related
-
2013
- 2013-02-15 US US13/768,662 patent/US9178748B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US9178748B2 (en) | 2015-11-03 |
| EP2129073A1 (en) | 2009-12-02 |
| US20120278499A1 (en) | 2012-11-01 |
| JP4456115B2 (ja) | 2010-04-28 |
| EP2129073B1 (en) | 2011-08-24 |
| RU2363111C2 (ru) | 2009-07-27 |
| NO338788B1 (no) | 2016-10-17 |
| CN1846420B (zh) | 2011-06-08 |
| ATE522068T1 (de) | 2011-09-15 |
| US20130159518A1 (en) | 2013-06-20 |
| EP1661366A1 (en) | 2006-05-31 |
| ATE458343T1 (de) | 2010-03-15 |
| RU2006110511A (ru) | 2007-10-20 |
| US8380848B2 (en) | 2013-02-19 |
| DE602004025590D1 (de) | 2010-04-01 |
| WO2005022865A1 (en) | 2005-03-10 |
| CN1846420A (zh) | 2006-10-11 |
| US20080215704A1 (en) | 2008-09-04 |
| US8239521B2 (en) | 2012-08-07 |
| EP1661366B1 (en) | 2010-02-17 |
| NO20060432L (no) | 2006-03-22 |
| JP2007504736A (ja) | 2007-03-01 |
| IL173303A0 (en) | 2006-06-11 |
| IL173303A (en) | 2011-08-31 |
| JP2009118498A (ja) | 2009-05-28 |
| HK1094630A1 (en) | 2007-04-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2338331T3 (es) | Transmision de informacion integrada relacionada con calidad de servicio. | |
| KR101237019B1 (ko) | 체감 품질 보고를 위한 시스템 및 방법 | |
| EP3962092B1 (en) | Method and apparatus for receiving multicast video using a playlist | |
| JP6591567B2 (ja) | サービスレート調整方法及び装置 | |
| KR20180009046A (ko) | 다중 경로 미디어 전달을 위한 방법 및 장치 | |
| KR102132266B1 (ko) | 데이터 스트리밍에 대한 보조의 노드 타입 기반 제어 | |
| CN108696772A (zh) | 一种实时视频的传输方法及装置 | |
| CN109417548A (zh) | 封装媒体流量在基于数据报的传输层上的高效传输 | |
| US7310323B2 (en) | Method and system for providing a transmission link for streaming traffic | |
| KR101054787B1 (ko) | Ｉｍｓ 인스턴트 메시지를 전송하기 위한 방법, 시스템, 및장치 | |
| CN102668508B (zh) | 利用特定uri的质量参数协商的方法 | |
| KR20080089980A (ko) | 유비쿼터스 브로드캐스트 멀티캐스트 서비스 시스템 및장치 이를 이용한 서비스 제공 방법 | |
| KR20160097538A (ko) | Udp기반의 멀티캐스트로 컨텐츠를 제공하는 방법, 서버 그리고 사용자 단말 | |
| CN120238970A (zh) | 基于有线接入的QoS处理方法、装置、可读介质及设备 | |
| CN119484490A (zh) | 窄带卫星通信中sip协议定制化裁剪系统及方法 | |
| CN104917585A (zh) | 报文交互方法和装置 | |
| HK1094630B (en) | Transmission of embedded information relating to a quality of service | |
| KR20150047890A (ko) | 고품질 서비스를 위한 트래픽 처리 방법 및 그 장치 |