ES2315876T3 - Procedimiento para asignar recursos en un sistema de comunicaciones. - Google Patents
Procedimiento para asignar recursos en un sistema de comunicaciones. Download PDFInfo
- Publication number
- ES2315876T3 ES2315876T3 ES05751173T ES05751173T ES2315876T3 ES 2315876 T3 ES2315876 T3 ES 2315876T3 ES 05751173 T ES05751173 T ES 05751173T ES 05751173 T ES05751173 T ES 05751173T ES 2315876 T3 ES2315876 T3 ES 2315876T3
- Authority
- ES
- Spain
- Prior art keywords
- transmission
- network
- communications device
- media
- data
- 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/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
- 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/80—Actions related to the user profile or the type of traffic
- H04L47/808—User-type aware
-
- 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/82—Miscellaneous aspects
- H04L47/824—Applicable to portable or mobile terminals
-
- 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/82—Miscellaneous aspects
- H04L47/825—Involving tunnels, e.g. MPLS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/26—Resource reservation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/12—Setup of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/15—Setup of multiple wireless link connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
- H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Time-Division Multiplex Systems (AREA)
- Radio Relay Systems (AREA)
Abstract
Un procedimiento en un sistema de comunicaciones que comprende: seleccionar al menos un flujo de medios para ser transmitido (402) desde un dispositivo de comunicaciones emisor (10) a un dispositivo de comunicaciones receptor (MT1) al menos parcialmente a través de una red de comunicaciones sin hilos (NW1), definir los requisitos de QoS (403, 405) para la transmisión del mencionado, al menos uno, flujo de medios seleccionados, reservar (404, 406) recursos de transmisión de la red de comunicaciones sin hilos (NM1) para la transmisión del mencionado al menos uno, flujo de datos de medios, realizar un procedimiento de configuración (407 - 410) entre el dispositivo de comunicaciones receptor (MT1) y el dispositivo de comunicaciones emisor (10) para activar al menos una conexión de transmisión de datos por paquetes, caracterizado porque el mencionado procedimiento incluye la transmisión (407, 409) de información acerca de los recursos reservados al dispositivo de comunicaciones emisor, comprendiendo la información acerca de los recursos reservados al menos uno de los siguientes parámetros para la conexión de transmisión de datos: - velocidad binaria máxima, - velocidad binaria garantizada, - retardo de transferencia; solicitar (411) por parte del dispositivo de comunicaciones receptor (MT1) el inicio de la transmisión de al menos un flujo de datos de medios, y transmitir (412) flujos de datos de medios desde el dispositivo de comunicaciones emisor (10) a un dispositivo de comunicaciones receptor (MT1) por medio de la utilización de un contexto PDP para cada uno de los flujos de datos de medios seleccionado.
Description
Procedimiento para asignar recursos en un
sistema de comunicaciones.
El área de la tecnología es la de medios de
flujos de datos sobre redes móviles, en las que un servidor
multimedia, una red móvil y un cliente de flujo de datos están
conectados lógicamente, por ejemplo a través de un protocolo RTSP
(Protocolo de Flujo de Datos en Tiempo Real) usado para la
configuración de la sesión y para el control de la misma, y por
ejemplo, un protocolo RTP (Protocolo de Transporte en Tiempo Real)
para la transferencia de medios. Los sistemas de flujos de datos
pueden ser adaptables en velocidad o no. Esta invención está
relacionada con sistemas de flujo de datos adaptables en velocidad
que pueden adaptar el contenido y/o la velocidad de la transmisión
de acuerdo con las condiciones variables del canal de red.
La presente invención se refiere a un
procedimiento en un sistema de comunicaciones, en el que se
transmiten flujos de datos multimedia desde un dispositivo de
comunicación emisor a un dispositivo de comunicación receptor al
menos parcialmente a través de una red de comunicaciones sin hilos.
La invención se refiere también a un sistema de comunicaciones que
comprende un dispositivo de comunicación emisor, un dispositivo de
comunicación receptor y una red de comunicaciones para la
transmisión de los flujos de datos multimedia desde el dispositivo
de comunicación emisor al dispositivo de comunicación receptor al
menos parcialmente a través de una red de comunicaciones sin hilos.
La invención se refiere además a un dispositivo de comunicación
emisor y a un dispositivo de comunicación receptor.
En esta descripción, el término dispositivo de
comunicación emisor hace referencia a un dispositivo de comunicación
que incluye un transmisor que está configurado para enviar flujos
de datos multimedia a una red de comunicaciones. El término
dispositivo de comunicación receptor hace referencia a un
dispositivo de comunicación que incluye un receptor para recibir
flujos de datos multimedia desde la red de comunicaciones,
respectivamente. Es obvio que el mismo dispositivo de comunicación
puede incluir tanto el transmisor como el receptor permitiendo por
medio de esto la comunicación unidireccional o la comunicación
bidireccional con la red de comunicaciones. Un dispositivo de
comunicación sin hilos incluye un transmisor y/o un receptor que
implementan la comunicación sin hilos en una red de comunicaciones
sin hilos. El término sistema de comunicaciones sin hilos, tal como
un sistema de comunicaciones móviles, por lo general hace referencia
a cualquier sistema de comunicaciones que haga posible una conexión
de transmisión de datos sin hilos entre un dispositivo de
comunicación sin hilos y partes estacionarias del sistema, el
usuario del dispositivo de comunicación sin hilos estando en
movimiento dentro del intervalo operativo del sistema. Un sistema
sin hilos típico es una Red Móvil Pública Terrestre (PLMN). Un
ejemplo bien conocido es el sistema GSM (Sistema Global para
Comunicaciones Móviles). La invención de manera preferible se
refiere a la tercera generación de sistemas de comunicaciones
móviles. Como un ejemplo, el Sistema de Telecomunicaciones Móviles
Universales (UMTS) se usa como un ejemplo de dicho sistema de
comunicaciones de tercera generación.
En los sistemas de tercera generación, se usan
los términos servicio de portadora y servicio. Un
servicio de portadora es un tipo de servicio de telecomunicaciones
que proporciona la facilidad para transmitir señales entre puntos
de acceso. En general, el servicio de portadora corresponde al
término de un canal de tráfico que define, por ejemplo, la
velocidad de la transmisión de datos y la calidad del servicio (QoS)
que se van a usar en el sistema cuando se transmita información
entre un dispositivo de comunicación sin hilos y otra parte del
sistema. El servicio de portadora entre el dispositivo de
comunicación sin hilos y la estación base es, por ejemplo, un
servicio de portadora radio, y el servicio de portadora entre la
unidad de control de red radio y la red núcleo es, por ejemplo, un
servicio de portadora Iu (portadora UMTS de Interfaz). En el
sistema UMTS, la interfaz entre la unidad de control de red radio y
la red núcleo se denomina la interfaz Iu. En UMTS también hay la
denominada parte GERAN, que usa, además de la interfaz Iu, también
una interfaz denominada interfaz Gb. En esta conexión, el servicio
es proporcionado por la red de comunicaciones móviles para realizar
una tarea (tareas); por ejemplo, los servicios de datos realizan
transmisiones de datos en el sistema de comunicaciones, los
servicios telefónicos están relacionados con llamadas de teléfono,
multimedia, etc. De esta forma, el servicio requiere la transmisión
de datos, tal como una llamada de teléfono o la transmisión de
flujos de datos multimedia, entre el dispositivo de comunicación sin
hilos y las partes estacionarias del sistema. Una tarea importante
del funcionamiento de un sistema de comunicaciones móviles de
tercera generación es controlar (inicializar, mantener y terminar,
de acuerdo con la necesidad) servicios de portadora de tal manera
que cada uno de los servicios solicitados pueda ser asignado a
estaciones móviles sin malgastar el ancho de banda
disponible.
disponible.
La calidad del servicio determina, por ejemplo,
cómo son procesadas las unidades de datos de protocolo (PDU) en la
red de comunicaciones móviles durante la transmisión. Por ejemplo,
los niveles de QoS definidos para las direcciones de conexión se
usan para controlar el orden de la transmisión, el almacenamiento
temporal (cadenas de paquetes) y para rechazar paquetes en nodos de
soporte nodos de soporte de pasarelas, en particular cuando dos o
más conexiones tengan paquetes para ser transmitidos de manera
simultánea. Los diferentes niveles de QoS determinan, por ejemplo,
diferentes retardos para las transmisiones de paquetes entre lo9s
diferentes extremos de la conexión, así como diferentes velocidades
binarias. También, el número de unidades de datos de paquete
rechazadas y/o perdidas puede variar en las conexiones con
diferentes niveles de QoS.
Es posible solicitar una QoS diferente para cada
contexto PDP. Por ejemplo, en las conexiones de correo electrónico,
se puede permitir un retardo relativamente largo en la transmisión
de los flujos de datos. Sin embargo, las aplicaciones interactivas
en tiempo real, tales como la videoconferencia, requieren la
transmisión de paquetes a una alta velocidad. En algunas
aplicaciones, tales como las transferencias de ficheros, es
importante que la transmisión por conmutación de paquetes sea sin
fallos, en las que en situaciones de error, las unidades de datos
de paquetes son retransmitidas en caso de que sea necesario.
Para el servicio de comunicaciones por
conmutación de paquetes en el sistema UMTS, se ha propuesto la
definición de cuatro clases de tráfico diferentes, y para las
propiedades de estas clases de tráfico, el objetivo ha sido
considerar los diferentes criterios para los diferentes tipos de
conexión. Un criterio definido para la primera y para la segunda
clases es que la transmisión tenga lugar en tiempo real, en el que
la transmisión no debe tener retardos significativos. Sin embargo,
en dichas clases, la precisión de la transferencia de datos no es
una propiedad tan importante. De una manera correspondiente, la
transmisión de datos que no sea en tiempo real es suficiente para
la tercera y para la cuarta clases de tráfico, pero se requiere una
transmisión de datos relativamente precisa de los mismos. Un
ejemplo de la comunicación de primera clase en tiempo real es la
transmisión de señales de voz convencionales en una situación en la
que dos o más personas estén discutiendo unas con las otras por
medio de dispositivos de comunicaciones sin hilos. Un ejemplo de una
situación en la que podría ser factible la comunicación de segunda
clase en tiempo real, es la transmisión de una señal de vídeo para
su visualización inmediata (flujo de datos). La comunicación de
paquetes no en tiempo real de tercera clase se puede usar, por
ejemplo, para la utilización de servicios de bases de datos, tales
como la navegación de las páginas de inicio de Internet, en las que
la transmisión de datos relativamente precisa a una velocidad
razonable es un factor más importante que la transmisión de datos en
tiempo real. En los sistemas de acuerdo con este ejemplo, por
ejemplo la transferencia de mensajes de correo electrónico y de
ficheros, se pueden clasificar dentro de la cuarta categoría.
Naturalmente, el número de clases de tráfico no es de manera
necesaria cuatro como se ha mencionado en este documento, sino que
la invención se puede aplicar en sistemas de comunicaciones por
conmutación de paquetes que comprendan cualquier número de clases de
tráfico. Las propiedades de las cuatro clases de tráfico
presentadas se presentan brevemente en la tabla 1.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página
siguiente)
La velocidad binaria garantizada se usa para el
control de admisión y para la reserva de recursos en la RAN y en la
CN, la velocidad binaria máxima se usa para el mantenimiento del
orden en la CN, es decir, no se permite superior que la velocidad
binaria máxima para que la CN entre en la GGSN, los paquetes que
sobrepasen esta velocidad binaria serán descartados.
Los modernos dispositivos de comunicaciones sin
hilos de segunda y de tercera generación tienen propiedades de
procesado de datos mucho mejores que los dispositivos de
comunicaciones sin hilos más antiguos. Por ejemplo, ya tienen la
facilidad de conectarse a Internet y usar una aplicación de
navegación en el dispositivo de comunicaciones sin hilos para
recuperar la información de Internet, y en el futuro, será posible
establecer llamadas multimedia, por ejemplo, para videoconferencias
en tiempo real y similares.
Los requisitos de diferentes aplicaciones pueden
ser significativamente diferentes. Algunas aplicaciones requieren
la comunicación rápida entre el emisor y el receptor. Estas
aplicaciones incluyen, por ejemplo, aplicaciones de vídeo y de
teléfono. Algunas otras aplicaciones pueden requerir la transmisión
de datos tan precisa como sea posible, pero la velocidad binaria de
la conexión de transmisión de datos es menos importante. Estas
aplicaciones incluyen, por ejemplo, aplicaciones de correo
electrónico y aplicaciones de bases de datos. Por otra parte, estas
aplicaciones se pueden usar en varios dispositivos de comunicaciones
sin hilos con propiedades diferentes.
El usuario del dispositivo de comunicaciones sin
hilos puede tener el deseo de ver una presentación multimedia con
el dispositivo de comunicaciones sin hilos. El usuario encuentra la
dirección de carga de dicha presentación y envía una petición para
enviar la presentación al dispositivo de comunicaciones sin hilos.
La petición es gestionada en el sistema de comunicaciones. La
dirección de carga de la presentación multimedia solicitada puede
direccionar a un servidor en una red de comunicaciones, tal como un
servidor de Internet. El servidor que entrega la presentación
multimedia al dispositivo de comunicaciones sin hilos receptor se
denomina un servidor de flujo de datos en esta descripción.
El sistema de comunicaciones debería reservar
recursos suficientes para la comunicación entre el servidor de
flujo de datos y el dispositivo de comunicaciones sin hilos para que
sea capaz de entregar la presentación multimedia seleccionada. En
cualquier otro caso, la presentación puede no ser presentada con la
misma precisión y libre de errores en el dispositivo de
comunicaciones sin hilos de recepción. En el sistema de
comunicaciones UMTS, el dispositivo de comunicaciones sin hilos
solicita un contexto PDP con ciertos parámetros de QoS primero.
Después, la red selecciona una portadora para la conexión por medio
de la utilización de algunas bases de selección, por ejemplo, los
parámetros que el dispositivo de comunicaciones sin hilos
posiblemente ha usado en la solicitud. Dichas bases de selección
puede que no sean apropiadas o lo suficientemente precisas en
situaciones que pueden ocurrir en las que el servicio de portadora
no pueda proporcionar capacidad de transmisión suficiente para la
conexión, o proporcione más capacidad de la que se necesita, en la
que el uso de los recursos de red no sea eficiente.
Otra situación en la que puede que se necesite
la entrega de información multimedia es con dos dispositivos de
comunicaciones sin hilos comunicando uno con el otro para
intercambiar información multimedia tal como vídeo o imágenes
fijas. También en esta clase de situación, se deberían reservar
recursos suficientes por parte de la red para la comunicación. Sin
embargo, cuando se usen los procedimientos de la técnica anterior,
no siempre es posible informar a ambos extremos de la conexión
acerca de las demandas para la conexión.
Los sistemas básicos de flujos de datos no son
adaptables. Por ejemplo, el servicio de flujo de datos por
conmutación de paquetes actual (PSS) definido por el 3GPP en las
ediciones 4 y 5 no es adaptable. El servicio de flujo de datos de
paquetes conmutados de la edición 6 será adaptable. La
característica adaptable viene dada por la capacidad del sistema,
es decir, tanto un servidor como un cliente de flujo de datos, para
adaptarse a las condiciones variables del canal de red tales como
los cambios en las velocidades binarias de canal de QoS negociadas,
retardos de transferencia, otros parámetros de calidad de servicio,
o incluso cambios en la red de segundo plano en caso de
traspasos.
Con el fin de hacer el sistema adaptable, se
debe establecer alguna comunicación entre el servidor de flujo de
datos y los clientes. Ésta ya está establecida siempre que se use el
protocolo RTSP para la configuración y el control de la sesión. Sin
embargo, la transmisión de la información necesaria entre el
servidor y el cliente debe ocurrir de una manera correcta con el
fin de garantizar que el sistema sea adaptable y en último caso se
pueda conseguir la mejor calidad del servicio al usuario para el
flujo de datos de audio y de vídeo.
Para este propósito, algunas técnicas de la
técnica anterior ya hacen posible la transmisión de información de
QoS, proveniente de la red móvil en segundo plano, desde un cliente
de flujo de datos a un servidor de flujo de datos. Esto permite más
cooperación entre los dos extremos con el fin de hacer que el
sistema sea más adaptable.
Lo que no se ha especificado tanto es la
relación entre los parámetros de QoS en un entorno de red móvil
específico y el uso del contexto PDP (Protocolo de Datos por
Paquetes). Por ejemplo, son posibles diferentes casos. A
continuación, no se considera el flujo RTCP asociado relacionado con
cada flujo de datos de medios RTP. De manera alternativa,
considerando el RTP y su flujo RTCP asociado como una parte del
mismo flujo de datos multimedia no cambia la naturaleza del
problema:
- 1.
- Un contexto PDP solamente lleva un medio de una sesión de flujo de datos
- 2.
- Un contexto PDP lleva todo el medio de una sesión de flujo de datos en un caso cuando haya más de uno.
Si el cliente de flujo de datos decide señalizar
el servidor de flujo de datos, por ejemplo, a través de RTSP,
algunos de los parámetros del perfil de QoS, por ejemplo, la
velocidad binaria garantizada, la velocidad binaria máxima o el
retardo de transferencia, pueden ocurrir algunos problemas para el
servidor en la interpretación correcta del perfil de QoS y, al
final, en la naturaleza de la conexión de red.
En RTSP hay dos posibles clases de sesiones, que
son una denominada sesión controlada agregada y una sesión
controlada no agregada. La sesión controlada agregada es una sesión
en la que, a nivel de transporte, todos los componentes de medios
pueden ser controlados por medio de una única orden enviada al
servidor por parte del cliente (por ejemplo, una orden de
REPRODUCIR RTSP para las componentes tanto de audio como de vídeo).
Si esto no ocurre, es decir, al menos una componente de medios está
controlada de manera independiente en una sesión, entonces se dice
que la sesión tiene control no agregado.
En lo que sigue, se describen algunos ejemplos
para clarificar los problemas que se refieren a la negociación de
los parámetros de QoS para flujos de datos multimedia. Se debería
hacer notar que los ejemplos y los diferentes parámetros usados en
los ejemplos no son restrictivos y pueden existir en diferentes
clases de implementaciones prácticas de parámetros y de
combinaciones de flujos de datos de medios.
\vskip1.000000\baselineskip
Ejemplo
1
En este ejemplo, el flujo de datos multimedia
incluye dos medios (por ejemplo, un flujo de datos de audio y un
flujo de datos de vídeo). Todos los diferentes medios son
transmitidos usando un único contexto PDP.
\vskip1.000000\baselineskip
Se supone que el cliente de flujo de datos ha
recibido notificación del servidor de flujo de datos (por ejemplo,
a través del protocolo SDP), de que el flujo de datos de audio
requiere 12 kbps y que el flujo de datos binario de vídeo requiere
52 kbps. También se supone que el cliente del flujo de datos
establece una conexión con la red móvil usando un único contexto
PDP, sobre el que el cliente desea transmitir tanto los flujos de
datos de audio como de vídeo, y que la red ha garantizado el
contexto PDP con los siguientes parámetros (entre otros) de perfil
QoS:
Velocidad binaria garantizada = 64 kbps
Velocidad binaria máxima = 70 kbps
\vskip1.000000\baselineskip
Ahora, supóngase que el cliente de flujo binario
quiere informar al servidor de flujo binario acerca de la QoS
garantizada desde la red, con el fin de habilitar al sistema para
que sea más adaptable. Para aumentar la eficiencia, el cliente se
supone que decide señalizar esta información antes de comenzar la
reproducción de los dos medios. Por lo tanto, elige señalizar los
dos campos anteriores usando el procedimiento SETUP. Como hay dos
medios, el cliente enviará los dos campos incorporados dentro de dos
mensajes SETUP (uno para audio y uno para vídeo), con la siguiente
información:
SETUP (Audio):
Velocidad binaria garantizada = 12 kbps
Velocidad binaria máxima = 70 kbps
\vskip1.000000\baselineskip
SETUP (Vídeo):
Velocidad binaria garantizada = 52 kbps
Velocidad binaria máxima = 70 kbps
\vskip1.000000\baselineskip
La velocidad binaria garantizada señalizada en
cada SETUP contiene el ancho de banda requerido para cada uno de
los medios (lo que se hace saber tanto al servidor de flujo de datos
como por el cliente de flujo de datos), pero la información de
velocidad binaria máxima solamente puede ser la velocidad binaria
máxima garantizada en el contexto PDP. Por lo tanto, no puede ser
nada más que 70 kbps en este ejemplo, porque no habría manera de
dividir la velocidad binaria máxima entre los dos medios. El
procedimiento de SETUP es interpretado por el servidor de flujo de
datos como siendo una descripción por medios. Por lo tanto, el
servidor interpretará como si hubiere virtualmente dos canales de
red con las características descritas por los dos mensajes de SETUP
(un canal con velocidad binaria garantizada de 12 kbps y una
velocidad binaria máxima de 70 kbps, y otro canal con una velocidad
binaria garantizada de 52 kbps y una velocidad binaria máxima de 70
kbps). La velocidad binaria garantizada acumulativa de los medios
es de 12 + 52 = 64 kbps, que es la velocidad binaria garantizada de
la red real del contexto PDP. El servidor tiene el derecho de enviar
una velocidad binaria máxima de 70 kbps para el audio y una
velocidad binaria máxima de 70 kbps para el vídeo. Cuando se use un
único contexto PDP, esto quiere decir que no es la velocidad binaria
máxima de red para el contexto PDP. Como cada flujo de datos de
medios se puede transmitir a una velocidad binaria variable, la suma
de las velocidades binarias instantáneas de los dos medios puede
alcanzar 140 kbps en cualquier momento del tiempo. Sin embargo, no
se permite cada valor mayor que una velocidad binaria máxima
proporcionada por la red (70 kbps en este ejemplo), porque los
recursos de red no se encuentran disponibles. Por lo tanto, se
conduce a que el servidor malinterprete la información de QoS del
contexto PDP. Esto conduce a una QoS de usuario mala.
Por otra parte, pensando en dividir la velocidad
binaria máxima de 70 kbps de una manera proporcional entre los dos
medios, es algo que conduciría al servidor a hacer una utilización
subóptima del uso del canal, que está compartido por el medio
diferente. El servidor intentaría usar el canal como si hubiese dos
contextos PDP separados.
Un problema similar ocurre si la información de
velocidad binaria garantizada enviada al servidor es la que está
realmente garantizada por la red en el contexto PDP. Por ejemplo, si
la información de la velocidad binaria garantizada de 64 kbps se
envía al servidor en ambos mensajes de SETUP, se generarían incluso
más problemas porque el servidor tendrá derecho a enviar a una
velocidad binaria garantizada de 64 kbps de audio y de 64 kbps de
vídeo, haciendo una velocidad binaria garantizada total de 128 kbps,
que no está disponible en la QoS PDP en este ejemplo. Esto
produciría un desbordamiento de la memoria de almacenamiento
temporal de la red y una maña QoS de usuario.
\vskip1.000000\baselineskip
Ejemplo
2
En este otro ejemplo, el flujo de datos
multimedia incluye también dos medios (por ejemplo, un flujo de
datos de audio y un flujo de datos de vídeo), pero cada medio
diferente es transmitido usando contextos PDP independientes.
\vskip1.000000\baselineskip
Se supone que el cliente de flujo de datos ha
recibido notificación desde el servidor de flujo de datos (por
ejemplo, a través del protocolo SDP), de que el flujo de datos de
audio requiere 12 kbps y que el flujo de datos de vídeo requiere 52
kbps. También se supone que el cliente de flujo de datos establece
una conexión con la red móvil usando dos contextos PDP
independientes, sobre los que el cliente desea transmitir
respectivamente los flujos de datos de audio y de vídeo, y que la
red ha garantizado el contexto PDP con los siguientes (entre otros)
parámetros de perfil QoS:
Contexto PDP para el audio:
Velocidad binaria garantizada = 12 kbps
Velocidad binaria máxima = 20 kbps
\vskip1.000000\baselineskip
Contexto PDP para el vídeo:
Velocidad binaria garantizada = 52 kbps
Velocidad binaria máxima = 64 kbps
\vskip1.000000\baselineskip
Ahora, supóngase que el cliente de flujo de
datos quiere informar al servidor de flujo de datos acerca de la
QoS garantizada desde la red con el fin de hacer posible que el
sistema sea más adaptable. La información QoS podría ser enviada en
una orden PLAY. La orden PLAY es por lo general interpretada por el
servidor como siendo una orden de sesión agregada. Por lo tanto,
solamente se deben enviar un par de parámetros. El cliente podría
decidir enviar una velocidad binaria garantizada = 12 + 52 = 64
kbps, y una velocidad binaria máxima = 20 + 64 = 84 kbps. Esto
confunde al servidor que entenderá que se usa un único contexto PDP
con los parámetros de QoS especificados, que no es el caso en este
ejemplo.
El servidor de flujo de datos es responsable de
la entrega de los datos del flujo de datos y el dispositivo de
comunicaciones sin hilos prealmacena temporalmente una
predeterminada cantidad de datos antes de la reproducción real. El
servidor de flujo de datos es también responsable para ajustar la
velocidad binaria de transmisión para compensar la variación y el
mantenimiento del ancho de banda de transmisión real y para mantener
la memoria de almacenamiento temporal del receptor (memoria de
almacenamiento temporal de fluctuaciones).
En 3GPP, los clientes del flujo de datos por
conmutación de paquetes (PSS) pueden informar de las características
de la red de comunicaciones sin hilos al servidor PSS. La
información se puede incluir en la cabecera del Protocolo de Flujo
de Datos en Tiempo Real (RTSP), en la que se definen parámetros que
se refieren a la red. Los parámetros pueden ser, por ejemplo,
velocidad binaria garantizada por la red, velocidad binaria máxima
de la red y retardo de transferencia máximo de la red.
También es esencial para el servidor de flujo de
datos multimedia poder adaptar las diferentes condiciones de
conexión y los diferentes tipos de red, tales como EGPRS (Servicio
Radio de Paquetes General Mejorado) y CDMA2000 (Acceso Múltiple por
División de Código) 1xEV-DV. Diferentes redes
móviles se comportan de manera diferente, por ejemplo, la variación
del ancho de banda de canal de transmisión EGPRS es más pequeña que
la de un canal CDMA2000 1xEV-DV. Si el servidor de
flujo de datos conoce acerca del tipo de la red que el cliente está
usando, puede entregar el mejor servicio. Por ejemplo, si el cliente
está en un canal de transmisión de alta variación, el servidor de
flujo de datos no debería reaccionar demasiado rápido a la variación
de canal. Por otra parte, si el servidor de flujo de datos conoce
que el móvil está funcionando sobre un canal estable, entonces se
debería tener en consideración cualquier variación de canal y
reaccionar más rápido. El servidor de flujo de datos puede ajustar
los parámetros de control para la entrega de datos del flujo de
datos si se conoce el tipo de red. Desafortunadamente, dicha
información solamente se encuentra disponible en el lado del
cliente.
Actualmente, 3GPP y 3GPP2 tienen diferentes
convenciones de nombres con relación a la adaptación de la velocidad
y a otra señalización. Si el flujo de datos multimedia no conoce
qué tipo de red está usando el cliente, entonces durante la
señalización el servidor podría tener problemas en responder a la
solicitud. Un servidor que cumpla con 3GPP y con 3GPP2 debería
poder analizar y enviar la correspondiente señalización estándar
relacionada, pero solamente si dicha información se encuentra
disponible para el servidor.
En los casos de ejemplo descritos con
anterioridad, el problema principal es que el servidor de flujo de
datos no conoce cuál es el tipo del canal de red reservado para la
transferencia de datos (que puede ser o el contexto PDP simple o el
contexto PDP múltiple), porque no tiene visibilidad sobre el tipo de
asignación de contexto PDP. Esta visibilidad solamente está en el
lado del cliente de flujo de datos.
- D1:
- El documento US2003/0035401 describe un procedimiento para reservar recursos en la comunicación sin hilos, en el que se usa un primer protocolo (SIP) para negociar un modo de funcionamiento preferido para un segundo protocolo (RSVP). Por medio de primeramente llevar a cabo las negociaciones a través de SIP, un terminal capaz de RSVP, un nodo GGSN de soporte de pasarela GPRS y posiblemente de un terminal no capaz de RSVP en el lado de terminación pueden acordar acerca de la configuración común del modo de funcionamiento RSVP y, por ejemplo, acerca de un protocolo de QoS a emplear. Una vez que se ha acordado la configuración del modo de funcionamiento RSVP, se puede evitar la señalización RSVP innecesaria durante el funcionamiento real RSVP.
- D2:
- El documento US2001/0032262 describe un procedimiento para reservar recursos en una red de línea de cable desde una red sin hilos con el fin de evitar el malgastar conexión sin hilos cara debido a la congestión o a la incapacidad de la red de línea de cable. Un cliente de servicio (terminal sin hilos) hace una solicitud de reserva de recursos a un negociador de servicio, que contacta con un negociador de ancho de banda y con un negociador de portadora radio para determinar los recursos disponibles en la línea de cable particular y en las redes sin hilos. En base a las respuestas de los negociadores, el negociador del servicio puede reservar los recursos solicitados para el cliente del servicio o denegar la solicitud debido a recursos indisponibles.
\vskip1.000000\baselineskip
Es de esta manera un objetivo de la presente
invención presentar un procedimiento y un sistema para intentar
resolver las posibles malas interpretaciones que el servidor podría
encontrar cuando sea informado por el cliente acerca de la
información de QoS del contexto o contextos PDP de la red.
Otro objetivo de la actual invención es ajustar
la entrega de los datos del flujo de datos y/o señalización para
proporcionar una calidad óptima del servicio.
Otro objetivo de la invención actual se refiere
a un problema de convención de nomenclatura que existe en el 3GPP y
en el 3GPP2.
Los objetivos de la invención se pueden
conseguir usando diferentes clases de procedimiento de señalización
de parámetros para informar al servidor acerca de las propiedades de
la sesión garantizadas al cliente por parte de la red.
La invención introduce señalización y una nueva
cabecera para el tipo de red de comunicaciones sin hilos. La
información acerca de la información del tipo de red de
comunicaciones sin hilos solamente se encuentra disponible en el
móvil. Esta invención propone transmitir esta información desde el
receptor al servidor.
La presente invención tiene ventajas cuando se
compara con los sistemas y con los procedimientos de la técnica
anterior. La invención permite hacer un servidor de flujo de datos
que esté al corriente de los parámetros de QoS garantizados para
cada contexto PDP. Esto permite una adaptación mejor y más precisa
por medio de la especificación de parámetros de perfil QoS más
precisos.
La invención permite también hacer un servidor
de flujo de datos que esté al corriente del tipo de red usada por
el dispositivo de comunicaciones sin hilos, que además mejora la
calidad del servicio. Gracias a la invención, el servidor puede
también construir de manera apropiada señalización que cumpla con
3GPP/3GPP2.
La invención clarifica el conflicto que ocurre
debido al uso del contexto PDP simple/múltiple por parte del
cliente para una sesión de flujo de datos, y la señalización del
Parámetro QoS al servidor.
Si no se usa el procedimiento descrito en la
invención, entonces la sesión multimedia puede no beneficiarse de
la información de parámetro QoS, sino que en lugar de esto, se
arriesga a que la calidad del servicio se vea severamente
degradada.
La invención hace uso de los conceptos de flujo
de datos sin hilos y mejora el funcionamiento del flujo de datos
multimedia y la adaptación para el dominio sin hilos, haciendo uso
de los protocolos y los códecs específicos 3GPP y 3GPP2.
Otra ventaja importante viene dada por la
posibilidad de usar de manera eficiente el ancho de banda delta
calculado como una velocidad binaria máxima - velocidad binaria
garantizada. Este ancho de banda se puede usar para la adaptación
de ancho de banda o para la gestión de picos de la velocidad binaria
de vídeo. Finalmente, este ancho de banda delta se puede usar para
la entrega de la mejor calidad de medios cuando se codifican flujos
de datos multimedia en tiempo real, por ejemplo, por medio del
cambio de los parámetros de codificación (incluyendo la velocidad
binaria del flujo de datos de medios) en el aire que tengan impacto
en la velocidad binaria.
A continuación se describirá la invención con
más detalle haciendo referencia a los dibujos que se anexan, en los
que
La figura 1 muestra un sistema en el que se
puede aplicar el procedimiento de acuerdo con una realización
preferida de la invención,
La figura 2 muestra un dispositivo de
comunicaciones sin hilos de acuerdo con una realización preferida de
la invención en un diagrama de bloques reducido,
La figura 3 muestra un diagrama de señalización
de reserva de QoS y de control de la sesión para un cliente con un
contexto PDP simple, y
La figura 4 muestra un diagrama de señalización
de reserva QoS y de control de la sesión para un cliente con
soporte de contexto PDP múltiple.
En la siguiente descripción de una realización
preferida de la invención, se usará como un ejemplo un sistema de
comunicaciones móviles del tipo UMTS; sin embargo, será obvio para
cualquiera que sea experto en la técnica que la invención no está
limitada solamente a este sistema, sino que también se puede aplicar
en otros sistemas de comunicaciones (por ejemplo, EGPRS) en el que
es posible determinar los varios niveles de QoS para la
comunicación.
A continuación se describirá con más detalle el
siguiente protocolo de descripción de sesión (SDP).
En la red central multidifusión de Internet
(Mbone), se usa una herramienta de directorio de sesión para
anunciar conferencias multimedia y para comunicar las direcciones de
la conferencia y la información específica de medios necesaria para
la participación. La red central multidifusión es la parte de la
Internet que soporta la multidifusión IP (Protocolo de Internet), y
de esta manera permite una comunicación muchos a muchos eficiente.
Se usa de manera extensa para la conferencia multimedia. Dichas
conferencias por lo general tienen la propiedad de que no es
necesaria una fuerte coordinación de los miembros de la conferencia;
para recibir una conferencia, un usuario en un sitio de una red
central multidifusión solamente tiene que conocer la dirección del
grupo multidifusión de la conferencia y los puertos UDP de los
flujos de datos de la conferencia.
Los directorios de sesión ayudan al anuncio de
las sesiones de conferencia y comunican la información pertinente
de configuración de conferencia a los posibles participantes. SDP
está diseñado para llevar dicha información a los destinatarios.
SDP es puramente un formato para la descripción de la sesión - no
incorpora un protocolo de transporte, y se puede llevar con
diferentes protocolos, incluyendo el Protocolo de Anuncio de Sesión,
el Protocolo de Inicio de Sesión, el Protocolo de Flujo de Datos en
Tiempo Real (RTSP), correo electrónico usando las extensiones
MIME, y el Protocolo de Transporte de Hipertexto.
SDP está destinado a que sea de propósito
general de forma que pueda ser usado por un abanico más amplio de
entornos de red y de aplicaciones más allá de sólo los directorios
de sesión multidifusión.
Una conferencia multimedia es un conjunto de dos
o más dispositivos de comunicaciones que se comunican junto con el
software que usan para comunicarse. Sin embargo, será evidente que
puede haber otras aplicaciones adecuadas, por ejemplo, una
videoconferencia.
Una sesión multimedia es un conjunto de emisores
y de receptores multimedia y los flujos de datos que fluyen de los
emisores a los receptores. Una conferencia multimedia es un ejemplo
de una sesión multimedia.
En lo que sigue, se describirán algunos detalles
de las presentes definiciones del protocolo de descripción de
sesión. Algunas descripciones del protocolo son requeridas y algunas
son opcionales. Los elementos opcionales están marcados con un
"*".
\vskip1.000000\baselineskip
- v =
- (versión del protocolo)
- o =
- (propietario/creador e identificador de sesión).
- s =
- (nombre de la sesión)
- i =*
- (información de la sesión)
- u =*
- (URI de descripción)
- e =*
- (dirección de correo electrónico)
- p =*
- (número de teléfono)
- c =*
- (información de conexión - no se requiere si se incluye en todos los medios)
- b =*
- (información de ancho de banda)
Una o más descripciones de hora (véase a
continuación)
- z =*
- (ajustes de zona horaria)
- k =*
- (clave de encriptado)
- a =*
- (cero o más líneas de atributo de sesión)
Cero o más descripciones de medios (véase a
continuación)
\vskip1.000000\baselineskip
- t =
- (hora en que la sesión está activa)
- r =*
- (cero o más horas de repetición)
\vskip1.000000\baselineskip
- m =
- (nombre de medios y direcciones de transporte)
- i =*
- (título de medios)
- c =*
- (información de conexión - opcional si se incluye a nivel de sesión)
- b =*
- (información de ancho de banda)
- k =*
- (clave de encriptado)
- a =*
- (cero o más líneas de atributo de medios)
\vskip1.000000\baselineskip
De acuerdo con el documento anteriormente
mencionado, la descripción del ancho de banda se define de la
siguiente manera:
b = <modifier> :
<bandwidth-value>
Éste especifica el ancho de banda propuesto para
ser usado por la sesión o por los medios, y es opcional.
<bandwidth-_value> está en
kilobits por segundo por defecto. Los modificadores puede
especificar que se van a usar unidades alternativas.
<modifier> es una única palabra
alfanumérica que da el significado a la cifra del ancho de banda. Se
definen inicialmente dos modificadores:
CT (Conferencia Total): Si el ancho de banda de
una sesión o de un medio en una sesión es diferente del ancho de
banda implícito del alcance, se debería suministrar una línea "b =
CT:..." para la sesión dando el límite superior propuesto para
el ancho de banda utilizado. El propósito primario de esto es dar
una idea aproximada de si pueden coexistir dos o más sesiones de
manera simultánea.
AS (Máximo Específico de Aplicación): El ancho
de banda se interpreta que es específico para la aplicación, es
decir, será el concepto de ancho de banda máximo de la aplicación.
Normalmente esto coincidirá con lo que se fije en el control de
"ancho de banda máximo" de la aplicación si procede. Para
aplicaciones basadas en RTP, AS da el "ancho de banda de la
sesión" RTP según se define en la sección 6.2 del RFC 1889 (RTP)
(incluyendo la velocidad binaria de medios y la sobrecarga de
cabeceras UDP/IP).
El Protocolo de Flujo de Datos en Tiempo Real
(RTSP) es un protocolo cliente - servidor para controlar la entrega
de datos con propiedades en tiempo real. Se usa para establecer y
para controlar un único flujo de datos o varios flujo de datos
sincronizados en el tiempo de medios continuos, tales como audio y
vídeo. RTSP es llevado con los protocolos de transporte tales como
UDP y TCP. En otras palabras, RTSP actúa como un control remoto de
red para servidores multimedia. Las fuentes de datos pueden incluir
tanto alimentación de datos en vivo (por ejemplo, vídeo y/o
audio en tiempo real) como secuencias almacenadas (por ejemplo,
imágenes fijas). Un cliente y un servidor RTSP negocian un conjunto
apropiado de parámetros para la entrega de medios, usando
parcialmente por ejemplo, sintaxis SDP (Protocolo de Descripción de
Sesión) para describir esos parámetros.
La figura 1 muestra una parte del sistema UMTS,
que comprende un dispositivo de comunicaciones sin hilos MT1, un
nodo de acceso radio 1 (RAN) que comprende una estación base 2 (BS),
y un controlador de red radio 3 (RNC) que controla la estación base
2 y encamina las conexiones entre la estación base 2 y el resto del
sistema, un centro de conmutación de móviles sin hilos 4 (WMSC) y
un nodo de acceso a datos de paquete 5 (PDAN) como enrutador de las
posibilidades además del controlador de red radio 3. El sistema UMTS
de acuerdo con la figura 1 comprende también por ejemplo una red
central 6 y una pasarela de datos de paquete 8 (PDG) a otras redes
de paquetes, tales como la red de Protocolo de Internet (IP) 7, en
la que el dispositivo de comunicaciones sin hilos puede comunicar
por ejemplo con un servidor 10 acoplado a la red IP. Además, la
figura 1 muestra una pasarela por conmutación de circuitos 9
(Pasarela a Centro de Conmutación de Servicios Móviles, GWMSC) para
acoplarse, por ejemplo, a una segunda red de comunicaciones móviles
NW2, y un registro de localización de inicio 11 (HLR) por ejemplo,
para almacenar los datos de contrato de acceso del abonado.
Además, la figura 2 muestra, en un diagrama de
bloques reducido, un dispositivo de comunicaciones sin hilos MT1
que cumple con una realización preferida de la invención, y que en
este ejemplo es un dispositivo de comunicaciones que comprende
funciones de procesado de datos y funciones de estación móvil, tal
como el Nokia 9210i Communicator. El dispositivo de comunicaciones
sin hilos MT1 comprende, por ejemplo, uno o más procesadores CPU,
DSP, medio de memoria MEM, el módulo de identidad de abonado UMTS
(USIM) o el correspondiente medio para identificar al abonado, y
una parte radio RF para comunicar con la estación base 2. El
procesador CPU puede estar integrado, por ejemplo, en un circuito
integrado específico de aplicación 12 (ASIC), con el que sea posible
realizar un gran número de las funciones lógicas del dispositivo de
comunicaciones sin hilos MT1. El medio de memoria comprende de
manera preferible una memoria de acceso aleatorio (RAM), una memoria
de sólo lectura (ROM), y al menos parte de la memoria del módulo de
identidad del abonado USIM. El dispositivo de comunicaciones sin
hilos MT1 también comprende una o más interfaces de usuario,
comprendiendo de manera preferible un teclado 13, 14, un
dispositivo de visualización 15, 16, y medios de audio, por ejemplo
un micrófono 17, un altavoz 18 y un códec 19.
En la figura 1, se supone que las funciones
relacionadas con la gestión de la llamada (CM) son implementadas en
el dispositivo de comunicaciones sin hilos MT1 y tanto en el centro
de conmutación de móviles sin hilos 4 como en el nodo de acceso de
datos por paquetes 5. Estas funciones de gestión de llamada
constituyen el medio para inicializar, mantener y terminar una
llamada. Por consiguiente, el dispositivo de comunicaciones sin
hilos MT1 y el centro de conmutación de móviles sin hilos 4 o el
nodo de acceso de datos por paquetes 5 intercambian mensajes de
señalización para inicializar, mantener y terminar una llamada. Las
funciones de gestión de portadora (BM) y de gestión de recursos
radio (RM) son llevadas a la práctica en el dispositivo de
comunicaciones sin hilos MT1 y en el controlador de red radio 3. Las
funciones de gestión de portadora son utilizadas para seleccionar,
por ejemplo, uno o varios canales lógicos de acuerdo con las
propiedades del servicio de portadora seleccionado para la
comunicación entre el dispositivo de comunicaciones sin hilos MT1 y
la estación base 2, para proporcionar una calidad de servicio que
cumpla con el servicio de portadora. Las funciones de gestión de
recursos radio se usan, por ejemplo, para seleccionar el canal radio
para la comunicación radio entre el dispositivo de comunicaciones
sin hilos MT1 y la estación base 2.
La conexión de transmisión de datos por paquetes
entre el dispositivo de comunicaciones sin hilos MT1 y la red IP 7
se puede establecer desde el nodo de acceso de datos por paquetes 5
(PDAN) a través de la red central de datos por paquetes 6 y de la
pasarela de datos por paquetes 8 (PDG). Es posible establecer una
conexión de transmisión de datos por conmutación de circuitos entre
el dispositivo de comunicaciones sin hilos MT1 y la red de
comunicaciones móviles a través del nodo de acceso radio 1, del
centro de conmutación de móviles sin hilos 4 y de la pasarela al
centro de conmutación de servicios móviles 9 (GWMSC). Esta pasarela
al centro de conmutación de servicios móviles 9 comprende un medio
para establecer una conexión entre la red de comunicaciones móviles
y la segunda red NW2, tal como GSM, RTPC o RDSI.
A continuación se describirá con referencia al
sistema de la figura 1, el procedimiento de acuerdo con una
realización preferida de la presente invención para el flujo de
datos de aplicaciones multimedia y los diagramas de señalización de
las figuras 3 y 4. las siguientes implementaciones se basan en la
utilización de protocolo RTSP. También, los parámetros
"QoSParams, MaxBW, GuaBW, TdelayMax y url" son nombres de
parámetros ficticios que son símbolos conceptuales para la
invención anteriormente explicada. Pueden ser nombrados de manera
diferente en implementaciones de la vida real.
En primer lugar, se definirán algunos términos.
Un Cliente es un dispositivo de comunicaciones sin hilos MT1 y un
Servidor es un proveedor de servicios multimedia de flujo de datos
(por ejemplo, el servidor 10 de la figura 1) para el Cliente. Una
Sesión Multimedia es un intervalo de tiempo durante el que se
intercambian datos relacionados multimedia entre el Cliente y el
Servidor. Una Fase de Configuración de Sesión Multimedia es el
intervalo de tiempo durante el que el Cliente y el Servidor
intercambian información de configuración relacionada con la sesión
multimedia, por ejemplo, los componentes multimedia que se vayan a
usar durante la sesión, la información del ancho de banda,
información relacionada con el códec multimedia, etc. Un contexto
PDP es la indicación lógica de un límite abstracto entre el proceso
de reserva de recursos QoS y la estación móvil que esté ejecutando
el cliente del flujo de datos.
El Cliente puede estar en una red habilitada de
QoS (Calidad del Servicio) NW1, que puede proporcionar algunas
garantías al Cliente en base a sus recursos. Estas garantías pueden
cubrir uno o más de los siguientes:
- -
- Velocidad binaria máxima (MaxBW): el ancho de banda máximo que se puede usar por parte del componente de medios negociado o de la sesión multimedia total.
- -
- Velocidad binaria garantizada (GuaBW): el valor de ancho de banda que garantiza el procedimiento de reserva de QoS al cliente para el componente de medios negociado o para la sesión multimedia total.
- -
- Retardo de transferencia (TDelayMax): el retardo (en milisegundos) que cada unidad de datos puede experimentar durante la transmisión desde el servidor al cliente y viceversa.
- -
- Se pueden definir otros parámetros, pero no se describen con detalle en este documento.
La invención cubre dos posibilidades diferentes
que el cliente puede experimentar en base a su capacidad para tener
múltiple o simple contextos PDP durante una sesión multimedia.
Primero, se describirá con más detalle la
situación en la que el cliente solamente puede gestionar un contexto
PDP simple a la vez. En otras palabras, un cliente con un soporte
de contexto PDP simple puede tener una única reserva de recursos
QoS en un único instante de tiempo, que abarca a todos los
componentes de medios (es decir, audio, vídeo, etc.) durante la
sesión multimedia. Esto quiere decir que los datos multimedia, con
independencia de ser datos de vídeo o datos de audio, etc.,
comparten el mismo canal de transmisión con los mismos recursos
QoS.
En el primer escenario, se activa una sesión
controlada agregada para el dispositivo de comunicaciones sin hilos
MT1 (cliente) que tiene solamente soporte de contexto PDP simple
para la sesión de flujo de datos. En este escenario, si el
dispositivo de comunicaciones sin hilos MT1 tiene múltiples
componentes de medios para establecer la sesión (por ejemplo, un
flujo de audio y también un flujo de vídeo acompañante), entonces el
cliente no debe enviar los parámetros de QoS negociados tales como
la velocidad binaria máxima MaxBW, la velocidad binaria garantizada
GuaBW, el retardo de transferencia máximo TdelayMax y cualquier otro
parámetro de perfil de QoS al servidor 10 durante la fase de
configuración debido al problema descrito en la sección Técnica
Antecedente de esta solicitud.
Los parámetros negociados de QoS se deben enviar
al servidor en o después de que se active la transmisión del flujo,
es decir, en o después de que se haya transmitido una orden de
Reproducir desde el dispositivo de comunicaciones sin hilos MT1 al
servidor 10.
La secuencia de la orden podría ser de la
siguiente manera (figura 3):
El dispositivo de comunicaciones sin hilos MT1
transmite 301 una orden Describir Sesión al servidor 10.
El servidor 10 contesta a esta orden por medio
de la transmisión 302 de la descripción SDP que incluye información
acerca de diferentes flujos de datos de medios.
En la anterior descripción SDP, el vídeo 1 tiene
una b = definición AS de 50 kbps, vídeo 2 tiene una b = definición
AS de 20 kbps, audio 1 tiene una b = definición AS de 10 kbps y
audio 2 tiene una b = definición AS de 20 kbps.
Entonces, en el dispositivo de comunicaciones
sin hilos MT1 se hace una selección, por ejemplo, por parte del
usuario, entre los medios informados para seleccionar los flujos de
datos que se vayan a transmitir al dispositivo de comunicaciones
sin hilos MT1. En este ejemplo, se supone que se seleccionan vídeo 1
(50 kbps) y audio 2 (20 kbps) teniendo una velocidad binaria total
de 70 kbps. Después de eso, el dispositivo de comunicaciones sin
hilos envía 303 una petición de un servicio de portadora a la red de
comunicaciones NW1. En la petición, el dispositivo de
comunicaciones sin hilos MT1 incluye los parámetros de QoS deseados
(velocidad binaria máxima de 70 kbps) para todos los componentes de
medios.
En este ejemplo, la red solamente puede
garantizar 60 kbps y habilitar una velocidad binaria máxima de 80
kbps. Después, la red NT1 informa 304 al dispositivo de
comunicaciones sin hilos MT1 del parámetro QoS garantizado para el
servicio de portadora. Después de negociar con la red para el
servicio de portadora para la sesión PDP, el dispositivo de
comunicaciones sin hilos MT1 transmite 305 un primer mensaje de
configuración al servidor 10 para informar del primer flujo de
medio seleccionado, es decir, vídeo 1.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
El servidor 10 contesta 306 con un mensaje OK,
si la selección es correcta.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
El dispositivo de comunicaciones sin hilos MT1
también transmite 307 un segundo mensaje de configuración al
servidor 10 para informar del segundo flujo de datos de medio
seleccionado, es decir, audio 2.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
El servidor 10 contesta 308 con un mensaje OK si
la selección es correcta.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
La reproducción de los flujos de datos de medios
se inicia por medio de la transmisión 309 de una orden de
Reproducir proveniente del dispositivo de comunicaciones sin hilos
MT1 al servidor 10. En este caso, la orden de Reproducir está
incluida con información acerca al menos de los parámetros de QoS
relativos con la velocidad binaria máxima y con la velocidad
binaria garantizada que la red NT1 haya garantizado.
\vskip1.000000\baselineskip
El servidor contesta con la orden por medio del
envío de OK al dispositivo de comunicaciones sin hilos MT1.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Ahora, cuando el servidor 10 haya recibido la
orden de Reproducir, conoce que existe un único canal de QoS con
parámetros de QoS señalizados por el dispositivo de comunicaciones
sin hilos MT1 y el servidor 10 puede adaptar la transmisión de los
flujos datos de medios seleccionados de acuerdo con los
parámetros.
Después de la orden de Reproducir, el
dispositivo de comunicaciones sin hilos MT1 puede actualizar los
parámetros de QoS negociados para la sesión multimedia completa,
usando cualquier otra orden RTSP definida dentro del contexto del
sistema de flujo de datos.
Si la sesión multimedia es una sesión controlada
no agregada (por ejemplo, los datos de audio y de vídeo son
recuperados desde dos servidores independientes), entonces el
dispositivo de comunicaciones sin hilos MT1 no debería enviar los
parámetros de QoS, ya que los servidores de medios independientes no
están al corriente uno del otro, ni están al corriente del hecho de
que los componentes de medios comparten el mismo canal reservado
de
QoS.
QoS.
En segundo lugar, se describirá con más detalle
la situación en la que el cliente es capaz de soportar múltiples
contextos PDP a la vez. En otras palabras, un cliente con soporte de
contexto PDP múltiple puede tener múltiples reservas de recursos
QoS en un único instante de tiempo, que se pueden distribuir entre
los componentes de medios (es decir, audio, vídeo, etc.) durante la
sesión multimedia. Puede que haya una sesión multimedia
independiente para cada componente de medios (es decir, audio,
vídeo, etc.) durante la sesión multimedia. Todos los componentes de
medios pueden tener diferentes reservas de recursos QoS.
En el segundo escenario, si el dispositivo de
comunicaciones sin hilos MT1 tiene múltiples componentes de medios
para establecer la sesión, y si el dispositivo de comunicaciones sin
hilos MT1 desea activar contextos PDP múltiples para diferentes
componentes de medios, y también si el protocolo de control de la
sesión no permite indicadores url de componente de medios para
diferenciar entre los componentes de medios, entonces el
dispositivo de comunicaciones sin hilos MT1 no debe enviar los
MaxBW, GuaBW, TDelayMax de QoS negociados y otros parámetros de
perfil QoS al servidor en la orden Reproducir, lo que sería lo más
probable una adición de estos parámetros. Los parámetros de QoS, en
lugar de esto, deberían ser enviados durante la fase de
configuración de cada uno de los componentes de medios.
La secuencie de órdenes podría ser la siguiente
(figura 4):
\vskip1.000000\baselineskip
El dispositivo de comunicaciones sin hilos MT1
transmite 401 una orden de Describir Sesión al servidor 10.
\vskip1.000000\baselineskip
El servidor 10 contesta a esta orden por medio
de la transmisión 402 de la descripción SDP incluyendo información
acerca de diferentes flujos de datos de medios.
En la anterior descripción SDP, vídeo 1 tiene
una b = definición AS de 50 kbps, vídeo 2 tiene una b = definición
AS de 20 kbps, audio 1 tiene una b = definición AS de 10 kbps y
audio 2 tiene una b = definición AS de 20 kbps.
Después, en el dispositivo de comunicaciones sin
hilos MT1 se hace una selección, por ejemplo, por parte del
usuario, entre los medios informados para seleccionar los flujos de
datos que se vayan a transmitir al dispositivo de comunicaciones
sin hilos MT1. En este ejemplo, se supone que se seleccionan vídeo 1
que tiene una velocidad binaria de 50 kbps y audio 2 que tiene una
velocidad binaria de 20 kbps. Después de esto, el dispositivo de
comunicaciones sin hilos envía 403 una primera petición de un primer
servicio de portadora a la red de comunicaciones NW1. En la
petición, el dispositivo de comunicaciones sin hilos MT1 incluye los
parámetros de QoS deseados (velocidad binaria garantizada de 50
kbps) para el primer componente de medios (vídeo 1). En este
ejemplo, la red solamente puede garantizar 50 kbps y habilitar una
velocidad binaria máxima de 80 kbps. Después, la red NT1 informa
404 al dispositivo de comunicaciones sin hilos MT1 de los parámetros
de QoS garantizados para el primer servicio de portadora. A
continuación, el dispositivo de comunicaciones sin hilos envía 405
una segunda petición de un segundo servicio de portadora a la red
de comunicaciones NW1. En la petición, el dispositivo de
comunicaciones sin hilos MT1 incluye los parámetros de QoS deseados
(velocidad binaria garantizada de 20 kbps) para el segundo
componente de medios (audio 1). En este ejemplo, la red solamente
puede garantizar 20 kbps y habilitar una velocidad binaria máxima
de 40 kbps. Después, la red NT1 informa 406 al dispositivo de
comunicaciones sin hilos MT1 de los parámetros de QoS garantizados
para el segundo servicio de portadora. Después de negociar con la
red para los servicios de portadora para las sesiones PDP, el
dispositivo de comunicaciones sin hilos MT1 transmite 407 un primer
mensaje de configuración al servidor 10 para informar del primer
flujo de datos de medios seleccionado, es decir, vídeo 1.
El servidor 10 contesta 408 con un mensaje OK si
la selección es correcta.
El dispositivo de comunicaciones sin hilos MT1
transmite también 409 un segundo mensaje de configuración al
servidor 10 para informar del segundo flujo de datos de medios
seleccionado, es decir, audio 2.
El servidor 10 contesta 410 con un mensaje OK si
la selección es correcta.
La reproducción de los flujos de medios se
inicia por medio de la transmisión 411 de una orden de Reproducir
proveniente del dispositivo de comunicaciones sin hilos MT1 al
servidor 10.
En este caso, la orden de Reproducir no está
incluida con la información acerca de los parámetros de QoS
relativos a la velocidad binaria máxima y a la velocidad binaria
garantizada que la red NT1 haya garantizado.
El servidor contesta a la orden por medio del
envío de OK al dispositivo de comunicaciones sin hilos MT1.
\vskip1.000000\baselineskip
De manera alternativa, en la petición PLAY RTSP,
el dispositivo de comunicaciones sin hilos MT1 podría haber hecho
lo siguiente:
\vskip1.000000\baselineskip
Ahora, el servidor puede identificar qué
parámetros de QoS están asignados con cada componente de medios, en
base a su URL de componente de medios.
Ahora, cuando el servidor 10 haya recibido la
orden de Reproducir, conoce que existen múltiples canales QoS con
parámetros de QoS individuales señalizados por el dispositivo de
comunicaciones sin hilos MT1. Como cada componente de medios tendrá
su propio conjunto de parámetros de QoS negociados válido para cada
contexto PDP, el servidor puede asociar de manera segura cada
componente de medios al canal negociado QoS correcto, con los
valores correctos asignados.
El Cliente también puede proporcionar
información acerca de la red de comunicaciones sin hilos al
Servidor, que no tiene necesariamente esta información porque se
encuentra disponible en el lado del Cliente. De acuerdo con la
invención, la información acerca del tipo de red se transmite desde
el Cliente al Servidor. Para hacer eso, la invención proporciona
una nueva cabecera RTSP,
"Mobile-Link-Char" y
señalización para la misma.
Como se ha mencionado, la cabecera
"Mobile-Link-Char" se define
para habilitar al cliente de servicio de flujo de datos multimedia
para que informe de las características de red al servidor de flujo
de datos. La cabecera
"Mobile-Link-Char" se puede
incluir en una petición usando cualquiera de los siguientes
procedimientos: SETUP, PLAY, OPTIONS y SET_PARAMETER. La cabecera
puede contener una o más especificaciones de características. Cada
una de las especificaciones contiene una URI que puede ser una URI
absoluta o una URI relativa, cualquier URI relativa usa la URI de
petición RTSP como base. La URI apunta al componente de medios al
que se aplica el parámetro dado. Éste puede ser un flujo de datos
de medios individual o un agregado de sesión. La cabecera
"Mobile-Link-Char" se debería
incluir en una petición SETUP o PLAY por parte del cliente, para dar
los valores iniciales para las características del enlace. Se puede
usar una petición de SET_PARAMETER o OPTIONS para actualizar los
valores de Mobile-Link-Char en una
sesión que se esté reproduciendo en el momento presente.
Dentro de
"Mobile-Link-Char" se incluye
un campo para el tipo de red móvil, MNT, que define la red de
comunicaciones sin hilos usada para la señalización. Junto con
"MNT" puede haber también otros parámetros tales como GBW,
para la velocidad de datos de usuario de enlace directo en kbits/s;
y MTD, para el retardo máximo de enlace directo en milisegundos; y
MBW, para la velocidad binaria máxima del enlace directo en kbit/s.
También se pueden incluir en la cabecera algunos otros parámetros
distintos a los que son mencionados.
El campo "MNT" de acuerdo con la invención
está compuesto de acuerdo con el siguiente ejemplo:
El "standard body" se usa para identificar
a la red correspondiente, por ejemplo, 3GPP o 3GPP2. Esto permite
al servidor construir la señalización adecuada, que cumpla con la
red en cuestión.
Las cadenas válidas en el campo de tipo de red
"MNT" pueden ser, por ejemplo, EGPRS, W-CDMA,
CDMA2000, y "MNT" Release Information son las versiones de
liberación de red pertinentes. Para 3GPP, "Network type ID"
corresponde a EGPRS o a W-CDMA (Acceso Múltiple por
División de Código de Banda Ancha) y para 3GPP2 corresponde a HRPD
(Datos de Paquete de Alta Velocidad) o SSS (Sistemas de Espectro
Expandido). Para 3GPP, "Release information" corresponde a
REL-x (donde x es un número), y para 3GPP2,
corresponde a REL-y (donde y es 0, A, B, C, etc.).
Los campos para "Standard body" y para "Network type ID"
se listan solamente para propósitos de referencia. Es obvio que se
pueden hacer adiciones más nuevas dentro de aquéllas sin salirse del
alcance de la invención.
Por ejemplo, para la red que cumple con 3GPP2
(1xEV-DV) la cabecera es:
Otro ejemplo es una red que cumple con 3GPP2
(1xEV-DO), en la que la cabecera es:
Otro ejemplo adicional es una red que cumple con
3GPP, en la que la cabecera es
Otro ejemplo adicional es una red que cumple con
3GPP (1xEV-DV), en la que la cabecera con otros
parámetros (la velocidad binaria es de 32 kbps y el retardo de
transferencia máximo es de 2,0 segundos) es
El servidor puede deducir a partir del campo
"MNT" en cuál de las redes que cumplen con 3GPP o con 3GPP2
está operando el cliente. Debido a esto, puede responder al cliente
con la sintaxis apropiada para RTSP, DP, RTCP y otra señalización.
Los términos 1xEV-DV y 1xEV-DO
corresponden a una evolución de una transferencia de datos (Datos y
Voz, Datos Solamente, respectivamente).
Si ocurre una renegociación de QoS para un
contexto PDP particular (es decir, un componente de medios
particular), el cliente puede señalizar los nuevos valores de QoS
usando cualquiera de las órdenes RTSP disponibles, por medio de la
referencia correcta al componente de medios para el que hayan
ocurrido los cambios.
Si el protocolo de control de sesión permite
indicadores url de componente de medios para diferenciar entre
componentes de medios, entonces se pueden señalizar los parámetros
de QoS también en la petición de Reproducción. La siguiente
secuencia de pseudo-orden muestra el posible
escenario:
En el ejemplo anterior, el servidor puede
diferenciar entre los componentes de medios y los parámetros de QoS
asignados para cada componente por medio de la utilización de la
información "media component URL". Este campo es un
identificador único del componente de medios en una sesión. Si el
cliente y el servidor pueden hacer uso de dicho parámetro, entonces
el dispositivo de comunicaciones sin hilos MT1 puede elegir enviar
los parámetros de QoS en la fase de configuración o en la fase de
reproducción. Este indicador URL de componente de medios da también
la posibilidad al dispositivo de comunicaciones sin hilos MT1 de
actualizar los parámetros de QoS durante la sesión, si ocurre una
renegociación QoS.
Si la sesión multimedia es una sesión controlada
no agregada (por ejemplo, los datos de audio y de vídeo se
recuperan desde dos servidores independiente), entonces el cliente
puede señalizar de manera segura los parámetros de QoS en la orden
de configuración, así como en la orden de reproducción, ya que habrá
órdenes de Reproducir independientes para cada componente de
medios.
El campo URL de componente de medios también
puede estar presente para identificar la URL de sesión en el primer
ejemplo, pero la restricción sobre el no envío de los parámetros de
QoS en la fase de configuración es aún válida para ese caso.
Si un conjunto de parámetros de QoS no contiene
la URL de componente de medios, entonces se puede usar la URL de
petición del protocolo de control de flujo de datos como la URL
principal para la asignación de parámetros de QoS.
En la descripción, RTSP se usa como el
procedimiento preferido. Será evidente que también son posibles
otros procedimientos externos. El ejemplo descrito en este
documento solamente proporciona una muestra de parte de la
señalización, pero otros formatos de dicha señalización están aún en
el alcance de esta invención. Para la comprensión de esto, será
evidente que también los nombres de los parámetros así como los
tipos de red pueden variar dependiendo de la situación.
Será obvio que la presente invención no está
limitada solamente a las realizaciones presentadas con anterioridad,
sino que se puede modificar dentro del alcance de las
reivindicaciones anejas.
Claims (9)
1. Un procedimiento en un sistema de
comunicaciones que comprende:
- seleccionar al menos un flujo de medios para ser transmitido (402) desde un dispositivo de comunicaciones emisor (10) a un dispositivo de comunicaciones receptor (MT1) al menos parcialmente a través de una red de comunicaciones sin hilos (NW1),
- definir los requisitos de QoS (403, 405) para la transmisión del mencionado, al menos uno, flujo de medios seleccionados,
- reservar (404, 406) recursos de transmisión de la red de comunicaciones sin hilos (NM1) para la transmisión del mencionado al menos uno, flujo de datos de medios,
- realizar un procedimiento de configuración (407 - 410) entre el dispositivo de comunicaciones receptor (MT1) y el dispositivo de comunicaciones emisor (10) para activar al menos una conexión de transmisión de datos por paquetes, caracterizado porque el mencionado procedimiento incluye la transmisión (407, 409) de información acerca de los recursos reservados al dispositivo de comunicaciones emisor, comprendiendo la información acerca de los recursos reservados al menos uno de los siguientes parámetros para la conexión de transmisión de datos:
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- solicitar (411) por parte del dispositivo de comunicaciones receptor (MT1) el inicio de la transmisión de al menos un flujo de datos de medios, y transmitir (412) flujos de datos de medios desde el dispositivo de comunicaciones emisor (10) a un dispositivo de comunicaciones receptor (MT1) por medio de la utilización de un contexto PDP para cada uno de los flujos de datos de medios seleccionado.
2. Un procedimiento de acuerdo con la
reivindicación 1, que comprende la transmisión de información acerca
del tipo de red de comunicaciones sin hilos al dispositivo de
comunicaciones emisor en o después del inicio de la transmisión
(412) del al menos un flujo de datos de medios solicitado por el
dispositivo de comunicaciones receptor.
3. Un procedimiento de acuerdo con la
reivindicación 2, en el que se define al menos un parámetro para
definir el tipo de red de comunicaciones sin hilos para la conexión
de la transmisión de datos.
4. Un procedimiento de acuerdo con la
reivindicación 3, en el que se define al menos información acerca
del estándar de red, el tipo de red y la liberación de red.
5. Un dispositivo de comunicaciones sin hilos
(MT1) que comprende al menos:
- un receptor (RF) para recibir flujos de datos de medios provenientes de un dispositivo de comunicaciones emisor (10) transmitidos al menos parcialmente a través de una red de comunicaciones sin hilos (NW1) usando al menos una conexión de transmisión de datos por paquetes;
- un medio para seleccionar al menos un flujo de medios para ser transmitido desde el dispositivo de comunicaciones emisor (10) al dispositivo de comunicaciones sin hilos (MT1);
- un medio para definir los requisitos de QoS para transmitir el al menos un flujo de medios seleccionado;
- un medio para solicitar recursos de transmisión desde la red de comunicaciones sin hilos (NW1) para la transmisión del mencionado, al menos un flujo de medios;
- un medio para realizar un procedimiento de configuración (407 - 410) entre el dispositivo de comunicaciones sin hilos (MT1) y el dispositivo de comunicaciones emisor (10) para activar la al menos una conexión de transmisión de datos por paquetes;
caracterizado porque
- el mencionado procedimiento de configuración incluye la transmisión (407, 409) de la información acerca de los recursos reservados al dispositivo de comunicaciones emisor (10), comprendiendo la información acerca de los recursos reservados al menos uno de los siguientes parámetros para la conexión de transmisión de datos:
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- un medio (13, 14, RF) para solicitar el inicio de la transmisión de al menos un flujo de datos de medios desde el dispositivo de comunicaciones emisor (10); y
- un medio para usar un contexto PDP en la transmisión de cada uno de los seleccionados, al menos uno, flujos de datos de medios.
6. Un dispositivo de comunicaciones sin hilos de
acuerdo con la reivindicación 5, en el que el medio para solicitar
recursos de transmisión desde la red de comunicaciones sin hilos
para la transmisión del mencionado, al menos uno, flujo de datos de
medios comprende un medio para definir un mensaje de
configuración.
7. Un dispositivo de comunicaciones sin hilos de
acuerdo con la reivindicación 5 ó 6, en el que el medio (13, 14,
RF) para solicitar el inicio de la transmisión del al menos un flujo
de datos de medios desde el dispositivo de comunicaciones emisor
comprende un medio para definir un mensaje de reproducción.
8. Un dispositivo de comunicaciones sin hilos de
acuerdo con cualquiera de las reivindicaciones 5 a la 7, que
comprende un medio (RF) para transmitir información acerca de la red
de comunicaciones sin hilos al dispositivo de comunicaciones emisor
en o después del inicio de la transmisión del al menos un flujo de
medios solicitado.
9. Un elemento de red que comprende al
menos:
- un medio para recibir información acerca de una selección de al menos un flujo de medios que se vaya a transmitir a un dispositivo de comunicaciones receptor al menos parcialmente a través de una red de comunicaciones sin hilos (NW1) usando al menos una conexión de transmisión de datos por paquetes;
- un medio para recibir requisitos de QoS para transmitir el mencionado al menos uno, flujo de datos de medios;
- un medio para solicitar recursos de transmisión desde la red de comunicaciones sin hilos (NW1) para la transmisión del mencionado al menos un flujo de datos de medios;
- un transmisor para transmitir el mencionado al menos un flujo de medios al dispositivo de comunicaciones receptor, estando el mencionado transmisor adaptado para enviar un mensaje de configuración (408, 410) en conexión con un procedimiento de configuración (407 - 410) entre el dispositivo de comunicaciones receptor y el elemento de red para activar la al menos una conexión de transmisión de datos por paquetes; caracterizado porque el mencionado procedimiento de configuración incluye la recepción (407, 409) de información acerca de los recursos reservados del dispositivo de comunicaciones receptor (MT1), comprendiendo la información acerca de los recursos reservados al menos uno de los siguientes parámetros para la conexión de transmisión de datos:
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- un medio para usar un contexto PDP en la transmisión de cada uno, al menos uno, de los flujos de datos de medios seleccionados.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US876262 | 2001-06-06 | ||
| US55044304P | 2004-03-04 | 2004-03-04 | |
| US550443P | 2004-03-04 | ||
| US10/876,262 US7701915B2 (en) | 2003-06-27 | 2004-06-24 | Method in a communication system, a communication system and a communication device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2315876T3 true ES2315876T3 (es) | 2009-04-01 |
Family
ID=34970486
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05751173T Expired - Lifetime ES2315876T3 (es) | 2004-03-04 | 2005-03-03 | Procedimiento para asignar recursos en un sistema de comunicaciones. |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US7701915B2 (es) |
| EP (1) | EP1721427B1 (es) |
| JP (1) | JP2007526727A (es) |
| KR (1) | KR100855610B1 (es) |
| AT (1) | ATE417439T1 (es) |
| AU (1) | AU2005222356B2 (es) |
| DE (1) | DE602005011578D1 (es) |
| ES (1) | ES2315876T3 (es) |
| WO (1) | WO2005088919A2 (es) |
Families Citing this family (47)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106419746B (zh) * | 2016-11-03 | 2019-02-15 | 江苏美的清洁电器股份有限公司 | 尘杯和具有其的尘杯组件、手持吸尘器 |
| US7701915B2 (en) * | 2003-06-27 | 2010-04-20 | Nokia Corporation | Method in a communication system, a communication system and a communication device |
| US7450723B2 (en) * | 2004-11-12 | 2008-11-11 | International Business Machines Corporation | Method and system for providing for security in communication |
| US20060184676A1 (en) * | 2005-02-16 | 2006-08-17 | Murata Kikai Kabushiki Kaisha | Image communication device |
| CN100397948C (zh) * | 2005-03-11 | 2008-06-25 | 上海华为技术有限公司 | 移动通信系统中预留资源激活方法 |
| US20070115926A1 (en) * | 2005-10-27 | 2007-05-24 | 3Com Corporation | System and method for receiving a user message at a packet-network telephone |
| US8014389B2 (en) * | 2005-12-06 | 2011-09-06 | Lippershy Celestial Llc | Bidding network |
| US8953596B2 (en) * | 2006-01-06 | 2015-02-10 | Qualcomm Incorporated | Conserving network capacity by releasing QoS resources |
| US8291102B2 (en) * | 2006-03-31 | 2012-10-16 | Alcatel Lucent | Method and apparatus for improved multicast streaming in wireless networks |
| BRPI0722378A2 (pt) | 2006-03-31 | 2012-05-22 | Qualcomm Incorporated | gerencimento de memória para controle de acesso à mìdia de alta velocidade |
| CN100423596C (zh) * | 2006-06-16 | 2008-10-01 | 丰达软件（苏州）有限公司 | 手机生成、发送、接收流媒体的方法 |
| US8849297B2 (en) * | 2006-07-14 | 2014-09-30 | Qualcomm Incorporated | Call establishment and maintenance in a wireless network |
| US7920522B2 (en) * | 2006-09-29 | 2011-04-05 | Qualcomm Incorporated | Method and apparatus for system interoperability in wireless communications |
| JP5012044B2 (ja) * | 2007-01-26 | 2012-08-29 | 日本電気株式会社 | コンテンツ配信システム、コンテンツ配信方法及びプログラム |
| US8812712B2 (en) * | 2007-08-24 | 2014-08-19 | Alcatel Lucent | Proxy-driven content rate selection for streaming media servers |
| JP5012397B2 (ja) * | 2007-10-16 | 2012-08-29 | 日本電気株式会社 | 通信システム、方法、装置、およびプログラム |
| RU2367099C1 (ru) * | 2007-12-25 | 2009-09-10 | ВОЕННАЯ АКАДЕМИЯ СВЯЗИ имени С.М. Буденного Министерство Обороны Российской Федерации | Способ управления доступом к сети cdma |
| EP2340652B1 (en) * | 2008-10-31 | 2013-05-22 | Telefonaktiebolaget L M Ericsson (publ) | Policy and charging control method, server, computer program and user terminal therefor |
| EP2359203B1 (en) * | 2008-11-24 | 2015-10-28 | ABB Research Ltd. | A method for providing control and automation services |
| MX2011006349A (es) | 2008-12-17 | 2011-07-13 | Ericsson Telefon Ab L M | Un metodo de y un servidor de red y equipo de usuario movil para proporcionar servicios de charlas/voip en una red de telecomunicacion movil. |
| US8767545B2 (en) * | 2009-06-15 | 2014-07-01 | Qualcomm Incorporated | Radio access network control of multimedia application data rates |
| US11277598B2 (en) * | 2009-07-14 | 2022-03-15 | Cable Television Laboratories, Inc. | Systems and methods for network-based media processing |
| US8743711B2 (en) * | 2009-12-15 | 2014-06-03 | Intel Corporation | Techniques for managing heterogeneous traffic streams |
| US20110161836A1 (en) * | 2009-12-31 | 2011-06-30 | Ruicao Mu | System for processing and synchronizing large scale video conferencing and document sharing |
| CN102158911A (zh) * | 2010-02-11 | 2011-08-17 | 华为技术有限公司 | 机器对机器业务的承载建立方法及网络传输设备 |
| US8441962B1 (en) * | 2010-04-09 | 2013-05-14 | Sprint Spectrum L.P. | Method, device, and system for real-time call announcement |
| US8335192B2 (en) * | 2010-04-13 | 2012-12-18 | Qualcomm Incorporated | Selectively transitioning between physical-layer networks during a streaming communication session within a wireless communications system |
| EP2561665B1 (en) * | 2010-04-19 | 2015-06-17 | Telefonaktiebolaget LM Ericsson (publ) | Pre-scheduling of quality of service reservation |
| US9503511B2 (en) * | 2010-07-08 | 2016-11-22 | Manipal University | Delivery of multimedia service in mobile network |
| US9565318B2 (en) | 2010-10-14 | 2017-02-07 | T-Mobile Usa, Inc. | Quality of service adjustments to improve network utilization |
| US8589509B2 (en) * | 2011-01-05 | 2013-11-19 | Cloudium Systems Limited | Controlling and optimizing system latency |
| US8886699B2 (en) | 2011-01-21 | 2014-11-11 | Cloudium Systems Limited | Offloading the processing of signals |
| US9014170B2 (en) | 2011-02-11 | 2015-04-21 | Interdigital Patent Holdings, Inc. | Method and apparatus for synchronizing mobile station media flows during a collaborative session |
| US8792439B2 (en) * | 2011-10-05 | 2014-07-29 | Alcatel Lucent | Method and system for rate adaptive allocation of resources |
| CN110049515B (zh) | 2011-10-21 | 2024-03-29 | 弗劳恩霍夫应用研究促进协会 | 无线资源管理设备及方法 |
| DE102011088884A1 (de) | 2011-12-16 | 2013-06-20 | Siemens Aktiengesellschaft | Verfahren zur Übertragung von Daten in einem Kommunikationsnetz |
| US9179169B2 (en) | 2012-03-14 | 2015-11-03 | Imagine Communications Corp. | Adaptive media delivery |
| US9306994B2 (en) * | 2012-06-06 | 2016-04-05 | Cisco Technology, Inc. | Stabilization of adaptive streaming video clients through rate limiting |
| US8843656B2 (en) | 2012-06-12 | 2014-09-23 | Cisco Technology, Inc. | System and method for preventing overestimation of available bandwidth in adaptive bitrate streaming clients |
| US9402114B2 (en) | 2012-07-18 | 2016-07-26 | Cisco Technology, Inc. | System and method for providing randomization in adaptive bitrate streaming environments |
| US9516078B2 (en) | 2012-10-26 | 2016-12-06 | Cisco Technology, Inc. | System and method for providing intelligent chunk duration |
| CN103905378B (zh) * | 2012-12-25 | 2017-04-12 | 华为技术有限公司 | 一种传输数据的方法及装置 |
| EP2962462A4 (en) * | 2013-07-24 | 2016-04-06 | Huawei Tech Co Ltd | SYSTEM AND DEVICE FOR NETWORK-BASED ADAPTIVE STREAMING |
| US9699500B2 (en) * | 2013-12-13 | 2017-07-04 | Qualcomm Incorporated | Session management and control procedures for supporting multiple groups of sink devices in a peer-to-peer wireless display system |
| US9363814B2 (en) | 2014-02-25 | 2016-06-07 | Alcatel Lucent | Rate allocation method and apparatus for optimization of adaptive wireless video streaming |
| CN109076062B (zh) * | 2016-02-26 | 2022-01-11 | 网络洞察力有限公司 | 边缘节点控制 |
| EP3497965B1 (en) * | 2016-08-11 | 2022-04-13 | Kyocera Corporation | Ran-assisted rate adaptation |
Family Cites Families (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2724084B1 (fr) | 1994-08-31 | 1997-01-03 | Alcatel Mobile Comm France | Systeme de transmission d'informations par un canal de transmission variant dans le temps, et equipements d'emission et de reception correspondants |
| US6125136A (en) * | 1997-12-31 | 2000-09-26 | Sony Corporation | Method and apparatus for demodulating trellis coded direct sequence spread spectrum communication signals |
| JP2000032048A (ja) * | 1998-07-14 | 2000-01-28 | Fujitsu Ltd | ネットワーク装置 |
| US6487255B1 (en) * | 1998-08-31 | 2002-11-26 | Ericsson Inc. | Information generation for coherent demodulation of differentially encoded signals |
| US6404746B1 (en) * | 1999-07-13 | 2002-06-11 | Intervoice Limited Partnership | System and method for packet network media redirection |
| FI114371B (fi) | 1999-08-09 | 2004-09-30 | Nokia Corp | Menetelmä kantopalvelun valitsemiseksi palvelulle langattomassa matkaviestinjärjestelmässä, tiedonsiirtojärjestelmä ja matkaviestinpäätelaite |
| KR20010017931A (ko) * | 1999-08-16 | 2001-03-05 | 박종섭 | 동기 통신 시스템에서 동기 무선망과 연결되는 망 인터페이스 방법 |
| US7054938B2 (en) * | 2000-02-10 | 2006-05-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for network service reservations over wireless access networks |
| US6477150B1 (en) * | 2000-03-03 | 2002-11-05 | Qualcomm, Inc. | System and method for providing group communication services in an existing communication system |
| US6597919B1 (en) * | 2000-06-23 | 2003-07-22 | Motorola, Inc. | Optimal radio channel allocation in a distributed connection and transport network |
| US7254605B1 (en) * | 2000-10-26 | 2007-08-07 | Austen Services Llc | Method of modulating the transmission frequency in a real time opinion research network |
| US7546376B2 (en) * | 2000-11-06 | 2009-06-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Media binding to coordinate quality of service requirements for media flows in a multimedia session with IP bearer resources |
| US20030172160A9 (en) * | 2001-01-10 | 2003-09-11 | Widegren Ina B. | Method and apparatus for coordinating end-to-end quality of service requirements for media flows in a multimedia session |
| US7106718B2 (en) * | 2001-02-09 | 2006-09-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Signaling quality of service class for use in multimedia communicatations |
| EP1248431B1 (en) * | 2001-03-27 | 2007-10-31 | Sony Deutschland GmbH | Method for achieving end-to-end quality of service negotiation for distributed multimedia applications |
| US7054945B2 (en) * | 2001-04-09 | 2006-05-30 | Nokia Corporation | Technique for providing announcements in mobile-originated calls |
| US7218626B2 (en) * | 2001-05-29 | 2007-05-15 | Interdigital Technology Corporation | System and method for reducing information communicated between universal mobile telecommunication system multimedia capable units |
| ITRM20010421A1 (it) | 2001-07-13 | 2003-01-13 | Univ Roma | Metodo di elezione dinamica del controllore tra gli elaboratori o stazioni di una rete mobile in area locale senza fili, o wlan (wireless lo |
| US7227865B2 (en) * | 2001-08-16 | 2007-06-05 | Interdigital Technology Corporation | Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities |
| KR100864040B1 (ko) * | 2001-11-02 | 2008-10-16 | 인터디지탈 테크날러지 코포레이션 | 양방향 및 역방향 자원 예약 셋업 프로토콜 |
| ATE323356T1 (de) * | 2002-01-08 | 2006-04-15 | Netzwerkauswahl für eine verbindung | |
| JP2003304523A (ja) * | 2002-02-08 | 2003-10-24 | Ntt Docomo Inc | 情報配信システム、情報配信方法、情報配信サーバ、コンテンツ配信サーバ及び端末 |
| GB2386283A (en) * | 2002-03-05 | 2003-09-10 | Pa Consulting Services | Packet data communications network |
| US7206324B2 (en) * | 2002-05-03 | 2007-04-17 | Telefonaktiebolaget Lm Ericsson (Publ) | QoS translator |
| US7451229B2 (en) * | 2002-06-24 | 2008-11-11 | Microsoft Corporation | System and method for embedding a streaming media format header within a session description message |
| US20040028055A1 (en) * | 2002-07-26 | 2004-02-12 | Lila Madour | Differentiated accounting in a packet data network |
| US8161158B2 (en) * | 2002-09-25 | 2012-04-17 | Nokia Corporation | Method in a communication system, a communication system and a communication device |
| US7701915B2 (en) * | 2003-06-27 | 2010-04-20 | Nokia Corporation | Method in a communication system, a communication system and a communication device |
-
2004
- 2004-06-24 US US10/876,262 patent/US7701915B2/en active Active
-
2005
- 2005-03-03 EP EP05751173A patent/EP1721427B1/en not_active Expired - Lifetime
- 2005-03-03 KR KR1020067020654A patent/KR100855610B1/ko not_active Expired - Fee Related
- 2005-03-03 WO PCT/US2005/007518 patent/WO2005088919A2/en not_active Ceased
- 2005-03-03 DE DE602005011578T patent/DE602005011578D1/de not_active Expired - Fee Related
- 2005-03-03 AT AT05751173T patent/ATE417439T1/de not_active IP Right Cessation
- 2005-03-03 JP JP2007502105A patent/JP2007526727A/ja active Pending
- 2005-03-03 US US11/073,029 patent/US20050232148A1/en not_active Abandoned
- 2005-03-03 ES ES05751173T patent/ES2315876T3/es not_active Expired - Lifetime
- 2005-03-03 AU AU2005222356A patent/AU2005222356B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7701915B2 (en) | 2010-04-20 |
| ATE417439T1 (de) | 2008-12-15 |
| DE602005011578D1 (de) | 2009-01-22 |
| EP1721427B1 (en) | 2008-12-10 |
| EP1721427A2 (en) | 2006-11-15 |
| KR20060122978A (ko) | 2006-11-30 |
| US20050025180A1 (en) | 2005-02-03 |
| WO2005088919A3 (en) | 2005-10-20 |
| US20050232148A1 (en) | 2005-10-20 |
| AU2005222356A1 (en) | 2005-09-22 |
| JP2007526727A (ja) | 2007-09-13 |
| AU2005222356B2 (en) | 2009-08-06 |
| KR100855610B1 (ko) | 2008-09-01 |
| WO2005088919A2 (en) | 2005-09-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2315876T3 (es) | Procedimiento para asignar recursos en un sistema de comunicaciones. | |
| RU2337505C2 (ru) | Способ и система для резервирования ресурса в беспроводной сети связи | |
| KR100731963B1 (ko) | 네트워크에서 ＱｏＳ 프로파일 파라미터를 통지 및부여하는 방법, 시스템 및 통신 장치 | |
| US9030933B2 (en) | Bi-directional and reverse directional resource reservation setup protocol |