CDR Generation Mechanism

 Structure of the Charging System

 Working Principles of the Charging System
 Networking Modes of the Charging System
Structure of the Charging System

When processing a call, the WCCU of the MSOFTX3000 generates original CDRs based on the collected
call data and stores them in the call detail record (CDR) pool. Through a specific sliding window protocol,
theMSOFTX3000 transfers the CDRs in the CDR pool to the iGWB with the help of the internal
communication system. The iGWBthen stores, processes, and transfers CDRs to the billing center (BC)
through the wide area network (WAN)/local area network (LAN). According to the information in final
CDRs, the BC of a PLMN carrier generates billing invoices for purposes of subscriber charging and cross-
network settlement. Figure 1 shows the structure of the MSOFTX3000 charging system.
Figure 1 Structure of the MSOFTX3000 charging system

LAN: Local Area Network WAN: Wide Area Network

SWP: Sliding Window Protocol BIN: Binary Protocol

HTTP: Hypertext Transfer Protocol MML: Human-Machine Language

FTP: File Transfer Protocol OMU: Operation & Maintenance Unit

SFTP: Secure File Transfer Protocol -

Working Principles of the Charging System

Figure 2 shows the logical structure of the MSOFTX3000 charging system.
Figure 2 Logical structure of the charging system

The charging system of the MSOFTX3000 consists of the WCCU, iGWB, BC, and interconnection
accessories.
 Call control module of the WCCU
The call control module generates original CDRs and stores them temporarily in the CDR pool of the
WCCU.
 CDR pool of the WCCU
The CDR pool is an area in the memory that stores the CDRs generated by the call control module
of the WCCU. The WCCU transfers the stored CDRs to the iGWB in real time.
The active WCCU sends CDR data to the standby WCCU in real time, which minimizes data loss
caused by board failure.
The MSOFTX3000 defines alarms and call restriction thresholds for the free space of the CDR pool.
When 20% of the WCCU CDR pool is occupied, an alarm is generated, but calls are not restricted
and the CDRs are not affected. When the free space of the CDR pool is less than 1% of the CDR
pool size, an alarm is generated, and calls are restricted. The CDRs are affected. You can configure
the thresholds of the free space for the CDR pool in command line mode. When the free space is
below the threshold, the system generates an alarm and determines the numbers of calls to be
restricted according to the free space of the CDR pool and the CDR increase rate.

NOTE:
Before loading data onto the WCCU or upgrading the WCCU, you must run CDR-related commands
on the Local Maintenance Terminal (LMT), for example, running a command to initiate immediate
transfer of original CDRs to the iGWB, to protect the WCCU against possible CDR loss.

 iGWB
The iGWB resides between the MSOFTX3000 and the BC. It receives, preprocesses, and caches
CDRs. The iGWB also functions as a billing interface.
 BC
Based on the final CDRs received from the iGWB, the BC generates billing invoices for subscribers.
The BC is not a part of the MSOFTX3000.

Networking Modes of the Charging System

 Connecting the iGWB to the BC directly

If the Mediation is not used in the charging system, the BC collects CDR files from the iGWB. Figure
3shows the networking mode involved when the iGWB is directly connected to the BC.
 Figure 3 Networking mode involved when the iGWB is directly connected to the BC

 Deploying the Mediation between the iGWB and the BC

The iGWB delivers CDR files to the Mediation. Then, the BC interworks with the Mediation to obtain
the CDR files for charging. Figure 4 shows the networking mode involved when the iGWB is
connected to the BC through the Medication.
Figure 4 Networking mode involved when the iGWB is connected to the BC through the Medication

In any of the preceding networking modes, ensure that the iGWB server can normally communicate with
the network where the billing system resides so that CDRs can be normally transmitted irrespective of
whether the iGWB server automatically delivers CDRs to the BC or the BC fetches CDRs from
the iGWB through FTP.
If CDRs are delivered in single-link mode, each pair of iGWB Virtual machines (VMs) is configured with
one virtual IP address, which enables the iGWB VMs to communicate with the BC or Mediation.
If CDRs are delivered in dual-link mode, each pair of iGWB VMs is configured with two virtual IP
addresses, which enable the iGWB to communicate with the BC or Mediation. If the active link is faulty,
the iGWB communicates with the BC or Medication through the standby link. By default, the single-link
mode is adopted, that is, only one active link is configured between the iGWB and the BC or Mediation.

General Process of Charging

Figure 1 shows the working process of the charging system.
Figure 1 Working process of the charging system

1. When a call is terminated, the WCCU generates and temporarily stores the charging information in
its buffer (that is, the CDR pool).
2. The content and format of the original CDRs generated by the MSOFTX3000 do not meet the
requirements of the BC. Thus, the CDRs must be preprocessed before being sent to the BC.
The iGWB resides between the MSOFTX3000 and the BC. It is responsible for receiving,
preprocessing, and temporarily storing CDRs in a buffer. It is also responsible for providing the
billing interface function. The WCCU sends CDRs from the CDR pool to the iGWB in real time
through the BASE bus. The iGWB stores the original CDRs as files.
3. The iGWB sorts the original CDRs, converts them from the binary format to the text format or
ASN.1 format, and generates the final CDRs. The iGWB then saves the final CDRs to different
channels based on the classification of CDRs. Figure 2 shows how the iGWB preprocesses CDRs.
 Figure 2 Procedure for preprocessing CDRs by the iGWB

NOTE:
The system is configured with active/standby iGWBs, which back up the CDRs in real time to avoid
loss of charging data due to the failure of the active iGWB.

4. To ensure reliable transfer of final CDRs to the BC, the iGWB communicates with the CDR
collector of the BC through the standard File Transfer Protocol (FTP) or Secure File Transfer
Protocol (SFTP).

Charging Scheme
 Offline Charging
 SCP Online Charging
 OCS Online Charging
Offline Charging

In this mode, the MSC server records all information regarding calls and generates original CDRs
accordingly. Then, the MSC server delivers the CDRs to the iGateway Bill (iGWB), which is responsible
for generating final CDRs and delivering the final CDRs to the billing center.

SCP Online Charging

In this mode, the MSC server sends an IDP message to the service control point (SCP) to trigger the
mobile originated (MO) or mobile terminated (MT) intelligent network (IN) service. The SCP then
determines whether to continue or release the call based on the actual call duration and current balance,
achieving online charging for subscribers. The SCP online change mode is generally used when the
MSOFTX3000 functions as an service switching point (SSP).

OCS Online Charging

In this mode, the MSC server interworks with the Online Charging System (OCS) by using Diameter
Credit Control (DCC) protocol. After receiving credit control requests from the MSC server in real time, the
OCS performs the credit control operations to achieve online charging for subscribers. The OCS online
charging mode can replace the existing CAP-based charging mode for various services.

Description of CDRs
 CDR Classification
 CDR File Format
CDR Classification

A CDR is a call detail record (CDR) generated by the MSOFTX3000. It is a charging data
unit stored in the memory of the WCCU and on the hard disk of the iGWB. The format of the
data unit is defined. There are several ways to classify CDRs. The name of a CDR varies
according to the classification criteria.
Classification Based on the Storage Location
 Original CDRs
Original CDRs refer to the charging data units that are generated by
the MSOFTX3000 initially and stored in the memory of the WCCU. In normal
circumstances, the MSOFTX3000 automatically transfers original CDRs over an
internal Ethernet to the iGWB in real time.
 Final CDRs
After receiving original CDRs from the MSOFTX3000, the iGWB first stores these
CDRs on a hard disk. Then, the iGWB sorts the CDRs, converts the CDRs into the
required format, and saves the processed CDRs to the hard disks in certain
classification modes. These processed CDRs are called final CDRs. Final CDRs
provide a key basis for subscriber charging and cross-network settlement. In normal
circumstances, the billing center (BC) acquires final CDRs from
the iGWB automatically and periodically.
Classification Based on the Generation Process
Based on the generation process, CDRs are classified into the following types:
 Intermediate CDRs
If the duration of a call is longer than the value of the long-call CDR timer, the system
generates an intermediate CDR for every expiry of the timer.
 Last CDRs
 When releasing a call after the conversation is complete, the system generates a last
CDR.
If the duration of a call is shorter than the value of the long-call CDR timer, the system only
generates a last CDR that records all the activities of the call. If the duration of the call is
longer than the value of the long-call CDR timer, the system generates intermediate CDRs
and a last CDR. In this case, the last CDR records only the call activities during the last
interval of the timer.

NOTE:
An intermediate CDR records the call activities only during an interval of the timer. The BC
charges a subscriber by accumulating the call expense in all the intermediate CDRs and the
last CDR.
CDR File Format

The MSOFTX3000 supports CDR files in the following formats:

Binary format
It is a data structure with the fixed length and format. In a binary CDR, each field is filled in
the fixed place.
Binary CDR files are used for the MSOFTX3000 to interwork with 2G equipment. Binary
CDR files are not recommended, except when the current office is a reconstructed 2G
office, a 2G office in China, or a special office.
TXT format
It is a data structure with a fixed length and format or with a variable length (any two fields
are separated by a delimiter) and a fixed format.
ASN.1 format
The Abstract Syntax Notation One (ASN.1) standard describes complex data structures
explicitly and is widely used as a syntax notation standard for the application layer.
Both Huawei and the 3GPP organization recommend ASN.1 CDRs.
Abstract Syntax Notation One (ASN.1) is a typical TLV data structure. TLV stands for tag,
length, and value. The ASN.1 coding defines three basic data structures: Integer, Boolean,
and Octet string. Designers can create complex data structures based on the basic data
structures. The ASN.1 CDR consists of one or several TLV data structures. You can use the
tag to locate a field in the CDR. Then, parse the length and data to obtain the content in the
field.
Charging Mechnisam Principles
1. Receiving
2. Processing
a. Decoding
b. Sorting
c. Format Conversion
d. Consolidation
e. Filtering
f. Encoding
3. Storage
4. Distribution
5. Backup
6. Deletion
7. Auditing
8. Query and Browse