ES2374002T3

ES2374002T3 - Almacenamiento de datos de red.

Info

Publication number: ES2374002T3
Application number: ES07847611T
Authority: ES
Inventors: María-Carmen BELINCHÓN VERGARA; Hubert Przybysz; Juan Manuel FERNÁNDEZ GALMES
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2007-11-30
Filing date: 2007-11-30
Publication date: 2012-02-10
Anticipated expiration: 2027-11-30
Also published as: WO2009068113A1; US20100306397A1; EP2215805B1; EP2215805A1; US8510457B2; ATE528905T1; JP2011508469A; JP5236007B2

Abstract

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.

Description

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 Industry 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 IMS son entidades críticas que se espera que sean resistentes a fallos puesto que un fallo en tales entidades puede provocar un importante fallo de red y que una enorme cantidad de abonados de dicha red se queden incapacitados para comunicar. En particular, una S-CSCF que da servicio a un número de abonados de IMS es una de esas entidades cuyo fallo podría hacer que el IMS alcance condiciones anómalas de procesamiento de modo que un número de abonados de IMS atendidos por la S-CSCF no podrían hacer un uso apropiado de los servicios o incluso no podrían hacer llamadas. A este respecto la mayor parte de, o todas, las características van acompañadas de un reseteo de la entidad que falla y una restauración después de que el fallo ha sido resuelto, probablemente volviendo a cargar datos estables permanentes si se ha encontrado que datos inconsistentes sean una razón para el fallo. Otras cuestiones pueden necesitar también que una entidad crítica quede fuera de servicio, por ejemplo un software o un hardware actualizado que no puede entrar en operación sin producir un reinicio de la entidad crítica afectada.

Un mecanismo para recuperar la red después de un restablecimiento de IMS ha sido discutido en el artículo CP070031.0 de trabajo de 3GPP y el estudio resultante 3GPP TS 23.820 v0.3.0, y v.0.4.0. Este estudio contiene la propuesta de que la S-CSCF debe almacenar alguna información de red en el HSS para su recuperación posterior después de un fallo de S-CSCF. En esta propuesta, la naturaleza de estos datos son las cabeceras de contacto registradas del usuario incluyendo la Visualización-Nombre, SIP URI y todos los parámetros de cabecera de contacto, junto con la cabecera de trayectoria y la fecha y la hora asociadas al registro.

Sin embargo, pueden existir otros tipos de información que la S-CSCF puede necesitar almacenar en el HSS con el fin de recuperarse por completo a partir del fallo. Un ejemplo de tal información son las suscripciones al paquete de evento de registro manejado por la S-CSCF. Es importante que esta información sea recuperada por la S-CSCF, puesto que contiene detalles de las entidades como los UEs, las P-CSCFs y los ASs que se han suscrito al evento. En caso de que esta información se pierda, estas entidades suscriptoras permanecerán sin saber si el usuario se ha dado de baja de otro modo. Esto puede conducir a su vez a un intento por una entidad suscriptora de iniciar el tráfico como si el usuario estuviera registrado, dando lugar a un fallo en la red.

Así, las propuestas existentes para que los datos de S-CSCF sean almacenados en HSS no cubren todos los datos que la S-CSCF puede necesitar almacenar en el HSS para estar en condiciones de recuperarse por completo y alinear información de estado a través del IMS. Las propuestas existentes son de naturaleza general y no detallan el método mediante el que se almacenan los datos de S-CSCF en el HSS.

Una propuesta incluye el uso del comando Cx de Petición de Asignación de Servidor (SAR) durante el proceso de registro para almacenar la información de datos de contacto en el HSS. Sin embargo, este mecanismo no es aplicable fácilmente cuando se utilizan múltiples direcciones de contacto, puesto que la baja en el registro de una dirección de contacto puede conducir a que otras direcciones de contacto no puedan ser registradas, y por lo tanto no darán como resultado ningún cambio del estado de registro del usuario.

Además, se debe hacer alguna indicación de cómo se almacenan las direcciones de contacto en el HSS, puesto que un comando de SAR normal conduce a la sobre-escritura de información de contacto previa en el caso de un reregistro.

Existe por tanto una necesidad de un mecanismo adecuado mediante el que la información de S-CSCF (tal como direcciones de contacto e información de paquete de evento de registro) pueda ser almacenada en el HSS y borrada cuando se necesite.

Sumario

La invención introduce un mecanismo genérico en la interfaz Cx para el almacenamiento y la recuperación de datos en el HSS mediante la S-CSCF.

La invención se divulga de acuerdo con las reivindicaciones anexas. De acuerdo con un aspecto de la presente invención se proporciona un método para su uso por una S-CSCF de un IMS. El método comprende recibir un mensaje de SIP que contiene información relativa a un par IMPI/IMPU e identificar el tipo de información contenida en el mensaje de SIP. La S-CSCF identifica también si previamente se ha enviado o no un paquete anterior de datos al HSS relacionado con el par IMPI/IMPU para su almacenamiento, y crea un nuevo paquete de datos que contiene la información para ser enviado a, y almacenado por, un Servidor de Abonados Domésticos “HSS”. Se envía un comando SAR al HSS, que contiene un AVP del tipo de Asignación de Servidor, que incluye una instrucción para el HSS y el nuevo paquete de datos.

En una realización, ningún paquete de datos previo para el par IMPI/IMPU ha sido enviado al HSS para su almacenamiento, y el mensaje de SIP es una petición de registro. En este caso, el AVP del comando SAR contiene la instrucción “REGISTRO”.

Si un paquete de datos previo para el par IMPI/IMPU ha sido enviado al HSS para su almacenamiento, entonces, el nuevo paquete de datos combina la información relacionada con el par IMPI/IMPU recibida en el mensaje de SIP con la información contenida en el paquete de datos anterior. Esta “combinación” de información puede incluir añadir datos al paquete de datos previo para crear el nuevo paquete de datos, o borrar datos del paquete de datos previo para crear el nuevo paquete. Si el paquete previo almacenado debe ser borrado en su totalidad, el nuevo paquete de datos está vacío, y el AVP del comando SAR contiene la instrucción “BORRADO DE REGISTRO” y el paquete de datos vacío con el fin de dar instrucciones al HSS para que borre el paquete de datos anterior.

Si el mensaje de SIP es una petición de registro para que una dirección adicional sea asociada al par IMPI/IMPU, entonces el AVP del comando SAR contiene la instrucción “BORRADO DE REGISTRO”. Si el mensaje de SIP no está asociado al registro o al borrado del registro, entonces el AVP del comando SAR contiene la instrucción “ALMACENAR”. De ese modo, la información puede ser almacenada en el HSS incluso aunque esto no sea provocado por un proceso de registro o de borrado de registro. Los ejemplos incluyen una petición de suscripción al paquete de evento de registro para el par IMPI/IMPU, o una anulación de tal suscripción.

Si el mensaje de SIP es una petición de borrado de registro, entonces el AVP del comando SAR contiene la instrucción de “BORRADO DE REGISTRO”.

De acuerdo con otro aspecto de la presente invención se proporciona un método para su uso en un IMS. El método comprende la recepción, en una S-CSCF, de un mensaje de SIP que contiene información relacionada con un par IMPI/IMPU. La S-CSCF identifica el tipo de información contenida en el mensaje de SIP, y crea un nuevo paquete de datos, que contiene la información, que va a ser enviado a, y almacenado por, un HSS. Un primer comando SAR se envía desde la S-CSCF al HSS. El comando SAR contiene un AVP de tipo de Asignación de Servidor que incluye una instrucción para el HSS y el nuevo paquete de datos. El HSS identifica si se encuentra o no actualmente almacenado un paquete de datos previo relacionado con el par IMPI/IMPU.

Si no se encuentra actualmente almacenado en el HSS un paquete previo de datos relacionado con el par IMPI/IMPU, el nuevo paquete de datos se almacena en el HSS. En una realización, el mensaje de SIP es una petición de registro, en cuyo caso el AVP del primer comando SAR contiene la instrucción de “REGISTRO”.

Si se encuentra actualmente almacenado en el HSS un paquete previo de datos asociado al par IMPI/IMPU, entonces el mensaje de error es devuelto desde el HSS a la S-CSCF, incluyendo el mensaje de error el paquete de datos previamente almacenado. La S-CSCF crea un paquete adicional de datos que combina la información relacionada con el par IMPI/IMPU recibida en el mensaje de SIP con la información contenida en el paquete anterior de datos. Un segundo comando SAR que contiene un AVP que incluye la instrucción “ALMACENAR” y el paquete adicional de datos, es enviado desde la S-CSCF hasta el HSS y almacenado en el HSS. De nuevo, la “combinación” de información en el paquete adicional de datos puede incluir añadir datos al paquete previo de datos para crear el paquete adicional de datos, o borrar datos del paquete anterior de datos para crear el paquete adicional de datos. Si el paquete previamente almacenado debe ser borrado en su totalidad, el paquete adicional de datos está vacío y el AVP del comando SAR contiene la instrucción “ALMACENAR” y el paquete adicional de datos vacío, con el fin de dar instrucciones al HSS para que borre el paquete previo de datos.

Si el mensaje de SIP es una petición de registro para que se asocie una dirección adicional con el par IMPI/IMPU, entonces el AVP del primer comando SAR contiene la instrucción “RE-REGISTRO”. Si el mensaje de SIP no está asociado al registro, entonces el AVP del primer comando SAR contiene aún la instrucción “RE-REGISTRO”. Los ejemplos incluyen una petición de suscripción al paquete de evento de registro para el par IMPI/IMPU, o una anulación de tal suscripción. Si el mensaje de SIP es una petición de baja de registro, entonces el AVP del primer comando SAR contiene la instrucción “BORRADO DE REGISTRO”.

Puede ocurrir que la S-CSCF sepa que el HSS ha almacenado ya un paquete de datos previo, y elija sobreescribirlo. En este caso, el AVP del primer comando SAR incluye la instrucción “ALMACENAR”, y el nuevo paquete de datos es almacenado por el HSS tanto si el paquete previo de datos relacionado con el par IMPI/IMPU está como si no está almacenado actualmente en el HSS. De manera similar, si el AVP del primer comando SAR incluye la instrucción “ALMACENAR” y el nuevo paquete de datos está vacío, entonces el paquete previo de datos es borrado en el HSS.

De acuerdo con un aspecto adicional de la presente invención se proporciona un método para su uso par parte de una S-CSCF de un IMS. El método comprende recibir un mensaje de SIP que contiene información relacionada con un par IMPI/IMPU, e identificar el tipo de información contenida en el mensaje de SIP. Se crea un paquete de datos, que va a ser enviado a, y almacenado por, un HSS. El paquete de datos incluye la información contenida en el mensaje de SIP y una etiqueta de datos que indica el tipo de datos. Se envía un comando SAR al HSS, conteniendo el comando SAR un AVP de tipo de Asignación de Servidor que incluye una instrucción para el HSS y el paquete de datos.

Si el mensaje de SIP es una petición de registro y ningún paquete previo de datos para el par IMPI/IMPU ha sido enviado al HSS para su almacenamiento, entonces 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 “REGISTRO”. Si el mensaje de SIP es una petición de registro para que una dirección adicional sea asociada al par IMPI/IMPU, entonces la etiqueta de datos indica de nuevo que el paquete de datos contiene información de dirección de contacto, pero el AVP del comando SAR contiene la instrucción “RE-REGISTRO”.

Si el mensaje de SIP no está asociado al registro, entonces el AVP del comando SAR contiene la instrucción RE-REGISTRO”. Un ejemplo incluye una petición de suscripción a un paquete de evento de registro para el par IMPI/IMPU, en cuyo caso 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.

Si un paquete de datos previamente almacenado debe ser borrado del HSS, entonces el AVP del comando SAR contiene la instrucción “BORRADO DE REGISTRO”, y el paquete de datos contiene solamente la etiqueta de datos y el campo de datos vacío, para indicar al HSS que un paquete de datos previamente almacenado identificado mediante la misma etiqueta de datos debe ser borrado. Si el mensaje de SIP es una petición de borrado de registro, entonces la etiqueta de datos indica que el paquete de datos contiene información de dirección de contacto.

La invención proporciona también una S-CSCF y/o un HSS configurados para poner en práctica los métodos que se han descrito en lo que antecede.

Breve descripción de los dibujos

La Figura 1 ilustra esquemáticamente la integración de un Sub-sistema Multimedia de IP en un sistema de comunicaciones móviles de 3G;

La Figura 2 es un diagrama de secuencia ilustrativo de acciones llevadas a cabo durante el registro de un abonado en el IMS cuando un paquete de datos único es controlado por la S-CSCF;

La Figura 3 es un diagrama de secuencia que ilustra una secuencia de eventos que dan como resultado el almacenamiento de datos en el HSS, no provocado por un proceso de registro;

La Figura 4 es un diagrama de secuencia que ilustra cómo se pueden añadir datos a un paquete de datos;

La Figura 5 es un diagrama de secuencia que ilustra la modificación de un paquete de datos que no ha sido provocada por un proceso de registro;

La Figura 6 es un diagrama de secuencia que ilustra la secuencia de acciones involucradas en la borrado de registro de una dirección;

La Figura 7 es un diagrama de secuencia que ilustra cómo se puede borrar un paquete de datos completo; La Figura 8 es un diagrama de secuencia que ilustra el borrado de un paquete de datos que no ha sido provocado por un proceso de borrado de registro;

La Figura 9 es un diagrama de secuencia que ilustra una secuencia de acciones llevadas a cabo durante el registro de un abonado en el IMS cuando un paquete de datos único está controlado por el HSS;

La Figura 10 es un diagrama de secuencia que ilustra la adición de datos a un paquete de datos;

La Figura 11 es un diagrama de secuencia que ilustra el borrado de datos de un paquete de datos;

La Figura 12 es un diagrama de secuencia que ilustra una secuencia de acciones llevadas a cabo durante el registro de un abonado en el IMS cuando se generan paquetes de datos separados mediante la S-CSCF;

La Figura 13 es un diagrama de secuencia que ilustra la adición de datos a la información almacenada en el HSS; y

La Figura 14 es un diagrama de secuencia que ilustra el borrado de datos a partir de de la información almacenada en el HSS.

Descripción detallada

Se describen tres mecanismos que permiten el almacenamiento de información de S-CSCF tal como direcciones de contacto e información de paquete de evento de registro en el HSS. A los efectos de la discusión que antecede, no es importante que el HSS entienda o no los datos. Además, los datos pueden estar en cualquier formato adecuado. A los efectos de la presente exposición, se puede considerar que los datos están empaquetados en una o más “burbujas” o paquetes de datos. Los tres mecanismos proporcionan planteamientos para el manejo de estos paquetes, y son como sigue:

1.: Paquete único de datos controlado por la S-CSCF

2.: Paquete único de datos controlado por el HSS

3.: Paquetes de datos separados.

1. Paquete único de datos controlado por la S-CSCF.

El primer planteamiento proporciona un mecanismo en el que toda la información de S-CSCF está almacenada en el HSS como un único paquete de datos ligado a un par de identidad privada/pública IMPI/IMPU. El HSS proporciona el paquete de datos de información a la S-CSCF en un mensaje de Cx durante los procedimientos de registro/borrado del registro. La S-CSCF conoce qué datos necesitan ser añadidos al, o retirados del, paquete de datos. La S-CSCF realiza por lo tanto una única operación de escritura en el HSS para almacenar la información.

Cuando la S-CSCF tiene información para ser almacenada, los datos son empaquetados y enviados al HSS como parte de la información de S-CSCF en un comando Cx-SAR. Si esto es parte de un procedimiento de registro o de borrado de registro, el comando SAR emitido por la S-CSCF contendrá el Par de Valor de Atributo (AVP) de tipo de Asignación de Servidor establecido en el valor ya especificado por el 3GPP (es decir, “REGISTRO”, “RE-REGISTRO”, “BORRADO DE REGISTRO” ...). Sin embargo, el comando Cx-SAR no necesita estar provocado por un proceso de registro, en cuyo caso el AVP contiene el valor “ALMACENAR”. Siempre que el HSS recibe una AVP de S-CSCF info en un comando SAR, se almacena el paquete de datos para el par IMPI/IMPU recibido en el comando SAR.

Esto puede ser entendido con referencia a las Figuras 2 y 3. La Figura 2 ilustra una secuencia de acciones llevadas a cabo durante el registro de un abonado 5 en el IMS. Por motivos de simplicidad, se realizan referencias a un abonado dado a través de la presente descripción en vez de distinguir entre el abonado dado y un equipo de usuario en uso por parte del abonado dado, suponiendo que no se va a producir ninguna malinterpretación por parte de los expertos en la materia con vistas a la lectura de las Especificaciones Técnicas de 3GPP aplicables.

Supóngase que el abonado 5 desea registrar la dirección “Contacto1” para el par de identidad pública/privada IMPI1/IMPU1. En este ejemplo se establece la suposición de que no existe ningún otro contrato para el par ni ninguna información de paquete de evento de registro almacenada en el par. El registro del abonado dado empieza con la sumisión de un mensaje de registro en una etapa S-21 desde el abonado 5 dado hacia una P-CSCF 4 del IMS, a través de una red de acceso no representada por motivos de simplicidad. El mensaje de registro es enviado en una etapa S-22 desde la P-CSCF 4 hacia una I-CSCF 3 encargada de seleccionar una S-CSCF adecuada para dar servicio al abonado dado. El Contacto1 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 no almacena datos de abonado individual e interroga, durante una etapa S-23, un HSS 2 que mantiene datos de abonado para los abonados del IMS.

El HSS 2 responde a esta interrogación en una etapa S-24 con capacidades requeridas por una S-CSCF 1 seleccionable para dar servicio al abonado dado. La suposición de que el procedimiento de registro ilustrado en la Figura 2 es un primer registro y ninguna S-CSCF, ha sido asignada previamente.

Con las capacidades recibidas durante la etapa S-24, la I-CSCF 3 selecciona una S-CSCF 1 (etiquetada en la Figura 2 como S-CSCF1) para atender al abonado dado, y envía el mensaje de registro hacia la S-CSCF1 seleccionada durante una etapa S-25. La S-CSCF1 1 empaqueta la información recibida como “S-CSCF-info”. En este ejemplo, esto corresponde a la cabecera de Contacto (Contacto1, ...). La S-CSCF 1 envía a continuación este paquete de datos hacia el HSS 2 durante una etapa S-26 con un comando Cx-SAR que contiene el AVP “REGISTRO”. El paquete de datos es recibido en el HSS 2, y almacenado en el HSS 2 en la etapa S-27. Con el fin de confirmar al S-CSCF1 1 su asignación en el HSS para dar servicio al abonado dado, el HSS 2 puede cargar en la S-CSCF1 1 durante una etapa S-28 un perfil de servicio para el abonado dado, principalmente un perfil de abonado con todos los datos de abonado necesarios para dar servicio al abonado dado.

La Figura 3 ilustra una secuencia de eventos en la que el almacenamiento de datos en el HSS 2 no está ocasionado por un proceso de registro. En este ejemplo, supóngase que AS 6 desea suscribirse al paquete de evento de registro para la identidad pública IMPU1. El AS 6 envía un mensaje de suscripción a la S-CSCF1 1 en una etapa S-31. La S-CSCF1 1 sabe que esta información debe ser almacenada en el HSS, y sabe que no existe ninguna información previa para la IMPU1. La S-CSCF1 1 empaqueta la información recibida como “S-CSCF info”. En este ejemplo, esto corresponde al paquete de evento de registro.

En la etapa S-32, la S-CSCF1 1 envía el paquete de datos al HSS 2 con un comando Cx-SAR que contiene el AVP “ALMACENAR”, puesto que este proceso no está conectado a ningún procedimiento de registro. El HSS 2 salva el paquete de datos en la etapa S-33, y responde a la S-SCSF1 1 en la etapa S-34 para confirmar que el almacenamiento ha tenido éxito. La S-CSCF1 1 devuelve un mensaje de OK 200 en la etapa S-35 al AS 6 para confirmar la suscripción con éxito al paquete de evento de registro.

Las Figuras 2 y 3 describen mecanismos adecuados para la creación de un paquete de datos que va a ser salvado en un HSS. En algunas circunstancias puede resultar necesario modificar un paquete de datos ya almacenado en el HSS. Este proceso puede ser entendido como que la S-CSCF envía datos al HSS respecto a un par de IMPI/IMPU que tiene datos ya almacenados. Esto puede implicar la adición de datos a un paquete de datos ya existente (es decir, almacenar nuevos datos adicionalmente a los datos ya almacenados). Alternativamente, puede implicar borrar datos de un paquete de datos existente.

La Figura 4 ilustra una secuencia de acciones llevadas a cabo en una situación que requiere la adición de datos a un paquete de datos. En este ejemplo, supóngase que el abonado 5 desea registrar la dirección “Contacto2” para el par IMPI1/IMPU1 de identidad privada/pública. A los efectos de este ejemplo, suponemos que Contacto1 ya ha sido registrado para el par, junto con la información de paquete de evento de registro.

Las tres primeras etapas S41 a S-43 son similares a las etapas S-21 a S-23 mostradas en la Figura 2: el abonado 5 envía un mensaje de registro en una etapa S-41 hacia la P-CSCF 4 del IMS, y este mensaje de registro es enviado en la etapa S-42 hacia la I-CSCF 3. Contacto2 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 interroga al HSS 2 en la etapa S-43.

En la etapa S-44, el HSS 2 responde a esta interrogación con un identificador de la S-CSCF1 1 asignada previamente para dar servicio al abonado 5. La I-CSCF 3 envía a continuación el mensaje de registro hacia la S-CSCF1 1 asignada durante la etapa S-45. La S-CSCF1 1 reconoce que ha existido una modificación de la información que va a ser almacenada en el HSS 2. La S-CSCF1 empaqueta la información adicional (Contacto2 ...) junto con la información previamente almacenada (Contacto1 ...) como un único paquete, etiquetado de nuevo como “S-CSCF-info”. En la etapa S-46 la S-CSCF 1 envía este paquete de datos hacia el HSS 2 con un comando Cx-SAR que contiene el AVP “RE-REGISTRO”. Este paquete de datos es recibido en el HSS 2, y almacenado en el HSS 2 en la etapa S-47. En la etapa S-48, el HSS 2 devuelve a la S-CSCF1 1 un perfil de servicio para el abonado dado, en particular un perfil de abonado con todos los datos de abonado necesarios para atender al abonado dado.

Se apreciará por lo tanto que la adición de nuevos datos a un paquete de datos almacenado en el HSS 2 incluye esencialmente enviar un nuevo paquete de datos, que contiene los antiguos datos junto con los nuevos datos, para sustituir el paquete de datos previamente almacenado.

Al igual que con la creación inicial de un paquete de datos, la modificación de un paquete de datos no necesita estar provocada por un procedimiento de registro. La Figura 5 ilustra una secuencia de acciones en la que la P-CSCF 4 desea suscribirse al paquete de evento de registro después del registro. En este ejemplo, se puede suponer que las direcciones de contacto han sido ya almacenadas como paquete de datos en el HSS 2 durante el proceso de registro como información de paquete de evento de registro.

En la etapa S-51, el UE 5 envía un mensaje de suscripción a la S-CSCF1 1, con el fin de abonarse a la información de paquete de evento de registro. La S-CSCF1 1 añade la información de que se ha hecho la petición de suscripción a los otros datos ya almacenados en el paquete de datos. El nuevo paquete de datos, más grande, es enviado al HSS 2 utilizando el comando Cx-SAR que contiene el AVP “ALMACENAR”.

El borrado de partes del paquete de datos puede ser llevado a cabo de la misma manera que el almacenamiento. La S-CSCF retira la parte del paquete de datos que ha de ser borrada y mantiene el resto, almacenando el nuevo paquete de datos (sin los datos indeseados) en el HSS. El mismo principio puede ser aplicado al borrado del paquete de datos completo en el HSS. La S-CSCF borra un paquete de datos completo en vez de parte del paquete de datos, y envía un AVP de S-CSCF info vacío al HSS en un comando SAR.

La Figura 6 ilustra una secuencia de acciones abarcadas cuando el abonado desea borrar Contacto2 para el par de IMPI1/IMPU1 privada/pública. El proceso es similar al proceso descrito con referencia a la Figura 4: el abonado 5 envía un mensaje de registro en la etapa S-61 hacia la P-CSCF 4 del IMS, y este mensaje de registro es reenviado en la etapa S-62 hacia la I-CSCF 3. Contacto2 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 interroga al HSS 2 en la etapa S-63, y el HSS 2 responde a esta interrogación con un identificador de la S-CSCF1 1 en la etapa S-64. La I-CSCF 3 envía a continuación el mensaje de registro hacia la S-CSCF1 asignada durante la etapa S-65.

La S-CSCF1 1 reconoce que ha existido una modificación de la información que va a ser almacenada en el HSS 2, y genera un nuevo paquete de datos sin Contacto2, pero con toda la demás información previamente conservada. El nuevo paquete es etiquetado de nuevo como “S-CSCF-info” y, en la etapa S-66, es enviado hacia el HSS 2 con un comando Cx-SAR que contiene el AVP “BORRADO DE REGISTRO”. El paquete de datos es recibido en el HSS 2, y almacenado en el HSS 2 en la etapa S-67, sustituyendo al paquete de datos previamente almacenado. En la etapa S-68, el HSS 2 devuelve a la S-CSCF1 1 un perfil de servicio para el abonado dado, especialmente un perfil de abonado con todos los datos de abonado necesarios para dar servicio al abonado dado.

La Figura 7 ilustra una secuencia de acciones involucradas en el borrado de un paquete de datos completo. Supóngase que el abonado 5 desea borrar Contacto1 para el par de IMPI1/IMPU1, y no existe ninguna otra información restante para este par de IMPI1/IMPU1. El proceso es similar al descrito con referencia a la Figura 6: el abonado 5 envía un mensaje de registro en la etapa S-67 hacia la P-CSCF 4 del IMS, y este mensaje de registro es reenviado en la etapa S-67 hacia la I-CSCF 3. Contacto1 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 interroga al HSS 2 en la etapa S-73, y el HSS 2 responde a esta interrogación con un identificador de la S-CSCF1 1 en la etapa S-74. La I-CSCF 3 reenvía a continuación el mensaje de registro hacia la S-CSCF1 1 asignada durante la etapa 7-65.

La S-CSCF1 1 sabe que Contacto1 debe ser retirado del paquete de datos, pero también reconoce que no existen ningunos otros datos ligados al par de IMPI1/IMPU1 que va a ser almacenado en el HSS 2. La S-CSCF1 1 genera por lo tanto un nuevo paquete de datos que es etiquetado como “S-CSCF-info” pero que está vacío. En la etapa S-76 el paquete de datos es enviado hacia el HSS 2 con un comando Cx-SAR que contiene el AVP de “BORRADO DE REGISTRO”. Cuando el HSS 2 recibe el paquete de datos vacío, el paquete de datos almacenado es borrado. En la etapa S-78, el HSS 2 devuelve a la S-CSCF1 1 un perfil de servicio para el abonado dado junto con una actualización sobre el estado de usuario (ahora borrado).

El borrado de un paquete de datos no necesita estar ocasionado por un proceso de borrado de registro. La Figura 8 ilustra una secuencia de acciones involucradas en tal borrado. Supóngase que la P-CSCF 4 desea desabonarse del paquete de evento de registro.

En la etapa S-81, el UE 5 envía un mensaje de suscripción a la S-CSCF1 1, con el fin de desabonarse de la información de paquete de evento de registro. La S-CSCF1 1 reconoce que el paquete de datos debe ser borrado, y en la etapa S-82 se envía un paquete de datos vacío al HSS 2. El HSS 2 borra el paquete de datos como respuesta. El paquete de datos vacío es enviado al HSS 2 usando el comando Cx-SAR que contiene el AVP de “ALMACENAR”.

En cada una de las situaciones descritas en lo que antecede, la S-CSCF debe saber por adelantado el tipo de datos (por ejemplo, direcciones de contacto, suscripción de paquete de evento de registro) que el paquete de datos debe contener. Una manera de conseguir esto consiste en un parámetro de configuración de la S-CSCF para definir qué datos deben ser salvados en un paquete de datos, y en qué circunstancias. De esta forma, la S-CSCF sabrá siempre qué datos, cuando sean actualizados en la red, ocasionarán el envío de un Cx-SAR al HSS. También sabrá qué datos deben ser añadidos al, o borrados del, paquete de datos y qué datos deben ser mantenidos en el paquete de datos.

Se apreciará que se pueden presentar problemas de competencia debidos a dos S-CSCFs diferentes que intenten modificar los datos al mismo tiempo, puesto que solamente se asignará una S-CSCF al par de IMPU/IMPI (según requiere el 3GPP).

2. Paquete único de datos controlado por el HSS

Al igual que en el planteamiento descrito en lo que antecede, el segundo planteamiento proporciona un mecanismo en el que toda la información de S-CSCF se almacena en el HSS como un único paquete de datos ligado a un par de IMPI/IMPU. El HSS proporciona de nuevo el paquete de datos de información a la S-CSCF en un mensaje de Cx durante los procedimientos de registro/borrado de registro. Sin embargo, esta vez la S-CSCF no mantiene ninguna pista sobre qué información es almacenada en el HSS. Cuando la S-CSCF está próxima a enviar un paquete de datos al HSS para su almacenamiento, se hace por tanto necesario recuperar datos desde el primer HSS. Estos datos pueden ser ejecutados en el mismo mediante la adición o la retirada de información en caso necesario, y un nuevo paquete de datos puede ser cargado entonces de nuevo en el HSS.

Al igual que en el planteamiento descrito anteriormente, el proceso puede ser entendido como que la S-CSCF almacena datos en el HSS para un par de IMPI/IMPU que no tiene ningún dato previamente almacenado. Como anteriormente, cuando la S-CSCF tiene información para ser almacenada, los datos son empaquetados y enviados al HSS como parte de la información de S-CSCF en un comando Cx-SAR. Como antes, esto ocurrirá habitualmente durante un proceso de registro inicial, pero puede ocurrir en cualquier momento, sin ninguna dependencia del estado del registro de usuario. Si es parte de un procedimiento de registro o de borrado de registro, el comando SAR emitido por la S-CSCF contendrá el tipo de Asignación de Servidor (AVP) establecido en el valor ya especificado por el 3 GPP (es decir, “REGISTRO”, “RE-REGISTRO”, “BORRADO DE REGISTRO”, ...). Si el comando Cx-SAR no está ocasionado por un proceso de registro, el AVP contiene el valor de “ALMACENAR”. Siempre que el HSS recibe un AVP de S-CSCF info en un comando SAR, se almacena el paquete de datos para el par de IMPI/IMPU recibido en el comando SAR.

La Figura 9 ilustra una secuencia de acciones llevadas a cabo durante el registro de un abonado 5 en el IMS. Supóngase que el abonado 5 desea registrar la dirección “Contacto1” para el par de identidad privada/pública IMPI1/IMPU1. Desde el punto de vista del abonado, esto es similar a las acciones emprendidas en la Figura 2. En este ejemplo, se realiza la suposición de que no existe ningún otro contacto para el par y ninguna otra información de paquete de evento de registro almacenada para el par. Al igual que en la Figura 2, se envía un mensaje de registro en la etapa S-91 desde el abonado 5 hacia la P-CSCF 4. El mensaje de registro es reenviado en la etapa S92 hacia la I-CSCF 3 encargada de seleccionar una S-CSCF adecuada para dar servicio al abonado dado. El Contacto1 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 interroga, durante la etapa S-93, a un HSS 2 que mantiene datos de abonado para abonados del IMS.

El HSS 2 responde a esta interrogación en una etapa S-94 con capacidades requeridas por una S-CSCF 1 seleccionable para dar servicio al abonado dado. Al igual que en la Figura 2, la suposición consiste en que el procedimiento de registro es un primer registro y ninguna S-CSCF ha sido previamente asignada. La I-CSCF 3 selecciona S-CSCF1 1 para dar servicio al abonado dado, y reenvía el mensaje de registro hacia la S-CSCF1 1 seleccionada durante la etapa S-95.

Como antes, la S-CSCF1 1 empaqueta la información recibida (la cual corresponde a la cabecera de Contacto (Contacto1, ...)) como “S-CSCF-info” y envía este paquete de datos hacia el HSS 2 durante la etapa S-96 con un comando Cx-SAR que contiene el AVP de “REGISTRO”. El paquete de datos es recibido en el HSS 2, el cual comprueba si los datos están ya almacenados para el par de IMPI1/IMPU1. En este ejemplo, ningún dato ha sido previamente almacenado, de modo que el paquete de datos S-CSCF-info se almacena en el HSS 2 en la etapa S

97. Con el fin de confirmar de nuevo a la S-CSCF1 1 su asignación en el HSS para dar servicio al abonado dado, el HSS 2 carga en la S-CSCF1 1 durante la etapa S-98 un perfil de servicio para el abonado dado. El retorno del perfil de servicio confirma a la S-CSCF que los datos han sido almacenados con éxito.

Según se ha expuesto previamente, en algunas circunstancias puede ser necesario modificar un paquete de datos ya almacenado en el HSS. Este proceso puede ser entendido como que la S-CSCF envía datos al HSS para un par de IMPI/IMPU que tiene datos ya almacenados. Esto puede implicar añadir datos a un paquete de datos existente o borrar datos a partir de un paquete de datos existente.

La Figura 10 ilustra una secuencia de acciones llevadas a cabo en una situación que requiere la adición de datos a un paquete de datos. Al igual que en el ejemplo de la Figura 4, supóngase que el abonado 5 desea registrar la dirección “Contacto2” para el par de identidad pública/privada IMPI1/IMPU1. A los efectos de este ejemplo, suponemos que Contacto1 está ya registrado para el par, junto con la información de paquete de evento de registro.

Las primeras cinco etapas S-101 a S-105 son similares las etapas S-41 a S-45 mostradas en la Figura 4: el abonado 5 envía un mensaje de registro en una etapa S-101 hacia la P-CSCF 4, y este mensaje de registro es reenviado en una etapa S-102 hacia la I-CSCF 3. Contacto2 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 interroga al HSS 2 en la etapa S-103. En la etapa S-104, el HSS 2 responde a esta interrogación con un identificador de la S-CSCF1 1 previamente asignada para dar servicio al abonado 5. La I-CSCF 3 reenvía a continuación el mensaje de registro hacia la S-CSCF1 1 asignada durante la etapa S-105.

La S-CSCF1 1 no reconoce que ha habido una modificación de la información que va a ser almacenada en el HSS 2, y empaqueta la información que va a ser almacenada (Contacto2 ...) en un paquete etiquetado como “S-CSCF-info”. En la etapa S-106, la S-CSCF 1 envía este paquete de datos hacia el HSS 2 con un comando Cx-SAR que contiene el AVP de “RE-REGISTRO”. El paquete de datos es recibido en el HSS 2, el cual comprueba si los datos han sido ya almacenados para el par de IMPI1/IMPU1. Esta vez, un paquete de datos etiquetado como “S-CSCF-info” (que contiene Contacto1, etc.) está ya almacenado en el HSS 2, de modo que en la etapa S-107 se devuelve un código de error a la S-CSCF1 1 que indica que el paquete de datos ya existe. El propio paquete de datos almacenado está también incluido en este mensaje de error.

Tras la recepción del mensaje de error, la S-CSCF1 1 descodifica el paquete de datos de retorno, y añade al mismo los nuevos datos (Contacto2 ...) para crear un nuevo paquete de datos, etiquetado de nuevo como “S-CSCF-info”. En otras palabras, el nuevo paquete de datos incluye los datos previamente almacenados en el HSS 2, junto con la nueva información recibida por la S-CSCF1 1 en la etapa 105. En este ejemplo, Contacto2 es añadido a Contacto1 existente y a la información de paquete de evento de registro.

El nuevo paquete de datos es enviado a continuación de nuevo al HSS 2 en la etapa S-108, pero esta vez es enviado con un comando Cx-SAR que contiene el AVP de “ALMACENAR”. Cuando el HSS recibe el comando SAR con una indicación de “ALMACENAR”, éste sobre-escribe el paquete de datos previamente almacenado para ese par de IMPI1/IMPU1. El HSS 2 salva de nuevo paquete de datos en la etapa S-109 y devuelve un mensaje de éxito S-110.

Se puede utilizar un proceso similar para borrar parte de, o todo, un paquete de datos. La Figura 11 ilustra una secuencia de acciones llevadas a cabo en una situación que requiere el borrado de datos a partir de un paquete de datos. Supóngase que el abonado 5 desea el borrado en el registro de la dirección “Contacto2” para el par de identidad privada/pública IMPI1/IMPU1.

Las primeras cinco etapas S-111 a S-115 son similares a las etapas S-61 a S-65 mostradas en la Figura 6: el abonado 5 envía un mensaje de registro en una etapa S-111 hacia la P-CSCF 4, y este mensaje de registro es reenviado en la etapa S-112 hacia la I-CSCF 3. Contacto2 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 interroga al HSS 2 en la etapa S-113. En la etapa S-114, el HSS 2 responde a esta interrogación con un identificador de la S-CSCF1 1 previamente asignada para dar servicio al abonado 5. La I-CSCF 3 envía a continuación el mensaje de registro hacia la S-CSCF1 1 asignada durante la etapa S-115.

Puesto que se ha dado instrucciones a la S-CSCF1 1 para que sea borrado el registro Contacto2, ésta no crea un paquete de datos para su envío al HSS 2. En su lugar, en la etapa S-116, un comando Cx-SAR que contiene el AVP de “BORRADO DE REGISTRO” es enviado hacia el HSS 2 que contiene un campo vacío etiquetado como “S-CSCF info. El HSS 2 identifica el hecho de que un paquete de datos etiquetado como “S-CSCF-info” está almacenado en el HSS 2 para el par de IMPI1/IMPU1, y devuelve un código de error a la S-CSCF1 1 en la etapa S-117, indicando la existencia del paquete de datos que ya existe. El propio paquete de datos almacenado es incluido también en este mensaje de error.

Tras la recepción del mensaje de error, la S-CSCF1 1 descodifica el paquete de datos devuelto, y retira del mismo los datos del registro retirado (Contacto2 ...) para crear un nuevo paquete de datos, etiquetado de nuevo como “S-CSCF info”. El nuevo paquete de datos es enviado a continuación al HSS 2 en la etapa S-118 con un comando Cx-SAR que contiene el AVP de “ALMACENAR”. El HSS 2 salva el nuevo paquete de datos en la etapa S-109 y devuelve un mensaje de éxito S-110.

Se apreciará que, una vez que la S-CSCF ha retirado datos de un paquete de datos devuelto por el HSS, el nuevo paquete de datos podría estar vacío. Por ejemplo, considérese la situación análoga a la mostrada en la Figura 7, en la que el abonado 5 desea borrar Contacto1 para el par de IMPI1/IMPU1, y no existe ninguna otra información restante para este par de IMPI1/IMPU1. En este caso, una vez que la S-CSCF ha retirado los datos de Contacto1 del paquete de datos devuelto por el HSS, el paquete de datos está vacío y debe ser borrado por el HSS. En este caso, la S-CSCF envía un comando Cx-SAR al HSS que contiene el AVP de “ALMACENAR” y un campo vacío etiquetado como “S-CSCF info”. El HSS borra a continuación el paquete de datos completo.

Si la S-CSCF conoce inicialmente que el paquete completo de datos debe ser borrado (por ejemplo, si se está borrando un IMPI completo), entonces simplemente envía un comando Cx-SAR al HSS que contiene el AVP de “ALMACENAR” y un campo vacío etiquetado como “S-CSCF info”. El HSS borra a continuación el paquete de datos completo.

Ambos planteamientos descritos en lo que antecede tienen la ventaja de que el HSS no necesita conocer la naturaleza de los datos que van a ser almacenados. El HSS simplemente almacena el paquete de datos completo recibido desde la S-CSCF. El segundo planteamiento (que se acaba de describir) requiere dos comandos SAR hacia el HSS cuando los paquetes de datos han de ser modificados, en vez de simplemente creados o borrados.

3. Paquetes de datos separados

El segundo planteamiento proporciona un mecanismo en el que la información de S-CSCF es almacenada en el HSS en forma de un número de paquetes de datos etiquetados (es decir, direccionables por separado) ligados a un par de IMPI/IMPU. El HSS proporciona paquetes de datos a la S-CSCF en mensajes de Cx. La S-CSCF direcciona, gestiona y manipula la información almacenada en cada uno de los paquetes separados por medio de diferentes etiquetas.

Un formato adecuado para la información es:

<S–CSCF-info>

<paquete de datos empaquetados = datos que van a ser almacenados> donde “tipo de datos” indica los datos que van a ser almacenados o borrados, por ejemplo “Contacto_info” o “RegEvento-Paquete_Info”. Id de Referencia es un número entero que indica datos de direccionamiento dentro del paquete de datos.

Considérese una situación en la que un abonado se registra en primer lugar en el IMS. En esta situación será necesario crear un paquete de datos por primera vez. La Figura 12 ilustra una secuencia de acciones llevadas a cabo durante el registro de un abonado 5 en el IMS. Supóngase que el abonado 5 desea registrar la dirección “Contacto1” para el par de identidad privada/pública IMPI1/IMPU1. Desde el punto de vista del abonado, esto es similar a las acciones emprendidas en las Figuras 2 y 9. En este ejemplo se hace una suposición de que no existe ningún otro contacto para el par ni ninguna información de paquete de evento de registro almacenada respecto al par. Un mensaje de registro es enviado en la etapa S-121 desde el abonado 5 hacia la P-CSCF 4. El mensaje de registro es reenviado en la etapa S-122 hacia la I-CSCF 3 encargada de seleccionar una S-CSCF adecuada para dar servicio al abonado dado. Contacto1 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 interroga, durante la etapa S-123, un HSS 2 que conserva datos de abonado para los abonados del IMS.

El HSS 2 responde a esta interrogación en una etapa S-124 con capacidades requeridas por una S-CSCF 1 seleccionable para dar servicio al abonado dado. Como anteriormente, la suposición consiste en que el procedimiento de registro es un primer registro y ninguna S-CSCF ha sido previamente asignada. La I-CSCF 3 selecciona la S-CSCF1 1 para dar servicio al abonado dado, y reenvía el mensaje de registro hacia la S-CSCF1 1 seleccionada durante la etapa S-125. Los datos enviados hacia el HSS son etiquetados en un comando Cx-SAR con un AVP de “REGISTRO” (como antes) junto con “S-CSCF info”, donde “S-CSCF-info” contiene además el paquete de datos empaquetados <tipo de datos: Contacto_info>.

Ningún otro dato ha sido previamente almacenado en el HSS 2 para el par de IMPI1/IMPU1. El HSS 2 almacena por lo tanto la información de contacto ligada al par de IMPI1/IMPU1, dentro de la etiqueta “Contacto_info”, en la etapa S

127. Un mensaje de éxito es devuelto a la C-CSCF1 1 en la etapa S-128.

La adición a un paquete de datos existente utilizando este planteamiento es directa y puede ser entendida con referencia a la Figura 13. Por ejemplo, supóngase que la P-CSCF 4 desea suscribirse al paquete de evento de registro. Las etapas 132-135 proporcionan la información necesaria a la S-CSCF1 1. La S-CSCF necesita añadir estos datos a los datos ya almacenados en el HSS 2 y, en la etapa S-136, envía al HSS 2 un comando Cx-SAR con un AVP de “RE-REGISTRO” junto con “S-CSCF info”, donde “S-CSCF-info” contiene además el paquete de datos empaquetados <tipo de datos: Reg-Evento-Paquete>.

El HSS 2 determina que se trata de una nueva referencia para un par de IMPI/IMPU previamente registrado. HSS almacena solo la nueva información como paquete de datos separado con una nueva etiqueta.

El borrado de datos de la información del paquete de datos almacenado es también simple: la S-CSCF envía un comando SAR al HSS, conteniendo la etiqueta para los datos que deben ser borrados con un valor vacío. Esto puede ser entendido con referencia a la Figura 14, la cual ilustra una secuencia de acciones requeridas si un abonado 5 desea borrar el registro Contacto2 para el par público/privado IMPI1/IMPU1. Al igual que en la Figura 6, el abonado 5 envía un mensaje de registro en la etapa S-141 hacia la P-CSCF 4 del IMS, y este mensaje de registro es reenviado en la etapa S-142 hacia la I-CSCF 3. Contacto2 viaja como parte de la cabecera de Contactos de SIP. La I-CSCF 3 interroga el HSS 2 en la etapa S-143, y el HSS 2 responde a esta interrogación con un identificador de la S-CSCF1 1 en la etapa S-144. La I-CSCF 3 reenvía a continuación el mensaje de registro hacia la S-CSCF1 1 asignada durante la etapa S-145.

La S-CSCF envía al HSS 2 un comando Cx-SAR con un AVP de “BORRADO DE REGISTRO” junto con “S-CSCF info”, donde “S-CSCF-info” contiene además un paquete de datos vacío <tipo de datos: Contacto_info>. La S-CSCF reconoce que el paquete de datos para Contacto2 debe ser borrado, y en la etapa S-147 borra el paquete de datos relevante. Se devuelve un mensaje que confirma el éxito en la etapa S-148.

Si se borran todos los paquetes de datos almacenados por el HSS, cuando el HSS determine que se ha borrado la última etiqueta para un par de IMPI/IMPU el usuario es borrado del registro. Se apreciará que durante el borrado del registro de los contactos, por ejemplo, la información de paquete de evento de registro debe ser mantenida hasta que el contacto sea borrado y/o dado de baja del registro.

El tercer planteamiento es simple tanto para la dirección de contacto como para la información de paquete de evento de registro. Solamente se requiere un comando SAR para almacenar la información, y la S-CSCF no necesita descodificar ninguna información recibida en el comando SAR. Sin embargo, se necesitarán etiquetas de paquete de datos estandarizadas.

Se apreciará que la operación de uno o más de los componentes descritos en lo que antecede puede ser controlada mediante un programa que opere en el dispositivo o aparato. Tal programa operativo puede estar almacenado en un medio legible con ordenador, o podría, por ejemplo, ser materializado en una señal tal como una señal de datos descargables desde un sitio web de Internet. Las reivindicaciones anexas deben ser interpretadas como que cubren en sí mismas un programa operativo, o como un registro sobre una portadora, o como una señal, o de cualquier otra forma.

También se apreciará que se pueden realizar diversas modificaciones en las realizaciones descritas anteriormente sin apartarse del alcance de la presente invención según se define mediante las reivindicaciones anexas. En particular, se apreciará que, aunque se ha descrito en relación con un Sistema Universal de Telecomunicaciones Móviles que tiene un Sub-sistema Multimedia de IP, la presente invención es también aplicable a otros tipos de red.

Claims

REIVINDICACIONES

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

10 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”.

15 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”.