ES2414874T3 - Un procedimiento y una disposición para el establecimiento de una sesión de comunicaciones para multimedia - Google Patents

Abstract

Un procedimiento de establecimiento de una sesión multimedia de conmutación de paquetes para un terminalmóvil en comunicación con otra parte, en el que un contexto PDP, Packet Data Protocol, primario ha sido activado enuna red móvil para el terminal móvil, comprendiendo el procedimiento las etapas siguientes, tal como se ejecutan enla red móvil: - recibir información acerca de la próxima sesión, que ha sido negociada y acordada entre las partescomunicantes, - determinar si se necesita o no algún recurso de red que proporcione una QoS requerida para la sesión en lared móvil, - determinar si debe activarse o no un contexto PDP secundario para el terminal móvil y la próxima sesión,y si se necesitan recursos de red y si debe activarse un contexto PDP secundario, - desencadenar la activación de dicho contexto PDP secundario. en el que dichas etapas de determinación y etapa de desencadenamiento son ejecutadas por una unidad de normas,responsable básicamente de autorizar las sesiones de comunicación en la red móvil.

Description

Un procedimiento y una disposición para el establecimiento de una sesión de comunicaciones para multimedia.

Campo técnico

La presente invención se refiere, en general, a un procedimiento y una disposición para el establecimiento de una sesión de comunicaciones para multimedia que implican un terminal móvil.

Antecedentes de la invención y técnica anterior

Con la aparición de la telefonía móvil 3G, se han desarrollado nuevas tecnologías de comunicaciones basadas en paquetes para dar soporte a la comunicación multimedia. Por ejemplo, las tecnologías GPRS (General Packet Radio Service, Servicio General de Paquetes vía Radio) y WCDMA (Wideband Code División Multiple Access, Acceso Múltiple por División de Código de Banda Ancha) dan soporte a servicios inalámbricos de telefonía multimedia que implican la comunicación por conmutación de paquetes de datos que representan imágenes, textos, documentos, animaciones, archivos de audio, archivos de vídeo, etc., además de las llamadas de voz tradicionales mediante conmutación de circuitos.

Típicamente, los servicios multimedia implican la transmisión de datos codificados que representan texto, documentos, imágenes, archivos de audio y archivos de vídeo en diferentes formatos y combinaciones. El término "multimedia" se usará en la presente descripción para hacer referencia, en general, a cualquier elección de medios comunicados usando la tecnología de transporte IP (Internet Protocol) basada en paquetes.

Una arquitectura de red llamada "Subsistema Multimedia IP” (IP Multimedia Subsystem, IMS) ha sido desarrollada por el Proyecto de Colaboración de 3ª generación (3rd Generation Partnership Project, 3GPP) como un estándar abierto para la gestión de servicios multimedia y sesiones en el dominio de paquetes. IMS es una plataforma para permitir servicios basados en transporte IP, más o menos independientes de la tecnología de acceso usada, y tampoco está limitada a ningún servicio específico. De esta manera, una red IMS controla las sesiones multimedia pero no es usada para la transferencia real de datos de carga útil que es direccionada a través de redes de acceso y cualquier red de transporte intermedia.

La descripción "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications Systems (UMTS); General Packet Radio Service (GPRS); Service Description; Stage 2 (3GPP TS 23.060 versión

5.9.0 Publicación 5); ETSI TS 123 060, 96.MPEG Meeting; 21.03.2011 - 25.03.2011; Génova; (Motion Picture Expert Group o ISO/IEC JTC1/SC29/EG11), LIS, Sophia Antipolis Cedex, Francia, vol. 3-SA2, no. V5.0.0, 1 de Septiembre de 2004 (1/09/2004) describe un procedimiento para determinar si se necesita o no un segundo contexto, Packet Data Protocol, PDP, sugiriendo un procedimiento de activación de contexto PDP solicitado por la red. El documento D1 describe cómo debe tomarse una decisión en la red en lugar de por el UE.

La descripción "Network Initiated Secondary PDP Context activation procedure", Borrador 3GPP; S2-99D27, 3RD Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route des Lucioles; F-06921 Sophia-Antipolis Cedex; Francia, vol. SA WG2, no. Abiko; 19991208, 8 de Diciembre de 1999 (8/12/1999) describe un procedimiento de activación de contexto PDP secundario iniciado por la red, que permite al GGSN iniciar la activación de un contexto PDP secundario. El procedimiento de activación de contexto PDP secundario puede ser iniciado solo cuando un contexto PDP está ya establecido para la misma dirección PDP. Una decisión acerca de la activación de un contexto PDP secundario en base a las necesidades de QoS no está completamente bajo el control de la red, si no que puede ser tomada en cooperación con el UE.

El documento WO 03/058866 A2 describe un procedimiento para activar un contexto PDP en una red celular que puede incluir la activación del contexto PDP en base a la determinación que puede estar basada en un desencadenante que se produce cuando una notificación es enviada al Nodo de Soporte de Servidor GPRS (Serving GPRS Support Node, SGSN).

La Fig. 1 es una ilustración esquemática simplificada de una estructura de red básica para proporcionar servicios multimedia por medio de una red de servicios IMS. Un primer terminal móvil A está conectado a una primera red 100 de acceso por radio y se comunica con un segundo terminal móvil B conectado a una segunda red 102 de acceso por radio, en una sesión S de comunicación que implica uno o más servicios multimedia. Puede haber también una red troncal intermedia, no mostrada, que une las redes 100 y 102 de acceso.

Una red 104 IMS está conectada a la primera red 100 de acceso por radio y gestiona la sesión con respecto al terminal A. En esta figura, una red 106 IMS correspondiente gestiona la sesión en nombre del terminal B, y las dos redes 104 y 106 IMS pueden estar controladas por operadores diferentes. De manera alternativa, los terminales A y B pueden estar conectados, por supuesto, a la misma red de acceso y/o pueden pertenecer a la misma red IMS. Por el contrario, el terminal A puede comunicarse también con un terminal, ordenador o servidor fijo, por ejemplo, para descargar algunos datos a través de Internet, siempre que la otra parte tenga la capacidad de comunicación SIP. Además, si un terminal está en itinerancia en una red de acceso visitada, los servicios multimedia son gestionados por la red IMS "doméstica" del terminal.

La sesión S mostrada en la Fig. 1 es gestionada por nodos específicos en cada red IMS, denominados en la presente memoria, en general, "nodos gestores de sesión" 108. Típicamente, estos nodos incluyen S-CSCF (Serving Call Session Control Function, Función de Control de Sesión de Llamada de Servicio), I-CSCF (Interrogating Call Session Control Function, Función de Control de Sesión de Llamada de Interrogación) y P-CSCF (Proxy Call Session Control Function, Función de Control de Sesión de Llamada Proxy). Cada red 104, 106 IMS incluye también uno o más servidores 110 de aplicaciones para permitir diversos servicios multimedia. Además, un elemento de base de datos principal HSS (Home Subscriber Server, Servidor de Abonados Domésticos) 112 almacena datos de abonado y de autenticación, así como información de servicio, entre otras cosas. Básicamente, la red 106 IMS es similar a la red 104. En general, las diversas funciones específicas de los elementos 108-112 de red mostrados son conocidas en la técnica, pero no es necesario describirlas adicionalmente en la presente memoria para entender el contexto de la presente invención. Por supuesto, las redes 104, 106 IMS contienen numerosos nodos y funciones diferentes no mostrados en la presente memoria, en aras de la simplicidad.

Se ha definido una especificación para la gestión de sesiones en redes IMS llamada "SIP" (Session Initiation Protocol, Protocolo de Inicio de Sesión, según el estándar IETF RFC 3261). SIP es un protocolo de control de capa de aplicación para la señalización, para crear y gestionar, en general, sesiones sobre una lógica de conmutación de paquetes. De esta manera, el estándar SIP es usado por los sistemas IMS y terminales con capacidad SIP para establecer y controlar las comunicaciones multimedia IP. El propio SIP no proporciona servicios multimedia, sino que proporciona un conjunto de primitivas que otros protocolos o aplicaciones pueden usar para implementar realmente este tipo de servicios.

Por ejemplo, se define un mensaje llamado "INVITE" en SIP para iniciar una sesión multimedia durante el establecimiento de sesión, cuando se ha invocado una aplicación determinada. Típicamente, el mensaje SIP INVITE incluye, entre otras cosas, una descripción de la sesión, es decir, información sobre el códec o códecs requeridos y otros parámetros de comunicación necesarios para la próxima sesión.

SIP usa un protocolo adicional llamado Protocolo de Descripción de Sesión (Session Description Protocol, SDP), para describir sesiones multimedia, que puede estar incluido como un cuerpo autónomo dentro de los mensajes SIP. SDP puede ser usado por los terminales para intercambiar información relacionada con sus capacidades y preferencias específicas, con el fin de negociar y acordar los parámetros de sesión, códecs particulares a usar durante una próxima sesión multimedia, tal como es bien conocido en la técnica. Los parámetros de sesión preferentes o necesarios pueden estar indicados como atributos, denominados "condiciones previas" en la información SDP.

Muchas aplicaciones móviles requieren una cierta Calidad de Servicio (Quality of Service, QoS), con el fin de proporcionar un resultado satisfactorio para los usuarios finales. Para las redes UMTS, se han definido cuatro clases principales de tráfico: "clase de conversación", "clase de flujo continuo", "clase interactiva" y "clase de fondo o de segundo plano", con el fin de clasificar las diferentes necesidades en cuanto a las velocidades de bits y los retrasos. Estas clases de tráfico se distinguen, principalmente, por sus necesidades con respecto a los retrasos de transferencia, de manera que las aplicaciones de la clase de conversación toleran sólo pequeños retrasos, denominado también, a veces, "tiempo real", mientras que la clase de fondo se aplica a las aplicaciones menos sensibles al retraso, denominado también, a veces, "mejor esfuerzo".

La selección de una clase de tráfico UMTS para una aplicación se usa para asignar un canal físico adecuado en la red de acceso, denominado, generalmente, un RAB (Radio Access Bearer, Portador de Acceso de Radio), con el fin de optimizar los escasos recursos de radio en la red de acceso, mientras se mantiene una calidad aceptable para el usuario final.

Típicamente, los terminales móviles con capacidad multimedia están configurados normalmente para identificar, para cada aplicación inherente, una clase de tráfico UMTS, tal como se ilustra esquemáticamente en la Fig. 2. De esta manera, un terminal móvil puede contener un número de aplicaciones 200, denotadas como A1, A2, A3, A4, A5 .... Una función 202 de asignación en el terminal traduce cada aplicación a una clase 204 de tráfico UMTS determinada, de las cuales sólo se muestran dos en la presente memoria. En este caso, las aplicaciones A1, A2 y A4 se asignan a la misma clase 2 de tráfico UMTS, ya que tienen necesidades similares con relación a la velocidad de bits y el retraso, mientras que las aplicaciones A3 y A5 son asignadas a la clase 1 de tráfico UMTS. De esta manera, varias aplicaciones con características similares pueden ser asignadas al mismo RAB, cumpliendo sus necesidades.

Sin embargo, antes de que un terminal móvil pueda intercambiar un mensaje SIP con la red IMS, debe establecerse un “contexto PDP (Packet Data Protocol, Protocolo de Paquetes de Datos)” para el terminal. Básicamente, un contexto PDP puede ser activado una vez que el terminal ha sido encendido. La activación de un contexto PDP para un terminal móvil incluye la asignación de una dirección IP temporal al terminal, para que sea capaz de comunicar los paquetes de datos con el terminal. Un contexto PDP significa también que un canal físico es asignado en la red de acceso, denominado, en general, un RAB (Radio Access Bearer, Portador de Acceso de Radio), para la comunicación IP. De esta manera, los mensajes SIP sólo pueden ser enviados a través de un contexto PDP.

La Fig. 3 ilustra la activación gradual de un terminal móvil A que está a punto de realizar una comunicación multimedia con otra parte B, que implica básicamente cinco etapas 3:1 - 3:5, tal como se ilustra, comprendiendo cada una varios mensajes de ida y vuelta. Estos mensajes son bien conocidos en la técnica y no se describirán en detalle. El terminal A se encuentra bajo la cobertura de radio de una red 300 de acceso móvil, que se divide en una parte 300a de red de radio y una parte 300b de red de núcleo.

La red 300b de núcleo mostrada en la Fig. 3 incluye un GGSN (Gateway GPRS Switching Node, Nodo de Conmutación de Pasarela GPRS) 304 y una "unidad de normas " 306, denominada frecuentemente PDF (Policy Decision Function, Función de Decisión de Normas) o PCRF (Policy and Charging Rule Function, Función de Normas de Carga y Política). Básicamente, la unidad de normas es responsable de autorizar las sesiones de comunicación. Por supuesto, la red 300 contiene numerosos otros nodos y elementos que no es necesario describir para entender el contexto de la presente invención. En aras de la simplicidad, la red IMS del terminal A se representa aquí, meramente, como un "núcleo IMS" 308, que contiene varios nodos, no mostrados, implicados en los procedimientos que se describen a continuación.

En una primera Etapa 3:1, un contexto PDP básico, denominado "primario", es activado para obtener una conexión IP. La activación del contexto PDP primario incluye la obtención de un RAB, para los mensajes de señalización SIP por conmutación de paquetes a través de IP. El contexto PDP es creado por el GGSN 304. Típicamente, este RAB se basa en la denominada comunicación de "mejor esfuerzo" sin ningún requisito particular con respecto a la velocidad de bits y el retraso, ya que sólo está destinado a transportar, ocasionalmente, mensajes SIP limitados.

En una etapa 3:2 siguiente, el terminal A se registra con el núcleo 308 IMS, gestionado aquí, básicamente, por un nodo S-CSCF y HSS, no mostrado. El registro IMS implica una cierta cantidad de señalización basada en SIP sobre el contexto PDP primario.

A continuación, debe establecerse una sesión multimedia con la parte B en una etapa 3:3 siguiente. En esta etapa, el protocolo SDP indicado anteriormente es usado dentro de los mensajes SIP, tales como INVITE, para comunicar parámetros específicos de la sesión que incluyen códecs, donde algunos parámetros pueden estar indicados como condiciones previas.

Típicamente, un terminal llamante propone uno o más códecs, junto con otros parámetros, para su uso durante la sesión, tal como se especifica en un mensaje INVITE, y el terminal llamado responde confirmando un códec propuesto adecuado, y cualquier otro parámetro propuesto, en un mensaje de "OK (invite)". La Etapa 3:3 incluye, además, la autorización de la sesión en la unidad 306 de normas, en base a los datos de la sesión y los datos de abonado almacenados. La Etapa 3:3 incluye también un procedimiento para reservar recursos de comunicación en la red 300 móvil que se adaptan a la próxima sesión con la parte B y según los parámetros confirmados por ambas partes en su diálogo SIP.

El establecimiento de la sesión y la reserva de recursos implican la activación de un contexto PDP secundario para el terminal A, indicada aquí como una Etapa 3:4 separada, que debería ser adaptada para el tipo o tipos de medios implicados en la próxima sesión. Los siguientes parámetros de QoS pueden ser indicados en el contexto PDP secundario: Clase de tráfico, máxima velocidad de bits (enlace ascendente/descendente), velocidad de bits garantizada (enlace ascendente/descendente), retraso de transferencia (enlace ascendente/descendente), orden de entrega, máximo tamaño de SDU (Service Data Unit, Unidad de Datos de Servicio) y un Descriptor Estadístico de Fuente (Source Statistic Descriptor).

El contexto PDP secundario es gestionado por el GGSN de la misma manera que para el contexto PDP primario en la Etapa 3:1. De esta manera, el contexto PDP secundario debería ser definido de manera que se cumplan los requisitos de la sesión con respecto a la información de parámetros de QoS, así como otros factores, con el fin de obtener un RAB apropiado para la comunicación de los medios. De esta manera, el nuevo RAB es más estable y fiable en comparación con el primer RAB asociado con el contexto PDP primario, y debería proporcionar una QoS "garantizada".

Cuando, finalmente, el contexto PDP secundario ha sido establecido, la sesión debe ser reconocida y los recursos reservados deben ser activados, como se ilustra en una Etapa 3:5, antes de comenzar la sesión real en una Etapa

3:6 final ilustrada, sobre el contexto PDP secundario. A veces, la activación de los recursos de red se denomina "apertura de puertas".

El procedimiento de establecimiento de una sesión, reserva de recursos de red, activación del contexto PDP secundario y activación de los recursos reservados, tal como se ilustra en las etapas 3:3-3:5, requiere una cantidad considerable de señalización secuencial, según lo dictado por los protocolos estandarizados. Además, debe llevarse a cabo un procedimiento similar para la otra parte, al menos si la otra parte es también un terminal móvil. En particular, la Etapa 3:3 no puede ser ejecutada al mismo tiempo en ambos lados, ya que el lado B en este caso reservará recursos de red antes de confirmar los parámetros de sesión al lado B, según las normas vigentes. De esta manera, la reserva de recursos de red en el lado A debe esperar hasta que se hayan recibido los parámetros de sesión confirmados desde el lado B.

De esta manera, la comunicación de los medios se retrasa debido a la extensa señalización secuencial necesaria según los procedimientos convencionales de establecimiento para las sesiones multimedia. En el campo de las comunicaciones móviles, en general, es conveniente minimizar dichos retrasos para hacer los servicios multimedia más atractivos para los usuarios finales de los móviles. Por ejemplo, cuando se usa el servicio denominado "Push-to-Talk over Celular (PoC)" (“Pulsar para hablar sobre Celular”), que emula un servicio walkie-talkie, los usuarios desean hablar inmediatamente después de presionar una tecla “pulsar para hablar” o similar, aunque esto desencadena, básicamente, todo el procedimiento de las etapas 3:3-3:5 anteriores.

Además, la reserva de los recursos de red es iniciada por el terminal móvil y, por lo tanto, está parcialmente fuera del control de un operador de red. De esta manera, es deseable, en general, que los operadores de red tengan un control total de la asignación de los recursos de red a los diferentes usuarios.

Sumario de la invención

Un objeto de la presente invención es, en general, hacer posible evitar o al menos reducir los problemas expuestos anteriormente. Más específicamente, un objeto de la presente invención es hacer posible la reducción del retraso antes de que un terminal móvil pueda iniciar la comunicación de medios, y permitir que un operador de red tenga el control sobre los recursos de red.

Estos objetos y otros se obtienen proporcionando un procedimiento y una disposición según las reivindicaciones independientes adjuntadas a continuación.

Según un aspecto de la invención, se proporciona un procedimiento para establecer una sesión multimedia de conmutación de paquetes para un terminal móvil en comunicación con otra parte, en el que un contexto PDP primario (Protocolo de Paquetes de Datos) ha sido activado en una red móvil para el terminal móvil. El procedimiento de la invención puede ser ejecutado en la red móvil. La información acerca de la próxima sesión es recibida, la cual ha sido negociada y acordada entre las partes comunicantes. A continuación, se determina si se necesita algún recurso de red que proporcione una QoS requerida para la sesión en la red móvil. También se determina si debe activarse o no un contexto PDP secundario para el terminal móvil y la sesión siguiente. Si se necesitan recursos de red y debe activarse un contexto PDP secundario, se desencadena la activación de dicho contexto PDP secundario, en el que dichas etapas de determinación y etapa de desencadenamiento son ejecutadas por una unidad de normas responsable, básicamente, de autorizar las sesiones de comunicación en la red móvil.

La información de la sesión puede ser incluida en una respuesta desde una parte llamada a una invitación de sesión desde una parte llamante, en la que dicha respuesta confirma, de manera efectiva, los parámetros de sesión propuestos en la invitación de sesión. La información de sesión puede ser derivada a partir de un SDP (Protocolo de Descripción de Sesión) proporcionado en dicha respuesta.

La presencia de un indicador de medios en el SDP recibido y la descripción de sesión en el propio SDP, pueden ser usadas para determinar si se necesita o no algún recurso de red que proporcione una QoS requerida para la sesión, de manera que una indicación "activo" en el SDP implica que se han reservado recursos de red y, por lo tanto, no son necesarios, mientras que cuando dicho indicador de medios indica "inactivo" en el SDP, implica que no se han reservado recursos de red y, por lo tanto, son necesarios. Las condiciones previas, proporcionadas como atributos en el SDP, pueden ser usadas también para determinar si se necesita o no algún recurso de red que proporcione una QoS requerida, de manera que se necesitan recursos de red cuando actualmente no se cumplen las condiciones previas proporcionadas, y viceversa.

Los datos de suscripción y autenticación para dicho terminal móvil y su usuario, y también el tipo de aplicación o servicio que se ha invocado para la próxima sesión, pueden ser usados para determinar si un contexto PDP secundario debe ser activado o no para la próxima sesión.

La unidad de normas puede ser una PDF (Policy Decision Function, Función de Decisión de Normas) o una PCRF (Policy and Charging Rule Function, Función de Normas de Carga y Política).

La activación del contexto PDP secundario puede ser desencadenada enviando una solicitud de activación de un contexto PDP secundario para el terminal, a un GGSN en la red móvil. La solicitud de activación de un contexto PDP secundario puede ser incluida en un mensaje "Credit Control Request CCR” (“Solicitud de Control de Crédito CCR") existente, modificado, que puede ser enviado al GGSN sobre un protocolo Gx basado en DIAMETER. En respuesta a la recepción de dicha solicitud de activación de un contexto PDP secundario, el GGSN puede instalar normas para la próxima sesión y puede enviar una orden al terminal móvil para iniciar un contexto PDP secundario.

Según otro aspecto de la invención, se proporciona una disposición en una red móvil para el establecimiento de una sesión multimedia de conmutación de paquetes para un terminal móvil en comunicación con otra parte, en el que un contexto PDP primario (Protocolo de Paquetes de Datos) ha sido activado en la red móvil para el terminal móvil. La disposición comprende medios para recibir información relacionada con la próxima sesión que se han negociado y acordado entre las partes en comunicación, medios para determinar si se necesita o no algún recurso de red que proporcione una QoS garantizada para la sesión, medios para determinar si debe activarse o no un contexto PDP secundario para el terminal móvil y la próxima sesión, y medios para desencadenar la activación de dicho contexto PDP secundario si se necesitan recursos de red que proporcionen una QoS requerida y debe activarse un contexto PDP secundario, en el que dichos medios de determinación y medios de desencadenamiento están incluidos en una unidad de normas responsable, básicamente, de autorizar las sesiones de comunicación en la red móvil.

La disposición puede comprender además medios para extraer dicha información de sesión desde una respuesta de una parte llamada a una invitación de sesión desde una parte llamante, en el que dicha respuesta confirma, de manera efectiva, los parámetros de sesión propuestos en la invitación de sesión. La disposición puede comprender, además, medios para derivar la información de sesión a partir de un SDP (Session Description Protocol, Protocolo de Descripción de Sesión) proporcionado en dicha respuesta.

La disposición puede comprender, además, medios para el uso de la presencia de un indicador de medios en el SDP recibido y la descripción de sesión en el propio SDP, para determinar si se necesita o no algún recurso de red que proporcione una QoS necesaria para la sesión, de manera que una indicación "activo" en el SDP implica que se han reservado recursos de red y, por lo tanto, no son necesarios, mientras que cuando dicho indicador de medios indica "inactivo" en el SDP, implica que no se han reservado recursos de red y, por lo tanto, son necesarios.

La disposición puede comprender, además, medios para el uso de las condiciones previas proporcionadas como atributos en el SDP para determinar si se necesita o no algún recurso de red que proporcione una QoS requerida, de manera que los recursos de red son necesarios cuando actualmente no se cumplen las condiciones previas proporcionadas, y vice versa.

La disposición puede comprender, además, medios para el uso de los datos de suscripción y de autenticación para dicho terminal móvil y su usuario, y también el tipo de aplicación o servicio que ha sido invocado para la próxima sesión, para determinar si debe activarse o no un contexto PDP secundario para la próxima sesión.

La unidad de normas puede ser una PDF (Policy Decision Function, Función de Decisión de Normas) o una PCRF (Policy and Charging Rule Function, Función de Normas de Carga y Política).

La disposición puede comprender, además, medios para el desencadenamiento de la activación del contexto PDP secundario mediante el envío de una solicitud de activación de un contexto PDP secundario para el terminal, a un GGSN en la red móvil. La disposición puede comprender además medios para incluir dicha solicitud de activación de un contexto PDP secundario en un mensaje "Solicitud de Control de Crédito CCR" existente, modificado, que es enviado al GGSN sobre un protocolo Gx basado en DIAMETER.

La disposición puede comprender, además, medios en un GGSN para la instalación de normas para la próxima sesión y para enviar una orden al terminal móvil para iniciar un contexto PDP secundario, en respuesta a la recepción de dicha solicitud para la activación de un contexto PDP secundario.

Otras características adicionales de la presente invención y sus beneficios ser explicarán en la descripción detallada siguiente.

Breve descripción de los dibujos

Ahora, la presente invención se describirá más detalladamente mediante las realizaciones preferidas y con referencia a los dibujos adjuntos, en los que:

La Fig. 1 es una vista esquemática de una estructura de red convencional para la comunicación de datos multimedia entre dos terminales móviles.

La Fig. 2 es un diagrama esquemático que ilustra la asignación de aplicaciones a las clases de tráfico UMTS en un terminal móvil.

La Fig. 3 es un diagrama de señalización que ilustra las diferentes etapas en el procedimiento de establecimiento de una sesión multimedia según la técnica anterior.

La Fig. 4 es un diagrama de flujo que ilustra un procedimiento para establecer una sesión multimedia, según un aspecto de la presente invención.

La Fig. 5 es un diagrama de señalización que ilustra diferentes etapas de mensajería para el establecimiento de una sesión multimedia, según una realización preferida.

Descripción de las realizaciones preferidas

En la presente invención, la tarea de desencadenar la activación de un contexto PDP secundario para un terminal móvil es trasladada desde el terminal a su red de núcleo móvil, o sino la red de núcleo móvil "doméstica" si el terminal está en itinerancia en otra parte. De esta manera, el operador de red puede tener un control total sobre sus recursos de red, puede reducirse el retraso antes del inicio de la sesión y pueden evitarse los conflictos de señalización.

Ahora, se describirá un procedimiento esquemático para el establecimiento de una sesión multimedia para dos partes que se comunican, incluyendo un terminal móvil, según un aspecto de la presente invención, con referencia a un diagrama de flujo mostrado en la Fig. 4. Se supone que se ha solicitado una sesión de comunicación que implica el terminal móvil, bien por dicho terminal móvil o bien por una parte contraria. En una primera Etapa 400, se recibe información acerca de la próxima sesión que ha sido negociada y acordada entre las partes comunicantes. La información de la sesión puede ser derivada a partir del SDP proporcionado en una respuesta desde una parte llamada a una invitación de sesión, en la que la respuesta confirma, de manera efectiva, los parámetros de sesión propuestos, tal como el mensaje de respuesta denominado OK (invite) indicado anteriormente.

En una Etapa 402 siguiente, se determina si se necesita o no algún recurso de red que proporcione una QoS requerida para la sesión. Según diferentes realizaciones, esto puede determinarse comprobando la presencia de un "indicador de medios" denominado "inactivo", que es un atributo existente actualmente en SDP usado para indicar si los recursos de los medios están inactivos. Por otro lado, si el indicador de medios "inactivo" no está presente, los recursos de medios están activos. En una realización de la presente invención, se propone usar el indicador de medios de manera que si el indicador de medios no está presente (activo), implica que los recursos de red han sido reservados y, por lo tanto, no es necesario reservar ningún recurso activando un contexto PDP secundario. Sin embargo, cuando el indicador de medios está presente (inactivo), no se han reservado recursos de red, los cuales, por lo tanto, son necesarios.

De manera alternativa, los atributos marcados como condiciones previas en el SDP pueden ser usados para determinar si se necesitan o no recursos de red que proporcionen una Qos requerida, de manera que dichos recursos de red son necesarios cuando actualmente no se cumplen las condiciones proporcionadas, y viceversa.

Cabe señalar que puede usarse cualquier mecanismo para indicar la necesidad de reserva de recursos, y la presente invención no está limitada a los ejemplos descritos anteriormente.

Si en la Etapa 402 se determina que en la actualidad no se necesitan recursos de red que proporcionen una QoS requerida, no es necesario activar un contexto PDP secundario, en consecuencia, y puede usarse un procedimiento ordinario para completar el establecimiento de la sesión, tal como se indica mediante una Etapa 404.

Sin embargo, si en la Etapa 402 se determinó que se necesitan recursos de red que proporcionen una QoS requerida, en una Etapa 406 siguiente, se determina además si un contexto PDP secundario debe ser activado o no para la próxima sesión. La decisión de activar un contexto PDP secundario se basa además en diversos datos de suscripción y de autenticación, y también en el tipo de aplicación o servicio que ha sido invocado para la próxima sesión. Por ejemplo, ciertas aplicaciones pueden requerir una QoS que requiere un contexto PDP secundario, mientras que otras no lo necesitan. Una suscripción de usuario móvil puede permitir una cierta QoS y/o ciertas preferencias por ciertos servicios, o puede denegar el acceso a otros servicios, etc.

Si en la Etapa 406 se determinó que no debe activarse ningún contexto PDP secundario, puede usarse el procedimiento ordinario indicado por la Etapa 404 para completar el establecimiento de la sesión. Si de hecho debe activarse un contexto PDP secundario, es decir, si la sesión puede ser autorizada, el procedimiento pasa a la última Etapa 408 ilustrada, para desencadenar la activación del contexto PDP secundario para el terminal móvil y la próxima sesión. Cuando se ejecuta el procedimiento de la presente invención según las Etapas 400, 402, 406 y 408 anteriores, el operador de red obtendrá el control total sobre la asignación de recursos asociados generalmente con la activación del contexto PDP secundario. El retraso en el establecimiento también puede ser reducido, ya que el procedimiento requiere, generalmente, menos señalización y puede tener lugar simultáneamente y de manera independiente para el terminal opuesto, lo que se hará evidente a partir de la descripción de la Fig. 5, más adelante.

Tal como se comprenderá a partir de la realización descrita más adelante, el procedimiento para establecer una sesión multimedia según el diagrama de flujo mostrado en la Fig. 4 puede ser implementado, básicamente, en una unidad de normas o elemento similar perteneciente a una red de acceso móvil, por ejemplo, tal como la unidad 306 mostrada en la Fig. 3. La unidad de normas puede ser una PDF (Función de Decisión de Normas) o una PCRF (Función de Normas de Carga y Política) y es responsable, básicamente, de autorizar las sesiones de comunicación. Además, el GGSN 304 y el núcleo 308 IMS de la Fig. 3 pueden requerir algunas adaptaciones al nuevo comportamiento de la unidad 306 de normas.

La Fig. 5 es un diagrama de señalización que ilustra diferentes etapas para establecer una sesión multimedia entre un terminal móvil A y otra parte B, según una realización preferida. Esta realización muestra cómo ciertos mensajes estándar existentes para el establecimiento de sesión pueden ser utilizados para transmitir la información necesaria para la activación de un contexto PDP secundario, si es necesario. De manera similar a la Fig. 3, los elementos de red implicados incluyen un GGSN 500 y una unidad 502 de normas que pertenece a una red móvil doméstica del terminal A, y un núcleo 504 IMS asociado con la misma red móvil. El lado opuesto de la red, no mostrado, es básicamente igual si la parte B es también un terminal móvil.

Se supone que se ha activado un contexto PDP primario para el terminal A para mensajes de señalización, tal como se describe para la Etapa 3:1 anterior. El procedimiento comienza en una Etapa 5:1 cuando el terminal A envía un mensaje INVITE hacia la parte B, con el fin de ejecutar una sesión multimedia que implica, en general, la comunicación de medios en cualquier dirección o en ambas direcciones. El mensaje INVITE contiene un SDP con los parámetros de sesión propuestos, y es transportado sobre el núcleo 504 IMS al lado B, tal como se indica por una flecha discontinua. Debido a que en este punto no se comunican medios, se asume que el terminal A ha fijado el indicador de medios como "inactivo" en el SDP del mensaje INVITE.

Después de haber considerado los parámetros de sesión de propuestos indicados en el mensaje INVITE recibido, B envía un mensaje de respuesta OK (invite) de vuelta al terminal A, en una Etapa 5:2 siguiente. Tal como se ha descrito anteriormente, la parte B incluye un SDP correspondiente en el mensaje OK (invite) que contiene los parámetros de sesión confirmados, que pueden ser usados en la próxima sesión por ambas partes A, B. Además, se espera que la parte B mantenga el indicador de medios como inactivo en el SDP en este mensaje.

Cuando el núcleo 504 IMS detecta el mensaje de respuesta OK desde B en la Etapa 5:2, la información SDP es traducida al protocolo Rx basado en DIAMETER, al que se añaden detalles de suscripción del terminal A como una base para una rutina ordinaria de autorización/Autenticación. A continuación, toda esta información es emitida a la unidad 502 de normas en un mensaje existente denominado " Solicitud de autorización/autenticación AAR" (“Authorisation/Authentication Request AAR”) para el terminal A, en una Etapa 5:3 siguiente. Hasta este momento, el procedimiento se ha ejecutado según procedimientos ordinarios para la iniciación y autorización de la sesión.

En una Etapa 5:4 siguiente, la unidad 506 de normas toma una decisión en relación a si debe activarse o no un contexto PDP secundario para el terminal A y la próxima sesión. Básicamente, la decisión se toma tal como se ha descrito anteriormente para las Etapas 402 y 406 de la Fig. 4 y, por lo tanto, no es necesario repetirlo aquí en detalle. Sin embargo, cabe señalar que el mensaje AAR existente se utiliza en esta realización para transportar el indicador de medios para proporcionar una base para la decisión, junto con una identidad de aplicación proporcionada en el SDP y dichos detalles de suscripción. De manera alternativa, las condiciones previas pueden ser proporcionadas en el SDP como una base similar para la decisión, tal como se ha descrito anteriormente.

En este ejemplo, se supone que la unidad 502 de normas decide en la Etapa 5:4 activar un contexto PDP secundario, por ejemplo, después de leer un indicador de medios inactivo, o detectar que no se cumplen determinadas condiciones previas. Por lo tanto, en una Etapa 5:5 siguiente, una solicitud para iniciar un contexto PDP secundario para el terminal A es enviada desde la unidad 502 de normas al GGSN 500. Esta solicitud puede ser transmitida, por ejemplo, usando un mensaje de control de crédito estándar. En este ejemplo, un mensaje existente "Solicitud de Control de Crédito CCR” (“Credit Control Request") es modificado para incluir dicha solicitud y es enviado al GGSN 500 sobre un protocolo Gx basado en DIAMETER. Este mensaje, que en los procedimientos ordinarios de la técnica anterior es enviado normalmente en sentido inverso desde el GGSN a la unidad de normas durante la activación del contexto PDP, puede ser usado, de esta manera, para transportar la solicitud de iniciar un contexto PDP secundario para el terminal A, incluyendo, entre otras cosas, los requisitos de QoS. Este mensaje desencadena, de manera efectiva, la activación del contexto PDP secundario, tal como es ejecutado por el GGSN 500 que ahora puede asignar recursos de red, incluyendo un RAB, al terminal A. De esta manera, el desencadenamiento está controlado por la unidad de normas, es decir, efectivamente el operador de red, en lugar de por el terminal.

A continuación, el nodo GGSN inicia el contexto PDP secundario, por ejemplo, enviando una solicitud para que el terminal invoque el procedimiento normal para la activación de un contexto PDP secundario con los parámetros definidos en la solicitud de iniciación. Sin embargo, la presente invención no está limitada en este sentido, y puede usarse cualquier mecanismo para la activación del contexto PDP secundario, que implique o no el terminal. En este ejemplo, sin embargo, el GGSN 500 envía un mensaje "Solicitud de contexto PDP" (Request PDP Context”) al terminal A, en una Etapa 5:6. Este mensaje ordena, de manera efectiva, al terminal A "iniciar" el contexto PDP secundario de una manera ordinaria. En este punto, el GGSN 500 también instala "normas", tal como se indica en una Etapa 5:7, que se usarán durante la sesión para controlar la transferencia de medios. La instalación de normas incluye el almacenamiento de parámetros de QoS específicos de la sesión y la carga de parámetros, así como la dirección IP y un número de puerto del terminal A a usar, etc. En respuesta al mensaje recibido en la Etapa 5:6, en consecuencia, el terminal A envía un mensaje "Inicia contexto PDP" (“Initiate PDP Context”) al GGSN 500, en una Etapa 5:8, que es reconocido por medio de un mensaje "Acepta contexto PDP" (“Accept PDP context”) enviado de vuelta desde el GGSN en una Etapa 5:9.

Cabe señalar que la Etapa 5:7 podría ser ejecutada en cualquier momento después de la Etapa 5:5, pero antes de la Etapa 5:10 siguiente en la que el GGSN 500 envía un mensaje Gx estándar modificado CCA “Respuesta de Control de Crédito”, ("Credit Control Answer”), a la unidad 502 de normas, como una respuesta al mensaje Gx CCR de la Etapa 5:5. El mensaje CCA Gx, que normalmente es enviado a la inversa desde la unidad de normas al GGSN según la técnica anterior, ha sido modificado ahora de manera que contenga información acerca del contexto PDP secundario activado. De esta manera, el mensaje Gx CCA existente es utilizado para transportar esta información a la unidad de normas en la Etapa 5:10, pero también puede ser usado todavía para el control de crédito ordinario, junto con el mensaje CCR Gx de la Etapa 5:5, tal como se pretendía originalmente.

A continuación, la unidad 502 de normas puede continuar con el envío de una respuesta estándar al mensaje Rx AAR, recibido en la Etapa 5:3, denominado Rx AAA "Respuesta de autorización/autenticación" (“Authorisation/Authentication Answer”), en una Etapa 5:11. Este mensaje indica que la sesión ha sido autorizada ahora y se han reservado recursos de red, permitiendo de esta manera el inicio de la sesión. Después de recibir el mensaje "Aceptar contexto PDP" (“Accept PDP context”) en la Etapa 5:9, el terminal A envía ahora un nuevo mensaje INVITE a la parte B, en una Etapa 5:12, que carece esta vez del indicador de medios "inactivo" en el SDP, que indica, en consecuencia, "activo”, y la parte opuesta responde con un mensaje OK (INVITE) con un SDP que, en consecuencia, indica" activo", en una Etapa 5:13 siguiente. Las dos últimas etapas reconocen la sesión como activa, y la comunicación de medios puede tener lugar en una Etapa 5:14 final.

Mediante la implementación de la presente invención, por ejemplo, según las realizaciones descritas anteriormente, el operador de red tendrá el control total de sus recursos de red al establecer una sesión multimedia para un terminal móvil, ya que el operador, en lugar del terminal, puede decidir cuándo desencadenar un contexto PDP secundario. Puede reducirse también el retraso antes de inicio de la sesión.

Los procedimientos actuales según la técnica anterior pueden resultar también en conflictos de señalización, denominados como "condición de carrera" (“race condition”), al establecer el indicador de medios en el SDP a inactivo, ya que un usuario que responde (por ejemplo, el usuario B) establece el SDP a activo (es decir, que carece del indicador de medios "inactivo") al aceptar la descripción de la sesión. El usuario que responde puede enviar el mensaje de aceptar Sesión (SIP OK Invite) y el mensaje de reserva de recursos casi al mismo tiempo. Esto permitirá al usuario que responde iniciar un contexto PDP secundario antes de que los recursos sean reservados en la unidad de normas en la red móvil, lo que resulta en un fallo en el establecimiento de PDP, a menos que la señal de reserva de recursos desencadenada por la respuesta aceptar sesión haya llegado en primer lugar a la unidad de normas, de ahí la condición de carrera. El uso de la presente invención evitará dicho conflicto.

Aunque la invención se ha descrito con referencia a realizaciones ejemplares específicas, en general, la descripción sólo pretende ilustrar el concepto de la invención y no debería considerarse como una limitación del alcance de la invención. Por ejemplo, el protocolo de señalización SIP y el concepto IMS han sido usados durante la descripción de las realizaciones anteriores, aunque, básicamente, pueden usarse cualquier otra norma y redes de servicio para permitir la comunicación multimedia. La presente invención está definida por las reivindicaciones adjuntas.

Claims (20)

1. REIVINDICACIONES

   1. Un procedimiento de establecimiento de una sesión multimedia de conmutación de paquetes para un terminal móvil en comunicación con otra parte, en el que un contexto PDP, Packet Data Protocol, primario ha sido activado en una red móvil para el terminal móvil, comprendiendo el procedimiento las etapas siguientes, tal como se ejecutan en la red móvil:

   recibir información acerca de la próxima sesión, que ha sido negociada y acordada entre las partes comunicantes,

   determinar si se necesita o no algún recurso de red que proporcione una QoS requerida para la sesión en la red móvil,

   determinar si debe activarse o no un contexto PDP secundario para el terminal móvil y la próxima sesión,

   y si se necesitan recursos de red y si debe activarse un contexto PDP secundario,

   desencadenar la activación de dicho contexto PDP secundario.

   en el que dichas etapas de determinación y etapa de desencadenamiento son ejecutadas por una unidad de normas, responsable básicamente de autorizar las sesiones de comunicación en la red móvil.

2. 2.

   Procedimiento según la reivindicación 1, en el que dicha información de la sesión es incluida en una respuesta desde una parte llamada a una invitación de sesión desde una parte llamante, confirmando dicha respuesta, de manera efectiva, los parámetros de sesión propuestos en la invitación de sesión.

3. 3.

   Procedimiento según la reivindicación 2, en el que la información de la sesión es derivada a partir de un SDP, Protocolo de Descripción de Sesión (Session Description Protocol) proporcionado en dicha respuesta.

4. 4.

   Procedimiento según la reivindicación 3, en el que la presencia de un indicador de medios en el SDP recibido y la descripción de la sesión en el propio SDP, se usan para determinar si se necesita o no algún recurso de red que proporcione una QoS requerida para la sesión, de manera que una indicación "activo" en el SDP implica que se han reservado recursos de red y, por lo tanto, no son necesarios, mientras que cuando dicho indicador de medios indica "inactivo" en el SDP, implica que los recursos de red no han sido reservados y, por lo tanto, son necesarios.

5. 5.

   Procedimiento según la reivindicación 3, en el que las condiciones previas proporcionadas como atributos en el SDP se usan para determinar si se necesita o no algún recurso de red que proporcione una QoS requerida, de manera que los recursos de red son necesarios cuando actualmente no se cumplen las condiciones previas proporcionadas, y viceversa.

6. 6.

   Procedimiento según cualquiera de las reivindicaciones 1-5, en el que los datos de suscripción y de autenticación para dicho terminal móvil y su usuario, y también el tipo de aplicación o servicio que se ha invocado para la próxima sesión, se usan para determinar si debe activarse o no un contexto PDP secundario para la próxima sesión.

7. 7.

   Procedimiento según la reivindicación 1, en el que la unidad de normas es una PDF, Función de decisión de normas o una PCRF, Función de Normas de Carga y Política.

8. 8.

   Procedimiento según la reivindicación 7, en el que la activación del contexto PDP secundario es desencadenada mediante el envío de una solicitud de activación de un contexto PDP secundario para el terminal, a un GGSN en la red móvil.

9. 9.

   Procedimiento según la reivindicación 8, en el que dicha solicitud de activación de un contexto PDP secundario es incluida en un mensaje "Control de Crédito Solicitud CCR" existente modificado que es enviado al GGSN sobre un protocolo Gx basado en DIAMETER.

10. 10.

    Procedimiento según la reivindicación 8 ó 9, en el que, en respuesta a la recepción de dicha solicitud para la activación de un contexto PDP secundario, el GGSN instala normas para la próxima sesión y envía una orden al terminal móvil para iniciar un contexto PDP secundario.

11. 11.

    Una disposición en una red móvil para establecer una sesión multimedia de conmutación de paquetes para un terminal móvil en comunicación con otra parte, en la que se ha activado un contexto PDP, Protocolo de Paquetes de Datos, primario en la red móvil para el terminal móvil, que comprende:

    medios para recibir información acerca de la próxima sesión que ha sido negociada y acordada entre las partes comunicantes,

    medios para determinar si se necesita o no algún recurso de red que proporcione una QoS garantizada para la sesión,

    medios para determinar si debe activarse o no un contexto PDP secundario para el terminal móvil y la próxima sesión, y

    medios para desencadenar la activación de dicho contexto PDP secundario, si se necesitan recursos de red que proporcionen una QoS requerida y debe activarse un contexto PDP secundario.

    en la que dichos medios de determinación y medios de desencadenamiento están incluidos en una unidad de normas que es responsable, básicamente, de autorizar las sesiones de comunicación en la red móvil.

12. 12.

    Disposición según la reivindicación 11, que comprende además medios para extraer dicha información de sesión desde una respuesta de una parte llamada a una invitación de sesión desde una parte llamante, confirmando, de manera efectiva, dicha respuesta los parámetros de sesión propuestos en la invitación de sesión.

13. 13.

    Disposición según la reivindicación 12, que comprende además medios para derivar la información de sesión desde un SDP, Protocolo de Descripción de Sesión, proporcionado en dicha respuesta.

14. 14.

    Disposición según la reivindicación 13, que comprende además medios para usar la presencia de un indicador de medios en el SDP recibido y la descripción de sesión en el propio SDP, para determinar si se necesita o no algún recurso de red que proporcione una QoS requerida para la sesión, de manera que una indicación "activa" en el SDP implica que se han reservado recursos de red y, por lo tanto, no son necesarios, mientras que cuando dicho indicador de medios indica "inactivo" en el SDP, implica que los recursos de red no han sido reservados y, por lo tanto, son necesarios.

15. 15.

    Disposición según la reivindicación 13 ó 14, que comprende además medios para usar las condiciones previas proporcionadas como atributos en el SDP para determinar si se necesita o no algún recurso de red que proporcione una QoS requerida, de manera que los recursos de red son necesarios cuando actualmente no se cumplen las condiciones previas proporcionadas, y vice versa.

16. 16.

    Disposición según cualquiera de las reivindicaciones 11-15, que comprende además medios para el uso de los datos de suscripción y de autenticación para dicho terminal móvil y su usuario, y también el tipo de aplicación o servicio que ha sido invocado para la próxima sesión, para determinar si debe activarse o no un contexto PDP secundario para la próxima sesión.

17. 17.

    Disposición según la reivindicación 11, en la que la unidad de normas es una PDF, Función de decisión de normas o una PCRF, Función de Normas de Carga y Política.

18. 18.

    Disposición según la reivindicación 17, que comprende además medios para el desencadenamiento de la activación de un contexto PDP secundario mediante el envío de una solicitud de activación de un contexto PDP secundario para el terminal, a un GGSN en la red móvil.

19. 19.

    Disposición según la reivindicación 18, que comprende además medios para incluir dicha solicitud para la activación de un contexto PDP secundario en un mensaje " Solicitud de Control de Crédito CCR" existente, modificado, que es enviado al GGSN sobre un protocolo Gx basado en DIAMETER.

20. 20.

    Disposición según la reivindicación 18 ó 19, que comprende además medios en un GGSN para la instalación de normas para la próxima sesión y para el envío de una orden al terminal móvil para iniciar un contexto PDP secundario, en respuesta a la recepción de dicha solicitud para la activación de un contexto PDP secundario.