MÉTODO Y APARATO PARA ASIGNAR UN SERVIDOR EN UNA RED IMS CAMPO DE LA INVENCIÓN La presente invención se refiere a un método y aparato para asignar un servidor en una red de Subsistema Multimedia IP y en particular, pero no necesariamente, a un método y aparato para asignar dinámicamente un servidor de aplicación a un usuario de Subsistema Multimedia IP. ANTECEDENTES DE LA INVENCIÓN Servicios Multimedia IP proporcionan una combinación dinámica de voz, video, mensajes, datos, etc. dentro de la misma sesión. Mediante el crecimiento del número de aplicaciones básicas y en medio que puede combinarse, crece el número de servicios ofrecidos a los usuarios finales (por ejemplo, suscriptores) , y se enriquece la experiencia de comunicación interpersonal. Esto conlleva a una nueva generación de servicios de comunicación multimedia ricos, personalizados, que incluyen los que se conocen como servicios "Multimedia IP de combinación". El Subsistema Multimedia IP (IMS) es la tecnología definida por el Third Generation Partnership Project [Proyecto de Asociación de Tercera Generación] (3GPP) para proporcionar servicios Multimedia IP en redes de comunicación móvil (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 y TS 29.329 Versiones 5 a 7). IMS proporciona características esenciales para enriquecer la experiencia de
comunicación de persona-a-persona de suscriptor final a través del uso de Facilitadores de Servicios IMS estandarizados que facilitan servicios de comunicación rica de persona-a-persona (cliente-a-cliente) así como servicios de persona-a-contenido (cliente-a-servidor) a través de redes basadas en IP. El IMS hace uso del Protocolo de Inicio de Sesión (SIP) para establecer y controlar llamadas o sesiones entre terminales de suscriptor (o terminales de suscriptor y servidores de aplicación) . El Protocolo de Descripción de Sesión (SDP) , portado por la señalización SIP, se emplea para describir y negociar los componentes de medio de la sesión. Mientras que SIP fue creado como protocolo de suscriptor-a-suscriptor, IMS permite que operadores y proveedores de servicios controlen el acceso de suscriptores a servicios y cobre a los suscriptores de manera correspondiente. A título de ejemplo, la Figura 1 ilustra esquemáticamente cómo el IMS se ajusta en la arquitectura de red móvil en el caso de una red de acceso GPRS/PS (IMS puede evidentemente operar también en otras redes de acceso) . Funciones de Control de Llamada/Sesión (CSCFs) operan como proxies de SIP dentro del IMS. La arquitectura 3GPP define tres tipos de CSCFs: la CSCF de Proxy (P-CSCF) que es un primer punto de contacto dentro del IMS para una terminal de SIP; la CSCF de Servicio (S-CSCF) que proporciona al suscriptor servicios que el suscriptor ha suscrito; y la CSCF de Interrogación (I-
CSCF) cuya función es identificar la S-CSCF correcta y enviar a esta S-CSCF una solicitud recibida a partir de una terminal de IP a través de una P-CSCF. Un suscriptor se registra con el IMS utilizando el método SIP REGISTER (REGISTRAR SIP) específico. Es un mecanismo para adjuntar al IMS y anunciar al IMS la dirección ("contacto") en donde se puede encontrar la identidad de suscriptor de SIP. En 3GPP, cuando una terminal de SIP efectúa un registro, el IMS autentica el suscriptor, y asigna una S-CSCF a este suscriptor a partir del conjunto de S-CSCFs disponibles. Mientras que los criterios para asignar S-CSCFs no son especificados por 3GPPP, pueden incluir requisitos de servicio y compartición de carga. Se observará que la asignación de una S-CSCF es esencial para controlar (y cobrar) el acceso del suscriptor a servicios basados en IMS. Operadores pueden proporcionar un mecanismo para evitar sesiones directas de SIP de suscriptor-a-suscriptor que evitarían de otra forma la S-CSCF. Durante el proceso de registro, es responsabilidad de la I-CSCF seleccionar una S-CSCF si una S-CSCF todavía no ha sido seleccionada. La I-CSCF recibe las capacidades de S-CSCF requeridas a partir del Servidor de Suscriptor Doméstico (HSS) de red doméstica, y selecciona una S-CSCF apropiada con base en las capacidades recibidas. [Se observará que la asignación de S-CSCF se efectúa también para un suscriptor
por la I-CSCF en el caso en el cual el suscriptor es llamado por otra parte, y al suscriptor no se le ha asignado actualmente una S-CSCF.] En el caso en el cual se despliegan múltiples HSSs en una red, la I-CSCF utiliza una Función de Localizador de Suscripción (SLF) para identificar el HSS correcto para un suscriptor. Cuando un suscriptor registrado envía subsiguientemente una solicitud de sesión al IMS, la P-CSCF puede enviar la petición a la S-CSCF solicitada con base en información recibida de la S-CSCF durante el proceso de registro. Dentro de la red de servicio de IMS, se proporcionan Servidores de Aplicación (ASs) , para implementar funcionalidad de servicio de IMS. Los Servidores de Aplicación proporcionan servicios a suscriptores finales en un sistema IMS, y pueden estar conectados ya sea como puntos finales en la interfaz Mr definida en 3GPP o "conectados" por una S-CSCF a través de la interfaz ISC definida por 3GPP. En este último caso, se utilizan Criterios de Filtro Inicial (IFC) por una S-CSCF con el objeto de determinar qué Servidores de Aplicaciones deben estar "conectados" durante el establecimiento de una Sesión de SIP (o de hecho para el propósito de cualquier método de SIP, relacionado o no con una sesión) . Los IFCs son recibidos por la S-CSCF a partir de un HSS durante el procedimiento de registro de IMS como parte de un Perfil de Suscriptor del suscriptor.
La Figura 2 ilustra una interfaz de Control de Servicio de IMS (ISC) entre un AS y una S-CSCF, así como otras interfaces dentro de un IMS. Aún cuando el AS en la Figura 2 se muestra teniendo solamente una sola interfaz con una S-CSCF, se observará que en la práctica, la interfaz de ISC se extenderá a través de una red de comunicación a la cual están conectados muchos (o todos) de los servidores de CSCF de una red de un operador dado, permitiendo que un AS comunique con todas estas CSCFs. [Otras entidades ilustradas en la Figura 2 serán bien conocidas por parte de las personas con conocimientos en la materia] . Una interfaz adicional (Ut) existe entre el AS y la terminal de suscriptor (TS23.002) aún cuanto esto no se muestre en la figura. La interfaz Ut permite al suscriptor manejar información relacionada con sus servicios, por ejemplo, creación y asignación de Identidades de Servicios Públicos, administración de políticas de autorización que se emplean, por ejemplo, en el caso de servicios de "presencia", administración de políticas de conferencias, etc. En el IMS de conformidad con lo definido en 3GPP, mientras que suscriptores están asignados estadísticamente a un HSS, son los ASs que proporcionan valor específico en caso de servicios proporcionados por la red. Una lectura de la especificación 3GPP en las versiones 5 y 6 sugiere que los suscriptores están asignados a ASs de SIP particulares de
manera fija. El concepto básico es que un suscriptor esté calificado para ser soportado por un ASs de SIP específico para un servicio dado o para los servicios dados. Con el objeto de permitir que la S-CSCF asignada alcance el AS asignado a través de la interfaz de ISC, los criterios de filtro (contenidos dentro del IFC enviado a la S-CSCF a partir del HSS) para este suscriptor para que este servicio contienen ya sea un nombre de dominio totalmente calificado (FQDN) o una dirección de IP como dirección de destino (codificada como SIP-URI) . Esto implica, por ejemplo, que cuando la S-CSCF identifica que un INVITE (invitado) particular debe ser encaminado hacia un AS, la S-CSCF recibe la dirección del AS específico a través de la interfaz Cx. Con el objeto de identificar el AS correcto para otras interfaces como, por ejemplo, la interfaz Ut entre las terminales de suscriptor y SIP-ASs, se proporcionan proxies de encaminamiento con la dirección del AS para el suscriptor particular. Cuando suscriptores son asignados a ASs específicos, entonces o bien la terminal está configurada con la dirección del AS para esta interfaz y servicio, o bien la terminal envía la solicitud a una entidad que sabe cómo recuperar la dirección del AS para este suscriptor. Un "extremo frontal" podría hacer eso y, en un caso de este tipo, la funcionalidad de encaminamiento estaría configurada en el extremo frontal.
COMPENDIO DE LA INVENCIÓN Como resultará claro a partir de los comentarios anteriores, la propuesta existente para la asignación de ASs a suscriptores requiere del suministro de un suscriptor a un servidor de aplicación de SIP específico para un servicio dado o para un conjunto dado de servicios. Esto requiere de un alto nivel de disponibilidad y del almacenamiento persistente de datos en los ASs puesto que, si un ASs individual se vuelve temporalmente no disponible o no conserva la información apropiada, el servicio o los servicios proporcionados no estarán disponibles a los suscriptores a los cuales el AS está asignado. La adopción de este enfoque puede requerir de la integración de redundancia para cada AS. Además, la asignación estática de suscriptores complica los aspectos operativos de la red y hace que acciones tales como la reasignación de suscriptores a ASs no sea una tarea trivial. Dicha reasignación puede ser requerida, por ejemplo, cuando el número de suscriptores en una red crece a un punto en el cual se requiere de capacidad adicional (potencia de procesamiento, memoria, etc.). De conformidad con un primer aspecto de la presente invención, se proporciona un método para dirigir solicitudes a un servidor de aplicación dentro de un subsistema multimedia IP, el método comprende: al recibir una solicitud asociada con un usuario de
Subsistema Multimedia IP en una entidad del Subsistema Multimedia IP, consultar una base de datos para determinar si o no el usuario está asignado a un servidor de aplicación; si se determina que el usuario no está asignado a un servidor de aplicación, asignar el usuario a un servidor de aplicación en dicha entidad, enviar la solicitud de dicha entidad al servidor de aplicación asignado, y enviar una solicitud de dicha entidad al servidor de aplicación asignado, y enviar una solicitud del servidor de aplicación o dicha entidad a dicha base de datos para provocar el registro ahí de la asignación; y si se determina que el usuario está asignado a un servidor de aplicación, enviar la solicitud de dicha entidad al servidor de aplicación asignado. Modalidades de la presente invención proporcionan un medio para manejar la asignación dinámica de usuarios de un Subsistema Multimedia IP a servidores de aplicación de Protocolo de Inicio de Sesión (SIP-ASs) . Las ventajas de la asignación dinámica de usuario son que el requisito de almacenamiento persistente de datos de asignación es menos estricto y que es más fácil cambiar y actualizar la arquitectura de red, como por ejemplo mediante la introducción de un nuevo servidor de aplicación. Dicha solicitud puede ser una solicitud de Protocolo de
Inicio de Sesión o una solicitud de conformidad con otro protocolo (por ejemplo, interfaz Ut) destinado para un servidor de aplicación del usuario. Preferentemente, dicho paso de consultar una base de datos para determinar si o no el usuario está asignado a un servidor de aplicación se efectúa de conformidad con el Protocolo de Inicio de Sesión. En una modalidad de la invención, dicha entidad de Subsistema Multimedia IP es una Función de Control de Llamada/Sesión de Servicio. En este caso, la consulta y la respuesta a la consulta se envían al Servidor de Suscriptor Doméstico a través de la interfaz Cx. En una modalidad alternativa, dicha entidad de Subsistema Multimedia IP es un distribuidor de extremo frontal o un servidor de aplicación "representante" que actúa como un solo servidor de aplicación lógica para el resto de la red. Para solicitudes recibidas del usuario en la Función de Control de Llamada/Sesión de Servicio del Subsistema Multimedia IP, el distribuidor de Extremo Frontal se localiza entre los servidores de aplicación y la Función de Control de Llamada/Sesión de Servicio, en la interfaz ISC. Al recibir la petición en la Función de Control de Llamada/Sesión de Servicio, la Función de Control de Llamada/Sesión de Servicio consulta un Servidor de Suscriptor Doméstico con el objeto de identificar el distribuidor de Extremo Frontal al cual se
debe enviar la solicitud. La consulta puede devolver a la Función de Control de Llamada/Sesión de Servicio una identificación de un solo distribuidor de Extremo Frontal, o bien puede identificar un grupo de distribuidores de Extremo Frontal a partir del cual se selecciona un distribuidor en el Extremo Frontal. Alternativamente, el distribuidor de Extremo Frontal puede recibir solicitudes del usuario a través de la interfaz Ut. El distribuidor de Extremo Frontal puede ser un nodo independiente dentro del Subsistema Multimedia IP. Alternativamente, puede ser una entidad funcional que se encuentra en un servidor de aplicación. En este último caso, el distribuidor del Extremo Frontal puede enviar una solicitud al servidor de aplicación en donde se encuentra, u otro servidor de aplicación según el servidor de aplicación al cual se asigna el usuario. Dicha base de datos puede proporcionarse en un Servidor de Suscriptor Doméstico. La asignación de usuarios a servidores de aplicación puede almacenarse en el Servidor de Suscriptor Doméstico, utilizando la interfaz ISC transparente y/o no transparente. Otras bases de datos alternativas mantenidas centralmente pueden incluir directorios de LDAP y bases de datos relacionales/de objetos disponibles a través de interfaces, por ejemplo SQL, JDBC, ODBC. Es también posible que la base de datos sea mantenida en una pluralidad de
ubicaciones dentro de la red. Por ejemplo en el caso en el cual la entidad que efectúa las asignaciones de servidor de aplicación es FE-DIST, se puede proporcionar una copia de la base de datos a cada FE-DIST . Preferentemente, dicha solicitud enviada del servidor de aplicación o dicha entidad a dicha base de datos incluye una o varias direcciones del servidor de aplicación. Una dirección puede estar incluida para cada interfaz a la cual el servidor de aplicación está conectado. En el caso en el cual el usuario no ha sido previamente asignado a un servidor de aplicación, el servidor de aplicación obtendrá datos de suscriptor a partir del Servidor de Suscriptor Doméstico. Para usuarios previamente asignados, el servidor de aplicación puede haber conservado los datos de suscriptor. Datos de suscriptor pueden ser conservados por el servidor de aplicación independientemente de si o no el usuario ha sido de-registrado/borrado de registro del Subsistema Multimedia IP. En ciertas implementaciones de la invención, un servidor de aplicación que recibe una solicitud de dicha entidad puede enviar la solicitud a un servidor de aplicación adicional y/o puede provocar que la asignación del usuario a este otro servidor sea registrada en dicha base de datos. Según un segundo aspecto de la presente invención, se proporciona un aparato para su uso en una red de Subsistema
Multimedia IP, el aparato comprende: un medio para recibir una solcitud asociada con un usuario de Subsistema Multimedia IP; un medio para consultar una base de datos para determinar si o no el usuario está asignado a un servidor de aplicación; si se determina que el usuario no está asignado a un servidor de aplicación, un medio para asignar el usuario a un servidor de aplicación y enviar la solicitud al servidor de aplicación asignado; y si se determina que el usuario está asignado a un servidor de aplicación, un medio para enviar la solicitud al servidor de aplicación asignado. Dicho aparato puede estar proporcionado dentro de un servidor de Función de Control de Llamada/Sesión de Servicio.
Alternativamente, el aparato puede encontrarse en un servidor de aplicación o bien puede ser un nodo independiente dentro del Subsistema Multimedia IP. Según un tercer aspecto de la invención, se proporciona un método para dirigir solicitudes de Protocolo de Inicio de
Sesión a un servidor de aplicación dentro de un Subsistema
Multimedia IP, el método comprende: al recibir una solicitud de Protocolo de Inicio de
Sesión asociada con un usuario de Subsistema Multimedia IP en una Función de Control de Llamada/Sesión de
Servicio del Subsistema Multimedia IP, enviar la solicitud a un primer servidor de aplicación que actúa como servidor de redireccionamiento; en el primer servidor de aplicación, consultar la base de datos para determinar si o no el usuario está asignado a un servidor de aplicación; Si se determina que el usuario no está asignado a un servidor de aplicación, asigna el usuario a un segundo servidor de aplicación a dicho primer servidor de aplicación, y devolver una solicitud de redireccionamiento a la Función de Control de Llamada/Sesión de Servicio que identifica el segundo servidor de aplicación; y enviar la solicitud a partir de la Función de Control de Llamada/Sesión de Servicio al segundo servidor de aplicación. Dicha solicitud de redireccionamiento puede comprender uno o varios de los siguientes mensajes SIP, enviados en respuesta a la solicitud de Protocolo de Inicio de Sesión: "300 Múltiples Choices" [Opciones Múltiples] "301 Moved Permanently" [Desplazamiento permanente] "302 Moved Temporarily" [Desplazamiento temporal] . La Función de Control de Llamada/Sesión de Servicio puede colocar en caché la identidad/ubicación del segundo servidor de aplicación de tal manera que solicitudes subsiguientes
puedan ser enviadas directamente al segundo servidor de aplicación. Esto se facilita por ejemplo utilizando las respuestas "301 Moved Permanently" [Se desplazó permanentemente] o "302 Moved Temporarily" [Se desplazó temporalmente] . Según un cuarto aspecto de la presente invención, se proporciona un servidor de aplicación para su uso en un Subsistema Multimedia IP, el servidor comprende: un medio para recibir una solicitud, asociada con un usuario de Subsistema Multimedia IP, a partir de una Función de Control de Llamada/Sesión de Servicio; un medio para consultar una base de datos para determinar si o no el usuario está asignado a un servidor de aplicación y, en caso de respuesta negativa, para asignar al usuario a un segundo servidor de aplicación; y un medio para devolver una solicitud de redireccionamiento a la Función de Control de Llamada/Sesión de Servicio que identifica el segundo servidor de aplicación. BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 ilustra esquemáticamente la integración de un Subsistema Multimedia IP en un sistema de comunicación móvil 3G; La Figura 2 ilustra esquemáticamente ciertas entidades del
Subsistema Multimedia IP que incluye un servidor de aplicación y una Función de Control de Llamada/Sesión de
Servicio conjuntamente con las varias interfaces; La Figura 3 ilustra esquemáticamente el uso de un FE-DIST para asignar usuarios de IMS a servidores de aplicación en registro de usuario IMS; La Figura 4 ilustra esquemáticamente el uso de un FE-DIST para manejar llamadas de salida y de llegada después de utilización de registro; La Figura 5 ilustra esquemáticamente el uso de un FE-DIST para manejar llamadas de llegada a un usuario no registrado;
La Figura 6 ilustra esquemáticamente el uso de un FE-DIST para manejar solicitudes recibidas a través de una interfaz no-SIP para un usuario registrado ante IMS; La Figura 7 ilustra esquemáticamente el uso de un FE-DIST para manejar solicitudes recibidas a través de una interfaz no-SIP para un usuario no registrado; La Figura 8 ilustra la señalización asociada con la formación de una base de datos de servidor de aplicación de un servidor ü de aplicación representativo; La Figura 9 ilustra los pasos de señalización y proceso asociados con el uso de un servidor de aplicación representativo para seleccionar un servidor de aplicación y provocar el redireccionamiento de mensajes al servidor seleccionado;
La Figura 10 ilustra pasos de proceso y señalización asociados con el uso de un servidor de aplicación representativo en el caso de un INVITE recibido en donde un servidor de aplicación ya asignado está activo; y La Figura 11 ilustra pasos de proceso y señalización asociados con el uso de un servidor de aplicación representativo en el caso de un INVITE recibido cuando un servidor de aplicación ya asignado está inactivo. DESCRIPCIÓN DETALLADA DE CIERTAS MODALIDADES Los Estándares Técnicos 3GPP referenciados arriba describen el uso de criterios de filtro inicial (IFC), que están almacenados en HSS, y que se envían a un nodo de Función de Control de Llamada/Sesión de Servicio (S-CSCF) ya sea al registrarse un suscriptor o bien cuando se efectúa una llamada terminante a un suscriptor no registrado. Convencionalmente, un IFC para un suscriptor contiene una dirección específica de Servidor de Aplicación de SIP (AS) , por ejemplo, un Nombre de Dominio Totalmente Calificado (FQDN) . Esto identifica el AS asignado a este suscriptor para un servicio dado [Es posible que un IFC contenga dos o más direcciones AS que corresponden a servicios IMS respectivos. Si la dirección de AS en el IFC es un SIP-URL, se utiliza un DNS para resolver el SIP-URL a una dirección de IP. La S-CSCF puede colocar en caché la asociación entre la dirección de SIP-AS específica y la dirección de IP por razones de
eficiencia. Esta colocación en caché es típicamente en el cliente de DNS de la S-CSCF del sistema y se coloca en caché en base a nodo, no en base a suscriptor. La discusión siguiente considera, a título de ejemplo, que se utiliza un enfoque flexible y dinámico para la asignación de SIP-AS. Esto incluye el reemplazo de la dirección de AS específica almacenada en el Criterio de Filtro Inicial (IFC) en el Servidor de Suscriptor Doméstico (HSS) con una identidad de AS genérica, por ejemplo, SIP-AS-service.operator.com, en el caso en el cual no se ha efectuado ya una asignación dinámica de SIP-AS. En lugar de identificar directamente un AS o un grupo de ASs, esta identidad identifica una nueva entidad funcional dentro del IMS, que se conoce aquí como Distribuidor de Extremo Frontal o "FE-DIST". El FE-DIST puede conocerse alternativamente como "AS representativo". El FE-DIST se coloca entre la S-CSCF y los ASs en la interfaz de ISC. Al registrarse un suscriptor -o al terminar una llamada para un suscriptor no registrado -el IFC es descargado a la S-CSCF a través de la interfaz Cx de conformidad con los procedimientos descritos en 3GPP TS 23.228; 3GPP TS 29.228 y 3GPP TS 29.229. La identidad genérica de SIP-AS es resuelta ya sea a través de un nombre específico, por ejemplo FE-DIST. operator . com, que se resuelve adicionalmente a una dirección de IP, o bien la identidad genérica es resuelta directamente a una dirección de IP.
Métodos existentes de DNS son utilizados para el proceso de resolución. [En el caso en el cual la identidad genérica es resuelta a un nombre específico que es resuelto adicionalmente a una dirección de IP, se requieren de dos desplazamientos redondos entre S-CSFC y DNS] . El IFC desencadena el suministro de un mensaje de registro de tercero, por ejemplo un mensaje de SIP REGISTER, por la S-CSCF a la función FE-DIST . La S-CSCF no coloca en caché la asociación entre el suscriptor y la dirección seleccionada de FE-DIST en esta etapa. La funcionalidad de FE-DIST puede ser una entidad funcional que se encuentra en cada SIP-AS que ofrece el servicio (requerido) , o bien puede desplegarse como nodo independiente. Es también evidentemente posible combinar estos dos enfoques cuando un servicio es desplegado e instalado en la red, es decir, equipar ciertos ASs con entidades funcionales de FE-DIST que coexisten con nodos de FE-DIST independientes. Las Figuras mencionadas abajo y que se utilizan para explicar la propuesta muestran el FE-DIST y los ASs (en donde se encuentra la Lógica de Aplicación) como entidades funcionales separadas. La Figura 3 ilustra esquemáticamente entidades funcionales dentro de un Subsistema Multimedia IP (IMS) que facilita el suministro de servicios a una terminal de suscriptor. La Figura 3 ilustra también, a título de ejemplo, pasos de
procedimiento asociados con la asignación dinámica de suscriptores a Servidores de Aplicación de IMS (ASi a ASn) habilitados por entidades de Distribución de Extremo Frontal (FE? a FEn) . Se considera aquí que ocurre una asignación de servidor de aplicación al registro, pero esto puede ocurrir en otros momentos. la La terminal de suscriptor inicia un proceso de REGISTRO enviando un mensaje SIP REGISTER a la red de IMS y se asigna a una de las S-CSCFs de conformidad con procedimientos definidos por 3GPP. lb Durante el proceso de registro, el perfil de servicio para el suscriptor es descargado a partir del HSS. Este perfil contiene el IFC. 2a Después de terminar el proceso de registro, la S-CSCF entiende que debe enviar un REGISTRO de tercero al nombre de servidor de aplicación identificado por el
IFC. El nombre de servidor de aplicación es un nombre genérico. La S-CSCF solicita la dirección de IP a partir de un servidor de DNS. El servidor de DNS responde con la dirección de uno o varios FE-DIST disponibles.
Obsérvese que la S-CSCF interpreta la dirección como una dirección AS y no ser requiera de ningún cambio de la funcionalidad de la S-CSCF. 2b La S-CSCF selecciona una de las direcciones de IP devueltas como la dirección a la cual se envía el
mensaje REGISTER. 2c El mensaje REGISTER de tercero es enviado al FE-DIST seleccionado . 2d El FE-DIST revisa si el suscriptor ya ha sido asignado a un AS mediante el hecho de consultar una base de datos central almacenada en el HSS a través de la interfaz Sh. Si es el caso, el mensaje REGISTER es enviado al AS asignado. Si la operación de búsqueda indica que el suscriptor todavía no está asignado a un AS, el FE-DIST selecciona un AS y envía el mensaje REGISTER al AS seleccionado. 3 Al recibir el registro de tercero, el AS efectúa las tareas siguientes: Almacena un mapeo entre su dirección y la identidad de suscriptor en el HSS. La Dirección que el AS almacena es de hecho un conjunto de direcciones diferentes para interfaces diferentes. Por ejemplo, pueden ser direcciones diferentes para la recepción de mensajes SIP, tráfico de HTTP, etc. Recupera los datos de suscriptor a partir de la ubicación central (por ejemplo HSS u otro repositorio central) . El AS suscribe a la ubicación central de tal manera que esté informado de cambios a los datos de suscriptor. A corto plazo, el SIP-AS puede almacenar el mapeo entre su
dirección y la identidad de suscriptor en el HSS utilizando datos transparentes (a través de la interfaz Sh: datos transparentes no son entendidos por el HSS) . A largo plazo, el mapeo puede ser agregado a los datos no transparentes en el HSS. Se observará que, en lugar de almacenar la base de datos mencionada en el paso 2b en una sola ubicación, es decir, el HSS, se pueden almacenar varias copias en varias ubicaciones dentro de la red. Por ejemplo, cada FE-DIST puede almacenar su propia copia de la base de datos. Al terminar el proceso ilustrado en la Figura 3, un SIP-AS ha sido asignado al suscriptor, y el SIP-AS ha recuperado una copia de los datos de suscriptor requeridos y está listo para dar servicio al suscriptor. Al cancelar un registro de suscriptor al IMS, el suscriptor puede seguir siendo asignado al SIP-AS y los datos de suscriptor mantenidos por el FE-DIST/AS/HSS no tienen que ser borrados. Esto permite una separación clara del procedimiento de asignación de suscriptor/AS con relación al procedimiento de registro de IMS/SIP, ofreciendo la ventaja que la frecuencia de recuperación de datos de suscriptor es reducida en comparación con el caso en el cual el procedimiento de asignación está conectado al procedimiento de registro de SIP/AS. Con referencia a la Figura 4, el procedimiento para manejar
"llamadas" de IMS salientes y entrantes para un suscriptor ya registrado se describirá a continuación, con referencia a los pasos de proceso numerados en la Figura. la Una solicitud de SIP (por SIP INVITE) que se refiere al usuario es recibido por la S-CSCF. 2a La S-CSCF analiza la solicitud de SIP inicial, y la S- CSCF solicita la dirección de IP, con base en el nombre del SIP-AS recibido del HSS a través de la interfaz Cx, a partir de un servidor de DNS. El servidor de DNS responde con una o varias direcciones a FE-DIST disponibles. Obsérvese que la S-CSCF interpreta la dirección como una dirección AS y la funcionalidad de la
S-CSCF no presenta cambios. En caso necesario, la S-CSCF selecciona una de las direcciones retornadas que indicará un FE-DIST . 2c En mensaje de SIP inicial es enviado a la dirección de
FE-DIST proporcionada o seleccionada. 2d El FE-DIST receptor identifica el AS asignado al suscriptor mediante la realización de una búsqueda en el HSS a través del Sh transparente (o mediante la revisión de su propia copia de la base de datos si se proporciona) . 3 La solicitud de SIP es enviada al SIP-AS. El SIP-AS tiene una copia de datos para el suscriptor a partir del proceso de registro (previamente efectuado) . Procesa
después la solicitud de SIP. Con referencia a la Figura 5, se describirá a continuación el procedimiento para manejar "llamadas" MS terminantes para un suscriptor no registrado, haciendo referencia a los pasos de proceso numerados en la Figura. la La S-CSCF recibe una solicitud de SIP terminantes (por ejemplo, SIP INVITE) . lb El perfil de servicio es descargado a la S-CSCF a partir del HSS. Contiene los criterios de filtro iniciales. 2a La S-CSCF analiza la solicitud de SIP inicial y la S- CSCF solicita la dirección de IP a partir de un servidor de DNS (con base en el nombre de SIP-AS recibido a partir del HSS en la interfaz Cx) . El servidor DNS responde a la S-CSCF con una o varias direcciones a FE- DIST disponibles. 2b En caso necesario, la S-CSCF selecciona una de las direcciones devueltas a la cual enviar el mensaje SIP inicial. 2c El mensaje SIP inicial es enviado al FE-DIST seleccionado. 2d El FE-DIST identifica el AS asignado al suscriptor mediante la realización de una búsqueda en el HSS en la
Sh transparente. 3 La solicitud de SIP es enviada a SIP-AS. Considerando que el suscriptor ha permanecido asignado a SIP-AS, aún
cuando el suscriptor fue borrado de registro/no registrado en IMS, el SIP-AS tendrá una copia de los datos para el suscriptor a partir un proceso de registro previo. Procesa la solicitud de SIP. [Si el AS ha perdido los datos de suscriptor por cualquier razón, esto habría sido descubierto en el paso 2d. Se habría asignado un nuevo AS y el AS seleccionado habría obtenido los datos de suscriptor a partir de la ubicación central] . El procedimiento propuesto aquí para asignar y encaminar solicitudes de SIP puede también aplicarse al caso en el cual peticiones llegan al Subsistema Multimedia IP a través de la interfaz Ut . La Figura 6 ilustra el caso en el cual una solicitud de SIP es recibida en la interfaz Ut y el usuario en cuestión ya ha sido asignado a un AS. Los pasos ilustrados y numerados son los siguientes: 1. Una solicitud es recibida dentro del IMS a través de la interfaz Ut . La solicitud es terminada en un FE- DIST para el servicio representado por este extremo frontal . 2. El FE-DIST solicita la dirección de AS a partir del HSS a través de la interfaz Sh. 3. La dirección de AS explícita es devuelta a través de la interfaz Sh al FE-DIST.
4. La Solicitud es enviada a la dirección explícita, y por ejemplo, un Servidor de Administración de Documentos XML (XDMS) en el AS de servicio. La Figura 7 ilustra el caso en el cual se recibe una solicitud de SIP a través de la interfaz Ut y el usuario en cuestión no ha sido todavía asignado a un AS. Los pasos ilustrados y numerados son los siguientes: 1. Una solicitud es recibida a través de la interfaz particular. La solicitud es terminada en un FE-DIST para el servicio representado por el extremo frontal.
2. El FE-DIST solicita la dirección de AS a partir del HSS a través de la interfaz Sh. 3. Una indicación que no se ha asignado AS es retornada.
4. El FE-DIST selecciona un AS (puede utilizar otras bases de datos para obtener los nombres de ASs válidos) . 5. La solicitud es enviada al AS seleccionado y al XMDS.
6. El AS seleccionado efectúa lo siguiente: • El SIP-AS puede seleccionar registrarse el mismo como AS de servicio para el suscriptor y si lo hace almacena su dirección explícita en el HSS. (Esto no puede ser requerido si la transacción ocurre solamente una vez y no se contempla que haya solicitudes subsiguiente) . • Leer los datos de suscriptor específicos para la
aplicación a partir del almacenamiento de datos central (típicamente el HSS) . • Procesar la solicitud. Mientras que las Figuras 6 y 7 se refieren específicamente a la interfaz Ut, se observará que el FE-DIST puede manejar solicitudes recibidas a través de otras interfaces. Mientras que se deben estandarizar otras interfaces, un ejemplo puede ser el caso en el cual un servidor de aplicación implementa tanto ISC como OSA, y el protocolo Parlay es utilizado en OSA. Un mecanismo alternativo para facilitar la asignación dinámica de usuarios a servidores de aplicación incluye la implementación de un FE-DIST que es capaz de asignar usuarios a servidor de aplicación relacionado con ciertos servicios y provocar el redireccionamiento de solicitudes de SIP hacia ese servidor de aplicación. Este nuevo FE-DIST actúa esencialmente como un servidor de aplicación que funciona en modo de redireccionamiento, y debe conocer de antemano los nombres y direcciones de todos los ASs que van a compartir la carga de usuarios. Por consiguiente, el FE-DIST debe contener una tabla con las direcciones de ASs a las cuales usuarios pueden ser asignados dinámicamente. La lista de nombres de AS y direcciones puede establecerse en el FE-DIST de dos formas diferentes . 1. Puede configurarse manualmente (a través de
operaciones y herramientas de mantenimiento, una interfaz comando-línea o cualquier otro medio) . 2. Automáticamente, por ASs mismos. En este enfoque cuando un AS es llevado en línea, enviará un mensajes SIP REGISTER al FE-DIST con el SIP URI del AS en los encabezados De a A y un encabezado de contacto que conserva el nombre o dirección del AS. La Figura 8 ilustra la señalización de SIP asociada con este proceso de configuración automático. Obsérvese que, en cualquier red dada puede existir ASs a los cuales usuarios pueden ser dinámicamente asignados y ASs que no tienen esta capacidad por consiguiente en los cuales los usuarios deben ser por consiguiente estadísticamente asignados . La asignación de un usuario a un AS se efectuará cuando el usuario accesa la red de IMS como por ejemplo, cuando se registra en la red. Cuando ocurre esto, la S-CSCF recibe un mensaje SIP REGISTER. Con base en información de desencadenamiento (IFCs) descargada del HSS, la S-CSCF envía el mensaje REGISTER al FE-DIST . Este procedimiento es bien conocido y definido en estándares de IMS. Ahora, el FE-DIST debe asignar un AS al usuario registrante. Revisa su lista pre-configurada de ASs y, con base en ciertos criterios, selecciona un AS y devuelve su nombre o dirección como encabezado de Contacto en una respuesta de "300 Múltiple
Choices" [300 Opciones Múltiples] a la S-CSCF. El FE-DIST anota la identidad y/o dirección del AS seleccionado y almacena esta información junto con el identificador de usuario recibido en la solicitud REGISTER en su tabla de mapeos de AS de identificador de usuario. Un AS puede seleccionarse, por ejemplo, con base en su nivel actual de ocupación, su nivel de uso (en el caso en el cual el FE-DIST recibe reportes de carga de ASs), su estado de operación (en caso en el cual el FE-DIST puede obtener información sobre el estatus de trabajo de ASs) . La S-CSCF, al recibir la respuesta de FE-DIST, envía la solicitud de REGISTER (ligeramente modificad como registro de tercero) al AS según ' lo instruido por el FE-DIST. Eventualmente, la S-CSCF recibirá una respuesta "200 OK" de este u otro AS (en el caso en el cual se lleva a cabo otro redireccionamiento) , y enviará la respuesta de vuelta al salto previo en la trayectoria de la solicitud REGISTER (normalmente alguna I-CSCF) . Para solicitudes de SIP adicionales relacionadas con el usuario ahora registrado, la S-CSCF envía cada nueva solicitud al FE-DIST después de hacerlo corresponder con su información de desencadenador, como lo hizo con la solicitud REGISTER antes. Sin embargo esto plantea el problema que cada nueva solicitud de SIP debe ser resuelta a través de FE-DIST, empeorando el tiempo de respuesta de la red global e
incrementando la carga en las funciones S-CSCF y FE-DIST . Un enfoque posiblemente mejorado es que FE-DIST conteste a REGISTER con una respuesta "301 Moved Permanently" [301 Desplazamiento Permanente] cuando encuentra que el usuario identificado en el REGISTER ya ha sido asignado a un AS . Esto permite a la S-CSCF colocar en caché la dirección de AS incluida en la respuesta de tal manera que no se envíen solicitudes del SIP relacionadas adicionales al FE-DIST. Otro enfoque es que el FE-DIST responda al REGISTER con una respuesta "302 Moved Temporarily" [302 Desplazamiento Temporal], incluyendo un encabezado Vence con un tiempo predefinido. Esto permite que la S-CSCF coloque en caché la dirección de AS durante este tiempo predefinido. Cuando vence este tiempo, la S-CSCF consultará el FE-DIST al recibir una solicitud de SIP adicional para el usuario. La ventaja de este enfoque es que reducirá la carga en el FE-DIST mientras que seguirá permitiendo la reasignación del usuario a un modo de suscriptor, por ejemplo, si un AS previamente asignado falla. Una forma sencilla de instalar el redireccionamiento reportado por el FE-DIST (en el "300 Múltiple Choices" [300 Opciones Múltiples] o "302 Moved Temporarily" [302 Desplazamiento Temporal] ) en S-CSCF es sobreescribir el campo AS de destino en la información de desencadenamiento del activador que disparó el envío de la solicitud al FE-DIST .
Obsérvese que en el caso de "302 Moved Temporarily" [302 Desplazamiento Temporal] , la S-CSCF debe conservar el servidor de destino antiguo para el desencadenador, de tal manera que puede recuperarlo cuando vence el tiempo establecido por la respuesta 302. En casos en los cuales el FE-DIST implementa un redireccionamiento en la S-CSCF, cuando el HSS actualiza subsiguientemente la información de desencadenamiento almacenada en S-CSCF para un usuario, cualquier redireccionamiento temporal o permanente instalado en la S-CSCF para este usuario debe ser removido. Si el redireccionamiento ha sido instalado mediante sobreescritura de la información de disparo, esto ocurrirá evidentemente de manera automática al almacenar la nueva información de disparo enviada por HSS. La Figura 9 ilustra cómo el FE-DIST maneja una solicitud de SIP inicial de un usuario. La solicitud puede un REGISTER, según lo ilustrado, o alguna otra solicitud para la cual el FE-DIST no tiene registrado ningún enlace id de usuario-AS. La figura 10 ilustra cómo una solicitud de SIP adicional para un usuario ya registrado es manejada por el FE-DIST, considerando el uso de la respuesta "302 Moved Temporarily" [302 Desplazamiento Temporal] . La Figura 11 ilustra un procedimiento para manejar relocalización de un usuario a partir de un AS que no
funciona a otro AS. Obsérvese que el servicio proporcionado por el nuevo AS requiere de registro (es decir, una solicitud REGISTER debe haber sido recibida antes de utilizar el servicio) , el enfoque presentado funcionará solamente en la medida en que el nuevo AS puede accesar la información de registro preexistente de alguna manera (por ejemplo, si todos los ASs comparten una base de datos de registros común que sigue funcionando aún en caso de fallas de ASs individuales) . Una persona con conocimientos en la materia observará que varias modificaciones pueden efectuarse a las modalidades descritas arriba sin salirse del alcance de la presente invención.