WO2001093472A2

WO2001093472A2 - Method and system for event sequence reconstruction and statistics computation

Info

Publication number: WO2001093472A2
Application number: PCT/SE2001/001197
Authority: WO
Inventors: Angelo Cuffaro; Bartosz Balazinski
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2000-05-30
Filing date: 2001-05-29
Publication date: 2001-12-06
Also published as: AU2001260945A1; WO2001093472A3

Abstract

A system and method for processing events in a telecommunication network. Events (34, 35) generated in the network (4) are correlated, and the correlated events are sent to a corresponding client entity in a client database. Each client entity (182) stores a parsing stack (90) containing a correlated set of events and stores a semantic action object (92) that defines client-specific functions that relate to the events. A server (84) reconstructs event sequences from the correlated events in each client based on sequencing rules that are common to all of the clients and updates the parsing stacks in response to the event sequences. In addition, in response to a particular event sequence, the server initiates (140) a semantic action that is defined by the client and that corresponds to the particular event sequence. The semantic action operates on data contained in the events that compose the particular event sequence.

Description

METHOD AND SYSTEM FOR EVENT SEQUENCE RECONSTRUCTION AND STATISTICS COMPUTATION

BACKGROUND OF THE INVENTION

Technical Field of the Invention The present invention relates in general to the processing of asynchronous events, and in particular to event sequence reconstruction and statistics computation in a radio system.

Description of Related Art

The ability to monitor faults and collect statistics are typical functions of mobile telecommunication systems . Such functions permit mobile telecommunication system operators to continually improve the system by adapting or "tuning" the network to provide higher quality service to subscribers and to reduce the frequency of faults in the network. One aspect of mobile telecommunication networks for which it is particularly important to perform such monitoring is the radio interface. To improve the network, a network operator might want to collect statistics, for example, relating to faulty mobile station behavior, handoffs to the wrong cells, reasons for dropped calls, etc.

Typically, each switch in the radio interface subsystem in a mobile telecommunication network generates asynchronous events, such as call accesses, handoffs, and call establishments, that relate to calls in the network. These events can be subsequently processed to collect statistics and monitor events relating to the radio interface. To collect meaningful statistics, these events normally must be correlated (e.g., on a per call basis) and a reconstruction of the sequence of events must be performed for each call. Such correlations and reconstructions are very expensive in terms of memory space and processing execution time. As a result, some operators are unable to collect statistics during peak hours due to excessive system load. In addition, because the types of statistics that might be of interest are virtually innumerable, it might be necessary to collect and store a large amount of information from the switch in case such information is of interest to the network operator at a particular time. An additional problem is that it can be difficult to modify or change the processing of events (i.e., to collect different statistics). Essentially, such changes require that the event processing code be rewritten each time the specific monitoring functions are changed.

There is a need, therefore, for a system and method for reconstructing event sequences on a correlated basis and for collecting statistics relating to those events using a reduced amount of storage and processing resources. Such a system and method would also preferably allow statistics collection to be quickly performed and to be easily customized while minimizing the amount of event information that must be retained in the network. Furthermore, the system and method should allow events to be correlated on a per call or per base station basis and permit the original sequence of events to be recreated in an efficient manner.

SUMMARY OF THE INVENTION

The present invention comprises a method and system for processing events in a telecommunication network. In particular, events can be processed in a way that allows for a convenient reconstruction of event sequences and for an easily configurable collection of statistics .

In accordance with one embodiment of the invention, a telecommunication system includes an event generating node. Each event generated by the node includes data relating to a particular occurrence in the system. In addition, the system includes an event analyzer for processing events in the system. The event analyzer includes a client database and an event processing server. The client database contains a plurality of clients, with each client storing a parsing stack that contains the current state of the event correlation (including elements correlated so far). Furthermore, each client defines at least one semantic action to be performed in response to the correlated events. The event processing server reconstructs event sequences from the correlated events in each client based on sequencing rules that are common to all clients in the event analyzer and updates the parsing stack in response to the event sequences. In response to a particular event sequence, the server initiates a semantic action defined by the client that corresponds to the particular event sequence. The semantic action uses data from the events that compose the particular event sequence. In accordance with another embodiment, there is provided a method for processing events in a telecommunication network. A plurality of events are detected and are correlated on a per-call basis. Each correlated event is then sent to a corresponding client entity, which stores a parsing stack containing previously received events for the client and which also stores a semantic action object defining at least one action to be performed for the client in response to a particular sequence of events. Upon detecting an occurrence of an expected sequence of events from the previously received events contained in the parsing stack and a newly received event, a function that corresponds to the detected sequence of events and that is defined by the semantic action object is performed. In addition, the parsing stack is updated in response to the detection of the sequence of events, and the updated parsing stack is stored in the client entity.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, reference is made to the following detailed description taken in conjunction with the accompanying drawings wherein:

FIGURE 1 is a sequence diagram illustrating a simplified example of a procedure that can be defined by a set of grammatical rules;

FIGURE 2 is a block diagram of a portion of a telecommunication network in which the present invention can be implemented in accordance with a preferred embodiment;

FIGURE 3 is a block diagram of the external host in accordance with a preferred embodiment of the present invention;

FIGURE 4 is a schematic depiction of the decoding procedure in accordance with the present invention;

FIGURE 5 is a detailed block diagram of the analyzer in accordance with a preferred embodiment of the present invention;

FIGURE 6 is a more detailed block diagram of the LR client and LR server configuration in accordance with a preferred embodiment of the present invention; FIGURE 7 is a schematic representation of an entry in the parsing stack of

FIGURE 6; FIGURE 8 is an alternative representation of the LR client and LR server functionalities in a accordance with the present invention; and

FIGURE 9, there is illustrated a flow diagram of a method for processing and monitoring events in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference is now made to the Drawings wherein like reference characters denote like or similar parts throughout the various Figures. The present invention relates to a method and system for reconstructing asynchronous event sequences and for easily customizing the collection of information and statistics pertaining to the event sequences . In a preferred embodiment, the invention is implemented in a mobile telecommunication system radio interface, although the invention can be used in any system in which asynchronous events are generated (e.g., GSN node, ATM switch, and the like).

Typically, a sequence of asynchronous events in a well-defined procedure will follow certain rules that are implied by the procedure. Such a sequence can be described by a set of grammatical rules of a formal language. In other words, the grammatical rules can define expected or acceptable sequences of events, wherein the defined sequences comprise sub-procedures that can or should occur in the overall procedure. In connection with a call setup in a mobile telecommunication network, for example, two events of interest are a voice channel designation attempt (VCD A) and a voice channel designation confirmation (VCDC). The occurrence of these two events might comprise a voice channel designation (VCD) sub-procedure. Thus, a grammatical rule defining this sub-procedure can be represented by:

VCD-VCDA VCDC. Referring now to FIGURE 1, there is shown a sequence diagram illustrating a simplified example of a procedure that can be defined by a set of grammatical rules. Pursuant to the procedure, an Entity A 10 transmits a message to an Entity B 12, wherein the transmission of the message is identified as Event 1 (as indicated at 14). In response, Entity B 12 sends a response message that is identified as Event 2 (as indicated at 16). Together, the occurrence of Event 1 and Event 2 define a sub- procedure A (as indicated at 18). Sub-procedure A can thus be said to be a "production" of Event 1 and Event 2, wherein the production is defined by:

A:=l 2. Also in accordance with this exemplary procedure, Entity A 10 can transmit a message to an Entity C 21 , wherein the transmission of the message is identified as

Event 3 (as indicated at 20). The transmission of a response message (as indicated at 22) is identified as Event 4. Sub-procedure B (as indicated at 24) is then a production of Event 3 and Event 4. Furthermore, a production of Procedure C (as indicated at 26) "fires" upon the occurrence of Sub-procedure A and Sub-procedure B. The firing of these productions can be monitored using an LR(n) type of algorithm, wherein L refers left-to-right scanning of the input sequence, R refers to constructing a rightmost derivation in reverse, n refers to the processing of n look ahead tokens, and the tokens are the asynchronous events. In this scenario it is recognized that parsing theory distinguishes between two types of elements: terminal elements and non-terminal elements. The terminal elements represent the input symbols (asynchronous events in the present case) and the non-terminal elements are elements produced from several terminal and/or non-terminal elements. Often times tokens are associated with terminal elements. On the other hand, the notion of lookup (or symbol lookup) is associated with terminal elements (or tokens). Pursuant to the present invention, a semantic action object defines a variety of semantic rules, each of which are associated with a particular production. Each semantic rule defines a specific action or function that should be triggered when the corresponding production fires. For example, a semantic rule might simply be a function call with events (or results of previously fired productions) as parameters. A grammatical representation of the procedure illustrated in FIGURE 1 may be provided as follows:

C:=A B {semantic_action_l (A,B)}

A:=l 2 {semantic_action_2 (1,2)}

B:=3 4 {semantic_action_3 (3,4)} Each production has an associated semantic action. When sub-procedure A fires (i.e., once Event 1 and Event 2 are received), an associated semantic action (semantic_action_2) is triggered. Semantic_action_2 is a function having Event 1 and Event 2 as parameters. Semantic_action_2, for example, might cause a certain calculation to be performed using data associated with Event 1 and Event 2 and cause the result of the calculation to be stored in a database. Alternatively, semantic_action_2 might cause certain data associated with Event 1 and Event 2 to be transferred to a record associated with Production A while causing other data associated with the events to simply be deleted.

Similarly, when Sub-procedure B fires (i.e., upon receipt of both Event 3 and Event 4, a semantic action associated with Sub-procedure B (semantic_action_3, in this case), having Event 3 and Event 4 as parameters, is triggered. Finally, when Sub- procedure C is satisfied (i.e., once productions A and B have fired), semantic_action_l , which represents a higher level calculation or function, having the results of Productions A and B as parameters (and thus the data contained therein), is triggered.

Referring now to FIGURE 2, there is illustrated a block diagram of a portion of a telecommunication system 2 in which the present invention can be implemented in accordance with a preferred embodiment. The system 2 includes a digital exchange system, or switch 30, that is used for routing and controlling calls in a network 4 that is controlled by the switch 30. A control part of the switch 30 is implemented primarily as software and comprises a processor on which a number of applications, or blocks (B) 32, run simultaneously. Each block 32 is responsible for a particular functionality (e.g., user authentication) or sub-functionality (e.g., communication with a mobile station's home location register during the user authentication).

To monitor faults and collect statistics, the switch 30 sends event data to an external host 50 (e.g., using TCP/IP). Each block 32 in the switch 30 sends events 34, such as call accesses, handoffs, and call establishments, to an acquisition block 36, which groups events 34 together in a variable size buffer to form an event cluster 38. When the buffer is sufficiently full, the event cluster 38 is sent from a TCP/IP interface 40 of the switch 30 to a TCP/IP interface 48 of the external host via a TCP/IP link 42 (which comprises a data transmission network separate from, or part of the switch 30 controlled network 2) . In this regard, the data transmission network may be part of an event monitoring system (EMS). The TCP/IP link 42 includes a unidirectional data channel 44 for transmitting event clusters 38 to the external host 50 and a bidirectional control channel 46 for controlling communications over the data channel 44. Although the external host 50 is shown and described as being outside of the monitored system, it will be appreciated by those of ordinary skill in the art that the host 50 can be either external or internal to the monitored system without affecting the operation of the present invention.

Referring now to FIGURE 3, there is shown a block diagram of the external host 50 in accordance with a preferred embodiment of the present invention. Upon receipt of the event clusters 38 at a TCP/IP stack 52, they are fed by a spooler 54 onto files 56 where the event clusters 38 are queued for processing by an analyzer 58. The analyzer 58 includes a decoder 60 that extracts and reformats each event 34 into reformatted event 35. Next, the reformatted events 35 are processed by a correlator 62, which correlates each reformatted event 35 for inclusion within a stack 64 of other related events 35. Finally, the newly received event 35 and the event stack 64 are forwarded to an action block 66 for the generation of productions and the performance of semantic actions. The external host 50 further includes a control application 68 for communicating control information with the acquisition block 36 via the control channel 46.

Upon receipt of each event cluster 38, the decoder 60 must extract and decode the individual events into a format that is recognizable by the correlator 62 and the action block 66. Referring now to FIGURE 5, there is shown a schematic depiction of the decoding procedure in accordance with the present invention. The decoder 60 is automatically generated (for example, C++ code) by a decoder generator 72 from a data description language (DDL) specification file 70. The decoder 60 extracts information (from fields 39) from each event 34 contained in the received event cluster 38 and reformats the data into a decoded event 35. The decoded event 35 includes an event type identification field 74, which permits the correlator 62 to distinguish among different event types, and a plurality of data fields 76 containing an array of complex data (integers and/or pointers to complex data structures) relating to the event 34 (for example, extracted from the fields 39). At least one data field 76 contains an event key, which is an identifier for a mobile station, base station, or other entity or node with which the event is associated. For example, the event key might be a mobile telephone number or a mobile switching center identifier (MSCID). One of the fields 76 can include a time stamp. Some of the data fields 76 can be empty (i.e., they can contain a null value).

For purposes of monitoring faults and collecting statistics, the present invention relates to a method and system for correlating asynchronous events, preferably on a per-call basis, and for recreating a sequence of the correlated events.

Specific example is made herein to correlation on a per-call basis, but the invention is not so limited in application. It will be understood that correlation may be made on any one of a number of attributes including: on a per-call basis; on a per-cell basis; on a per-mobile identification basis; on a per-mobile type basis; on a per-base station basis; and on a per-time interval basis. Using the invention, it is possible to easily extract selected information from the events and to collect statistics by performing calculations on two or more events that relate to a particular call (i.e., correlated attribute). This result can be achieved using an LR(n) parsing algorithm to rebuild event sequences for each call/attribute. Referring now to FIGURE 5 , there is illustrated a detailed block diagram of the analyzer 58 in accordance with a preferred embodiment of the present invention. After an event 35 is decoded 60, a hashing value is calculated (e.g., by the correlator 62) for the event 35 from the event key. In this regard it is important to recognize that two items identify each event: the event key used to find the proper LR client and event type which is used by the LR server (following reaching the correct LR client) in order to perform the proper action. The event 35 is then forwarded to an entry 79 in a hashing table 80 that corresponds to the calculated hashing value. In this way, each entry in the hashing table is a pointer to an unsorted list of LR clients 82. Next, it is determined whether an LR client 82 has been created for the entity identified by the event key value, which, in a preferred embodiment, corresponds to a particular call or mobile subscriber. Thus, the hashing table scheme is used to sort events on a per-call basis. If an LR client 82 has been created for the event key value, then the event 35 is sent to that LR client 82. If, on the other hand, no LR client 82 exists for the event key, then a new LR client 82 is started and the event 35 is sent to the new LR client 82. Subsequent events 35 having the same event key are sent to the same LR client

82. Events 35 are sorted on a per-call basis such that there is a single LR client per call. The events for each LR client 82 are then forwarded, along with other information stored in the LR client, to an LR server 84. While each LR client 82 contains data relating to an individual call, the LR server 84 contains methods and data that are common to all of the LR clients 82. Put another way, each LR client 82 utilizes the LR server 84 methods and common data (where tokens correspond to the event types). In particular, the LR server 84 processes data in the LR clients 82 according to grammatical rules (as discussed above) for call procedures in the system 2. The methods and data (for example, C++ code) used by the LR server 84 are automatically generated by an LR code generator 86 from an Acquisition Description Language (ADL) specification file 88, which defines the grammatical rules used for the overall system. In the case of a telecommunication system, for example, the grammatical rules might represent various expected sequences of events for calls. Although the LR client 82 and LR server 84 are depicted as separate blocks, they can also be implemented as separate functionalities in one processor or device. In this regard, the LR client and LR server are in reality located in the same process where the LR client contains LR data related to a particular call and the LR server contains all the common data and parsing methods.

Referring now to FIGURE 6, there is illustrated a more detailed block diagram of the LR client 82 and LR server 84 configuration in accordance with a preferred embodiment of the present invention. Each LR client 82 contains a current parsing stack 90 that stores information relating to the current state of the LR client 82. In particular, each entry in the parsing stack 90 will typically contain either data relating to an event 35 or data relating to a sub-procedure (i.e., a production), which results from the occurrence of two or more events 35. For purposes of understanding and describing the invention, however, sub-procedures or productions can simply be thought of as higher level events 35.

Referring now to FIGURE 7, there is shown a schematic representation of an entry 100 in the parsing stack 90 of FIGURE 6. The entry 100 includes an identification field 102 that can contain an indication of an event type or a production sub-procedure identifier, depending on the type of data contained in the entry 100. The entry 100 further includes a data field that stores data pertaining to the event 35 or sub-procedure. Returning again to FIGURE 6, the LR client 82 further includes a semantic action object 92, which contains the context of the user defined actions that are to be performed on, or that use, the data stored in the LR client 82. The reason for this is that the user will define the same actions for each LR client (i.e., each call), but depending on the call the context will be different, and therefore there is a need to differentiate between those contexts by storing them in different LR clients. In this case, the user is, for example, a network operator, telecommunication service provider, or other user of the monitoring system. Each LR client 82 includes a semantic action object 92 that is one instance of a general monitoring class. The various LR clients 82 in the external host 50 can contain different instances of semantic action objects 92.

Essentially, the content and operation of the semantic action object 92 is selected entirely by the user according to the desired actions to be performed (e.g., calculating quality statistics, monitoring faults, sending information to a database, etc.).

When the LR client 82 receives a new event 35, the current parsing stack 90, the new event 35, and the semantic action object 92 are sent to the LR server 84 (as indicated by the right pointing arrow). The LR server 84 operates using a standard LR parsing algorithm on these three items according to existing procedures using a goto matrix 94, an action matrix 96, and a production list 98, which collectively are used to perform the operations defined by the grammatical rules. When the new event 35 results in the firing of a production, the LR server 84 also calls a function in the semantic action object 92 that is associated with that production. In other words, the semantic action object 92 defines actions that are to be performed when certain productions fire, such as calculating statistics from the data associated with the events 35, sending data to an external memory, and/or storing portions of the data contained in the event or preceding production entries 100 in a new production entry 100 of the parsing stack 90. The function call to the semantic action object 92 has as its input a production identifier and the events that led to the firing of the production. The LR server 84 also updates the parsing stack by removing the events and/or preceding productions from the parsing stack 90 and replaces them with a single new production entry 100 each time a production fires. It should be noted that only the events and/or results of the productions that are part of the production that currently fires (i.e., the elements that are required by the production) are removed from the stack. This removal of elements from the stack is called a reduction. On the other hand, if a newly received event 35 does not cause a production to fire, the LR server 84 simply updates the parsing stack 90 by adding the new event 35. In either case, the LR server 84 then returns an updated parsing stack 90' to the LR client 82 (as indicated by the left pointing arrow).

In this scheme, the LR client 82 contains information that is specific to the corresponding call, while the LR server 84 is stateless and contains the grammatical information that is generic to all calls. In addition, the LR server 84 executes a parsing scheme that is generic (i.e., the LR server 84 simply performs operations defined by the current grammar and the received semantic action object 92) in that it defines one or more expected structures of events without regard to the type of analysis to be performed. In performing these functions, the parsing scheme is concerned only with the identification field 102 of each new event 35 and of each event or production entry 100 in the parsing stack 90. The semantic action object 92, on the other hand, operates only on the information in the data field 104 of the entries 100 based on the particular production that fires.

As an example, the scheme might be used to calculate a signal to noise ratio for a particular radio connection. First, the LR client 82 receives an event 35 that is identified as a carrier signal measurement and that contains measurement data. As a result, the event 35, the current parsing stack 90, and the semantic action object 92 are sent to the LR server 84. It is assumed in this example that the received event 35 does not cause a production to fire. Accordingly, the LR server 84 adds the event 35 to the parsing stack 90 and returns the updated parsing stack 90' to the LR client 82.

Subsequently, the LR client 82 receives another event 35, which this time is identified as an interference measurement containing measured interference data.

Again, the event 35, the current parsing stack 90 (as updated in the previous iteration), and the semantic action object 92 are sent to the LR server 84. Here, it is assumed that the interference measurement event combined with the carrier signal measurement event cause a production (called, e.g., a signal quality measurement sub-procedure) to fire. As a result, the LR server 84 calls the semantic action object 92, which is simply an application code written by a user for use in one or more LR clients 82. The function call to the semantic action object 92 includes the two initiating events 35 and causes the semantic action object 92 to execute a method corresponding to the production. In this example, the corresponding method is a process for calculating the signal-to-noise ratio, which returns a calculated value. The updated parsing stack 90' returned by the LR server 84 then includes an entry 100 identifying the production in the identification field 102 and containing the calculated signal-to-noise data in the data field 104. Generally, the entries 100 for the initiating events 35 are removed from the parsing stack 90 when the production occurs.

Referring now to FIGURE 8, there is illustrated an alternative representation of the LR client 82 and LR server 84 functionalities in a accordance with the present invention. Events 35 are received by an LR(n) engine 106, which performs operations on the received events 35 and on items in the execution stack 90 based on the state of the items (as indicated at 102) using the procedures defined in the goto matrix 94 and action matrix 96. In addition, the LR(n) engine 106 further performs specified semantic actions (as defined in an action related functions portion 108 of the parsing table) using semantic information 104 contained in the execution stack 90. -

Accordingly, the LR(n) engine outputs results (as indicated at 110) in accordance with the semantic action objects 92.

Referring now to FIGURE 9, there is illustrated a flow diagram of a method 120 for processing and monitoring events 35 in accordance with a preferred embodiment of the present invention. At step 122, a new event 35 is received, and the event is decoded at step 124. Next, at step 126, it is determined whether the event correlates with an existing client 82 in the system. If so, then the event is sent to the existing client at step 132. Otherwise, a new client is generated and the event is sent to the new client at steps 128 and 130, respectively. When a new event is received by the client, the client sends the new event along with a parsing stack containing previous event data that is specific to that client to a server at step 134. At step 136, the server determines whether the new event 35 causes a production to fire. If not, the event is added to the parsing stack at step 138, and the method begins waiting to receive another event at step 122. If the event does cause a production to fire in the server, a semantic action associated with the production is performed at step 140. The parsing stack is then updated at step 142 in accordance with the production and the semantic action. Finally, at step 144 it is determined if the update to the parsing stack, in which the production acts as a new event, causes another production to fire. If so, then the process returns to step 140 to perform a semantic action associated with the production. Otherwise, the process begins to wait for the receipt of a new event at step 122.

Although preferred embodiments of the method and apparatus of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it is understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications, and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A telecommunication system, comprising: at least one event generating node, each event generated by the at least one event generating node including data relating to a particular occurrence in the system; an event analyzer for processing events in the system, said event analyzer comprising: a client database containing a plurality of clients, wherein each client stores a parsing stack containing a correlated set of the events and defines at least one semantic action to be performed in response to the correlated events; an event processing server for reconstructing event sequences from the correlated events in each client based on sequencing rules that are common to all of the clients in the event analyzer and for initiating, in response to a particular event sequence, a semantic action defined by the client, wherein the semantic action corresponds to the particular event sequence and uses data from the events that compose the particular event sequence, said event processing server further updating the parsing stack in response to the event sequence.

2. The system of claim 1 , wherein the correlated events are correlated on a given attribute basis.

3. The system of claim 2, wherein the correlation on the given attribute basis is selected from the group consisting of: correlation on a per-call basis; correlation on a per-cell basis; correlation on a per-mobile identification basis; correlation on a per-mobile type basis; correlation on a per-base station basis; and correlation on a per-time interval basis.

4. The system of claim 1, wherein the event generating node comprises a telecommunication switch, each event comprising an event occurring during a call.

5. The system of claim 1, wherein each correlated event in the parsing stack includes an identification of an event type and the data relating to the event.

6. The system of claim 5, wherein the event processing server reconstructs event sequences using the event type identifications for the events in the parsing stack.

7. The system of claim 6, wherein the event processing server removes the events that compose an event sequence from the parsing stack and adds to the parsing stack a higher level event that corresponds to the event sequence.

8. The system of claim 7, wherein the semantic action defines a set of data associated with the higher level event to be stored in the higher level event entry of the parsing stack.

9. The system of claim 1, wherein the an event processing server reconstructs event sequences from the correlated events using an LR(n) parsing algorithm, with each token corresponding to an event.

10. A telecommunication system, comprising: a switch for routing calls in a network, said switch reporting events that occur in connection with at least one application running in the network; a processor for monitoring reported events in the network, said processor comprising: a correlator for correlating the reported events, wherein the reported events are correlated on the basis of at least one shared attribute; a plurality of clients, each client for storing information relating to a particular set of correlated events, said information including a parsing stack containing events and/or intermediate production results for that client and a semantic action object defining at least one semantic action to be performed in connection with the events for that client; a server for executing a parsing algorithm to reconstruct a sequence of events for a particular client, said event sequence reconstructed using events listed in the parsing stack and a received event for the client, said server updating the parsing stack and initiating, in response to a reconstructed event sequence, at least one semantic action that corresponds to the event sequence and that is defined by the semantic action object stored in the particular client.

11. The system of claim 10, wherein the correlation by the correlator of the reported events on the basis of at least one shared attribute comprises correlating the reported events on a per-call basis.

12. The system of claim 11 , wherein the reconstruction of the sequence of events by the server comprises reconstructing at least a portion of a call sequence.

13. The system of claim 10, wherein the at least one semantic action specifies a procedure for calculating call-related statistics.

14. The system of claim 10, wherein the at least one semantic action specifies a procedure for recording call-related data.

15. The system of claim 10, further comprising a decoder for decoding the events received from the switch.

16. The system of claim 10, further comprising an interface for sending events from the switch to the processor.

17. The system of claim 10, wherein the parsing algorithm performs an LR(n) type of parsing.

18. A method for processing events in a telecommunication network, comprising the steps of: detecting a plurality of events; correlating the events on a per-call basis; sending each correlated event to a corresponding client entity, each client entity storing a parsing stack containing previously received events for the client and storing a semantic action object defining at least one action to be performed for the client in response to a particular sequence of events; detecting an occurrence of an expected sequence of events from the previously received events contained in the parsing stack and a newly received event; performing a function defined by the semantic action obj ect in response to the detected sequence of events, said function corresponding to the detected sequence of events; updating the parsing stack in response to the detected sequence of events; and storing the updated parsing stack in the client entity.

19. The method of claim 18, wherein the step of updating the parsing stack, comprises: removing the events that compose the detected sequence of events from the parsing stack; and adding a higher level event representing the detected sequence of events to the parsing stack.

20. The method of claim 19, further comprising the step of generating a set of data for inclusion in the higher level event, said set of data generated from data contained in each of the events that compose the detected sequence of events.

21. The method of claim 18, wherein the occurrence of the expected sequence of events is detected using an LR(n) parsing algorithm, where the events correspond to tokens.

22. The method of claim 18, further comprising the steps of determining whether a client entity exists for each correlated event and, if a client entity does not exist for the correlated event, creating a client entity that corresponds to the correlated event.