ES2559686T3 - Método, aparato y sistema para una recuperación en caso de siniestro operativo de un subsistema IMS - Google Patents

Abstract

Un método de recuperación de siniestro operativo, que comprende: iniciar una Función de Control de Sesión de Llamada, CSCF, redundante (S101); la obtención, por la función CSCF redundante, de la información de identidades de usuarios privados de subsistemas multimedia IP, IMS IMPIs, registrados que están asociados con una identidad de usuario público IMS, IMPU, en una suscripción de IMS transmitida por una entidad de memorización en red de un usuario; en donde la identidad de memorización en red es un Servidor de Abonado Residencial, HSS; la determinación, por la función CSCF redundante, de una IMPU a recuperar en conformidad con la información recibida de las IMPIs registradas y la demanda a la entidad de memorización en red del usuario para recuperar datos de configuración de servicio de usuario de la IMPU y datos de usuarios en copia de seguridad de la IMPU; la recepción, por la función CSCF redundante, de los datos de configuración de servicio de usuario de la IMPU y los datos de usuarios en copia de seguridad de todos las IMPIs asociadas con la IMPU que se incluyen en una respuesta reenviada por la entidad de memorización en red del usuario; la recuperación, por la CSCF redundante, de un servicio correspondiente en conformidad con los datos de usuarios en copia de seguridad obtenidos de todas IMPIs que se asocian con la IMPU y los datos de configuración de servicio de usuario de la IMPU en la suscripción de IMS (S103).

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Metodo, aparato y sistema para una recuperacion en caso de siniestro operativo de un subsistema IMS CAMPO DE LA INVENCION

La presente invencion se refiere a tecnolog^as de redes de Subsistema Multimedia IP (IMS) y en particular, a un metodo, un aparato y un sistema para la recuperacion de siniestro operativo de un subsistema iMs.

ANTECEDENTES DE LA INVENCION

Un subsistema IMS introduce una idea de separacion de control respecto al soporte en una red de comunicaciones basada en el protocolo IP. El subsistema IMS es un elemento esencial en el procesamiento de servicios de la red de comunicaciones. La alta fiabilidad del subsistema IMS es la base de alta fiabilidad operativa de la red de comunicaciones completa.

Para mejorar la fiabilidad del subsistema IMS, debe mejorarse la capacidad de recuperacion en caso de siniestro operativo de la red. Una red de IMS incluye multiples entidades de red, entre las cuales existe una fuerte asociacion. La capacidad de recuperacion en caso de siniestro operativo de la red significa que cuando falla un dispositivo de red, el fallo del dispositivo de red tenga el menor impacto posible sobre la red de IMS completa y sobre sus usuarios.

En la tecnica anterior, despues del registro satisfactorio con una red IMS, un equipo de usuario (UE) inicia de inmediato el funcionamiento de un temporizador de registro en conformidad con un periodo de registro negociado; cuando termina el funcionamiento del temporizador de registro, se inicia un re-registro del equipo UE. Si falla una Funcion de Control de Sesion de Llamada de servicio (S-CSCF) que proporciona servicios para el usuario, una nueva funcion S-CSCF puede asignarse al usuario por intermedio de un mecanismo de re-registro operativamente iniciado por un temporizador de registro.

En conformidad con las descripciones anteriores, cuando la funcion S-CSCF que proporciona servicios para el usuario tiene un fallo operativo, el servicio de red del equipo UE puede recuperarse despues de que el temporizador de registro del usuario inicie un re-registro y se vuelva a seleccionar una funcion S-CSCF. Es decir, la duracion de la interrupcion del servicio del equipo UE depende del periodo de registro del UE. Cuanto mas largo sea el periodo de registro, tanto mas larga sera la duracion de la interrupcion del servicio. Para cumplir los requisitos de fiabilidad de una red de telecomunicaciones, el periodo de registro debe ser lo mas corto posible. No obstante, si el periodo de registro se establece a un valor demasiado pequeno, se producira un re-registro con frecuencia. Con respecto a la red, un re-registro aumenta la carga de procesamiento de la red y en particular, un re-registro frecuente ocupa recursos de interfaz de aire valiosos de una red de acceso de radio (RAN). Con respecto al equipo de usuario UE un re-registro frecuente consume la energfa limitada del UE y acorta el tiempo de reserva activa del UE.

Una solucion de los problemas anteriores esta disponible en la tecnica anterior. Es decir, durante el registro, la funcion S-CSCF realiza una copia de seguridad de los datos de usuarios relacionados con el registro, tal como la informacion de Identidad de Usuario Privado de IMS (IMPI), informacion de Identidad de Usuario Publico de IMS (IMPU), direccion de contacto registrada e informacion de rutas, para un Servidor de Abonado Residencial (HSS). Cuando la funcion S-CSCF tiene un fallo operativo y un equipo UE utiliza la red, una funcion CSCF Interrogante (I- CSCF) puede seleccionar otra S-CSCF para proporcionar servicios de sesion para el equipo UE y la nueva funcion S-CSCF puede obtener los datos de usuarios en copia de seguridad de IMPu que utiliza servicios con el fin de recuperar los servicios relacionados del equipo UE, con lo que se pone en practica la recuperacion en caso de siniestro operativo de la funcion S-CSCF.

Actualmente, los identificadores IDs de usuarios utilizados en una red de IMS incluyen principalmente una informacion de IMPI y de IMPU que se memoriza en un servidor HSS en el modo de suscripcion. Cuando un usuario realiza una operacion de servicio relacionada, las entidades relacionadas en la red tal como una I-CSCF, una S- CSCF y un Servidor de Aplicacion (AS) obtienen los datos de suscripcion del usuario por intermedio de un identificador ID de usuario. En el subsistema IMS, la relacion entre IDs de usuario y la relacion entre IDs de usuario y los datos de suscripcion son complejas. Segun se ilustra en la Figura 1, una suscripcion de IMS incluye toda la informacion de suscripcion que puede transmitirse por un equipo UE por intermedio de una interfaz Cx; una suscripcion IMS puede incluir multiples IMPIs, pero una IMPI pertenece a solamente una suscripcion de IMS; una IMPI puede incluir multiples IMPUs y una IMPU puede compartirse por multiples IMPIs. Es decir, la suscripcion de IMS esta en una relacion denominada de 'uno a muchos' con la IMPI y la IMPI esta en una relacion de 'muchos a muchos' con la IMPU. Por lo tanto, la logica de servicio tal como una IMPI multi-IMPU, una-IMPI multi-IMPI y multi- IMPI multi-IMPU pueden ponerse en practica de forma flexible.

El siguiente problema se hizo evidente en la solucion tecnica anterior para la recuperacion en caso de siniestro operativo de IMS; en la tecnica anterior, no se dispone de ninguna solucion de recuperacion detallada contra el modelo de datos de usuarios complejos en el IMS; por lo tanto, cuando se adopta la solucion tecnica anterior, los servicios de tipo una-IMPU multi-IMPI y multi-IMPI multi-IMPU de usuarios puede perderse, con lo que se reducen

5

10

15

20

25

30

35

40

45

50

55

60

65

las experiencias de continuidad de servicio de los usuarios. A modo de ejemplo, cuando el modelo de datos de usuario ilustrado en la Figura 2 se toma a modo de ejemplo, el procesamiento de la solucion de recuperacion de siniestro operativo de IMS en la tecnica anterior es como sigue:

Se supone que todas las instancias de IMPI y de IMPU en la suscripcion de IMS que se ilustra en la Figura 2 se registran en una funcion S-CSCF1. Si falla la funcion S-CSCF1 y si un equipo UE (IMPI1 e IMPU3) asociado con el servicio realiza un re-registro periodico, una demanda de registro se reenvfa a una funcion S-CSCF2 en conformidad con la solucion tecnica anterior. La funcion S-CSCF2 registra la IMPI1 y la IMPU3 de forma satisfactoria por intermedio de un proceso de registro estandar y recupera los datos de usuarios en copia de seguridad de las IMPI1 e IMPU3 para la funcion S-CSCF2. Ademas, un servidor HSS cambia el nombre del servidor memorizado para la suscripcion de IMS desde S-CSCF1 a S-CSCF2 y a continuacion, puede enviar un mensaje de respuesta de terminacion de registro (RTA) a la funcion S-CSCF original (S-CSCF1) para notificar que un proceso de migracion de UE es opcional y que aun cuando se envfe el mensaje RTA, falla el envfo debido al fallo de la S-CSCF original. Hasta ahora, el proceso de recuperacion de siniestro operativo causado por el registro de UE (IMPI1 e IMPU3) esta completo. Si se solicita a IMPU3: despues de recibir una demanda de llamada, una funcion I-CSCF busca el servidor HSS para una S-CSCF (S-SCCF2) que sirve a IMPU3 (de hecho, la suscripcion de IMS); la funcion S-CSCF2 esta en el estado normal y por lo tanto, la funcion I-CSCF no anade un indicador de recuperacion de siniestro operativo a la demanda de llamada, sino que enruta directamente la demanda a la S-CSCF2; despues de recibir la demanda, la S-CSCF2 determina que la IMPU3 tiene un terminal IMPI1 registrado a nivel local y que la demanda de llamada no contiene un indicador de recuperacion de siniestro operativo, por lo que S-CSCF2 no realiza una recuperacion de siniestro operativo, sino que analizas si enviar la demanda de llamada a IMPI1 o no hacerlo; en consecuencia, se pierde el servicio de una-IMPU multi-IMPI (IMPI1 e IMPI2) de la IMPU3.

Documento de HUAWEI: “Discusion sobre el fallo operativo de la funcion S-CSCF” INTERNET CITATION XP002470754 recuperado desde Internet: URL:

http://www.3gpp.org/ftp/tsg ct/WG4 protocollars ex-CN4/TSGCT4 36 Vienna/Docs/C4-071026.zip, describe

escenarios de fallos operativos de la funcion S-CSCF y sus posibles soluciones.

El documento CN 1 905 472 A describe un metodo para realizar la fiabilidad operativa de la red IMS. El metodo incluye: la primera entidad de red en la red IMS adquiere informacion sobre si la segunda entidad de red que memoriza los datos asociados con el registro del usuario no es valida; y si la primera entidad de red adquiere conocimientos de que la segunda entidad de red no es valida, lo notifica a un usuario registrado relacionado con la segunda entidad de red para un re-registro.

SUMARIO DE LA INVENCION

La invencion da a conocer un metodo, un aparato y un sistema, segun las reivindicaciones 1, 8, 9 y 11, para recuperacion de un siniestro operativo de una IMS con el fin de impedir que el servicio de tipo una-IMPU multi-IMPI, una-IMPI multi-IMPU o multi-IMPI multi-IMPU que este asociada con un modelo de datos de usuario complejo en el IMS sea objeto de perdida durante la recuperacion del siniestro operativo.

Varios aspectos de la idea inventiva son evidentes a partir de las reivindicaciones independientes. Las reivindicaciones subordinadas se refieren a formas de realizacion adicionales.

BREVE DESCRIPCION DE LOS DIBUJOS

La Figura 1 ilustra un modelo de datos de usuario en la tecnica anterior;

La Figura 2 es un diagrama de flujo de un metodo para memorizar de forma segura los datos de recuperacion del siniestro operativo en conformidad con una forma de realizacion de la presente invencion;

La Figura 3 es un diagrama de flujo en donde una red notifica a un equipo UE de registro para la recuperacion de un servicio por intermedio de datos de suscripcion de registro de copia de seguridad en conformidad con una forma de realizacion de la presente invencion;

La Figura 4 ilustra un modelo de datos de un mensaje extendido de Respuesta de Asignacion de Servidor (SAA) o Demanda de Perfil de Empuje (PPR) en conformidad con una forma de realizacion de la presente invencion;

La Figura 5 es un diagrama de flujo principal de un metodo para la recuperacion de siniestro operativo en conformidad con una forma de realizacion de la presente invencion;

La Figura 6 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una primera forma de realizacion de la presente invencion;

La Figura 7 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con

5

10

15

20

25

30

35

40

45

50

55

60

65

una segunda forma de realizacion de la presente invencion;

La Figura 8 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una tercera forma de realizacion de la presente invencion;

La Figura 9 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una cuarta forma de realizacion de la presente invencion;

La Figura 10 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una quinta forma de realizacion de la presente invencion;

La Figura 11 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una sexta forma de realizacion de la presente invencion;

La Figura 12 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una septima forma de realizacion de la presente invencion;

La Figura 13 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una octava forma de realizacion de la presente invencion;

La Figura 14 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una novena forma de realizacion de la presente invencion;

La Figura 15 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una decima forma de realizacion de la presente invencion;

La Figura 16 es un diagrama de flujo de un metodo para la recuperacion del siniestro operativo en conformidad con una undecima forma de realizacion de la presente invencion;

La Figura 17 ilustra una estructura de red de un subsistema IMS sobre la recuperacion del siniestro operativo en conformidad con una forma de realizacion de la presente invencion;

La Figura 18 ilustra una estructura de una unidad de procesamiento de recuperacion de siniestro operativo en conformidad con una forma de realizacion de la presente invencion;

La Figura 19 ilustra una estructura de una unidad de determinacion en conformidad con una forma de realizacion de la presente invencion;

La Figura 20 ilustra una estructura de una unidad de determinacion ilustrada en la Figura 19 en conformidad con otra forma de realizacion de la presente invencion;

La Figura 21 ilustra una estructura de una unidad de determinacion ilustrada en la Figura 19 en conformidad con otra forma de realizacion de la presente invencion;

La Figura 22 ilustra otra estructura de red de un subsistema IMS sobre la recuperacion del siniestro operativo en conformidad con una forma de realizacion de la presente invencion;

La Figura 23 ilustra una estructura de una unidad de obtencion de datos de recuperacion de siniestro operativo en conformidad una forma de realizacion de la presente invencion;

La Figura 24 ilustra una estructura de una unidad de obtencion de datos de recuperacion de siniestro operativo en conformidad con otra forma de realizacion de la presente invencion;

La Figura 25 ilustra una estructura de una unidad de obtencion de datos de recuperacion de siniestro operativo en conformidad con otra forma de realizacion de la presente invencion; y

La Figura 26 ilustra una estructura de una funcion S-CSCF en conformidad con una forma de realizacion de la presente invencion.

DESCRIPCION DETALLADA DE LAS FORMAS DE REALIZACION DE LA INVENCION

Los datos de usuarios requeridos por un descubrimiento de siniestro operativo deben ser objeto de copia de seguridad por anticipado. Pueden adoptarse multiples modos de copias de seguridad de datos de usuario. A modo de ejemplo, cuando un equipo UE se registra normalmente, una funcion S-CSCF que proporciona servicios para el usuario envfa los datos en copia de seguridad del usuario a una entidad de memorizacion en red tal como un servidor HSS por intermedio de un Par de Valores de Atributos (AVP) extendido: Datos en copia de seguridad de

5

10

15

20

25

30

35

40

45

50

55

60

65

usuario en una demanda de asignacion de servidor de registro (SAR). La entidad de memorizacion en red puede memorizar los datos en copia de seguridad del usuario, a modo de ejemplo, puede memorizar los datos en copia de seguridad del usuario utilizando el mdice de una IMPI. Solamente un elemento de datos en copia de seguridad necesita memorizarse para cada IMPI.

En el proceso anterior de puesta en practica de la copia de seguridad de datos del usuario, la funcion S-CSCF puede realizar una copia de seguridad de los datos asociados con el registro del usuario incluyendo, sin limitacion, una direccion de contacto e informacion de rutas. Ademas, la funcion S-CSCF puede efectuar una copia de seguridad de los datos de suscripcion del estado del registro del equipo UE incluyendo, sin limitacion, a la informacion de ID-llamada, Desde, Para, Cseq y Registro-Ruta.

A continuacion se describe un metodo de copia de seguridad de datos de usuario espedfico requerido para la recuperacion de siniestro operativo dado a conocer en formas de realizacion de la invencion con referencia a los dibujos adjuntos. En un metodo de copia de seguridad de datos de recuperacion de siniestro operativo dado a conocer en una forma de realizacion de la invencion que se ilustra en la Figura 2, una funcion S-CSCF realiza una copia de seguridad de los datos de seguridad del usuario para una entidad de memorizacion en red HSS por intermedio de un mensaje de interfaz Cx en un momento operativo adecuado. El proceso de copia de seguridad espedfico incluye las etapas siguientes:

Etapas 1-3: Una funcion S-CSCF procesa una demanda de registro de un equipo UE y acepta la demanda de registro del UE de forma ocasional.

Etapas 4-6: La funcion S-CSCF comprueba si cambian, o no, los datos de registro claves del equipo de usuario UE.

A. Si el equipo UE no ha creado informacion de registro a nivel local, se crea informacion de registro por intermedio de este registro.

B. Si el equipo UE ha creado informacion de registro a nivel local, pero cambian los datos de registros claves, a modo de ejemplo, si cambia la informacion de ruta registrada o la informacion de contacto registrada, o ambas a la vez, cambian la informacion de ruta registrada y la informacion de contacto registrada, la funcion S-CSCF necesita realizar una copia de seguridad de los datos de registro claves (informacion de Ruta e informacion de Contacto) al servidor HSS por intermedio de un mensaje SAR (REGISTRATION o RE_REGISTRATION); ademas, si estan disponibles los datos de suscripcion de registro claves (ID-Llamada, Para, Desde, Cseq y Ruta de Registro) tambien necesita efectuarse su copia de seguridad.

Si los datos no son objeto de copia de seguridad para el servidor HSS en la etapa 4, se pueden omitir las etapas 5 y 6.

Si el servidor HSS memoriza los datos de copia de seguridad del equipo UE registrado y el mensaje SAR (REGISTRATION o RE_REGISTRATION) no transmiten los datos objeto de copia de seguridad, el servidor HSS puede comprobar si la funcion S-CSCF que origina una demanda es la misma que el nombre anteriormente memorizado de una funcion S-CSCF. Si no es asf, el servidor HSS puede seleccionar la supresion de los datos de copia de seguridad memorizados. Este caso puede producirse cuando la funcion S-CSCF original objeto de fallo tiene la capacidad de enviar datos de copia de seguridad pero la nueva S-CSCF no tiene dicha capacidad.

Etapas 7 y 8: La funcion S-CSCF reenvfa un mensaje 200 OK al equipo UE.

Ademas, los datos de suscripcion de registro claves pueden ser objeto de copia de seguridad durante la suscripcion del registro. El proceso espedfico es como sigue:

Etapas 9-12: La funcion S-CSCF recibe una demanda de suscripcion de registro desde el equipo UE y acepta la demanda de suscripcion de registro y luego, reenvfa un mensaje de resultado positivo de la suscripcion al equipo UE.

Etapas 13 a 15: La funcion S-CSCF comprueba si los datos de suscripcion de registro claves del UE son objeto de cambio o no.

A. Si el equipo UE no ha creado informacion de suscripcion a nivel local, se crea informacion de suscripcion de registro por intermedio de esta suscripcion de registro.

B. Si el equipo UE ha creado informacion de suscripcion de registro a nivel local, pero cambia los datos de suscripcion de registro claves, a modo de ejemplo, si uno o mas elementos de la informacion de suscripcion de registro tal como informacion de ID-llamada, Desde, Para y Ruta-Registro cambian, la funcion S-CSCF realiza una copia de seguridad de los datos de suscripcion de registro claves anteriores para el servidor HSS por intermedio de un mensaje SAR (REGISTRATION, RE_REGISTRATION u otro valor de tipo de asignacion de servicio recientemente extendido); ademas, la funcion S-CSCF puede efectuar una copia de seguridad de los datos de

5

10

15

20

25

30

35

40

45

50

55

60

65

registro claves para el servidor HSS. En la demanda, la funcion S-CSCF puede establecer “Datos de usuarios ya disponibles” a “USER_DATA_ALREADY_AVAILABLE” para impedir que se envfen de nuevo los datos de configuracion del servicio.

Despues de que los datos de recuperacion de siniestro operativo sean objeto de copia de seguridad, la nueva funcion S-CSCF puede notificar al UE del re-registro mediante la recuperacion de los datos de suscripcion de copia de seguridad para recuperar todos los servicios de un equipo UE espedfico cuando falla o se reinicia la funcion S- CSCF original. De este modo, puede recuperarse el servicio del tipo una-IMPU multi-IMPI, una-IMPI multi-IMPU o multi-IMPI multi-IMPU y esta operacion permite al usuario tener mejores experiencias de continuidad del servicio. A modo de ejemplo, un proceso de recuperacion de servicio del UE en conformidad con una forma de realizacion de la presente invencion que se ilustra en la Figura 3 incluye las etapas siguientes:

Etapa 1: Despues de que se inicie la recuperacion del siniestro operativo, una funcion S-CSCF obtiene datos de usuarios en copia de seguridad desde un servidor HSS.

Etapa 2: La funcion S-CSCF analiza los datos de suscripcion de registro contenidos en los datos de usuarios en copia de seguridad. En conformidad con los datos de suscripcion de registro, la funcion S-CSCF envfa un mensaje NOTIFY a un equipo UE para notificar al UE el registro inmediato.

Etapa 3: El equipo UE reenvfa un mensaje 200 OK.

Etapa 4: En conformidad con la indicacion de la red, el equipo UE origina un registro inmediato para la recuperacion de los servicios de red.

En el proceso anterior, cuando la red notifica al UE el registro por intermedio del mensaje NOTIFY, en un periodo de tiempo dado, la funcion S-CSCF puede realizar una operacion de-registro de red para el equipo UE, incluyendo el de-registro de los datos relacionados en el servidor HSS si el equipo UE no origina un registro para la red.

Conviene senalar que cuando la funcion S-CSCF demanda al servidor HSS la recuperacion de los datos de configuracion de servicio y los datos en copia de seguridad de una IMPU, el servidor HSS puede reenviar los datos en copia de seguridad de multiples IMPIs porque una IMPU puede asociarse con multiples IMPIs. Los datos en copia de seguridad pueden transmitirse por intermedio de una nueva AVP Associated-Back-Info en un mensaje SAA o PPR extendido. A modo de ejemplo, anadiendo una nueva AVP denominada “Identidades asociadas-registradas” al mensaje SAA el servidor HSS reenvfa la informacion de todas las IMPIs registradas que estan asociadas con la IMPU; como alternativa, anadiendo un bit de indicador al AVP original: Identidades Asociadas, el servidor HSS reenvfa la informacion de las IMPIs registradas que estan asociadas con la IMPU.

Durante la puesta en practica real, la informacion de Associated-Back-Info puede adoptar una estructura de AVP compuesta. La estructura de AVP compuesta es como sigue:

Associated-Back-Info::= <Cabecera AVP: TBD>

{Nombre de usuario}

*{Datos-Backup-Usuario}

La estructura de AVP anterior incluye dos AVPs, esto es, Nombre de usuario y Datos-Backup-Usuario. Nombre de usuario incluye informacion de IMPI; Datos-Backup-Usuario incluye los datos en copia de seguridad de la IMPI que se incluye en Nombre de usuario. Cuando una IMPU esta asociada con multiples IMPIs, el servidor HSS puede reenviar un mensaje que transmite multiples Associated-Back-Info AVPs.

O bien, Associated-Back-Info puede definirse como un AVP que contiene informacion de texto. El modelo de datos se ilustra en la Figura 4. Cada instancia de Associated-Back-Info incluye una a n instancias de User-Back-Info. Cada instancia de User-Back-Info incluye una instancia de Nombre de usuario y al menos una instancia de Datos-Backup- Usuario. Cada instancia de Datos-Backup-Usuario incluye los datos de copia de seguridad de la IMPI que se incluye en Nombre de usuario, al menos la informacion de ruta y de contacto asociada con el registro de IMPI.

El metodo para la recuperacion del siniestro operativo se describe, a continuacion, en detalle, haciendo referencia a formas de realizacion a modo de ejemplo y a los dibujos adjuntos.

Segun se ilustra en la Figura 5, que es un diagrama de flujo principal de un metodo para la recuperacion del siniestro operativo en una forma de realizacion de la presente invencion, el proceso espedfico de recuperacion de siniestro operativo incluye las etapas siguientes:

Etapa S101: Una funcion CSCF redundante tal como una S-CSCF se inicia operativamente. Durante la puesta en practica real, cuando datos no estan disponibles despues de que la funcion CSCf que proporciona servicios para un

5

10

15

20

25

30

35

40

45

50

55

60

65

usuario tiene un fallo operativo o se reinicia, la recuperacion del siniestro operativo puede iniciarse en cada proceso de servicio. A modo de ejemplo, la funcion CSCF redundante se inicia cuando el usuario origina una llamada o registro por intermedio de un equipo UE; o bien, la funcion CSCF redundante se inicia cuando el usuario termina una llamada o cuando un AS origina una llamada en lugar del UE; ademas, la funcion CSCF redundante puede iniciarse en el proceso de servicio de mensajes cortos o en el proceso de servicio de suscripcion.

Etapa S102: La funcion CSCF redundante obtiene datos de usuarios en copia de seguridad de IMPIs registrados que estan asociadas con las IMPUs de usuario y los datos de configuracion de servicio del usuario de las IMPUs en una suscripcion de IMS desde una entidad de memorizacion en red del usuario, tal como un servidor HSS. En esta forma de realizacion, durante la recuperacion de datos de una funcion S-CSCF recientemente seleccionada o S- CSCF satisfactoriamente reiniciada, no solamente los datos de configuracion de servicio de las IMPUs y los datos de usuarios en copia de seguridad de las IMPIs que estan asociadas con esta llamada o registro, sino tambien los datos de usuarios en copia de seguridad de todas las IMPIs registradas que estan asociadas con el usuario y los datos de configuracion de servicio del usuario de las IMPIs en la suscripcion IMPUs en la suscripcion de IMS son objeto de recuperacion.

Etapa S103: La funcion S-CSCF redundante recupera un servicio correspondiente del usuario en funcion de los datos de usuarios de copia de seguridad obtenidos de IMPIs registradas y los datos de configuracion de servicios del usuario de las IMPUs en la suscripcion de IMS.

A continuacion se describe un metodo para la recuperacion del siniestro operativo con referencia a la forma de realizacion en varios escenarios operativos de aplicacion.

La Figura 6 es un diagrama de flujo de un metodo para la recuperacion de siniestro operativo en conformidad con una forma de realizacion de la presente invencion.

En la primera forma de realizacion, un servidor HSS determina si todos los datos de usuarios en una suscripcion de IMS estan completamente recuperados para una nueva funcion S-CSCF (S-CSCF2, esto es, CSCF redundante). Si no es asf, el servidor HSS envfa un mensaje PPR a la nueva funcion S-CSCF para impulsar los datos de usuarios en copia de seguridad y los datos de configuracion de servicio del usuario a la nueva funcion S-CSCF. El escenario operativo de aplicacion espedfico en donde un servicio inicia la recuperacion del siniestro operativo es como sigue: cuando la funcion S-CSCF original (S-CSCF1) en donde se registra un fallo de UE, un proceso de origen del servicio de usuario (tal como un proceso de origen de servicio de llamada) o un proceso de servicio de registro del usuario inicia la recuperacion del siniestro operativo. Mas concretamente, si la funcion S-CSCF original del equipo UE no esta disponible durante el proceso de origen de llamada, el equipo UE puede realizar un re-registro.

Segun se ilustra en la Figura 6, el equipo UE esta registrado (desde la etapa 1. REGISTER a la etapa 17. 200 OK). El proceso de registro espedfico es el mismo que el proceso estandar de iMs, en donde:

Etapa L2: En conformidad con el proceso estandar, el servidor HSS puede enviar un mensaje de Demanda de Terminacion de Registro (RTR) a la funcion S-CSCF original (S-CSCF1) del equipo UE despues de cambiar el nombre del servidor ServerName en conformidad con un mensaje de Demanda-Autenticacion-Multimedia (MAR). En la primera forma de realizacion, despues de que el servidor HSS envfe el mensaje RTR (SERVER_CHANGE) a los otros equipos UE registrados asociados que son afectados, el servidor HSS no cambia el estado del registro del UE si la funcion S-CSCF original (S-CSCF1) del equipo UE no proporciona respuesta alguna; si el servidor HSS conoce que la funcion S-CSCF (S-CSCF1) original del equipo UE tiene un fallo operativo por intermedio de un mecanismo de deteccion de fallo operativo, el servidor HSS no necesita enviar el mensaje RTR y no necesita cambiar el estado de registro del UE.

En la primera forma de realizacion, cuando se determina que falla operativamente S-CSCF1 (a modo de ejemplo, la funcion S-CSCF1 no responde al mensaje RTR o el fallo operativo de S-CSCF1 se detecta por intermedio del mecanismo de deteccion de fallos), el servidor HSS envfa un mensaje PPR (etapa 18. PPR) a la funcion S-CSCF2 con el fin de recuperar los datos de usuarios en una suscripcion de IMS. En comparacion con el mensaje PPR estandar, el mensaje PPR enviado contiene un AVP adicional: User-Backup-Data, que se utiliza para soportar datos de usuarios en copia de seguridad y dar instrucciones a la funcion S-CSCF2 para realizar una recuperacion de siniestro operativo para la informacion de usuario en el mensaje PPR.

En general, un mensaje PPR soporta solamente un perfil de usuario, que se encapsula en un AVP: User-Data; es decir, un mensaje PPR soporta solamente User-Data. Cuando multiples IMPUs que se registran por una IMPI estan en diferentes conjuntos de registro implfcitos, el servidor HSS necesita enviar un mensaje PPR que soporte datos en copia de seguridad de usuarios para diferentes conjuntos de registro implfcitos.

Para disminuir el trafico de trabajos en una interfaz Cx, una forma de realizacion de la invencion da a conocer otro modo de extension opcional para reducir la transmision repetida de datos en copia de seguridad. Es decir, en un mensaje PPR, se pueden soportar multiples AVPs denominados User-Data, y cada User-Data contiene los datos de configuracion de servicios del usuario (perfil de servicio) de todas las IMPUs en un solo conjunto de registro

5

10

15

20

25

30

35

40

45

50

55

60

65

imphcito. De este modo, los datos de usuarios en copia de seguridad de una IMPI y los perfiles de servicio de todas las IMPUs registradas asociadas con la IMPI pueden recuperarse intercambiando un mensaje PPR una vez. Los datos de configuracion de servicio del usuario determinan el tipo de un servicio de aplicacion de usuario.

Despues de recibir el mensaje PPR, la funcion S-CSCF2 memoriza los datos de usuarios en copia de seguridad y los datos de configuracion de servicio del usuario soportados en el mensaje PPR y reenvfa un mensaje de Push Profile Answer (PPA) de respuesta de perfil (etapa 19. PPA) al servidor HSS. La funcion S-CSCF2 realiza operaciones de recuperacion para el usuario en conformidad con los datos de usuario en copia de seguridad y los datos de configuracion de servicio del usuario soportados en el mensaje PPR; a modo de ejemplo, la funcion S- CSCF2 envfa un mensaje NOTIFY al equipo UE para iniciar un re-registro inmediato (etapa 20. Procesamiento de recuperacion); como alternativa, cuando esta disponible una demanda de servicio asociada con el usuario, la funcion S-CSCF2 determina el tipo del servicio de aplicacion del usuario en conformidad con los datos de configuracion de servicio del usuario y realiza una recuperacion de servicio en conformidad con los datos de usuario en copia de seguridad.

Si otras IMPUs o IMPIs registradas que son afectadas en el servidor HSS necesitan recuperarse, es preciso repetir las etapas 18 a 20 hasta que los datos de todas las IMPUs y IMPIs registradas sean recuperados (etapa 21. pPr a etapa 23. Procesamiento de recuperacion).

Conviene senalar que un escenario de aplicacion espedfico en donde un servicio inicia la recuperacion de siniestro operativo es como sigue: cuando la funcion S-CSCf original en donde se registra un equipo UE se reinicia, el procesamiento de recuperacion causado por el origen de la llamada de un usuario no objeto de migracion en la funcion S-CSCF da lugar a un re-registro del equipo UE. El proceso de recuperacion de un servicio de usuario mediante registro es similar al descrito en la primera forma de realizacion.

La Figura 7 es un diagrama de flujo de un metodo para recuperacion de siniestro operativo en conformidad con una segunda forma de realizacion de la invencion.

En la segunda forma de realizacion, un servidor HSS determina si todos los datos de usuarios en copia de seguridad en una suscripcion de IMS estan completamente recuperados para una nueva funcion S-CSCF. Si no lo estan, el servidor HSS envfa un mensaje PPR a la nueva funcion S-CSCF para impulsar los datos de usuario en copia de seguridad y los datos de configuracion de servicio hacia la nueva funcion S-CSCF. El escenario operativo de aplicacion espedfico en donde un servicio inicia una recuperacion de siniestro operativo es como sigue: la funcion S- CSCF original en donde se registra un equipo UE tiene un fallo operativo o se reinicia y la terminacion de llamada por el equipo UE o el origen de llamada por un AS, en lugar del UE, inicia la recuperacion del siniestro operativo.

Segun se ilustra en la Figura 7, el proceso espedfico de recuperacion de siniestro operativo incluye las etapas siguientes:

Etapas 1 a 5: Despues de recibir una demanda de terminacion de servicio desde un equipo UE o una demanda de origen de servicio desde un AS en lugar del UE, una funcion I-CSCF envfa un mensaje de sondeo a un servidor HSS para obtener la funcion S-CSCF actual. Si falla la funcion S-CSCF actual, la funcion I-CSCF interacciona con el servidor HSS para seleccionar otra funcion S-CSCF y a continuacion, reenvfa la demanda de servicio con un indicador de recuperacion de siniestro operativo a la nueva funcion S-CSCF; si la funcion S-CSCF actual indicada por el servidor HSS se reinicia satisfactoriamente despues de su fallo operativo, la funcion I-CSCF reenvfa la demanda de servicio a la funcion S-CSCF satisfactoriamente reiniciada.

La funcion S-CSCF (S-CSCF redundante) que recibe la demanda de servicio determina que necesita realizarse una recuperacion de siniestro operativo en conformidad con el indicador de recuperacion de siniestro operativo en la demanda de servicio recibida. Como alternativa, la demanda de servicio puede no soportar un indicador de recuperacion de siniestro operativo y cuando la funcion S-CSCF redundante encuentra que el equipo UE no esta registrado a nivel local, la funcion S-CSCF redundante envfa un mensaje SAR (UNREGISTERED_USER) al servidor HSS. Despues de recibir el mensaje, el servidor HSS encuentra que el equipo UE esta en el estado noUNREGISTERED y luego, reenvfa un mensaje SAA (DIAMETER_ERROR_IN_ASSIGNMENT_TYPE). La funcion S- CSCF redundante puede realizar la recuperacion de siniestro operativo despues de recibir el mensaje DIAMETER_ERROR_IN_ASSIGNMENT_TYPE.

Etapas 6 a 7: El servidor HSS puede determinar que la funcion S-CSCF redundante necesita recuperar datos de usuarios en conformidad con la demanda de restablecimiento RESTORE originada por la funcion S-CSCF redundante en la etapa 3 y luego, enviar un mensaje PPR para recuperar datos de usuario (lo que es similar a las etapas 18 y 9 en la primera forma de realizacion).

Cuando el AS origina una llamada en lugar del UE, la llamada puede alcanzar a la funcion S-CSCF sin pasar a traves de la funcion I-CSCF y la recuperacion del siniestro operativo puede realizarse en dos casos.

(1) Si la funcion S-CSCF obtenida desde el servidor HSS no puede ser objeto de contacto, el AS puede enrutar una

5

10

15

20

25

30

35

40

45

50

55

60

65

sesion a la funcion I-CSCF para un enrutamiento posterior. El proceso de recuperacion de siniestro operativo es el mismo que se describio con anterioridad.

(2) Si la funcion S-CSCF obtenida desde el servidor HSS puede ser objeto de contacto, pero la funcion S-CSCF se reinicia, pueden perderse los datos de usuarios. La funcion S-CSCF determina que necesitan recuperarse datos de usuarios desde el servidor HSS en conformidad con la logica de un escenario operativo de reinicio. Para otras etapas del procesamiento, veanse las etapas 6 y 7.

La Figura 8 es un diagrama de flujo de un metodo para recuperacion de siniestro operativo en conformidad con una tercera forma de realizacion de la invencion.

En la tercera forma de realizacion, una funcion S-CSCF determina que necesita realizarse una recuperacion de siniestro operativo; el modo de originar una demanda de datos de usuarios para un servidor HSS varias veces puede adoptarse para recuperar los datos de usuarios en una suscripcion de IMS; y el mdice de la demanda originada es una IMPI. Un escenario operativo de aplicacion espedfico en donde un servicio inicia una recuperacion de siniestro operativo es como sigue: la funcion S-CSCF original (S-CSCF1) en donde se registra un equipo UE tiene un fallo operativo, y el origen de llamada por el UE o el registro del UE inicia una recuperacion de siniestro operativo; si la funcion S-CSCF original no esta disponible cuando el UE origina una llamada, el equipo UE realiza un re-registro.

Segun se ilustra en la Figura 8, el proceso espedfico de recuperacion de siniestro operativo incluye las etapas siguientes:

Etapas 1 a 6: Un equipo UE se registra en un proceso de conmutacion desde S-CSCF1 a S-CSCF2 (S-CSCF redundante).

Etapa L1: Esta etapa es la misma que la etapa L2 en la primera forma de realizacion. Si un servidor HSS no detecta que falla la funcion S-CSCF1, el servidor HSS envfa un mensaje RTR; si el servidor HSS no recibe un mensaje RTA, el servidor HSS no cambia el estado de registro del UE.

Etapas 7 a 9: El equipo UE origina una demanda de registro; una funcion I-CSCF envfa una demanda de registro a la funcion S-CSCF2 intercambiando un mensaje UAR o UAA con el servidor HSS; y la funcion S-CSCF2 envfa un mensaje SAR al servidor HSS despues de la autenticacion del UE.

Etapa 10: El servidor HSS envfa un mensaje SAA a la funcion S-CSCF2, que transmite la informacion de todas las IMPIs registradas en una suscripcion de IMS ademas de las Identidades-Asociadas (todas las IMPIs en las suscripcion de IMS); en la tercera forma de realizacion, la informacion de las IMPIs registradas puede reenviarse anadiendo AVP: Identidades-Asociadas-Registradas o anadiendo un bit de indicador al AVP: Identidades-Asociadas original.

Etapas 11 a 12: La funcion S-CSCF reenvfa un mensaje 200 OK al equipo UE despues de recibir el mensaje SAA.

Etapa 13: Despues de obtener la lista de IMPIs registradas, la funcion S-CSCF2 comprueba los equipos UEs registrados al nivel local en la suscripcion de IMS. Si los equipos UEs registrados indicados en la informacion de usuario de IMPI registrada que se proporciona por el servidor HSS no estan registrados en la S-CSCF2, la funcion S-CSCF2 puede enviar una Demanda de Restablecimiento de Servicio (SRR) o un mensaje SAR que transmite informacion de indicacion de recuperacion de siniestro operativo al servidor HSS. El mensaje SRR o SAR soporta una IMPI que no esta registrada en la listas de IMPIs registradas con el fin de demandar al servidor hSs la recuperacion de datos de usuarios en copia de seguridad de la IMPI.

Etapa 14: Despues de recibir la demanda de recuperacion de los datos de usuarios de la IMPI no registrada en la lista de IMPIs registradas, el servidor HSS reenvfa una respuesta que soporta los datos de usuarios en copia de seguridad de la IMPI y los datos de configuracion de servicio de usuario de la IMPU asociada con la IMPI.

En la tercera forma de realizacion, el mensaje SAR o SAA puede extenderse de modo que pueda transmitir multiples AVPs User-Data, con lo que reenvfa los datos de configuracion de servicio del usuario de las IMPUs que estan asociadas con una IMPI pero que pertenecen a diferentes conjuntos de registro implfcitos.

Despues de que la funcion S-CSCF reciba la respuesta, la S-CSCF realiza las operaciones de recuperacion en conformidad con los datos en copia de seguridad contenidos en la respuesta.

Etapas 15 a 16: Si la lista de IMPIs registradas reenviada en la etapa 10 contiene multiples IMPIs, las operaciones de recuperacion en las etapas 13 y 14 pueden realizarse para cada IMPI.

La Figura 9 es un diagrama de flujo de un metodo para la recuperacion de siniestro operativo en conformidad con una cuarta forma de realizacion de la invencion.

5

10

15

20

25

30

35

40

45

50

55

60

65

En la cuarta forma de realizacion, una funcion S-CSCF determina necesita realizarse una recuperacion de siniestro operativo; el modo de originar una demanda de datos de usuarios para un servidor HSS varias veces puede adoptarse para recuperar los datos de usuarios en una suscripcion de IMS; y el mdice de la demanda originada es una IMPI. Un escenario de aplicacion espedfico en donde un servicio inicia una recuperacion de siniestro operativo es como sigue: la funcion S-CSCF se reinicia, y el origen de llamada por un UE o el registro del equipo UE inicia la recuperacion del siniestro operativo; si se reinicia la funcion S-CSCF y no estan disponibles los datos de usuarios del origen de la llamada cuando el UE origina una llamada, el equipo UE realiza una operacion de re-registro.

Segun se ilustra en la Figura 9, el proceso espedfico de recuperacion de siniestro operativo incluye las etapas siguientes:

Etapas 1 a 11: Un equipo UE origina una demanda de registro despues de que se reinicie satisfactoriamente una funcion S-CSCF; una funcion I-CSCF envfa una demanda de registro a la funcion S-CSCF reiniciada intercambiando un mensaje UAR o UAA con un servidor HSS; y la funcion S-CSCF envfa un mensaje SAR al servidor HSS despues de la autenticacion del equipo UE.

Etapas 12 a 18: Estas etapas son las mismas que las etapas 10 a 16 en la tercera forma de realizacion. La funcion S-CSCF reiniciada puede recuperar completamente todos los datos de usuarios en una suscripcion de IMS.

La Figura 10 es un diagrama de flujo de un metodo para recuperacion de siniestro operativo en conformidad con una quinta forma de realizacion de la invencion.

En la quinta forma de realizacion, una funcion S-CSCF determina que necesita realizarse una recuperacion de siniestro operativo; el modo de originar una demanda de datos de usuarios a un servidor HSS varias veces puede adoptarse para recuperar los datos de usuario en una suscripcion de IMS; y el mdice de la demanda originada es una IMPI. Un escenario de aplicacion espedfico en donde un servicio inicia una recuperacion de siniestro operativo es como sigue: la funcion S-CSCF tiene un fallo operativo o se reinicia y la terminacion de llamada por el UE o el origen de llamada por un AS en lugar del equipo UE por intermedio de una funcion I-CSCF inicia una recuperacion de siniestro operativo.

Segun se ilustra en la Figura 10, el proceso espedfico de recuperacion de siniestro operativo incluye las etapas siguientes:

Etapas 1 a 3: Despues de recibir una demanda de terminacion de servicio desde un equipo UE o una demanda de origen de servicio desde un AS en lugar del UE, una funcion I-CSCF envfa un mensaje de sondeo a un servidor HSS para obtener la funcion S-CSCF actual. Si falla la funcion S-CSCF actual, la funcion I-CSCF interacciona con el servidor HSS para seleccionar otra funcion S-CSCF y luego, reenvfa la demanda de servicio con un indicador de recuperacion de siniestro operativo a la nueva funcion S-CSCF; si la funcion S-CSCF actual indicada por el servidor HSS se reinicia satisfactoriamente despues de su fallo operativo, la funcion I-CSCF reenvfa la demanda de servicio a la funcion S-CSCF reinicia de forma satisfactoria.

La funcion S-CSCF que recibe la demanda de servicio determina que necesita realizarse una recuperacion de siniestro operativo en conformidad con el indicador de recuperacion de siniestro operativo en la demanda de servicio recibida. Como alternativa, la demanda de servicio puede no incluir un indicador de recuperacion de siniestro operativo y cuando la funcion S-CSCF encuentra que el equipo UE no esta registrado a nivel local, la S-CSCF envfa un mensaje SAR (UNREGISTERED_USER) al servidor HSS. Despues de recibir el mensaje, el servidor HSS encuentra que el equipo UE esta en el estado no-UNREGISTERED y luego, reenvfa un mensaje SAA (DIAMETER_ERROR_IN_ASSIGNMENT_TYPE). La funcion S-CSCF puede realizar una recuperacion de siniestro operativo despues de recibir el mensaje (DIAMeTeR_ERROR_IN_ASSIGNMENT_TYPE).

Etapa 4: En la respuesta de recuperacion de siniestro operativo desde el servidor HSS, ademas del perfil de servicio de la IMPU o los perfiles de servicio de todas las IMPUs en el conjunto de registro implfcito de la IMPU, y los datos de usuarios en copia de seguridad de las IMPIs, necesita reenviarse la informacion de la IMPIs registradas en una suscripcion de IMS. En la quinta forma de realizacion, a modo de ejemplo, puede anadirse AVP: Identidades- Asociadas-Registradas a la respuesta de recuperacion para transmitir la informacion de las IMPIs registradas.

Etapas 6 a 9: Estas etapas son las mismas que las etapas 13 a 16 (procesamiento de recuperacion) en la tercera forma de realizacion.

Cuando el AS origina una llamada en lugar del UE, la llamada puede alcanzar a la funcion S-CSCF sin pasar a traves de la funcion I-CSCF y la recuperacion de siniestro operativo puede realizarse en dos casos.

(1) Si la funcion S-CSCF obtenida desde el servidor HSS no puede ser objeto de contacto, el servidor AS puede enrutar una sesion a la funcion I-CSCF para su enrutamiento posterior. El proceso de recuperacion de siniestro operativo posterior es el mismo que se describio con anterioridad.

5

10

15

20

25

30

35

40

45

50

55

60

65

(2) Si la funcion S-CSCF obtenida desde el servidor HSS puede ser objeto de contacto, pero se reinicia la S-CSCF, pueden perderse datos de usuarios. La funcion S-CSCF determina que necesita recuperarse datos de usuarios desde el HSS en conformidad con la logica de un escenario de reinicio operativo. Para otras etapas del procesamiento, vease la etapa 3 y etapas posteriores.

Ademas, una demanda de recuperacion de siniestro operativo puede originarse con el mdice de una IMPU, en conformidad con el metodo para recuperacion de siniestro operativo segun una sexta forma de realizacion de la invencion que se ilustra en la Figura 11.

En la sexta forma de realizacion, una funcion S-CSCF determina que necesita realizarse una recuperacion de siniestro operativo, el modo de originar una demanda de datos de usuarios de recuperacion de siniestro operativo para un servidor HSS varias veces puede adoptarse para recuperar los datos de usuario en una suscripcion de IMS y el mdice de la demanda originada es una IMPU. La sexta forma de realizacion puede ser aplicable a varios procesos de iniciacion de servicios, tal como un proceso de iniciacion de servicio llamante o llamado originado por un equipo UE o un proceso de iniciacion de recuperacion llamante originado por un AS en lugar del equipo UE. Los procesos de iniciacion de servicios no se describen aqrn en detalle. Solamente se describe el metodo para recuperar completamente datos de suscripcion de IMS.

Segun se ilustra en la Figura 11, el proceso de recuperacion completa de datos de suscripcion de IMS incluye las etapas siguientes:

Etapa 1: Una funcion S-CSCF redundante envfa un mensaje SRR o SAR a un servidor HSS.

Etapa 2: El servidor HSS reenvfa un mensaje SAR o SAA, que soporta los datos en copia de seguridad de todas las IMPIs registradas que estan directamente asociadas con la IMPU transmitida en el mensaje SRR o SAR; por intermedio de AVP: User-Data, el servidor HSS reenvfa los datos de configuracion de servicio del usuario de todas las IMPUs en el UE o un conjunto de registro implfcito de la IMPU. Ademas, el servidor HSS reenvfa la lista de otras IMPUs registradas en una suscripcion de IMS.

Etapa 3: La funcion S-CSCF recupera los datos de usuario transmitidos en el mensaje SRA o SAA. Despues de obtener la lista de IMPUs registradas, la funcion S-CSCF recupera los datos completos de las IMPUs, uno por uno, por intermedio del Tipo-Asignacion-Servidor en el mensaje SAR extendido; a modo de ejemplo, la funcion S-CSCF anade un nuevo tipo de operacion (RESTORE_ONE) al mensaje SAR con el fin de demandar al servidor HSS la recuperacion de los datos completos de las IMPUs uno por uno.

Etapa 4: Despues de recibir el mensaje SAR del tipo RESTORE_ONE, el servidor HSS reenvfa los datos en copia de seguridad (Datos-Backup-Usuario) de todas las IMPIs registradas que estan directamente asociadas con la IMPU transmitida en el mensaje SAR. Por intermedio de la AVP User-Data, el servidor HSS reenvfa el perfil de usuario del UE de la IMPU o el UE en el conjunto de registro implfcito de la IMPU. La funcion S-CSCF recupera los datos de usuario en conformidad con los datos.

Si la lista de IMPU reenviada en la etapa 2 contiene multiples IMPUs, las operaciones de recuperacion en las etapas 3 y 4 se realizan para cada IMPU.

La Figura 12 es un diagrama de flujo de un metodo para recuperacion de siniestro operativo en conformidad con una septima forma de realizacion de la invencion.

La septima forma de realizacion es diferente de las formas de realizacion anteriores. En esta forma de realizacion, la funcion S-CSCF recupera todos los datos de usuarios en copia de seguridad en una suscripcion de IMS por intermedio de una recuperacion de siniestro operativo de una sola vez. La septima forma de realizacion puede ser aplicable a varios procesos de iniciacion operativa del servicio. Los procesos de iniciacion operativa del servicio no se describen aqrn en detalle.

Segun se ilustra en la Figura 12, el proceso de recuperacion de todos los datos de usuarios en copia de seguridad en una suscripcion de IMS por intermedio de una recuperacion de siniestro operativo de una sola vez puede realizarse mediante las etapas siguientes:

Etapa 1: Una funcion S-CSCF envfa un mensaje SRR o SAR a un servidor HSS.

Etapa 2: El servidor HSS realiza un sondeo de las instancias de registro de la totalidad de IMPIs y de IMPUs en una suscripcion de IMS de la IMPU transmitida en el mensaje SRR o SAR y luego, reenvfa todos los datos de usuarios en copia de seguridad y los datos de configuracion de servicio del usuario en las instancias de registro a la funcion S-CSCF por intermedio de un mensaje SRA o SAA.

En esta forma de realizacion, el mensaje SRA o SAA necesita extenderse para soportar multiples AVPs con el nombre de User-Data. Los contenidos encapsulados en cada User-Data cumplen la norma especificada y los

5

10

15

20

25

30

35

40

45

50

55

60

65

contenidos incluyen la Identidad Privada, las IMPUs en el conjunto de registro impUcito relacionado y los perfiles de servicio de estas IMPUs.

La Figura 13 es un diagrama de flujo de un metodo para recuperacion de siniestro operativo en conformidad con una octava forma de realizacion de la invencion.

La octava forma de realizacion es diferente de las primera a sexta formas de realizacion. En la octava forma de realizacion, la funcion S-CSCF recupera todos los datos en una suscripcion de IMS por intermedio de una recuperacion de siniestro operativo de una sola vez y el servidor HSS recupera todos los datos de usuarios en copia de seguridad en una suscripcion de IMS por intermedio de un mensaje PPR o PPA. La octava forma de realizacion puede ser aplicable a varios procesos de iniciacion operativa de servicio. Los procesos de iniciacion operativa del servicio no se describen aqu en detalle.

Segun se ilustra en la Figura 13, el proceso de recuperacion de todos los datos de usuarios en copia de seguridad en una suscripcion de IMS por intermedio de una recuperacion de siniestro operativo de una sola vez puede realizarse mediante las etapas siguientes:

Etapa 1: Una funcion S-CSCF interacciona con un servidor HSS por intermedio de un mensaje MAR o MAA, SRR o SRA o SAR o SAA.

Etapa 2: El servidor HSS puede cambiar el nombre de servidor ServerName intercambiando un mensaje MAR o MAA y determinar que falla la funcion S-CSCF original (a modo de ejemplo, no se reenvfa ninguna respuesta cuando se envfa un mensaje RTR). A continuacion, el servidor HSS envfa todos los datos de usuarios en copia de seguridad y datos de configuracion de servicio de usuario en una suscripcion de IMS de la IMPU afectada a una funcion S- CSCF redundante por intermedio de un mensaje PPR.

Como alternativa, el servidor HSS puede conocer que el escenario operativo actual es un escenario operativo de recuperacion de siniestro operativo intercambiando un mensaje SRR o SRA o SAR o SAA. A continuacion, el servidor HSS envfa todos los datos de usuarios en copia de seguridad y los datos de configuracion de servicio en la suscripcion de IMS de la IMPU afectada a la funcion S-CSCF redundante por intermedio de un mensaje PPR.

Conviene senalar que en el proceso de puesta en practica anterior, el mensaje PPR necesita extenderse para soportar multiples AVPs con el nombre de User-Data. Los contenidos encapsulados en cada User-Data cumplen la norma especificada y los contenidos incluyen la Identidad Privada, las IMPUs relacionadas en el conjunto de registro implfcito y los perfiles de servicio de estas IMPUs.

Por lo tanto, en la primera a octava forma de realizacion, cuando se adopta el metodo para recuperacion de los datos de usuarios en copia de seguridad y los datos de servicio de usuario en una suscripcion de IMS en una sola vez, los datos de configuracion de servicio del usuario de otras IMPUs registradas y los datos de usuarios en copia de seguridad de las IMPIs del usuario no cubiertas en esta iniciacion de servicio se recuperan a su debido tiempo. De este modo, se puede recuperar el servicio de una-IMPU multi-IMPI, una IMPI multi-IMPU o multi-IMPI multi-IMPU y esta operacion permite al usuario tener mejores experiencias de continuidad de servicio.

La Figura 14 es un diagrama de flujo de un metodo para la recuperacion de siniestro operativo en conformidad con una novena forma de realizacion de la invencion.

En la novena forma de realizacion, una funcion S-CSCF determina que necesita realizarse una recuperacion de siniestro operativo; los datos de servicio de una IMPU, los datos de servicio de las IMPUs en el conjunto de registro implfcito de la IMPU y los datos en copia de seguridad de todas las IMPIs registradas que estan asociadas con la IMPU se recuperan de una sola vez. Un escenario de aplicacion espedfico en donde un servicio inicia una recuperacion de siniestro operativo es como sigue: la funcion S-CSCF tiene un fallo operativo y el origen de llamada por un equipo UE o el registro del UE inicia la recuperacion del siniestro operativo; si la funcion S-CSCF original no esta disponible cuando el equipo UE origina una llamada, el equipo UE realiza una operacion de re-registro.

Segun se ilustra en la Figura 14, el proceso espedfico de recuperacion de siniestro operativo incluye las etapas siguientes:

Etapas 1 a 6: Un equipo UE se registra en un proceso de conmutacion desde la funcion S-CSCF1 a una nueva S- CSCF (S-CSCF2).

Etapa L1: Esta etapa es la misma que la etapa L2 en la primera forma de realizacion. Si un servidor HSS no detecta que la funcion S-CSCF original falla (S-CSCF1) en donde esta registrado el UE, el servidor HSS envfa un mensaje RTR a la funcion S-CSCF original del equipo UE; si el servidor HSS no recibe un mensaje RTA, el HSS no cambia el estado del registro del equipo de usuario UE.

Etapas 7 a 9: El equipo UE origina una demanda de registro; una funcion I-CSCF envfa una demanda de registro a

5

10

15

20

25

30

35

40

45

50

55

60

65

la funcion S-CSCF2 intercambiando un mensaje UAR o UAA con el servidor HSS y la funcion S-CSCF2 origina un mensaje SAR para el servidor HSS despues de la autenticacion del equipo de usuario UE.

Etapa 10: El servidor HSS reenvfa un mensaje SAA a la funcion S-CSCF2, transmitiendo la informacion de las IMPIs registradas que estan directamente asociadas con la IMPU transmitida en el mensaje SAR. Si ninguna de las IMPIs registradas esta asociada con la IMPU con la excepcion de las IMPIs controvertidas en el mensaje SAR, el servidor HSS no necesita reenviar la informacion de las IMPIs registradas. En la novena forma de realizacion, la informacion de las IMPIs registradas que estan asociadas con la IMPU puede reenviarse anadiendo un parametro AVP: Identidades-Asociadas-Registradas o anadiendo un bit de indicador al AVP: Identidades-Asociadas original.

Si el servidor HSS no reenvfa la informacion de las IMPIs registradas que estan asociadas con la IMPU, no se requiere realizar la etapa 13 y posteriores.

Etapa 13: Despues de obtener una lista de IMPIs registradas, la funcion S-CSCF2 comprueba las IMPIs registradas que estan asociadas con la IMPU a nivel local. Si las IMPIs registradas proporcionadas por el servidor HSS no estan registradas en la funcion S-CSCF2, la funcion S-CSCF2 puede enviar un mensaje SRR o SAR que transmite informacion de indicacion de recuperacion de siniestro operativo al servidor HSS. El mensaje SRR o SAR transmite la IMPU de la demanda de registro con el fin de demandar al HSS la recuperacion de los datos de usuarios en copia de seguridad de la IMPU. Los datos de configuracion de servicio de la IMPU pueden ser tambien objeto de demanda. Si los datos de configuracion de servicio de usuarios (perfil de usuario) estan ya reenviados en el mensaje SAA, el parametro User-Data-Already-Available puede establecerse a “USER_DATA_ALREADY_AVAILABLE” de modo que el servidor HSS no envfe de nuevo el perfil de servicio, pero se siguen enviando los datos de usuarios en copia de seguridad.

Etapa 14: Despues de recibir la demanda de recuperacion de los datos de usuarios de la IMPU, el servidor HSS reenvfa los datos de usuarios en copia de seguridad de todas las IMPIs asociadas con la IMPU o los datos de usuarios en copia de seguridad de todas las IMPIs en el conjunto de registro implfcito de la IMPU y el perfil de servicio de la IMPU o los perfiles de servicio de todas las IMPUs en el conjunto de registro implfcito de la IMPu. Si la funcion S-CSCF establece User-Data-Already-Available a “USER_DATA_ALREADY_AVAIlAbLE”, el servidor HSS no puede reenviar el perfil de servicio.

Despues de recibir la respuesta, la funcion S-CSCF2 realiza operaciones de recuperacion en conformidad con los datos en copia de seguridad contenidos en la respuesta.

La Figura 15 es un diagrama de flujo de un metodo para la recuperacion de siniestro operativo en conformidad con una decima forma de realizacion de la invencion.

En la decima forma de realizacion, una funcion S-CSCF determina que necesita realizarse una recuperacion de siniestro operativo; los datos de servicio de una IMPU, los datos de servicio de IMPUs en el conjunto de registro implfcito de la IMPU y los datos en copia de seguridad de todas las IMPIs registradas que estan asociadas con la IMPU se recuperan de una sola vez. Un escenario de aplicacion espedfico en donde un servicio inicia una recuperacion de siniestro operativo es como sigue: se reinicia la funcion S-CSCF y un origen de llamada por un equipo UE o un registro del UE inicia la recuperacion del siniestro operativo; si la funcion S-CSCF se reinicia y los datos de usuarios del origen de la llamada no estan disponibles cuando el equipo UE origina una llamada, el equipo UE realiza una operacion de re-registro.

Segun se ilustra en la Figura 15, el proceso espedfico de recuperacion de siniestro operativo incluye las etapas siguientes:

Etapas 1 a 11: Un equipo UE origina una demanda de registro despues de que se reinicie satisfactoriamente una funcion S-CSCF; una funcion I-CSCF envfa una demanda de registro a la funcion S-CSCF reiniciada intercambiando un mensaje UAR o UAA con un servidor HSS; y la funcion S-CSCF origina un mensaje SAR para el servidor HSS despues de la autenticacion del equipo UE.

Etapas 12 a 16: Estas etapas son las mismas que las etapas 10 a 14 en la novena forma de realizacion. La funcion S-CSCF reiniciada puede recuperar completamente todos los datos de registro y todos los datos de servicio de una IMPU y de las IMPUs en el conjunto de registro implfcito de la IMPU en una sola operacion.

La Figura 16 es un diagrama de flujo de un metodo para la recuperacion de siniestro operativo en conformidad con una undecima forma de realizacion de la invencion.

En la undecima forma de realizacion, una funcion S-CSCF determina que necesita realizarse una recuperacion de siniestro operativo; los datos de servicio de una IMPU, los datos de servicio de IMPUs en el conjunto de registro implfcito de la IMPU y los datos de registro de todas las IMPIs registradas que estan asociadas con la IMPU se recuperan de una sola vez. Un escenario de aplicacion espedfico en donde un servicio inicia una recuperacion de siniestro operativo es como sigue: la funcion S-CSCF tiene un fallo operativo o se reinicia y la terminacion de

5

10

15

20

25

30

35

40

45

50

55

60

65

llamada por un equipo UE o el origen de llamada por un AS en lugar del equipo UE, por intermedio de una funcion I- CSCF, inicia una recuperacion de siniestro operativo.

Segun se ilustra en la Figura 16, el proceso espedfico de recuperacion de siniestro operativo incluye las etapas siguientes:

Etapas 1 a 3: Una funcion I-CSCF recibe una demanda de terminacion de servicio procedente de un equipo UE o una demanda de origen de servicio desde un AS en lugar del UE y luego origina un mensaje de sondeo para un servidor HSS con el fin de obtener la funcion S-CSCF actual. Si falla la S-CSCF actual, la funcion I-CSCF interacciona con el servidor HSS para seleccionar otra funcion S-CSCF y luego, reenvfa la demanda de servicio con un indicador de recuperacion de siniestro operativo a la nueva funcion S-CSCF; si la funcion S-CSCF actual indicada por el servidor HSS se reinicia satisfactoriamente despues de su fallo operativo, la funcion I-CSCF reenvfa la demanda de servicio a la funcion S-CSCF reiniciada de forma satisfactoria.

La funcion S-CSCF que recibe la demanda de servicio determina que necesita realizarse una recuperacion de siniestro operativo en conformidad con el indicador de recuperacion de siniestro operativo contenido en la demanda de servicio recibida. Como alternativa, la demanda de servicio puede no incluir un indicador de recuperacion de siniestro operativo y cuando la funcion S-CSCF encuentra que el equipo UE no esta registrado a nivel local, la funcion S-CSCF origina una demanda SAR (UNREGISTEReD_USEr) para el servidor HSS. Despues de recibir la demanda, el servidor HSS encuentra que el equipo UE esta en el estado registrado REGISTERED y luego, reenvfa un mensaje SAA (DIAMETERjERROR_IN_aSsIGNMENTjTYPE). La funcion S-CSCF puede realizar una recuperacion de siniestro operativo despues de recibir el mensaje SAA (DIAMETERjERRORjINjASSIGNMENTjTYPE).

Etapa 4: En el mensaje SAA, el servidor HSS reenvfa el perfil de servicio de la IMPU o los perfiles de servicio de todas las IMPUs en el conjunto de registro implfcito de la IMPU y los datos de usuario en copia de seguridad de todas las IMPIs asociadas con la IMPU o los datos de usuario en copia de seguridad de todas las IMPIs en el conjunto de registro implfcito de la IMPU. El servidor HSS puede reenviar un mensaje SAA que soporte el perfil de usuario de la IMPU o los perfiles de usuario de toda las IMPUs en el conjunto de registro implfcito de la IMPu y los datos de usuarios en copia de seguridad de toda las IMPIs asociadas con la IMPU o los datos de usuarios en copia de seguridad de todas las IMPIs asociadas con todas las IMPUs en el conjunto de registro implfcito de la IMPU asf como DIAMETERjERRORjINjASSIGNMENTjTYPE descrito en la etapa 3 para la funcion S-CSCF.

Despues de recibir la respuesta, la funcion S-CSCF realiza operaciones de recuperacion en conformidad con los datos en copia de seguridad contenidos en la respuesta.

Cuando el AS origina una llamada en lugar del equipo UE, la llamada puede alcanzar la funcion S-CSCF sin pasar a traves de la funcion I-CSCF y puede realizarse la recuperacion del siniestro operativo en dos casos.

(1) Si la funcion S-CSCF obtenida desde el servidor HSS no puede ser objeto de contacto, el AS puede enrutar una sesion a la I-CSCF para su enrutamiento posterior. El proceso de recuperacion de siniestro operativo posterior es el mismo que se describio con anterioridad.

(2) Si la funcion S-CSCF obtenida desde el servidor HSS puede ser objeto de contacto, pero se reinicia la funcion S- CSCF, pueden perderse datos de usuarios. La funcion S-CSCF determina que necesitan recuperarse datos de usuarios desde el servidor HSS en conformidad con la logica de un escenario de reinicio operativo. Para otras etapas del procesamiento, vease la etapa 3 y etapas posteriores.

Por lo tanto, en las novena a undecima formas de realizacion, los datos de usuarios en copia de seguridad y los datos de servicio del usuario que estan asociados con una IMPU afectada se recuperan completamente en cada operacion de iniciacion de servicio. Los datos de servicio de usuarios completo y los datos de usuarios en copia de seguridad pueden obtenerse en cada operacion de iniciacion de servicio y se puede recuperar tambien el servicio de tipo una iMpU multi-IMPI, una IMPI multi-IMPU o multi-IMPI multi-IMPU. De este modo, el usuario tiene mejores experiencias de continuidad del servicio.

Para poner en practica los metodos de procesamiento anteriores dados a conocer en formas de realizacion de la invencion, el sistema de red existente y las funciones de dispositivos necesitan extenderse en consecuencia.

La Figura 17 ilustra una estructura de red de un subsistema IMS en relacion con la recuperacion de siniestro operativo en conformidad con una forma de realizacion de la invencion.

En esta forma de realizacion, un subsistema IMS incluye una funcion CSCF 1, tal como una S-CSCF, y una entidad de memorizacion en red 2, tal como un servidor HSS. La entidad de memorizacion en red 2 incluye una unidad de memorizacion de datos de usuarios 21 y una unidad de procesamiento de recuperacion de siniestro operativo 22.

La unidad de memorizacion de datos de usuario 21 esta adaptada para memorizar datos de configuracion de

5

10

15

20

25

30

35

40

45

50

55

60

65

servicio de usuarios, datos de usuarios en copia de seguridad para recuperacion de servicios de usuarios e informacion de una funcion CSCF en donde esta registrado un usuario.

La unidad de procesamiento de recuperacion de siniestro operativo 22 esta adaptada para realizar una recuperacion de siniestro operativo. Una estructura espedfica de la unidad de procesamiento de recuperacion de siniestro operativo se ilustra en la Figura 18. Mas concretamente, la unidad de procesamiento de recuperacion de siniestro operativo incluye una unidad de determinacion 221 y una unidad de transmision de datos 222.

La unidad de determinacion 221 esta adaptada para determinar si realizar, o no, una recuperacion de siniestro operativo para una funcion CSCF. Durante la puesta en practica espedfica, la unidad de determinacion 221 puede adoptar varias estructuras. A modo de ejemplo, una estructura espedfica de la unidad de determinacion 221 ilustrada en la Figura 19 incluye:

una unidad de analisis sintactico 2211a, adaptada para analizar un mensaje SAR que transmite una indicacion de recuperacion que se envfa por una funcion CSCF con el fin de determinar si el mensaje SAR transmite, o no, informacion de indicacion de recuperacion; y

una unidad de determinacion 2212a, en conformidad con el resultado del analisis sintactico de la unidad de analisis sintactico 2211a, adaptada para determinar que necesita realizarse una recuperacion de siniestro operativo para una funcion CSCF si el mensaje SAR transmite informacion de indicacion de recuperacion.

Ademas, otra estructura espedfica de la unidad de determinacion 221 ilustrada en la Figura 20 incluye:

una unidad de deteccion 2211b, adaptada para detectar si una funcion CSCF en donde esta registrado un usuario cambia o no y si una unidad de memorizacion en red del usuario recibe un mensaje RTA reenviado por la funcion CSCF despues de enviar un mensaje RTR a la CSCF original en donde esta registrado el usuario; y

una unidad de determinacion 2212b, adaptada para determinar que necesita realizarse una recuperacion de siniestro operativo para la funcion CSCF si el resultado de la deteccion de la unidad de deteccion 2211b indica que cambia la funcion CSCF en donde esta registrado el usuario y que la entidad de memorizacion en red del usuario no recibe el mensaje RTA reenviado por la funcion CSCF.

Ademas, otra estructura espedfica de la unidad de determinacion 221 ilustrada en la Figura 21 incluye:

una unidad de deteccion 2211c, adaptada para detectar si cambia una funcion CSCF en donde esta registrado un usuario y si falla la funcion CSCF original en donde esta registrado el usuario; y

una unidad de determinacion 2212c, adaptada para determinar que necesita realizarse una recuperacion de siniestro operativo para la funcion CSCF si el resultado de la deteccion de la unidad de deteccion 2211c indica que cambia la funcion CSCF en donde esta registrado el usuario y que la funcion CSCF original en donde esta registrado el usuario tiene un fallo operativo.

La unidad de transmision de datos 222 esta adaptada para transmitir los datos de usuario en copia de seguridad de las IMPIs registradas que estan asociadas con el usuario y los datos de configuracion de servicio del usuario de las IMPUs en una suscripcion de IMS para una funcion CSCF redundante interaccionando con la CSCF redundante una vez o muchas veces si el resultado de la determinacion de la unidad de determinacion 221 es afirmativo.

La Figura 22 ilustra otra estructura de red de un subsistema IMS con respecto a la recuperacion de siniestro operativo en una forma de realizacion de la invencion.

En esta forma de realizacion, un subsistema IMS incluye una funcion CSCF 1, tal como una S-CSCF y una unidad de memorizacion en red 2, tal como un servidor HSS. La unidad de memorizacion en red 1 incluye una unidad de obtencion de datos de recuperacion de siniestro operativo 11 y una unidad de procesamiento de recuperacion de siniestro operativo 12.

La unidad de obtencion de datos de recuperacion de siniestro operativo 11 esta adaptada para obtener datos de usuario en copia de seguridad de las IMPIs registradas que estan asociadas con la IMpUs de usuario y los datos de configuracion de servicio del usuario de las IMPUs en una suscripcion de IMS desde una entidad de memorizacion en red del usuario en conformidad con la informacion de las IMPIs o IMPUs registradas que se transmite en una respuesta reenviada por la entidad de memorizacion en red despues de que un servicio inicie una recuperacion de siniestro operativo.

La unidad de procesamiento de recuperacion de siniestro operativo 12 esta adaptada para recuperar el servicio correspondiente en conformidad con los datos de usuario en copia de seguridad de las IMPIs registradas y los datos de configuracion de servicio del usuario de las IMPUs en la suscripcion de IMS que se obtienen por la unidad de obtencion de datos de recuperacion de siniestro operativo 11.

5

10

15

20

25

30

35

40

45

50

55

60

65

En una estructura espedfica de la unidad de obtencion de datos de recuperacion de siniestro operativo 11 de la invencion que se ilustra en la Figura 23, la unidad de obtencion de datos de recuperacion de siniestro operativo 11 puede incluir:

una unidad de analisis sintactico 111a, adaptada para analizar la informacion de las IMPIs registradas que estan asociadas con las IMPUs de usuario en una suscripcion de IMS transmitida desde un servidor HSS del usuario,

una unidad de evaluacion 112a, adaptada para determinar una IMPI a recuperarse en conformidad con la informacion recibida de las IMPIs registradas;

una unidad de demanda 113a, adaptada para demandar los datos de usuarios en copia de seguridad de la IMPI y los datos de configuracion de servicio del usuario de la IMPU asociada con la IMPI que se determina por la unidad de evaluacion 112a desde el servidor HSS del usuario; y

una unidad de recepcion 114a, adaptada para recibir los datos de usuario en copia de seguridad de la IMPU y los datos de configuracion de servicio de usuario de la IMPU asociada con la IMPI transmitida en la respuesta reenviada por el servidor HSS del usuario.

Ademas, en otra estructura espedfica de la unidad de obtencion de datos de recuperacion de siniestro operativo 11 de la invencion ilustrada en la Figura 24, la unidad de obtencion de datos de recuperacion de siniestro operativo 11 puede incluir:

una unidad de analisis sintactico 111b, adaptada para analizar la informacion de las IMPUs registradas que estan asociadas con las IMPUs del usuario en una suscripcion de IMS transmitida desde un servidor HSS del usuario;

una unidad de evaluacion 112b, adaptada para determinar una IMPU a recuperarse en conformidad con la informacion recibida de IMPUs registradas;

una unidad de demanda 113b, adaptada para demandar los datos de usuarios en copia de seguridad de la IMPI registrada que esta directamente asociada con la IMPU determinada por la unidad de evaluacion 112b y los datos de configuracion de servicio del usuario de la IMPU asociada con la IMPU desde el servidor HSS del usuario; y

una unidad de recepcion 114b, adaptada para recibir los datos del usuario en copia de seguridad de la IMPI registrada que esta directamente asociada con la IMPU y los datos de configuracion de servicio de usuario de la IMPU transmitida en la respuesta reenviada por el servidor HSS del usuario.

En otra estructura espedfica de la unidad de obtencion de datos de recuperacion de siniestro operativo 11 de la invencion que se ilustra en la Figura 25, la unidad de obtencion de datos de recuperacion de siniestro operativo 11 puede incluir:

una unidad de analisis sintactico 111c, adaptada para analizar la informacion de las IMPIs registradas que estan asociadas con las IMPUs de usuarios en una suscripcion de IMS transmitida por una entidad de memorizacion en red del usuario;

una unidad de evaluacion 112c, adaptada para determinar una IMPU a recuperarse en conformidad con la informacion recibida de las IMPIs registradas;

una unidad de demanda 113c, adaptada para demandar los datos de usuarios en copia de seguridad y de la IMPI registrada que esta directamente asociada con la IMPU objeto de recuperacion, que se determina por la unidad de evaluacion 112c y los datos de configuracion de servicio del usuario de la IMPU de la entidad de memorizacion en red del usuario; y

una unidad de recepcion 114c, adaptada para recibir los datos de usuarios en copia de seguridad de la IMPI registrada que esta directamente asociada con la IMPU y los datos de configuracion de servicio del usuario de la IMPU transmitida en la respuesta reenviada por la entidad de memorizacion en red del usuario.

La entidad de memorizacion en red 2 incluye:

una unidad de memorizacion de datos de usuarios 21, adaptada para memorizar datos de configuracion de servicio de usuario, datos de usuarios en copia de seguridad para recuperacion de servicios de usuarios e informacion de una funcion CSCF en donde esta registrado un usuario; y

una unidad de transmision de datos de recuperacion de siniestro operativo 22, adaptada para transmitir los datos de usuarios en copia de seguridad para la recuperacion de siniestro operativo hacia una funcion CSCF.

Ademas, la entidad de memorizacion en red 2 incluye, ademas:

5

10

15

20

25

30

una unidad de encapsulacion de mensaje 23, adaptada para encapsular una respuesta que transmite la informacion de IMPIs o IMPUs registradas, en donde la respuesta puede ser cualquier mensaje tal como un mensaje SAA que transmite la informacion de IMPIs o IMPUs registradas por intermedio de un AVP: Identidades-Asociadas- Registradas del mensaje SAA o anadiendo un bit de indicador al parametro AVP: Identidades-Asociadas del mensaje SAA; y

una unidad de envfo de mensajes 24 adaptada para enviar la respuesta que incluye la informacion de las IMPIs o IMPUs registradas hacia una funcion CSCF.

Segun se ilustra en la Figura 26, una funcion CSCF sobre la copia de seguridad de datos de recuperacion de siniestro operativo puede incluir las unidades funcionales siguientes en una estructura de red de un subsistema IMS sobre recuperacion de siniestro operativo en una forma de realizacion de la invencion:

una unidad de procesamiento de inicio 13, adaptada para iniciar la copia de seguridad de datos de recuperacion de siniestro operativo que puede iniciar la copia de seguridad de datos de recuperacion de siniestro operativo despues de que una suscripcion de registro de usuario este completa durante la puesta en practica espedfica; y

una unidad de procesamiento de determinacion 14, adaptada para: determinar si los datos de suscripcion de registro en copia de seguridad despues de que la unidad de procesamiento de inicio 13 inicie la copia de seguridad de datos de recuperacion de recuperacion de siniestro operativo y para efectuar la copia de seguridad de los datos de suscripcion de registro si el resultado de la determinacion es efectuar una copia de seguridad de los datos de suscripcion de registro.

Aunque la invencion ha sido descrita a traves de varias formas de realizacion a modo de ejemplo, la invencion no esta limitada a dichas formas de realizacion.

Claims (11)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   60

   65

   REIVINDICACIONES

   1. Un metodo de recuperacion de siniestro operativo, que comprende:

   iniciar una Funcion de Control de Sesion de Llamada, CSCF, redundante (S101);

   la obtencion, por la funcion CSCF redundante, de la informacion de identidades de usuarios privados de subsistemas multimedia IP, IMS IMPIs, registrados que estan asociados con una identidad de usuario publico IMS, IMPU, en una suscripcion de IMS transmitida por una entidad de memorizacion en red de un usuario; en donde la identidad de memorizacion en red es un Servidor de Abonado Residencial, HSS;

   la determinacion, por la funcion CSCF redundante, de una IMPU a recuperar en conformidad con la informacion recibida de las IMPIs registradas y la demanda a la entidad de memorizacion en red del usuario para recuperar datos de configuracion de servicio de usuario de la IMPU y datos de usuarios en copia de seguridad de la IMPU;

   la recepcion, por la funcion CSCF redundante, de los datos de configuracion de servicio de usuario de la IMPU y los datos de usuarios en copia de seguridad de todos las IMPIs asociadas con la IMPU que se incluyen en una respuesta reenviada por la entidad de memorizacion en red del usuario;

   la recuperacion, por la CSCF redundante, de un servicio correspondiente en conformidad con los datos de usuarios en copia de seguridad obtenidos de todas IMPIs que se asocian con la IMPU y los datos de configuracion de servicio de usuario de la IMPU en la suscripcion de IMS (S103).
2. 2. El metodo segun la reivindicacion 1, en donde la etapa de obtencion, por la funcion CSCF redundante, de la informacion de las IMPIs registradas que estan asociadas con la IMPU en la suscripcion de IMS transmitidas por la entidad de memorizacion en red del usuario comprende:

   obtener, por la funcion CSCF redundante, la informacion de las IMPIs registradas que estan directamente asociadas con la IMPU transmitida por la entidad de memorizacion en red del usuario; o

   obtener, por la funcion CSCF redundante, la informacion de las IMPIs registradas incluidas en Identidades Privadas Asociadas existentes de un mensaje de respuesta de asignacion de servidor, SAA, transmitido por la entidad de memorizacion en red del usuario; o

   obtener, por la funcion de CSCF redundante, la informacion de las IMPIs registradas incluidas en un nuevo parametro de un mensaje SAA extendido transmitido por la entidad de memorizacion en red del usuario; o

   obtener, por la funcion CSCF redundante, la informacion de las IMPIs registradas incluida en un nuevo parametro de un mensaje PPR extendido transmitido por la entidad de memorizacion en red del usuario.
3. 3. El metodo segun la reivindicacion 1, en donde la funcion CSCF redundante se inicia operativamente en un proceso de registro de servicio.
4. 4. El metodo segun la reivindicacion 3, en donde

   la funcion CSCF redundante se inicia operativamente en el proceso de registro de servicio por el equipo UE comprende:

   la recepcion, por una funcion CSCF interrogante, I-CSCF, del usuario, de una demanda de registro de servicio procedente del equipo de usuario UE; y

   la deteccion, por la funcion I-CSCF del usuario, de que una funcion CSCF original que sirve al usuario no esta disponible y la seleccion de una nueva funcion CSCF para servir al usuario; la demanda, por la nueva CSCF que funciona como la CSCF redundante, de informacion de suscripcion de la entidad de memorizacion en red del usuario y su iniciacion operativa para realizar la recuperacion del siniestro; o

   la recepcion, por una funcion CSCF reiniciada, de una demanda de registro de servicio procedente del equipo de usuario UE; y

   la demanda, por la CSCF reiniciada, que funciona como la CSCF redundante, de informacion de suscripcion procedente de la entidad de memorizacion en red del usuario y su iniciacion operativa para realizar la recuperacion del siniestro.
5. 5. El metodo segun la reivindicacion 1, en donde la funcion CSCF redundante comprende una funcion CSCF entre una CSCF recientemente seleccionada que sirve al usuario cuando una CSCF original que sirve al usuario tiene un fallo operativo y una CSCF reiniciada que sirve al usuario.

   5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   60

   65
6. 6. El metodo segun la reivindicacion 1, en donde:

   los datos de usuarios en copia de seguridad comprenden:

   una direccion de una CSCF Proxy, P-CSCF, una direccion de contacto de un equipo de usuario UE y datos de suscripcion de estado de registro del equipo UE durante el registro de UE; y

   la recuperacion, por la funcion CSCF redundante, de un servicio correspondiente en funcion de los datos de usuarios en copia de seguridad obtenidos de las IMPIs registradas y los datos de configuracion de servicio del usuario de las IMPUs en la suscripcion de IMS comprende:

   el envfo, por la funcion CSCF redundante, de un mensaje de notificacion NOTIFY a todos o algunos equipos de usuario UEs registrados relacionados en conformidad con la direccion de contacto y los datos de suscripcion de estado de registro del UE en los datos de usuarios en copia de seguridad, para notificar al equipo UE el registro con una red.
7. 7. El metodo segun la reivindicacion 1, en donde la recuperacion, por la funcion CSCF redundante, de un servicio correspondiente en conformidad con los datos de usuarios en copia de seguridad obtenidos de las IMPIs registradas y los datos de configuracion de servicio del usuario de la IMPU en la suscripcion de IMS comprende:

   cuando se recibe una demanda de servicio relacionada del usuario, la evaluacion, por la funcion CSCF redundante, del tipo de servicio en conformidad con los datos de configuracion de servicio del usuario obtenidos y la recuperacion de un servicio relacionado del usuario en conformidad con los datos de usuarios en copia de seguridad.
8. 8. Una funcion de Control de Sesion de Llamada, CSCF, que comprende:

   una unidad de analisis sintactico, adaptada para efectuar el analisis de la informacion de Subsistema Multimedia IP registrado, IMS, identidades de usuarios privados, IMPIs, que estan asociadas con la Identidad de Usuario Publico de IMS, IMPU, en la suscripcion de IMS transmitida por una entidad de memorizacion en red de un usuario; en donde la entidad de memorizacion en red es un Servidor de Abonado Residencial, HSS;

   una unidad de evaluacion, adaptada para determinar una IMPU a recuperarse en conformidad con la informacion recibida de las IMPIs registradas;

   una unidad de demanda, adaptada para demandar a la entidad de memorizacion en red del usuario la recuperacion de datos de usuarios en copia de seguridad de la IMPU a recuperar, que se determinan por la unidad de evaluacion, y datos de configuracion de servicio del usuario de la IMPU;

   una unidad de recepcion, adaptada para recibir los datos de usuarios en copia de seguridad de todas las IMPIs asociadas con la IMPU y los datos de configuracion de servicio del usuario de la IMPU incluidos en una respuesta reenviada por la entidad de memorizacion en red del usuario; y

   una unidad de procesamiento de recuperacion de siniestro (12), adaptada para recuperar un servicio correspondiente en funcion de los datos de usuarios en copia de seguridad de todos las IMPIs asociadas con la IMPU y los datos de configuracion de servicio del usuario de la IMPU en la suscripcion de IMS que se obtienen por la unidad de obtencion de datos de recuperacion de siniestros.
9. 9. Una entidad de memorizacion en red, en donde la entidad de memorizacion en red es un Servidor de Abonado Residencial, HSS, que comprende:

   una unidad de memorizacion de datos de usuario (21), adaptada para memorizar datos de configuracion de servicio del usuario, datos de usuarios en copia de seguridad para la recuperacion de servicios del usuario e informacion de una Funcion de Control de Sesion de Llamada, CSCF, en donde esta registrado un usuario;

   en donde el servidor HSS esta adaptado

   para transmitir, a una funcion CSCF, informacion de Identidades de Usuarios Privados, IMPIs, del Subsistema Multimedia IP, IMS, que se asocian con la Identidad de Usuario Publico de IMS, IMPU, en una suscripcion IMS de un usuario; y

   para recibir una demanda desde la funcion CSCF para recuperar datos de configuracion de servicio del usuario de una IMPU a recuperar y datos de usuarios en copia de seguridad de la IMPU;

   comprendiendo el servidor HSS ademas:

   una unidad de transmision de datos de recuperacion de siniestro operativo (22), adaptada para transmitir los datos de usuarios en copia de seguridad a una funcion CSCF en un mensaje de respuesta;

   una unidad de encapsulacion de mensaje (23), adaptada para encapsular la respuesta que incluye los datos de 5 configuracion de servicio del usuario de la IMPU y los datos de usuarios en copia de seguridad de todas las IMPIs asociadas con la IMPU; y

   una unidad de envfo de mensaje (24), adaptada para enviar la respuesta que incluye la informacion de las IMPIs registradas a la funcion CSCF.

   10
10. 10. La entidad de memorizacion en red segun la reivindicacion 9, en donde la respuesta comprende un mensaje de Respuesta de Asignacion de Servidor, SAA.
11. 11. Un Subsistema Multimedia IP, IMS, que comprende una Funcion de Control de Sesion de Llamada, CSCF, en 15 conformidad con la reivindicacion 8 y una entidad de memorizacion en red en conformidad con cualquiera de las

    reivindicaciones 9 a 10.