ES2371961T3

ES2371961T3 - Agrupamiento de identidades de usuario en un subsistema multimedia ip.

Info

Publication number: ES2371961T3
Application number: ES07821925T
Authority: ES
Inventors: Germán BLANCO BLANCO; Jesús-Javier ARAUZ-ROSADO
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2007-10-26
Filing date: 2007-10-26
Publication date: 2012-01-12
Anticipated expiration: 2027-10-26
Also published as: EP2215796B1; US20100232422A1; CN101836415B; ATE523024T1; WO2009052870A1; US8582563B2; EP2215796A1; CN101836415A

Abstract

Un Home Subscriber Server "HSS - Servidor de Abonado Local", (81) que soporta datos de abonado de usuarios de un IP Multimedia Subsystem "IMS -Subsistema multimedia IP" (8), teniendo el HSS una estructura de datos por abonado que incluye una pluralidad de Identidades de Usuario Públicas de IMS (2a-2g), estando cada IMS Public User Identity "IMPU - Identidad de Usuario Pública de IMS" asociada con al menos una IMS Private User Identity "IMPI - Identidad de Usuario Privada de IMS" (3a-3b), donde un número n de IMPUs están distribuidas en un número m de Conjuntos de Registro implícitos (71, 72, 73, 74), y donde todas las IMPUs de cada Implicit Registration Set "IRS - Conjunto de Registro Implícito" comparten el mismo estado de registro (51, 52, 53, 54), estando el HSS caracterizado porque cada IRS está asociado con una condición de acceso (41, 42, 43, 44), una IMPU (2a) dada es compartida por más de un IRS (71, 72), y el estado explícito de la citada IMPU (2a) dada bajo una condición de acceso (42) dada activa el registro implícito de las IMPUs (2a, 2b, 2c, 2f) en el IRS (72) asociado con la citada condición de acceso (42), mientras que el estado del registro (51, 53, 54) de las IMPUs en cualquier otro IRS (71, 73, 74) permanece sin cambios.

Description

Agrupamiento de identidades de usuario en un subsistema multimedia IP

CAMPO TÉCNICO La presente invención se refiere generalmente al registro implícito de identidades de usuario en un Subsistema multimedia IP y, en particular, en el que se aplica en un escenario convergente de telefonía fija - telefonía móvil.

ANTECEDENTES De acuerdo con las especificaciones técnicas de 3GPP, es decir TS 23.228, a cada suscripción de usuario del IP Multimedia Subsystem (en lo que sigue IMS -Subsistema multimedia IP) el operador de red Local le asigna una o más Identidades de Usuario Privadas de IMS. Cada IMS Private User Identity (en lo que sigue IMPI – Identidad de Usuario Privada de IMS) se utiliza para el registro del usuario en el IMS, y puede ser asociada con una o más Identidades de Usuario Públicas de IMS. Cada IMS Public User Identity (en lo que sigue IMPU – Identidad de Usuario Pública de IMS) es utilizada por el usuario para comunicaciones con otros usuarios y puede ser asociada con un único IMS Service Profile (en lo que sigue SP – Perfil de Servicio) de IMS y con una o más IMPIs. A este respecto, cualquier SP puede ser asociado con más de una IMPU, mientras que cada IMPU sólo puede ser asociada con un SP. Siendo SP, en pocas palabras, una colección de datos relativos a servicio y a usuario. Detalles en interfaces relevantes aplicables aparecen en el documento 3GPP TS 29.229.

Actualmente, una pluralidad de IMPUs puede estar incluida en un Implicit Registration Set (en lo que sigue IRS – Conjunto de Registro Implícito) en el que todas las IMPUs comparten un mismo estado de registro y están asociadas con un mismo conjunto de IMPIs. Así, donde un par de IMPI/IMPU está explícitamente registrado o es eliminado del registro, y la IMPU pertenece a un IRS, todas las IMPUs del IRS son simultáneamente consideradas como implícitamente registradas o eliminadas del registro por la red sin requerir un registro o una eliminación del registro para todos ellos. Para el propósito de la presente invención, donde varias IMPUs comparten un único SP y están incluidas en un mismo IRS, las citadas varias IMPUs están consideradas como alias, como se describe en la publicación de patente GB-A-2 425 685.

De acuerdo con la comprensión anterior de un IRS, donde todas las IMPUs comparten un mismo estado de registro y están asociadas con un mismo conjunto de IMPIs, uno infiere que una IMPU sólo puede pertenecer a un IRS. Si no, donde la IMPU está incluida en dos IRSs, todas las IMPUs de los dos IRSs tendrían el mismo estado de registro; de manera que cualquier IMPU de los dos IRSs tendría dos estados de registro diferentes al mismo tiempo, lo cual no es posible.

La estructura de datos de ejemplo ilustrada en la FIG. 1 muestra una suscripción con dos IMPIs, es decir IMPI-1 e IMPI-2, nueve IMPUs, es decir IMPU-1 a IMPU-9 y tres IRSs, es decir IRS-1 a IRS-3, en los cuales algunas de las IMPUs están distribuidas y donde todas las IMPUs de cada IRS están asociadas con la misma al menos una IMPI. En esta estructura de datos de ejemplo, la OMPU-3 está asociada con la IMPI-1 y la IMPI-2, mientras que la IMPU-6 sólo está asociada con la IMPI-2. En esta situación, la IMPU-3 puede ser registrada utilizando cualquiera de la IMPI1 ó la IMPU-2, mientras que la IMPU-6 sólo puede ser registrada utilizando la IMPU-2.

También en esta estructura de datos de ejemplo, el IRS-1 consiste en la IMPU-1 y la IMPU-2, ambas asociadas sólo con la IMPI-1, de manera que el registro implícito bien de la IMPU-1 ó de la IMPU-2 sólo puede ser llevado a cabo con la IMPI-1, y activa el registro implícito bien de la IMPU-2 ó de la IMPU-1 respectivamente. El IRS-2, no obstante, consiste en la IMPU-4 y la IMPU-5, los dos asociados individualmente con la IMPI-1 y con la IMPI-2, de manera que el registro explícito bien de la IMPU-1 ó de la IMPU-2 puede ser llevado a cabo bien con la IMPI-1 ó con la IMPI-2, y activa el registro implícito bien de la IMPU-2 ó de la IMPU-1 respectivamente y para las mismas IMPI-1 ó IMPI-2. El IRS-3, por otra parte, consiste en las IMPU-7, IMPU-8 e IMPU-9, todas ellas asociadas solamente con la IMPI-2, de manera que el registro explícito de las IMPU-7, IMPU-8 ó IMPU-9 sólo puede ser llevado a cabo con la IMPI-2, y activa el registro implícito de las tres IMPUs. En particular, puesto que la IMPU-7 y la IMPU-8 están las dos asociadas con un único SP, es decir SP-E en esta Fig. 1, y dado que tanto la IMPU-7 como la IMPU-8 están incluidas en el mismo IRS, es decir en el IRS-3, tanto la IMPU-7 como la IMPU-8 se dice que son un alias de la otra, y pueden utilizarse indistintamente puesto que el tratamiento hecho por la red es el mismo para las dos.

Una vez que la estructura de datos de ejemplo anterior con las realizaciones convencionales entre las IMPUs, las IMPIs, los IRSs y los SPs ha sido presentada, un razonamiento para introducir el IRS puede merecer la pena. Por un lado, el IMS hace uso del llamado Session Initiation Protocol (en lo que sigue, SIP – Protocolo de Iniciación de Sesión), donde los identificadores de usuario son preferiblemente en forma de una llamada URI de SIP, tal como ‘sip: user@ims.com’. Por otro lado, los usuarios de una red de telefonía fija están generalmente identificados por un número de abonado en forma de una llamada URI de TEL, tal como ‘tel: +987656789’. De acuerdo con la especificación de SIP de IETF, una URI de TEL no puede ser registrada explícitamente. No obstante, los usuarios del IMS podrían también ser alcanzables con una URI de TEL, especialmente en el contexto de llamadas de emergencia. Para solucionar esto, el concepto de IRS fue introducido para permitir que un conjunto de IMPUs en

E07821925 16-11-2011

forma de URI de TEL y de URI de SIP sean implícitamente registradas mediante el registro explícito de una IMPU del citado IRS, la citada IMPU en forma de una URI de SIP. Incluso aunque las URI de SIP y URI de TEL se expresan de manera formal con un prefijo respectivo tal como se indica anteriormente ‘sip: user@ims.com’ y ‘tel: +987656789’ respectivamente, en lo que sigue, y en aras de la simplicidad, se denominan simplemente ‘user@ims.com’ y ‘+987656789’ respectivamente.

Cuando se considera una red fixed-mobile convergent (en lo que sigue FMC - convergente de telefonía fija-telefonía móvil) para acceder al IMS, un usuario puede tener IMPUs de un tipo de URI de SIP, tal como bob@wire-line y bob@wireless, e IMPUs de un tipo de URI de TEL, tal como +1234567890 que identifica a un terminal de telefonía móvil y +9876543210 que identifica a un terminal telefónico fijo. Tal usuario FMC puede tener: un teléfono móvil alcanzable por una MSISDN, y que tiene un SIP User Agent (en lo que sigue SIP UA – Agente de Usuario de SIP); un teléfono fijo alcanzable con un número de usuario E.164; un Personal Computer (en lo que sigue PC – Ordenador Personal) de sobremesa con un UA de SIP basado en software; y probablemente una set-top box (en lo que sigue – STB – Caja para colocar sobre el televisor) de IPTV con un UA de SIP incorporado. Además, son necesarias diferentes URIs de TEL para terminales telefónicos fijos y móviles puesto que las llamadas de otra red de operador típicamente tienen un coste menor cuando se llama a un terminal telefónico fijo que el coste de la misma llamada a un terminal telefónico móvil y así al usuario llamante debería permitírsele elegir entre llamar a un terminal telefónico fijo o a un terminal telefónico móvil.

Así, a este usuario de FMC puede dársele bajo la estructura de datos convencional ilustrada en la Fig. 1 un primer IRS con una primera IMPU +9876543210 del tipo de URI de TEL que identifica al terminal telefónico fijo y una segunda IMPU bob@wireline del tipo de URI de SIP que identifica, por ejemplo, al Personal Computer (en lo que sigue PC – Ordenador Personal) de sobremesa, y probablemente a la STB de IPTV; y un segundo IRS con una primera IMPU +1234567890 del tipo de URI de TEL, es decir una MSISDN, que identifica al terminal de telefonía móvil y una segunda IMPU bob@wireless del tipo de URI de SIP que identifica el UA de SIP en el terminal de telefonía móvil. En operación, donde el UA de SIP en el terminal de telefonía móvil registra la IMPU bob@wireless, la red automáticamente registra la IMPU +1234567890 del tipo de URI de TEL que representa el número de MSISDN del terminal de telefonía móvil. También en operación, donde el UA de SIP bien en el PC de sobremesa o en la STB de IPTV registra la IMPU bob@wireline, la red automáticamente registra la IMPU +9876543210 del tipo de URI de TEL que representa el número de ISDN del terminal de telefonía móvil.

Este usuario FMC puede tener también una IMPU del tipo de URI de SIP que identifica al usuario en el IMS, tal como bob@ims.com, e incluso una IMPU alias del tipo de URI de SIP que identifica también al usuario del IMS, tal como bob@bobdomain. Actualmente, estas dos IMPUs que identifican al usuario en el IMS pueden preferiblemente estar incluidas en un tercer IRS bajo la estructura de datos anterior, y no pueden estar definidas en los dos IRSs explicados anteriormente para los entornos de telefonía fija e inalámbrica puesto que podrían tener un estado de registro diferente para el IRS de telefonía fija o inalámbrica, y hacer entonces un registro sucesivo de la IMPU bob@ims.com.

Por otro lado, dentro del contexto de las llamadas de emergencia a través del IMS, requisitos regulatorios imponen que cada terminal que lleva a cabo una llamada a un emergency response centre (en lo que sigue ERC – Centro de Respuesta a Emergencias) debe ser alcanzable por medio de un número E.164 ordinario. Al mismo tiempo, los cuerpos de estandarización han acordado que donde un usuario no registrado se registra con el objetivo de iniciar una llamada de emergencia, este usuario utiliza una llamada “Emergency Public Identity” (en lo que sigue E-IMPU – Identidad Pública para Emergencias) que es una URI de SIP diferente de cualquier otra IMPU asociada con el usuario. Con estos antecedente, puede inferirse que el número E.164 para llamadas de emergencia, como mandan los requisitos regulatorios, no puede ser el mismo que el MSISDN que identifica al terminal de telefonía móvil o al número de abonado de ISDN que identifica al terminal fijo, puesto que implicaría que el número de abonado de MSISDN o de ISDN debe ser parte de dos IRSs diferentes al mismo tiempo, lo que no es posible hoy en día. Así, con el fin de cumplir los requisitos regulatorios, puede asignarse una URI de TEL adicional con el número E.164 para cada usuario que sólo puede utilizarse para llamadas de emergencia.

Esta aparente primera solución fuerza a la reserva de un identificador adicional, es decir, a una URI de TEL de emergencia, además de la E-IMPU anterior del tipo de URI de SIP para cada abonado. Este identificador sólo puede utilizarse para llamadas de emergencia, pero el operador necesita solicitar un espacio para numeración mucho mayor de la administración, y el inconveniente anterior de sucesivos registros implícitos para usuarios de una red FMC se maximiza, incluso. Además, esta solución implica que el ERC vería un identificador de abonado diferente para devolver la llamada al usuario donde el usuario accede al ERC desde el dominio de IMS en lugar de donde el usuario accede al ERC desde un dominio de telefonía convencional, lo que puede provocar una dificultad adicional en identificar el origen de la llamada de emergencia.

Intentando solucionar esto, una segunda solución está hoy en día bajo discusión en los cuerpos de estandarización de 3GPP, y mediante la cual una URI de TEL utilizable para llamadas de emergencia podría ser compartida por más de un IRS, como se ilustra en la Fig. 2. Esta segunda solución propone un primer IRS con IMPUs utilizables sólo

E07821925 16-11-2011

para llamadas de emergencia y al menos un segundo IRS con IMPUs no utilizables para llamadas de emergencia, compartiendo los dos IRSs la URI de TEL utilizable para llamadas de emergencia. En operación, donde el usuario registra explícitamente una IMPU del tipo de URI de SIP del IRS para llamadas de emergencia, todas las IMPUs del citado IRS que incluyen la URI de TEL están implícitamente registradas para llamadas de emergencia, y este registro no afecta al estado del registro de la URI de TEL y de otras IMPUs en otros IRSs. Puesto que la única IMPU compartida por más de un IRS en esta solución es del tipo de URI de TEL, y dado que una URI de TEL no puede ser registrada explícitamente, esta solución no resuelve el inconveniente anterior de sucesivos registros para usuarios FMC. Además, a la vista de esta solución, al usuario FMC anterior se le puede proporcionar un IRS para llamadas de emergencia que tienen como URI de TEL bien el +1234567890 que representa el número del terminal de telefonía móvil MSISDN, o bien el +9876543210 que representa el número de ISDN del terminal telefónico fijo, mientras que el usuario es registrado en el otro entorno respectivamente. En otras palabras, esta solución no resuelve el problema de compartir IMPUs del tipo de URI de SIP que identifican al usuario en el IMS entre más de un IRS.

COMPENDIO

Es un objeto de la presente invención obviar al menos algunas de las desventajas anteriores y proporcionar un agrupamiento flexible de identidades de usuario en el IMS. Más específicamente, y especialmente aplicable a usuarios FMC, la presente invención se dirige a proporcionar una estructura de datos más flexible en la que cualquier IMPU, incluso las del tipo de URI de SIP, pueda ser compartida por más de un IRS.

El objeto anterior es alcanzado de manera general de acuerdo con la invención proporcionando un Home Subscriber Server (en lo que sigue HSS – Servidor de Abonado Local) que soporta tal estructura de datos flexible por usuario del IMS, un método de llevar a cabo el registro implícito de un IRS compartiendo una IMPU dada con otro IRS, y un servidor de Serving Call Session Control Function (en lo que sigue S-CSCF – Función de Control de Sesión de Llamada de Servicio) que proporciona servicio a abonados del IMS y que coopera con el HSS para determinar el IRS para ser registrado implícitamente.

Así, de acuerdo con un primer aspecto de la presente invención, se proporciona un HSS que soporta datos de abonado de usuarios del IMS, teniendo este HSS una estructura de datos por abonado que incluye una pluralidad de IMPUs, estando cada IMPU asociada con al menos una IMPI, donde un número n de IMPUs es distribuido en un número m de IRSs, y donde todas las IMPUs en cada IRS comparten el mismo estado del registro. En este HSS, cada IRS está asociado con una condición de acceso, una IMPU dada es compartida por más de un IRS, y el registro explícito de la citada IMPU dada bajo una condición de acceso dada activa el registro implícito de las IMPUs del IRS asociadas con la citada condición de acceso, mientras que el estado del registro de las IMPUs en cualquier otro IRS asociado con una condición de acceso diferente permanece sin cambios. Además, un registro explícito en este HSS de una IMPU, que pertenece sólo a un IRS, activa también un registro implícito de las IMPUs del citado IRS para la condición de acceso asociada.

De manera general, y siendo aplicable al HSS así como a la S-CSCF y al método, la condición de acceso puede ser seleccionada de un grupo de condiciones de acceso que incluye: un acceso por telefonía móvil solamente, un acceso por telefonía fija solamente, una llamada de emergencia, una red de itinerancia y combinaciones de los mismos. Más específicamente, una condición de acceso puede ser construida llevando a cabo una operación lógica con una combinación de condiciones individuales tales como una selección de O entre varias redes de acceso fijo más un Y con una condición de llamada de emergencia.

Con el fin de impedir la eliminación parcial del registro de las IMPUs en un IRS, cualquier registro implícito de IMPUs del IRS es grabado en el HSS. A continuación, una eliminación del registro de una IMPU en un IRS, cuyo registro implícito fue grabado, activa la eliminación del registro de esas IMPUs del citado IRS.

Por lo que respecta a la implementación, este HSS puede comprender un almacén para almacenar la estructura de datos por abonado; un receptor para recibir el registro explícito de la IMPU dada bajo la condición de acceso dada; y un procesador para activar el registro implícito de IMPUs del IRS asociado con la citada condición de acceso. Este HSS puede comprender también un emisor para enviar las IMPUs del IRS como resultado del registro explícito de la IMPU dada.

En particular, el almacén de este HSS puede comprender un gestor de memoria para enviar y extraer datos de una base de datos externa, o puede incluir directamente una base de datos interna con este propósito.

A la vista de las ventajas anteriores, el procesador de este HSS puede disponerse para grabar en el almacén el registro implícito de las IMPUs en cualquier IRS con el fin de impedir una eliminación parcial del registro de las IMPUs del citado IRS. Además, el receptor de este HSS puede estar dispuesto para recibir una eliminación del registro de una IMPU en un IRS, cuyo registro implícito fue grabado en el almacén, y el procesador puede estar dispuesto para activar la eliminación del registro de esas IMPUs del citado IRS. Además, el receptor de este HSS puede también estar dispuesto para recibir una condición de acceso dada junto con una eliminación del registro de

E07821925 16-11-2011

una IMPU, y el procesador puede también estar dispuesto para utilizar la condición de acceso dada para determinar una eliminación del registro de esas IMPUs en un IRS con la citada condición de acceso.

De acuerdo con un segundo aspecto de la presente invención, se proporciona un método de llevar a cabo un registro implícito de un IRS entre una pluralidad de IRSs en un HSS, donde cada IRS comprende más de una IMPU y las IMPUs en cada IRS comparten un mismo estado de registro. Este método comprende una etapa de distribuir un número n de IMPUs en un número m de IRSs; una etapa de compartir una IMPU dada por más de un IRS; una etapa de asociar cada IRS con una condición de acceso; una etapa de llevar a cabo un registro explícito de la IMPU dada bajo una condición de acceso dada; y una etapa de activar un registro implícito en el HSS de las IMPUs de un IRS asociado con la citada condición de acceso dada, mientras que el estado del registro de IMPUs en cualquier otro IRS asociado con una condición de acceso diferente permanece sin cambios. Además, este método puede comprender también una etapa de llevar a cabo un registro explícito de una segunda IMPU, que pertenece sólo a un IRS, y una etapa responsable de activar un registro implícito de las IMPUs del citado IRS para la condición de acceso asociada.

Alineado con características ventajosas proporcionadas en el HSS, este método puede comprender también una etapa de grabar el registro implícito de IMPUs en cualquier IRS, con el fin de impedir una eliminación parcial del registro de IMPUs del citado IRS. Además, este método puede comprender también una etapa de eliminar del registro aquellas IMPUs de un IRS cuyo registro implícito fue grabado, durante la eliminación del registro de una IMPU del citado IRS. Además, este método puede comprender también una etapa de recibir una condición de acceso dada junto con una eliminación del registro de una IMPU, y una etapa de utilizar la condición de acceso dada para determinar una eliminación del registro de las IMPUs de un IRS asociadas con la citada condición de acceso.

De acuerdo con un tercer aspecto de la presente invención, se proporciona una S-CSCF que proporciona servicio a abonados del IMS. Esta S-CSCF incluye un receptor para recibir un registro explícito de una IMPU de un abonado dado, y un emisor para enviar el registro explícito de la citada IMPU hacia un HSS que soporta datos de abonado para usuarios del IMS. En esta S-CSCF, el emisor está dispuesto para enviar una condición de acceso dada para la cual aplica el registro explícito. Además, el emisor también puede estar dispuesto para enviar hacia el HSS, junto con una eliminación del registro de un IMPU, una condición de acceso dada para la cual aplica la eliminación del registro.

La invención puede ser llevada a la práctica mediante uno o más programas de ordenador, cargables en una memoria interna de un número de ordenadores, cada uno con unidades de entrada y de salida así como con una unidad de tratamiento, comprendiendo el programa de ordenador un código ejecutable adaptado para llevar a cabo etapas del método de acuerdo con cualquiera de las reivindicaciones 14 a 20 cuando se ejecutan en el ordenador. El código ejecutable del uno o más programas de ordenador puede ser grabado en un portador legible en un ordenador.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Las características, objetos y ventajas de la invención resultarán evidentes leyendo esta descripción junto con los dibujos que se acompañan, en los cuales:

La FIG. 1 representa una distribución de ejemplo de IMPUs de IRSs de acuerdo con datos de abonado convencionales para IMS, por lo que ninguna IMPU puede ser compartida por más de un IRS. La FIG. 2 representa otra distribución de ejemplo de IMPUs de IRSs, de acuerdo con explicaciones actualmente soportadas en foros de estandarización, por lo que sólo una IMPU del tipo de una URI de TEL puede ser compartida por más de un IRS, mientras que ninguna IMPU que puede estar explícitamente registrada puede ser compartida por más de un IRS. La FIG. 3 ilustra una red Convergente de Telefonía Fija-Telefonía Móvil de ejemplo, en la que a un usuario se le dan varias IMPUs utilizables en un entorno de telefonía fija o con cable, varias IMPUs utilizables en un entorno de telefonía móvil o inalámbrica, y varias IMPUs utilizables para acceder al IMS a través del entorno de telefonía fija o móvil. La FIG. 4 ilustra una estructura de datos de ejemplo mediante la cual cualquier IMPU puede ser compartida por más de un IRS, y cada IRS está asociado con una condición de acceso cuyo cumplimiento durante el registro explícito de una IMPU del IRS activa un registro implícito de las IMPUs del citado IRS. La FIG. 5 ilustra una realización de ejemplo de la estructura de datos aplicable a llamadas de emergencia, y en la que se requiere que una IMPU de emergencia especial sea compartida por más de un IRS y sea utilizada para registro explícito. La FIG. 6 ilustra una realización de ejemplo de un método para llamadas de emergencia en el que aplica la estructura de datos de ejemplo ilustrada en la Fig. 5. La FIG. 7 ilustra una realización de ejemplo de un método para registro implícito de dos IRSs diferentes, cada uno asociado con una condición de acceso particular como se ilustra en la Fig. 4, mediante un usuario que registra una IMPU compartida por los dos IRSs bajo respectivas condiciones de acceso.

E07821925 16-11-2011

La FIG. 8 ilustra una realización de ejemplo de una posible secuencia de llamadas llevada a cabo desde otro usuario para alcanzar al usuario que ha registrado los dos IRSs diferentes tal como se ilustra en la Fig. 7. La FIG. 9 representa elementos estructurales básicos de un HSS que soporta la estructura de datos y activa los registros implícitos, y una S-CSCF que indica información básica para derivar condiciones de acceso. La FIG. 10 ilustra una realización de ejemplo de posibles secuencias de acciones para no registrar o eliminar explícitamente del registro una IMPU así como para respectivamente no registrar y eliminar del registro los correspondientes IRSs bajo condiciones de acceso respectivas.

DESCRIPCIÓN DETALLADA Lo que sigue describe algunas realizaciones preferidas para un HSS que soporta una estructura de datos flexible por abonado del IMS, un método de llevar a cabo el registro implícito de un IRS que comparte una IMPU dada con otro IRS, y un servidor de S-CSCF que proporciona servicio a abonados del IMS y que proporciona al HSS información básica para derivar condiciones de acceso, cooperando todos ellos para proporcionar una estructura de datos más flexible donde cualquier IMPU, incluso aquéllas del tipo de URI de SIP, puede ser compartida por más de un IRS.

La Fig. 3 ilustra un escenario en el que un usuario de IMS puede acceder al IMS 8 mediante una llamada red Convergente de Telefonía Fija-Telefonía Móvil, como ya se ha comentado anteriormente cuando se explicaban los inconvenientes a los que se dirige la presente invención. Una red Convergente de Telefonía Fija-Telefonía Móvil, es decir una red FMC, puede ser entendida como una red a la cual una usuario 91 puede conectarse con otros usuarios 92 por medio de una red de telefonía fija o por cable 61-62, o por medio de una red de telefonía móvil, celular o inalámbrica 63. Donde el usuario 91 tiene una conexión por cable, el usuario puede conectarse a un PC de sobremesa 9d, una STV de IPTV 9c, y un teléfono convencional 9b, por ejemplo. Por otro lado, donde tal usuario 91 es un usuario FMC, el usuario puede también tener una conexión inalámbrica mediante un terminal de telefonía móvil 9a, donde el usuario podría incluso conectar un PC portátil (no ilustrado en ningún dibujo) para acceder al IMS 8 a través de él.

En este escenario de ejemplo ilustrado en la Fig. 3, al usuario FMC 91 se le proporciona una primera IMPU 2a tal como Bob@ims.com, es decir IMPU-1, para identificar al usuario en el IMS; una segunda IMPU 2b tal como Bob@wireless, es decir IMPU-2, para identificar, por ejemplo, una cuenta de correo electrónico en el PC portátil conectado con el terminal de telefonía móvil 9a; una tercera IMPU 2c del tipo de una URI de TEL tal como +1234567890, es decir IMPU-3, para identificar al terminal de telefonía móvil de MSISDN para servicios de telefonía fija y móvil; una cuarta IMPU 2d tal como Bob@wireline, es decir IMPU-4, para identificar, por ejemplo, cualquier aplicación de usuario en el PC de sobremesa 9d o en la STB de IPTV 9c, ambos conectados con la red de telefonía fija; una quinta IMPU 2e del tipo de una URI de TEL tal como +9876543210, es decir IMPU-5, para identificar el número de ISDN del terminal de telefonía fija para servicios de telefonía fijos o móviles; y una sexta IMPU 2f tal como Bob@bob-domain, es decir IMPU-6, para identificar un alias del usuario en el IMS, por ejemplo, una identidad relacionada con una posición de trabajo o con actividades privadas.

Donde la presente invención resuelve el problema de que una IMPU de un usuario dado sea compartida entre más de un IRS, por ejemplo, siendo la IMPU-1 compartida por un primer IRS con IMPUs en el entorno local y un segundo IRS con IMPUs en el entorno de la telefonía móvil, una estructura de datos de ejemplo tal como la ilustrada en la Fig. 4 puede ser proporcionada por el usuario dado.

La estructura de datos ilustrada en la Fig. 4 incluye un primer IRS 71, es decir IRS-1, para ser registrado implícitamente en el que el usuario accede al IMS 8 a través del entorno local mostrado en la Fig. 3, es decir, a través de una primera red de acceso 61 ó a través de una segunda red de acceso 62; y un segundo IRS 72, es decir IRS-2, para ser registrado implícitamente en el que el usuario accede al IMS 8 a través del entorno de telefonía móvil mostrado en la Fig. 3, es decir, a través de una tercera red de acceso 63. En aras de la simplicidad con respecto a la presente invención, todas la IMPUs tanto del IRS-1 como del IRS-2 están asociadas con un par de IMPIs del usuario 91 dado, es decir la IMPI-1 3a y la IMPI-2 3b.

El primer IRS, es decir el IRS-1, que representa el entorno local puede así incluir la IMPU-1 2a para ser compartida, es decir Bob@ims.com, que identifica al usuario en el IMS 8, y las IMPUs del usuario 91 en el entorno local: la IMPU-4 2d, es decir Bob@wireline, que identifica a cualquier aplicación del usuario en el PC de sobremesa 9d o la STB de IPTV 9c, y la IMPU-5 2e, es decir +9876543210, que identifica al número de ISDN del terminal de telefónica fijo 9b para servicios de telefonía fija y móvil. Además, este IRS-1 incluye también cualquier otra IMPU alias de la IMPU-1 tal como la IMPU-6 2f, es decir Bob@bobdomain. Este IRS-1 71 incluye también, de acuerdo con la invención, una condición de acceso 41 que debe cumplirse con el fin de llevar a cabo el registro implícito de las IMPUs del IRS-1. En este caso, la condición de acceso 41 es construida como resultado de acceder al IMS 8 a través bien de la primera red de acceso 61, o bien de la segunda red de acceso 62 o de ambas.

En general, una condición de acceso incluida en cualquier IRS puede entenderse como resultado de una operación lógica (lo que hace uso de operadores lógicos tradicionales tales como Y, O, NO, etc.) con condiciones individuales

E07821925 16-11-2011

seleccionadas de un grupo de condiciones que incluye: un acceso telefónico móvil sólo, un acceso telefónico fijo sólo, llamada de emergencia, red de itinerancia, redes de acceso individuales y combinaciones de los mismos.

Además, el IRS-1 incluye también un estado de registro 51 para indicar el estado de registro aplicable para todas las IMPUs del citado IRS-1. En particular, como se muestra en la Fig. 4, tanto la IMPU-1 2a como la IMPU-6 2f comparten un único SP, es decir el SP-A 6a; mientras que tanto la IMPU-4 2d como la IMPU-5 2e comparten un único SP, es decir el SP –B 6b. Como se ha comentado ya anteriormente, la IMPU-2 y la IMPU-6 que comparten un único SP y que están incluidas en el mismo IRS se dice que son IMPUs alias, como lo son IMPU-4 e IMPU-5 respectivamente.

El segundo IRS 72, es decir IRS-2, que representan el entorno de telefonía móvil puede incluir también la IMPU-1 2a para ser compartida, es decir Bob@ims.com, que identifica al usuario en el IMS 8, y las IMPUs del usuario 91 en el entorno de telefonía móvil: La IMPU-2 2b, es decir Bob@wireless, que identifica a una cuenta de correo electrónico para el usuario en el PC portátil conectado con el terminal de telefonía móvil 9a, y la IMPU-3 2c, es decir +1234567890, que identifica el terminal de telefonía móvil 9a de MSISDN para servicios telefónicos fijo y móvil. Además, este IRS-2 incluye también la IMPU-6 2f, es decir Bob@bobdomain, como IMPU alias de la IMPU-1. Este IRS-2 72 incluye también, de acuerdo con la invención, una condición de acceso 42 que debe cumplirse con el fin de llevar a cabo el registro implícito de las IMPUs del IRS-2. En este caso, la condición de acceso 42 puede incluir simplemente un indicador de acceso al IMS 8 a través de la tercera red de acceso 63. Además, el IRS-2 72 incluye también un estado de registro 52 para indicar el estado del registro aplicable para todas las IMPUs del citado IRS-2. En particular, como se muestra en la Fig. 4, tanto la IMPU-1 2a como la IMPU-6 2f comparten el único SP, es decir el SP-A 6a, como para el IRS-1; mientras que tanto la IMPU-2 2b como la IMPU-3 3c comparten un único SP, es decir SP-C 6c. Como ya se ha comentado anteriormente, la IMPU-1 y la IMPU-6 que comparten un único SP y que están incluidas en el mismo IRS se dice que son IMPUs alias, como lo son también la IMPU-2 y la IMPU-3 respectivamente.

Con este fin, el HSS 81 puede comprende un almacén 13 para almacenar la estructura de datos por abonado; un receptor 12 para recibir el registro explícito de la IMPU-2 2a bajo la condición de acceso 42 dada; y un procesador 10 para activar el registro implícito de las IMPUs 2a, 2b, 2c, 2f del IRS-2 72 asociado con la citada condición de acceso 42. En una realización de la invención, el HSS 81 puede también comprender un emisor 11 para enviar esas IMPUs 2a, 2b, 2c, 2f al IRS-2 72 asociadas con la citada condición de acceso 41 como resultado del registro explícito de la IMPU-1 2a dada. En particular, el almacén 13 puede comprender datos de una base de datos externa 131, donde la base de datos es proporcionada por un tercer suministrador participante, o puede comprender una base de datos interna, no mostrada en ningún dibujo, que coopera con otras entidades funcionales del HSS 81.

También con este propósito, la S-CSCF 82 puede incluir un receptor 22 para recibir un registro explícito de la IMPU1 2a dada, y un emisor 21 para enviar el registro explícito de la citada IMPU hacia el HSS 81, donde el emisor 21 puede estar también dispuesto para enviar hacia el HSS la condición de acceso dada para la cual aplica el registro explícito.

En operación, y donde una IMPU dada es compartida por más de un IRS, el registro explícito de la citada IMPU dada bajo una condición de acceso dada activa el registro implícito de las IMPUs del IRS asociadas con la citada condición de acceso, mientras que el estado del registro de las IMPUs en cualquier otro IRS, que está asociado con una condición de acceso diferente, permanece sin cambios. Una vez que la estructura de datos de ejemplo de la Fig. 4 ha sido definida para un usuario dado 91 en una red FMC como se muestra en la Fig. 3, diferentes secuencias o acciones pueden ser seguidas por el usuario con respecto a los registros de pares de IMPI/IMPU en el IMS 8.

La fig. 7 ilustra una secuencia de ejemplo de acciones que el usuario 91 puede llevar a cabo en el curso del acceso al IMS 8. El usuario puede utilizar el terminal de telefonía móvil 9a para registrar la IMPU-1 2a, Bob@ims.com, con un mensaje de Registro de SIP en la etapa S-200. Tal mensaje llega al IMS por medio de la tercera red de acceso 63, y es transmitido a través de la red de núcleo de IMS hasta que llega a la S-CSCF 82 asignada para proporcionar servicio al usuario. La S-CSCF 82 que recibe tal mensaje envía durante una etapa S-205 un registro explícito correspondiente hacia el HSS 81 a cargo del usuario, probablemente con un mensaje de SAR, que proporciona la IMPU-1 para ser registrada junto con una indicación para determinar la condición de acceso que va debe ser aplicada.

El HSS 81 que recibe tal registro explícito de IMPU-1 determina que el IRS-2 72 incluye la IMPU-1 2a recibida y cumple con la condición de acceso 42, y activa el registro implícito de esas IMPUs del citado IRS-2 72. A continuación, el HSS envía durante la etapa S-210 a la S-CSCF 82 que actualmente proporciona servicio al usuario, probablemente con un mensaje SAA, aquellas IMPUs del citado IRS-2 72 (es decir la IMPU-1, la IMPU-6, la IMPU-2 y la IMPU-3), probablemente acompañadas por los SP-A 6a y SP-C 6c respectivamente asociados y de otros datos de abonado. La emisión de SPs y de otros datos del abonado no es significativa para el propósito de la invención. Eventualmente, el usuario 91 es informado a través del terminal de telefonía móvil 9a, durante la etapa S-215, del

E07821925 16-11-2011

registro implícito de la IMPU-1, la IMPU-6, la IMPU-2 y la IMPU-3, probablemente con un mensaje de OK de SIP

200.

La secuencia de ejemplo de acciones ilustrada en la Fig. 7 continúa donde el usuario hace uso del PC de sobremesa 9d conectado a una línea fija para acceder al IMS 8. El usuario 91 lleva a cabo durante una etapa S-220 un nuevo registro explícito de la IMPU-1 2a, Bob@ims.com, desde el PC de sobremesa 9d con un mensaje de Registrar de SIP. Este mensaje llega al IMS por medio de la primera red de acceso 61, y es transmitido a través de la red de Núcleo de IMS hasta que alcanza la S-CSCF 82 asignada para proporcionar servicio al usuario. Por lo que respecta al registro previo, la S-CSCF 82 que recibe tal mensaje envía durante una etapa S-225 un registro explícito correspondiente hacia el HSS 81 a cargo del usuario, probablemente con un mensaje de SAR, proporcionando la IMPU-1 que va a ser registrada junto con una indicación para determinar la condición de acceso que se va a aplicar.

En este caso particular, la condición de acceso que debe cumplirse es el acceso a través de la primera red de acceso 61, y en el IRS-1 71 en el HSS 81 que había sido configurada con una condición de acceso 41 construida como resultado de llevar a cabo la operación lógica: ‘acceso a través de primera red de acceso 61’ O’ acceso a través de segunda red de acceso 62’.

El HSS 81 que recibe tal registro explícito nuevo de la IMPU-1 determina que el IRS-1 71 también incluye la IMPU-1 recibida 2a y cumple con la condición de acceso 41, y activa el registro implícito de las IMPUs del citado IRS-1 71. A continuación, el HSS envía durante la etapa S-230 a la S-CSCF 82 que actualmente proporciona servicio al usuario, probablemente con un mensaje de SAA, las IMPUs del citado IRS-1 71 (es decir la IMPU-1, la IMPU-6, la IMPU-4 y la IMPU-5), probablemente acompañadas por los SP-A 6a y SP-B 6b asociados respectivamente y por otros datos de abonado. Como antes, la emisión de SPs y de otros datos de abonado no es significativa para el propósito de la invención. Eventualmente, el usuario 91 es informado a través del PC de sobremesa 9d, durante la etapa S-235, del registro implícito de la IMPU-1, la IMPU-6, la IMPU-4 y la IMPU-5, probablemente con un mensaje de OK de SIP

200.

En la presente situación, y a continuación de los dos registros implícitos del IRS-1 71 y del IRS-2 72 llevados a cabo en el HSS 81 como resultado de los dos registros explícitos de la IMPU-1 2a bajo diferentes condiciones de acceso 41 y 42, el HSS 81 ha grabado los citados dos registros implícitos del IRS-1 71 y del IRS-2 72 con el fin de impedir ninguna otra eliminación parcial del registro de las IMPUs correspondientes.

Para este propósito, el procesador 10 del HSS 81 puede estar dispuesto para grabar en el almacén 13 el registro implícito de IMPUs de cualquier IRS con el fin de impedir la eliminación parcial del registro de las IMPUs del IRS asociado con la citada condición de acceso.

Antes de explicar cómo puede el usuario 91 eliminar del registro cualquier IMPU registrada actualmente, pueden presentarse algunas realizaciones de ejemplo de comunicaciones entre el usuario 91 y cualquier otro usuario.

Por ejemplo, la Fig. 8 ilustra una realización de ejemplo en la que otro usuario 92 inicia un número de llamadas, o de comunicaciones, hacia el usuario 91 dado. El citado otro usuario 92 puede iniciar una comunicación para alcanzar al usuario 91 dado en casa y, particularmente, al terminal telefónico fijo 9b puesto que las llamadas a terminales de línea fijos son habitualmente más baratas que la tarifa aplicable a los terminales móviles 9a. Para este propósito, el otro usuario 92 marca +9876543210, es decir la IMPU-5, y la llamada señalada durante la etapa S-250 hacia la S-CSCF 82 que actualmente proporciona servicio al usuario 91 dado. La S-CSCF 82 procesa tal señalización de llamada y, encontrando la IMPU-5 indicada entre aquéllas ya registradas en el HSS, envía durante la etapa S-255 una invitación para comunicar hacia el terminar telefónico fijo 9b identificado mediante la IMPU-5 indicada, probablemente con un mensaje de Invitar de SIP. Simultáneamente con esta llamada, o después, el mismo otro usuario 92 ó cualquier otro usuario pueden desear iniciar una comunicación hacia el PC de sobremesa 9d en casa del usuario 91 dado. Para este propósito, el otro usuario 92 escribe la dirección de destino Bob@wireline, es decir la IMPU-4, y la llamada es señalada durante una etapa S-260 hacia la S-CSCF 82 que actualmente proporciona servicio al usuario 91 dado. La S-CSCF 82 procesa tal señalización de llamada y, encontrando la IMPU-4 indicada entre aquéllas ya registradas en el HSS, envía durante una etapa S-265 una invitación de comunicar hacia el PC de sobremesa 9d identificado por la IMPU-4 indicada, probablemente con un mensaje de Invitar de SIP.

Por otra parte, el mismo otro usuario 92 ó cualquier otro usuario desea iniciar también una comunicación hacia un PC portátil conectado al terminal móvil 9a del usuario 91 dado. Para ello, el otro usuario 92 escribe la dirección de destino Bob@wireless, es decir, la IMPU-2, y la llamada es señalada durante una etapa S-270 hacia la S-CSCF 82 que actualmente proporciona servicio al usuario 91 dado. La S-CSCF 82 procesa tal llamada señalando y encontrando la IMPU-2 indicada entre aquéllas ya registradas en el HSS, envía durante una etapa S-275 una invitación para comunicar hacia el PC portátil a través del terminal móvil 9a identificado por la IMPU-2 indicada, probablemente también con un mensaje de Invitar de SIP. Asimismo, el mismo otro usuario 92, ó cualquier otro usuario, puede desear iniciar una llamada telefónica hacia el terminal móvil 9a del usuario 91 dado. Para ello, el otro usuario 92 marca +1234567890, es decir la IMPU-3, y la llamada es señalada durante una etapa S-280 hacia la S

E07821925 16-11-2011

CSCF 82 que actualmente proporciona servicio al usuario 91 dado. La S-CSCF 82 procesa tal señalización de llamada y, encontrando la IMPU-3 indicada entre las ya registradas en el HSS, envía durante una etapa S-285 una invitación para comunicar hacia el terminal móvil 9a identificado por la IMPU-3 indicada, probablemente con un mensaje de Invitar de SIP.

Con respecto a un estado no registrado y a un estado de eliminado del registro que cualquier IMPU puede tener, la Fig. 10 ilustra una realización de ejemplo del flujo de acciones que puede ser iniciado de acuerdo con la invención para eliminar del registro una IMPU a través del terminal móvil 9a, así como para eliminar del registro una IMPU a través del PC de sobremesa 9d. Como ya se ha comentado anteriormente, sólo las IMPUS del tipo de URI de SIP pueden ser utilizadas durante los procedimientos de registro, siendo para hacer que una IMPU pase a estado registrado, a estado no registrado o a estado eliminado del registro.

La etapa 10 se inicia así con un mensaje de señalización enviado desde el terminal móvil 9a durante una etapa S300 que instruye el IMS 8 para eliminar del registro a la IMPU-6 2f, es decir Bob@bobdomain. Tal mensaje se recibe en la S-CSCF 82 que actualmente proporciona servicio al usuario 91, que transmite uno correspondiente durante una etapa S-305 hacia el HSS 81, probablemente con un mensaje de SAR que indica la citada IMPU-6 junto con una indicación de determinar la condición de acceso que debe ser aplicada, es decir, acceder al IMS a través de la tercera red de acceso 63. El HSS 81, cuando se recibe tal instrucción para eliminar del registro la IMPU-6, determina que en el IRS-2 72 incluye la IMPU-6 2f recibida y cumple con la condición de acceso 42, y activa las IMPUS del citado IRS-2 72 que son implícitamente eliminadas del registro. A continuación, el HSS 81 envía durante una etapa S-310 a la S-CSCF 82 que actualmente proporciona servicio al usuario, probablemente con un mensaje de SAA, las IMPUs del citado IRS-2 71 (es decir la IMPU-1, la IMPU-6, la IMPU-2 y la IMPU-3) que han sido eliminadas del registro. Eventualmente, el terminal móvil 9a es informado durante una etapa S-315 de que la IMPU-2, la IMPU-6, la IMPU-2 y la IMPU-3 han sido eliminadas del registro. Aunque no se ilustra en ningún dibujo, un mecanismo similar también puede ser aplicado entre la S-CSCF 82 y el HSS 81 para hacer que una IMPU sea explícitamente eliminada del registro y, subsiguientemente, las IMPUs del IRS correspondiente para la condición de acceso asociada que es así implícitamente eliminada del registro.

La Fig. 10 continúa con un mensaje de señalización enviado desde el PC de sobremesa 9d durante una etapa S-320 que instruye al IMS 8 para eliminar del registro la IMPU-4 2d, es decir Bob@wireline. Tal mensaje es recibido en la S-CSCF 82 que actualmente proporciona servicio al usuario 91, que transmite uno correspondiente durante una etapa S-325 hacia el HSS 81, probablemente con un mensaje de SAR que indica que la citada IMPU-4 junto con una indicación de determinar la condición de acceso que debe ser aplicada, esto es, acceder al IMS a través de la primera red de acceso 61. El HSS 81, cuando se recibe tal instrucción de eliminar del registro a la IMPU-4 2d, determina que en el IRS-1 71 incluye la IMPU-4 2d recibida y cumple con la condición de acceso 41, y activa las IMPUs del citado IRS-1 71 que son implícitamente eliminadas del registro. A continuación, el HSS 81 envía durante una etapa S-330 a la S-CSCF 82 que actualmente proporciona servicio al usuario, probablemente con un mensaje de SAA, las IMPUs del citado IRS-1 71 (es decir la IMPU-1, la IMPU-6, la IMPU-4 y la IMPU-5) que han sido eliminadas del registro. Eventualmente, el PC de sobremesa 9d es informado durante una etapa S-335 de que la IMPU-1, la IMPU-6, la IMPU-4 y la IMPU-5 han sido eliminadas del registro. Aunque no se ilustra en ningún dibujo, un mecanismo similar puede ser también aplicado entre la S-CSCF 82 y el HSS 81 para hacer que una IMPU sea explícitamente eliminada del registro y, subsiguientemente, las IMPUs del correspondiente IRS para la condición de acceso asociada que es así implícitamente eliminada del registro.

En las realizaciones de ejemplo anteriores, el estado del registro 51, 52 de cada IRS adopta un único valor ‘registrada’, ‘no registrada’ o ‘eliminada del registro’ aplicable a las IMPUs de cada IRS 71, 72.

Para ello, el receptor 12 del HSS 81 puede ser dispuesto para recibir una eliminación de registro de una IMPU del IRS, o una instrucción para hacer que la IMPU sea eliminada del registro, cuyo registro implícito fue grabado en el almacén 13, y el procesador 10 puede estar dispuesto para activar la eliminación del registro de las IMPUs del citado IRS, o para hacer que esas IMPUs sean eliminadas del registro. Además, el receptor 12 puede también estar dispuesto para recibir una condición de acceso dada junto con una eliminación del registro de una IMPU, o la instrucción para hacer que sea eliminada del registro, y el procesador 10 puede también estar dispuesto para utilizar la condición de acceso dada para determinar una eliminación del registro de las IMPUs de un IRS asociadas con la citada condición de acceso, o para hacer que sean eliminadas del registro, como podría ser el caso.

También para ello, el emisor 21 de la S-CSCF 82 puede también estar dispuesto para enviar hacia el HSS 81, junto con una eliminación del registro de una IMPU, una condición de acceso dada para la cual aplica la eliminación del registro.

La estructura de datos explicada anteriormente, mediante la cual una IMPU dada puede ser compartida por más de un IRS, estando cada IRS asociado con una condición de acceso, y el registro explícito de la IMPU dada, bajo una condición de acceso dada, activando el registro implícito de las IMPUs del IRS asociadas con la condición de acceso dada, puede cumplir los requisitos regulatorios anteriores en el campo de las Llamadas de Emergencia.

E07821925 16-11-2011

Con respecto a esto, la estructura de datos de ejemplo ilustrada en la Fig. 5 incluye un tercer IRS 73, es decir el IRS3, para ser registrado implícitamente donde el usuario accede al IMS 8 para una llamada de emergencia a través del entorno local mostrado en la Fig. 3, esto es, a través de una primera red de acceso 61 ó a través de una segunda red de acceso 62; y un cuarto IRS 74, es decir el IRS-4, para ser implícitamente registrado donde el usuario accede al IMS 8 para una llamada de emergencia a través del entorno de telefonía móvil mostrado en la Fig. 3, es decir, a través de una tercera red de acceso 63. En aras de la simplicidad con respecto a la presente invención, todas las IMPUs del IRS-3 y del IRS-4 están también asociadas con el mismo par de IMPIS del usuario 91 dado como antes, es decir la IMPI-1 3a y la IMPI-2 3b.

Donde los requisitos regulatorios imponen una IMPU dedicada para ser registrada para Llamadas de Emergencia, una IMPU llamada de Emergencia (en lo que sigue E-IMPU), tal E-IMPU puede ser compartida, de acuerdo con la presente invención, por todos los IRSs en los que la emergencia está incluida como, al menos parte de, la condición de acceso.

Este tercer IRS 73 de la estructura de datos, es decir el IRS-3 utilizable para llamadas de emergencia desde el entorno local, incluye la E-IMPU 2g utilizable para el registro de una llamada de emergencia, y puede también incluir la IMPU-1 2a, es decir Bob@ims.com, identificando el usuario el IMS 8, y las IMPUs del usuario 91 en el entorno local: la IMPU-4 2d, es decir Bob@wireline, y la IMPU-5 2e, es decir +9876543210. Además, este IRS-3 puede también incluir la IMPU-6 2f, es decir Bob@bobdomain, como IMPU alias de la IMPU-1. Este IRS-3 73 incluye también, de acuerdo con la invención, una condición de acceso 43 que debe ser cumplida con el fin de llevar a cabo el registro implícito de las IMPUs del IRS-3 de emergencia.

En este caso, la condición de acceso 43 es construido como resultado de llevar a cabo la operación lógica: ‘llamada de emergencia’ Y [‘acceso a través de la primera red de acceso 61’ O ‘acceso a través de la segunda red de acceso 62’].

Por lo que se refiere al IRS-1, el IRS-3 de emergencia incluye también un estado del registro 53 para indicar el estado del registro aplicable para todas las IMPUs del citado IRS-3. En particular, como se muestra en la Fig. 5, tanto la IMPU-1 2a como la IMPU-6 2f comparten un único SP, es decir el SP-A 6a; mientras que tanto la IMPU-4 2d como la IMPU-5 2e comparten un único SP, es decir el SP-B 6b. La E-IMPU puede estar simplemente asociada con un tipo de perfil por defecto 6d, es decir SP-nulo, puesto que no se utiliza ninguna capacidad de servicio particular para llamadas de emergencia, distinta de la de ser utilizada para activar el registro implícito de IMPUs del IRS-3 ó del IRS-4 de emergencia, y especialmente los del tipo de URI de TEL utilizables para propósitos de devolución de llamada.

La Fig. 5 ilustra también el cuarto IRS 74 de la estructura de datos, es decir el IRS-4 utilizable para llamadas de emergencia desde el entorno de telefonía móvil. Este IRS-4 74 también incluye la E-IMPU 2g utilizable para el registro de una llamada de emergencia, y también puede incluir la IMPU-1 2a, es decir Bob@ims.com, que identifica al usuario en el IMS 8, y las IMPUs del usuario 91 en el entorno de telefonía móvil: la IMPU-2 2b, es decir Bob@wireless, y la IMPU-3 2c, es decir +1234567890. Además, este IRS-4 puede también incluir la IMPU-6 2f, es decir Bob@bobdomain, como IMPU alias de la IMPU-1. Este IRS-4 74 incluye también, de acuerdo con la invención, una condición de acceso 44 que debe ser cumplida con el fin de llevar a cado el registro implícito de las IMPUs del IRS-4 de emergencia.

En este caso, la condición de acceso 44 es construida como resultado de llevar a cabo la operación lógica: ‘llamada de emergencia’ Y’ acceso a través de la tercera red de acceso 63’. Por lo que se refiere al IRS-2 previo, el IRS-4 de emergencia incluye también un estado de registro 54 para indicar el estado del registro aplicable para todas las IMPUs del citado IRS-4. En particular, como se muestra en la Fig. 5, tanto la IMPU-1 2a como la IMPU-6 2f comparten un único SP, es decir el SP-A 6a; mientras que tanto la IMPU-2 2b como la IMPU-3 2c comparten un único SP, es decir el SP-C 6c. La E-IMPU puede estar simplemente asociada, como en el IRS-3, con un tipo de perfil por defecto 6d, es decir el SP-nulo, puesto que no se utilizan capacidades de servicio particulares para llamadas de emergencia distintas de las que permiten el registro implícito de IMPUs del tipo de URI de TEL utilizables para propósitos de devolución de llamada.

En operación, la Fig. 6 ilustra una realización de ejemplo del usuario 91 que hace una llamada de emergencia a través del terminal de telefonía móvil 9a por medio del IMS 8. La secuencia de acciones se inicia con un registro explícito de la E-IMPU llevado a cabo durante una etapa S-100 a través del terminal de telefonía móvil 9a. Tal mensaje llega al IMS por medio de la tercera red de acceso 63, y es transmitido a través de la red de Núcleo del IMS hasta que alcanza una S-CSCF 82 asignada para proporcionar servicio al usuario. La S-CSCF 82 que recibe tal mensaje envía durante una etapa S-105 un registro explícito correspondiente hacia el HSS 81 a cargo del usuario, probablemente con un mensaje de SAR, proporcionando el E-IMPU 2g para ser registrado junto con una indicación de determinar la condición de acceso que debe aplicarse.

E07821925 16-11-2011

El HSS 81 que recibe tal registro explícito de la E-IMPU determina que el IRS-4 74 incluye la E-IMPU 2g recibida y cumple con la condición de acceso 44, y activa el registro implícito de las IMPUs en el citado IRS-4 74. Entonces, el HSS envía durante una etapa S-110 a la S-CSCF 82 que actualmente proporciona servicio al usuario, probablemente con un mensaje de SAA, las IMPUs del citado IRS-4 74 (es decir la IMPU-1, la IMPU-6, la IMPU-2 y la IMPU-3), o al menos las del tipo de URI de TEL (IMPU-3: +1234567890), probablemente acompañadas por los SP-A 6a y SP-C 6c asociados respectivamente y por otros datos del abonado. Como se ha comentado ya anteriormente, la emisión de SPs y de otros datos del abonado no es significativa para el propósito de la invención. Eventualmente, el usuario 91 es informado a través del terminal de telefonía móvil 9a, durante una etapa S-115, del registro implícito de la IMPU-1, la IMPU-6, la IMPU-2 y la IMPU-3, probablemente con un mensaje de OK de SIP 200 u otro similar.

La secuencia de acciones de ejemplo ilustrada en la Fig. 7 continúa donde el usuario hace la llamada de emergencia hacia una Emergency Call Session Control Function 83 (en lo que sigue E-CSCF – Función de Control de Sesión de Llamada de Emergencia) durante una etapa S-120. Tal llamada de emergencia siempre incluye una URI de TEL que identifica un terminal de usuario, o equipo de usuario, donde el usuario es alcanzable: en este caso, la IMPU-3. A continuación, la E-CSCF envía tal llamada de emergencia hacia el ERC 93 durante una etapa S-125. Siempre que el ERC 93 necesita comunicar con el usuario 91, por ejemplo durante una etapa S-130, inicia una devolución de llamada haciendo uso de la URI de TEL recibida que se dirige al usuario, es decir la IMPU-3. Tal devolución de llamada es señalada hacia la S-CSCF 92 que proporciona servicio al usuario, como para cualquier llamada entrante convencional, y la S-CSCF envía tal devolución de llamada hacia el terminal de telefonía móvil 9a actualmente en uso por el usuario 91.

Por lo que respecta a la implementación de realizaciones, la invención puede ser llevada a la práctica mediante un programa de ordenador, que es cargable en una memoria interna de un ordenador que incluye unidades de entrada y salida, así como una unidad de tratamiento. Este programa de ordenador comprende porciones de código ejecutables adaptadas para llevar a cabo secuencias de acciones descritas bajo las realizaciones anteriores cuando se ejecutan en el ordenador. En particular, el programa de ordenador puede ser grabado en un medio legible por ordenador de soporte, tal como un CD-ROM.

La invención es descrita anteriormente con respecto a varias realizaciones de una manera ilustrativa y no restrictiva. Obviamente, variaciones y combinaciones de estas realizaciones son posibles a la luz de las enseñanzas anteriores, y cualquier modificación de las realizaciones que cae dentro del alcance de las reivindicaciones se pretende que esté incluida en las mismas.

Claims

REIVINDICACIONES

1. Un Home Subscriber Server “HSS – Servidor de Abonado Local”, (81) que soporta datos de abonado de usuarios de un IP Multimedia Subsystem “IMS – Subsistema multimedia IP” (8), teniendo el HSS una estructura de 5 datos por abonado que incluye una pluralidad de Identidades de Usuario Públicas de IMS (2a-2g), estando cada IMS Public User Identity “IMPU – Identidad de Usuario Pública de IMS” asociada con al menos una IMS Private User Identity “IMPI – Identidad de Usuario Privada de IMS” (3a-3b), donde un número n de IMPUs están distribuidas en un número m de Conjuntos de Registro implícitos (71, 72, 73, 74), y donde todas las IMPUs de cada Implicit Registration Set “IRS – Conjunto de Registro Implícito” comparten el mismo estado de registro (51, 52, 53, 54),

10 estando el HSS caracterizado porque cada IRS está asociado con una condición de acceso (41, 42, 43, 44), una IMPU (2a) dada es compartida por más de un IRS (71, 72), y el estado explícito de la citada IMPU (2a) dada bajo una condición de acceso (42) dada activa el registro implícito de las IMPUs (2a, 2b, 2c, 2f) en el IRS (72) asociado con la citada condición de acceso (42), mientras que el estado del registro (51, 53, 54) de las IMPUs en cualquier otro IRS (71, 73, 74) permanece sin cambios.
2.

El HSS de la reivindicación 1, en el que un registro explícito de una IMPU, que pertenece sólo a un IRS, activa un registro implícito de las IMPU en el citado IRS para la condición de acceso asociada.
3.

El HSS de la reivindicación 1, en el que la condición de acceso dada es seleccionada de un grupo de

20 condiciones de acceso que incluye: sólo un acceso telefónico móvil, sólo un acceso telefónico fijo, una llamada de emergencia, una red de itinerancia y combinaciones de los mismos.
4. El HSS de la reivindicación 1, en el que el registro implícito de las IMPUs del IRS asociadas con la citada

condición de acceso es grabado con el fin de impedir una eliminación parcial del registro de las IMPUs del citado 25 IRS.
5. El HSS de la reivindicación 2, en el que el registro implícito de las IMPUs del IRS es grabado con el fin de impedir una eliminación parcial del registro de las IMPUs del citado IRS.

30 6. El HSS de la reivindicación 1, que comprende también un almacén (13) para almacenar la estructura de datos por abonado; un receptor (12) para recibir el registro explícito de la IMPU (2a) dada bajo la condición de acceso (42) dada; y un procesador (10) para activar el registro implícito de las IMPUs (2a, 2b, 2c, 2f) del IRS (72) asociado con la citada condición de acceso (42).

35 7. El HSS de la reivindicación 6, que comprende también un emisor (11) para enviar las IMPUs (2a, 2b, 2c, 2f) del IRS (72) asociadas con la citada condición de acceso (42) dada como resultado del registro explícito de la IMPU (2a) dada.
8. El HSS de la reivindicación 6, en el que el procesador está dispuesto para grabar en el almacén el registro

40 implícito de las IMPUs del IRS asociadas con la citada condición de acceso con el fin de impedir una eliminación parcial del registro de las IMPUs del citado IRS.
9. El HSS de la reivindicación 7, en el que el procesador está dispuesto para grabar en el almacén el registro

implícito de las IMPUs del IRS con el fin de impedir una eliminación parcial del registro de las IMPUs del citado IRS.45
10. El HSS de la reivindicación 6, en el que el receptor está también dispuesto para recibir una condición de acceso dada junto con una eliminación de un registro de una IMPU, y el procesador está también dispuesto para utilizar la condición de acceso dada para determinar una eliminación del registro de las IMPUs del IRS asociadas con la citada condición de acceso.
11.

El HSS de la reivindicación 6, en el que el almacén comprende un gestor de memoria (130) para enviar y obtener datos de una base de datos externa (131).
12.

Un método de llevar a cabo un registro implícito de un Implicit Registration Set “IRS – Conjunto de Registro

55 Implícito” entre una pluralidad de IRSs en un Home Subscriber Server “HSS – Servidor de Abonado Local” (81), comprendiendo cada IRS más de una IMS Public User Identity “IMPU – Identidad de Usuario Pública de IMS” y compartiendo las IMPUs de cada IRS un mismo estado de registro, comprendiendo el método una etapa de distribuir un número n de IMPUs (2a-2g) en un número m de IRSs (71, 72, 73, 74), y caracterizado por las etapas de:

60 - el que una IMPU (2a) dada sea compartida por más de un IRS (71, 72);

- asociar cada IRS (71, 72, 73, 74) con una condición de acceso (41, 42, 43, 44); -llevar a cabo un registro explícito (S-100, S-200, S-220) de la IMPU (2a) dada bajo una condición de acceso

(42) dada; y - activar un registro implícito en el HSS (S-110, S-210, S-230) de las IMPUs (2a, 2b, 2c, 2f) de un IRS (72) asociadas con la citada condición de acceso (42) dada, mientras que el estado del registro (51, 53, 54) de las IMPUs de cualquier otro IRS permanece sin cambios.

5 13. El método de la reivindicación 12, que comprende también una etapa de llevar a cabo un registro explícito de una segunda IMPU, que pertenece sólo a un IRS, y una etapa responsable de activar un registro implícito de IMPUs en el citado IRS para la condición de acceso asociada.
14. El método de la reivindicación 12, en el que la condición de acceso dada es seleccionada de un grupo de

10 condiciones de acceso que incluye: sólo un acceso telefónico móvil, sólo un acceso telefónico fijo, una llamada de emergencia, una red de itinerancia y combinaciones de los mismos.
15. El método de la reivindicación 12, que comprende también una etapa de grabar el registro implícito de las IMPUs

del IRS asociadas con la citada condición de acceso, con el fin de impedir una eliminación parcial del registro de las15 IMPUs del citado IRS.
16. El método de la reivindicación 13, que comprende también una etapa de grabar el registro implícito de las IMPUs del IRS, con el fin de impedir una eliminación parcial del registro de las IMPUs del citado IRS.

20 17. El método de la reivindicación 12, que comprende también una etapa de recibir una condición de acceso dada junto con una eliminación parcial del registro de una IMPU, y una etapa de utilizar la condición de acceso dada para determinar una eliminación parcial del registro de las IMPUs de un IRS asociadas con la citada condición de acceso.
18. Un programa de ordenador, cargable en una memoria interna de un ordenador con unidades de entrada y salida

25 así como con una unidad de tratamiento, comprendiendo el programa de ordenador un código ejecutable adaptado para llevar a cabo las etapas del método de acuerdo con cualquiera de las reivindicaciones 12 a 17 cuando se ejecuta en el ordenador.
19. El programa de ordenador de la reivindicación 18, en el que el software ejecutable es grabado en un portador 30 legible en un ordenador.