ES2639563T3 - Sistema de procesamiento de eventos - Google Patents

Abstract

Aparato de procesamiento de eventos (301) en una red de comunicaciones para uso al procesar mensajes de solicitud de iniciación de servicio en un sistema de procesamiento de eventos, siendo conectable el aparato (301) a una pluralidad de nodos de servicio desde los cuales un abonado puede recibir servicio durante el procesamiento de un evento de red, pudiendo transmitir cada dicho nodo de servicio un mensaje de respuesta de servicio que comprende datos particulares para operación del nodo de servicio, comprendiendo el aparato una función dispuesta, al recibir un primer mensaje de solicitud de iniciación de servicio enviado por un nodo servidor en una red actualmente implicada en el procesamiento de dicho evento de red, para solicitar mensajes de respuesta de servicio desde una pluralidad de nodos de servicio, y para controlar la operación de al menos alguno de dicha pluralidad de nodos de servicio implicados en el procesamiento del mismo evento de red basándose en los datos contenidos en dichos mensajes de respuesta de servicio, en el que, en el caso de que los datos contenidos en un mensaje de respuesta de servicio recibido desde uno de la pluralidad de nodos de servicio sea indicativo de una solicitud para un recurso de señalización que solapa o entra en conflicto con datos contenidos en un mensaje de respuesta de servicio recibido desde otro de la pluralidad de nodos de servicio, la función está dispuesta para procesar los datos contenidos en respectivos mensajes de respuesta de servicio basándose en datos de atributos para posibilitar el acceso al recurso de señalización solicitado por cada respectivo nodo de servicio implicado en el procesamiento del mismo evento de red, en el que los datos de atributo especifican reglas para interacción entre la pluralidad de nodos de servicio basándose en los mensajes de respuesta de servicio recibidos.

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Sistema de procesamiento de eventos Campo de la invencion

La presente invencion se refiere a un metodo y un sistema para el procesamiento de eventos en una red de comunicaciones, y es particularmente, pero no exclusivamente, adecuado para coordinar el aprovisionamiento de servicios en respuesta a activadores de iniciacion de servicio. Las realizaciones de la invencion son particularmente aplicables para uso al controlar la operacion de nodos de servicio, cada uno de los cuales esta dispuesto para proporcionar un servicio particular en una red movil, o una red fija, o a una combinacion de las dos.

Antecedentes de la invencion

Un operador movil tfpico comprende dos o mas socios de operacion, cada uno de los cuales ofrece servicios de red a medida. Como resultado los socios de operacion, vistos como una totalidad, a menudo comprenden diferentes y diversos servicios y equipo de servicio correspondiente. La responsabilidad para el desarrollo, integracion y operacion de los servicios de red radica en cada socio de operacion individual, y proporcionar esta diversidad es de manera tfpica extremadamente costoso para el operador cuando se ve como una totalidad, puesto que los costes asociados con desarrollar, soportar y comercializar los diversos servicios pueden ser significativos. Ademas, cuando se enfrenta con la tarea de integrar diversos servicios de red, el operador de red tiene varios problemas diffciles de superar, no solo debido al hecho de que las aplicaciones de servicio heredadas tfpicamente no son compatibles hacia delante, y, como ya se ha mencionado, muchos de los servicios de red estan desarrollados y administrados por diferentes proveedores de servicio.

La Figura 1 es un diagrama esquematico que muestra una disposicion de red movil convencional que comprende una estacion movil MS, componente de red de conmutacion de nodo servidor MSC, y registro de localizacion domestico HLR, junto con diversos nodos IN1, IN2, IN3, cada uno dispuesto para proporcionar un servicio de red inteligente. El mSc esta dispuesto para enviar mensajes a, y recibir mensajes desde, los nodos de servicios IN1, IN2, IN3 de acuerdo con datos de parametros de servicio recibidos desde el registro de localizacion domestico HLR tras el registro de la estacion movil MS con el MSC o de acuerdo con ajustes que se configuran estadfsticamente en la red domestica. Aunque el MS esta registrado con el MSC, el MSC monitoriza las apariciones de activadores de servicio (denominados Puntos de Deteccion (DP)), y, cuando se identifica un activador, el conmutador de MSC contacta con cualquier nodo de servicio que este asociado con el activador. En algunos sistemas conocidos, cada servicio IN1, IN2, IN3 opera independientemente entre sf (por ejemplo cada servicio puede proporcionarse por un proveedor de servicio diferente), y a menudo se da el caso de que diferentes servicios estan disenados para responder al mismo activador. Tfpicamente, en tales situaciones el MSC simplemente activa uno de los servicios de red, de esta manera fallando al proporcionar de manera eficaz al MS con los otros servicios. La publicacion de patente internacional numero WO97/50232 describe un sistema que esta disenado para mitigar este problema, y describe una red que tiene un denominado punto de mediacion, que tiene acceso a servicios que corresponden al mismo activador, junto con reglas que determinan la interoperacion entre los mismos, y controla la invocacion de los diversos servicios desde un unico punto. Sin embargo, el documento WO97/50232 requiere que las aplicaciones se categoricen en simples clasificaciones y unicamente permite un conjunto preconfigurado y tabulado de interacciones entre servicios, que es prescriptivo e inflexible. Adicionalmente, cada servicio unicamente puede invocarse de acuerdo con la regla, es decir unicamente una vez con respecto a un activador dado.

La solicitud de patente internacional que tiene el numero de publicacion WO01/31935 describe un sistema en el que la invocacion de diversos nodos de servicio se controla por medio de un gestor de servicio para proporcionar a un abonado con acceso a recursos de red. Estos nodos de servicio pueden coordinarse basandose en un “perfil de abonado”, que enumera aplicaciones accesibles para un abonado dado y especifica el orden en el que los nodos de servicio asociados con las aplicaciones se han de invocar. Generar o actualizar un perfil de abonado implica una cierta cantidad de pre-procesamiento de las aplicaciones (es decir analisis entre servicios) para identificar combinaciones de servicio que no entran en conflicto permitidas; el resultado del analisis entre servicios se almacena como un perfil en el HLR o similar.

Cada aplicacion, o nodo de servicio, requiere el uso de ciertos recursos de red, que se denominan en el documento WO01/31935 como “tipos de control”. Estos se especifican cuando un nodo de servicio registra su aplicacion asociada y se usan para determinar la coexistencia de respectivas aplicaciones con relacion a un evento de red dado. De manera importante el documento WO01/31935 no permite acceso al mismo tipo de control por dos o mas aplicaciones durante un evento de red dado.

El documento WO01/31935 tambien describe asignar ciertos tipos de control en tiempo real, desde una agrupacion de tipos de control y en relacion con un servicio espedfico solicitado por un abonado particular. La agrupacion comprende tipos de control que no se han “reservado de manera fija” por un servicio en un perfil de abonado de la manera anteriormente descrita. Esto permite que el aprovisionamiento de servicio sea mas flexible de lo que sena

5

10

15

20

25

30

35

40

45

50

55

60

65

de otra manera, puesto que las solicitudes de servicios no se rechazan basandose en lo que pueden necesitar, sino en su lugar basandose en lo que realmente necesitaran para el servicio solicitado y abonado solicitante.

Aunque esta disposicion proporciona flexibilidad adicional, sin embargo, la solicitud del ultimo nodo de servicio solicitante, se rechazara si un nodo de servicio realmente necesita un tipo de control que ya se ha reservado por una aplicacion implicada en el aprovisionamiento del evento de red. En resumen, la invencion descrita en el documento WO01/31935 es basicamente un dispositivo para calcular combinaciones de servicio permitidas y que no entran en conflicto. Por lo tanto, no preprogramando todos los tipos de control en un perfil de abonado, el documento WO01/31935 proporciona flexibilidad mejorada, pero no resuelve el problema de como tratar con solicitudes que entran en conflicto para el mismo tipo de control (siendo este un problema separado y uno que no se trata en el documento WO01/31935).

Ademas de la existencia de diferentes nodos de servicio que compiten por el mismo activador, la convergencia tecnica entere los dominios de las telecomunicaciones, la informatica y la multimedia ha dado lugar a un nuevo entorno para el desarrollo y aprovisionamiento de servicios de telecomunicaciones. Esto ha obligado a tanto operadores de telecomunicaciones como proveedores de servicio a desarrollar y desplegar nuevos servicios y aplicaciones residenciales y empresariales. Para cumplir este desaffo los operadores y proveedores de servicio han buscado sustituir los sistemas propietarios cerrados con plataformas comunes normalizadas, abiertas, interoperables y comunes, y al menos alguno de los servicios anteriormente mencionados se realizan en tales plataformas abiertas.

Parlay es un consorcio de multiples distribuidores abierto formado para desarrollar tales API abiertas independientes de tecnologfa, que posibilita a los distribuidores de servicio de internet, distribuidores de dispositivos de red, desarrolladores de software, proveedores de servicio, ASP y empresas, crear aplicaciones que pueden ejecutarse a traves de multiples redes moviles y operadoras fijas. La norma Parlay/OSA (Arquitectura de Servicios Abierta) define una API (Interfaz de Programacion de Aplicacion) que es agnostica en cuanto a la tecnologfa y esta configurada para usar protocolos y tecnologfas tales como SIP (protocolo de iniciacion de sesion), JAIN (API de Java para redes inteligentes) y servicios web para comunicar con dispositivos y servicios de terceros en diferentes dominios.

Aunque esta estructura ha mejorado enormemente la interoperabilidad de los servicios, existen, sin embargo, problemas de implementacion asociados con servicios separados que registran interes en eventos de red. En la siguiente descripcion se supone que “una aplicacion/servicio que registra interes en...”significa” “una aplicacion/servicio que esta dispuesto para reaccionar a...”, y que “un evento de red” significa, por ejemplo, un activador de la red (o de hecho otro servicio o nodo de aplicacion) con respecto a un destino especificado y direccion de origen.

Actualmente hay 14 Funciones de Control de Servicio (SCF), que incluyen diversas SCF de control de llamada generico (GCC) y control de llamada de multiples partes (MPCC); entre ellas, las SCF de GCC/MPCC mapean todos los mensajes de la red inteligente (IN), y pueden por lo tanto invocar todas las capacidades de red. Usando las API Parlay, cualquier servicio dado puede registrar y anular el registro de los eventos de red (por medio de, por ejemplo, las SCF de GCC, los metodos enableCallNotification() y disableCallNotification() respectivamente y para las SCF de MPCC, por medio de los metodos createNotification() y destroyNotification() respectivamente) correspondiendo cada solicitud de registro a uno o mas abonados (direccion de origen) y/o direccion o direcciones de destino (por ejemplo un numero especificado en el caso de servicios de traduccion de numero). Una representacion simplificada de la red y dominios de OSA se muestra en la Figura 2, y un ejemplo del encaminamiento de mensajes de registro de GCC entre OSA y dispositivos de red se muestra en la Figura 3. En este ejemplo una aplicacion App1 esta dispuesta para comprobar el equilibrio de abonados especificados antes de la asignacion de recursos de red, y por consiguiente la App1 invoca el metodo enableCallNotification() cada vez que determina que el equilibrio del abonado necesita comprobarse antes de asignar recursos de red con respecto al servicio solicitado. Esto da como resultado un mensaje de MAP AnyTimeModification() que se envfa al HLR para activar la informacion se suscripcion necesaria (O-CSI, D-CSI (activada en relacion con la direccion del abonado)). Habiendo registrado satisfactoriamente este evento de red, cuando un abonado especificado solicita posteriormente un servicio (es decir O-CSI (datos que identifican el abonado)), se invoca la App1 y se usa para controlar al menos la parte inicial del procedimiento de aprovisionamiento de servicio.

El metodo enableCallNotification() se pretende puramente para que las aplicaciones indiquen su interes de que sean notificadas cuando tienen lugar ciertos eventos. Es posible suscribirse a un cierto evento para un intervalo total de direcciones, por ejemplo la aplicacion puede indicar que desea estar informada de cuando se realiza una llamada a cualquier numero que empiece por 800. Si una aplicacion ya ha solicitado notificaciones con criterios que solapan el criterio especificado, la solicitud se rechaza con, por ejemplo, P_GCCS_INVALID_CRITERIA para un mensaje de registro de GCC y P_INVALID_CRITERIA para un mensaje de registro de MPCC. Se dice que los criterios solapan si ambas direcciones de origen y de destino de finalizacion solapan y se usa el mismo plan de numero y se usa el mismo CallNotificationType (por ejemplo activador de red). Como resultado, en la mayona de las configuraciones unicamente una aplicacion puede hacer una solicitud para un conjunto dado de criterios.

British Telecommunications Exact Technologies ha identificado que teniendo una regla estricta y rapida de “algun solapamiento-no co-existencia” es demasiado restrictiva y ha presentado una solucion mediante la cual la GW

5

10

15

20

25

30

35

40

45

50

55

60

65

Parlay comprende una Funcion de Capacidad de Servicio de Gestion de Polttica (SCF), dispuesta para cooperar con la SCF de Control de Llamada mostrada en la Figura 2 cuando una aplicacion intenta registrarse con la pasarela. Su SCF de Gestion de Polttica gestiona un almacen de perfiles de usuario en el que se almacenan los detalles de servicios a los que ha accedido un abonado dado, junto con los respectivos eventos activadores. Los perfiles de usuario se rellenan unicamente despues de que la SCF de Gestion de Polftica ha comprobado que las aplicaciones pueden coexistir, habiendose comprobado su coexistencia por medio de una funcion de procesamiento de interaccion de caractenstica que se proporciona con metadatos que especifican reglas de interaccion de aplicacion (denominadas reglas de “interaccion de caractenstica”). Esta solucion, por lo tanto, requiere reglas que especifican interacciones entre aplicaciones y servicios para que se prealmacenen y sean accesibles en respuesta a unas solicitudes de registro de aplicacion. Cuando un evento de red se recibe posteriormente desde la red, la SCF de Control de Llamada accede a cualquier perfil de usuario que corresponda al abonado asociado con el evento de red y recupera detalles de aplicaciones y servicios almacenados en el mismo, controlando su respectiva invocacion de manera secuencial. Hay varios problemas con esta solucion, no solo resultantes del hecho de que las solicitudes de registro se resuelven en vista de que esa/esas aplicacion o aplicaciones ya se han registrado. Las desventajas de esta solucion pueden observarse a partir de la consideracion del siguiente escenario, en el que una primera aplicacion A se ha registrado para el usuario, habiendose actualizado el perfil de usuario para incluir datos indicativos de la aplicacion A. Si una solicitud de registro se recibe posteriormente desde la aplicacion B, y si las reglas de interaccion indican que A es incompatible con B, la solicitud de registro de la aplicacion B fallara. Si, posteriormente, la aplicacion A anula el registro para el abonado, no hay medio de volver a capturar la aplicacion B, incluso aunque no haya ahora razon por la que el abonado no pueda recibir el servicio de la aplicacion B.

Es un objeto de la invencion proporcionar un nivel mejorado de integracion y flexibilidad para servicios de red.

Sumario de la invencion

De acuerdo con un primer aspecto de la presente invencion se proporciona un aparato de procesamiento de eventos para uso al procesar mensajes de solicitud de iniciacion de servicio en un sistema de procesamiento de eventos, siendo el aparato conectable a una pluralidad de nodos de servicio desde los cuales un abonado puede recibir servicio durante el procesamiento de un evento de red, pudiendo transmitir cada dicho nodo de servicio un mensaje de respuesta de servicio que comprende datos particulares para operacion del nodo de servicio, comprendiendo el aparato una funcion dispuesta, al recibir un primer mensaje de solicitud de iniciacion de servicio enviado por un nodo servidor en una red actualmente implicada en el procesamiento de dicho evento de red, para solicitar mensajes de respuesta de servicio desde una pluralidad de nodos de servicio, y para controlar la operacion de al menos alguno de dicha pluralidad de nodos de servicio implicados en el procesamiento del mismo evento de red basandose en los datos contenidos en dichos mensajes de respuesta de servicio,

en el que, en el caso que los datos contenidos en un mensaje de respuesta de servicio recibido desde uno de la pluralidad de nodos de servicio sea indicativo de una solicitud para un recurso de senalizacion que solapa o entra en conflicto con datos contenidos en un mensaje de respuesta de servicio recibido desde otro de la pluralidad de nodos de servicio, la funcion esta dispuesta para procesar los datos contenidos en respectivos mensajes de respuesta de servicio basandose en datos de atributos para posibilitar el acceso al recurso de senalizacion solicitado por cada respectivo nodo de servicio implicado en el procesamiento del mismo evento de red,

en el que los datos de atributo especifican reglas para interaccion entre la pluralidad de nodos de servicio basandose en los mensajes de respuesta de servicio recibidos.

Durante el procesamiento de un evento de red tal como una llamada, este aspecto abre la posibilidad de la operacion coordinada de, por ejemplo, un primer nodo de servicio, que, durante la ejecucion, depende del contenido de datos desde otro (segundo) nodo de servicio como parte del procesamiento de un evento de red, con dicho otro nodo de servicio. Cualquier nodo de servicio dado aparece de manera efectiva como un sistema abierto al aparato, que significa que el aparato puede interactuar con el nodo de servicio en uno o mas punto o puntos durante el procesamiento de un evento de red.

Las realizaciones de la invencion tambien proporcionan un medio de integracion de la funcionalidad desde diferentes servicios de acuerdo con reglas y condiciones predeterminadas seleccionables. Preferentemente las reglas se recuperan en respuesta a la recepcion del mensaje de solicitud de iniciacion de servicio y pueden incluir, por ejemplo, establecer eventos y reglas de espera condicional que especifican que nodo de servicio invocar y cuando se han cumplido las condiciones de espera. El aparato proporciona de esta manera un medio flexible de procesamiento de un evento de red, en el que los servicios estan “mezclados y adaptados” de manera eficaz dinamicamente de acuerdo con los datos de reglas y condiciones seleccionados.

De manera convencional, la funcion puede configurarse para controlar la operacion de un nodo de servicio dado mas de una vez durante el mismo evento de red basandose en el contenido de un dicho mensaje de respuesta de servicio. La funcion se ve implicada de manera eficaz a lo largo de todo el dialogo entre los diversos nodos de servicio y nodos de servidores; esto es completamente diferente de los sistemas conocidos tales como los descritos en el documento WO97/50232, en el que los activadores recibidos posteriormente pueden tratarse unicamente como eventos separados, provocando que el punto de mediacion realice una busqueda de servicios como si el activador en cuestion se recibiera como parte de un evento de red no relacionado. Esta caractenstica es particularmente

5

10

15

20

25

30

35

40

45

50

55

60

65

beneficiosa para uso con servicios que requieren alertas en respuesta a diversos eventos (tal como cuando una parte llamada esta ocupada o no disponible), y que puede consultarse una pluralidad de ocasiones, respondiendo cada vez con detalles de contacto alternativos para una parte llamada.

En una disposicion la funcion transporta datos indicativos de uno o mas activadores de iniciacion de servicio en un mensaje de solicitud de servicio a un respectivo nodo de servicio, siendo los activadores cualesquiera de ese o esos enviados desde el nodo servidor al aparato y/o un activador modificado por la funcion. La funcion puede modificar tambien datos tales como claves de servicio, protocolos y/o dfgitos llamados que acompanan la solicitud de iniciacion de servicio, basandose en los datos recuperados, y/o basandose en el contenido de los mensajes de respuesta de servicio recibidos desde los nodos de servicio implicados en el evento de red. Los mensajes de solicitud de servicio posteriores pueden a continuacion formularse basandose en los datos modificados. Una ventaja particular de proporcionar los medios para modificar los activadores es que el intervalo de funcionalidad accionable por la funcion se mejora sobre lo que es posible con los sistemas conocidos, puesto que diferentes servicios y aplicaciones responden a diferentes activadores. Esencialmente, cambiando los activadores implicados en un evento de red dado, el numero de servicios (y por lo tanto el intervalo de funcionalidad) que puede invocarse en relacion con el evento de red aumenta. Ademas la funcion puede disponerse para monitorizar la recepcion de mensajes de solicitud de iniciacion de servicio adicionales - en particular, datos de activador - como resultado de la operacion, y la operacion de control de nodos de servicio basandose en datos recuperados que corresponden a los datos de activador nuevamente recibidos.

En algunos casos un nodo de servicio puede, en un mensaje de respuesta de servicio, solicitar mensajes de solicitud de iniciacion tales como puntos de activador que entranan de otra manera en conflicto con solicitudes similares de otros nodos de servicio implicados en el evento de red. Tales conflictos potenciales pueden evitare por recurso a datos de preferencia que especifican un orden de preferencia entre, y condiciones dependientes de, datos recibidos desde dichos diferentes nodos de servicio. El aparato asegura de esta manera que todos los mensajes de solicitud de iniciacion transmitidos posteriormente (o mensajes de invocacion de servicio) asociados con el evento de red estan sin conflictos.

Mas espedficamente, en respuesta a recibir dicho primer mensaje de solicitud de iniciacion de servicio, el aparato esta dispuesto para transmitir segundos mensajes de solicitud de iniciacion de servicio a dos o mas de dichos nodos de servicio en la secuencia seleccionada. Esta secuencia se selecciona de acuerdo con logica de procesamiento de llamada especificada, e incluye eventos que son dependientes de respuestas desde uno o mas de dichos nodos de servicio. Por ejemplo, el aparato puede disponerse para procesar un mensaje de respuesta de nodo de servicio desde un primer nodo de servicio antes de transmitir un segundo mensaje de solicitud de iniciacion de servicio a un segundo nodo de servicio.

Preferentemente la logica de procesamiento de llamada se almacena en un sistema de almacenamiento de datos que es accesible por el aparato y esta dispuesto para almacenar datos con respecto a una pluralidad de abonados. En una disposicion los datos almacenados incluyen datos de servicio que especifican servicios proporcionados por una pluralidad de dichos nodos de servicio, y una o mas condiciones que especifican una relacion entre dichos servicios. Esta relacion entre los servicios define de manera eficaz la logica de procesamiento de llamada y se indexa de acuerdo con los activadores de iniciacion de servicio.

Ejemplos de activadores de iniciacion de servicio incluyen, y no estan limitados a, eventos y activadores asociados con control de llamada, interaccion y mensajena llevados por tales protocolos ,tales como puntos de deteccion de Camel y Red Inteligente (INAP, INAP extendido, CAP); eventos de MAP tales como mensajes de Actualizacion de Localizacion y ForwardSM; eventos asociados con el envfo de mensajes de datos tales como mensajes de MMS y SMS; numeros de configuracion (por ejemplo B#) y eventos SIP tales como aquellos llevados por MSCML, VXML, CCXML y NETANN.

En una disposicion, uno de los nodos de servicio es un nodo de pasarela que proporciona acceso a una pluralidad de nodos de servicio adicionales mas alla de la pasarela; preferentemente el aparato comprende un componente de interfaz dispuesto para proporcionar acceso, mediante el nodo de pasarela, al mismo. Los nodos de servicio adicionales pueden a continuacion estar dispuestos para descubrir la funcionalidad del aparato, y usar la informacion descubierta para disenar de manera proactiva servicios de acuerdo con la misma.

En resumen, el aparato puede observarse como que opera en dos modos: uno primero, en el que se recuperan los datos accionables que corresponden a la solicitud de iniciacion de servicio; y uno segundo, en el que el aparato invoca nodos de servicio basandose en los datos recuperados, incluyendo tambien el segundo modo monitorizar, y la actuacion sobre los datos recibidos desde los nodos de servicio accionados en forma de mensajes de respuesta de servicio.

En una disposicion, en la recepcion de un segundo mensaje de solicitud de iniciacion de servicio enviado por un nodo servidor en la red actualmente implicada en el procesamiento del mismo evento de red, la funcion puede controlar la operacion de al menos uno de dicha pluralidad de nodos de servicio, y como resultado de la operacion, transmitir un mensaje de respuesta de servicio al nodo servidor desde el cual se recibe el segundo mensaje de

5

10

15

20

25

30

35

40

45

50

55

60

65

solicitud de iniciacion de servicio. El primer y segundo mensajes de solicitud de iniciacion de servicio podnan enviarse desde los mismos o diferentes nodos servidores; el aparato podna usarse, por ejemplo, para transferir el procesamiento de eventos desde un nodo servidor en una red visitante a un nodo servidor en la red domestica en cualquiera de los siguientes escenarios: durante el aprovisionamiento del Servicio Internacional de Voz sin Interrupciones; mientras se traduce un numero corto a un numero de conexion completa; mientras se efectua diversos servicios de mensajena y cualquier combinacion de estos y otros servicios conocidos y futuros distintos.

De acuerdo con un segundo aspecto de la presente invencion se proporciona un sistema de procesamiento de eventos para procesar activadores de iniciacion de servicio, comprendiendo el sistema de procesamiento de eventos:

una pluralidad de nodos de servicio desde los cuales un abonado puede recibir servicio durante el procesamiento de un evento de red;

un nodo servidor dispuesto para almacenar datos que definen un conjunto de diferentes activadores de iniciacion de servicio para un abonado, correspondiendo cada uno de dicho activador de iniciacion de servicio respectivamente a un primer mensaje de solicitud de iniciacion de servicio diferente;

un sistema de almacenamiento dispuesto para almacenar datos con respecto a una pluralidad de abonados, incluyendo los datos almacenados datos de servicio que especifican servicios disponibles a partir de una pluralidad de dichos nodos de servicio, y una o mas condiciones que especifican una relacion entre dichos servicios;

un sistema de procesamiento dispuesto, en respuesta a la recepcion de dichos primeros mensajes de solicitud de iniciacion de servicio enviados desde dicho nodo servidor con respecto al abonado, para recuperar datos de servicio asociados con el abonado desde dicho sistema de almacenamiento, en el que el sistema de procesamiento esta dispuesto para transmitir al menos un segundo mensaje de solicitud de iniciacion de servicio a cada uno de un conjunto predeterminado de diferentes nodos de servicio de acuerdo con los datos recuperados.

En este aspecto de la invencion el sistema de almacenamiento puede estar ffsica y logicamente separado del sistema de procesamiento, lo que significa que las actualizaciones a los datos de servicio y las condiciones que especifican las relaciones entre los servicios pueden modificarse completamente de manera independiente de tanto la operacion del sistema de procesamiento como de la transferencia de mensajes entre los nodos de servicio, el nodo servidor y el sistema de procesamiento.

De acuerdo con un tercer aspecto de la invencion se proporciona el aparato para procesar mensajes de solicitud de iniciacion de servicio en un sistema de procesamiento de eventos, siendo el aparato conectable a un nodo servidor en una red implicada en el procesamiento un evento de red y a una pluralidad de nodos de servicio desde los cuales un abonado puede recibir servicio durante el procesamiento del evento de red, pudiendo el nodo servidor almacenar datos que definen un conjunto de diferentes activadores de iniciacion de servicio para un abonado y transmitir un conjunto de primeros mensajes de solicitud de iniciacion de servicio a una pluralidad de diferentes nodos de servicio, correspondiendo cada uno de dicho primer mensaje de solicitud de iniciacion de servicio respectivamente a uno diferente de dichos activadores de iniciacion de servicio, en el que el aparato es sensible a diferentes dichos primeros mensajes de solicitud de iniciacion de servicio durante el procesamiento del mismo evento de red, y esta dispuesto para transmitir al menos un segundo mensaje de solicitud de iniciacion de servicio a cada uno de un conjunto predeterminado de diferentes nodos de servicio en respuesta a recibir uno de dicho mensaje de solicitud de iniciacion de servicio.

El aparato configurado de acuerdo con el tercer aspecto puede responder a diferentes activadores recibidos durante el mismo evento de red e identificar los activadores como que son parte del mismo evento de red. Esto proporciona una manera particularmente conveniente de controlar, por ejemplo, dispositivos de conmutacion asociados con una llamada, y transferir una llamada entre diferentes redes, desde las que pueden recibirse diferentes activadores durante el procesamiento de la misma llamada.

Adicionalmente en las disposiciones de este aspecto de la invencion, un nodo servidor, tal como un conmutador, transmite un primer mensaje de solicitud de iniciacion de servicio al aparato, que puede enviar segundos mensajes de iniciacion de servicio a dos o mas nodos de servicio. Estos segundos mensajes de iniciacion de servicio pueden ser los mismos que los del primer mensaje de solicitud de iniciacion de servicio, y uno cualquiera del segundo mensaje de iniciacion de servicio puede ser el mismo que, o diferente a, otro segundo mensaje de iniciacion de servicio.

De acuerdo con un aspecto adicional de la presente invencion se proporciona un aparato para procesar mensajes de solicitud de iniciacion de servicio en un sistema de procesamiento de eventos de red, siendo el aparato conectable a una pluralidad de nodos de servicio desde los cuales un abonado puede recibir servicio durante el procesamiento de una llamada, y que comprende una funcion dispuesta, al recibir un primer mensaje de solicitud de iniciacion de servicio enviado por un nodo servidor en una red actualmente implicada en el procesamiento de una llamada, para controlar la operacion de al menos uno de dicha pluralidad de nodos de servicio, en el que, como resultado de la operacion, la funcion esta dispuesta para generar un primer mensaje de respuesta de servicio y para transmitir el

5

10

15

20

25

30

35

40

45

50

55

60

65

mismo al nodo servidor desde el que se recibe el primer mensaje de solicitud de iniciacion de servicio, y en la recepcion de un segundo mensaje de solicitud de iniciacion de servicio enviado por un nodo servidor en la red actualmente implicada en el procesamiento del mismo evento de red, la funcion esta dispuesta para reanudar el control de al menos uno de dicha pluralidad de nodos de servicio.

Este aspecto de la invencion posibilita que el aparato permanezca implicado en el procesamiento de un evento de red despues de que el manejo del evento haya pasado entre diferentes nodos servidores en la red. Tfpicamente el aparato se configurara para monitorizar la recepcion del segundo mensaje de solicitud de iniciacion de servicio y continuara el control del procesamiento de eventos cuando se recibe el segundo mensaje de solicitud.

De acuerdo con un aspecto adicional de la invencion se proporciona un aparato para procesar mensajes de solicitud de iniciacion de servicio en un sistema de procesamiento de eventos de red, siendo el aparato conectable a un nodo servidor en una red implicada en el procesamiento del evento de red y a una pluralidad de nodos de servicio desde los cuales un abonado puede recibir servicio durante el procesamiento de dicho evento de red, pudiendo almacenar el nodo de servicio datos que definen un conjunto de diferentes activadores de iniciacion de servicio para un abonado y de transmitir unos individuales de un conjunto de primeros mensajes de solicitud de iniciacion de servicios al aparato, correspondiendo cada dicho primer mensaje de solicitud de iniciacion de servicio respectivamente a uno diferente de dichos activadores de iniciacion de servicio, en el que el aparato es sensible a uno de dichos primeros mensajes de solicitud de iniciacion de servicio para transformar el activador de iniciacion de servicio asociado en datos indicativos de un segundo activador de iniciacion de servicio, y para solicitar un mensaje de respuesta de servicio desde al menos uno de dicho nodo de servicio basandose en el segundo activador de iniciacion de servicio.

Este aspecto es particularmente conveniente para situaciones en las que el conjunto de activadores disponibles para el nodo servidor (conmutador) no incluye activadores que corresponden a ciertos servicios. En las disposiciones de este aspecto de la invencion, el aparato transforma los datos de activador que recibe, preferentemente usando datos incluidos en el mensaje de solicitud de iniciacion de servicio, tal como el ID de la parte llamada, para avanzar eventos de red que fallanan al manejarse correctamente de otra manera, un ejemplo de este tipo es el procesamiento de llamadas B#, para las que se proporciona unicamente el conjunto requerido de activadores a dispositivos de conmutacion en redes habilitadas para CAMEL 3. Otro ejemplo es el procesamiento de un numero de operador de lmea fija, un intervalo de numeros, un numero de operador movil o un intervalo de numeros, correspondiendo cada uno a un servicio particular o intervalo de servicios.

De acuerdo con un aspecto adicional mas de la invencion se proporciona una red movil que comprende una pluralidad de dichos aparatos de procesamiento de eventos, comprendiendo cada uno uno o mas nodos de servicio de pasarela dispuestos para proporcionar acceso a nodos de servicio adicionales. Ventajosamente la red movil esta dispuesta de manera que una cualquiera de las pasarelas puede acceder a uno cualquiera de los nodos de servicio adicionales, proporcionando de esta manera un conjunto de servicios consolidado para la red movil.

Las realizaciones de la invencion pueden aplicarse para controlar, directamente, dichos uno o mas otros nodos de servicio de manera accesible mediante el nodo de servicio de pasarela. Por lo tanto, ventajosamente, la invencion puede implementarse en lo que es de manera eficaz “el otro lado de la pasarela” y controlar la operacion de, por ejemplo, aplicaciones de servicio de OSA.

Se ha de observar que, en general, cada nodo de servicio esta configurado para proporcionar un servicio de red espedfico, y en la siguiente descripcion, esto se denomina como servicio de red y/o aplicacion de servicio.

De acuerdo con un aspecto adicional de la presente invencion se proporciona un aparato para procesar mensajes de solicitud de registro de servicio en un sistema de procesamiento de eventos, incluyendo cada uno de dichos mensajes de solicitud de registro de servicio datos de registro que identifican un nodo de servicio, un activador de iniciacion de servicio y un abonado con respecto al que se refiere la solicitud de registro, siendo el aparato conectable a un nodo servidor en una red implicada en procesamiento de eventos y a un nodo de servicio desde el que un abonado puede recibir servicio durante el procesamiento de eventos, pudiendo el nodo servidor transmitir una pluralidad de mensajes de solicitud de iniciacion de servicio a dichos aparatos, correspondiendo cada mensaje de solicitud de iniciacion de servicio respectivamente a diferentes activadores de iniciacion de servicio, en el que el aparato es sensible a la recepcion de uno de dichos mensajes de solicitud de registro de servicio enviados desde un nodo de servicio de registro para almacenar datos de registro indicativos del nodo de servicio registrado y activador de iniciacion de servicio correspondiente en asociacion con el abonado, siendo dichos datos de registro para uso al procesar mensajes de solicitud de iniciacion de servicio enviados desde dicho nodo servidor con respecto al abonado, estando dispuesto el aparato para almacenar datos de registro para una pluralidad de mensajes de solicitud de registro de servicio identificando cada uno un nodo de servicio diferente y el mismo abonado, en el que el aparato esta dispuesto para definir un orden de preferencia entre dichos diferentes nodos de servicio despues de que se han recibido dichos datos de registro.

Por lo tanto con las realizaciones de este aspecto de la invencion, las interacciones entre nodos de servicio se resuelven despues de que se haya completado el registro por medio de datos que definen un orden de preferencia

5

10

15

20

25

30

35

40

45

50

55

60

65

entre los nodos. Como resultado y en comparacion con sistemas conocidos, las solicitudes de registro no se rechazan por motivos de criterios solapantes (las solicitudes ilegales o no soportadas pueden rechazarse aun) sino que en su lugar se indican y las aplicaciones se invocan posteriormente de acuerdo con los datos de preferencia.

Una ventaja significativa asociada con este aspecto de la invencion es que, puesto que las solicitudes de registro no se rechazan, todas estas aplicaciones para las que un abonado se ha suscrito para el servicio pueden activarse en el momento de la recepcion de un correspondiente mensaje de solicitud de iniciacion de servicio. Se apreciara que los datos de preferencia tienen en cuenta cualesquiera conflictos potenciales entre servicios.

En una disposicion el aparato esta dispuesto para almacenar dichos datos de registro si el mensaje de solicitud de registro se recibe desde un nodo de servicio identificado como accesible para el abonado, proporcionando de esta manera un medio de verificacion, o de otra manera, que el abonado de hecho ha accedido al nodo de servicio solicitante.

Ademas, en respuesta a la recepcion de un segundo y posteriores mensajes de solicitud de registro el aparato puede estar dispuesto para recuperar datos de interaccion que especifican interacciones en tiempo real posteriores entre los correspondientes dos o mas nodos de servicio y para almacenar dichos datos de interaccion. Los datos de interaccion definen dicho orden de preferencia entre dichos diferentes nodos de servicio. Posteriormente, y en respuesta a recibir un primer mensaje de solicitud de iniciacion de servicio, el aparato puede transmitir segundos mensajes de solicitud de iniciacion de servicio a dos o mas de dichos nodos de servicio en la secuencia seleccionada en dependencia de los datos de preferencia, y que incluyen eventos que son dependientes de respuestas desde uno o mas de dichos nodos de servicio. De manera conveniente el aparato puede disponerse para procesar un mensaje de respuesta de nodo de servicio desde un primer nodo de servicio antes de transmitir un segundo mensaje de solicitud de iniciacion de servicio a un segundo nodo de servicio durante el mismo evento de red.

Como alternativa, el aparato puede estar dispuesto para recuperar datos de interaccion que especifican interacciones entre correspondientes dos o mas nodos de servicio en respuesta a la recepcion del mensaje de solicitud de iniciacion de servicio antes de continuar de la manera anteriormente descrita.

De manera convencional el aparato esta en asociacion operativa con una funcion configurada de acuerdo con aspectos de la invencion anteriormente descritos.

Las caractensticas y ventajas adicionales de la invencion seran evidentes a partir de la siguiente descripcion de realizaciones preferidas de la invencion, proporcionada a modo de ejemplo unicamente, que se realiza con referencia a los dibujos adjuntos.

Breve descripcion de los dibujos

La Figura 1 es un diagrama esquematico que muestra la operacion de una red movil convencional dispuesta para entregar servicios de red a un abonado;

La Figura 2 es un diagrama esquematico que muestra una red que tiene acceso a un dominio de OSA, la interfaz de API de OSA y el protocolo en el que se mapean los metodos de clase de API a diversos protocolos de red;

La Figura 3 es un diagrama esquematico que muestra un ejemplo de flujos de mensajena entre el dominio de OSA y el dominio de red;

La Figura 4 es un diagrama de bloques esquematico que muestra componentes de un sistema de procesamiento de eventos de acuerdo con una realizacion de la invencion;

La Figura 5 es un diagrama de bloques esquematico que muestra componentes de un sistema de procesamiento de eventos de acuerdo con una segunda disposicion de una realizacion de la invencion;

La Figura 6 es un diagrama de bloques esquematico que muestra componentes de un sistema de procesamiento de eventos de acuerdo con una tercera disposicion de una realizacion de la invencion;

La Figura 7 es un diagrama de bloques esquematico que muestra componentes de registro de una pasarela de OSA de acuerdo con una realizacion de los aspectos de registro de la invencion;

La Figura 8 es un diagrama esquematico que muestra un ejemplo de un proceso de registro de acuerdo con una primera realizacion de registro;

La Figura 9 es un diagrama esquematico que muestra contenidos del Sistema de Aprovisionamiento de Servicio de la Figura 5 de acuerdo con la primera realizacion de registro mostrada en la Figura 8;

La Figura 10 es un diagrama esquematico que muestra un ejemplo de un proceso de registro de acuerdo con una segunda realizacion de registro;

La Figura 11 es un diagrama esquematico que muestra contenidos del Sistema de Aprovisionamiento de Servicio de la Figura 5 de acuerdo con la segunda realizacion de registro mostrada en la Figura 10;

La Figura 12 es un diagrama de bloques esquematico que muestra componentes de un sistema de procesamiento de eventos de acuerdo con una realizacion adicional de la invencion;

La Figura 13 es un diagrama de bloques esquematico que muestra, en mas detalle, componentes de un sistema de procesamiento de eventos mostrado en la Figura 6;

5

10

15

20

25

30

35

40

45

50

55

60

65

La Figura 14 es un diagrama de bloques esquematico que muestra, en mas detalle, un componente de interaccion de servicio del sistema de procesamiento de eventos mostrado en las Figuras 4, 5, 6, 12 y 13;

La Figura 15 es un diagrama esquematico que muestra un ejemplo de un proceso de manejo de eventos de acuerdo con una realizacion de los aspectos de procesamiento de eventos de la invencion;

La Figura 16 es un diagrama de flujo que describe etapas llevadas a cabo por el componente de interaccion de servicio mostrado en la Figura 14 durante el proceso de manejo de eventos mostrado en la Figura 15;

La Figura 17 es un diagrama esquematico que describe etapas llevadas a cabo por el componente de interaccion de servicio mostrado en la Figura 14 durante un proceso de manejo de eventos inter-OSA;

La Figura 18 es un diagrama esquematico que describe etapas llevadas a cabo por el componente de interaccion de servicio mostrado en la Figura 14 durante un proceso de manejo de eventos OSA-IN; y Las Figuras 19 - 23 son diagramas esquematicos que muestran ejemplos adicionales de procesos de manejo de eventos de acuerdo con las realizaciones de la invencion.

Se ha de observar que las partes y etapas que se hayan presentado la primera vez en relacion con una figura dada y que sean identicas o equivalentes a partes y etapas que tienen lugar en figuras posteriores se describiran con el mismo numero de referencia en tales figuras posteriores, y no se describiran en ningun detalle adicional en las figuras posteriores.

Descripcion detallada de la invencion

Las realizaciones de la invencion estan relacionadas con aspectos de redes de servicio, en particular con la intermediacion de manera eficaz de los diversos, y potencialmente en conflicto, servicios de red disponibles para un abonado, y proporciona un sistema y aparato de procesamiento de eventos dispuesto para entregar esta funcionalidad. Estos servicios incluyen espedficamente, pero no exclusivamente: servicios de correo de voz (Aplicacion Internacional de Voz Sin Interrupciones, o ISVA); servicios de traduccion de numero de Red Privada Virtual (iVPN); y servicios de Encaminamiento Domestico Selectivo (SHR), mensajes de facturacion prepago, mensajes de post pago, servicios de Presionar para Hablar (basados en resolucion B#), reenvfo de llamada tardfa, interacciones de llamada/recurso temporales, servicios que implican mensajena de SMS y MMS y servicios de iniciacion de SIP entre otros. Una caractenstica particular de las realizaciones de la invencion es la capacidad para controlar la operacion de servicios de IN y OSA, y entre diferentes servicios de OSA, ademas de intermediar entre diferentes servicios de IN. Las realizaciones de la invencion tambien estan relacionadas con la intermediacion entre servicios no de redes inteligentes y no de OSA (por ejemplo, que implican mensajena de SMS y MMS y servicios de iniciacion de sesion de SIP).

Entorno de red

Haciendo referencia a la Figura 2, el acceso a la funcionalidad de red, incluyendo la funcionalidad de la Red Inteligente, se ofrece y controla por diferentes Servidores de Capacidad de Servicio (SCS), que aparecen como caractensticas de capacidad de servicio en la interfaz de OSA. Esta interfaz de OSA se denomina comunmente como GW de Parlay/OSA 101. Las aplicaciones de OSA tales como App1 comunican con la GW de OSA 101 mediante las interfaces de OSA, mientras que las funciones de red principal subyacentes (capacidades de Red Inteligente, el MSC 107 (Centro de Conmutacion Movil) y el HLR 115 (Registro de Localizacion Domestico)) usan sus protocolos espedficos tales como CAP (Protocolo de Aplicacion CAMEL) y MAP (Parte de Aplicacion de Movilidad) para comunicar con la GW de OSA 101. Como se ha descrito anteriormente, hay 14 SCF, que incluyen diversas sCf de control de llamada generica (GCC) y control de llamada de multiples partes (MPCC), que mapean colectivamente todos los mensajes de CAP, MAP e INAP, y pueden por lo tanto invocar todas las capacidades de red.

Las funciones de red principales anteriormente referenciadas se consideran de manera conveniente que son parte de una Red Movil Publica Terrestre (PLMN), que pueden realizarse como una red celular tal como una red gSm o UMTS, y que comprenden adicionalmente componentes relacionados con la transmision y entrega de datos en el nivel de radio (no mostrado). En la operacion, el MSC 107 tiene en cuenta el impacto de la asignacion de recursos de radio y la naturaleza movil de los abonados, y realiza procedimientos requeridos para registro de localizacion y traspaso de estaciones moviles. Como se muestra en la Figura 1, el MSC 107 esta conectado al HLR 115, que esta dispuesto para almacenar datos que identifican la localizacion de abonados moviles (por ejemplo para poder encaminar llamadas a los mismos); numeros de identificacion fijados a cada suscripcion movil (por ejemplo, la Identidad de Abonado Movil Internacional (IMSI); Numero de ISDN de Abonado Movil Internacional (MsiSdN)); informacion de suscripcion de servicio de comunicacion, restricciones de servicio (por ejemplo limitaciones de itinerancia); atributos y preferencias de abonado generales; e informacion de servicio complementaria que incluye parametros asociados con estos servicios.

En terminos de comunicacion entre los diversos componentes de la red, el MSC 107 y el HLR 115 envfan y reciben datos mediante una diversidad de protocolos de senalizacion, incluyendo pero sin limitacion, Parte de Aplicacion movil (MAP) del Numero de Sistema de Senalizacion 113 (SS N.° 7), mientras que la senalizacion entre el MSC 107 y los componentes de radio usa la Parte de Aplicacion de Sistema de Estacion Base (BSSAP) de SS N.° 7.

5

10

15

20

25

30

35

40

45

50

55

60

65

Vista general: arquitectura de sistema

Volviendo ahora a la Figura 4, se describira una primera disposicion de un sistema de procesamiento de eventos de acuerdo con una realizacion de la invencion. En esta primera disposicion el sistema de procesamiento esta dispuesto para controlar la operacion de diversos servicios de red inteligente IN1, IN2, IN3 de acuerdo con una o mas reglas, y comprende una Funcion de Interaccion de Servicio SIF 301 y un Almacen de Perfil de Abonado 303. La Figura 4 ilustra, esquematicamente, el flujo de datos entre los diversos componentes del sistema, y puede observarse que, en lugar del MSC 107 que comunica directamente con los nodos del servicio de red inteligente IN1 ... IN3, el MSC 107 interactua unicamente con la SIF 301, y distribuye mensajes a diversos nodos de red de acuerdo con, al menos en parte, los datos recibidos desde el SPS 303.

La SIF 301 asume la responsabilidad de comunicar con los diversos nodos de servicio de red IN1 ... IN3, y la naturaleza y orden de cualquier comunicacion con ellos se controla de acuerdo con datos recibidos desde el SPS 303, como se describira en mas detalle a continuacion. El SPS 303 es esencialmente un repositorio de datos que almacena informacion relacionada con activacion y servicio espedfico de abonado. Ademas, puede almacenar datos entre servicios, que pueden configurarse y combinarse por la SIF para especificar interacciones entre nodos de servicio (por ejemplo en terminos de prioridad de acceso). El SPS puede aprovisionarse con datos desde servicios de aprovisionamiento, tales como servicios web localizados en una web mas amplia, como se muestra esquematicamente en la Figura 4.

Volviendo ahora a la Figura 5, puede observarse que la SIF 301 esta tambien dispuesta para interactuar con, y controlar la operacion de, diversas aplicaciones de OSA, mediante una pasarela de OSA 101 (unicamente se muestra una por claridad). En tales disposiciones la informacion relacionada con el servicio almacenado en el SPS 303 incluye reglas y condiciones en relacion con la interaccion entre servicios de IN y servicios de OSA, como se describiran todos en mas detalle mas adelante en la descripcion.

Una tercera disposicion se muestra en la Figura 6, en la que una SIF 301 esta dispuesta para controlar la operacion de servicios localizados detras de la pasarela 101. Esta disposicion trata una limitacion del diseno de pasarela de OSA convencional, en concreto cualquier activador/abonado dado que esta pregrabado de manera eficaz en una unica aplicacion de OSA (y por lo tanto que tiene de manera eficaz la misma ausencia de flexibilidad como se ha descrito anteriormente en el contexto de servicios de red inteligente proporcionados por un MSC de conmutacion). Esta disposicion, por lo tanto, proporciona un medio para que se invoquen multiples aplicaciones de OSA, de manera flexible, en respuesta a ciertos activadores de servicio y/o datos de abonado. Un sistema de procesamiento de eventos podna incluir dos aparatos de SIF, uno localizado en la red, de conformidad con la primera y segunda disposiciones (Figuras 4, 5) y uno en el dominio de OSA (Figura 6), que significa que los dos aparatos de SIF senan ambos logica y ffsicamente distintos entre sf. Como alternativa el sistema de procesamiento de eventos podna comprender una unica SIF, que esta ffsicamente distribuida, pero logicamente integrada, entre la red y el dominio de OSA. Estas diversas disposiciones se analizaran en mas detalle a continuacion.

Registro de servicio

El Almacen de Perfil de Abonado SPS 303 esta dispuesto para almacenar una lista de servicios (IN y OSA) y las relaciones entre ellos, en terminos de procesamiento de eventos de red, para todos los abonados. Los servicios estan preferentemente codificados acuerdo con las identidades de abonado y activadores de servicio, de modo que, para cualquier identidad y activador de abonado dados, los servicios disponibles para el abonado pueden seleccionarse cuando se debe procesar una llamada que implica un cierto activador. Ademas, la relacion o relaciones entre los servicios seleccionados pueden recuperarse, en forma de “logica de modelo de llamada” asociada con el activador.

Como puede observarse a partir de la Figuras 4 y 5, el SPS 303 puede aprovisionarse con datos 311 desde servicios de aprovisionamiento, tal como servicios web localizados en una red mas ancha, y el proceso de aprovisionamiento es preferentemente independiente del proceso de registro. Lo siguiente establece una posible estructura de datos para los datos 311, denominados en el presente documento como datos aprovisionados, almacenados en el sPs 303 con respecto a un abonado dado:

Abonado - clave MSISDN o IMSI o Id corporativa Atributos: - DP Aplicacion GT

Clave de servicio Protocolo

Preferencia de ejecucion

Ejecucion sincrona o asincrona Preferencia de conexion;

reenviar DRA / PN que llama modificado en InitiaIDP Preferencia de reenvio

5

10

15

20

25

30

35

40

45

50

55

60

65

Preferencia de liberacion Preferencia de error En red/fuera de red/cualquiera es aplicacion de busqueda es aplicacion de encaminamiento domestico Atributos: - Eventld

ServiceSet: referencia a un conjunto particular de aplicaciones y reglas de aplicacion especificadas en otra tabla de SPS.

Tiempos de espera Localizacion [rw]

Estos atributos incluyen datos que posibilitan que la SIF 301, cuando se configura de manera adecuada, haga funcionar internamente servicios basandose en respuestas individuals y mensajes recibidos desde la red y otros servicios. El SPS 303 puede almacenar reglas entre aplicaciones y entre servicios, que especifican interacciones entre nodos de servicio cuando se reciben las diversas respuestas y mensajes de la red (por ejemplo en terminos de prioridad de acceso); estos aspectos se describen en mas detalle a continuacion. En terminos de activadores, a modo de ejemplo unicamente, el SPS 303 puede configurarse para soportar la siguiente lista no limitante de activadores de servicio: INAP DPI - DP18; CAP V1 O-CSI, T-CSI; eventos de MAP no de DP, por ejemplo locationUpdate, forwardSM; activadores CAP V2 V3 V4; MMS, SMS, SS, USSD, SIP.

Como se ha descrito anteriormente en la seccion de antecedentes, el punto de inicio para capturar eventos de red de interes para aplicaciones de OSA es convencionalmente dentro del SCS de procesamiento de eventos, que comprueba los parametros especificados en un mensaje enableCallNotification() (o mensaje createNotification() para llamadas MPCC) para identificar si una aplicacion ya esta registrada o no para estos parametros. Basandose en esta comprobacion, el SCS permite o rechaza el registro de la aplicacion para estos parametros.

En contraste, el punto de inicio para las realizaciones de la invencion es el registro incondicional de una aplicacion solicitante, que significa que, al contrario de metodos conocidos, los parametros incluidos en una solicitud de registro no se comprueban frente a aplicaciones previamente registradas. Por supuesto los conflictos potenciales que se gestionaron anteriormente de una manera un tanto estricta en el registro necesitan aun manejarse y las realizaciones de la invencion proporcionan un medio alternativo y flexible de gestion de conflictos, en un lugar diferente en un ciclo de procesamiento de eventos. Esto se describira en mas detalle a continuacion, pero los primeros aspectos del proceso de registro para las aplicaciones de OSA se describiran con referencia a las Figuras 7 -13.

Volviendo ahora en primer lugar a la Figura 7, puede observarse que la GW Parlay 101 incluye una funcion de registro 305 configurada para comunicar tanto con el SCS de Control de Llamada 103 como con el SPS de almacen 303. Ademas de los datos aprovisionados 311, anteriormente introducidos (informacion relacionada con activacion y servicio espedficos de abonado), el SPS 303 almacena datos dinamicos 313, que indican el estado en tiempo real de cualquier aplicacion dada listada en los datos aprovisionados 311. Ejemplos de tal informacion en tiempo real incluyen datos que identifican si una aplicacion esta o no activa, junto con detalles de abonados y eventos de red actualmente registrados con respecto a la aplicacion; en la siguiente descripcion estos datos en tiempo real se denominan como alternativa como “manejadores de aplicacion”. Las aplicaciones estan preferentemente codificadas de acuerdo con las identidades de abonado y activadores de servicio, de modo que, para cualquier identidad y activador de abonado dados, las aplicaciones disponibles para el abonado pueden seleccionarse cuando se ha de procesar una llamada que implica un cierto activador.

La Figura 8 muestra las etapas implicadas en un proceso de registro de acuerdo con una primera realizacion: en la etapa 81 la App1 envfa una solicitud GCC enableCallNotification() al SCS 103, que provoca que la funcion de registro 305 asigne un ID de asignacion (assigmnentid) con respecto a la App1. En la etapa 82 el ID de asignacion se envfa al SPS 303, junto con el activador, los datos de direccion de origen y destino especificados en la solicitud enableCallNotification(), y se transmite posteriormente un mensaje de acuse de recibo de vuelta a la App1 en la etapa 83. Tras la recepcion de un mensaje desde la funcion de registro 305 en la etapa 82, el SPS actualiza el almacen dinamico 313, ya sea para incluir la App1 (y detalles del activador, direccion de origen y destino recibidos en la etapa 81) o, si la App1 ya esta almacenada en el mismo en relacion con otros parametros de activador/abonado, para actualizar los parametros para incluir aquellos correspondientes a los datos recibidos en la etapa 81. La Figura 9 es un diagrama esquematico que muestra como se distribuyen datos entre componentes del SPS 303: el drculo que corresponde a los datos dinamicos 313 representa aplicaciones con respecto a las que se han recibido datos desde la funcion de registro 305 de la manera anteriormente descrita (como se muestra en la Figura 8), mientras que el drculo que corresponde a los datos aprovisionados 311 representa aplicaciones con respecto a las cuales el abonado se ha suscrito, pero que no se han registrado aun con la pasarela 101. Se apreciara que en esta realizacion y posteriores, la solicitud de registro puede referirse igualmente a una pluralidad de abonados (por ejemplo registro en masa) como para un unico abonado.

La Figura 10 muestra las etapas implicadas en un proceso de registro de acuerdo con una segunda realizacion: en la etapa 81 la App1 envfa una solicitud enableCallNotification() al SCS 103, que provoca que la funcion de registro

5

10

15

20

25

30

35

40

45

50

55

305 envfe una solicitud al SPS 303 con respecto a la App1, que consulta el SPS 303 para la combinacion abonado/activador/AppI realizada en la solicitud recibida en la etapa 81 (etapa 1001). Esto provoca que el SPS 303 consulte el almacen de datos aprovisionados 311 y en la etapa 1003 el SPS 303 devuelve un resultado de la consulta a la funcion de registro 305. Suponiendo que el resultado es positivo, la funcion de registro 305 asigna un ID de asignacion a App1 y en la etapa 1005 envfa el ID de asignacion asignado al SPS 303, junto con el activador, datos de direccion de origen y destino especificados en la solicitud de enableCallNotification(). Un mensaje de acuse de recibo se transmite posteriormente de vuelta a la App1 en la etapa 1007. Tras la recepcion de un mensaje desde la funcion de registro 305 en la etapa 1005, el SPS actualiza el almacen dinamico 313, para incluir la App1 (y detalles del activador, direccion de origen y destino recibida en la etapa 81) o, si la App1 ya esta almacenada en el mismo con otros parametros de activador/abonado, para actualizar los parametros para incluir aquellos que corresponden a los datos recibidos en la etapa 81. La Figura 11 es un diagrama esquematico que muestra como se distribuyen los datos entre los componentes del SPS 303: el cfrculo que corresponde a los datos dinamicos 313 representa aplicaciones con respecto a las que los datos se han recibido desde la funcion de registro 305 de la manera anteriormente descrita (como se muestra en la Figura 10), mientras que el cfrculo que corresponde a los datos aprovisionados 311 representa aplicaciones con respecto a las que el abonado se ha suscrito, pero que no se han registrado aun con la pasarela 301.

A partir de una comparacion de las Figuras 9 y 11 puede observarse que la diferencia entre los dos procesos de registro es que, en el primer metodo de registro, el almacen de datos dinamico 313 puede mantener los datos de aplicacion que son realmente invalidos para este evento de abonado/activador particular, mientras que en el segundo metodo de registro el almacen dinamico 313 unicamente mantendra un subconjunto de aplicaciones para las que el abonado tiene acceso legttimo. Aunque en la primera disposicion esto significa que el almacen de datos dinamico 313 puede mantener datos invalidos, es un procedimiento un tanto mas rapido que el segundo (que implica 2 etapas menos que lo que se requiere en el segundo proceso); sin embargo, el segundo proceso de registro es mas seguro que el primero. Una ventaja particular de las aplicaciones de registro de acuerdo con la segunda realizacion es que el proceso de registro es transparente a la aplicacion de registro, que significa que puede integrarse de manera convencional con cualquier disposicion compatible con la norma de oSa.

Es tambien posible un proceso adicional (no mostrado), en el que el SPS mantiene datos que especifican todas las combinaciones posibles de las aplicaciones, junto con condiciones de interaccion asociadas entre ellas. Estos datos se rellenan fuera de lmea, de modo que, durante el proceso de registro el SPS sirve como un tipo de funcion de busqueda para reglas entre aplicaciones pertinentes. Cuando la funcion de registro 305 recibe (mediante el SCS 103) una solicitud de registro de aplicacion (etapa 81), la funcion de registro 305 asigna un ID de asignacion a la aplicacion App1 y envfa el identificador asignado al SPS 303 (etapa 82). En respuesta a la recepcion del identificador, el sPs 303 recupera reglas de interaccion basandose en este, y cualquier otra aplicacion que se haya registrado para este abonado, y asocia las reglas de interaccion recuperadas con el activador, direccion de origen y destino recibidas en la etapa 81. Ademas el SPS actualiza el almacen dinamico 313, ya sea para incluir la App1 (y detalles del activador, direccion de origen y destino recibidas en la etapa 81) o, si la App1 ya esta almacenada en el mismo en asociacion con otros parametros de activador/abonado, para actualizar los parametros para incluir aquellos que corresponden a los datos recibidos en la etapa 81. La operacion del SPS de acuerdo con esta realizacion puede explicarse con referencia a un ejemplo:

El SPS 303 esta dispuesto para almacenar las reglas de interaccion como se indican a continuacion:

Aplicacion o aplicaciones Regla o reglas

Aplicacion unica (por ejemplo X) Ninguna X y Y Beta

X y Z Delta

Z e Y Gamma

X e Y y Z Alfa

Suponiendo que un registro de abonado desde el que se ha recibido unicamente una solicitud de aplicacion desde la Aplicacion X, a continuacion en respuesta a una solicitud de registro posterior desde la Aplicacion Y, el SPS 303 recupera en una regla de interaccion para una combinacion de aplicaciones X e Y (en este punto beta), y marca la regla de interaccion recuperada contra el abonado y activador, ademas de actualizar el almacen de datos dinamico 313 para reflejar el registro de la aplicacion Y para este abonado y los datos de activador recibidos en la etapa 81. Si, posteriormente, la aplicacion Z se registra para este abonado, el SPS 303 localiza una regla de interaccion para una combinacion de aplicaciones X, Y y Z (alfa) y actualiza tanto el SPS 303 como el almacen de datos dinamico 313 en consecuencia. Si la aplicacion X a continuacion anula el registro (ya sea de por sf o en relacion con este abonado) el SPS 303 recupera la de regla de interaccion gamma y actualiza la informacion de los almacenes en consecuencia. Estas reglas de interaccion especifican interacciones validas entre dos o mas aplicaciones cuando un evento relacionado con un activador asociado se recibe desde la red. Se ha de observar que estas interacciones pueden ser condicionales sobre el tipo de respuesta y/o mensaje recibido desde los servicios (aplicaciones) asociados con los servicios; este comportamiento puede especificarse de manera conveniente en las reglas de interaccion, o puede especificarse en datos asociados con los servicios afectados.

5

10

15

20

25

30

35

40

45

50

55

60

65

Se ha de observar que esta disposicion es considerablemente diferente a la presentada por BT (descrita como “Interaccion de caractenstica/seleccion de servicio”). En el metodo y sistema de BT, las reglas de interaccion se consultan en el momento del registro de aplicacion para determinar si las aplicaciones pueden coexistir o no en relacion con el mismo activador. Si las reglas de interaccion permiten que una aplicacion solicitante coexista con una aplicacion que ya se ha registrado con respecto al abonado/activador asociado, los detalles de esta aplicacion solicitante se registran en un perfil de usuario. Cuando se recibe un correspondiente activador de red las aplicaciones se invocan secuencialmente, en un orden determinado por el orden en el que se enumeran las aplicaciones en el perfil de usuario (que se determina por el orden en el que las aplicaciones se registraron con la pasarela). En contraste, con las realizaciones de la presente invencion, es la interaccion o interacciones potenciales entre aplicaciones las que se selecciona o seleccionan durante el proceso de registro, habiendose resuelto las relaciones reales y permisibles entre aplicaciones y comportamientos posteriores fuera de lmea. Como resultado, el orden en el que se invocan las aplicaciones no esta restringido por, o de hecho incluso relacionado a, el orden en el que las aplicaciones se registran con la pasarela. En su lugar, la invocacion de las aplicaciones se especifica en las reglas preconfiguradas, que pueden optimizarse como una funcion de las mismas aplicaciones. Esto es una ventaja evidente sobre el diseno de Bt.

Como se ha descrito anteriormente, ademas de almacenar datos indicativos de aplicaciones disponibles, junto con informacion de estado en tiempo real asociada asignada durante la fase de registro, el SPS 303 esta dispuesto para almacenar datos indicativos de las relaciones entre servicios y aplicaciones, en terminos de como debena procesarse un evento de red entrante; estos datos se almacenan en forma de “logica de modelo de llamada” asociada con eventos de red (o activadores). A partir de lo anterior se apreciara que tales reglas de interaccion, o logica de modelo de llamada, se seleccionan en el momento de registro de aplicacion en el caso del metodo de registro de terceros. Cuando el registro de aplicaciones se efectua de acuerdo con el primer y segundo metodos las reglas de interaccion asociadas se seleccionan a partir del repositorio de reglas de interaccion cuando se recibe un evento desde la red, como se describira en mas detalle a continuacion.

Se apreciara a partir de lo anterior que en el caso de tanto aplicaciones de OSA como de IN, el problema de conflictos entre aplicaciones se ignora completamente en la fase de registro. En su lugar, la gestion entre aplicaciones se controla por la SIF 301 cuando se recibe una solicitud para servicio desde la red. En terminos de la configuracion de estos componentes, haciendo referencia a la Figura l2, en una primera disposicion la SIF 301 esta localizada en la pasarela 101, y asume la responsabilidad de comunicar con los diversos nodos de servidor de aplicacion de red App1 ... Appn. Se muestra una disposicion alternativa en la Figura 13, en la que la SIF 301 esta localizada fuera de la pasarela 101, y por lo tanto comunica directamente con las aplicaciones de OSA App1, App2 y el SPS 303, mientras comunica con la pasarela 101 mediante una interfaz. En ambas figuras las lmeas discontinuas indican comunicaciones con interfaces de pasarela para comunicar con dispositivos externos tales como, en el caso de la Figura 12, el SPS 303 y las aplicaciones App1, App2 y en el caso de la Figura 13, el SCS 101).

Invocacion de servicio

Los componentes de la SIF 301 y la funcionalidad proporcionada de esta manera se describiran ahora con referencia a la Figura 14, que es un diagrama de bloques que muestra una descomposicion de la SIF 301 en sus partes componentes. Preferentemente estos componentes se implementan como uno o una pluralidad de componentes de software, y se distribuyen en uno o un conjunto de dispositivos informaticos, que comprenden CPU convencional, memoria, bus de datos, puertos de entrada/salida, almacenamiento de datos y programas de sistema operativo (no mostrado).

Hablando en general, la SIF 301 esta dispuesta para proporcionar una mediacion de aplicacion inter-IN a IN y/o IN a OSA y/o inter OSA a OSA, de manera que multiples aplicaciones de servicio puedan compartir puntos activadores tales como los eventos de punto de deteccion del Protocolo de Aplicacion de Red Inteligente (INAP) y el Protocolo de Aplicacion Camel (CAP) enumerados anteriormente. En una disposicion la SIF esta configurada para recibir, desde el MSC 107 o desde cualquier SCF, tal como una que incluye el SCS 103 mostrado en la Figura 2, un mensaje de solicitud de servicio que incluye alguna clase de activador; realizar una consulta en la base de datos de SPS 303 en dependencia del activador recibido; recibir datos desde el SPS 303 en respuesta a la consulta; invocar y coordinar cualesquiera de las aplicaciones de servicio que se identifiquen por los datos devueltos por el SPS 303 de acuerdo con la logica de modelo de llamada asociada con las mismas (devuelta por el SPS 303); y recopilar una respuesta global para enviar de vuelta al SCS 103 o al MSC 107 para posibilitar que el servicio continue. La logica de modelo de llamada incluye servicios de accionamiento en dependencia de respuestas y mensajes recibidos desde otros servicios durante el establecimiento de llamada; la logica es suficientemente flexible y detallada que, para un evento de red dado, el MSC 107 y otros dispositivos de conmutacion de red podnan implicarse en el establecimiento de eventos, y cualquier aplicacion de servicio dada puede invocarse mas de una vez.

En la presente realizacion la SIF 301 comprende una interfaz de servicios 140 para comunicar con la red aplicaciones de servicio IN1 ... INx, App1 ... Appn y dispositivos de conmutacion tales como el MSC 107; una interfaz de SPS 141 para comunicar con el SPS 303, un motor de logica 142 y un motor de procesamiento de eventos 143. La interfaz de servicios 140 esta dispuesta para soportar al menos cAp, INAP, MAP, SIP y API tal como CORBA y SOAP, posibilitando de esta manera que la SIF 301 comunique con una gama de dispositivos de red diferentes.

5

10

15

20

25

30

35

40

45

50

55

60

65

El motor de logica 142 esta dispuesto para solicitar datos de servicio desde el SPS 303, junto con datos que identifican reglas y detalles de aplicaciones de servicio (en forma de reglas fijas 145, reglas dinamicas 147 y/o reglas de guiones 149 (al menos algunas de las cuales se reciben desde el SPS 303 en tiempo real)), en dependencia de los datos de activador y de abonado. Habiendo recibido estos datos, el motor de logica 142 esta dispuesto para generar uno o mas eventos de procesamiento de red, que implican invocar un servicio mediante la interfaz de servicios 140 y provocar que el motor de procesamiento de eventos 143 monitorice, y actue sobre, la salida de tales servicios invocados. En particular, el motor de procesamiento de eventos 143 esta dispuesto para realizar la gestion de transaccion, gestion de correlacion (por ejemplo correlacionar los DP recibidos desde diferentes conmutadores), control de tiempo de espera (en relacion con respuestas recibidas desde los servicios IN1 ... INx, App1 ... Appn y el SPS 303); gestion de instancias (en relacion con secuenciacion de servicios, y soporte para multiples operaciones independientes simultaneas); y tareas administrativas generales tales como gestion de estadfsticas y de alarmas. El motor de procesamiento de eventos 143 puede por lo tanto efectuar uno o mas servicios de red y aplicaciones de OSA en respuesta a un mensaje de OSA callEventNotify() y/o un InitialDP de IN, recopilar respuestas globales desde algunos o todos los servicios accionados y enviar datos al SCS 103 o MSC 107 para conectar un abonado al servicio o servicios de red requeridos.

Las caractensticas y funcionalidad del motor de procesamiento de eventos de red 143 se describiran ahora en mas detalle. La logica de modelo de llamada devuelta desde el SPS 303 (tfpicamente en forma de datos 145, 147) se usa de manera eficaz para controlar la secuencia en la en la que se invocan las aplicaciones de servicio de IN y OSA IN1 ... INx, App1 ... Appn con mensajes iniciales y posteriores, resolviendo de esta manera el problema de distribuir el unico activador resultante de un punto de activador. Cuando la salida de una aplicacion de servicio influencia la operacion de otra aplicacion de servicio, la invocacion es preferentemente smcrona, pero si las salidas desde diversas aplicaciones de servicio se combinan simplemente por el motor de procesamiento de eventos 143, las aplicaciones de servicios se invocan preferentemente de manera asmcrona para mejorar la latencia. Puede observarse por lo tanto que el procesamiento entre aplicaciones se gestiona en el momento del procesamiento de una llamada por medio de las reglas recuperadas desde el SPS 303. Ademas de que el SPS 303 devuelva reglas de secuenciacion con respecto a activadores de OSA tales como callEventNotify () y activadores IN tales como activadores InitialDP, existen tambien reglas para procesar notificaciones de eventos (ERB (IN), RouteRes() (OSA)) applyCharging (AC/ACR (IN), mensajes superviseCallReq()/superviseCallRes() (OSA)), acceso de llamada y recursos temporales (ETC/CTR) y cualquier respuesta resultante a partir de los mismos.

En resumen, la operacion de la SIF 301 puede observarse como que comprende dos fases distintas: una primera, en la que la SIF 301 recupera datos accionables que corresponden al activador; y una segunda, en la que la SIF 301 invoca aplicaciones basandose en los datos accionables, incluyendo la invocacion monitorizacion para, y actuar sobre, datos recibidos desde las aplicaciones accionadas.

El motor de procesamiento de eventos 143 esta dispuesto adicionalmente para controlar la operacion de multiples aplicaciones de servicio que generan eventos y acciones en conflicto. Tomando un ejemplo sencillo, si multiples aplicaciones de servicio devuelven un mensaje CONECTAR (IN) o routeRequest() (OSA), el motor de procesamiento de eventos 143 aplica diversas reglas para identificar cual de los mensajes 'gana'; y en otro ejemplo sencillo, si se devuelve un mensaje CONECTAR/routeRequest() y un mensaje LIBERAr (IN) o release() (OSA) por aplicaciones de servicio diferentes, el motor de procesamiento de eventos 143 aplica diversas reglas para identificar cual de las dos acciones en conflicto se toma. Esencialmente, por lo tanto, las salidas se procesan de acuerdo con una regla apropiada desde el SPS 303 asociado con el evento en conflicto y/o accion.

El motor de procesamiento de eventos 143 esta dispuesto para manejar fallos de comunicacion, de acuerdo con las reglas dinamicas (es decir configurables) 147 recuperadas desde el SPS 303, dependientes del tipo de fallo. Por ejemplo, si una primera aplicacion de servicio se aborta, una opcion es que la totalidad de las transacciones se aborten, mientras que otra puede ser que si la primera aplicacion de servicio continua pero la segunda falla, la respuesta desde la primera debena tomar preferencia.

El motor de procesamiento de eventos 143 esta configurado tambien para monitorizar respuestas dentro de un periodo de tiempo predeterminado, en el que, en el caso de que una respuesta de aplicacion de servicio falle al llegar, o las respuestas de MSC fallen, la SIF 301 realiza una de una pluralidad de acciones. Por ejemplo, en el caso de que una aplicacion de servicio falle al responder dentro del periodo de tiempo especificado, la SIF podna enviar una respuesta de fallo de TCAP al MSC 107 que depende de las reglas de error asociadas. Las reglas de error y tiempo de espera podnan ser reglas estaticas 145 almacenadas y mantenidas por la SIF 301.

En resumen, el motor de logica 142 y el motor de procesamiento de eventos 143 controlan las siguientes acciones de acuerdo con condiciones especificadas en las reglas fijas, dinamicas y estaticas 145, 147, 149:

i. El orden en el que se invocan las aplicaciones de servicio;

ii. Como se combinan respuestas desde aplicaciones de servicio;

iii. Como deberan realizarse transacciones posteriores basandose en repuestas desde las aplicaciones de

servicios;

iv. Si el control de llamada se gestiona por la SIF, o se delega a una aplicacion de servicio; y

5

10

15

20

25

30

35

40

45

50

55

60

65

v. Si las aplicaciones debenan excluirse de la invocacion como una funcion del tipo de red (por ejemplo domestica o de itinerancia).

Una lista no limitante de ejemplos de las reglas fijas 145 se describira ahora:

• Las solicitudes son acumulativas: si la aplicacion de servicio A solicita el informe de solicitud BCSM DPx y la aplicacion B solicita RRB DPy a continuacion el resultado debera solicitar RRB DPx y DPy. (Un informe de solicitud de BCSM se denomina en el presente documento como RRB y es una solicitud para crear puntos de activador para mas tarde en el flujo de comunicaciones - por ejemplo Ocupado, Desconectado, Respuesta, No respuesta. Si estos puntos se activan, se genera automaticamente un informe de evento BCSM (ERB));

• Si hay multiples solicitudes de RRB para el mismo DP entonces unicamente debera solicitarse una unica invocacion;

• Si hay multiples solicitudes de RRB para el mismo DP entonces el modo monitor debera ser el solicitado de manera mas elevada;

• CONTINUAR debera devolverse unicamente si todas las aplicaciones de servicio indican continuar;

• Si hay unicamente una aplicacion de servicio enumerada para un abonado / DP entonces la SIF debera abandonar la llamada, es decir reenviar el InitialDP a la aplicacion de servicio, con la respuesta encaminada directamente de vuelta al MSC de inicio;

• Si no hay aplicaciones de servicio definidas entonces la SIF debera devolver una respuesta CONTINUAR;

• La SIF debera interrumpir el flujo en la oportunidad mas anterior posible; por ejemplo unicamente se devuelve CONTINUAR, CONECTAR o LIBERAR al MSC, o si todas las respuestas de MSC esperadas estan destinadas para una unica aplicacion;

• etc.

Una lista no limitante de ejemplos de las reglas dinamicas 147 se describira ahora:

• El orden de la retransmision de DP inicial a las aplicaciones de servicio debera estar en el orden de preferencia configurado;

• Si las aplicaciones de servicio pueden invocarse asmcronamente entonces debenan hacerse, puesto que esto mejorara la latencia;

• Si la respuesta es LIBERAR, entonces la respuesta global debera regirse por la preferencia de liberacion de la aplicacion de servicio. Si hay una aplicacion de servicio con una prioridad de liberacion superior que no ha devuelto una LIBERACION (es decir CONTINUAR o CONECTAR) entonces la aplicacion de servicio de prioridad inferior debera ignorarse. Si la LIBERACION es de la aplicacion con la prioridad de liberacion mas alta, entonces las aplicaciones de servicio restantes no necesitan accionarse; y debera devolverse una LIBERACION y FIN de TCAP;

• Si se devuelve un CONECTAR, entonces la parte llamada / llamante devuelta al MSC debera ser la de la aplicacion de servicio con la preferencia de conexion mas alta;

• etc.

Una lista no limitante de ejemplos de reglas 149 que se realizan en guiones preferentemente se describira ahora:

• Informes de facturacion (ACR) deberan distribuirse unicamente a aquellas aplicaciones que contribuyeron al AC previamente generado. Puede haber calculos complejos requeridos para mensajear los ACR en una forma apropiada para cada aplicacion de servicio;

• Cuando la accion es dependiente del contenido en un mensaje, puede usarse un guion para identificar el contenido en el mensaje e invocar una accion apropiada;

• etc.

Ademas de las reglas fijas, dinamicas y estaticas 145, 147, 149 anteriormente descritas, la SIF 301 opera de

acuerdo con varias reglas generales, que incluyen las siguientes:

• La SIF debera finalizar los dialogos de TCAP con TC_END cuando la respuesta al MSC es un sencillo CONECTAR, CONTINUAR o LIBERAR (fin basico);

• La SIF debera finalizar la transaccion sin un TC_END si determina que no se esperan mas mensajes (por ejemplo ACR recibido que indica el fin de la llamada, y no hay puntos de activador mas posteriores preparados) - esto se conoce como un fin pre-dispuesto, y no se envfan mensajes adicionales;

• La SIF debera finalizar todos los dialogos abiertos si recibe un TC_ABORT del MSC - retransmitiendo el TC_ABORT;

• La SIF debera finalizar todos los dialogos abiertos si recibe un TC_END del MSC - retransmitiendo el TC_END;

• La SIF debera finalizar el dialogo con un TC_END si tienen lugar errores no esperados;

• Siguiendo un Informe de Ocupado de ERB, debera devolverse un mensaje de conexion a un numero diferente (esto puede invalidar todas las interacciones anteriores con otras aplicaciones, por lo que puede usarse un guion para abortar algunas aplicaciones o modificar el comportamiento explfcitamente, usando potencialmente mensajes generados espedficamente para este fin).

5

10

15

20

25

30

35

40

45

50

55

60

65

Se apreciara que en esta, y otras realizaciones, el protocolo y/o API usadas en las reglas son aquellas apropiadas para los servicios implicados, y no estan restringidas a INAP, CAP, GCC, MPCC.

La funcionalidad de un sistema de procesamiento de eventos se describira ahora con referencia varios escenarios de ejemplo que implican el procesamiento de llamadas de entrada desde una estacion movil MS 2. Haciendo referencia a la Figura 15, en un primer ejemplo el sistema esta relacionado con el control de la operacion de diversos servicios de IN, que incluye una aplicacion de Encaminamiento Domestico de Servicio (SHR) para uso al cambiar el nodo servidor cuando un abonado MS 2 esta realizando itinerancia en una red visitante VPLMN, y una aplicacion de servicio no especificada IN1, cuya operacion depende del nodo servidor que esta en la red domestica. Este primer ejemplo ilustra las interacciones entre la SIF 301, una aplicacion de SHR y otra y como tal es un ejemplo sencillo; se incluye para demostrar los tipos de reglas, condiciones y mensajes que pasan a y desde la SIF 301, nodo servidor 107 y nodos de servicio para ayudar a entender otras realizaciones de la invencion mas complejas.

En este ejemplo la SIF 301 se usa para gestionar entradas a y desde las diversas aplicaciones de servicio de SHR, IN1 que dependen de los datos de servicio relacionados con el abonado MS 2 (un servicio de SHR permite que se procese una llamada en la red domestica (HPLMN) si esta resuelve los problemas o limitaciones asociados con el procesamiento por la red visitante (VPLMN)).

La Figura 15 es un diagrama esquematico que muestra la transferencia de comunicacion entre componentes del sistema, aunque la Figura 16 es un diagrama de bloques que muestra las etapas llevadas a cabo por la SIF 301. A continuacion, se hara referencia a las Figuras 15 y 16 juntas. En la etapa 1501, habiendo recibido una solicitud de una Actualizacion de Localizacion, el HLR 115 envfa una senal que comprende O-CSI (Informacion de Abonado Camel de Origen) al vMSC 107 (MSC en la red visitante), que realiza diversos procedimientos de autenticacion y configuracion para autenticar el abonado MS 2 con la red VPLMN. La informacion enviada al vMSC 107 en la etapa 1501 incluye la direccion de red de la SIF 301 y los activadores de servicio asociados con respecto al abonado Ms 2.

Habiendo autenticado satisfactoriamente el usuario, el vMSC 107 espera que el abonado MS 2 solicite acceso a un servicio de red; una vez recibido (etapa 1503) el vMSC 107 envfa (etapa 1505) un mensaje a la SIF 301, que incluye datos que identifican el abonado MS 2 y que especifican el tipo de activador de servicio (en este ejemplo CAP iDp DP2), junto con detalles de CdPN (B) y CgPN (MS 2). Volviendo a la Figura 16, cuando se recibe un mensaje por la SIF 301, identifica en primer lugar el tipo de mensaje (etapa 1601). En este ejemplo, el tipo de mensaje se identifica para que sea un mensaje de establecimiento de servicio, y, puesto que el IDP representa una nueva llamada, la SIF 301 formula una consulta (etapa 1603), usando por ejemplo el Protocolo de Acceso de Directorio (DAP), para recuperar datos desde el SPS 303. Habiendo formulado y realizado una consulta adecuada, el SPS 303 devuelve datos de acuerdo con la misma, comprendiendo los datos una seleccion de reglas e informacion de servicio que especifica los servicios a los que tiene acceso el abonado MS 2 y las condiciones en las que pueden accederse los servicios (etapa 1605). En el presente ejemplo, la consulta del SPS 303 devuelve los siguientes datos:

MS2

• Aplicaciones de servicio:

o SHR, IN1: ambos configurados para responder a eventos DP2

• Condiciones:

o Regla (1) Acceder a SHR en primer lugar;

o Regla (2) si SHR devuelve direccion de correlacion para CdPN: (1) sustituir CdPN por direccion de correlacion; y (2) acceder a IN1 cuando llamada encaminada mediante HPLMN.

El motor de procesamiento de eventos 143 esta configurado a continuacion de acuerdo con estas condiciones (etapa 1607), habilitandole de manera eficaz para monitorizar datos que provienen del SHR, y para responder de acuerdo con los eventos (1) y (2) si debiera el SHR devolver una direccion de correlacion. Volviendo de nuevo a la Figura 15, en la etapa 1507 la SIF 301 envfa un mensaje al SHR que comprende los datos de activador (IDP e DP2), y, en la etapa 1509, recibe una respuesta desde el SHR (teniendo la aplicacion de servicio de SHR la responsabilidad para determinar si la llamada debiera encaminarse de manera domestica o no).

En este ejemplo, la aplicacion de servicio de SHR envfa una direccion de correlacion a la SIF 301, que procesa la misma de acuerdo con las etapas mostradas en la Figura 16: en la etapa 1601 la SIF 301 determina que los datos recibidos son desde la aplicacion de servicio de SHR, y pasa los datos al motor de procesamiento de eventos 143 (habiendose configurado previamente para monitorizar una entrada de este tipo). A continuacion, el motor de procesamiento de eventos 143 ejecuta las reglas recuperadas desde el SPS 303 con los datos recibidos como entrada, que en este caso comprenden datos que especifican que se ha de realizar el Encaminamiento Domestico, junto con una direccion de correlacion para lo mismo (etapa 1611). De acuerdo con la Regla (2), la siguiente accion a realizar es el envfo de la direccion de correlacion al vMSC 107 para cambiar la conmutacion con la que esta

5

10

15

20

25

30

35

40

45

50

55

60

65

conectado el abonado MS 2, por lo que el motor de procesamiento de eventos 143 prepara un mensaje para enviarse al vMSC (etapa 1613), y a continuacion prepara el motor de procesamiento de eventos 143 para monitorizar el siguiente evento conectado (etapa 1615). En este escenario particular, el motor de procesamiento de eventos 143 esta configurado para monitorizar el mismo Punto de Deteccion Inicial (IDP) como se envio a la SIF 301 en la etapa 1505.

Volviendo de nuevo a la Figura 15, en la etapa 1511 la SIF 301 envfa un mensaje de conexion al vMSC, que dirige el vMSC para traspasar a un conmutador que corresponde a la direccion de correlacion (CID). La SIF 301 tambien envfa un mensaje de TCAP, que cierra el dialogo entre la SIF 301 y el vMSC 107. En la etapa 1513 el vMSC 107 encamina la llamada al GMSC, que es el conmutador que tiene una direccion de red que corresponde a la direccion de correlacion de CID, y que esta localizado en la red domestica (HPLMN). Tras la recepcion del mensaje de conexion, el GMSC envfa un mensaje de IDP a la SIF 301, incluyendo el mensaje la direccion de correlacion de CID y un nuevo Punto de Deteccion DP3 (etapa 1515). Volviendo de nuevo a la Figura 16, habiendo identificado el mensaje como que se origina desde un conmutador y que comprende un Punto de Deteccion Inicial IDP que correlaciona con la CID previamente grabada por la SIF 301, el motor de procesamiento de eventos 143 ejecuta las reglas recuperadas desde el SPS 303 en la etapa 1603 con los datos recibidos como entrada (etapa 1611). De acuerdo con el evento restante (evento (2)), y habiendo recibido un mensaje desde un conmutador en la red domestica (HPLMN), la siguiente accion a realizar por la SIF 301 es enviar un mensaje a la aplicacion de servicio IN1, y esperar una respuesta desde la misma. Por consiguiente, en la etapa 1517, el motor de procesamiento de eventos 143 envfa un mensaje a IN1 y espera una respuesta.

Pueden haber varios otros eventos que dependen de la salida de IN1 - dependiendo de la naturaleza de la aplicacion de servicio - pero el ejemplo anteriormente expuesto demuestra como puede usarse la SIF 301 para coordinar una aplicacion de servicio de SHR junto con al menos otra aplicacion de servicio IN1 que es dependiente del mismo activador que el SHR (en este ejemplo DP2).

La funcionalidad de un sistema de procesamiento de eventos que implica aplicaciones de OSA unicamente se describira ahora con referencia a la Figura 17 que muestra un escenario generico que implica el procesamiento de activadores de entrada desde la red. Haciendo referencia a la Figura 17, en la etapa 1701 un evento IN se recibe por el SCS 103 y se pasa a la SIF 301, incluyendo el evento IN datos que identifican la parte llamante (abonado) y que especifican el tipo de activador de servicio (por ejemplo CAP IDP DP2), junto con detalles de la Parte Llamada (CdPN). Habiendo identificado este que es el primero de tal mensaje desde la red en relacion con el escenario de procesamiento de eventos actual, la SIF 301 formula una consulta (etapa 1703), usando por ejemplo el Protocolo de Acceso de Directorio (DAP), para recuperar datos desde el SPS 303 que corresponden al mismo. Tras la recepcion de la solicitud de consulta, el SPS 303 recupera datos que corresponden al abonado y activador desde el almacen de datos dinamico 313. Haciendo referencia de vuelta a la Figura 9, si tuvo lugar el registro de acuerdo con la primera disposicion, esta etapa implicara el filtrado de los datos dinamicos 313 usando los datos aprovisionados 311, y para el ejemplo mostrado en la Figura 9, dara como resultado una salida de App1 y App2. Por otra parte, si el registro tuvo lugar de acuerdo con la segunda disposicion, entonces puesto que el abonado accede a una aplicacion solicitante que se comprobo durante el proceso de registro, el SPS 303 simplemente tiene que recuperar los contenidos del almacen dinamico 313 (App1 y App2). Si el registro tuvo lugar de acuerdo con la tercera realizacion el SPS 303 recuperara los contenidos del almacen dinamico 313 (App1 y App2) junto con reglas de interaccion preseleccionadas que rigen la interaccion entre App1 y App2.

Para casos en los que el registro ha tenido lugar previamente de acuerdo con cualquiera del primer o el segundo metodo de registro, y a diferencia del tercer metodo de registro, una vez que se han identificado las aplicaciones pertinentes (App1, App2), el SPS 303 tiene que realizar una etapa separada de seleccion de reglas e informacion de servicio que especifica las condiciones en las que puede accederse a las aplicaciones; independientemente de si el metodo de registro de las reglas de interaccion ahora seleccionadas se han transmitido a continuacion a la SIF 301 en la etapa 1705. A continuacion, el motor de procesamiento de eventos 143 esta configurado de acuerdo con estas condiciones, que, para los fines del presente ejemplo, puede suponerse que provocan que se invoque la App2 antes de la App1. Por consiguiente en la etapa 1707 la App2 se invoca por medio de, por ejemplo, el mensaje callEventNotify(), y en la etapa 1709 se recibe una respuesta y se procesa por la SIF 301, mas espedficamente el motor de procesamiento de eventos 143 (habiendose configurado previamente para monitorizar una entrada de este tipo cuando se transmitio el mensaje de notificacion en la etapa 1707). A continuacion, el motor de procesamiento de eventos 143 ejecuta las reglas recuperadas desde el SPS 303 en la etapa 1705 con los datos recibidos en la etapa 1709 como entrada. De acuerdo con la regla o reglas procesadas, el motor de procesamiento de eventos 143 determina que la siguiente accion a realizarse es el envfo de datos recibidos en la etapa 1709 a la App1, por lo que el motor de procesamiento de eventos 143 envfa un mensaje callEventNotify() a la App1 (etapa 1711), y a continuacion prepara el motor de procesamiento de eventos 143 para monitorizar el siguiente evento conectado. Habiendo recibido una respuesta desde la App1 (etapa 1713) el motor de procesamiento de eventos 143 ejecuta las reglas recuperadas desde el SPS 303 en la etapa 1705 con los datos recibidos en la etapa 1713 como entrada. De acuerdo con la regla o reglas procesadas, el motor de procesamiento de eventos 143 determina que la siguiente accion a realizar es la conexion de la parte llamante (abonado) con la Parte Llamada (VPS de buzon), y por consiguiente la SIF 301 provoca que el sCs 103 envfe un mensaje de conexion a la red (etapa 1715), que dirige a la red para conectar el abonado a su VPS de buzon de voz, que le posibilita acceso a sus mensajes grabados. La

5

10

15

20

25

30

35

40

45

50

55

60

65

etapa 1717 indica la transmision de eventos de red adicionales con respecto a los que una o mas aplicaciones de OSA han registrado un interes.

La Figura 18 muestra un ejemplo de un sistema de procesamiento de eventos que implica aplicaciones de OSA e IN, y muestra que las realizaciones de la invencion pueden usarse tambien para controlar la operacion de aplicaciones de OSA y servicios de IN como parte de un servicio de procesamiento de eventos global con relacion a un activador de red. En este escenario, las etapas 1701, 1703, 1705 avanzan como se describe en relacion con la Figura 17, pero puesto que, en este ejemplo, se supone que el activador en cuestion provoca que el SPS solicite datos relacionados tanto con servicios de IN como aplicaciones de OSA, los datos devueltos por el SPS 303 incluiran reglas de invocacion que provocan que el SCS 103 intercale la transmision de mensajes al dominio de IN con transmision de mensajes en el dominio de OSA; una lista de las etapas asociadas se expone en la figura.

A partir de los ejemplos anteriores, puede observarse que un sistema de procesamiento de eventos configurado de acuerdo con las realizaciones de la invencion proporciona una Funcion de Integracion de Servicio que integra, y controla la operacion de, una pluralidad de aplicaciones de servicio. En disposiciones de red que comprenden una pluralidad de sistemas de procesamiento de eventos, puede desarrollarse un repositorio central de aplicaciones de servicio que son accesibles por uno cualquiera, o un subconjunto, de tal SIF de acuerdo con las reglas de acceso asignadas a un sistema de procesamiento de eventos particular. Ademas, en cualquier SIF dada que proporcione acceso a una pluralidad de aplicaciones de servicio a medida y/o heredadas, la SIF esta configurada para integrar estas aplicaciones entre sf y con otras aplicaciones de servicio que se esten desarrollando recientemente. Una caractenstica particularmente ventajosa de las realizaciones de la invencion es que la SIF comprende un medio para anunciar de manera eficaz la funcionalidad de la misma, posibilitando que las aplicaciones de servicio recientemente desarrolladas utilicen tal funcionalidad de una manera proactiva; esta funcionalidad se muestra, esquematicamente, como la API de SCS 148 en la Figura 14.

Ejemplos adicionales que ilustran la flexibilidad asociada con realizaciones de la invencion se presentan en las Figuras 19 - 23, la primera de las cuales ilustra la operacion de coordinacion de SIF 301 de una aplicacion de busqueda tal como el servicio de iVPN (App 1) con la operacion de la Aplicacion de Voz Sin Interrupciones Internacional (App 2). En este ejemplo la aplicacion de busqueda App1 esta dispuesta para determinar cuales de los dispositivos registrados de una parte llamada (abonados) estan activos y proporcionar un servicio de traduccion de numero en relacion con la misma. El ejemplo podna incluir adicionalmente una aplicacion de SHR (ya sea en la SIF o como una aplicacion separada (no mostrada)), que se usana para ordenar que el vMSC traspase el control de llamada a un GMSC, de la manera anteriormente descrita en los ejemplos anteriores. En respuesta a la recepcion de una solicitud de conexion (etapa 1901) del vMSC, la SIF esta configurada (por medio de reglas recuperadas del SPS 303, como se ha descrito anteriormente (expuestas a continuacion)) para enviar una solicitud (etapa 1903) para un servicio de traduccion de numero a la App 1. Como se ha descrito anteriormente, la App 1 es una aplicacion de busqueda de iVPN que tiene acceso a una lista pre-especificada de dispositivos registrados para el abonado, y, en respuesta al mensaje de solicitud de servicio enviado desde la SIF en la etapa 1903, envfa de vuelta (etapa 1905) un numero de dfgito completo traducido que corresponde a un primer dispositivo en la lista, junto con una solicitud para un mensaje de ocupado de ERB en el caso de que el dispositivo no este disponible. En respuesta a la recepcion del numero traducido del primer dispositivo desde App1 la SIF establece un evento de espera (etapa 1907) para un mensaje de ocupado de RRB desde el vMCS y envfa un mensaje (etapa 1909) a la App 2, que incluye detalles del numero traducido. La App 2 a continuacion envfa una instruccion Conectar (etapa 1911) a la SIF, junto con una solicitud para un mensaje de ocupado de ERB en el caso que el primer dispositivo no este disponible.

La SIF 301 a continuacion consolida la entrada desde ambas aplicaciones App1, App2 y envfa una solicitud de conexion con respecto al primer dispositivo al vMSC (etapa 1913). En el presente ejemplo el primer dispositivo no esta disponible para el vMSC que devuelve un mensaje de ocupado de eRb a la SIF (etapa 1915); de acuerdo con las reglas aplicables en este ejemplo, la SIF esta dispuesta para priorizar la recepcion de mensajes de ocupacion de ERB y enviarlos a la aplicacion de busqueda App 1 en el primer caso, mientras que marca el hecho de que la App 2 necesita informarse del hecho de que el primer dispositivo no esta disponible. Habiendo recibido un mensaje de ocupado de ERB la SIF envfa el mensaje de ocupado de ERB a la App 1 (etapa 1917), que, en respuesta al mismo, recupera y transmite detalles de un segundo dispositivo en la lista del abonado a la SIF (etapa 1919). Tras la recepcion de la identidad de este segundo dispositivo (identidad larga Y), la SIF finaliza la sesion con la App 2 en relacion con el primer dispositivo (etapa 1921) e inicia una segunda sesion en relacion con el segundo dispositivo (etapa 1923). La App 2 a continuacion envfa una solicitud de Conexion a la SIF (etapa 1925), esta vez en relacion con el segundo dispositivo (acompanandose la solicitud de conexion, como anteriormente, con una solicitud para un mensaje de ocupado de ERB en el caso de que el segundo dispositivo no este disponible). La SIF 301 de nuevo consolida la entrada desde ambas aplicaciones App1, App2 y envfa una solicitud de conexion con respecto al segundo dispositivo al vMSC (etapa 1927), y las etapas posteriores (no mostradas) continuan en dependencia de la disponibilidad, o de otra manera, del segundo dispositivo (es decir si el segundo dispositivo no esta disponible las etapas 1915 - 1927 se repiten de manera eficaz, mientras que si el segundo dispositivo esta disponible, el vMSC continua para procesar la llamada.

Las reglas que podnan aplicarse en relacion con este ejemplo adicional (segun se recuperan del SPS 303 y son ejecutables por la SIF 301 para proporcionar la funcionalidad anteriormente descrita) son como sigue:

5

10

15

20

25

30

35

40

45

50

55

60

65

En el presente ejemplo, para el activador CAP T-CSI y abonado MS 2, la consulta del SPS 303 devuelve los siguientes datos de servicio y conjuntos de condiciones:

• Aplicaciones de servicio:

o SHR, Aplicacion de Busqueda (varios dispositivos registrados), iSVA

• Condiciones:

o Comprobar si el SHR aplicable (es decir ^esta el MSC en VPLMN?); si es aplicable, enviar direccion de correlacion a conmutador en VPLMN; o Regla (1): Busqueda de acceso appln en primer lugar;

o Regla (2): Si la respuesta desde la Aplicacion de Busqueda indica una conexion con un ajuste (que corresponde a un primer dispositivo) de una direccion de encaminamiento de destino (DRA), modificar el numero de parte llamada en el IDP para que sea el DRA y enviar el IDP modificado a la aplicacion de ISVA. De otra manera, o en cualquier otro caso, enviar el IDP no modificado a la ISVA.

o Regla (3): Si la respuesta desde el servicio de ISVA (CdPN), almacenar CdPN hasta que el MS 2 se conecte al conmutador en el HPLMN;

o Regla (4): Si appln de busqueda e ISVA ambas solicitan mensajes de ocupacion de RRB, enviar cualquier mensaje de ocupado de ERB recibido a la appln de busqueda, recuperar nueva direccion de encaminamiento de destino (es decir DRA que corresponde al segundo dispositivo), finalizar dialogo con ISVA basandose en la primera DRA, y enviar dRa modificada a ISVA.

o Regla (5): una vez que MS 2 se conecto mediante HPLMN, enviar mensaje Conectar al conmutador en HPLMN.

Un ejemplo adicional se describira ahora, con referencia a la Figura 20, que muestra otro ejemplo de la operacion de coordinacion de SIF 301 de un Nodo de Servicio Inteligente (VPN) con un nodo de servicio de OSA (aplicacion de busqueda VPX). En este ejemplo se supone que el abonado ya se ha suscrito a un servicio de VPN como un servicio de red inteligente, y desea que este este integrado con sus servicios de OSA recien retomados. Por consiguiente, y volviendo a la Figura 20, en respuesta a la recepcion de una solicitud de conexion (etapa 2001) desde el MSC, la SIF esta configurada (por medio de reglas recuperadas desde el SPS 303, como se ha descrito anteriormente) para enviar una solicitud (etapa 2003) al servicio de VPN. En respuesta, el VPN envfa de vuelta (etapa 2005) un numero de dfgito completo que corresponde al numero de parte llamada. En respuesta, la SIF envfa un mensaje (etapa 2007) a VPX, que incluye detalles del numero de dfgito completo. La aplicacion de VPX envfa una instruccion Conectar (etapa 2009), con respecto al primer dispositivo que corresponde al numero de dfgito completo de la parte llamada (identidad E), a la SIF, junto con una solicitud para un mensaje de ocupado de ERB en el caso de que el primer dispositivo no este disponible. La SIF establece un evento de espera (etapa 2011) para un mensaje de ocupado de RRB desde el MCS, consolida la entrada desde ambas aplicaciones VPN, VPX y envfa una solicitud de conexion con respecto al primer dispositivo al MSC (etapa 2013). En el presente ejemplo el primer dispositivo no esta disponible por lo que el MSC devuelve un mensaje de ocupado de ERB a la SIF (etapa 2015), que provoca que la SIF envfe el mensaje de ocupado de ERB a VPX (etapa 2017), que, en respuesta al mismo, recupera y transmite detalles de un segundo dispositivo en la lista del abonado a la SIF (etapa 2019). Tras la recepcion de la identidad de este segundo dispositivo (identidad F), la SIF envfa una solicitud de conexion con respecto al segundo dispositivo al MSC (etapa 2021), y a las etapas posteriores (no mostradas) que continuan en dependencia de la disponibilidad, o de otra manera, del segundo dispositivo (es decir si el segundo dispositivo no esta disponible las etapas 2017 - 2021 se repiten de manera eficaz).

Se muestra otro ejemplo en la Figura 21, que muestra el uso de la SIF 301 para coordinar la operacion de servicios post pago y prepago: en este ejemplo la SIF 301 esta configurada para realizar procesamiento con respecto a las tarifas de post pago para modificarlas en un formato adecuado para un servicio prepago. Tales aplicaciones de post pago incluyen una aplicacion de VPN y una aplicacion de “Zona Oficina”, la ultima de las cuales identifica la localizacion de un abonado y modifica la tarifa convencional (es decir tarifa de VPN) en dependencia de las mismas. En respuesta a la recepcion de una solicitud de conexion (etapa 2101) desde el MSC, la SIF identifica en primer lugar, basandose en la clave de servicio SK(a) que acompana la solicitud de recopilacion y los datos solicitados desde el SPS 303, que el abonado es del tipo prepago, que se le ha concedido acceso a diversos servicios de post pago de OSA (siendo cada uno identificable mediante claves de servicio SK(b) y SK(c) respectivamente). Por consiguiente, en la etapa 2103, la SIF 301 esta configurada para enviar una solicitud a la pasarela 101, que identifica la aplicacion a consultarse en esta etapa por medio de la clave de servicio SK(b); tras la recepcion de la clave de servicio SK(b) y datos de llamada asociados, la pasarela 101 envfa un mensaje calleventNotify() a la aplicacion que corresponde a la clave de servicio SK(b), que en este caso es App 2 (etapa 2105). La App 2 es una Aplicacion de Busqueda de VPN que tiene acceso a una lista predefinida de dispositivos registrados para el abonado, y, en respuesta al mensaje de solicitud de servicio enviado desde la GW 101, envfa de vuelta (etapa 2107) un numero de dfgito completo, traducido que corresponde a un primer dispositivo en la lista, junto con una tarifa asociada con este servicio. En vista del hecho de que la App 2 es una aplicacion post pago, la GW de OSA 101 empaqueta la informacion de tarifa con el mensaje de respuesta de facturacion de sCi asociado y envfa esta en la SIF (etapa 2109). De acuerdo con las reglas enviadas desde el SPS 303, la SIF a continuacion indica que la siguiente

5

10

15

20

25

30

35

40

45

50

55

60

aplicacion a consultarse es la aplicacion de Oficina Domestica App 1, y env^a una solicitud a la pasarela 101, incluyendo la solicitud datos que identifican la App 1 por medio de la clave de servicio SK(c) y datos que identifican la parte llamada (etapa 2111); tras la recepcion de la clave de servicio SK(c), la pasarela 101 reconoce que la solicitud se ha de enviar a la aplicacion de oficina App1 y envfa el numero de parte llamada (B largo) a la misma (etapa 2113). En respuesta, la App 1 envfa datos indicativos de una tarifa asociada con la localizacion de la parte llamante - tarifa Y - a la SIF, mediante la GW de OSA 101 (etapas 2115, 2117). Una vez en la recepcion de la informacion de tarifa diferente, la SIF procesa los datos para identificar una tarifa adecuada para proporcionar al abonado con estos servicios - en su capacidad como un tipo de abonado de prepago (etapa 2119). La salida de este proceso de evaluacion es la transmision de un mensaje que comprende unos datos de tarifa combinados y solicitud de servicio al servicio de prepago IN1 (etapa 2121). Una vez recibido, el servicio de prepago IN1 realiza el proceso de evaluacion de facturacion convencional y (suponiendo que el abonado tiene fondos suficientes) envfa una solicitud para conexion de llamada y solicitud para mensaje de ocupado (etapa 2123) a la SIF 301. En respuesta a lo mismo, la SIF 301 establece un evento de espera para un mensaje de ocupado de RRB desde el MSC y envfa una solicitud de conexion con respecto al primer dispositivo al MSC.

Un ejemplo adicional mas se muestra en la Figura 22, que muestra interacciones entre la SIF 301 y el SPS 303 (habiendose supuestos estos que ya se han realizado en los ejemplos anteriores) asf como interacciones con nodos de servicio en la red. En este ejemplo la SIF 301 y el SPS 303 interconectan de manera elegante para resolver un problema experimentado por abonados que realizan itinerancia en una red que no es Camel 3, en concreto que surge cuando el HLR 115 unicamente envfa servicios O-CSI al VLR. Cuando unicamente se equipan con servicios O-CSI el vMSC no puede discriminar entre llamadas que tienen prefijos especificados y eventos que necesitan encaminamiento domestico (y otros servicios); como resultado las llamadas que tienen un prefijo no reconocido por el vMSC se manejan incorrectamente. (Estos prefijos se denominan los “B#”, y los correspondientes eventos necesitan datos de servicio N-CSI/DCSI para que el VLR conozca que debena procesarse una llamada por un nodo de servicio de Pulsar para Hablar). En este ejemplo se supone que el SPS 303 se aprovisiona para poder identificar si una llamada entrante debena enviarse a un nodo de Pulsar para Hablar o Encaminado de manera domestica, basandose en el B# - codificando esencialmente los datos basandose en B# ademas de datos de abonado y de activador. Haciendo referencia a continuacion a la Figura 22, en la etapa 2201 el vMSC envfa un mensaje a la SIF, incluyendo el mensaje un B# como prefijo para el numero de parte llamada. En respuesta, la SIF 301 contacta con el SPS 303, que solicita informacion espedfica de servicio en relacion con el numero de parte llamada (etapa 2203) y el abonado. En la etapa 2205 el sPs 303 realiza algun procesamiento interno, comparando el prefijo con datos almacenados con respecto a este abonado en relacion con servicios de B#. En el caso de que los datos almacenados indiquen que este abonado se ha suscrito a servicios de Pulsar para Hablar, los datos indicativos del servicio se enviaran a la SIF 301 (etapa 2207), que posibilita que la SIF 301 envfe un mensaje un tanto identico al servicio corregido (en este punto PTT). Si el abonado no ha invocado el servicio de PTT, el sPs 303 enviana en su lugar datos que indican que la llamada debena encaminarse de manera domestica, provocando que la SIF 301 comunique con el nodo de SHR mostrado en la Figura 22.

Se muestra un ejemplo adicional en la Figura 23, que muestra la SIF 301 que controla el Reenvfo de Llamada Tardfa (LCFOR) en conjunto con un servicio prepago IN2 para evitar la situacion en la que, cuando la parte A llama a la parte By la parte B esta realizando itinerancia, se establece un circuito de voz entre el conmutador al que esta conectado la parte A (en la red domestica); el vMSC asociado con la parte B en la red visitada; y un nodo de servicio asociado en la red domestica al que el abonado tiene acceso. Haciendo referencia a continuacion a la Figura 23, en la etapa 2301 se recibe un punto de deteccion de llamada de terminacion por la SIF 301 desde la pasarela de MSC; la SIF 301 solicita datos que corresponden al abonado desde el SPS 303, y, que identifican que el abonado se ha suscrito a un servicio de LCFOR ademas de un servicio adicional IN2 (no especificado), la SIF 301 identifica que necesita invocar el nodo de LCFOR en primer lugar. Por consiguiente, en la etapa 2303 la SIF 301 envfa datos que indican que la llamada es una llamada de terminacion para el nodo de servicio de LCFOR, que envfa una solicitud para un mensaje de ocupado de ERB/No contestacion/abandonado/mensaje contestado a la SIF 301 en la etapa 2305. La SIF 301 registra, internamente, que necesita monitorizar cualquiera de tales mensajes de ERB desde el MSC una vez que el control de la llamada se pasa al MSC de pasarela, y envfa un mensaje al otro nodo de servicio (se muestra uno: IN2) al que el abonado llamado tiene acceso (etapa 2307). El nodo de servicio IN2 envfa un mensaje de facturacion y solicita un mensaje de respuesta de ERB a la SIF 301 con respecto a una llamada que se esta respondiendo (etapa 2309), que provoca que la SIF 301 registre que necesita monitorizar llamadas que se estan respondiendo, e informar al nodo de servicio IN2. La SIF 301 a continuacion ordena al GMSC que continue avanzando la llamada (etapa 2311), que provoca que el GMSC conecte al vMSC (etapa 2313). En respuesta a la llamada que se esta respondiendo, el GMSc envfa un mensaje de ERB a la SIF (etapa 2317); en vista del hecho de que el nodo de LCFOR registrado para un mensaje de este tipo en la etapa 2305, la SIF 301 reenvfa el mensaje al nodo de LCFOR en la etapa 2319, que, en respuesta, envfa una instruccion para Reenvfo de Llamada a la SIF (etapa 2321). En respuesta a la recepcion de este mensaje la SIF 301 finaliza la sesion previamente activa con el nodo IN2 en la etapa 2323, y en su lugar inicia una sesion con respecto a un evento de reenvfo de llamada (etapa 2325). La facturacion de llamada con respecto a un evento de reenvfo de llamada de este tipo a continuacion se configura y la SIF 301 ordena que el GMSC se conecte al Numero Reenviado en la etapa 2329.

Detalles de la realizacion adicional

Aunque las realizaciones han descrito el procesamiento de llamada SS7, las realizaciones de la invencion podnan aplicarse a otros tipos de eventos de red, incluyendo procesamiento de llamada de SIP (Protocolo de Iniciacion de 5 Sesion) y procesamiento de mensaje.

Adicionalmente, la operacion de la SIF 301 puede iniciarse por invocacion de metodo a traves de una API - por ejemplo CORBA, SOAP de modo que la SIF puede proporcionar una facilidad de intermediacion de servicio a traves de las aplicaciones de servicio de IN.

10

Aunque la SIF 301 se describe como una unica entidad, se apreciara que una entidad de este tipo puede distribuirse a traves de una pluralidad de componentes de procesamiento.

Las realizaciones anteriores se han de entender como ejemplos ilustrativos de la invencion, y se preven 15 realizaciones adicionales de la invencion. Se ha de entender que cualquier caractenstica descrita en relacion con una realizacion cualquiera puede usarse en solitario, o en combinacion con una o mas caractensticas de cualquier otra de las realizaciones, o cualquier combinacion de cualquier otra de las realizaciones. Adicionalmente, pueden emplearse equivalentes y modificaciones no descritas anteriormente sin alejarse del alcance de la invencion, que se define en las reivindicaciones adjuntas.

20

Claims (34)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   60

   65

   REIVINDICACIONES

   1. Aparato de procesamiento de eventos (301) en una red de comunicaciones para uso al procesar mensajes de solicitud de iniciacion de servicio en un sistema de procesamiento de eventos, siendo conectable el aparato (301) a una pluralidad de nodos de servicio desde los cuales un abonado puede recibir servicio durante el procesamiento de un evento de red, pudiendo transmitir cada dicho nodo de servicio un mensaje de respuesta de servicio que comprende datos particulares para operacion del nodo de servicio, comprendiendo el aparato una funcion dispuesta, al recibir un primer mensaje de solicitud de iniciacion de servicio enviado por un nodo servidor en una red actualmente implicada en el procesamiento de dicho evento de red, para solicitar mensajes de respuesta de servicio desde una pluralidad de nodos de servicio, y para controlar la operacion de al menos alguno de dicha pluralidad de nodos de servicio implicados en el procesamiento del mismo evento de red basandose en los datos contenidos en dichos mensajes de respuesta de servicio,

   en el que, en el caso de que los datos contenidos en un mensaje de respuesta de servicio recibido desde uno de la pluralidad de nodos de servicio sea indicativo de una solicitud para un recurso de senalizacion que solapa o entra en conflicto con datos contenidos en un mensaje de respuesta de servicio recibido desde otro de la pluralidad de nodos de servicio, la funcion esta dispuesta para procesar los datos contenidos en respectivos mensajes de respuesta de servicio basandose en datos de atributos para posibilitar el acceso al recurso de senalizacion solicitado por cada respectivo nodo de servicio implicado en el procesamiento del mismo evento de red,

   en el que los datos de atributo especifican reglas para interaccion entre la pluralidad de nodos de servicio basandose en los mensajes de respuesta de servicio recibidos.
2. 2. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 1, en el que, basandose en el contenido de dicho mensaje de respuesta de servicio, la funcion esta dispuesta para controlar la operacion de un nodo de servicio dado mas de una vez durante el mismo evento de red.
3. 3. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 1 o la reivindicacion 2, en el que la funcion esta dispuesta para enviar un mensaje de solicitud de servicio a respectivos nodos de servicio, comprendiendo al menos uno de dicho mensaje de solicitud de servicio datos indicativos de uno o mas activadores de iniciacion de servicio que corresponden a dicha primera solicitud de iniciacion de servicio.
4. 4. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 3, en el que la funcion esta dispuesta para modificar al menos uno de dicho activador de iniciacion de servicio y para formular un mensaje de solicitud de servicio basandose en dicho activador de iniciacion de servicio modificado.
5. 5. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 1 a la reivindicacion 4, en el que la funcion esta dispuesta para monitorizar la recepcion de mensajes de solicitud de iniciacion de servicio adicionales como resultado de la operacion.
6. 6. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 1 a la reivindicacion 5, en el que la funcion esta dispuesta para monitorizar la recepcion de mensajes de respuesta adicionales como resultado de la operacion.
7. 7. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 1 a la reivindicacion 6, en el que, en la recepcion de un segundo mensaje de solicitud de iniciacion de servicio enviado por un nodo servidor en la red actualmente implicada en el procesamiento del mismo evento de red, la funcion esta dispuesta para controlar la operacion de al menos uno de dicha pluralidad de nodos de servicio, y como resultado de la operacion, para transmitir un mensaje de respuesta de servicio al nodo servidor desde el que se recibe el segundo mensaje de solicitud de iniciacion de servicio.
8. 8. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 7, en el que el primer mensaje de solicitud de iniciacion de servicio se recibe desde el mismo nodo servidor que desde el cual se recibe el segundo mensaje de solicitud de iniciacion de servicio.
9. 9. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 1 a la reivindicacion 8, en el que el mensaje de solicitud de iniciacion de servicio incluye datos que identifican el activador de iniciacion de servicio correspondiente, y la funcion esta dispuesta para acceder a datos que identifican nodos de servicio que corresponden a dicho activador de iniciacion de servicio, para uso al controlar la operacion del mismo.
10. 10. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 1 a la reivindicacion 9, en el que la funcion esta dispuesta para generar un mensaje de solicitud de servicio en dependencia de datos asociados con el abonado y dichos datos contenidos en dicho primer mensaje de solicitud de iniciacion de servicio.
11. 11. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 5, en el que el mensaje de solicitud de iniciacion de servicio adicional comprende datos de activador diferentes de datos de activador contenidos dentro de dicho mensaje de solicitud de iniciacion de servicio.

    5

    10

    15

    20

    25

    30

    35

    40

    45

    50

    55

    60

    65
12. 12. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 10 o la reivindicacion 11, en el que la funcion esta dispuesta para solicitar dichos mensajes de respuesta de servicio durante la asignacion de recursos de red asociados con el evento de red.
13. 13. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que la funcion esta dispuesta para modificar al menos uno de dicho activador de iniciacion de servicio y para formular un mensaje de solicitud de servicio basandose en dicho activador de iniciacion de servicio modificado.
14. 14. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que, en respuesta a recibir dicho primer mensaje de solicitud de iniciacion de servicio, el aparato esta dispuesto para transmitir segundos mensajes de solicitud de iniciacion de servicio a dos o mas de dichos nodos de servicio en una secuencia seleccionada.
15. 15. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 14, en el que la secuencia seleccionada depende de los mensajes de respuesta de nodo de servicio recibidos desde uno o mas de dichos nodos de servicio.
16. 16. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que el aparato (301) comprende una funcion de monitorizacion dispuesta para monitorizar un mensaje de respuesta de servicio desde dicho un primer nodo de servicio y el aparato (301) esta dispuesto para transmitir un segundo mensaje de solicitud de iniciacion de servicio a dicho un segundo nodo de servicio en respuesta a dicho mensaje de respuesta de servicio.
17. 17. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que el aparato (301) esta dispuesto para invocar una funcion de monitorizacion en respuesta a la recepcion de mensajes de respuesta de nodo de servicio desde dicho primer nodo de servicio.
18. 18. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 16 o la reivindicacion 17, en el que los datos para uso mediante la funcion de monitorizacion son dependientes, al menos en parte, de los datos incluidos en el mensaje de respuesta de nodo de servicio recibido desde dicho primer nodo de servicio.
19. 19. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 16, en el que dicho segundo nodo de servicio es diferente de dicho primer nodo de servicio.
20. 20. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 16 o la reivindicacion 17, en el que la funcion de monitorizacion esta dispuesta para monitorizar un mensaje de solicitud de iniciacion de servicio enviado desde un nodo servidor distinto del nodo servidor desde el que se enviaron dichos primeros mensajes de solicitud de iniciacion de servicio.
21. 21. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 16, en el que los segundos mensajes de solicitud de iniciacion de servicio son del mismos tipo que el primer mensaje de solicitud de iniciacion de servicio.
22. 22. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de las reivindicaciones anteriores, dispuesto para generar un mensaje de instruccion de servicio en respuesta a un mensaje de respuesta de nodo de servicio, incluyendo el mensaje de instruccion de servicio datos que solicitan un cambio al nodo servidor implicado en dicho procesamiento de eventos, en el que el aparato (301) esta dispuesto para transmitir dicho mensaje de instruccion de servicio al nodo servidor desde el que se recibio el primer mensaje de solicitud de iniciacion de servicio.
23. 23. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 22, en el que el mensaje de instruccion de servicio generado comprende datos que ordenan al nodo servidor que traspase el evento de red a un nodo servidor diferente.
24. 24. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 23, en el que dicho nodo servidor diferente esta localizado en una red diferente a aquella en la que el nodo servidor esta dispuesto para operar.
25. 25. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 24, en el que uno de dichos nodos de servicio es un nodo de pasarela que proporciona acceso a una pluralidad de nodos de servicio adicionales mas alla de la pasarela.
26. 26. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 25, en el que dichos nodos de servicio proporcionan uno o alguno de: servicios de traduccion de numero, servicios de manejo de mensajes, servicios de modificacion de mensajes, servicios de encaminamiento de mensajes, servicios de correo de voz, servicios de diversion de llamada y/o servicios de busqueda de dispositivo.

    5

    10

    15

    20

    25

    30

    35

    40

    45
27. 27. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 1, en el que el aparato (301) es sensible a la recepcion de uno de dichos mensajes de solicitud de registro de servicio enviados desde un nodo de servicio de registro para almacenar datos de registro indicativos del nodo de servicio registrado y activador de iniciacion de servicio correspondiente en asociacion con el abonado, siendo dichos datos de registro para uso al procesar mensajes de solicitud de iniciacion de servicio enviados desde dicho nodo servidor con respecto al abonado,

    estando dispuesto el aparato (301) para almacenar datos de registro para una pluralidad de mensajes de solicitud de registro de servicio identificando cada uno un nodo de servicio diferente y el mismo abonado,

    en el que el aparato esta dispuesto para definir un orden de preferencia entre dichos diferentes nodos de servicio despues de que se han recibido dichos datos de registro.
28. 28. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 27, en el que el aparato (301) esta dispuesto para almacenar dichos datos de registro si el mensaje de solicitud de registro se recibe desde un nodo de servicio identificado como accesible para el abonado.
29. 29. Aparato de procesamiento de eventos (301) de acuerdo con la reivindicacion 27 o 28, en el que en respuesta a la recepcion de un segundo y posterior mensaje de solicitud de registro, el aparato (301) esta dispuesto para recuperar datos de interaccion que especifican interacciones entre correspondientes dos o mas nodos de servicio y para almacenar dichos datos de interaccion, definiendo de esta manera un orden de preferencia entre dichos diferentes nodos de servicio.
30. 30. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 27 a la reivindicacion 29, en el que en respuesta a la recepcion del mensaje de solicitud de iniciacion de servicio, el aparato (301) esta dispuesto para recuperar datos de interaccion que especifican interacciones entre correspondientes dos o mas nodos de servicio, definiendo de esta manera un orden de preferencia entre dichos diferentes nodos de servicio.
31. 31. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 27 a la reivindicacion 30, en el que el aparato (301) esta dispuesto para almacenar datos de registro adicionales con respecto a un mensaje de solicitud de registro de servicio adicional que identifica un nodo de servicio diferente adicional y el mismo abonado, recibiendose dicho mensaje de solicitud de registro de servicio adicional posteriormente, estando dispuesto el aparato (301) para definir un orden de preferencia entre dichos diferentes nodos de servicio despues de que se hayan almacenado dichos datos de registro adicionales.
32. 32. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 27 a la reivindicacion 31, en el que dicha pluralidad de mensajes de solicitud de registro de servicio se reciben a diferentes tiempos.
33. 33. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 27 a la reivindicacion 32, en el que el mensaje de solicitud de iniciacion de servicio incluye datos que identifican un activador de iniciacion de servicio correspondiente, y la funcion esta dispuesta para acceder a datos indicativos de un orden de preferencia entre dichos diferentes nodos de servicio, para uso al controlar la operacion de los mismos.
34. 34. Aparato de procesamiento de eventos (301) de acuerdo con una cualquiera de la reivindicacion 27 a la reivindicacion 33, en el que dichos datos de registro identifican una pluralidad de abonados con respecto a los que se refiere la solicitud de registro.