ES2639563T3 - Event Processing System - Google Patents

Abstract

Event processing apparatus (301) in a communications network for use when processing service initiation request messages in an event processing system, the apparatus (301) being connectable to a plurality of service nodes from which a The subscriber can receive service during the processing of a network event, each said service node being able to transmit a service response message comprising particular data for operation of the service node, the apparatus comprising an arranged function, upon receiving a first message from service initiation request sent by a server node in a network currently involved in the processing of said network event, to request service response messages from a plurality of service nodes, and to control the operation of at least some of said plurality of service nodes involved in processing the same network event based on data conte nests in said service response messages, in which, in the event that the data contained in a service response message received from one of the plurality of service nodes is indicative of a request for an overlapping signaling resource or conflicts with data contained in a service response message received from another of the plurality of service nodes, the function is arranged to process the data contained in respective service response messages based on attribute data to enable access to the signaling resource requested by each respective service node involved in the processing of the same network event, in which the attribute data specify rules for interaction between the plurality of service nodes based on the received service response messages.

Description

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

DESCRIPTION

Event Processing System Field of the Invention

The present invention relates to a method and system for the processing of events in a communications network, and is particularly, but not exclusively, suitable for coordinating the provision of services in response to service initiation triggers. The embodiments of the invention are particularly applicable for use in controlling the operation of service nodes, each of which is arranged to provide a particular service in a mobile network, or a fixed network, or a combination of the two.

Background of the invention

A typical mobile operator comprises two or more operation partners, each offering customized network services. As a result, the operating partners, seen as a whole, often comprise different and diverse services and corresponding service equipment. The responsibility for the development, integration and operation of network services lies with each individual operating partner, and providing this diversity is typically extremely expensive for the operator when viewed as a whole, since the costs associated with developing, Support and market the various services can be significant. Furthermore, when faced with the task of integrating various network services, the network operator has several difficult problems to overcome, not only due to the fact that legacy service applications are typically not compatible forward, and, as already You mentioned, many of the network services are developed and managed by different service providers.

Figure 1 is a schematic diagram showing a conventional mobile network arrangement comprising a mobile station MS, server node switching network component MSC, and home location register HLR, together with various nodes IN1, IN2, IN3, each One willing to provide an intelligent network service. The mSc is arranged to send messages to, and receive messages from, the service nodes IN1, IN2, IN3 in accordance with service parameter data received from the home location register HLR after the registration of the mobile station MS with the MSC or according to settings that are statistically configured in the home network. Although the MS is registered with the MSC, the MSC monitors the occurrences of service triggers (called Detection Points (DP)), and, when an activator is identified, the MSC switch contacts any service node that is associated with the activator In some known systems, each service IN1, IN2, IN3 operates independently from each other (for example each service can be provided by a different service provider), and it is often the case that different services are designed to respond to the same trigger. Typically, in such situations the MSC simply activates one of the network services, thus failing to effectively provide the MS with the other services. International Patent Publication Number WO97 / 50232 describes a system that is designed to mitigate this problem, and describes a network that has a so-called mediation point, which has access to services that correspond to the same activator, along with rules that determine interoperability. between them, and controls the invocation of the various services from a single point. However, WO97 / 50232 requires that applications be categorized into simple classifications and only allows a preconfigured and tabulated set of interactions between services, which is prescriptive and inflexible. Additionally, each service can only be invoked according to the rule, that is, only once with respect to a given trigger.

The international patent application that has the publication number WO01 / 31935 describes a system in which the invocation of various service nodes is controlled by means of a service manager to provide a subscriber with access to network resources. These service nodes can be coordinated based on a "subscriber profile", which lists applications accessible to a given subscriber and specifies the order in which the service nodes associated with the applications are to be invoked. Generating or updating a subscriber profile implies a certain amount of pre-processing of the applications (ie analysis between services) to identify combinations of services that do not conflict with each other; The result of the analysis between services is stored as a profile in the HLR or similar.

Each application, or service node, requires the use of certain network resources, which are referred to in WO01 / 31935 as "control types". These are specified when a service node registers its associated application and is used to determine the coexistence of respective applications in relation to a given network event. Importantly, WO01 / 31935 does not allow access to the same type of control by two or more applications during a given network event.

WO01 / 31935 also describes assigning certain types of control in real time, from a grouping of control types and in relation to a specific service requested by a particular subscriber. The grouping comprises control types that have not been "fixedly reserved" by a service in a subscriber profile in the manner described above. This allows service provisioning to be more flexible than it is.

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

otherwise, since service requests are not rejected based on what they may need, but instead based on what they really need for the requested service and the requested subscriber.

Although this provision provides additional flexibility, however, the request of the last requesting service node will be rejected if a service node really needs a type of control that has already been reserved by an application involved in the provisioning of the network event. In summary, the invention described in WO01 / 31935 is basically a device for calculating permitted and non-conflicting service combinations. Therefore, by not preprogramming all types of control in a subscriber profile, WO01 / 31935 provides improved flexibility, but does not solve the problem of how to deal with conflicting requests for the same type of control (this being a separate problem and one that is not addressed in document WO01 / 31935).

In addition to the existence of different service nodes competing for the same activator, the technical convergence between the domains of telecommunications, computer science and multimedia has given rise to a new environment for the development and provision of telecommunications services. This has forced both telecommunications operators and service providers to develop and deploy new residential and business services and applications. To meet this challenge, operators and service providers have sought to replace closed proprietary systems with standardized, open, interoperable and common common platforms, and at least some of the services mentioned above are performed on such open platforms.

Parlay is a consortium of multiple open distributors formed to develop such open APIs independent of technology, which enables internet service distributors, network device distributors, software developers, service providers, ASP and companies, to create applications that can run through multiple mobile networks and fixed operators. The Parlay / OSA (Open Services Architecture) standard defines an API (Application Programming Interface) that is agnostic in terms of technology and is configured to use protocols and technologies such as SIP (Session Initiation Protocol), JAIN ( Java API for smart networks) and web services to communicate with third-party devices and services in different domains.

Although this structure has greatly improved the interoperability of services, there are, however, implementation problems associated with separate services that register interest in network events. The following description assumes that "an application / service that registers interest in ..." means "" an application / service that is willing to react to ... ", and that" a network event "means, for example , a network trigger (or indeed another service or application node) with respect to a specified destination and source address.

There are currently 14 Service Control Functions (SCF), which include various SCF generic call control (GCC) and multi-part call control (MPCC); among them, GCC / MPCC SCFs map all messages in the intelligent network (IN), and can therefore invoke all network capabilities. Using the Parlay APIs, any given service can record and unregister network events (through, for example, GCC SCFs, enableCallNotification () and disableCallNotification () methods respectively and for MPCC SCFs, by means of the createNotification () and destroyNotification () methods respectively) each registration request corresponding to one or more subscribers (source address) and / or destination address or addresses (for example a number specified in the case of translation services of number). A simplified representation of the OSA network and domains is shown in Figure 2, and an example of the routing of GCC log messages between OSA and network devices is shown in Figure 3. In this example an App1 application is arranged to check the balance of subscribers specified before the allocation of network resources, and therefore App1 invokes the enableCallNotification () method each time it determines that the subscriber's balance needs to be checked before allocating network resources with respect to the requested service. This results in a MAP AnyTimeModification () message that is sent to the HLR to activate the necessary subscription information (O-CSI, D-CSI (activated in relation to the subscriber's address)). Having successfully registered this network event, when a specified subscriber subsequently requests a service (ie O-CSI (data identifying the subscriber)), App1 is invoked and used to control at least the initial part of the provisioning procedure of service.

The enableCallNotification () method is purely intended for applications to indicate their interest in being notified when certain events occur. It is possible to subscribe to a certain event for a total range of addresses, for example the application may indicate that you want to be informed when a call is made to any number that starts with 800. If an application has already requested notifications with criteria that overlap the Specified criteria, the request is rejected 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 source and end destination addresses overlap and the same number plan is used and the same CallNotificationType is used (for example network trigger). As a result, in the majority of configurations only one application can make a request for a given set of criteria.

British Telecommunications Exact Technologies has identified that having a strict and rapid rule of “some overlap-no co-existence” is too restrictive and has presented a solution whereby the GW

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Parlay comprises a Policy Management Service Capacity (SCF) Function, arranged to cooperate with the Call Control SCF shown in Figure 2 when an application attempts to register with the gateway. Your Polttica Management SCF manages a user profile store in which the details of services to which a given subscriber has accessed are stored, along with the respective trigger events. The user profiles are filled in only after the Policy Management SCF has verified that the applications can coexist, having verified their coexistence by means of a feature interaction processing function that is provided with metadata that specifies interaction interaction rules. application (called "feature interaction" rules). This solution, therefore, requires rules that specify interactions between applications and services so that they are 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 any user profile corresponding 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 only resulting from the fact that the registration requests are resolved in view of the fact that these applications have already been registered. The disadvantages of this solution can be observed from the consideration of the following scenario, in which a first application A has been registered for the user, the user profile having been updated to include data indicative of the application A. If a registration request it is subsequently received from application B, and if the rules of interaction indicate that A is incompatible with B, the application for registration of application B will fail. If, subsequently, application A cancels the registration for the subscriber, there is no means to re-capture application B, even if there is now no reason why the subscriber cannot receive the service of 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, an event processing apparatus is provided for use in processing service initiation request messages in an event processing system, the apparatus being connectable to a plurality of service nodes from the which a subscriber can receive service during the processing of a network event, each said service node being able to transmit a service response message comprising particular data for operation of the service node, the apparatus comprising an arranged function, upon receiving a first service initiation request message sent by a server node in a network currently involved in processing said network event, to request service response messages from a plurality of service nodes, and to control the operation of at least some of said plurality of service nodes involved in the processing of the same network event based on the data contained in said service response messages,

in which, in the event that the data contained in a service response message received from one of the plurality of service nodes is indicative of a request for a signaling resource that overlaps or conflicts with data contained in a message of service response received from another of the plurality of service nodes, the function is arranged to process the data contained in respective service response messages based on attribute data to enable access to the signaling resource requested by each respective node of service involved in processing the same network event,

in which the attribute data specify rules for interaction between the plurality of service nodes based on the received service response messages.

During the processing of a network event such as a call, this aspect opens up the possibility of coordinated operation of, for example, a first service node, which, during execution, depends on the data content from another (second) node of service as part of the processing of a network event, with said other service node. Any given service node appears effectively as a system open to the device, which means that the device can interact with the service node at one or more points or points during the processing of a network event.

The embodiments of the invention also provide a means of integrating functionality from different services according to selectable predetermined rules and conditions. Preferably, the rules are retrieved in response to the receipt of the service initiation request message and may include, for example, establishing conditional waiting events and rules that specify which service node to invoke and when the waiting conditions have been met. The apparatus thus provides a flexible means of processing a network event, in which the services are "mixed and adapted" dynamically in accordance with the data of selected rules and conditions.

Conventionally, the function can be configured to control the operation of a given service node more than once during the same network event based on the content of said service response message. The function is effectively involved throughout the dialogue between the various service nodes and server nodes; This is completely different from known systems such as those described in WO97 / 50232, in which the triggers subsequently received can only be treated as separate events, causing the mediation point to search for services as if the activator in question received as part of an unrelated network event. This feature is particularly

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

beneficial for use with services that require alerts in response to various events (such as when a called party is busy or unavailable), and that a plurality of occasions can be consulted, responding each time with alternative contact details for a called party.

In one arrangement, the function carries data indicative of one or more service initiation triggers in a service request message to a respective service node, the activators being any of that or those sent from the server node to the device and / or a function modified trigger. The function may also modify data such as service keys, protocols and / or called digits that accompany the service initiation request, based on the data retrieved, and / or based on the content of the service response messages received from the service nodes involved in the network event. Subsequent service request messages can then be formulated based on the modified data. A particular advantage of providing the means for modifying the activators is that the range of functionality operable by the function is improved over what is possible with known systems, since different services and applications respond to different activators. Essentially, by changing the triggers involved in a given network event, the number of services (and therefore the range of functionality) that can be invoked in relation to the network event increases. In addition, the function can be arranged to monitor the reception of additional service initiation request messages - in particular, trigger data - as a result of the operation, and the operation of control of service nodes based on recovered data corresponding to the data. of trigger again received.

In some cases a service node may, in a service response message, request initiation request messages such as trigger points that otherwise conflict with similar requests from other service nodes involved in the network event. Such potential conflicts may avoid recourse to preference data that specify an order of preference between, and conditions dependent on, data received from said different service nodes. The device thus ensures that all initiation request messages subsequently transmitted (or service invocation messages) associated with the network event are without conflicts.

More specifically, in response to receiving said first service initiation request message, the apparatus is arranged to transmit second service initiation request messages to two or more of said service nodes in the selected sequence. This sequence is selected in accordance with the specified call processing logic, and includes events that are dependent on responses from one or more of said service nodes. For example, the apparatus may 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.

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

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, such as Camel and Smart Network detection points (INAP, extended INAP, CAP) ; MAP events such as Location Update and ForwardSM messages; events associated with sending data messages such as MMS and SMS messages; configuration numbers (for example B #) and SIP events such as those carried by MSCML, VXML, CCXML and NETANN.

In one arrangement, one of the service nodes is a gateway node that provides access to a plurality of additional service nodes beyond the gateway; preferably the apparatus comprises an interface component arranged to provide access, by means of the gateway node, to it. The additional service nodes may then be willing to discover the functionality of the device, and use the information discovered to proactively design services in accordance with it.

In summary, the device can be seen as operating in two modes: one first, in which the actionable data corresponding to the service initiation request is retrieved; and a second one, in which the device invokes service nodes based on the recovered data, also including the second mode of monitoring, and the action on the data received from the service nodes operated in the form of service response messages.

In one arrangement, upon receipt of a second service initiation request message sent by a server node in the network currently involved in the processing of the same network event, the function may control the operation of at least one of said plurality of service nodes, and as a result of the operation, transmit a service response message to the server node from which the second message is received from

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

service initiation request. The first and second service initiation request messages may be sent from the same or different server nodes; the apparatus could be used, for example, to transfer the processing of events from a server node in a visiting network to a server node in the home network in any of the following scenarios: during provisioning of the International Voice Service without Interruptions; while translating a short number to a complete connection number; while performing various messaging services and any combination of these and other known and future different services.

According to a second aspect of the present invention, an event processing system is provided for processing service initiation triggers, the event processing system comprising:

a plurality of service nodes from which a subscriber can receive service during the processing of a network event;

a server node arranged to store data defining a set of different service initiation triggers for a subscriber, each of said service initiation activator corresponding respectively to a first different service initiation request message;

a storage system arranged to store data with respect to a plurality of subscribers, including stored data service data that specify services available from a plurality of said service nodes, and one or more conditions that specify a relationship between said services ;

a processing system arranged, in response to receiving said first service initiation request messages sent from said server node with respect to the subscriber, to retrieve service data associated with the subscriber from said storage system, in which the Processing system is arranged to transmit at least a second service initiation request message to each of a predetermined set of different service nodes according to the recovered data.

In this aspect of the invention the storage system can be physically and logically separated from the processing system, which means that updates to the service data and the conditions that specify the relationships between the services can be completely modified independently of both the operation of the processing system such as the transfer of messages between the service nodes, the server node and the processing system.

According to a third aspect of the invention, the apparatus for processing service initiation request messages in an event processing system is provided, the apparatus being connectable to a server node in a network involved in processing a network event and a plurality of service nodes from which a subscriber can receive service during the processing of the network event, the server node may store data defining a set of different service initiation triggers for a subscriber and transmit a set of first messages of service initiation request to a plurality of different service nodes, each of said first service initiation request message corresponding respectively to a different one of said service initiation triggers, wherein the apparatus is sensitive to different said first service initiation request messages during mi processing This is a network event, and is arranged to transmit at least a second service initiation request message to each of a predetermined set of different service nodes in response to receiving one of said service initiation request message.

The device configured in accordance with the third aspect can respond to different triggers received during the same network event and identify the triggers as being part of the same network event. This provides a particularly convenient way of controlling, for example, switching devices associated with a call, and transferring a call between different networks, from which different triggers can be received during the processing of the same call.

Additionally in the provisions of this aspect of the invention, a server node, such as a switch, transmits a first service initiation request message to the apparatus, which can send second service initiation messages to two or more service nodes. These second service initiation messages may be the same as those of the first service initiation request message, and any one of the second service initiation message may be the same as, or different from, another second service initiation message. .

In accordance with a further aspect of the present invention, an apparatus is provided for processing service initiation request messages in a network event processing system, the apparatus being connectable to a plurality of service nodes from which a subscriber can receiving service during the processing of a call, and comprising a function provided, upon receiving a first service initiation request message sent by a server node in a network currently involved in the processing of a call, to control the operation of the minus one of said plurality of service nodes, in which, as a result of the operation, the function is arranged to generate a first service response message and to transmit the

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

same to the server node from which the first service initiation request message is received, and upon receipt of a second service initiation request message sent by a server node in the network currently involved in processing the same service event network, the function is arranged to resume control of at least one of said plurality of service nodes.

This aspect of the invention allows the apparatus to remain involved in the processing of a network event after the event handling has passed between different server nodes in the network. Typically, the device will be configured to monitor the reception of the second service initiation request message and will continue the control of event processing when the second request message is received.

According to a further aspect of the invention, an apparatus is provided for processing service initiation request messages in a network event processing system, the apparatus being connectable to a server node in a network involved in the processing of the event. network and a plurality of service nodes from which a subscriber can receive service during the processing of said network event, the service node being able to store data defining a set of different service initiation triggers for a subscriber and transmitting individual of a set of first service initiation request messages to the apparatus, each said first service initiation request message corresponding respectively to a different one from said service initiation triggers, in which the apparatus is sensitive to one of said first service initiation request messages to transform the ini trigger service association associated with data indicative of a second service initiation trigger, and to request a service response message from at least one of said service node based on the second service initiation trigger.

This aspect is particularly convenient for situations in which the set of triggers available for the server node (switch) does not include triggers that correspond to certain services. In the provisions of this aspect of the invention, the apparatus transforms the activator data it receives, preferably using data included in the service initiation request message, such as the ID of the called party, to advance network events that fail. when handled correctly in another way, an example of this type is the processing of B # calls, for which only the required set of activators is provided to switching devices in CAMEL-enabled networks 3. Another example is the processing of a number of fixed line operator, a range of numbers, a mobile operator number or a range of numbers, each corresponding to a particular service or range of services.

In accordance with a further aspect of the invention, a mobile network is provided comprising a plurality of said event processing apparatus, each comprising one or more gateway service nodes arranged to provide access to additional service nodes. Advantageously, the mobile network is arranged so that any one of the gateways can access any one of the additional service nodes, thus providing a consolidated set of services for the mobile network.

The embodiments of the invention can be applied to directly control said one or more other service nodes in an accessible manner by means of the gateway service node. Therefore, advantageously, the invention can be implemented in what is effectively "the other side of the gateway" and control the operation of, for example, OSA service applications.

It should 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 a network service and / or service application.

According to a further aspect of the present invention, an apparatus is provided for processing service registration request messages in an event processing system, each of said service registration request messages including registration data identifying a node. of service, a service initiation trigger and a subscriber with respect to which the registration request refers, the apparatus being connectable to a server node in a network involved in event processing and to a service node from which a subscriber can receiving service during event processing, the server node being able to transmit a plurality of service initiation request messages to said devices, each service initiation request message corresponding respectively to different service initiation triggers, in which the apparatus is sensitive to the receipt of one of said servi registration request messages cio sent from a registration 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 when processing service initiation request messages sent from said server node with respect to 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, in which the apparatus is arranged to define an order of preference between said different service nodes after said registration data has been received.

Therefore, with the embodiments of this aspect of the invention, the interactions between service nodes are resolved after the registration is completed by means of data defining an order of preference.

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Between the nodes As a result and in comparison with known systems, registration requests are not rejected due to overlapping criteria (illegal or unsupported requests can still be rejected) but instead are indicated and applications are subsequently invoked according to the data preferably.

A significant advantage associated with this aspect of the invention is that, since the registration requests are not rejected, all of these applications for which a subscriber has subscribed for the service can be activated at the time of receiving a corresponding message from service initiation request. It will be appreciated that the preference data takes into account 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, thus providing a means of verification, or otherwise, that the the subscriber has in fact accessed the requesting service node.

In addition, in response to the reception of a second and subsequent registration request messages, the device may be arranged to retrieve interaction data specifying subsequent real-time interactions between the corresponding two or more service nodes and to store said interaction data. . The interaction data defines said order of preference between said different service nodes. Subsequently, and in response to receiving a first service initiation request message, the apparatus may transmit second service initiation request messages to two or more of said service nodes in the selected sequence depending on the preference data, and that include events that are dependent on responses from one or more of said service nodes. Conveniently, the apparatus may 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 network event.

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

Conventionally the apparatus is in operative association with a function configured in accordance with aspects of the invention described above.

The additional features and advantages of the invention will be apparent from the following description of preferred embodiments of the invention, provided by way of example only, which is done with reference to the accompanying drawings.

Brief description of the drawings

Figure 1 is a schematic diagram showing the operation of a conventional mobile network arranged to deliver network services to a subscriber;

Figure 2 is a schematic diagram showing a network that has access to an OSA domain, the OSA API interface and the protocol in which API class methods are mapped to various network protocols;

Figure 3 is a schematic diagram showing an example of messaging flows between the OSA domain and the network domain;

Figure 4 is a schematic block diagram showing components of an event processing system according to an embodiment of the invention;

Figure 5 is a schematic block diagram showing components of an event processing system according to a second arrangement of an embodiment of the invention;

Figure 6 is a schematic block diagram showing components of an event processing system according to a third arrangement of an embodiment of the invention;

Figure 7 is a schematic block diagram showing registration components of an OSA gateway in accordance with an embodiment of the registration aspects of the invention;

Figure 8 is a schematic diagram showing an example of a registration process according to a first registration embodiment;

Figure 9 is a schematic diagram showing contents of the Service Provisioning System of Figure 5 according to the first embodiment of registration shown in Figure 8;

Figure 10 is a schematic diagram showing an example of a registration process according to a second embodiment of registration;

Figure 11 is a schematic diagram showing contents of the Service Provisioning System of Figure 5 in accordance with the second embodiment of registration shown in Figure 10;

Figure 12 is a schematic block diagram showing components of an event processing system according to a further embodiment of the invention;

Figure 13 is a schematic block diagram showing, in more detail, components of an event processing system shown in Figure 6;

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Figure 14 is a schematic block diagram showing, in more detail, a service interaction component of the event processing system shown in Figures 4, 5, 6, 12 and 13;

Figure 15 is a schematic diagram showing an example of an event management process in accordance with an embodiment of the event processing aspects of the invention;

Figure 16 is a flow chart describing steps carried out by the service interaction component shown in Figure 14 during the event handling process shown in Figure 15;

Figure 17 is a schematic diagram describing steps carried out by the service interaction component shown in Figure 14 during an inter-OSA event handling process;

Figure 18 is a schematic diagram describing steps carried out by the service interaction component shown in Figure 14 during an OSA-IN event handling process; and Figures 19-23 are schematic diagrams showing additional examples of event management processes in accordance with the embodiments of the invention.

It should be noted that the parts and stages that have been presented for the first time in relation to a given figure and that are identical or equivalent to parts and stages that take place in subsequent figures will be described with the same reference number in such subsequent figures , and will not be described in any additional detail in the subsequent figures.

Detailed description of the invention

The embodiments of the invention are related to aspects of service networks, in particular with the efficient intermediation of the various, and potentially conflicting, network services available to a subscriber, and provides an arranged event processing system and apparatus. to deliver this functionality. These services specifically include, but not exclusively: voicemail services (International Voice Application without Interruptions, or ISVA); Virtual Private Network number (iVPN) translation services; and Selective Domestic Routing (SHR) services, prepaid billing messages, post-payment messages, Press-to-Talk services (based on resolution B #), late call forwarding, temporary call / resource interactions, services that involve SMS messaging and MMS and SIP initiation services among others. A particular feature of the embodiments of the invention is the ability to control the operation of IN and OSA services, and between different OSA services, in addition to intermediating between different IN services. The embodiments of the invention are also related to the intermediation between non-smart network and non-OSA services (for example, involving SMS and MMS messaging and SIP session initiation services).

Network environment

Referring to Figure 2, access to network functionality, including the functionality of the Smart Network, is offered and controlled by different Service Capability Servers (SCS), which appear as service capability features in the interface of OSA This OSA interface is commonly referred to as Parlay / OSA 101 GW. OSA applications such as App1 communicate with OSA 101 GW through OSA interfaces, while the underlying core network functions (Smart Network capabilities, the MSC 107 (Mobile Switching Center) and HLR 115 (Domestic Location Registration)) use their specific protocols such as CAP (CAMEL Application Protocol) and MAP (Mobility Application Part) to communicate with the OSA 101 GW. As described above, there are 14 SCFs, which include various generic call control (GCC) and multi-part call control (MPCC) sCfs, which collectively map all CAP, MAP and INAP messages, and can therefore Both invoke all network capabilities.

The main network functions referenced above are conveniently considered to be part of a Public Land Mobile Network (PLMN), which can be performed as a cellular network such as a gSm or UMTS network, and which additionally comprise components related to transmission and data delivery at the radio level (not shown). In operation, MSC 107 takes into account the impact of the allocation of radio resources and the mobile nature of subscribers, and performs procedures required for location registration and mobile station transfer. As shown in Figure 1, MSC 107 is connected to HLR 115, which is arranged to store data that identifies the location of mobile subscribers (for example to be able to route calls to them); identification numbers set to each mobile subscription (for example, International Mobile Subscriber Identity (IMSI); International Mobile Subscriber ISDN Number (MsiSdN)); communication service subscription information, service restrictions (for example roaming limitations); general subscriber attributes and preferences; and complementary service information that includes parameters associated with these services.

In terms of communication between the various components of the network, MSC 107 and HLR 115 send and receive data through a variety of signaling protocols, including but not limited to, Mobile Application Part (MAP) of Signaling System Number 113 (SS No. 7), while the signaling between MSC 107 and radio components uses the Base Station System Application Part (BSSAP) of SS No. 7.

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Overview: system architecture

Turning now to Figure 4, a first arrangement of an event processing system according to an embodiment of the invention will be described. In this first arrangement the processing system is arranged to control the operation of various intelligent network services IN1, IN2, IN3 according to one or more rules, and comprises a Service Interaction Function SIF 301 and a Subscriber Profile Store 303. Figure 4 schematically illustrates the flow of data between the various system components, and it can be seen that, instead of the MSC 107 that communicates directly with the nodes of the intelligent network service IN1 ... IN3, the MSC 107 interacts only with SIF 301, and distributes messages to various network nodes according to, at least in part, the data received from SPS 303.

SIF 301 assumes responsibility for communicating with the various network service nodes IN1 ... IN3, and the nature and order of any communication with them is controlled in accordance with data received from SPS 303, as will be described in more detail. then. SPS 303 is essentially a data repository that stores information related to activation and specific subscriber service. In addition, you can store data between services, which can be configured and combined by the SIF to specify interactions between service nodes (for example in terms of access priority). The SPS can be provisioned with data from provisioning services, such as web services located on a larger web, as shown schematically in Figure 4.

Turning now to Figure 5, it can be seen that SIF 301 is also arranged to interact with, and control the operation of, various OSA applications, by means of an OSA 101 gateway (only one is shown for clarity). In such provisions the information related to the service stored in SPS 303 includes rules and conditions in relation to the interaction between IN services and OSA services, as all will be described in more detail later in the description.

A third arrangement is shown in Figure 6, in which a SIF 301 is arranged to control the operation of services located behind the gateway 101. This arrangement addresses a limitation of the conventional OSA gateway design, in particular any activator / subscriber since it is prerecorded effectively in a single OSA application (and therefore it has effectively the same lack of flexibility as described above in the context of intelligent network services provided by a switching MSC). This arrangement, therefore, provides a means for multiple OSA applications to be invoked flexibly in response to certain service triggers and / or subscriber data. An event processing system could include two SIF devices, one located in the network, in accordance with the first and second provisions (Figures 4, 5) and one in the OSA domain (Figure 6), which means that the two SIF devices both logically and physically different from each other. As an alternative, the event processing system could include a single SIF, which is physically distributed, but logically integrated, between the network and the OSA domain. These various provisions will be analyzed in more detail below.

Service record

Subscriber Profile Store SPS 303 is arranged to store a list of services (IN and OSA) and the relationships between them, in terms of network event processing, for all subscribers. The services are preferably coded according to the subscriber identities and service activators, so that, for any given identity and subscriber activator, the services available to the subscriber can be selected when a call involving a certain activator must be processed. In addition, the relationship or relationships between the selected services can be recovered, in the form of "call model logic" associated with the trigger.

As can be seen from Figures 4 and 5, SPS 303 can be provisioned with data 311 from provisioning services, such as web services located in a wider network, and the provisioning process is preferably independent of the registration process. The following establishes a possible data structure for data 311, referred to herein as provisioned data, stored in sPs 303 with respect to a given subscriber:

Subscriber - MSISDN or IMSI key or corporate ID Attributes: - DP GT Application

Service key Protocol

Execution Preference

Synchronous or asynchronous execution Connection preference;

forward DRA / PN calling modified in InitiaIDP Forwarding preference

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Release preference Error preference In network / out of network / whatever is search application is domestic routing application Attributes: - Eventld

ServiceSet: reference to a particular set of applications and application rules specified in another SPS table.

Waiting times Location [rw]

These attributes include data that enable SIF 301, when properly configured, to operate services internally based on individual responses and messages received from the network and other services. SPS 303 can store rules between applications and between services, which specify interactions between service nodes when the various responses and messages are received from the network (for example in terms of access priority); These aspects are described in more detail below. In terms of activators, by way of example only, SPS 303 can be configured to support the following non-limiting list of service activators: INAP DPI - DP18; CAP V1 O-CSI, T-CSI; non-DP MAP events, for example locationUpdate, forwardSM; CAP activators V2 V3 V4; MMS, SMS, SS, USSD, SIP.

As described earlier in the background section, the starting point for capturing network events of interest to OSA applications is conventionally within the event processing SCS, which checks the parameters specified in an enableCallNotification () message (or message createNotification () for MPCC calls) to identify if an application is already registered or not for these parameters. Based on this check, the SCS allows or rejects the registration of the application for these parameters.

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

Turning now first to Figure 7, it can be seen that the GW Parlay 101 includes a registration function 305 configured to communicate with both the Call Control SCS 103 and with the storage SPS 303. In addition to the provisioned data 311, previously entered (information related to specific subscriber activation and service), SPS 303 stores dynamic data 313, which indicates the real-time status of any given application listed in the provisioned data 311. Examples of such real-time information include data that identify whether an application is active or not, along with details of subscribers and network events currently registered with respect to the application; In the following description, this real-time data is referred to as an alternative as “application handlers”. The applications are preferably coded according to the subscriber identities and service activators, so that, for any given subscriber identity and activator, the applications available to the subscriber can be selected when a call involving a certain activator is to be processed. .

Figure 8 shows the steps involved in a registration process according to a first embodiment: in step 81 App1 sends a GCC enableCallNotification () request to SCS 103, which causes the registration function 305 to assign an assignment ID ( assigmnentid) with respect to App1. In step 82, the assignment ID is sent to the SPS 303, together with the trigger, the source and destination address data specified in the enableCallNotification () request, and a receipt acknowledgment message is subsequently transmitted back to App1 in step 83. Upon receipt of a message from the registration function 305 in step 82, the SPS updates dynamic store 313, either to include App1 (and details of the trigger, address of origin and destination received in the step 81) or, if App1 is already stored therein in relation to other activator / subscriber parameters, to update the parameters to include those corresponding to the data received in step 81. Figure 9 is a schematic diagram showing how data is distributed among components of SPS 303: the circle corresponding to dynamic data 313 represents applications with respect to which data has been received from the registration function 305 in the previous manner mind described (as shown in Figure 8), while the link corresponding to the provisioned data 311 represents applications with respect to which the subscriber has subscribed, but which have not yet been registered with the gateway 101. It will be appreciated that in this embodiment and later, the registration request can also refer to a plurality of subscribers (for example, mass registration) as to a single subscriber.

Figure 10 shows the steps involved in a registration process according to a second embodiment: in step 81 App1 sends an enableCallNotification () request to SCS 103, which causes the registration function

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

305 send a request to SPS 303 with respect to App1, which consults SPS 303 for the subscriber / activator / AppI combination made in the request received in step 81 (step 1001). This causes SPS 303 to query the provisioned data store 311 and in step 1003 the SPS 303 returns a query result to the registration function 305. Assuming the result is positive, the registration function 305 assigns an ID of Assignment to App1 and in step 1005 send the assignment ID assigned to SPS 303, together with the trigger, source and destination address data specified in the enableCallNotification () request. An acknowledgment message is subsequently transmitted back to App1 in step 1007. Upon receipt of a message from registration function 305 in step 1005, the SPS updates dynamic store 313, to include App1 (and details of the trigger, address of origin and destination received in step 81) or, if App1 is already stored in it with other activator / subscriber parameters, to update the parameters to include those corresponding to the data received in the stage 81. Figure 11 is a schematic diagram showing how the data is distributed among the components of SPS 303: the circle corresponding to the dynamic data 313 represents applications with respect to which the data has been received from the registration function 305 in the manner described above (as shown in Figure 10), while the circle corresponding to the provisioned data 311 represents applications with respect to which the subscriber h to subscribed, but who have not registered yet with the gateway 301.

From a comparison of Figures 9 and 11 it can be seen that the difference between the two registration processes is that, in the first registration method, the dynamic data store 313 can maintain the application data that is really invalid for this particular subscriber / trigger event, while in the second registration method the dynamic store 313 will only maintain a subset of applications for which the subscriber has full access. Although in the first provision this means that the dynamic data store 313 can maintain invalid data, it is a somewhat faster procedure than the second (which implies 2 stages less than what is required in the second process); however, the second registration process is safer than the first. A particular advantage of the registration applications according to the second embodiment is that the registration process is transparent to the registration application, which means that it can be conventionally integrated with any provision compatible with the oSa standard.

An additional process (not shown) is also possible, in which the SPS maintains data that specifies all possible combinations of applications, together with interaction conditions associated with each other. This data is filled out of line, so that, during the registration process, the SPS serves as a type of search function for rules between relevant applications. When the registration function 305 receives (via SCS 103) an application registration application (step 81), the registration function 305 assigns an assignment ID to the App1 application and sends the identifier assigned to the SPS 303 (step 82) . In response to the receipt of the identifier, sPs 303 retrieves interaction rules based on this, and any other application that has been registered for this subscriber, and associates the interaction rules retrieved with the activator, address of origin and destination received at the step 81. In addition, the SPS updates dynamic store 313, either to include App1 (and details of the trigger, source and destination address received in step 81) or, if App1 is already stored in it in association with others. Activator / subscriber parameters, to update the parameters to include those corresponding to the data received in step 81. The operation of the SPS according to this embodiment can be explained with reference to an example:

SPS 303 is arranged to store the interaction rules as indicated below:

Application or applications Rule or rules

Unique application (for example X) None X and Y Beta

X and Z Delta

Z and Y Gamma

X and Y and Z Alpha

Assuming that a subscriber record from which only one application request has been received from Application X, then in response to a subsequent registration request from Application Y, SPS 303 retrieves in an interaction rule for a combination of X and Y applications (at this beta point), and marks the interaction rule recovered against the subscriber and activator, in addition to updating the dynamic data store 313 to reflect the registration of the Y application for this subscriber and the activator data received in step 81. If, subsequently, the Z application is registered for this subscriber, SPS 303 locates an interaction rule for a combination of X, Y and Z (alpha) applications and updates both SPS 303 and the data store dynamic 313 accordingly. If the X application then cancels the registration (either by itself or in relation to this subscriber) the SPS 303 retrieves the gamma interaction rule and updates the information of the stores accordingly. These interaction rules specify valid interactions between two or more applications when an event related to an associated trigger is received from the network. It should be noted that these interactions may be conditional on the type of response and / or message received from the services (applications) associated with the services; This behavior can be conveniently specified in the interaction rules, or it can be specified in data associated with the affected services.

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

It should be noted that this provision is considerably different from that presented by BT (described as "Characteristic interaction / service selection"). In the BT method and system, the interaction rules are consulted at the time of application registration to determine if the applications can coexist or not in relation to the same activator. If the interaction rules allow an applicant application to coexist with an application that has already been registered with respect to the associated subscriber / activator, the details of this requesting application are recorded in a user profile. When a corresponding network trigger is 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 were registered with the gateway ). In contrast, with the embodiments of the present invention, it is the interaction or potential interactions between applications that is selected or selected during the registration process, having resolved the real and permissible relationships between applications and subsequent behaviors outside the line. As a result, the order in which applications are invoked is not restricted by, or in fact even related to, the order in which applications are registered with the gateway. Instead, the invocation of applications is specified in the preconfigured rules, which can be optimized as a function of the applications themselves. This is an obvious advantage over the Bt design.

As described above, in addition to storing data indicative of available applications, along with associated real-time status information assigned during the registration phase, SPS 303 is arranged to store data indicative of the relationships between services and applications, in terms how an incoming network event should be processed; This data is 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 party registration method. When the registration of applications is carried out in accordance with the first and second methods, the associated interaction rules are selected from the interaction rules repository when an event is received from the network, as will be described in more detail below.

It will be appreciated from the foregoing that in the case of both OSA and IN applications, the problem of conflicts between applications is completely ignored in the registration phase. Instead, inter-application management is controlled by SIF 301 when a request for service is received from the network. In terms of the configuration of these components, referring to Figure l2, in a first arrangement SIF 301 is located on gateway 101, and assumes the responsibility of communicating with the various network application server nodes App1 ... Appn. An alternative arrangement is shown in Figure 13, in which SIF 301 is located outside gateway 101, and therefore communicates directly with OSA applications App1, App2 and SPS 303, while communicating with gateway 101 via an interface In both figures the dashed lines indicate communications with gateway interfaces to communicate with external devices such as, in the case of Figure 12, the SPS 303 and the applications App1, App2 and in the case of Figure 13, the SCS 101) .

Service invocation

The components of SIF 301 and the functionality provided in this manner will now be described with reference to Figure 14, which is a block diagram showing a decomposition of SIF 301 into its component parts. Preferably these components are implemented as one or a plurality of software components, and are distributed in one or a set of computing devices, comprising conventional CPU, memory, data bus, input / output ports, data storage and software programs. operating system (not shown).

Generally speaking, SIF 301 is arranged to provide an inter-IN to IN and / or IN to OSA application mediation and / or inter OSA to OSA, so that multiple service applications can share trigger points such as event events. Detection point of the Intelligent Network Application Protocol (INAP) and the Camel Application Protocol (CAP) listed above. In one arrangement, the SIF is configured to receive, from MSC 107 or from any SCF, such as one that includes SCS 103 shown in Figure 2, a service request message that includes some kind of trigger; make a query in the SPS 303 database depending on the received trigger; receive data from SPS 303 in response to the query; invoke and coordinate any of the service applications that are identified by the data returned by SPS 303 in accordance with the call model logic associated with them (returned by SPS 303); and collect a global response to send back to SCS 103 or MSC 107 to enable the service to continue. The call model logic includes drive services depending on responses and messages received from other services during call establishment; The logic is sufficiently flexible and detailed that, for a given network event, the MSC 107 and other network switching devices may be involved in the establishment of events, and any given service application may be invoked more than once.

In the present embodiment, SIF 301 comprises a service interface 140 for communicating with the network service applications IN1 ... INx, App1 ... Appn and switching devices such as MSC 107; an SPS interface 141 for communicating with the SPS 303, a logic engine 142 and an event processing engine 143. The service interface 140 is arranged to support at least cAp, INAP, MAP, SIP and API such as CORBA and SOAP, thus enabling SIF 301 to communicate with a range of different network devices.

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Logic engine 142 is arranged to request service data from SPS 303, together with data identifying rules and details of service applications (in the form of fixed rules 145, dynamic rules 147 and / or script rules 149 (at least some of which are received from SPS 303 in real time)), depending on the activator and subscriber data. Having received this data, the logic engine 142 is arranged to generate one or more network processing events, which involve invoking a service through the service interface 140 and causing the event processing engine 143 to monitor, and act upon, the exit of such invoked services. In particular, the event processing engine 143 is arranged to carry out the transaction management, correlation management (for example correlating the DPs received from different switches), timeout control (in relation to responses received from the IN1 services. .. INx, App1 ... Appn and SPS 303); instance management (in relation to service sequencing, and support for multiple simultaneous independent operations); and general administrative tasks such as statistics and alarm management. The event processing engine 143 can therefore perform one or more OSA network services and applications in response to an OSA callEventNotify () message and / or an IN InitialDP, collect global responses from some or all of the driven services. and send data to SCS 103 or MSC 107 to connect a subscriber to the required network service or services.

The features and functionality of the network event processing engine 143 will now be described in more detail. The call model logic returned from SPS 303 (typically in the form of data 145, 147) is used effectively to control the sequence in which the IN and OSA service applications are invoked IN1 ... INx , App1 ... Appn with initial and subsequent messages, thus solving the problem of distributing the only activator resulting from an activator point. When the output of a service application influences the operation of another service application, the invocation is preferably synchronous, but if the outputs from various service applications are simply combined by the event processing engine 143, the service applications are invoked. preferably asmchronously to improve latency. It can therefore be observed that inter-application processing is managed at the time of processing a call by means of the rules retrieved from SPS 303. In addition to SPS 303 returning sequencing rules with respect to OSA triggers such as callEventNotify () and IN triggers such as InitialDP triggers, there are also rules for processing event notifications (ERB (IN), RouteRes () (OSA)) applyCharging (AC / ACR (IN), messages superviseCallReq () / superviseCallRes () (OSA )), call access and temporary resources (ETC / CTR) and any resulting response from them.

In summary, the operation of SIF 301 can be seen as comprising two distinct phases: the first, in which SIF 301 recovers actionable data corresponding to the trigger; and a second, in which SIF 301 invokes applications based on actionable data, including invocation monitoring for, and acting on, data received from the driven applications.

The event processing engine 143 is additionally arranged to control the 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, event processing engine 143 applies various rules to identify which of the 'wins' messages; and in another simple example, if a CONNECT / routeRequest () message and a LIBERAr (IN) or release () (OSA) message are returned by different service applications, event processing engine 143 applies various rules to identify which of The two conflicting actions are taken. Essentially, therefore, the outputs are processed in accordance with an appropriate rule from SPS 303 associated with the event in conflict and / or action.

The event processing engine 143 is arranged to handle communication failures, in accordance with the dynamic (ie configurable) rules 147 retrieved from SPS 303, depending on the type of failure. For example, if a first service application is aborted, one option is that all transactions are aborted, while another may be that if the first service application continues but the second fails, the response from the first should take preference .

The event processing engine 143 is also configured to monitor responses within a predetermined period of time, in which, in the event that a service application response fails to arrive, or the MSC responses fail, SIF 301 performs one of a plurality of actions. For example, in the event that a service application fails to respond within the specified period of time, the SIF could send a TCAP fault response to MSC 107 that depends on the associated error rules. The error and timeout rules could be static rules 145 stored and maintained by SIF 301.

In summary, the logic engine 142 and the event processing engine 143 control the following actions according to conditions specified in the fixed, dynamic and static rules 145, 147, 149:

i. The order in which service applications are invoked;

ii. How responses are combined from service applications;

iii. How subsequent transactions should be made based on responses from the applications of

services;

iv. If the call control is managed by the SIF, or is delegated to a service application; Y

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

v. If applications should be excluded from the invocation as a function of the type of network (for example, domestic or roaming).

A non-limiting list of examples of fixed rules 145 will now be described:

• The requests are cumulative: if the service application A requests the BCSM DPx application report and the application B requests RRB DP and then the result must request RRB DPx and DPy. (A BCSM request report is referred to herein as RRB and is a request to create trigger points for later in the communications flow - for example Busy, Disconnected, Response, No response. If these points are activated, a BCSM event report (ERB) is generated automatically;

• If there are multiple RRB requests for the same DP then only one invocation should be requested;

• If there are multiple RRB requests for the same DP then the monitor mode should be the highest requested;

• CONTINUE should be returned only if all service applications indicate continue;

• If there is only one service application listed for a subscriber / DP then the SIF must abandon the call, ie forward the InitialDP to the service application, with the response routed directly back to the start MSC;

• If there are no service applications defined then the SIF must return a CONTINUE response;

• The SIF should interrupt the flow at the earliest possible opportunity; For example, only CONTINUE, CONNECT or RELEASE to the MSC is returned, or if all expected MSC responses are intended for a single application;

• etc.

A non-limiting list of examples of dynamic rules 147 will now be described:

• The order of the initial DP retransmission to the service applications must be in the order of preference set;

• If service applications can be invoked asynchronously then they should be done, since this will improve latency;

• If the answer is FREE, then the overall response should be governed by the service application release preference. If there is a service application with a higher release priority that has not returned a RELEASE (ie CONTINUE or CONNECT) then the lower priority service application should be ignored. If the RELEASE is of the application with the highest release priority, then the remaining service applications need not be activated; and a TCAP RELEASE and END must be returned;

• If a CONNECT is returned, then the called / calling party returned to the MSC should be that of the service application with the highest connection preference;

• etc.

A non-limiting list of examples of rules 149 that are made in scripts will preferably now be described:

• Billing reports (ACR) should be distributed only to those applications that contributed to the previously generated CA. There may be complex calculations required to message ACRs in an appropriate manner for each service application;

• When the action is dependent on the content in a message, a script can be used to identify the content in the message and invoke an appropriate action;

• etc.

In addition to the fixed, dynamic and static rules 145, 147, 149 described above, SIF 301 operates in

according to several general rules, which include the following:

• The SIF must end the TCAP dialogs with TC_END when the response to the MSC is a simple CONNECT, CONTINUE or RELEASE (basic purpose);

• The SIF must complete the transaction without a TC_END if it determines that no more messages are expected (for example ACR received indicating the end of the call, and there are no trigger points later) - this is known as a pre-order willing, and no additional messages are sent;

• The SIF must end all open dialogs if it receives a TC_ABORT from the MSC - retransmitting the TC_ABORT;

• The SIF must complete all open dialogs if it receives a TC_END from the MSC - retransmitting the TC_END;

• The SIF must end the dialogue with a TC_END if unexpected errors occur;

• Following an ERB Busy Report, a connection message should be returned to a different number (this may invalidate all previous interactions with other applications, so a script can be used to abort some applications or modify the behavior explicitly, potentially using messages generated specifically for this purpose).

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

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

The functionality of an event processing system will now be described with reference to several example scenarios that involve processing incoming calls from a mobile station MS 2. Referring to Figure 15, in a first example the system is related to the control of the operation of various IN services, which includes a Domestic Service Routing (SHR) application for use when changing the server node when an MS 2 subscriber is roaming on a VPLMN visitor network, and an unspecified service application IN1, whose operation depends on the server node that is in the home network. This first example illustrates the interactions between SIF 301, an application of SHR and another and as such is a simple example; It is included to demonstrate the types of rules, conditions and messages that pass to and from SIF 301, server node 107 and service nodes to help understand other more complex embodiments of the invention.

In this example, SIF 301 is used to manage inputs to and from the various SHR service applications, IN1 that depend on the service data related to the subscriber MS 2 (an SHR service allows a call to be processed in the home network (HPLMN) if this resolves the problems or limitations associated with processing by the visiting network (VPLMN)).

Figure 15 is a schematic diagram showing the transfer of communication between system components, although Figure 16 is a block diagram showing the steps carried out by SIF 301. Next, reference will be made to Figures 15 and 16 together. In step 1501, having received a request for a Location Update, HLR 115 sends a signal comprising O-CSI (Origin Camel Subscriber Information) to vMSC 107 (MSC in the visiting network), which performs various procedures of authentication and configuration to authenticate the MS 2 subscriber with the VPLMN network. The information sent to vMSC 107 in step 1501 includes the network address of SIF 301 and the associated service triggers with respect to the subscriber Ms 2.

Having successfully authenticated the user, vMSC 107 expects the subscriber MS 2 to request access to a network service; once received (step 1503) the vMSC 107 sends (step 1505) a message to SIF 301, which includes data that identifies the subscriber MS 2 and specifies the type of service trigger (in this example CAP iDp DP2), together with details of CdPN (B) and CgPN (MS 2). Returning to Figure 16, when a message is received by SIF 301, it first identifies the type of message (step 1601). In this example, the type of message is identified to be a service establishment message, and, since the IDP represents a new call, SIF 301 makes a query (step 1603), using for example the Access Protocol of Directory (DAP), to retrieve data from SPS 303. Having formulated and made an appropriate query, SPS 303 returns data in accordance with it, the data comprising a selection of rules and service information that specifies the services to which the subscriber MS 2 has access and the conditions under which the services can be accessed (step 1605). In the present example, the SPS 303 query returns the following data:

MS2

• Service applications:

o SHR, IN1: both configured to respond to DP2 events

• Terms:

o Rule (1) Access SHR first;

o Rule (2) if SHR returns correlation address for CdPN: (1) replace CdPN with correlation address; and (2) access IN1 when calling routed through HPLMN.

The event processing engine 143 is then configured in accordance with these conditions (step 1607), enabling it to effectively monitor data from the SHR, and to respond according to events (1) and (2) if it should the SHR return a correlation address. Returning again to Figure 15, in step 1507 SIF 301 sends a message to the SHR comprising the trigger data (IDP and DP2), and, in step 1509, receives a response from the SHR (having the application of SHR service the responsibility to determine if the call should be routed domestically or not).

In this example, the SHR service application sends a correlation address to SIF 301, which processes it according to the steps shown in Figure 16: in step 1601 SIF 301 determines that the data received is from the SHR service application, and passes the data to event processing engine 143 (having previously configured to monitor such an input). Next, the event processing engine 143 executes the rules retrieved from SPS 303 with the data received as input, which in this case comprises data specifying that the Domestic Routing is to be performed, together with a correlation address for same (step 1611). According to Rule (2), the next action to be taken is the sending of the correlation address to vMSC 107 to change the commutation with which it is

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

the subscriber MS 2 connected, so that the event processing engine 143 prepares a message to be sent to the vMSC (step 1613), and then prepares the event processing engine 143 to monitor the next connected event (step 1615). In this particular scenario, event processing engine 143 is configured to monitor the same Initial Detection Point (IDP) as sent to SIF 301 in step 1505.

Returning again to Figure 15, in step 1511 SIF 301 sends a connection message to the vMSC, which directs the vMSC to transfer to a switch corresponding to the correlation address (CID). SIF 301 also sends a TCAP message, which closes the dialogue between SIF 301 and vMSC 107. In step 1513 vMSC 107 routes the call to the GMSC, which is the switch that has a network address corresponding to the CID correlation address, and that is located in the home network (HPLMN). Upon receipt of the connection message, the GMSC sends an IDP message to SIF 301, including the message the CID correlation address and a new DP3 Detection Point (step 1515). Returning again to Figure 16, having identified the message as originating from a switch and comprising an IDP Initial Detection Point that correlates with the CID previously recorded by SIF 301, event processing engine 143 executes the rules recovered from SPS 303 in step 1603 with the data received as input (step 1611). According to the remaining event (event (2)), and having received a message from a switch in the home network (HPLMN), the next action to be performed by SIF 301 is to send a message to the service application IN1, and Wait for an answer from it. Therefore, in step 1517, the event processing engine 143 sends a message to IN1 and awaits a response.

There may be several other events that depend on the output of IN1 - depending on the nature of the service application - but the above example demonstrates how SIF 301 can be used to coordinate an SHR service application along with at least one other application of service. IN1 service that is dependent on the same trigger as the SHR (in this example DP2).

The functionality of an event processing system that involves OSA applications will only be described with reference to Figure 17 which shows a generic scenario that involves the processing of input triggers from the network. Referring to Figure 17, in step 1701 an IN event is received by SCS 103 and SIF 301 is passed, including the IN event data identifying the calling party (subscriber) and specifying the type of service trigger (for example CAP IDP DP2), along with details of the Called Party (CdPN). Having identified this which is the first of such a message from the network in relation to the current event processing scenario, SIF 301 formulates a query (step 1703), using for example the Directory Access Protocol (DAP), to retrieve data from SPS 303 corresponding to it. Upon receipt of the request for consultation, SPS 303 retrieves data that corresponds to the subscriber and activator from the dynamic data store 313. Referring back to Figure 9, if the registration took place according to the first provision, this step will involve filtering the dynamic data 313 using the provisioned data 311, and for the example shown in Figure 9, it will result in an output of App1 and App2. On the other hand, if the registration took place in accordance with the second provision, then since the subscriber accesses an applicant application that was checked during the registration process, SPS 303 simply has to retrieve the contents of dynamic storage 313 (App1 and App2). If the registration took place in accordance with the third embodiment, SPS 303 will recover the contents of dynamic storage 313 (App1 and App2) together with pre-selected interaction rules that govern the interaction between App1 and App2.

For cases in which registration has previously taken place according to any of the first or second registration method, and unlike the third registration method, once the relevant applications have been identified (App1, App2), SPS 303 You have to perform a separate stage of rule selection and service information that specifies the conditions under which applications can be accessed; regardless of whether the method of registration of the interaction rules now selected have been subsequently transmitted to SIF 301 in step 1705. Next, the event processing engine 143 is configured in accordance with these conditions, which, for For the purposes of this example, it can be assumed that they cause the App2 to be invoked before App1. Therefore, in step 1707, App2 is invoked by means of, for example, the callEventNotify () message, and in step 1709 a response is received and processed by SIF 301, more specifically the event processing engine 143 ( having previously configured to monitor such an input when the notification message was transmitted in step 1707). Next, the event processing engine 143 executes the rules retrieved from SPS 303 in step 1705 with the data received in step 1709 as input. According to the rule or rules processed, the event processing engine 143 determines that the next action to be performed is the sending of data received in step 1709 to App1, whereby the event processing engine 143 sends a message callEventNotify () to App1 (step 1711), and then prepares event processing engine 143 to monitor the next connected event. Having received a response from App1 (step 1713) the event processing engine 143 executes the rules retrieved from SPS 303 in step 1705 with the data received in step 1713 as input. In accordance with the rule or rules processed, the event processing engine 143 determines that the next action to be performed is the connection of the calling party (subscriber) with the Called Party (mailbox VPS), and therefore the SIF 301 causes that the sCs 103 send a network connection message (step 1715), which directs the network to connect the subscriber to its voicemail VPS, which allows access to its recorded messages. The

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

step 1717 indicates the transmission of additional network events with respect to which one or more OSA applications have registered an interest.

Figure 18 shows an example of an event processing system that involves OSA and IN applications, and shows that embodiments of the invention can also be used to control the operation of OSA applications and IN services as part of a service. global event processing in relation to a network trigger. In this scenario, steps 1701, 1703, 1705 proceed as described in relation to Figure 17, but since, in this example, it is assumed that the activator in question causes the SPS to request data related to both IN services and OSA applications, the data returned by SPS 303 will include invocation rules that cause SCS 103 to intercede the transmission of messages to the IN domain with transmission of messages in the OSA domain; A list of the associated stages is shown in the figure.

From the above examples, it can be seen that an event processing system configured in accordance with the embodiments of the invention provides a Service Integration Function that integrates, and controls the operation of, a plurality of service applications. In network arrangements comprising a plurality of event processing systems, a central repository of service applications that are accessible by any one, or a subset, of such SIF may be developed in accordance with the access rules assigned to a system of particular event processing. In addition, in any given SIF that provides access to a plurality of custom and / or inherited service applications, the SIF is configured to integrate these applications between sf and other recently developed service applications. A particularly advantageous feature of the embodiments of the invention is that the SIF comprises a means for effectively announcing the functionality thereof, enabling recently developed service applications to use such functionality in a proactive manner; This functionality is shown, schematically, as the SCS 148 API in Figure 14.

Additional examples illustrating the flexibility associated with embodiments of the invention are presented in Figures 19-23, the first of which illustrates the coordination operation of SIF 301 of a search application such as the iVPN service (App 1) with Operation of the International Uninterrupted Voice Application (App 2). In this example, the App1 search application is arranged to determine which of the registered devices of a called party (subscribers) are active and to provide a number translation service in relation to it. The example could additionally include a SHR application (either in the SIF or as a separate application (not shown)), which is used to order the vMSC to transfer the call control to a GMSC, in the manner described above in the previous examples. In response to receiving a connection request (step 1901) from the vMSC, the SIF is configured (by means of rules retrieved from SPS 303, as described above (set out below)) to send a request (step 1903) for a number translation service to App 1. As described above, App 1 is an iVPN search application that has access to a pre-specified list of devices registered for the subscriber, and, in response to the message of service request sent from the SIF in step 1903, sends back (step 1905) a translated full digit number corresponding to a first device on the list, along with a request for an ERB busy message in the case that the device is not available. In response to receiving the translated number of the first device from App1, the SIF establishes a waiting event (step 1907) for a busy RRB message from the vMCS and sends a message (step 1909) to App 2, which includes details of the translated number. App 2 then sends a Connect instruction (step 1911) to the SIF, along with a request for an ERB busy message in case the first device is not available.

SIF 301 then consolidates the entry from both applications App1, App2 and sends a connection request regarding the first device to the vMSC (step 1913). In the present example the first device is not available for the vMSC that returns an eRb busy message to the SIF (step 1915); In accordance with the rules applicable in this example, the SIF is willing to prioritize the reception of ERB occupation messages and send them to the App 1 search application in the first case, while marking the fact that App 2 needs to be informed from the fact that the first device is not available. Having received an ERB busy message, the SIF sends the ERB busy message to App 1 (step 1917), which, in response to it, retrieves and transmits details of a second device in the subscriber's list to the SIF ( stage 1919). Upon receipt of the identity of this second device (long identity Y), the SIF ends the session with App 2 in relation to the first device (stage 1921) and initiates a second session in relation to the second device (stage 1923) . App 2 below sends a SIF Connection request (step 1925), this time in relation to the second device (accompanying the connection request, as before, with a request for an ERB busy message in the case of that the second device is not available). SIF 301 again consolidates the entry from both applications App1, App2 and sends a connection request with respect to the second device to the vMSC (stage 1927), and the subsequent stages (not shown) continue depending on availability, or other way, of the second device (that is, if the second device is not available, steps 1915-1927 are repeated efficiently, while if the second device is available, the vMSC continues to process the call.

The rules that could be applied in relation to this additional example (as recovered from SPS 303 and are enforceable by SIF 301 to provide the functionality described above) are as follows:

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

In the present example, for the T-CSI CAP activator and MS 2 subscriber, the SPS 303 query returns the following service data and condition sets:

• Service applications:

o SHR, Search Application (several registered devices), iSVA

• Terms:

o Check if the applicable SHR (ie ^ is the MSC in VPLMN?); if applicable, send correlation address to switch in VPLMN; o Rule (1): Access search appln first;

o Rule (2): If the response from the Search Application indicates a connection with a setting (corresponding to a first device) of a destination routing address (DRA), modify the part number called in the IDP so that be the DRA and send the modified IDP to the ISVA application. Otherwise, or in any other case, send the unmodified IDP to the ISVA.

o Rule (3): If the response from the ISVA service (CdPN), store CdPN until the MS 2 connects to the switch in the HPLMN;

o Rule (4): If the search application and ISVA both request RRB occupation messages, send any ERB busy message received to the search application, retrieve new destination routing address (ie DRA corresponding to the second device ), finalize dialogue with ISVA based on the first DRA, and send modified dRa to ISVA.

o Rule (5): once MS 2 is connected through HPLMN, send message Connect to switch in HPLMN.

An additional example will now be described, with reference to Figure 20, which shows another example of the SIF 301 coordination operation of an Intelligent Service Node (VPN) with an OSA service node (VPX search application). In this example it is assumed that the subscriber has already subscribed to a VPN service as an intelligent network service, and you want it to be integrated with your newly retaken OSA services. Therefore, and returning to Figure 20, in response to receiving a connection request (step 2001) from the MSC, the SIF is configured (by means of rules retrieved from SPS 303, as described above) to send a request (step 2003) to the VPN service. In response, the VPN sends back (step 2005) a full digit number that corresponds to the called party number. In response, the SIF sends a message (step 2007) to VPX, which includes details of the full digit number. The VPX application sends a Connect instruction (step 2009), with respect to the first device that corresponds to the complete digit number of the called party (identity E), to the SIF, together with a request for an ERB busy message in the case that the first device is not available. The SIF establishes a waiting event (stage 2011) for a busy RRB message from the MCS, consolidates the entry from both VPN applications, VPX and sends a connection request regarding the first device to the MSC (stage 2013). In the present example, the first device is not available, so the MSC returns an ERB busy message to the SIF (stage 2015), which causes the SIF to send the ERB busy message to VPX (stage 2017), which , in response to it, retrieves and transmits details of a second device in the subscriber's list to the SIF (stage 2019). Upon receipt of the identity of this second device (identity F), the SIF sends a connection request with respect to the second device to the MSC (step 2021), and to the subsequent stages (not shown) that continue depending on availability, or otherwise, of the second device (that is, if the second device is not available, the steps 2017-2021 are repeated effectively).

Another example is shown in Figure 21, which shows the use of SIF 301 to coordinate the operation of post-paid and prepaid services: in this example SIF 301 is configured to perform processing with respect to post-payment rates to modify them in A suitable format for a prepaid service. Such post-payment applications include a VPN application and an "Office Zone" application, the last of which identifies the location of a subscriber and modifies the conventional rate (ie VPN rate) depending on them. In response to the receipt of a connection request (step 2101) from the MSC, the SIF first identifies, based on the service key SK (a) that accompanies the collection request and the data requested from SPS 303, that the subscriber is of the prepaid type, which has been granted access to various OSA post-payment services (each being identifiable by service keys SK (b) and SK (c) respectively). Therefore, in step 2103, SIF 301 is configured to send a request to the gateway 101, which identifies the application to be consulted at this stage by means of the service key SK (b); Upon receipt of the service key SK (b) and associated call data, the gateway 101 sends a calleventNotify () message to the application corresponding to the service key SK (b), which in this case is App 2 ( step 2105). App 2 is a VPN Search Application that has access to a predefined list of registered devices for the subscriber, and, in response to the service request message sent from GW 101, sends back (step 2107) a number of Full, translated digit corresponding to a first device on the list, along with a fee associated with this service. In view of the fact that App 2 is a post-payment application, OSA 101 GW packages the rate information with the associated sCi billing response message and sends it in the SIF (step 2109). In accordance with the rules sent from SPS 303, the SIF below indicates that the following

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

application to be consulted is the application of Domestic Office App 1, and sent a request to the gateway 101, including the request for data that identifies App 1 through the service key SK (c) and data that identifies the called party (step 2111); Upon receipt of the service key SK (c), the gateway 101 recognizes that the request must be sent to the App1 office application and sends the called party number (B long) to it (step 2113). In response, App 1 sends data indicative of a rate associated with the location of the calling party - rate Y - to the SIF, through the OSA 101 GW (steps 2115, 2117). Once upon receipt of the different rate information, the SIF processes the data to identify an appropriate rate to provide the subscriber with these services - in its capacity as a type of prepaid subscriber (step 2119). The output of this evaluation process is the transmission of a message comprising combined rate data and service request to the IN1 prepaid service (step 2121). Once received, the IN1 prepaid service performs the conventional billing evaluation process and (assuming the subscriber has sufficient funds) sends a request for call connection and request for busy message (step 2123) to SIF 301. In In response to this, SIF 301 establishes a wait event for a busy RRB message from the MSC and sends a connection request regarding the first device to the MSC.

A further example is shown in Figure 22, which shows interactions between SIF 301 and SPS 303 (assuming these have already been done in the previous examples) as well as interactions with service nodes in the network. In this example, SIF 301 and SPS 303 interconnect in an elegant way to solve a problem experienced by subscribers who are roaming in a network that is not Camel 3, specifically that arises when HLR 115 only sends O-CSI services to the VLR. When only equipped with O-CSI services, the vMSC cannot discriminate between calls that have specified prefixes and events that need domestic routing (and other services); As a result, calls that have a prefix not recognized by the vMSC are handled incorrectly. (These prefixes are called the "B #", and the corresponding events require N-CSI / DCSI service data so that the VLR knows that a call must be processed by a Push to Talk service node). In this example, it is assumed that SPS 303 is provisioned to identify whether an incoming call should be sent to a Pulse to Talk or Routing node domestically, based on B # - essentially encoding the data based on B # in addition to subscriber data and activator. Referring next to Figure 22, in step 2201 the vMSC sends a message to the SIF, the message including a B # as a prefix for the called party number. In response, SIF 301 contacts SPS 303, which requests specific service information regarding the called party number (step 2203) and the subscriber. In step 2205 the sPs 303 performs some internal processing, comparing the prefix with stored data with respect to this subscriber in relation to B # services. In the event that the stored data indicates that this subscriber has subscribed to Pulsar to Talk services, the indicative data of the service will be sent to SIF 301 (step 2207), which allows SIF 301 to send a somewhat identical message to the corrected service (at this point PTT). If the subscriber has not invoked the PTT service, the sPs 303 sends instead data indicating that the call should be routed domestically, causing SIF 301 to communicate with the SHR node shown in Figure 22.

An additional example is shown in Figure 23, which shows the SIF 301 that controls the Late Call Forwarding (LCFOR) in conjunction with a prepaid IN2 service to avoid the situation in which, when part A calls part B and part B is roaming, a voice circuit is established between the switch to which part A is connected (in the home network); the vMSC associated with part B in the visited network; and an associated service node in the home network to which the subscriber has access. Referring next to Figure 23, in step 2301 a termination call detection point is received by SIF 301 from the MSC gateway; SIF 301 requests data that corresponds to the subscriber from SPS 303, and, which identifies that the subscriber has subscribed to an LCFOR service in addition to an additional service IN2 (not specified), SIF 301 identifies that the node needs to invoke LCFOR first. Therefore, at step 2303, SIF 301 sends data indicating that the call is a termination call for the LCFOR service node, which sends a request for an ERB busy message / No reply / abandoned / message answered to SIF 301 in step 2305. SIF 301 records, internally, that it needs to monitor any such ERB messages from the MSC once the call control is passed to the gateway MSC, and sends a message to the other node of service (one shown: IN2) to which the called subscriber has access (step 2307). The IN2 service node sends a billing message and requests an ERB response message to SIF 301 regarding a call that is being answered (step 2309), which causes SIF 301 to record that it needs to monitor calls that are being responding, and inform the service node IN2. SIF 301 then orders the GMSC to continue advancing the call (step 2311), which causes the GMSC to connect to the vMSC (step 2313). In response to the call being answered, the GMSc sends an ERB message to the SIF (step 2317); In view of the fact that the LCFOR node registered for such a message in step 2305, SIF 301 forwards the message to the LCFOR node in step 2319, which, in response, sends an instruction for Call Forwarding to the SIF (step 2321). In response to receiving this message, SIF 301 terminates the previously active session with node IN2 in step 2323, and instead initiates a session with respect to a call forwarding event (step 2325). The call billing regarding a call forwarding event of this type is then set and SIF 301 mandates that the GMSC connect to the Forwarded Number in step 2329.

Details of the additional embodiment

Although the embodiments have described the SS7 call processing, the embodiments of the invention may be applied to other types of network events, including SIP (5 Session Initiation Protocol) call processing and message processing.

Additionally, the operation of SIF 301 can be initiated by method invocation through an API - for example CORBA, SOAP so that the SIF can provide a service intermediation facility through the IN service applications.

10

Although SIF 301 is described as a single entity, it will be appreciated that such an entity can be distributed through a plurality of processing components.

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

twenty

Claims (34)

5 10 fifteen twenty 25 30 35 40 Four. Five fifty 55 60 65 1. Event processing apparatus (301) in a communications network for use when processing service initiation request messages in an event processing system, the apparatus (301) being connectable to a plurality of service nodes from the which a subscriber can receive service during the processing of a network event, each said service node being able to transmit a service response message comprising particular data for operation of the service node, the apparatus comprising an arranged function, upon receiving a first service initiation request message sent by a server node in a network currently involved in processing said network event, to request service response messages from a plurality of service nodes, and to control the operation of at least some of said plurality of service nodes involved in the processing of the same network event based on the data contained in these service response messages, in which, in the event that the data contained in a service response message received from one of the plurality of service nodes is indicative of a request for a signaling resource that overlaps or conflicts with data contained in a service response message received from another of the plurality of service nodes, the function is arranged to process the data contained in respective service response messages based on attribute data to enable access to the signaling resource requested by each respective node of service involved in processing the same network event, in which the attribute data specify rules for interaction between the plurality of service nodes based on the received service response messages. 2. Event processing apparatus (301) according to claim 1, wherein, based on the content of said service response message, the function is arranged to control the operation of a given service node more than one once during the same network event. 3. Event processing apparatus (301) according to claim 1 or claim 2, wherein the function is arranged to send a service request message to respective service nodes, comprising at least one of said message of service request data indicative of one or more service initiation triggers corresponding to said first service initiation request. 4. Event processing apparatus (301) according to claim 3, wherein the function is arranged to modify at least one of said service initiator activator and to formulate a service request message based on said activator of modified service initiation. 5. Event processing apparatus (301) according to any one of claim 1 to claim 4, wherein the function is arranged to monitor the reception of additional service initiation request messages as a result of the operation. 6. Event processing apparatus (301) according to any one of claim 1 to claim 5, wherein the function is arranged to monitor the reception of additional response messages as a result of the operation. 7. Event processing apparatus (301) according to any one of claim 1 to claim 6, wherein, upon receipt of a second service initiation request message sent by a server node in the network currently involved in the processing of the same network event, the function is arranged to control the operation of at least one of said plurality of service nodes, and as a result of the operation, to transmit a service response message to the server node from the that the second service initiation request message is received. 8. Event processing apparatus (301) according to claim 7, wherein the first service initiation request message is received from the same server node from which the second initiation request request message is received. service. 9. Event processing apparatus (301) according to any one of claim 1 to claim 8, wherein the service initiation request message includes data identifying the corresponding service initiation trigger, and the function It is arranged to access data that identifies service nodes that correspond to said service initiation trigger, for use in controlling its operation. 10. Event processing apparatus (301) according to any one of claim 1 to claim 9, wherein the function is arranged to generate a service request message depending on data associated with the subscriber and said data contained in said first service initiation request message. 11. Event processing apparatus (301) according to claim 5, wherein the additional service initiation request message comprises trigger data other than trigger data contained within said service initiation request message. 5 10 fifteen twenty 25 30 35 40 Four. Five fifty 55 60 65 12. Event processing apparatus (301) according to claim 10 or claim 11, wherein the function is arranged to request said service response messages during the allocation of network resources associated with the network event. 13. Event processing apparatus (301) according to any one of the preceding claims, wherein the function is arranged to modify at least one of said service initiation trigger and to formulate a service request message based on said modified service initiation trigger. 14. Event processing apparatus (301) according to any one of the preceding claims, wherein, in response to receiving said first service initiation request message, the apparatus is arranged to transmit second initiation request messages of service to two or more of said service nodes in a selected sequence. 15. Event processing apparatus (301) according to claim 14, wherein the selected sequence depends on the service node response messages received from one or more of said service nodes. 16. Event processing apparatus (301) according to any one of the preceding claims, wherein the apparatus (301) comprises a monitoring function arranged to monitor a service response message from said first service node and The apparatus (301) is arranged to transmit a second service initiation request message to said second service node in response to said service response message. 17. Event processing apparatus (301) according to any one of the preceding claims, wherein the apparatus (301) is arranged to invoke a monitoring function in response to receiving service node response messages from said first service node. 18. Event processing apparatus (301) according to claim 16 or claim 17, wherein the data for use by the monitoring function is dependent, at least in part, on the data included in the reply message of the service node received from said first service node. 19. Event processing apparatus (301) according to claim 16, wherein said second service node is different from said first service node. 20. Event processing apparatus (301) according to claim 16 or claim 17, wherein the monitoring function is arranged to monitor a service initiation request message sent from a server node other than the server node from which said first service initiation request messages were sent. 21. Event processing apparatus (301) according to claim 16, wherein the second service initiation request messages are of the same type as the first service initiation request message. 22. Event processing apparatus (301) according to any one of the preceding claims, arranged to generate a service instruction message in response to a service node response message, including the service instruction message data that they request a change to the server node involved in said event processing, in which the apparatus (301) is arranged to transmit said service instruction message to the server node from which the first service initiation request message was received. 23. Event processing apparatus (301) according to claim 22, wherein the generated service instruction message comprises data ordering the server node to transfer the network event to a different server node. 24. Event processing apparatus (301) according to claim 23, wherein said different server node is located in a network different from that in which the server node is arranged to operate. 25. Event processing apparatus (301) according to claim 24, wherein one of said service nodes is a gateway node that provides access to a plurality of additional service nodes beyond the gateway. 26. Event processing apparatus (301) according to claim 25, wherein said service nodes provide one or some of: number translation services, message handling services, message modification services, message routing, voicemail services, call diversion services and / or device search services. 5 10 fifteen twenty 25 30 35 40 Four. Five 27. Event processing apparatus (301) according to claim 1, wherein the apparatus (301) is sensitive to receiving one of said service registration request messages sent from a registration service node for storing registration data indicative of the registered service node and corresponding service initiation trigger in association with the subscriber, said registration data being for use when processing service initiation request messages sent from said server node with respect to the subscriber, the apparatus (301) 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 preference between said different service nodes after said registration data has been received. 28. Event processing apparatus (301) according to claim 27, wherein the apparatus (301) is arranged to store said registration data if the registration request message is received from a service node identified as accessible For the subscriber. 29. Event processing apparatus (301) according to claim 27 or 28, wherein in response to the reception of a second and subsequent registration request message, the apparatus (301) is arranged to retrieve interaction data which specify interactions between corresponding two or more service nodes and to store said interaction data, thus defining an order of preference between said different service nodes. 30. Event processing apparatus (301) according to any one of claim 27 to claim 29, wherein in response to receiving the service initiation request message, the apparatus (301) is arranged to recover interaction data that specify interactions between corresponding two or more service nodes, thus defining an order of preference between said different service nodes. 31. Event processing apparatus (301) according to any one of claim 27 to claim 30, wherein the apparatus (301) is arranged to store additional registration data with respect to a request for registration message. additional service that identifies an additional different service node and the same subscriber, said additional service registration request message being received subsequently, the apparatus (301) being arranged to define an order of preference between said different service nodes after it is have stored such additional registration data. 32. Event processing apparatus (301) according to any one of claim 27 to claim 31, wherein said plurality of service registration request messages are received at different times. 33. Event processing apparatus (301) according to any one of claim 27 to claim 32, wherein the service initiation request message includes data identifying a corresponding service initiation trigger, and the function It is arranged to access data indicative of an order of preference between said different service nodes, for use in controlling their operation. 34. Event processing apparatus (301) according to any one of claim 27 to claim 33, wherein said registration data identifies a plurality of subscribers with respect to which the registration request refers.