GB2413030A - Event processing system - Google Patents

Abstract

Processing network events in a telecommunications network particularly for use in controlling operation of a plurality of service nodes, each of which is arranged to provide a particular network service in a mobile or fixed network or a combination of both. Managing registration of service nodes within the network, and providing apparatus for processing service registration request messages in a call processing system, each said service registration request message including registration data identifying a service node, a service initiation trigger and a subscriber in respect of whom the registration request relates, the apparatus being connectable to a serving node in a network involved in call processing and to a service node from which a subscriber is able to receive service during call processing, the serving node being capable of transmitting a plurality of service initiation request messages to said apparatus, each service initiation request message corresponding respectively to a different service initiation trigger, ```wherein the apparatus is responsive to receipt of one of said service registration request messages sent from a registering service node to store registration data indicative of the registered service node and corresponding service initiation trigger in association with the subscriber, said registration data being for use in processing service initiation request messages sent from said serving node in respect of the subscriber, ```the apparatus being arranged to store registration data for a plurality of service registration request messages each identifying a different service node and the same subscriber, ```wherein the apparatus is arranged to define an order of precedence between said different service nodes after said registration data have been received.

Description

Event Processing System

Field of the Invention

The present invention relates to a method and a system for processing network events in a telecommunications network, and is particularly, but not exclusively, suited to a system in which such events are processed by means of disparate types of service nodes, each of which is arranged to provide a particular network service in a mobile network, or a fixed network or a combination of the two.

Background of the Invention

Technical convergence between the telecommunications, computing and multimedia domains has given rise to a new environment for the development and provision of telecommunications services. This has compelled both telecom operators and service providers to develop and deploy new residential and enterprise services and applications. To meet this challenge operators and service providers have sought to replace closed, proprietary systems with standardised, open, interoperable and common platforms.

Parlay is an open multi-vendor consortium formed to develop such open technology independent APIs, enabling Internet Service Vendors, network device vendors, software developers, service providers, ASPs and enterprises to create applications that can run across multiple mobile and fixed carrier networks. The Parlay/OSA (Open Service Architecture) standard defines an API (application programming interface) that is technology agnostic and configured to use protocols and technologies such as SIP (Session Initiation Protocol), JAIN (Java APIs for Intelligent Networks) and Web Services to communicate with third party devices and services in different domains.

Whilst this framework has greatly improved the interoperability of services, there are, nevertheless, implementation issues associated with, for example, disparate services registering for interest in network events. In the following description is it assumed that "an application/service registering for interest in..." means "an application/service is arranged to react to...", and that "a network event" means, for example, a trigger from the network (or indeed another service or application node) in respect of a specified destination and source address.

There are currently 14 Service Control Functions (SCF), including various generic call control (GCC) and multi party call control (MPCC) SCFs; between them, the GCC/MPCC SCFs map to all of the Intelligent Network (IN) messages, and can therefore invoke all of the network capabilities. Using the Parlay APIs, any given service can register and deregister for network events (by means of e.g. for GCC SCFs, enableCallNotification() and disableCallNotification() methods respectively and for MPCCSCFs, by means of createNotification() and destroyNotification() methods respectively) each registration request corresponding to one or more subscribers (source address) and/or destination address(es) (e.g. a specified number in the case of number translation services). A simplified representation of the network and OSA domains is shown in Figure 1, and an example of the routing of GCC registration messages between OSA and network devices is shown in Figure 2.

In this example an application Appl is arranged to check the balance of specified subscribers prior to allocation of network resources, and accordingly Appl invokes the enableCallNotification() method each time it determines that a subscriber's balance needs checking prior to allocating network resources in respect of the requested service. This results in a MAP AnyTimeModification() message being sent to the HER in order to activate the necessary subscription information (O-CSI, D-CSI (activated in relation to the subscriber's address)).

Having successfully registered for this network event, when such a specified subscriber subsequently requests a service (i.e. O-CSI (data identifying the subscriber)), Appl is invoked and used to control at least the initial part of the service provision procedure.

The enableCallNotification() method is purely intended for applications to indicate their interest to be notified when certain call events take place. It is possible to subscribe to a certain event for a whole range of addresses, e.g. the application can indicate it wishes to be informed when a call is made to any number starting with 800. If an application has already requested notifications with criteria that overlap the specified criteria, the request is refused with, for example, P_GCCS_INVALID_CRITERIA for a GCC registration message and P_INVALID_CRITERIA for an MPCC registration message. The criteria are said to overlap if both originating and terminating destination addresses overlap and the same number plan is used and the same CallNotificationType (e.g. network trigger) is used. As a result, in most configurations only one application can place a request for a given set of criteria.

British Telecommunications Exact Technologies has identified that having a hard and fast rule of "any overlap-no-co-existence" is overly restrictive and has presented a solution whereby the Parlay GW comprises a Policy Management Service Capability Function (SCF), arranged to cooperate with the Call Control SCF shown in Figure 1 when an application attempts to register with the gateway. Their Policy Management SCF manages a store of user profiles in which details of services to which a given subscriber has access, together with the respective trigger events, are stored. The user profiles are populated only after the Policy Management SCF has checked that applications can co-exist, their co- existence having been checked by means of a feature interaction processing function which is provisioned with meta-data specifying application interaction rules (so-called "feature interaction" rules). This solution therefore requires rules specifying interactions between applications and services to be pre-stored and accessible in response to application registration requests. When a network event is subsequently received from the network, the Call Control SCF accesses whichever user profile corresponds to the subscriber associated with the network event and retrieves details of applications and services stored therein, controlling their respective invocation sequentially.

There are several problems with this solution, not least resulting from the fact that registration requests are resolved in view of that/those application(s) that have already registered. The short comings of this solution can be seen from consideration of the following scenario, in which a first application A has registered for the user, the user profile having been updated to include data indicative of application A. If a registration request is subsequently received from application B. and if the interaction rules indicate that A is incompatible with B the registration request from application B will fail. If, subsequently, application A de-registers for the subscriber, there is no means of recapturing application B. even though there is now no reason why the subscriber cannot receive service from application B. It is an object of the invention to provide an improved level of integration and flexibility for network services.

Summary of the Invention

According to a first aspect of the present invention there is provided apparatus for processing service registration request messages in a call processing system, each said service registration request message including registration data identifying a service node, a service initiation trigger and a subscriber in respect of whom the registration request relates, the apparatus being connectable to a serving node in a network involved in call processing and to a service node from which a subscriber is able to receive service during call processing, the serving node being capable of transmitting a plurality of service initiation request messages to said apparatus, each service initiation request message corresponding respectively to a different service initiation trigger, wherein the apparatus is responsive to receipt of one of said service registration request messages sent from a registering service node to store registration data indicative of the registered service node and corresponding service initiation trigger in association with the subscriber, said registration data being for use in processing service initiation request messages sent from said serving node in respect of the subscriber, the apparatus being arranged to store registration data for a plurality of service registration request messages each identifying a different service node and the same subscriber, wherein the apparatus is arranged to define an order of precedence between said different service nodes after said registration data have been received.

Thus with embodiments of the invention, interactions between service nodes, referred to herein alternatively as application nodes or application service nodes, are resolved after registration has been completed by means of data defining an order of preference between the nodes. As a result and in comparison with known systems, registration requests are not refused on the grounds of overlapping criteria (illegal or unsupported requests can still be rejected) but are instead noted and applications are subsequently invoked in accordance with the preference data. A significant advantage of embodiments of the invention is that, because registration requests are not refused, all of those applications for which a subscriber has subscribed for service can, at the time of receipt of a corresponding service initiation request message, be activated. It will be appreciated that the preference data take account of any potential conflicts between services.

In one arrangement the apparatus is arranged to store said registration data if the registration request message is received from a service node identified as accessible to the subscriber, thereby providing a means of verifying, or otherwise, that the subscriber indeed has access to the requesting service node.

In addition, in response to receipt of a second and subsequent registration request messages the apparatus can be arranged to retrieve interaction data specifying subsequent real-time interactions between corresponding two or more service nodes and to store said interaction data. The interaction data define said order of precedence between said different service nodes. Subsequently, and in response to receiving a first service initiation request message, the apparatus can transmit second service initiation request messages to two or more of said service nodes in a selected sequence in dependence on the preference data, and including events that are dependent on responses from one or more said service nodes. Conveniently the apparatus can be arranged to process a service node response message from a first service node before transmitting a second service initiation request message to a second service node during the same call.

Alternatively, the apparatus can be arranged to retrieve interaction data specifying interactions between corresponding two or more service nodes in response to receipt of service initiation request message before proceeding in the manner described above.

When the service nodes are embodied as application services, the apparatus effectively acts as a broker therebetween, controlling the respective operations in accordance with data defining the order of preference, which might conveniently be embodied as event processing logic associated with network events. Thus embodiments of the invention provide a means of allowing potentially conflicting applications to co- exist by managing interactions between applications and services when requests for service are received, i.e. in real-time.

Examples of service initiation triggers include, and are not limited to, events and triggers associated with call control, interaction and messaging carried by such protocols as Camel and Intelligent Network detection points (INAP, extended INAP, CAP); MAP events such as Location Update and ForwardSM messages; events associated with sending of data messages such as MMS and SMS messages; and SIP events such as those carried by MSCML, VXML, CCXML, and NETANN.

Preferably the preference data are stored in a data storage system that is accessible by the apparatus and is arranged to store data in respect of a plurality of subscribers. In one arrangement the stored data includes service data specifying services provided by a plurality of said service nodes, and one or more conditions specifying a relationship between said services. This relationship between the services effectively defines event processing logic and is indexed in accordance with the service initiation triggers.

Conveniently the apparatus is in operative association with a function arranged, on receiving a first service initiation request message sent by a serving node in a network currently involved in processing of a call, to control operation of at least one of said registered service nodes. As a result of the operation, the function is arranged to generate a first service response message and to transmit same to the serving node from which the first service initiation request message is received, and on receiving a second service initiation request message sent by a serving node in the network currently involved in processing of the same call, the function is arranged to control operation of at least one of said plurality of service nodes, and as a result of the operation to generate a second service response message and to transmit same to the serving node from which the second service initiation request message is received.

In some cases a service node might, in a service response message, request initiation request messages such as trigger points which would otherwise conflict with similar requests from other service nodes involved in the call.

Such potential conflicts can be avoided by recourse to preference data specifying an order of precedence between, and conditions dependent upon, data received from said different service nodes. The apparatus thereby ensures that all subsequently transmitted initiation request messages (or service invocation messages) associated with the call are conflict-free.

It is to be noted that in general each service node is configured to provide a specific network service, and in the following description, this is referred to as network service and/or service application.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings

Figure I is a schematic diagram showing the OSA API interface and the protocol on which the API class methods are mapped; Figure 2 is a schematic diagram showing an example of messaging flows between the OSA domain and the network domain; Figure 3 is a schematic block diagram showing registration components of an OSA gateway according to an embodiment of the invention; Figure 4 is a schematic diagram showing an example of a registration process according to a first registration embodiment; Figure 5 is a schematic diagram showing contents of the Service Provisioning System of Figure 3 according to the first registration embodiment shown in Figure 4; Figure 6 is a schematic diagram showing an example of a registration process according to a second registration embodiment; Figure 7 is a schematic diagram showing contents of the Service Provisioning System of Figure 3 according to the second registration embodiment shown in Figure 6; Figure 8 is a schematic block diagram showing components of an Event Processing System according to an embodiment of the invention; Figure 9 is a schematic block diagram showing components of an Event Processing System according to a second embodiment of the invention; Figure 10 is a schematic block diagram showing, in more detail, the service interaction component shown in Figures 8 and 9; Figure 11 is a schematic diagram describing steps carried out by the service interaction component shown in Figure 10 during an inter-OSA call handling process; and Figure 12 is a schematic diagram describing steps carried out by the service interaction component shown in Figure 10 during an OSA-IN call handling process.

It is to be noted that parts and steps that are presented for the first time in relation to a given Figure and that are identical or equivalent to parts and steps occurring in subsequent Figures will be described with the same reference numeral in such subsequent Figures, and will not be described in any further detail in the subsequent Figures.

Detailed Description of the Invention

Embodiments of the invention are concerned with aspects of service networks, in particular with efficiently brokering the various and potentially conflicting services available to a subscriber via the Open Service Architecture (OSA), and those available to a subscriber via a combination of the OSA and Intelligent Networks IN. In particular, embodiments of the invention provide an event processing system and apparatus arranged to deliver this functionality. In order to appreciate the level at which embodiments of the invention operate, an overview of the OSA interface to network capabilities will firstly be presented with reference to Figure 1.

Access to network functionality, including functionality of the Intelligent Network, is offered and controlled by different Service Capability Servers (SCSs), which appear as service capability features in the OSA interface. This OSA interface is commonly referred to as Parlay/OSA GW 101. OSA applications such as Appl communicate with the OSA GW 101 via OSA interfaces, while the underlying core network functions (Intelligent Network capabilities, MSC (Mobile Switching Centre) and HER (Home Location Register)) use their specific protocols such as CAP (CAMEL Application Protocol) and MAP (Mobility Application Part) to communicate with the OSA GW 101. As described above, there are 14 SCFs, including various generic call control (GCC) and multi party call control (MPCC) SCFs, which collectively map to all of the CAP, MAP and INAP messages, and can therefore invoke all of the network capabilities.

As described above in the Background section, the starting point for capturing network events of interest to OSA applications is within the Event Processing SCS, which, in conventional arrangements, checks the parameters specified in an enableCallNotification() message (or createNotification() message for MPCC calls) in order to identify whether or not an application has already registered for those parameters. On the basis of this check, the SCS allows or rejects registration of the application for those parameters.

By contrast, the starting point for embodiments of the invention is unconditional registration of a requesting application, which means that, contrary to known methods, the parameters included in a registration request are not checked against previously registered applications. Of course the potential conflicts that were previously managed in a somewhat heavy-handed manner at registration still need to be handled and embodiments of the invention provide an alternative and more flexible means of conflict management, at a different place in a event processing cycle. This will be described in more detail below, but first aspects of the registration process according to embodiments of the invention will be described with reference to Figures 3 - 8.

Turning firstly to Figure 3, it can be seen that the Parlay GW lot includes a registration function 305 configured to communicate both with the Call Control SCS 103 and with a store SPS 303. The SPS store 303 holds so called provisioned data 311, which comprise subscriber-specific triggering and service related information, and dynamic data 313, which indicate the real-time status of any given application listed in the provisioned data 311. Examples of such real-time status information include data identifying whether or not an application is active, together with details of subscribers and network events currently registered in respect of the application; in the following description these real-time data are alternatively referred to as "application handles". The applications are preferably keyed in accordance with subscriber identities and service triggers, so that, for any given subscriber identity and trigger, the applications available to the subscriber can be selected when a call involving a certain trigger is due to be processed. By way of example only, the SPS 303 can be configured to support the following non-limiting list of service triggers: INAP DPI - DP18; CAP Vl O-CSI, T-CSI; MAP non-DP events, e.g. IocationUpdate, forwardSM; CAP V2 V3 V4 triggers; MMS, SMS, SS, USSD, SIP. The following sets out a possible data structure for data stored in the SPS 303 in respect of a given subscriber: Subscriber - Subscriberld (e.g. MSISDN, IMSI, corporateld etc) Attributes: - Eventld ServiceSet: reference to a particular set of applications and application rules specified in

another SPS table.

ServiceSet - list of applications and the interaction rules for those applications.

ED serviceSet 1 comprises applications X and Y. together with the rules required for them to interwork.

serviceSet 2 comprises applications Y and Z. together with the rules required for them to interwork.

Thus subscriber A might have a subscription described by serviceSet 1 and subscriber B serviceSet 2.

The SPS 303 can additionally store inter-application and inter-service rules, which specify interactions between service nodes when an event is received from the network (e.g. in terms of access priority); these aspects of the SPS are described in more detail below. The SPS 303 can be provisioned with data from provisioning services, such as web services located in a wider network, and the provisioning process is preferably independent of the registration process.

Figure 4 shows the steps involved in a registration process according to a first embodiment: at step 401 Appl sends a GCC enableCallNotification() request to the SCS 103, which causes the registration function 305 to assign an assignmentld in respect of Appl. At step 403 the assignmentId is sent to the SPS 303, together with the trigger, source and destination address data specified in the enableCallNotification() request, and an acknowledgement message is subsequently transmitted back to Appl at step 405. Upon receipt of a message from the registration function 305 at step 403, the SPS updates the dynamic store 313, either to include Appl (and details of the trigger, source and destination address received at step 401) or, if Appl is already stored therein in relation to other trigger/subscriber parameters, to update the parameters so as to include those corresponding to the data received at step 401. Figure 5 is a schematic diagram showing how data are distributed amongst components of the SPS 303: the circle corresponding to the dynamic data 313 represents applications in respect of which data have been received from the registration function 305 in the manner described above (as shown in Figure 4), whereas the circle corresponding to the provisioned data 311 represents applications in respect of which the subscriber has subscribed, but which have not yet registered with the gateway 101. It will be appreciated that in this, and subsequent embodiments, that the registration request can relate equally to a plurality of subscribers (eg bulk registration) as to a single subscriber.

Figure 6 shows the steps involved in a registration process according to a second embodiment: at step 401 Appl sends an enableCallNotification() request to the SCS 103, which causes the registration function 305 to send a request to the SPS 303 in respect of Appl, querying the SPS 303 for the subscriber/trigger/Appl combination embodied in the request received at step 401. This causes the SPS 303 to consult the store of provisioned data 311 and at step 605 the SPS 303 returns a result of the query to the registration function 305. Assuming the result to be positive, the registration function 305 allocates an assignmentId to Appl and at step 607 sends the allocated assignmentId to the SPS 303, together with the trigger, source and destination address data specified in the enableCallNotification() request. An acknowledgement message is subsequently transmitted back to Appl at step 609. Upon receipt of a message from the registration function 305 at step 607, the SPS updates the dynamic store 313, either to include Appl (and details of the trigger, source and destination address received at step 401) or, if Appl is already stored therein with other trigger/subscriber parameters, to update the parameters so as to include those corresponding to the data received at step 401. Figure 7 is a schematic diagram showing how data are distributed amongst components of the SPS 303: the circle corresponding to the dynamic data 313 represents applications in respect of which data have been received from the registration function 305 in the manner described above (as shown in Figure 6), whereas the circle corresponding to the provisioned data 311 represents applications in respect of which the subscriber has subscribed, but which have not yet registered with the gateway 301.

From a comparison of Figure 5 and 7 it can be seen that the difference between the two registration processes is that, in the first embodiment, the dynamic data store 313 can hold application data which is actually invalid for this particular subscriber/trigger event, whereas in the first embodiment the dynamic store 313 will only ever hold a subset of applications for which the subscriber has bona fide access. Whilst in the first embodiment this means that the dynamic data store 313 can hold invalid data, it is a somewhat quicker procedure (involving 2 fewer steps than are required in the second embodiment); however, the second embodiment is safer than the first embodiment.

A further embodiment is also possible (not shown), in which the SPS holds data specifying all possible combinations of applications, together with interaction conditions associated therewith. These data are populated offline, so that, during the registration process, the SPS serves as a kind of look-up function for pertinent inter-application rules. When the registration function 305 receives (via the SCS 103) an application registration request (step 401), the registration function 305 assigns an assignmentId to the application Appl and sends the assigned identifier to the SPS 303 (step 403). In response to receipt of the identifier, the SPS 303 retrieves interaction rules on the basis of this, and any other applications that have registered for this subscriber, and associates the retrieved interaction rules with the trigger, source and destination address received at step 401. In addition the SPS updates the dynamic store 313, either to include Appl (and details of the trigger, source and destination address received at step 401) or, if Appl is already stored therein in association with other trigger/subscriber parameters, to update the parameters so as to include those corresponding to the data received at step 401. Operation of the SPS according to this embodiment can be explained with reference to an example: The SPS 303 is arranged to store the interaction rules as indicated below: Application(s) Rule(s) Single App (e.g. X) None X&Y Beta X & Z Delta Z&Y Gamma X&Y&Z Alpha Assuming a subscriber record for whom an application request has been received from Application X only, then in response to a subsequent registration request from Application Y. the SPS 303 retrieves interaction rule for a combination of applications X & Y (here beta), and marks the retrieved interaction rule against the subscriber and trigger, in addition to updating the dynamic data store 313 to reflect registration of application Y for this subscriber and trigger data received at step 401. If, subsequently, application Z registers for this subscriber, the SPS 303 locates an interaction rule for a combination of applications X, Y and Z(alpha) and updates both the SPS 303 and dynamic data store 313 accordingly. If application X then deregisters (either per se or in relation to this subscriber) the SPS 303 retrieves interaction rule gamma and updates the stores information accordingly. These interaction rules specify valid interactions between two or more applications when an event relating to an associated trigger is received from the network and, among other things, thereby provides increased flexibility in terms of service interaction.

It is to be noted that this arrangement is considerably different to that presented by BT (described as "Feature interaction/Service Selection"). In the BT method and system, interaction rules are consulted at the time of application registration in order to determine whether or not applications can co-exist in relation to the same trigger. If the interaction rules permit a requesting application to co-exist with an application that has already registered in respect of the associated subscriber/trigger, details of this requesting application are recorded in a user profile. When a corresponding network trigger is subsequently received the applications are invoked sequentially, in an order determined by the order in which the applications are listed in the user profile (which is determined by the order in which the applications registered with the gateway). By contrast, with embodiments of the present invention, it is the potential interaction(s) between applications that is/are selected during the registration process, the actual and permissible inter-application relationships having been resolved off-line. As a result, the order in which applications are invoked is not constrained by, or indeed even connected to, the order in which applications register with the gateway. Instead, invocation of applications is specified in the preconfigured rules, which can be optimised as a function of the applications themselves. This is a clear advantage over the BT design.

Thus in addition to storing data indicative of available applications, together with associated real-time status information assigned during the registration phase, the SPS 303 is arranged to store data indicative of the relationships between services and applications, in terms of how an incoming network event should be processed; these data are stored in the form of"call model logic" associated with network events (or triggers). From the foregoing it will be appreciated that such interaction rules, or call model logic, are selected at the time of application registration in the case of the third registration method.

When registration of applications is effected in accordance with the first and second methods the associated interaction rules are selected from the repository of interaction rules when an event is received from the network, as will be described in more detail below.

It will be appreciated from the foregoing that, unlike known systems, the issue of conflicts between applications is completely ignored in the registration phase. Instead, inter-application management is controlled by means of a so called Service Interaction Component (SIF) arranged to cooperate with, or be a part of, the Gateway 101 when a request for service is received from the network. Referring firstly to Figure 8, in a first arrangement the SIF 801 is located within the gateway 101, and assumes the responsibility of communicating with the various network application server nodes Appl Appn. The nature and order of invocation of applications is controlled in accordance with data received from the SPS 303, as is described in more detail below. An alternative arrangement is shown in Figure 9, in which the SIF 801 is located outside of the Gateway 101, and thus communicates directly with the OSA applications Appl, App2 and the SPS 303, whilst communicating with the gateway 101 via an interface. In both Figures the dotted lines indicate communications with gateway interfaces in order to communicate with external devices such as, in the case of Figure 8, the SPS 303 and applications Appl, App2 and, in the case of Figure 9, the SCS 101).

The components of the SIF 801 and functionality provided thereby will now be described with reference to Figure 10, which is a block diagram showing a breakdown of the SIF 801 in its component parts. Preferably these components are implemented as one or a plurality of software components, and distributed on one or a suite of computer devices, which comprise standard CPU, memory, data bus, Input/Output ports, data storage, and operating system programs (not shown).

Generally speaking, the SIF 801 is arranged to provide an inter OSA to OSA application and and/or IN to OSA mediation such that multiple service applications can share trigger points such as the Intelligent Network Application Protocol (INAP) and Camel Application Protocol (CAP) detection point events listed above. Generally speaking the SIF 801 is configured to receive, from any SCF such as one including SCS 103 shown in Figure 1, a service request message including some sort of trigger; then perform a query upon the SPS database 303 in dependence on the received trigger; receive data from the SPS 303 in response to the query; invoke and co-ordinate whichever services and applications are identified by the data returned by the SPS 303 according to the call model logic associated therewith (returned by the SPS 303); and collate an overall response to send back to the SCS 103 to enable the SCS 103 to instruct devices in the network to continue with the call (e.g. switching devices).

More specifically, in the present embodiment the SIF 801 comprises a services interface 01 for communicating with the applications Appl Appn and SCSs such as SCS 103; an SPS interface 03 for communicating with the SPS 303, a logic engine 05 and an event processing engine 13. The services interface 01 is arranged to support at least SIP and APIs such as CORBA and SOAP, and preferably to support CAP, INAP, MAP, thereby enabling the SIF 801 to communicate with a range of disparate network devices (i.e. to communicate directly with network devices such as switches in the PLMN rather than via the SCS 103).

The logic engine 05 is the part of the SIF 801 arranged to request service data from the SPS 303, together with data identifying rules and details of service applications (in the form of fixed rules 07, dynamic rules 09 and/or scripted rules 11 (at least some of which are received from the SPS 303 in real-time)), in dependence on the trigger and subscriber data. Having received these data, the logic engine 05 is arranged to generate one or more event processing events, which involve invoking a service via the services interface 01 and causing the event processing engine 13 to monitor for, and act upon, output from such invoked services. In particular, the event processing engine 13 is arranged to perform transaction management, correlation management (e.g. correlate DP received from different switches), timeout control (in relation to responses received from applications and services and the SPS 303); instance management (in relation to sequencing of services, and support for multiple simultaneous independent operations); and general administrative tasks such as statistics and alarm management. The event processing engine 13 can therefore effect one or more network services and OSA applications in response to an OSA callEventNotify() message and/or an IN InitialDP, collate overall responses from some or all of the actioned services and send data to the SCS 103 so as to connect a subscriber to the requisite network service(s).

The features and functionality of the event processing engine 13 will now be described in more detail. The call model logic returned from the SPS 303 (typically in the form of rules 09, 11) is effectively used to control the sequence in which applications are invoked with initial and subsequent messages, thereby resolving the problem of distributing single triggers resulting from a trigger point. Where the output of one service application influences operation of another service application, invocation is preferably synchronous, but if the output from various service applications is simply combined by the event processing engine 13, the service applications are preferably invoked asynchronously so as to improve latency. It can therefore be seen that inter application processing is managed at the time of processing a call by means of the rules retrieved from the SPS 303. In addition to the SPS 303 returning sequencing rules in respect of OSA triggers such as callEventNotify () and IN triggers such as InitialDP triggers, there are rules for processing event notifications (ERB (IN), RouteRes() (OSA)) applyCharging (AC/ACR (IN), i superviseCallReq()/superviseCallRes() (OSA)) messages, temporary call and resource access (ETC/CTR) and any resultant responses therefrom.

The event processing engine 13 is additionally arranged to control operation of multiple service applications that generate conflicting events and actions. Taking a simple example, if multiple service applications return a CONNECT (IN) or routeRequest() (OSA) message, the event processing engine 13 applies various rules in order to identify which of the messages 'wins'; and in another simple example, if a CONNECT/routeRequest() message and a RELEASE (IN) or release() (OSA) message is returned by different service applications, the event processing engine 13 applies various rules to identify which of the two conflicting actions is taken. Essentially, therefore, the outputs are processed in accordance with an appropriate rule retrieved from the SPS 303 associated with the conflicting event and/or action.

The event processing engine 13 is arranged to handle communication failures, in accordance with the dynamic (i.e. configurable) rules 09 retrieved from the SPS 303, dependent on the type of failure. For example, if a first service application aborts, one option is that the whole transaction aborts, whilst another might be that if the first service application succeeds but the second fails, the response from the first should take precedence.

The event processing engine 13 is also configured to monitor for responses within a predetermined time period, wherein, in the event that a service application response or response from the SCS 103 fails to arrive, the SIF 801 performs one of a plurality of actions. For example, in the case of a service application failing to respond within the specified time period, the SIF could trigger the SCS 103 to send a TCAP failure response into the network depending on the associated error rules. The error and timeout rules could be static rules 07 stored and maintained by the SIF 801.

In summary, the logic engine 05 and event processing engine 13 controls the following actions in accordance with conditions specified in the fixed, dynamic and static rules 07, 09, 11: i. The order in which service applications are invoked; ii. How responses from service applications are combined; iii. How subsequent transactions based on responses from the service applications shall be performed; iv. Whether the call control is managed by the SIF, or delegated to a service application; and v. Whether applications should be excluded from invocation as a function of the type of network (e.g. home or roaming).

A non-limiting list of examples of the fixed rules 07 will now be described: Requests are cumulative: if service application A requests Request Report BCSM (RRB) DPx and application B requests RRB DPy then the result shall request RRB DPx and DPy. (A Request Report BCSM is referred to herein as RRB and is a request to create trigger points for later in the communications flow - e.g. Busy, Disconnect, Answer, No answer; in the Parlay domain, the equivalent of a RRB is a routeRequest() message with associated reponseRequested parameters specifying a particular monitor mode and report type). If these points are triggered, an event report BCSM (ERB) (or, in the Parlay domain, a RouteRes() message) is automatically generated); If there are multiple RRB requests (or routeRequest() messages) for the same trigger then only a single invocation shall be requested; If there are multiple RRB requests (or routeRequest() messages) for the same trigger then the monitor mode shall be the highest requested; CONTINUE (or routeRequest() with no destination address) shall only be returned if all service applications indicate continue; If there is only one service application listed for a subscriber / DP then the SIF shall drop out of the call, i.e. forward the InitialDP or callEventNotify() (as appropriate) message to the service application, with the response routed directly back to the initiating switching node; 30. If there are no service applications defined then the SIF shall return a CONTINUE (or routeRequest() with no destination address) response; The SIF shall drop out of the flow at the earliest possible opportunity; e.g. if only CONTINUE (or routeRequest() with no destination address), CONNECT (or routeRequest() with destination address) or RELEASE (or releaser) message in the Parlay domain) is returned to the MSC, or if all expected MSC responses are destined for a single application; A non- limiting list of examples of the dynamic rules 09 will now be described: The order of Initial DP, or callEventNotify(), relay to service applications shall be in the configured precedence order; If service applications can be invoked asynchronously then they should be, since this will improve latency; If the response is RELEASE (or a release() message in the Parlay domain) , then the overall response shall be governed by the release precedence of the service application. If there is a service application with a higher release priority that has not returned a RELEASE (or release() message, as appropriate) (i.e. if it has returned a CONTINUE or CONNECT (or routeRequest() with or without destination address)) then the RELEASE (or release() message) from the lower priority service application shall be ignored. If the RELEASE (or releaser) message in the Parlay domain) is from the application with the highest release priority, then the remaining service applications need not be actioned; and a RELEASE/release() message and TCAP END (or callEnded() in the Parlay domain) shall be returned; If a CONNECT/routeRequest() message is returned, then the called / calling party returned to the switching node shall be that from the service application with the highest connect precedence; . . . A non- limiting list of examples of the scripted rules 11 will now be described: Charging Reports (ACR (or superviseCallRes() messages in the Parlay domain)) shall be distributed only to those applications that contributed to the AC (or superviseCallReq() message in the Parlay domain) previously generated. There may be complex calculations required to massage the ACR/superviseCallRes() message in to an appropriate form for each service application; Following an ERB Busy Report, (or RouteRes() message with parameters indicating that a party is busy), a CONNECT/routeRequest() message relating to a different number shall be returned (this may invalidate all previous interactions with other applications, so a script might be used to abort some applications or modify behavior explicitly, potentially using messages generated specifically for this purpose); Where action is dependent on content within a message, a script can be used to identify the content within the message and invoke an appropriate action.

In addition to the fixed, dynamic and static rules 07, 09, 11 described above, the SIF 801 operates in accordance with several general rules, which include the following: The SIF shall end the TCAP dialogs with TC_END (or callEnded() in the Parlay domain) when the response to the MSC is a simple CONNECT, CONTINUE (routeRequest() message with or without destination address) or RELEASE/release() message (basic end).

The SIF shall end the transaction without a TC_END (or callEnded() message) if it determines that there are no more messages expected (e.g. ACR/superviseCallRes() received indicating end of call, and no later trigger points armed) - this is known as a pre arranged end, and no further messages are sent.

The SIF shall end all open dialogs if it receives a TC_ABORT (or callFaultDetected() message) - by relaying the abortive message. i

The SIF shall end all open dialogs if it receives a TC_END (or callEnded() message) from the MSC - by relaying the TC_END.

The SIF shall end the dialog with a TC_END (or callEnded() message) if unexpected errors occur.

It will be appreciated that in this, and other embodiments, that the protocol andlor APIs used in the rules are those appropriate to the services involved, and are not restricted to INAP, CAP, GCC, MPCC.

The functionality of an Event Processing System EPS involving OSA applications will now be described with reference to Figure 11 which shows a generic scenario involving processing of incoming triggers from the network.

Referring to Figure 11, at step 1 l 01 an IN event is received by the SCS 103 and passed to the SIF 801, the IN event including data identifying the Calling Party (subscriber) and specifying the type of service trigger (e.g. CAP IDP DP2) , together with details of the Called Party (CdPN). Having identified this to be the first such message from the network in relation to the current event processing scenario, the SIF 801 formulates a query (step 1103), using e.g. the Directory Access Protocol (DAP), so as to retrieve data from the SPS 303 corresponding thereto. Upon receipt of the query request, the SPS 303 retrieves data corresponding to the subscriber and trigger from the dynamic data store 313. Referring back to Figure 5, if registration occurred in accordance with the first embodiment, this will involve filtering the dynamic data 313 using the provisioned data 311, and for the example shown in Figure 5, will result in an output of Appl and App2. If registration occurred in accordance with the second embodiment on the other hand, then because subscriber access to a requesting application was checked during the registration process, the SPS 303 simply has to retrieve the contents of the dynamic store 313 (Appl and App2).

If registration occurred in accordance with the third embodiment the SPS 303 will retrieve the contents of the dynamic store 313 (Appl and App2) together with preselected interaction rules governing the interaction between Appl and App2.

For cases in which registration has previously occurred in accordance with either the first or the second registration methods, and unlike the third registration method, once the relevant applications (Appl, App2) have been identified, the SPS 303 has to perform a separate step of selecting rules and service information specifying the conditions in which the applications can be accessed; irrespective of registration method the now selected interaction rules are then transmitted to the SIF 801 at step 1105. Next, the event processing engine 13 is configured in accordance with these conditions, which for the purposes of the present example cause App2 to be invoked before Appl.

Accordingly at step 1107 App2 is invoked by means of e.g. callEventNotify() message, and at step 1109 a response is received and processed by the SIF 801, more specifically the event processing engine 13 (having previously been configured to monitor for such an input when the notify message was transmitted at step 1107). Next, the event processing engine 13 runs the rules retrieved from the SPS 303 at step 1105 with the data received at step 1109 as input. In accordance with the processed rule(s), the event processing engine 13 determines that the next action to be performed is sending of data received at step 1109 to Appl, so the event processing engine 13 sends a callEventNotify() message to Appl (step 1111), and then prepares the event processing engine 13 to monitor for the next connected event. Having received a response from App 1 (step 1113) the event processing engine 13 runs the rules retrieved from the SPS 303 at step 1105 with the data received at step 1113 as input. In accordance with the processed rule(s), the event processing engine 13 determines that the next action to be performed is connection of the calling Party (subscriber) with the Called Party (Mailbox VPS), and accordingly the SIF 801 causes the SCS 103 to send a CONNECT message to the network (step 1115), directing the network to connect the subscriber to his Voice Mailbox VPS, enabling him to access his recorded messages. Step 1117 indicates transmission of further network events in respect of which one or more OSA application has registered an interest.

Figure 12 shows an example of an Event Processing System EPS involving OSA and IN applications, and shows that embodiments of the invention can also be used to control operation of OSA applications and IN services as part of an overall event processing service relating to a network trigger. In this scenario, steps 1101, 1103, 1105 progress as described in relation to Figure 11, but since, in this example, it is assumed that the trigger in question causes the SPS to solicit data relating both to IN services and OSA applications, the data returned by the SPS 303 will include invocation rules that cause the SCS 103 to interleave transmission of messages to the IN domain with transmission of messages into the OSA domain; a list of the associated steps is set out in the Figure.

Additional Embodiment Details Whilst the SIF 801 is described as a single entity, it will be appreciated that such an entity can be distributed over a plurality of processing components.

It could, for example, be a part of the registration function 305 andlor an SCS.

The above embodiments are to be understood as illustrative examples of the invention, and further embodiments of the invention are envisaged. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims (9)

1. Claims 1. Apparatus for processing service registration request messages

   in a call processing system, each said service registration request message including registration data identifying a service node, a service initiation trigger and a subscriber in respect of whom the registration request relates, the apparatus being connectable to a serving node in a network involved in call processing and to a service node from which a subscriber is able to receive service during call processing, the serving node being capable of transmitting a plurality of service initiation request messages to said apparatus, each service initiation request message corresponding respectively to a different service initiation trigger, wherein the apparatus is responsive to receipt of one of said service registration request messages sent from a registering service node to store registration data indicative of the registered service node and corresponding service initiation trigger in association with the subscriber, said registration data being for use in processing service initiation request messages sent from said serving node in respect of the subscriber, the apparatus being arranged to store registration data for a plurality of service registration request messages each identifying a different service node and the same subscriber, wherein the apparatus is arranged to define an order of precedence between said different service nodes after said registration data have been received.
2. 2. Apparatus according to claim 1, wherein the apparatus is arranged to store said registration data if the registration request message is received from a service node identified as accessible to the subscriber.
3. 3. Apparatus according to claim 1 or claim 2, wherein in response to receipt of a second and subsequent registration request message the apparatus is arranged to retrieve interaction data specifying interactions between corresponding two or more service nodes and to store said interaction data, thereby defining an order of precedence between said different service nodes.
4. 4. Apparatus according to claim 1 or claim 2, wherein in response to receipt of service initiation request message the apparatus is arranged to retrieve interaction data specifying interactions between corresponding two or more service nodes, thereby defining an order of precedence between said different service nodes.
5. S. Apparatus according to any one of the preceding claims, wherein the apparatus is arranged to store further registration data in respect of a further service registration request message identifying a further different service node and the same subscriber, said further service registration request message being received subsequently, the apparatus being arranged to define an order of precedence between said different service nodes after said further registration data have been stored.
6. 6. Apparatus according to any one of the preceding claims, wherein said plurality of service registration request messages are received at different times.
7. 7. Apparatus according to any one of the preceding claims, the apparatus being in operative association with a function arranged, on receiving a first service initiation request message sent by a serving node in a network currently involved in processing of a call, to control operation of at least one of said registered service nodes, wherein, as a result of the operation, the function is arranged to generate a first service response message and to transmit same to the serving node from which the first service initiation request message is received, and on receiving a second service initiation request message sent by a serving node in the network currently involved in processing of the same call, the function is arranged to control operation of at least one of said plurality of service nodes, and as a result of the operation to generate a second service response message and to transmit same to the serving node from which the second service initiation request message is received.
8. 8. Apparatus according to claim 7, wherein the service initiation request message includes data identifying the corresponding service initiation trigger, and the function is arranged to access data indicative of said order of preference between said different service nodes, for use in controlling operation thereof.
9. 9. Apparatus according to any one of the preceding claims, wherein said registration data identifies a plurality of subscribers in respect of whom the registration request relates.