Un método para su uso por una Función de Control de Llamada/Sesión de Servicio "S-CSCF" de un Sub-sistema Multimedia de IP "IMS",

que comprende: recibir un mensaje de Protocolo de Iniciación de Sesión "SIP" que contiene información relativa a un par de identidad de usuario privado/identidad de usuario público "IMPI/IMPU"; identificar el tipo de información contenida en el mensaje de SIP; identificar si se ha enviado o no anteriormente un paquete previo de datos en relación con el par de IMPI/IMPU a un Servidor de Abonados Domésticos "HSS" para su almacenamiento; crear un nuevo paquete de datos, que contiene la información, para ser enviado a, y almacenado por, el HSS; enviar al HSS un comando de Petición de Asignación de Servidor "SAR" que contiene un Par de Valor de Atributo "AVP" que incluye una instrucción para el HSS y el nuevo paquete de datos; en el que, si un paquete previo de datos para el par de IMPI/IMPU ha sido enviado al HSS para su almacenamiento, entonces el nuevo paquete de datos combina la información relacionada con el par de IMPI/IMPU recibido en el mensaje de SIP con la información contenida en el paquete previo de datos

Almacenamiento de datos de red

Campo técnico

La presente invención se refiere al almacenamiento de datos de red en una red de comunicaciones, por ejemplo en un Sistema Universal de Comunicaciones Móviles que posee un Sistema Multimedia de IP. En particular, la invención se refiere al almacenamiento de datos de red en un Servidor de Abonados Domésticos en un Sub-sistema Multimedia de IP.

Antecedentes Los servicios Multimedia de IP proporcionan una combinación dinámica de voz, video, mensajería, datos, etc., dentro de la misma sesión. Al crecer el número de aplicaciones básicas y los medios que es posible combinar, crecerá el número de servicios ofrecidos a los usuarios finales, y se enriquecerá la experiencia de comunicación inter-personal. Esto conducirá a una nueva generación de servicios de comunicación multimedia intensos, personalizados, incluyendo lo que se conoce como servicios “Multimedia de IP combinacional”.

El Sistema Universal de Telecomunicaciones Móviles (UMTS) es un sistema inalámbrico de tercera generación diseñado para proporcionar tasas más altas de datos y servicios incrementados a los abonados. El UMTS es un sucesor del Sistema Global para Comunicaciones Móviles (GSM) , con una importante etapa evolutiva entre el GSM y el UMTS que es el Servicio General de Radio por Paquetes (GPRS) . El GPRS introduce conmutación por paquetes en la red central de GSM y permite el acceso directo a las redes de datos por paquetes (PDNs) . Esto permite que los paquetes de alta tasa de datos conmuten transmisiones mucho más allá del límite de 64 kbps del ISDN a través de la red de llamada de GSM, lo cual es una necesidad para tasas de transmisión de datos de UMTS de hasta 2 Mbps. El UMTS está estandarizado por el Proyecto Partnership de 3ª Generación (3GPP) , el cual es un conglomerado de organismos de normalización regionales tales como el European Telecommunication Standards Institute (ETSI) , la Association of Radio Industr y Businesses (ARIB) y otros. Véase 3GPP TS 23.002 para más detalles.

La arquitectura de UTMS incluye un sub-sistema conocido como Sub-sistema Multimedia de IP (IMS) para soportar telefonía tradicional, así como nuevos servicios multimedia de IP (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 y TS 29.329 Emisiones 5 a 7) . El IMS proporciona características clave para enriquecer la experiencia de comunicación de persona a persona de usuario final mediante el uso de Habilitadores de Servicio de IMS estandarizado, los cuales facilitan nuevos servicios intensos de comunicación de persona a persona (cliente a cliente) así como servicios de persona respecto a contenido (cliente con servidor) sobre redes basadas en IP. El IMS está capacitado para conectar con la Red de Telefonía Pública Conmutada/Red Digital de Servicios Integrados (PSTN/ISDN) así como con Internet.

El IMS hace uso del Protocolo de Iniciación de Sesión (SIP) para establecer y controlar llamadas o sesiones entre terminales de usuario (o terminales de usuario y servidores de aplicación) . El Protocolo de Descripción de Sesión (SDP) , portado por la emisión se señales de SIP, se utiliza para describir y negociar los componentes multimedia de la sesión. Mientras que el SIP fue creado como un protocolo de usuario a usuario, el IMS permite que los operadores y proveedores de servicio controlen el acceso de usuario a los servicios y facturen a los usuarios de manera correspondiente. El 3GPP ha elegido el SIP para la transmisión de señales entre un Equipo de Usuario (UE) y el IMS, así como también entre los componentes dentro del IMS.

Los detalles específicos de la operación de la red de comunicaciones de UMTS y de los diversos componentes dentro de una red de ese tipo pueden ser encontrados en las Especificaciones Técnicas para UMTS que están disponibles en http://www.3gpp.org. Otros detalles del uso de SIP dentro del UMTS pueden ser encontrados en la Especificación Técnica de 3GPP TS 24.228 V5.8.0 (03-2004) .

La Figura 1 de los dibujos que se acompañan ilustra esquemáticamente cómo se acopla el IMS en la arquitectura de red móvil en el caso de una red de acceso de GPRS/GS (el IMS puede operar, por supuesto, por medio de otras redes de acceso) . Las Funciones de Control de Llamada/Sesión (CSCFs) operan como representantes del SIP dentro del IMS. La arquitectura de 3GPP define tres tipos de CSCFs: la CSCF de Representante (P-CSCF) que es el primer punto de contacto dentro del IMS para un terminal de SIP; la CSCF de Servicio (S-CSCF) que proporciona servicios al usuario a los que el usuario se ha abonado; y la CSCF de Interrogación (I-CSCF) cuyo papel es el de identificar la S-CSCF correcta y enviar a esa S-CSCF una petición recibida desde un terminal de SIP a través de una P-CSCF.

Un usuario se registra en el IMS utilizando el método de REGISTRO SIP. Éste es un mecanismo para adherirse al IMS y anunciar al IMS la dirección en la que puede ser hallada una identidad de usuario de SIP. En 3GPP, cuando un terminal de SIP realiza un registro, el IMS autentica al usuario y asigna una S-CSCF a ese usuario a partir del conjunto de S-CSCFs disponibles. Aunque los criterios para asignar las S-CSCFs no están especificados en el 3GPP, éstos pueden incluir requisitos de servicio y compartir carga. Se aprecia que la asignación de una S-CSCF es clave para controlar (y facturar) accesos de usuario a servicios basados en IMS. Los operadores pueden proporcionar un mecanismo para impedir sesiones directas de SIP de usuario a usuario que pudieran de algún modo eludir la S-CSCF.

Durante el proceso de registro, es responsabilidad de la I-CSCF seleccionar una S-CSCF si no hay ya una S-CSCF seleccionada. La I-CSCF recibe las capacidades de S-CSCF requeridas desde el Servidor de Abonados Domésticos (HSS) de la red doméstica, y selecciona una S-CSCF apropiada en base a las capacidades recibidas. (Se apreciará que la asignación de S-CSCF se lleva también a cabo para un usuario de I-CSCF en caso de que el usuario sea llamado por otro interesado, y normalmente no se asigna al usuario una S-CSCF) . Cuando un usuario registrado envía posteriormente una petición de sesión al IMS, la P-CSCF está capacitada para enviar la petición a la S-CSCF seleccionada en base a la información recibida desde la S-CSCF durante el proceso de registro.

Dentro de la red de servicio de IMS, los Servidores de Aplicación (ASs) han sido previstos para implementar la funcionalidad de servicio de IMS. Los Servidores de Aplicación proporcionan servicios a usuarios finales en un sistema de IMS, y pueden ser conectados ya sea como puntos extremos sobre la interfaz Mr definida de 3GPP, o bien “enlazados en” mediante una S-CSCF sobre la interfaz ISC definida de 3GPP. En el último caso, se utilizan Criterios de Filtro Inicial (IFC) por parte de una S-CSCF para determinar qué Servidores de Aplicaciones deberán ser “enlazados en” durante un establecimiento de Sesión de SIP. Se pueden aplicar diferentes IFCs a casos de llamadas diferentes. Los IFCs son recibidos por la S-CSCF desde un HSS durante el procedimiento de registro de IMS como parte de un Perfil de Usuario del usuario. Algunos Servidores de Aplicación realizarán acciones dependientes de las identidades de abonado (ya sea del abonado llamado o ya sea del llamante, cualquiera que sea “propiedad” de la red que controla el Servidor de Aplicación) . Por ejemplo, en el caso de envío de llamada, el servidor de aplicación (terminal) apropiado determinará el nuevo interesado terminal al que se deberá enviar una llamada para un abonado dado. En el caso de que un IFC indique que un mensaje de SIP recibido en la S-CSCF debe ser enviado a un AS de SIP particular, ese AS se agrega a la trayectoria del mensaje. Una vez que el mensaje de SIP es devuelto por el AS a la S-CSCF, es enviado hacia su destino final, o enviado a otro AS si esto está indicado en los IFCs.

El 3GPP utiliza el concepto de direcciones de contacto en la red de IMS. Estas direcciones están ligadas a una Identidad Privada Multimedia de IP (IMPI) y una Identidad Pública Multimedia de IP (IMPU) y son típicamente direcciones de IP de terminales de usuario. Una IMPU particular puede ser registrada simultáneamente desde múltiples UEs que utilizan IMPIs diferentes y direcciones de contacto diferentes. Eventualmente, puede ser posible registrar una Identidad de Usuario Público que sea compartida simultáneamente a través de múltiples direcciones de contacto (en los mismos UEs o por medio de UEs separados) por medio de procedimientos de registro de IMS.

Algunas entidades de un... [Seguir leyendo]

1. Un método para su uso por una Función de Control de Llamada/Sesión de Servicio “S-CSCF” de un Sub-sistema Multimedia de IP “IMS”, que comprende: recibir un mensaje de Protocolo de Iniciación de Sesión “SIP” que contiene información relativa a un par de identidad de usuario privado/identidad de usuario público “IMPI/IMPU”;

identificar el tipo de información contenida en el mensaje de SIP;

identificar si se ha enviado o no anteriormente un paquete previo de datos en relación con el par de IMPI/IMPU a un Servidor de Abonados Domésticos “HSS” para su almacenamiento; crear un nuevo paquete de datos, que contiene la información, para ser enviado a, y almacenado por, el HSS;

enviar al HSS un comando de Petición de Asignación de Servidor “SAR” que contiene un Par de Valor de Atributo “AVP” que incluye una instrucción para el HSS y el nuevo paquete de datos; en el que, si un paquete previo de datos para el par de IMPI/IMPU ha sido enviado al HSS para su almacenamiento, entonces el nuevo paquete de datos combina la información relacionada con el par de IMPI/IMPU recibido en el mensaje de SIP con la información contenida en el paquete previo de datos.

2. El método de la reivindicación 1, en el que, si el mensaje de SIP es una petición de registro, y ningún paquete previo de datos para el par de IMPI/IMPU ha sido enviado al HSS para su almacenamiento, entonces el AVP del comando SAR contiene la instrucción de “REGISTRO”.

3. El método de la reivindicación 1, en el que:

el mensaje de SIP es una petición de registro para una dirección adicional que ha de ser asociada al par de IMPI/IMPU; y el AVP del comando SAR contiene la instrucción de “RE-REGISTRO”.

4. El método de la reivindicación 1, en el que: el mensaje de SIP no está asociado a registro; y el AVP del comando SAR contiene la instrucción de “ALMACENAR”.

5. El método de la reivindicación 4, en el que el mensaje de SIP contiene una petición de suscripción al paquete de evento de registro para el par de IMPI/IMPU.

6. El método de la reivindicación 1, en el que se borran datos del paquete previo de datos para crear el nuevo paquete de datos.

7. El método de la reivindicación 6, en el que: el mensaje de SIP es una petición de borrado de registro; y el AVP del comando SAR contiene la instrucción de “BORRADO DE REGISTRO”.

8. El método de la reivindicación 6, en el que: el mensaje de SIP no está asociado al borrado de registro; y el AVP del comando SAR contiene la instrucción de “ALMACENAR”.

9. El método de la reivindicación 8, en el que el mensaje de SIP contiene una petición de anulación de suscripción respecto a un paquete de evento de registro para el par de IMPI/IMPU.

10. El método de la reivindicación 6 ó 7, en el que, cuando los datos son borrados del paquete previo de datos, el nuevo paquete de datos está vacío, comprendiendo el método enviar el comando SAR al HSS, conteniendo el AVP del comando SAR la instrucción de “BORRADO DE REGISTRO” y el paquete de datos vacío con el fin de dar la instrucción al HSS de que borre el paquete previo de datos.

11. Un método para su uso en un Sub-sistema Multimedia de IP “IMS”, que comprende: en una Función de Control de Llamada/Sesión de Servicio “S-CSCF”, recibir un mensaje de Protocolo de Iniciación de Sesión “SIP” que contiene información relativa a un par de identidad de usuario privado/identidad de usuario público “IMPI/IMPU”;

en la S-CSCF, identificar el tipo de información contenida en el mensaje de SIP”;

en la S-CSCF, crear un nuevo paquete de datos, que contenga la información, para ser enviado a, y almacenado por, un Servidor de Abonados Domésticos “HSS”; enviar desde la S-CSCF hasta el HSS un primer comando de Petición de Asignación de Servidor “SAR” que contiene un Par de Valor de Tributo “AVP” que incluye una instrucción para el HSS y el nuevo paquete de datos; en el HSS, identificar si está o no almacenado actualmente un paquete previo de datos en relación con el par de IMPI/IMPU;

si no está almacenado actualmente en el HSS un paquete previo de datos en relación con el par de IMPI/IMPU, almacenar el nuevo paquete de datos en el HSS; si está almacenado actualmente en el HSS un paquete previo de datos asociado al par de IMPI/IMPU, devolver un mensaje de error desde el HSS hasta la S-CSCF, incluyendo el mensaje de error el paquete de datos previamente almacenado;

en la S-CSCF, en respuesta al mensaje de error, crear un paquete de datos adicional que combine la información relativa al par de IMPI/IMPU recibida en el mensaje de SIP con la información contenida en el paquete previo de datos;

enviar desde la S-CSCF hasta el HSS un segundo comando SAR que contiene un AVP que incluye la instrucción de “ALMACENAR” y el paquete adicional de datos, y almacenar el paquete adicional de datos en el HSS.

12. Un método para su uso por una Función de Control de Llamada/Sesión de Servicio “S-CSCF” de un Subsistema Multimedia de IP “IMS”, que comprende:

recibir un mensaje de Protocolo de Iniciación de Sesión “SIP” que contiene información relacionada con un par de identidad de usuario privado/identidad de usuario público “IMPI/IMPU”;

identificar el tipo de información contenida en el mensaje de SIP; crear un paquete de datos para ser enviado a, y almacenado por, un Servidor de Abonados Domésticos “HSS”, incluyendo el paquete de datos la información contenida en el mensaje de SIP y una etiqueta de datos que indica el tipo de datos con el fin de proporcionar información al HSS que permita que almacene información de S-CSCF en paquetes de datos separados, etiquetados, direccionables por separado, ligados al par de IMPI/IMPU;

enviar al HSS un comando de Petición de Asignación de Servidor “SAR” que contiene un Par de Valor de Atributo “AVP” que incluye una instrucción para el HSS y el paquete de datos.

13. El método de la reivindicación 12, en el que: el mensaje de SIP es una petición de registro; ningún paquete previo de datos para el par de IMPI/IMPU ha sido enviado al HSS para su almacenamiento; la etiqueta de datos indica que el paquete de datos contiene información de dirección de contacto; y el AVP del comando SAR contiene la instrucción de “REGISTRO”.

14. El método de la reivindicación 12, en el que: el mensaje de SIP es una petición de registro para que una dirección adicional sea asociada al par de IMPI/IMPU;

la etiqueta de datos indica que el paquete de datos contiene información de dirección de contacto; y el AVP del comando SAR contiene la instrucción de “RE-REGISTRO”.

15. El método de la reivindicación 12, en el que: el mensaje de SIP no está asociado a registro; y el AVP del comando SAR contiene la instrucción de “RE-REGISTRO”.

16. El método de la reivindicación 15, en el que:

el mensaje de SIP contiene una petición de suscripción a un paquete de evento de registro para el par de IMPI/IMPU; y la etiqueta de datos incluye una indicación de que el paquete de datos contiene información relacionada con el paquete de evento de registro.

17. El método de la reivindicación 12, en el que:

un paquete de datos previamente almacenado debe ser borrado del HSS;

el AVP del comando SAR contiene la instrucción de “BORRADO DE REGISTRO”; y el paquete de datos contiene solamente la etiqueta de datos y un campo de datos vacío, para indicar al HSS que un paquete de datos previamente almacenado e identificado mediante la misma etiqueta de datos debe ser borrado.

18. El método de la reivindicación 17, en el que:

el mensaje de SIP es una petición de borrado de registro; y la etiqueta de datos indica que el paquete de datos contiene información de dirección de contacto.

19. Una Función de Control de Llamada/Sesión de Servicio “S-CSCF” asignable para dar servicio a un abonado registrado en un Sub-sistema Multimedia de IP “IMS”, comprendiendo la S-CSCF:

un receptor para recibir un mensaje de Protocolo de Iniciación de Sesión “SIP” que contiene información relacionada con un par de identidad de usuario privado/identidad de usuario público “IMPI/IMPU”;

un procesador para identificar el tipo de información contenida en el mensaje de SIP y crear un nuevo paquete de datos, que contenga la información, para ser enviado a, y almacenado por, el HSS; y un emisor para enviar a un Servidor de Abonados Domésticos “HSS” un comando de Petición de Asignación de Servidor “SAR” que contiene un Par de Valor de Atributo “AVP” que incluye una instrucción para el HSS y el nuevo paquete de datos;

en la que, si un paquete previo de datos para el par de IMPI/IMPU ha sido enviado al HSS para su almacenamiento, entonces el procesador está configurado para que combine la información relativa al par de IMPI/IMPU recibida en el mensaje de SIP con la información contenida en el paquete previo de datos.

20. La S-CSCF de la reivindicación 19, en la que el procesador está configurado para que identifique si el paquete previo de datos relativo al par de IMPI/IMPU ha sido o no enviado previamente al HSS para su almacenamiento.

21. La S-CSCF de la reivindicación 19, en la que el procesador y el emisor están configurados para enviar el comando SAR sin comprobar inicialmente si un paquete previo de datos para el par de IMPI/IMPU fue enviado al HSS para su almacenamiento, y en la que el receptor, el procesador y el emisor están configurados de modo que, si un paquete previo de datos asociado al par de IMPI/IMPU está actualmente almacenado en el HSS:

el receptor recibe un mensaje de error desde el HSS, incluyendo el mensaje de error el paquete de datos previamente almacenado;

el procesador crea un paquete de datos adicional que combina la información relacionada con el par de IMPI/IMPU recibida en el mensaje de SIP con la información contenida en el paquete previo de datos; y el emisor envía al HSS un segundo comando SAR que contiene un AVP que incluye la instrucción de “ALMACENAR” y el paquete adicional de datos.

22. La S-CSCF de la reivindicación 19, en la que el procesador está configurado para incluir en el nuevo paquete de datos una etiqueta de datos que indique el tipo de datos.

23. Un Servidor de Abonados Domésticos “HSS” que mantiene datos de abonado para abonados de un Subsistema Multimedia de IP “IMS”, comprendiendo el HSS:

un receptor para recibir desde una Función de Control de Llamada/Sesión de Servicio “S-CSCF” un comando de Petición de Asignación de Servidor “SAR” que contiene un Par de Valor de Atributo “AVP” que incluye una instrucción para el HSS y un paquete de datos que contiene información extraída de una petición de SIP relacionada con un par de IMPI/IMPU; y medios de almacenamiento para almacenar el paquete de datos; un procesador para identificar si un paquete previo de datos relativo al par de IMPI/IMPU está actualmente almacenado en los medios de almacenamiento; y un emisor configurado para enviar un mensaje de error, que incluye el paquete previo de datos relacionado con el par de IMPI/IMPU, hasta la S-CSCF si el paquete previo de datos está actualmente almacenado en 5 los medios de almacenamiento, estando los medios de almacenamiento configurados para retener el paquete previo de datos;

en el que, si se envía el mensaje de error, el receptor está configurado para recibir desde la S-CSCF un segundo comando SAR que contiene un AVP que incluye la instrucción de “ALMACENAR” y un paquete adicional de datos, combinando el paquete adicional de datos la información extraída de la petición de SIP

relacionada con el par de IMPI/IMPU con la información contenida en el paquete previo de datos;

y en el que los medios de almacenamiento están configurados para almacenar el paquete adicional de datos.

24. El HSS de la reivindicación 23, en el que el emisor está configurado para enviar el mensaje de error a la S-CSCF solamente si el comando SAR contiene la instrucción de “RE-REGISTRO” o de “BORRADO DE REGISTRO”.

25. El HSS de la reivindicación 23 ó 24, en el que los medios de almacenamiento están configurados para almacenar el paquete de datos y sobre-escribir cualesquiera paquetes de datos previamente almacenados con relación al par de IMPI/IMPU si el comando SAR contiene la instrucción de “ALMACENAR”.