button - online cdr generator

bottom

Your first CDR generation

Presentation

The first tutorial of our CDR generator exposes the basics of CDR generation with our demo project. The generated CDR are very simple and this will be enhanced as we'll move to the next tutorials.

CDR File CSV Example of generated CDR from this tutorial
CDR Profile The XML Profile use to generate those CDR

This tutorial will help to understand how a profile is organized in a XML file and how parameter changes affect the generated CDR.

Profiles

The basics of CDR generation is to simulate the activity of a set of customers during a period of time with usage patterns. All these three components are found in a profile in distinct parts of a XML configuration file.

Profile Template

You don't have to change anything into the generator itself or other parameters of the GEDIS project. That project is designed to read all its parameters from the XML profile file.

With that first profile the generator only produces a couple of CDR for a same customer. All CDR are just similar, that is they model the same customer calling the same duration towards the same correspondent. If you look at the generated data like in the following figure you will notice that basicaly only the timestamp of the CDR are changing.

Tutorial 1 CDR View

Time distribution of the CDR

First, you will notice that the generator dispatches all the calls into the simulation time period defined by the simulation's start date and simulation's duration. These two parameters are defined in the profile in the section named simulation.

Tutorial 1 Simulation Period

The simulation's duration must be defined in the format "[d] HH:MM:SS" where d is an optional value giving the number of days. Notice that "2 00:00:00" is equivalent to "48:00:00". The simulation start date must defined in the format "YYYY/MM/DD HH:MM:SS"

The time dispatching will produce the first CDR at the beginning of the period and the last CDR roughly at the end of the period. Silent periods are automatically inserted between every two consecutive CDR with random length. This makes sure that two consecutive CDR will not overlap for the same customer. While at the same time, two different customers may have overlapping CDR.

Even if the first tutorial has only one customer and one pattern, the figure below illustrate what hapens with 3 different customers having each CDR from two patterns.

CDR Time Distribution

CDR are produced in the order of definition of their pattern. In that tutorial it is not very important since you have a single pattern of usage. But later in the tutorials, with profiles exposing multiple patterns, you'll see that CDR are produced from patterns in the same order that patterns are defined.

Notice, that there's another generator that allows to shuffle CDR from a same customer to obtain the actual model described in the picture.

In this tutorial you can freely change the values for the simulation start date and duration in order to notice the distribution of the CDR that will be generated.

Customers

A profile describes the activity of a customer or a set of customers. In each CDR you'll have the identifiers of the customer the CDR is generated for. Each customer may be the caller or the receiver of the call, depending on the call type of each pattern a CDR is generated from. The customer data are defined in a profile in the section named customers.

Tutorial 1 Customers

A customer is uniquely defined by three parameters : MS ISDN, IMEI and IMSI. There's also a fourth parameter used to identify the network operator of the customer . The reason for having this fourth parameter is to allow to produce CDR attached to different operators. This is the case for example when you want to simulate the activity of roamer in (foreigner using a local network).

Customers count

The customer count is a very important parameter in the section because it tells the generator the number of times the profile is to be instantiated. In that tutorial the count is 1 meaning that the CDR are generated for a single customer.

If you have more than one customer to generate traffic for, then you must also configure the parameters giving the unique identifiers of the customer in such a way that a new identifier will be generated / used for each new customer. That will be the purpose of the next tutorial.

Usage pattern

CDR are generated for customers, during a simulation period but more importantly their are generated after a pattern of usage.Thus each CDR conforms to a single pattern described in the profile. Notice that a pattern has a marker that is embedded in the CDR to track back the pattern use to generate each CDR.

A pattern describes how a given customer is consuming a service and in the telco project services are voice calls, SMS, data, etc.

Tutorial 1 Pattern

Here are the basic parameters of a pattern :

  • nb_calls : Gives the number of CDR to generate with this pattern
  • durations : The duration of call in HH:MM:SS format or number of seconds.
  • call_type: a pair delimited by the "/" sign of the call type and call service
  • corresp1: The pair delimited by the "/" sign with the first correspondent type and ISDN
  • correps2: same for the second correspondent
  • network: the international operator code from where the CDR is supposed to be produced

You can use any values appropriate for you for the call type and services, the correspondent types and ISDN (even non numerical values). But the number of call must be a integer and the duration must be either in HH:MM:SS format or integer (interpreted as a number of seconds)

Get me to the next tutorial !