NO338023B1 - Data processing in a mediation or service supply system. - Google Patents

Description

Data processing in an intermediary or service supply system

Technical area

The present invention is related to data processing.

More specifically, the present invention is related to the processing of structured data registers that contain data fields and data in the data fields. An example of such a data register is an event register which contains data about the use of a communication network.

Herein, an embodiment of the present invention relates to methods and systems for mediation. Mediation is a process in which application data is collected from communication networks and delivered to the operator's operations and enterprise support system(s)

(Operation and Business Support System(s)) (OSS/BSS). Mediation software collects application data from the network by setting up an interface between various different network elements. The dissemination layer then collects, correlates, enriches, validates, formats, and/or evaluates data so that it is readable by the OSS/BSS system(s) that is the target, and contains all the necessary information.

In modern telecommunications networks, there is a demand for handling events as soon as data is available in the network. Continuous streaming media, which is also called real-time media, has been developed to meet these requirements. Especially in continuously flowing communication, quality, reliability and efficiency of data processing are very important.

In modern telecommunications networks, there is also a need for easy adaptation of the system to offer new services and to process the event registers according to changing processing requirements. The above-mentioned purposes are often at odds with each other: simple adaptation of the system tends to reduce the throughput, while, on the other hand, a system that has an optimized throughput usually requires intensive work to be reconfigured.

Another embodiment of the present invention relates to systems and methods for dissemination. Service provisioning and service activation is a process in which any type of service in any type of network is provided and activated to network elements. These could be, for example, enabling all consumer and community services, such as voice, ADSL, WLAN access and VPN which, with the same supply system, help the operator to remove many costly, unnecessary and overlapping processes.

Background fabric

Patent publication US 6,449,618 proposes a real-time system for event processing. The system presented in the publication has poor flexibility.

Bedichek RC: Talisman fast and accurate multicomputer simulation, 1995

"ACM SIGMETRICS JOINT INTERNATIONAL CONFERENCE ON

MEASUREMENT AND MODELING OF COMPUTER SYSTEMS", Ottawa, May 15 - 19, 1995, describes a system and method for processing data records according to a predefined logic, including a data field table containing fields for creating data during processing in the system, a logical definition structure containing the predefined logic contained in the logical definition structure, wherein the logical definition structure comprises, a the parameters containing pointers to data fields to store values from the parameters necessary in the predefined logic, a function code set containing program codes to perform functions necessary in the predefined logic, and a series of bytecode instructions containing a function pointer pointing to a function code in the function code set to be used in the execution of the instruction, and a pointer pointing to a set of parameter pointers in the parameter table needed in the execution of the instruction.

The patent publication US 6,166,657 proposes a system for supporting and handling telecommunications services. The main idea in US 6,366,657 is that the system includes a Service Creator Environment (SCE), which environment makes it possible to easily create, provide and manage new services for subscribers. This is done with tool folders to specify object definitions in an object-oriented framework. The system presented in the publication is aimed at telecommunications operators to make services easier.

There are two alternative ways to develop the known systems further in an attempt to combine efficiency and ease of modification and handling.

The first option would be to generate some scripting language from the predefined processing logic. A suitable scripting language is Perl. The advantage of this approach is that the resulting code can be inspected and is human readable. Hence, the code is easy to debug. However, there are several disadvantages to the scripting language approach. For example, the performance is relatively small since the scripting languages (even Perl) are slower than machine languages. It is also difficult to generate valid code and to ensure that the variable names etc. do not cause any conflicts in the system.

The other option would be to generate C or Java source code, and compile it before execution. This solution produces the fastest code, if C is used, because translation is not necessary. The problem is to compile the source code and to make sure that the system really works correctly. The logic formed in this way cannot be tested before it is put into use, if really fast changes to the logic are needed. This makes the system unreliable and risky. Compilation is also very difficult, if not impossible, because it must be performed in customer environments and on different platforms. Hence, this approach involves serious risks and is extremely difficult. On the other hand, if the problems involved in this solution can be solved, the solution will offer a very high performance.

Explanation of the invention

It is an aim of the present invention to form a reliable data processing system and method which both provides a relatively high performance and is relatively easy to adapt to new processing logic.

More specifically, the purpose is achieved as stated in the independent requirements.

The purpose of the invention has been achieved by forming a special logical definition structure based on the processing logic. The logical definition structure is designed so that it is easy to execute efficiently. The logical definition structure is also designed so that making modifications to the processing logic requires relatively limited and direct alterations in the logic definition structure. This is made possible by defining the processing logic in the form of a series of bytecode instructions, in which each instruction contains a pointer to a part of a program code that performs a function and a pointer to parameters to be used in the execution of the function. The instructions, the program codes that perform the functions, the pointers and the data being processed are stored in tables, thus allowing the use of efficient pointing mechanisms along with flexibility and easy modification. The logical definition structure then includes a parameter table containing pointers to the value of the parameters needed in the processing logic, a function code set containing program codes to perform the functions needed in the processing logic, and a series of bytecode instructions, each of the instructions pointing to pointers in the parameter table and a function code required in the execution of the instruction.

The present invention makes it possible to construct a reliable data processing system and method which both provide a relatively high performance and are relatively easy to adapt to new processing logic.

The inventive concept also allows for several useful and advantageous embodiments that provide additional advantages.

In one embodiment of the invention, adaptation of supply logic can be implemented and visualized through a graphical user interface. New services and service packages - regardless of their complexity - can be quickly introduced without having to perform time-consuming and costly changes to the OS S/B SS system of an operator.

The invention also offers embodiments of a mediation system that can be operated continuously once it has been started, because all configurations can be performed while the system is in production.

There are also embodiments that allow both batch-type processing and real-time event log processing.

It is clear from the explanation above that the present invention can be used with a wide variety of applications that require fast and reliable processing of event registers.

Brief description of drawings

For a more complete understanding of the present invention and its advantages, the invention is now described by means of the examples and with reference to the following drawings, in which: Figure 1 presents a block diagram of a system according to an embodiment of the invention. Figure 2 presents a block diagram of an example of a function according to an embodiment of the invention. Figure 3a presents a block diagram of an example of an embodiment of execution of a function for processing logic according to an embodiment of the invention. Figure 3b presents a block diagram of another example of performing the execution of a function for processing logic according to the invention. Figure 4 presents a block diagram of an example of an execution of byte code according to an embodiment of the invention. Figure 5 presents a flow diagram of an example of a mediation process according to an embodiment of the invention.

Definitions

Data register:

A data register is a register that contains data about, for example, service use or supply requests. A data register typically contains several data fields and can be structured (registers contain other registers). In communication systems, examples of data records would include such as CDR, call detail record (Cali Detail Record); ER, event record (Event Record); UDR, usage data record (Usage Data Record); and IPDR, internet protocol detail record (Internet Protocol Detail Record).

Field:

A field is a simple unit in a data record. Normally, a field contains a value that can be any data (date, integer, string, etc).

Event:

An event is a transaction that occurs in a telecommunications network. Incidents are typically caused by actions taken by a subscriber while using telecommunications services. Events may also be based on actions performed by the telecommunications network or a device connected to it, for example during the performance of telecommunications services. Some events may even be generated automatically during the execution of the service program and perform other functions to provide services to the customers.

Event register:

An event register is a data register that indicates that an event has occurred. That is, an event register provides information that a subscriber has used a telecommunications service. An incident register also contains detailed information about the incident. Hence, an event register can contain information about use, for example if the telecommunications service used is a telephone call, the event register can indicate how long the call lasted, or if the service is to download a file from an FTP server, the event register can contain information about the size of the transferred the data block.

Real time:

In contrast to batch processing, real-time processing refers to sending a record of events through the dissemination system in streaming format. That is, as soon as a specific node in the dissemination stream has processed (for example enriched) the register, it is forwarded to the next node. In batch processing, a large number of event registers are first collected in an intermediate storage, and then the quantity of event registers is processed from the intermediate storage. Hence, in batch processing, processing delays experienced by the event registers are typically very long and vary between event registers. In real-time processing, processing delays experienced by the event registers are typically short and essentially of the same size between event registers.

Throughput time in a real-time system can be, for example, from about 1 millisecond to 10 seconds. In some embodiments, events can pass through the system even faster. Sometimes, depending on the embodiment and application, the term real time may also include throughput times longer than expressed above. In general, a real-time service is a service that does not include significant delays as judged by a user of the service as actions performed, and services provided essentially at the time the services are ordered (ie, events added to the mediation system).

Input Register:

A data register read by a processing node. The format and structure of the input register is preferably predefined and known by the node.

Output Register:

A data register written by a processing node. The format and structure of the output register is predefined and known by the processing node.

Processing logic executor:

A processing logic executor is a node application in a mediation system. A processing logic executor handles predefined processing logic in a processing stream. It executes the user-defined ruleset using existing rule prototype functions.

Node base:

A nodebase provides an interface for reading input registers and writing output registers. A processing logic executor receives field values using the name of the field from the node base. The node base implements the functionality of operations such as creating a new output register and rejecting an existing register.

Function: (- arrows in figure 2)

An arrow or actually a group of arrows pointing to a single field representing a function. A function is a prototype of a processing rule, such as field validation, value comparison, or conversion.

Function code:

A function code is a program code to perform a function required in the predefined logic. In a preferred embodiment, the function code is a binary code directly executable by an operating system. The code uses function parameters for decisions that need to be made during function execution.

Instructions:

An instruction is a simple unit of bytecode for processing logic. In a preferred embodiment, an instruction contains a pointer to the function code, pointer to the function parameters and the number of parameters. Instructions are formed during compilation process.

B<y>tecode Executor:

A bytecode executor is the component that takes care of instruction fetching, decoding and execution. Hence, the bytecode executor takes the next instruction from the table and calls the function of the instruction using the instruction's parameters.

Shared library files:

Shared library files contain function code for both core and custom functions. The code is produced by a C compiler and is fast to execute. The functions are loaded into memory from the files when the processing logic executor is started.

Best way to carry out the invention

Figure 1 shows an example of using an embodiment of the invention. The system in Figure 1 includes a graphical user interface 1 (GUI) for defining the predefined processing logic according to which the user wants the system to process the data registers, such as event registers in a communication network. The GUI 1 produces a predefined processing logic file 2 containing the predefined processing logic and takes care of storing data in a persistent store, such as database 3. In the embodiment, the predefined processing logic file 2 contains an XML representation of the logic built with the GUI 1.

The system includes a compiler 4 which uses the predefined processing logic file 2 as a source code, and builds a processing logic bytecode 5 based on the predefined processing logic. The compilation is performed each time the logic is tested or stored in the persistent store 3. The persistent store 3 holds all configurations of processing logic and the compiled bytecodes for them.

The processing logic bytecode 5 is a simple text file that describes how the predefined processing logic will be executed. It has a sequential set of instructions and their parameters. All instructions are stored using the original function names.

The system also includes a processing logic executor 6 which can be a node application that can be executed using node base. The executor for processing logic 6 includes in itself a function library 7, a bytecode parser 8 and a bytecode executor 9.

The function library 7 contains all the functions for the processing logic. In the figure, the function library 7 is divided into core functions 10 and custom functions 11.

The byte code parser 8 parses the plain text byte code 5 and produces a more efficient form of the code. The complete bytecode has no function name but direct pointers to it.

The bytecode executor 9 executes the analyzed bytecode. Hence, the byte code executor 9 acts as the logic execution device to execute the predefined processing logic. The code is executed "blindly" without knowing what the functions do.

Hence, in the embodiment, a graphical user interface may be used to set up the system to process data records according to a desired processing logic. After defining the processing logic, the compiler parses the processing logic and compiles it into a format (processing logic bytecode) that is fast and easy to execute. The compiler means reads the XML file for processing logic, forms a data structure from it, and produces a bytecode file using the data structure. The compiler removes all "useless" information that is not needed in the execution from the processing logic, flattening the structure of the logic. The compiler also reserves a field table, to which all the fields are placed. After this, the fields are no longer referred to by their names, but by the index in the table. The bytecode parser changes the index to direct memory location.

Required instructions are added to the bytecode when the compiler either encounters a function in the processing logic definition or needs to add a function for e.g. to jump from one place to another in the code. When the compiler adds an instruction it also adds the parameters of the function as a list of indices of the fields. The bytecode parser builds the parameter table using this information. After the compilation is complete, the compiler calculates the values for the bytecode header fields.

In an advanced embodiment, a user can also define and add custom functions via the graphical user interface. When adding a custom function, the system adds a new connection screen to define the function parameters in the graphical user interface. The system also adds a corresponding function code to the function code table of the processing logic executor 6. For the custom function functionality, the compiler includes a custom function extension to modify the logic definition structure to include the custom function and the parameters of the custom function in the system field tables. Figure 2 shows an example of the function of the executor for processing logic 6. In Figure 2, each arrow 10, 11 (or a group of arrows pointing to the same field) represents a function for processing logic. The processing logic executor executes, in the specified order, the bytecode generated by the compiler. Each arrow in the figure represents a process logic function that executes the action depending on the function parameters (fields).

In the embodiment, the fields 22, 32 in the input 20 and output 30 are register fields read by the node base 130. The node base 130 reads the fields 22 from an input file 20 and forms a data structure 40 for the register. Each field can be retrieved or written using the field name. The processing logic executor 6 must not read all the fields from the input register.

In the embodiment, internal fields 42 in the processing logic executor 6 are temporary fields that the processing logic executor has produced. Internal fields 42 may contain original data read from the node base 130 or data generated from the functions 10, 11. Internal fields 42 may also be constants inside the executor for processing logic 6.

In the embodiment, the processing logic executor 6 allocates memory to all temporary fields 42 in the initialization phase to make execution more efficient. The fields grow automatically during execution if necessary. The fields read from the nodebase do not need any space (the nodebase takes care of that), and they cannot be modified inside the executor for processing logic.

In the embodiment, the fields can be mapped directly from the input register 20 into the output register 30 without modifying the field or using it for other fields.

In the figure, each arrow 10, 11 (or a group of arrows pointing to the same field) represents a function in the processing logic executor 6. The function can be, for example, string concatenation which takes two input fields and produces an output field. The byte code for processing logic 5 consists of pointers to these functions 10, 11 and their parameters.

Figure 3 shows two examples of function executions of processing logic in an embodiment of the invention. In the embodiment on the left (Figure 3a), there is an example of a base function that takes four input fields 22, 42 and produces two output fields 32, 42. In the embodiment on the right (Figure 3b), an example has a function that takes three input fields 22, 42 and does not produce any output fields, but modifies the program counter 17 according to the field values.

In the embodiment, the instructions 62 in both examples in Figure 3 are pointers to function codes 12. Function code 12 only exists in memory once even though there are many instructions 62 that use it. The byte code executor 9 always executes the instruction 62 to which its program counter 17 points. The byte code executor 9 increases the program counter 17 by one after each function call.

In Figure 3b, the example shows how a function can update the program counter. For example comparison functions, unconditional jump etc. modify the program counter. This means that the execution "jumps" to different places in the code.

In the embodiment, the processing logic executor 6 receives its entire configuration in node application parameters and in bytecode files 5. Node application parameters include all predefined specific processing logic parameters and settings of the processing logic executor. Breakpoints in the bytecode and other debugging parameters are set using the node parameters if necessary. These parameters are used, for example, in debug mode. Figure 4 shows an example of a byte code executor 9 according to an embodiment of the invention. In the embodiment, the bytecode executor 9 retrieves an instruction 62 at some point in time. A simple instruction 62 contains three parts: function pointer 70, number of parameters 80 and pointer-to-parameters 90 of the instruction 62. Figure 4 describes how a simple instruction 62 is handled in the byte code executor 9. Each instruction 62 consists of the following parts: • Function pointer 70 - The function pointer points to the relevant function code 12 that is used in the execution of this instruction 62. • Number of parameters 80 - The function can use a different number of parameters 52 depending on the use of the function. For example, a value comparison function can take 3-N parameters depending on the number of values to compare. • Pointer to parameters 90 - The pointer to parameters points to the parameter table 50 which contains all parameters 52 needed throughout the predefined processing logic. All the parameters 52 in this instruction 62 are one after the other in the table 50. The pointer 90 refers to the first parameter 54 and the number of parameters 80 tells how many of them are to be used. The parameter list can contain both input and output parameters.

In the embodiment, the function receives both the number of parameters and the pointer to the parameter list as function arguments.

In the embodiment, the bytecode executor 6 handles the execution of the bytecode 5. The execution is performed blindly, without thinking that the functions are executed. The byte code 5 is divided into three different parts: initialization, processing and stop part. Bytecode execution is a straight-forward task: 1. Fetch the next instruction from the instruction list (the one referenced by the program counter). 2. Call the function in the statement using parameter count and parameter pointer as function parameters.

3. Check if the execution has reached the end of the instruction list.

a. If not, increase the program counter by one and skip to part 1

b. If execution has reached the end, return from the process function and return control to the node base.

The processing logic executor in the above described embodiment is a very flexible component. The user can program new custom functions into the system without modifying the existing implementation. This makes it possible to form even very complicated logic using processing logic and to make customer-specific modifications to the system, if necessary, without affecting performance.

The processing logic executor in the above-described embodiment also provides high performance. The interpretation overhead is minimal in this implementation which means that running logic with the processing logic executor is almost like running a machine code program specifically programmed for the customer's logic.

The processing logic executor in the above-described embodiment is also highly modular and therefore easy to test. Each function is an independent software component that can be tested with an automated tool. This will save costs in porting the product and make it easier to implement new functionality into the system.

In the embodiment of the invention, the byte code for processing logic 5 is stored in a plain text format to avoid problems with porting from one platform to another. The bytecode contains the following components: • Header - The header contains detailed information about the predefined processing logic. • Fields - This section contains instructions for creating the field table. It lists all fields, their lengths and initial values.

• Instructions - This section lists the instructions and their parameters.

In the embodiment of the invention, the bytecode parser 8 takes care of reading the bytecode file 5, parsing it into internal structures and pre-formatting fields. The internal structures include the following components: • Data field tables 40 - The fields are stored in two tables: one containing all integers and another containing all strings. The fields are read and initialized. Initialization includes memory allocation and setting of value, if necessary. • Instruction table 60 - Instructions are stored in a long table. They are stored there as described in the design of the bytecode executor for processing logic.

In the embodiment of the invention, the functions for processing logic 10, 11 are tested with an automated test tool. The main idea is that the function developer creates some test data in a text file in a defined format, and executes the test cases.

The automated test tool uses the processing logic function library 7 to load the functions 10, 11 defined in the test case file. No coding is required for the tests.

An embodiment of the invention belongs to the processing of data registers in communication systems with communication networks. Sophisticated mediation solutions have several beneficial characteristics, the most important of which are described below.

In Figure 5, each node 120 includes a node base 130 and a node application 140. The node base 130 provides the basic standard functionality for the node 120. It handles the internal sending mechanism for data usage between the nodes 120 and encodes the internal usage data. The node base 130 provides an interface to the node application 140 to access application data and gather custom comparison information. To perform its task, a node base 130 may include several components, such as a node input 131, a node output 132, a node API 133, a node configuration 134, and a node comparison 135.

A node input 131 is responsible for reading data, input registers 20, from the internal input data sources, parsing them and sending data to the node application interface. A node input uses the data transfer interface that defines the internal data format and mechanism for data transfer.

A node output 132 is responsible for reading data, output registers 30, from the node application interface, encoding and writing it to the data transfer interface. A node output uses the data transfer interface which defines the internal data format and mechanism of data transfer.

Node API 133 gives the node application access to application data. It "hides" from the internal data transfer interface from the node application 140. The Node API includes the functionality to obtain application data to and receive it from the node application 140. It is also used to retrieve custom comparison information from the node application 140 and to provide configuration parameters to it. .

The node configuration 134 is responsible for reading configuration data from the configuration interface and for initializing the node according to given configuration parameters. The node configuration also passes node application specific parameters to the node API. The node configuration uses the configuration interface which defines the configuration data format and the transfer mechanism. The node compare 135 is responsible for writing different compare data to the compare interface. The node comparison defines content to comparison interfaces. The node comparison uses comparison interface which defines standard data format for comparison and transfer mechanism. The node comparison also uses handler interfaces that define monitored data format and transfer mechanism. It is used, for example, to indicate the node's status.

The data transfer and/or buffering interface 145 defines the data format for use and the mechanism for data transfer between the nodes.

Dissemination consists of various processes such as collection, approval, enrichment, accumulation, correlation, assessment, conversion and delivery. The varied functionality allows the OSS/BSS systems to receive application data as they want it.

The keywords of the solution architecture for dissemination are simplicity and directness. The modular design of the solution according to an embodiment of the invention enables real-time and distribution processes, reliable operation and high performance.

Node (distribution process)

The nodes 120 are functional components specialized in various dissemination processes, such as collection, accumulation, validation, correlation and formatting, or a combination of these. The nodes are connected to form processing streams for handling event registers.

Each node 120 has standard functionality that provides automated

data transfer mechanism between the nodes, and process information logging mechanisms between the node and the node handler (not shown in the figure). The actual application data processing logic is implemented by various applications 140 located in the nodes. These applications 140 are isolated from internal mechanisms for data transfer and internal data formats that enable easier

application development. The applications 140 are drawn as ovals in the presented figure 5. The system provides a standard interface through which the applications communicate with the framework for processing.

The nodes 120 can further be categorized according to their functionality. The functionality is dependent on the node application 140 and the node's position in the processing chain 200. The first node 120 in a processing chain may be called a collection node and the last node a distribution node. In these cases, the data parsing and formatting functionality needs to be performed by the application 140 itself and the standard functionality, provided that the node base 130 is not used. The flow of application data and the standard components that become redundant are shown in Figure 5. In this picture, it is assumed that the data source 210 and the destination 220 both operate with a real-time protocol, i.e. they use a connection link to send and receive data.

If the destination for output data 220 requires the use of a file-based interface, the applications take care of formatting and writing data in the output files. In cases like this, it may be necessary to separate the generation of the output files and the delivery of the output files to separate nodes 120.

In one embodiment of the present invention, the processing logic executor 6 represents an example of a node application 140 used in mediation systems.

Claims (36)

1. A mediation system for processing event registers according to a predefined logic, where an event register is a data register that indicates that an event has occurred and contains detailed information about the event, where the event is a transaction that occurs in a communication network, where the mediation system includes interfaces with network elements in the communication network for collecting consumption data from the communication network, means for delivering consumption data to an operator's operational and business support system, and at least one node including a system for processing event records adapted to aggregate, correlate, refine, validate, format and /or rank data in the event registers so that the data is readable by the operator's operational and business support system characterized in that the system for processing event registers includes: data field tables (40) for storing data during processing in the system, where the data field tables (40) contain data fields for storing values for the parameters necessary in the predetermined logic, data fields for storing values read from a data register during processing, and data fields for writing output from functions necessary in the predetermined logic, where the data fields are stored in a first and a second table, where the first table contains integers and the second table contains strings, a logical definition structure including: - a parameter table ( 50) containing pointers to the data fields to store values from the parameters required in the predefined logic, - a function code set containing program codes to perform the functions required in the predefined logic, and - a series (60) of byte code instructions (62) built by a compiler (4) from a file (2) containing the mock ddetermined logic, in which each bytecode instruction (62) contains: - a function pointer (70) pointing to a function code (10, 11, 12) in the function code set to be used in the execution of the instruction (62), - a number of parameters (80) , and - a pointer-to-parameter (90) pointing to a first (54) in a sequence of parameter pointers (52) in the parameter table (50) necessary in the execution of the instruction (62), and a logical execution device (6 ) configured to process event registers according to the predefined logic by executing a sequence of bytecode instructions (62) contained in the logical definition structure, where each bytecode instruction (62) is executed by calling the respective function code (10, 11, 12) in the function code set using the respective function pointer (70) and using the respective number of parameters (80) and the respective pointer-to-parameter (90) as function parameters. 2. The system according to claim 1, configured to receive registers for input data (20) having a specified form with data fields and values in said data fields. 3. The system according to claim 1 or 2, configured to produce registers for output data (30) having a specified form with data fields and values in said data fields. The system according to any one of claims 1 to 3, wherein the pointers to data fields in the parameter table (50) are direct pointers to memory locations of data fields in the data field tables (40). 5. The system according to any one of claims 1 to 4, wherein while the system is in operation and processing a data register, the values stored in the data field tables (40) contain: - values for the parameters of the predefined logic, and - values from the data register under processing, and when the processing is finished, the values stored in the data field tables (40) also contain: - values for the output of the process, and - at least some intermediate values, if these were necessary in the processing of the data register. 6. The system according to any one of claims 1 to 5, wherein each pointer (52) in the parameter table (50) points to a single data field in the data field tables (40). 7. The system according to any one of claims 1 to 6, wherein the system contains at least two different pointers (52) pointing to a common data field in the data field tables (40). 8. The system according to any one of claims 1 to 7, wherein the function code set contains a function having a number of parameters and another function having a different number of parameters. The system according to any one of claims 1 to 8, wherein the feature code set is dynamically extensible. 10. The system according to any one of claims 1 to 9, wherein the program code in the function code set is in the form of binary code directly executable by an operating system. 11. The system according to any one of claims 1 to 10, wherein the construction of the parameter table (50) is such that each set of parameters required in the execution of the bytecode instructions (62) is formed from subsequent parameters in the parameter table (50) . 12. The system of claim 1, wherein the pointer-to-parameter (90) contains a pointer to the first parameter (54) and a number of the parameters (80) necessary in the execution of the bytecode instruction (62). The system according to any one of claims 1 to 12, wherein the function pointer (70) and pointer-to-parameter (90) are in the form of direct pointers pointing to memory locations. 14. The system according to any one of claims 1 to 13, in which the logic execution means includes: - a program counter (17) pointing to a byte code instruction (62) in the series (60) of byte code instructions, - means for resetting the program counter (17) so that the program counter points to the first byte code instruction (62) when the logical execution device starts processing a new data register, and - means for setting the program counter (17) to point to the following byte code instruction (62) after each function call . 15. The system of claim 14, wherein at least one function code (10, 11, 12) in the first function code set includes program code means for changing the value of the program counter (17). 16. The system according to any one of claims 1 to 15, including - a graphical user interface (1) for defining the predefined logic, - a compiler (4) for compiling the predefined logic to produce a series (60) with bytecode instructions (62) and the parameters of said instructions, and - a bytecode parser (8) for parsing the series (60) of bytecode instructions (62) to form the logical definition structure including the instructions in the form of function pointers (70) and pointers to parameters ( 90). 17. The system according to claim 16, including functionality to add a custom function to the function code set, and to affect said functionality: - means for displaying a screen in the graphical user interface to define the parameters of the custom function, and - a custom function extension in the compiler to modify the logical definition structure to include the custom function and parameters of the custom function 18. The system according to any one of claims 1 to 17, wherein said at least one node includes: - a node-based (130) program device capable of providing base software functionality for the node, said base software functionality includes an external interface of the node and an internal interface of the node, - an application programming interface device for receiving application programs for the node, which application program is able to interact with the internal interface of the node, and - an application program (140), and wherein the logical definition structure is contained in the application program of the node. 19. A method for processing event registers according to a predefined logic, where an event register is a data register that indicates that an event has occurred and contains detailed information about the event, where the event is a transaction that occurs in a communication network, where the method includes: to collect consumption data from network elements in the communication network, to process event registers by aggregating, correlating, refining, validating, formatting and/or ranking data in the event registers so that the data is readable by an operator's operational and business support system, to deliver consumption data to the operator's operational and business support system, characterized by using data field tables (40) to store data during processing in the system, where the data field tables (40) contain data fields to store values for the parameters necessary in the predetermined logic, data fields to store values read from a data register during processing, and data fairy lt to write output from functions necessary in the predetermined logic, where the data fields are stored in a first and second table, where the first table contains integers and the second table contains strings, to use a logical definition structure including: - a parameter table (50) containing pointers to the data fields to store values from the parameters required in the predefined logic, - a function code set containing program codes to perform the functions required in the predefined logic, and - a series (60) of byte code instructions (62) built by a compiler (4) ) from a file (2) containing the predetermined logic, in which each byte code instruction (62) contains: - a function pointer (70) pointing to a function code (10, 11, 12) in the function code set to be used in the execution of the instruction (62), - a number of parameters (80), and - a pointer-to-parameter (90) pointing to a first (54) in a sequence of parameter pointers (52) in the parameter table (50) necessary in the execution of the instruction (62), and where the processing of the event registers according to the predefined logic includes executing a sequence of bytecode instructions (62) contained in the logical definition structure, where each bytecode instruction (62) is executed by calling the respective function code (10,11, 12) in the function code set using the respective function pointer (70) and using the respective number of parameters (80) and the respective pointer-to-parameter (90) as function parameters. 20. The method according to claim 19, in which the processed data registers have a plurality of data fields and values in at least some of said data fields, where the method comprises: - reading values from at least some of the data fields in a data register, - writing the read values in data fields in the data field tables (40), and - to process the values from the data register in the data fields in the data field tables (40) by executing the sequence of instructions (62), in which each instruction (62) in the executed sequence contains the function pointer (70) and a pointer- to-parameter (90), said processing includes executing each of the pointed function codes (10,11,12) using the values pointed to by the pointed set of parameter-value pointers. 21. The method of claim 20, wherein instructions in the executed sequence of instructions are stored in an instruction table. 22. The method of claim 21, wherein the executed sequence of instructions contains at least one subsequence of instructions, and the instruction in the at least one subsequence of instructions are located consecutively in the instruction table. 23. The method in claim 21 or 22, in which the step of processing data includes for each instruction in the sequence of instructions: - reading a program counter (17) that points to an instruction (62) in the instruction table, - retrieving the instruction pointed to by the program counter (17), - to call the pointed function and give the pointer-to parameter (90) as an argument, and - to increment the program counter (17). 24. The method according to any one of claims 20 to 23, including producing at least one output data register (30) after executing the instruction sequence, wherein the at least one output data register (30) includes a plurality of data fields and the step of producing the at least one register for output data (30) includes: - reading values in at least some of the data fields in the data field tables (40), and - writing the values read from the data field tables (40) in the data fields of the at least one register for output data (30). The method according to any one of claims 20 to 24, wherein the function pointer (70) and pointer-to-parameter (90) are in the form of direct pointers pointing to memory locations. The method according to any one of claims 20 to 25, wherein each parameter-value pointer points to a single data field in the data field tables (40) and is in the form of a direct pointer pointing to a memory location. 27. The method according to any one of claims 20 to 26, wherein the values during processing are stored in the data field tables (40), said values including the values of the parameters necessary in the predefined logic, the value read from the data register during processing, and output from the functions. 28. The method according to any one of claims 20 to 27, wherein a same parameter value is used in more than one function. 29. The method according to any one of claims 20 to 28, wherein the function codes (10, 11, 12) in the function code set are in the form of binary code directly executable by an operating system. 30. The method according to any one of claims 20 to 29, wherein said data registers are event registers in a mediation system in a communication network. 31. The method according to any one of claims 20 to 30, comprising the steps of receiving a processing logic from a graphical user interface (1) and forming the instruction sequence based on the received processing logic. 32. The method of claim 31, wherein the step of forming the sequence of instructions on the basis of the received processing logic includes: - compiling the received processing logic to produce a series (60) of bytecode instructions (62) and the parameters of said instructions, and - parsing the series (60) with bytecode instructions to form the sequences of instructions (62), wherein the instructions (62) are in the form of function pointers (70) and pointers to parameters (90). 33. The method according to any one of claims 20 to 34, wherein after processing a data register, the method includes repeating the method with another data register. 34. The method of claim 33, wherein the value from a following data register is written in the same data field table (40) to replace the values from a preceding data register. 35. A computer program product for performing the method in claim 19. 36. The computer program product of claim 35, comprising: - program code for influencing a compiler (4) usable for compiling the processing logic to produce the series of bytecode instructions and parameters for said instructions, the compiler also being usable for reserving the field tables for storing components necessary in the processing of the processing logic, said field table includes: - the data field tables (40) which contain data fields to store values necessary in the processing logic, - the parameter table (50) which contains pointers to data fields to store values of the parameters necessary in the processing logic, and - the function code set which contains program code (10, 11, 12) for performing functions necessary in the processing logic, - program code for implementing a bytecode parser (8) useful for parsing the series of bytecode instructions produced by the compiler (4) to form the logical definition structure , in which the bytecode instructions (62 ) are in the form of function pointers (70) and pointers to parameters (80) and in which the references to the fields in the field tables are in the form of direct memory locations, and - program code for implementing an execution engine (6) which is useful for processing data registers according to the processing logic by executing the series of bytecode instructions (62) in the logical definition structure.