Duplicate and sequence checking

If a duplicate checker has been added in Comptel EventLink and Comptel EventLink receives ERs from the network, it can check them for duplicates and verify their sequence. By doing this, it ensures that the numerous ERs come into the system in the correct order and that none of them is missing or delayed or tries to enter the system for the second time.

4.3.5 Aggregation

When aggregating, Comptel EventLink creates summary records from a number of input records from the same network source. Aggregation thus allows the OSS/BSS systems to receive only one billable ER from each service usage. An example of aggregation is the combining of partial record from long duration calls. After the records have been combined, over-aged ERs are flushed. Statistical data is collected according to predefined variables.

EventLink Aggregation Library is responsible for creating summary records of sessions or calls in the input data. This is done according to predefined aggregation rules (aggregation schemes). EventLink Aggregation Library uses EventLink Temporary Record Storage Library as its partial storage.

General principles of aggregation

The input records of a call or connection (events) to be aggregated are grouped together based on their event key and record type (optional). An event key is a set of one or more record fields that identify an event. The type of the input record (record type), if used, is taken from the output type audit field of the input record.

An input record that belongs to a long event (partial) is first prepared by the

aggregation library before it is sent (checked in) to be aggregated. The aggregation library collects the key fields and locates the event that matches to the event key. If a matching event was found, the incoming partial is aggregated to the existing partial event, if possible, and stored to the partial storage where it waits for the rest of the event partials to arrive. If no matching event is found, the partial is inserted to the partial storage and it is kept there for the rest of the event partials to arrive.

All event partials are kept in the partial storage. There are three ways in which the partials can be removed:

• event is completed

• event expires based on its age or its limit • partial storage is flushed

The actual rules of the event completion vary between aggregation schemes, and the only common rule of completion for all aggregations is the possibility to define a limit that is inspected at check-in time (completing limit).

If the value of the completing limited field in currently checked-in partial or the outcome of the aggregation is higher than or equal to the value defined for the limit, the event partial is completed and handed back to the business logic node during the check-in.

Another way to remove a partial from the partial storage is to have it expired based on its age (flushing). The flushing is based either on the real start time of the partial or an artificial time (reference time) that can be freely defined for each partial. If both the reference time and the start time are available, the reference time is used during the flushing.

Similarly, as there is a completing limit that is inspected during the check-in, it is also possible to define a limit for one or more of the fields in the partial that is inspected only during the flushing. With limit-based expiration, the partial is flushed when a field value equals to or exceeds the limit value even if the partial would not expire based on its age. The partial expiration requires that the partials have either the reference time or the start time defined.

When an expired or completed partial or a completed event is detected, it is removed from the partial storage and made available for the node as an output record. Some partial fields can be configured, for example, to be summed up or to contain the minimum, maximum, chronologically first or chronologically last value. All such operations have already been handled by the aggregation library during the aggregation process. The resulting values are stored in the output record. The fields that have an additional operation configured or are required by the aggregation operation are called active fields. The fields that do not have any operations configured and are not necessary from the aggregation process point of view are called passive fields. They are taken from the chronologically first partial based on time stamps.

Aggregations schemes

Aggregation Library provides four aggregation schemes: • basic aggregation scheme

• extended aggregation scheme

• time based aggregation (long call combining)

• sequence number based aggregation (long call combining)

In an aggregation scheme, a completing limit or flush time limit must be defined to send the event to charging. Expired partials can sent for charging.

The basic aggregation library scheme supports the aggregation of one event within a set of call event references. The event partials are aggregated in the order of their arrival. The partial that arrives first is used as a basis for the fields of the complete record.

In the extended aggregation library scheme, event partials are aggregated in chronological order based on their time stamps.

Long call combining is a more specific case of the basic aggregation. It has clearly

defined rules when two partials may or may not be aggregated together and when the event becomes complete during the check-in.

The leading partial of a long call is called the first partial and the very last partial that the network element creates for a long call is called the last partial. All partials between the first partial and the last partial are called intermediate partials. The creation of new intermediate partials is started each time the configurable time limit in the network element is exceeded.

Some network elements generate a running sequence number for the partials of a connection that usually starts from 1 and ranges up to total number of partial in the connection. Some network elements create repetitive first partials during a

The logic how the different kinds of partials are recognised is defined in the

equipment vendor specifications. Because of that, the logic varies from case to case. Long call aggregation schemes are able to detect and reject incoming partials that overlap with partials that have already entered the aggregation library based on overlapping time or sequence numbers of the partials. In addition, a long call aggregation scheme is also able to detect and reject incoming partials that could be aggregated with a partial in the partial storage but where conflict of partial types prevents the aggregation of the partials.

Time stamp based aggregation aggregates the partials in chronological order based

on the timestamps in the partials. The time stamp based aggregation requires that the reference time, if configured, start time and either duration or end time information exists in the partial. The scheme configuration parameter is used to define whether the existing end time of the partials is taken from the partial or whether it is calculated by summing up the start time and duration. If the required duration or end time field is missing, the check-in function returns an error indication to the node implementation. Sometimes the time stamps of the long event partials do not run in a smooth

sequence. Therefore, a value called maximum difference can be defined for the time stamps. The maximum difference tells to the aggregation library how many seconds the two partials can slip apart or overlap each other for them to be still aggregated. In addition to the reference time or the start time, the long call aggregation requires that the partials have the partial type, possible partial sequence number and duration and/or end time defined.

Sequence number based aggregation aggregates long event partials in the order of

the partial sequence numbers issued by the network equipment. Only the reference time or, if no reference time has been configured, the start time, sequence number and either duration or end time are required to be present in the partials. The sequence number flow must also be configured for the events if this aggregation method is used.

In the long call aggregation, an event may have more than one partial in the partial storage waiting to be aggregated. The event partial in the partial storage is a partial that presents a group of partials that the library has already been able to aggregate together (aggregated partial).

If a matching event is found from the partial storage at the check-in, the partials of that event are checked one by one to see if the incoming partial can be aggregated with the current partial or partials in the partial storage. If no matching event is found at the check-in, the event partial is inserted to the partial storage.

The currently incoming partial may have been a partial that is a missing link between two intermediate partials or even a missing link between the first and last partials. Because of that, the aggregation library does an iterative aggregation attempt after each successful aggregation to find out whether the repetitive aggregation or even a completion of an event would be possible.

The following presents different possibilities for aggregation:

• aggregation of a first partial and an intermediate partial results in a first partial • aggregation of an intermediate partial and an intermediate partial results in an

intermediate partial

• aggregation of an intermediate partial and a last partial results in a last partial • aggregation of a first partial and a last partial results in a complete event, which is

removed from the partial storage and handed back to the node implementation as an output record

• ‘potentially first partials’ are handled as first partials unless they exist in the middle of the long call due to sequence number wrap-around, in which case they are handled as intermediate partials

Note Aggregation schemes detect the single partials and remove them immediately to the business logic.

4.3.6 Correlation

Also correlation involves the combining of ERs but the ERs to be correlated come from different sources and are in different formats. The ERs may come at the same time from both access network and content platforms, which is the case in a content usage session.

The purpose of correlation is to gather all charging information into one or more correlated ERs, which can be distributed to the Operations and Business Support System (OSS/BSS). The information is typically divided into two logical elements: • session information, referred to as session records

• service information, referred to as service records

Session records provide the identity of the user (for example, username or IMSI) as well as session start time, end time and session identification. The session record may also list the network traffic usage during the session.

Service records provide information on the usage of various services. For example, MMS usage records from an MMSC network element. Correlation provides means to combine different kinds of records based on certain key field values in the ERs. EventLink Correlator Node is typically used in joining S-CDRs and G-CDRs from GPRS network or IN and MSC records.