MÉTODO Y APARATO PARA ASIGNAR SERVIDORES DE APLICACIÓN EN UN IMS CAMPO DE LA INVENCIÓN La presente invención se refiere a un método y aparato para asignar servidores en un 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, 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 usuario (o terminales de usuario 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 usuario-a-usuario, IMS permite que operadores y proveedores de servicios controlen el acceso de usuarios a servicios y cobre a los usuarios 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 usuario servicios que el usuario 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 usuario 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 en donde se puede encontrar la identidad de usuario de SIP. En 3GPP, cuando una terminal de SIP efectúa un registro, el IMS autentica el usuario, y asigna una S-CSCF a este usuario 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 usuario a servicios basados en IMS. Operadores pueden proporcionar un mecanismo para evitar sesiones directas de SIP de usuario-a-usuario 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 usuario por la I-CSCF en el caso en el cual el usuario es llamado por otra parte, y al usuario no se le ha asignado actualmente una S-CSCF.]. 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 usuario (TS23.002) aún cuanto esto no se muestre en la figura. La interfaz Ut permite al usuario 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 servidor de aplicación AS 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 la discusión arriba, la propuesta existente para asignación de ASs a suscriptores requiere del suministro de un usuario a un servidor de aplicación de SIP específico para un servicio dado o un conjunto dado de servicios. Esto requiere de un alto nivel de disponibilidad y almacenamiento persistente de datos en los ASs puesto que, si un AS individual se vuelve temporalmente no disponible o no conserva la información apropiada, el (los) servicio (s) proporcionados no estarán disponibles a los suscriptores a los cuales se asigna el AS. La adopción de este enfoque puede requerir de la formación de redundancia para cada AS. De conformidad con un primer aspecto de la presente invención, se proporciona un método para asignar un Servidor de Aplicación de Protocolo de Inicio de Sesión a un suscriptor dentro de Subsistema Multimedia IP, el método comprende : Identificar en un Servidor de Suscriptor Doméstico un conjunto de criterios de filtro inicial proporcionados para dicho suscriptor, dicho conjunto de criterios de filtro inicial contiene por lo menos una identidad genérica de Servidor de Aplicación de Protocolo de Inicio de Sesión; enviar dicho conjunto de criterios de filtro inicial desde el Servidor de Suscriptor Doméstico a una Función de Control de Llamada/Sesión de Servicio asignada a dicho suscriptor; recibir dicho conjunto de criterios de filtro inicial en dicha Función de Control de Llamada/Sesión de Servicio y resolver dicha identidad genérica de Servidor de Aplicación de Protocolo de Inicio de Sesión en varias direcciones de Servidor de Aplicación; asignar una de dichas direcciones a dicho suscriptor para su uso en el suministro de un servicio a dicho suscriptor; y colocar en caché una dirección asignada en la Función de Control de Llamada/Sesión de Servicio para dicho suscriptor para uso subsiguiente. Modalidades de la presente invención introducen un grado considerable de flexibilidad en el proceso de asignar un servidor de aplicación SIP a un suscriptor. En el caso en el cual un Servidor de Aplicación SIP dado no esté disponible o no pueda proporcionar el servicio deseado, la S-CSCF puede simplemente asignara un nuevo Servidor de Aplicación al suscriptor. Preferentemente, dicha identidad de Servidor de Aplicación de Protocolo de Inicio de Sesión es una SIP-URI. Preferentemente dichas varias direcciones de Servidor de Aplicación son Nombres de Dominio totalmente calificados o direcciones IP. Preferentemente, dicho paso de resolver dicha identidad genérica de Servidor de Aplicación de Protocolo de Inicio de Sesión en varias direcciones de Servidor de Aplicación comprende el envío de una solicitud que contiene dicha identidad genérica de Servidor de Aplicación de Protocolo de Inicio de Sesión a un Servidor de Nombre de Dominio, el Servidor de Nombre de Dominio responde mediante la identificación de varias direcciones de Servidor de Aplicación que corresponden a dicha identidad genérica de Servidor de Aplicación de Protocolo de Inicio de Sesión, y enviara a la Función de Control de Llamada/Sesión de Servicio dichas varias direcciones. En una modalidad de la presente invención, dicho paso de asignar una de dichas direcciones a dicho suscriptor para uso en el suministro de un servicio a dicho suscriptor comprende la selección de una dirección con base en una escala de prioridad de direcciones proporcionada por el Servidor de Nombre de Dominio. La selección puede basarse en una selección de circuito cíclico, ponderada según la prioridad. Preferentemente, el método comprende, después de la asignación de una dirección de Servidor de Aplicación a un suscriptor, colocar en caché en la Función de Control de Llamada/Sesión de Servicio de la asociación entre el suscriptor y la dirección. El método del primer aspecto de la invención mencionado arriba se lleva acabo en el registro de Protocolo de Inicio de Sesión del suscriptor. El método puede también efectuarse cuando el suscriptor no esté registrado pero se encuentre en el extremo de finalización de una llamada de Protocolo de Inicio de Sesión. En una modalidad del primer aspecto de la presente invención, el método comprende el envío, a partir del servidor de aplicación que corresponde a la dirección asignada a un almacén central, de una o varias direcciones de interfaz del servidor de aplicación. Preferentemente, dicho almacén central es dicho Servidor de Suscriptor Doméstico. Esto se efectúa después de recibir una petición SIP para un usuario que el servidor de aplicación no conoce actualmente. Según un segundo aspecto de la presente invención, se proporciona un nodo de Función de Control de Llamada/Sesión de Servicio para uso dentro de un Subsistema Multimedia IP, el nodo comprende: una entrada conectada a un Servidor de Suscriptor Doméstico para recibir a partir de ahí un conjunto de criterios de filtro inicial para un suscriptor, dicho conjunto de criterios de filtro inicial contiene por lo menos una identidad genérica de Servidor de Aplicación de Protocolo de Inicio de Sesión; un medio de procesamiento para resolver dicha identidad genérica de Servidor de Aplicación de Protocolo de Inicio de Sesión en varias direcciones de Servidor de aplicación y para asignar una de dichas direcciones a dicho suscriptor para uso en el suministro de un servicio a dicho suscriptor; y una memoria para colocar en caché la dirección asignada en asociación con el suscriptor.
De conformidad con un tercer aspecto de la presente invención, se proporciona un método para encaminar mensajes de Protocolo de Inicio de Sesión entre una Función de Control de Llamada/Sesión de Servicio y un Servidor de Aplicación dentro de un Subsistema Multimedia IP, el método comprende: identificar en dicha Función de Control de Llamada/Sesión de Servicio una dirección de dicho Servidor de aplicación a asignar a un suscriptor dado; colocar en caché una asociación entre dicha dirección y dicho suscriptor; y utilizar dicha asociación para transferir futuros mensajes de Protocolo de Inicio de Sesión enviados a dicho suscriptor o provenientes de dicho suscriptor. De conformidad con otro aspecto de la presente invención, se proporciona un método para identificar un Servidor de
Aplicación SIP asignado a un suscriptor en un Subsistema
Multimedia IP, el método comprende: al asignar un Servidor de Aplicación SIP a un suscriptor, enviar desde el Servidor de Aplicación a un almacén central, una o varias direcciones de interfaz del servidor de aplicación o de otro servidor de aplicación; almacenar el (las) dirección (es) recibida (s) en el almacén central en asociación con la identidad de suscriptor; subsiguientemente recibir una solicitud del suscriptor u otra entidad de red, en un Servidor de Aplicación del Subsistema Multimedia IP, y en respuesta enviar una consulta a dicho almacén central; al recibir dicha consulta en dicho almacén central, identificar una dirección de Servidor de Aplicación (o. direcciones) asignada (s) al suscriptor, y enviar la(s) dirección (es) identificada (s) al Servidor de Aplicación que efectúa la consulta. El término "Servidor de Aplicación" como se utiliza aquí abarca el Servidor de Aplicación SIP convencional así como otros servidores que tienen una interfaz SIP. Preferentemente, dicho almacén central es el Servidor de Suscriptor Doméstico, la interfaz Sh utilizándose para transferir dicha (s) dirección (es) de interfaz al Servidor de Suscriptor Doméstico. Protocolos tales como el Protocolo de Acceso a Directorio Ligero (LDAP) y Lenguaje de Consulta Estructurada pueden utilizarse para transferir la(s) dirección (es) a otros almacenes centrales. Se observará que el servidor de aplicación que recibe la petición puede o no ser el servidor de aplicación asignado. En el caso en el cual no es el servidor de aplicación asignado, la solicitud es transferida al servidor de aplicación asignado utilizando una dirección identificada. La petición puede ser recibida en el servidor de aplicación por un distribuidor de extremo frontal, por ejemplo, o un extremo frontal de un XDMS . La solicitud puede ser enviada al servidor de aplicación a partir de una terminal de suscriptor a través de la interfaz Ut. El primer aspecto y el curto aspecto de la presente invención se emplean de manera útil en combinación y, en dicho caso el paso de enviar a partir del servidor de aplicación a un almacén central una o varias direcciones de interfaz del servidor de aplicación se efectúa después del envío de un "método" SIP, por ejemplo, una solicitud SIP o mensaje de registro, a partir de la Función de Control de Llamada/Sesión de Servicio al servidor de aplicación para un suscriptor del cual el servidor de aplicación no tiene actualmente conocimientos . De conformidad con un quinto aspecto de la presente invención se proporciona un servidor de aplicación para su uso en un Subsistema Multimedia IP, el servidor de aplicación comprende : una entrada para recibir un método SIP a partir de una Función de Control de Llamada/Sesión de Servicio para un suscriptor, identificar el servidor de aplicación como servidor asignado para el suscriptor; y enviar su(s) dirección (es) de interfaz o una dirección de interfaz o direcciones para otro servidor de aplicación, a un almacén central para almacenamiento en asociación con la identidad de suscriptor. De conformidad con un sexto aspecto de la invención se proporciona un servidor de aplicación para uso en un Subsistema Multimedia IP, el servidor de aplicación comprende: una entrada para recibir una petición con relación a un suscriptor; enviar una consulta a un almacén central, la consulta identifica al suscriptor; recibir una respuesta de un almacén central que contiene una dirección de un servidor de aplicación ya asignado al suscriptor; y si el servidor de aplicación asignado no es la aplicación que recibe la solicitud, enviar la solicitud a la dirección de servidor asignado. BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 ilustra esquemáticamente la integración de 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 de Servicio/Estado; La Figura 3 ilustra esquemáticamente un proceso para asignar SIP-AS a un suscriptor durante registro de IMS;
La Figura 4 ilustra esquemáticamente un proceso para manejar una solicitud de llamada saliente o entrante para un suscriptor registrado; La figura 5 ilustra esquemáticamente un proceso para manejar una solicitud de llamada entrante para un suscriptor no registrado; La Figura 6 ilustra esquemáticamente un proceso para manejar una solicitud recibida de un suscriptor a través de una interfaz no ISC en donde el suscriptor está registrado con el IMS; y La Figura 7 ilustra esquemáticamente un proceso para manejar una solicitud recibida de un suscriptor en una interfaz no ISC en donde el suscriptor no está registrado con el IMS. DESCRIPCIÓN DETALLADA DE CIERTAS MODALIDADES Los Estándares Técnicos 3GPP mencionados arriba describen el uso de criterios de filtro inicial (IFC) , 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 una llamada entrante es efectuada a un suscriptor no registrado. Convencionalmente, un IFC para un suscriptor contiene una dirección de Servidor de Aplicación de SIP específica (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 (dentro de la S-CSCF) y se coloca en caché en base a nodo y no en base a usuario . Se propone aquí reemplazar la dirección de Servidor de Aplicación específica con una identidad AS genérica, por ejemplo SIP-AS. Esto identifica un grupo predefinido de ASs, todos los cuales pueden proporcionar un servicio IMS dado. En particular, el criterio de filtro inicial (IFC) , almacenado en el HSS, es proporcionado con un nombre genérico de un servidor de aplicación (por ejemplo SIP-AS.operator.com). Al registrase un suscriptor (o al efectuarse una terminación de 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 en un nombre específico (por ejemplo SIP-ASl.operator.com) que es resuelto adicionalmente en una dirección IP, o bien la identidad genérica es resuelta directamente a un número de 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 IP, se requieren de dos desplazamientos redondos entre S-CSCF y DNS] . El IFC activa el suministro de un mensaje de registro de tercero (es decir, un mensaje de SIP REGISTER) por la S-CSCF a SIP-AS seleccionado. La S-CSCF recuerda la asociación entre el suscriptor y la dirección AS seleccionada y envía todos los mensajes subsiguientes para este grupo de filtros a la dirección específica SIP-AS. Para facilitar este proceso, el DNS está equipado con un nombre de dominio genérico que puede ser resuelto a un número de nombres de dominios totalmente calificados o direcciones de IP. El nombre de dominio genérico (por ejemplo, SIP-AS.operator.com, según un servicio IMS específico) puede representar un gran número de servidores de aplicación. El nombre de dominio totalmente calificado o dirección IP representa un servidor de aplicación específico (por ejemplo, SIP-AS32.operator.com en el caso de un FQDN) . Para permitir que las solicitudes de usuario sean recibidas en una interfaz que no involucra la S-CSCF en el enfoque de asignación de SIP-AS flexible descrito aquí, es provechoso permitir que un SIP-AS asignado coloque en caché su(s) dirección (es) de contacto en un almacén central, típicamente el HSS, en asociación con un perfil de suscriptor. Esto permite que una solicitud posterior, recibida a través de una interfaz de este tipo, sea transferida al SIP-AS asignado. Con referencia a la Figura 3, el procedimiento de asignación de SIP-AS será descrito ahora en el contexto de un registro de SIP para un suscriptor particular. Los pasos de este procedimiento son los siguientes, con la numeración de pasos correspondiente a la numeración utilizada en la Figura: la La terminal de suscriptor inicia un proceso de REGISTRO enviando el mensaje SIP REGISTER a la S-CSCF (a través de una P-CSCF) . lb Durante el proceso de registro, un perfil de registro para suscriptor es descargado a la S-CSCF a partir del
HSS. Este perfil de servicio contiene el criterio de filtro inicial que incluye una identidad genérica de servidor de aplicación. 2a Después de terminar el proceso de registro, la S-CSCF está informada por el IFC que debe enviar una solicitud de REGISTRO de tercero a un servidor de aplicación. La S-CSCF debe primero sin embargo solicitar la dirección de IP a partir de un servidor de DNS enviándole la identidad genérica. El servidor de DNS responde con un número de dirección IP que corresponde a los ASs disponibles respectivos. Las direcciones están acompañadas por ponderaciones de prioridad respectiva. 2b La S-CSCF selecciona una de las direcciones de IP devueltas para transferir el mensaje de REGISTER a ella. La selección se basa en una selección de tipo circuito cíclico, ponderada según la prioridad asignada por el DNS. La S-CSCF coloca en caché un mapeo entre el suscriptor y la dirección IP de AS seleccionado. 2c Un mensaje de tercero es enviado al AS seleccionado por la S-CSCF. 3 Al recibir el registro de tercero, el AS efectúa las tareas siguientes: - Almacena su propia dirección en el HSS. Esta dirección puede comprender de hecho un conjunto de direcciones para interfaces diferentes, por ejemplo, puede existir una dirección diferente para recepción de mensajes SIP, tráfico HTTP, etc. [La dirección (o una de las direcciones) puede ser la dirección SIP-AS proporcionada a la SI-CSCF durante el paso de resolución de identidad, aun cuando esto no tiene que ser el caso.] Recupera los datos de suscriptor específico de la aplicación solicitada a partir del HSS. - El AS indica al HSS que desea estar informado de cambios subsiguientes a los datos de suscriptor. En el corto plazo, el SIP-AS puede almacenar su dirección en el HSS utilizando "datos transparentes" en la interfaz Sh. A largo plazo, la dirección SIP-AS puede agregarse a los datos no transparentes en el HSS.
Se observará que, mientras en este ejemplo el HSS es el repositorio central para la dirección de AS (y dato de suscriptor) , otro repositorio central puede ser utilizado en lugar de el. Podría ser una base de datos acoplada (directamente) a un conjunto de ASs que implementan un servicio IMS o que es genérica para todos los ASs en un dominio de operador/proveedor de servicio. Al terminar el proceso, SIP-AS ha sido seleccionada para el suscriptor. El SIP-AS ha recuperado una copia de los datos de suscriptor a partir de HSS, y la S-CSCF ha colocado en caché la dirección del SIP-AS asignada para este usuario. El SIP-AS a también almacenado sus direcciones en el HSS en asociación con la identidad de suscriptor. Durante el borrado del registro, el SIP-AS remueve la dirección de AS almacenada a partir del HSS. Con referencia a la Figura 4, se describirá un procedimiento para manejar llamadas salientes o entrantes para un suscriptor ya registrado. El flujo para llamadas salientes y entrantes es el siguiente: 1 Una solicitud de SIP para el suscriptor es recibida por la S-CSCF. 2 La S-CSCF analiza la solicitud de SIP. La S-CSCF identifica la dirección de IP de AS previamente colocada en caché para este suscriptor. 3 La solicitud de SIP es enviada al SIP-AS. El SIP-AS tiene una copia de los datos específicos de solicitud para el suscriptor descargados durante el proceso de registro previo y efectúa el procesamiento de la solicitud de SIP. Con referencia ahora a la Figura 5, se describirá un procedimiento para manejar llamadas entrantes para un suscriptor no registrado. Puesto que el suscriptor todavía no está registrado, la S-CSCF no tiene una dirección de IP de
SIP-AS en caché para este suscriptor y tampoco el SIP-AS tiene los datos de suscriptor específico de aplicación a a partir de HSS. El flujo de proceso es el siguiente: 1 La S-CSCF recibe una solicitud de SIP de finalización.
2 La S-CSCF descarga el perfil de servicio a partir del HSS. Esto contiene el criterio de filtro inicial incluyendo una identidad genérica para el SIP-AS. 3a La S-CSCF analiza la solicitud de SIP. Si uno de los IFCs corresponde, la S-CSCF entiende que debe enviar la solicitud de SIP de finalización a un servidor de aplicación. La entidad de servidor de aplicación contenida en el IFC es un nombre genérico. La S-CSCF solicita por consiguiente la dirección de IP as partir de un servidor de DNS. El servidor de DNS responde con un número de dirección de IP. 3b La S-CSCF selecciona una de las direcciones de IP devueltas para transferir el mensaje REGISTER. La S-CSCF coloca en caché un mapeo entre el suscriptor y la dirección seleccionada de IP de AS. 4. La solicitud de SIP de finalización es enviada al SIP-AS seleccionado. 5. Al recibir la solicitud de SIP de finalización, el AS efectúa las acciones siguientes: Almacena su propia dirección (sus propias direcciones) para el usuario en el HSS. Recupera los datos de suscriptor específico de solicitud requerida a partir del HSS. El AS indica al HSS que desea estar informado de cambios subsiguientes a los datos de suscriptor. Durante el borrado del registro, el SIP-AS remueve la dirección de AS almacenada del HSS. Opcionalmente el SIP-AS y la S-CSCF pueden tener un temporizador que indica que los datos deben ser conservados durante un cierto lapso de tiempo después del borrado del registro. En este caso, el SIP-AS removerá la dirección de AS almacenada al vencer el temporizador. Se observará que, en algunos casos, por ejemplo, cuando el
SIP-AS transfiere una solicitud (recibida a partir del S- CSCF) a otro SIP-AS, las direcciones almacenadas en el HSS por el AS mencionado primero pueden ser direcciones para el otro AS. Esto puede ocurrir cuando el AS tiene una funcionalidad de distribución de extremo frontal o cuando no hay respuesta de un AS originalmente seleccionado, y se ha efectuado una nueva selección. Puede ocurrir también cuando existe una falta de correspondencia entre la dirección almacenada por un S-CSCF y el AS que da servicio al usuario. En este caso, el AS que recibe inicialmente la solicitud debe revisar si el suscriptor está asignado a otro AS buscando en la asociación usuario usuario-AS en HSS. Si existe, la solicitud debe ser transferida al AS correcto. Si el usuario no está asignado a un AS (no hay asociación usuario-AS en HSS), el AS debe escribir su dirección en HSS. Esto permite encaminar el tráfico desde el FE hacia el AS correcto. Después del registro de un suscriptor en el IMS, es posible que un suscriptor inicie cierta acción, por ejemplo, un cambio de datos y características de un servicio de IMS particular mediante el envío de una solicitud a un AS a través de la interfaz Ut. La entidad funcional que maneja el tráfico Ut se conoce como XDMS, Servidor de Administración de Documentos XML (XDMS) que se co-localiza típicamente con un AS particular. La dirección de este AS puede prealmacenarse en la terminal como una dirección por omisión para la interfaz Ut. De manera similar a la forma en la cual se maneja el tráfico de ISC, en donde la S-CSCF encamina las señalización al AS que da servicio a un usuario particular, se requiere de una entidad funcional de extremo frontal para asegurar que el tráfico de Ut es encaminado al XDMS co-localizado con el AS que da servicio al usuario. Una solicitud de una terminal de suscriptor enviada a través de la interfaz Ut es recibida por un extremo frontal de XDMS. El extremo frontal de XDMS busca la dirección del AS que se refiere a la funcionalidad XDMS, a través de la interfaz Sh (Nota: es una de las direcciones AS que fue almacenada en los procedimientos descritos arriba) . En el caso en el cual ninguna dirección SIP-AS esté almacenada, el extremo frontal seleccionará el mismo un SIP-AS y transferirá la solicitud a este SIP-AS. El SIP-AS al cual la solicitud es transferida almacenará entonces su dirección en el HSS, recuperará los datos de suscriptor del HSS (u otra ubicación) de almacenamiento central y efectuará el procesamiento de la solicitud. Con referencia a la Figura 5, se describirá a continuación un proceso genérico para el manejo de solicitudes de otras interfaces (incluyendo la interfaz Ut) cuando un AS ya ha sido asignado a un suscriptor. 1. Una solicitud es recibida a través de la interfaz a partir de una terminal de suscriptor. La solicitud es terminada en un "distribuidor de extremo frontal" para el servicio representado por este extremo frontal. 2. El FE-DIST solicita la dirección de AS para la aplicación a partir del HSS (u otra ubicación central) . 3. La dirección de AS es retornada al FE-DIST .
4. La solicitud es enviada por el FE-DIST al XDMS. Con referencia a la Figura 6, se describirá a continuación un proceso para el manejo de solicitudes a partir de otras interfaces (incluyendo la interfaz de Ut) , cuando un AS no ha sido ya asignado a un suscriptor. 1. Una solicitud es recibida de la terminal de suscriptor a través de la interfaz particular. La solicitud es finalizada en un "Distribuidor de extremo frontal" para el servicio representado por este extremo frontal. 2. El FE-DIST solicita la dirección de AS para el servicio a partir del HSS. 3. Una indicación en el sentido que ningún AS ha sido asignado es devuelta al FE-DIST . 4. El FE-DIST selecciona un AS (puede utilizar otras bases de datos para obtener los nombres como ASs válidos) .
. La solicitud es transferida al AS seleccionado. 6. El AS seleccionado efectúa lo siguiente: - El SIP-AS puede almacenar su nombre en el HSS. (Nota: Esto puede no ser requerido si la transacción debe ocurrir solamente una vez y no se espera que haya solicitudes subsiguientes) . - Lee los datos de suscriptor a partir del HSS. - Procesa la solicitud. En el caso en el cual una solicitud SIP sea subsiguientemente recibida en la S-CSCF, esta puede ser manejada por el S-CSCF seleccionando un nuevo SIP-AS utilizando la identidad genérica de AS de conformidad con el enfoque descrito arriba. El HSS es informado de la selección y a su vez informa el AS previamente asignado que ya no está asignado y que puede liberar datos almacenados y olvidar el usuario (como resultado del AS habiendo "suscrito" a cambios en el elemento de datos en el HSS) . La 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.