Método de inicio de una comunicación del Subsistema Multimedia IP para un usuario que no está registrado a priori en el Subsistema Multimedia IP,

comprendiendo el método:

recibir una solicitud de comunicación desde el usuario no registrado, en un Servidor de Aplicaciones del Protocolo de Inicio de Sesión a través de una interfaz con una red externa, o recibir un estímulo generado interna o externamente que requiere el establecimiento de una comunicación del Subsistema Multimedia IP;

asignar una Función de Control de Llamadas/Estados de Servicio al usuario no registrado;

enviar una solicitud de Protocolo de Inicio de Sesión desde el Servidor de Aplicaciones hacia la Función de Control de Llamadas/Estados de Servicio asignada; y establecer la comunicación solicitada.

Metodo para iniciar comunicaciones basadas en el IMSI

Campo de la invención

La presente invención se refiere a un metodo y un aparato para iniciar comunicaciones basadas en el Subsistema 5 Multimedia IP (IMS) y, en particular, para iniciar comunicaciones para usuarios que no estan registrados en el IMS.

Antecedentes de la invención

Los servicios Multimedia IP (IPMM) proporcionan una combinación dinamica de voz, video, mensajeria, datos, etcetera, dentro de la misma sesión. Con el aumento del numero de aplicaciones basicas y los medios que es posible combinar, aumentara el numero de servicios ofrecidos a los usuarios finales, y se enriquecera la experiencia de la comunicación interpersonal. Esto conducira a una nueva generación de servicios de comunicación multimedia enriquecidos, personalizados, incluyendo los servicios denominados "Multimedia IP combinatorios" que se consideran de forma mas detallada posteriormente.

El Subsistema Multimedia IP (IMS) es la tecnologia definida por el Proyecto de Asociación de Tercera Generación (3GPP) para proporcionar servicios Multimedia IP a traves de redes de comunicaciones móviles (3GPP TS 22.228, 15 TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 y TS 29.329 Versión 5 y Versión 6) . El IMS proporciona caracteristicas clave para enriquecer la experiencia de comunicación de persona-a-persona de los usuarios finales, a traves de la integración y la interacción de servicios. El IMS permite nuevas comunicaciones enriquecidas de persona-a-persona (cliente-a-cliente) asi como de persona-a-contenido (cliente-a-servidor) a traves de una red basada en el IP. El IMS hace uso del Protocolo de Inicio de Sesión (SIP) para establecer y controlar llamadas o sesiones entre terminales de usuario (o terminales de usuario y servidores de aplicaciones) . El Protocolo de Descripción de Sesión (SDP) , transportado mediante senalización SIP, se usa para describir y negociar los componentes de los medios de la sesión. Aunque el SIP se cre6 como un protocolo de usuario-a-usuario, el IMS permite que los operadores y los proveedores de servicios controlen el acceso de los usuarios a servicios y que cobren, de forma correspondiente, a los usuarios.

La Figura 1 ilustra esquematicamente cómo encaja el IMS en la arquitectura de una red móvil en el caso de una red de acceso GPRS/PS. Las Funciones de Control de Llamadas/Sesiones (CSCFs) funcionan como proxies SIP con el IMS. La arquitectura del 3GPP define tres tipos de CSCFs: el CSCF Proxy (P-CSCF) , que es el primer punto de contacto dentro del IMS para un terminal SIP; la CSCF de Servicio (S-CSCF) , que proporciona al usuario servicios a los que esta abonado dicho usuario; y la CSCF de Interrogación (I-CSCF) cuyo papel es identificar la S-CSCF

correcta y reenviar a esta S-CSCF una solicitud recibida desde un terminal SIP a traves de una P-CSCF.

Un usuario se registra en el IMS usando el metodo especificado SIP REGISTER. Este es un mecanismo para incorporarse al IMS y para anunciar al IMS la dirección en la que se puede contactar con una identidad de usuario SIP. En el 3GPP, cuando un terminal SIP lleva a cabo un registro, el IMS autentica al usuario, y asigna a ese usuario una S-CSCF de entre el conjunto de S-CSCFs disponibles. Aunque los criterios para asignar S-CSCFs no estan especificados por el 3GPP, los mismos pueden incluir requisitos de compartición de carga y servicios. Se observa que la asignación de una S-CSCF es clave para controlar (y cobrar por) el acceso de los usuarios a servicios basados en el IMS. Los operadores pueden proporcionar un mecanismo para evitar sesiones SIP directas de usuario-a-usuario que, de otro modo, eludirian la S-CSCF.

Durante el proceso de registro, es responsabilidad de la I-CSCF seleccionar una S-CSCF si es que no se ha seleccionado ya una S-CSCF. La I-CSCF recibe las capacidades requeridas S-CSCF desde el Servidor de Abonados Domesticos (HSS) de la red domestica, y selecciona una S-CSCF apropiada sobre la base de las capacidades recibidas. [Se observa que la asignación de la S-CSCF es llevada tambien para un usuario por la I-CSCF en el caso de que al usuario le llame otro participante, y el usuario no tenga asignada en ese momento una S-CSCF]. Cuando posteriormente un usuario registrado envia una solicitud de sesión al IMS, la P-CSCF puede 45 reenviar la solicitud a la S-CSCF seleccionada, sobre la base de información recibida desde la S-CSCF durante el proceso de registro.

Dentro de la red de servicio IMS, se proporcionan servidores de aplicaciones (ASs) para implementar una funcionalidad de servicio IMS. Aunque originalmente se concibi6 que los ASs funcionaran como "esclavos" con respecto a las CSCFs IMS, respondiendo a solicitudes delegadas por las S-CSCFs, esto no es necesario que sea 50 asi y, de hecho, en la actualidad se espera que los ASs puedan tener interfaces con redes externas (es decir, no del 3GPP) , y que puedan recibir un estimulo interno para realizar una acción (por ejemplo, la expiración de un temporizador) . La Figura 2 ilustra la interfaz de Control de Servicio IMS (ISC) entre un AS y una S-CSCF, asi como otras interfaces dentro del IMS. Aunque el AS en la Figura 2 se muestra de manera que tiene solamente una unica interfaz con una S-CSCF, se apreciara que, en la practica, la interfaz de ISC discurrira a traves de una red de 55 comunicaciones a la cual estan conectados muchos (o la totalidad) de los servidores de CSCF de la red de un operador dado, permitiendo que un AS se comunique con todas estas CSCFs. [Otras entidades ilustradas en la Figura 1 seran bien conocidas para aquellos expertos en la materia].

Existe otra interfaz (Ut) entre el AS y el terminal de usuario (TS23.002) aunque la misma no se muestra en la Figura. La interfaz Ut permite que el usuario gestione información relacionada con sus servicios, por ejemplo, la creación y asignación de Identidades de Servicios Publicos, gestión de politicas de autorización que son usadas, por ejemplo, por servicios de "presencia", gestión de politicas de conferencias, etcetera.

La arquitectura IMS actual permite que un AS inicie una sesión IMS en respuesta a la recepción, por parte del AS, de una solicitud apropiada a traves de una interfaz externa. Se podria concebir, por ejemplo, el envio de una solicitud de sesión IMS hacia el AS a traves de una interfaz HTTP, donde un usuario da inicio al envio de una solicitud accediendo a una pagina web en Internet. En este caso, al producirse la recepción de la solicitud de sesión, el AS en primer lugar contactara con un Servidor de Abonados Domesticos (HSS) del usuario iniciador para determinar si el usuario ya esta registrado o no en el IMS. El AS envia al HSS una identidad SIP generada para el usuario y que puede ser usada por el HSS para determinar si el usuario esta o no registrado. En caso afirmativo, el HSS enviara al AS la identidad de la S-CSCF ya asignada al usuario. A continuación, el AS reenviara un SIP INVITE a la S-CSCF identificada, y el procedimiento de establecimiento de sesión continuara tal como se ilustra en la Figura 3. Un escenario ejemplificativo en el que podria surgir esta situación es el caso en el que un abonado móvil 3GPP esta registrado en el IMS, y el abonado a continuación entra en una pagina web, a traves de un PC domestico, y solicita una sesión IMS a traves de ese canal.

Si se da el caso de que el usuario no esta registrado todavia en el IMS, y el HSS comunica esto al AS, la solicitud no se puede procesar. La TS.228 establece especificamente que "Si el AS no pudiera adquirir una dirección de S-CSCF para la Identidad de Usuario Publico, el AS no iniciara una sesión en nombre del usuario".

Se apreciara que surge un problema similar cuando el estimulo para establecer una sesión IMS se genera internamente, dentro del AS. Por ejemplo, se puede concebir un escenario en el que se haya solicitado al AS que realice una actualización del estado de un usuario en un servidor de presencia en un tiempo solicitado. Como en el caso de un servicio que se origina externamente, las normas actuales permitiran que el AS inicie la sesión IMS requerida unicamente si el usuario en cuestión esta registrado en el IMS.

Aunque la argumentación anterior se refiere a un usuario que se supone que es un usuario que posee una identidad de usuario publico, el usuario puede ser una aplicación, es decir, que posea una identidad de servicio publico.

Sumario de la invención

Se reconoce que los usuarios claramente pueden desear acceder a servicios IMS incluso cuando no esten registrados todavia en el IMS, y, en particular, cuando... [Seguir leyendo]

1. Metodo de inicio de una comunicación del Subsistema Multimedia IP para un usuario que no esta registrado a priori en el Subsistema Multimedia IP, comprendiendo el metodo:

recibir una solicitud de comunicación desde el usuario no registrado, en un Servidor de Aplicaciones del Protocolo de Inicio de Sesión a traves de una interfaz con una red externa, o recibir un estimulo generado interna o externamente que requiere el establecimiento de una comunicación del Subsistema Multimedia IP;

asignar una Función de Control de Llamadas/Estados de Servicio al usuario no registrado;

enviar una solicitud de Protocolo de Inicio de Sesión desde el Servidor de Aplicaciones hacia la Función de Control de Llamadas/Estados de Servicio asignada; y establecer la comunicación solicitada.

2. Metodo segun la reivindicación 1, en el que dicha etapa de asignar una Función de Control de Llamadas/Estados de Servicio al usuario no registrado la lleva a cabo el Servidor de Aplicaciones.

3. Metodo segun la reivindicación 2, en el que el Servidor de Aplicaciones obtiene capacidades de Función de Control de Llamadas/Estados de Servicio de un Servidor de Abonados Domesticos y asigna una Función de Control de Llamadas/Estados de Servicio basandose en estas capacidades, y a continuación, envia una solicitud de Protocolo de Inicio de Sesión a la CSCF de Servicio asignada.

4. Metodo segun la reivindicación 1, en el que dicha etapa de asignar una Función de Control de Llamadas/Estados de Servicio al usuario no registrado la lleva a cabo una CSCF de Interrogación al producirse la recepción de una solicitud de Protocolo de Inicio de Sesión desde el Servidor de Aplicaciones.

5. Metodo segun la reivindicación 4, en el que el Servidor de Aplicaciones envia la solicitud SIP a la CSCF de Interrogación, y, como respuesta, la CSCF de Interrogación obtiene capacidades de Función de Control de Llamadas/Estados de Servicio de un Servidor de Abonados Domesticos y asigna una Función de Control de Llamadas/Estados de Servicio basandose en estas capacidades, enviando a continuación, la CSCF de Interrogación, la solicitud de Protocolo de Inicio de Sesión a la CSCF de Servicio asignada.

6. Metodo segun la reivindicación 1, en el que dicha etapa de asignar una Función de Control de Llamadas/Estados de Servicio al usuario no registrado la lleva a cabo una CSCF de Servicio.

7. Metodo segun la reivindicación 6, en el que el Servidor de Aplicaciones envia la solicitud de Protocolo de Inicio de Sesión a una CSCF de Servicio, y, como respuesta, esa CSCF de Servicio obtiene capacidades de Función de Control de Llamadas/Estados de Servicio de un Servidor de Abonados Domesticos, y asigna una Función de Control de Llamadas/Estados de Servicio basandose en estas capacidades, enviando a continuación, la CSCF de Servicio, la solicitud de Protocolo de Inicio de Sesión a la CSCF de Servicio asignada en caso de que la CSCF de Servicio no sea ella misma.

8. Metodo segun una cualquiera de las reivindicaciones anteriores, y que comprende enviar desde el Servidor de Abonados Domesticos al Servidor de Aplicaciones un testigo de seguridad, y enviar este testigo de seguridad desde el Servidor de aplicaciones junto con dicha solicitud de Protocolo de Inicio de Sesión como medios de validación de la solicitud.

9. Metodo segun la reivindicación 8, y que comprende, al producirse la recepción de dicha solicitud en la Función de Control de Llamadas/Estados de Servicio asignada, reenviar dicho testigo de seguridad al Servidor de Abonados Domesticos, validando, el Servidor de Abonados Domesticos, el testigo en nombre de la Función de Control de Llamadas/Estados de Servicio.

10. Metodo segun una cualquiera de las reivindicaciones anteriores, y que comprende transferir un perfil de servicio para el usuario no registrado desde el Servidor de Abonados Domesticos a la Función de Control de Llamadas/Estados de Servicio asignada, incluyendo este perfil de servicio información de perfil para solicitudes sin registro de origen.