functional description of charging gateway 4.3

Functional Description ofCharging Gateway 4.3

DN03353543Issue 10 en

# Nokia Corporation 1 (111)

00041683.00Nokia Charging Gateway Release 4.3, ProductDocumentation

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This document is intended for the useof Nokia's customers only for the purposes of the agreement under which the document issubmitted, and no part of it may be reproduced or transmitted in any form or means without theprior written permission of Nokia. The document has been prepared to be used by professionaland properly trained personnel, and the customer assumes full responsibility when using it.Nokia welcomes customer comments as part of the process of continuous development andimprovement of the documentation.

The information or statements given in this document concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia and the customer. However, Nokia hasmade all reasonable efforts to ensure that the instructions contained in the document areadequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich may not be covered by the document.

Nokia's liability for any errors in the document is limited to the documentary correction of errors.NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENTOR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARYLOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright according tothe applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

Other product names mentioned in this document may be trademarks of their respectivecompanies, and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2006. All rights reserved.

2 (111) # Nokia Corporation DN03353543Issue 10 en

Functional Description of Charging Gateway 4.3

Contents

Contents 3

1 Changes in functionality 71.1 Changes between releases 4.2 and 4.3 71.2 Changes between releases 4.1 and 4.2 91.3 Changes between releases 4.0 and 4.1 11

2 Main functions and architecture 132.1 Architecture of a single Charging Gateway 142.2 Resiliency and load sharing 152.3 Audit Log 162.4 Process supervision 182.5 Supported CDR type versions 19

3 Administrator subsystem 23

4 Collector subsystem 254.1 Overview of Collector subsystem 254.1.1 CDR buffer 274.1.2 Crash recovery 274.1.3 Traffica support in Collector 274.2 Collector main application 284.3 Collector protocol handler modules 284.3.1 Validation in Collector 284.3.2 Raw data file 294.3.3 GTP' protocol handler 294.3.3.1 Network element IP address reloading 304.3.3.2 GTP' collector communications 304.3.3.3 GTP' message log file 324.3.3.4 GTP' duplicate prevention 324.3.3.5 GTP' attributes 334.3.4 FTP protocol handler 334.3.5 Nokia Control File FTP protocol handler 344.4 Collector converter modules 354.4.1 CGNokiaMSCConverter configuration functionality 374.4.2 Protocol handler usage of converter modules 40

5 Core subsystem 415.1 CDR processing in Core 415.2 Data processing nodes 425.3 Impact of flushes on CDR processing 425.3.1 Understanding masterflush 435.3.2 Understanding flush triggers in Aggregator and Combiner 435.3.3 Example of using Aggregator with SGSN CDRs 465.3.4 Understanding flushing in Simple Aggregator, Aggregator2, and Small

Aggregator 515.4 CdrEvaluator expression syntax 525.5 FML boolean expressions 54



Contents

5.5.1 Operators in FML boolean expressions 545.5.2 Using FML boolean expressions 555.6 Provided data circuits 575.6.1 Default main data circuit rule 575.6.2 Sample data circuit: record type rule 605.6.3 Sample data circuit: ICD rule 615.6.4 Sample data circuit: IMS rule 625.6.5 Sample data circuit: MSC rule 625.6.6 Sample data circuit: CPS Rel. 2 rule 63

6 Distributor subsystem 676.1 Overview of Distributor subsystem 676.2 Distributor main application 696.2.1 Support for headers and trailers 696.2.2 Numbering outgoing CDRs and files 716.2.3 Support for multiple output formats 736.3 Distributor converter modules 746.3.1 FML to ASCII converter 756.3.2 FML to XSV converter 756.3.3 FML to TLV converter 756.3.3.1 TLV type values 766.3.3.2 TLV encoding rules 766.3.3.3 Output CDR conversion examples 776.3.4 Traffica converter 796.4 Distributor protocol handler modules 796.4.1 File Transfer Protocol (FTP) 816.4.2 File protocol 816.4.3 CORBA protocol 826.4.4 User Datagram Protocol (UDP) 836.5 Map of CDRs and predefined output formats 83

7 User interfaces 877.1 Graphical user interface 877.2 Command line interface 897.2.1 Commands in non-interactive mode 897.2.2 Commands in interactive mode 907.2.2.1 Core administration menu 917.2.2.2 Collector administration menu 917.2.2.3 Distributor administration menu 927.2.2.4 Common administration menu 927.2.2.5 KPI administration menu 93

8 External interfaces 958.1 Performance monitoring interface 958.1.1 Architecture of the Performance Monitoring Interface 958.1.2 Key Performance Indicators (KPIs) 978.2 Alarm interface 1008.3 Nokia Charging Center interface 1048.4 Traffica interface 105

9 Runtime environment 107



10 CG.cproperties file 109



Contents

1 Changes in functionality

1.1 Changes between releases 4.2 and 4.3

Changes in content

The current release of Charging Gateway is based on features in previousreleases.

The following are new features in the current release:

Table 1. New features in Charging Gateway rel. 4.3

Feature Description

Small Aggregator node A new data processing node primarily foraggregating MSC CDRs. For moreinformation, see Small Aggregator nodeinData Processing Nodes in ChargingGateway 4.3.

Multiple Core support The user can configure multiple Cores toincrease CG's CDR handling capacity.Multiple Core support has causedmodifications in the Input Interface node.

Nokia CPS release 2 support CG supports CDRs from this networkelement. Due to this, changes have alsobeen implemented in Correlator2 andAggregator2 nodes. A new sample datacircuit has been made for CPS 2.

Nokia MSC support (up to M13.3) CG supports CDRs from this networkelement. The Small Aggregator node hasbeen created to support this feature. Anew sample data circuit has been madefor MSC.

Nokia FISN rel. 3 support The CG supports CDRs from this networkelement.



Changes in functionality

Table 1. New features in Charging Gateway rel. 4.3 (cont.)

Feature Description

Nokia 3G SGSN rel. 4 support The CG supports CDRs from this networkelement.

Nokia SGSN SG6.0 support The CG supports CDRs from this networkelement.

Push to talk over cellular (PoC) release 2support

The CG supports CDRs from this networkelement.

FTP Collector enhancement The FTP Collector can now be used tofetch CDRs from 3G SGSN.

Nokia Control File FTP Collector A new protocol handler for MSC and 2GSGSN support using the Nokia ControlFile mechanism. See Nokia Control FileFTP protocol handler.

FML2XSV Converter Configurable separator support inDistributor. Allows the use of anycharacter as a separator in output CDRs.See Distributor converter modules.

File renaming support in Distributor The Output CDR files can be renamed inFTP transfer to distinguish betweenclosed files and files not ready fortransfer. See Distributor convertermodules.

NVS support CG supports CDRs from this networkelement.

Nokia enhanced SNMP solution suite(NE3S) for alarm handling

The NE3S alarm interface with theESYMAC alarm agent can be configuredfor use instead of the default alarminterface. For details, see Alarm interface.

GUI changes Several configuration dialogs and pageshave been modified to support the newfeatures. Also several usability featuresimprovements have been added. SeeChanges in the graphical user interface inGraphical User Interface Help forCharging Gateway 4.3.

tlvReader The tlvReader is a new command line toolfor viewing TLV-format CDRs produced byDistributors using the FML to TLVconverter. For details on the tool and itsuse, seetlvReader functions and usage inOperating and Maintaining ChargingGateway 4.3.




Feature Description

Capacity licensing CG 4.3 introduces CDR load basedcapacity licensing. For details on use, seeConfiguring capacity licensing inCommissioning and Integrating ChargingGateway 4.3.

In addition to the above features, toolkits are available for each of the subsystems- Collector, Core, and Distributor - to make customised extensions. For anycustomization needs, please contact your local Nokia representative.

Changes in documentation

Information about the following topics has been added:

. FML boolean expressions

. Protocol handler usage of converter modules under Collector convertermodules

. Control File FTP protocol handler has been added under Collector protocolhandler modules

All data processing node specific information has been moved to Data ProcessingNodes in Charging Gateway4.3 document.

In addition, all the changes related to the features listed in the above table havebeen added to the documentation.


Changes in content

The 4.2 release of Charging Gateway is based on features in previous releases.

The following are new features in the CG release 4.2:




pkic1201

Highlight


Feature Description

Aggregator2 node This is a new data processing node for aggregating CDRs based on record typeID rather than record type version. For more information, see Aggregating CDRs.

Input Interfacenode change

The Input Interface data processing node was modified to support the newAggregator2 node.

Combiner nodechange

The Combiner data processing node was modified to support configurations basedon record type ID (used in Aggregator2).

Correlator2 node This is a new data processing node that introduces more configurable options forcorrelating CDRs. For more information, see Correlator2 node in Data ProcessingNodes in Charging Gateway 4.3.

Nokia GGSN rel.5.0 support

Collector supports the CDRs from this network element. The rel. 5.0 CDRs canalso be forwarded to Traffica.

A predefined CDR output format is not included.

Nokia 2G SGSNrel. 5.0 support


A predefined CDR output format is not included. The existing 2G SGSN rel. 3.1output format can be used for this purpose.

Nokia 3G SGSNrel. 3.0 support


A predefined CDR output format is not included.

OSC rel. 2.0support

CG can send CDRs for OSC rel. 2.0 for rating, fetch the rated CDRs, and forwardthem to a billing system.

These CDRs are routed through the data circuit directly to Distributor withoutfurther processing.

Duplicate Checkernode

New data processing node.

GTP' messagelogging

Message type is now included in the logged information. Also, this plus the timestamp and IP address (with port number, when the message is from a networkelement) of each message are written into the file in readable format (whenopened in a HEX editor).

FML to TLVconverter

New Distributor converter module that converts CDRs in FML to Type-Length-Value (TLV) based ASCII output. Each CDR is converted to an ASCII string on asingle line, with each CDR separated by a new line. For more information, seeFML to TLV converter.

CDR viewer You can now search raw data files and output CDRs through the GUI.

GUI changes Several configuration dialogs and pages have been modified. See Changes in theGraphical User Interface for details.

IP addressreloading

Commands have been added to Admin CLI for reloading network element IPaddresses used in GTP' Collector.

Configurable echomessage sending

GTP’ Collector can be configured to send echo request messages periodically toparticular network elements.




Feature Description

Configurable NodeAlive messagesending

GTP’ Collector can be configured to keep sending Node Alive Request signals toselected network elements until an answer (Node Alive Response) is received.

POSIX queues The Tuxedo-based queues between Collector and Core, between Core andDistributor, and between Collector and Distributor (Traffica queue), have beenreplaced by configurable queues based on POSIX.

This introduces new parameters for some data process nodes, as well as forCollector and Distributor.

Apache Tomcatserver

The BEA Weblogic Server has been replaced by Apache Tomcat.

Note that the CG.cproperties file has changed due to this server change.

Sequence numberrestart

The Distributor sequence number can be restarted (default) or continue from theprevious number after a subsystem is restarted. This is controlled through a newparameter in the CG.cproperties file.


Several new sections have been added to the Functional Description to cover thenew functionality. Two sections, Position in the networks and Software andhardware components, have been replaced by references to the CG4 ProductDescription.


Changes in content

The 4.1 release of Charging Gateway is based on features in previous releases.

The following are new features in the CG release 4.1:


Feature Description

New CDR outputformats

New default output formats for the following elements and systems: CA rel. 2.0,CPS rel. 1.0, GGSN rel. 4.1, ICD rel. 3.0, PoC rel. 1.0, and TA rel. 2.0.

Processsupervision

CG processes are monitored according to configurable settings.

See Process supervision for details.





Feature Description

Generic hot billinginterface

New interface allows hot billing to any Customer Care and Billing System (CCBS)using Common Object Request Broker Architecture (CORBA).

See CORBA protocol for details.

GUI enhancements Several changes made to the GUI to improve usability and expand functionality.

Global sequencenumbering

Single sequence numbering file that can be used by all Distributors on a given CGserver. See Numbering outgoing CDRs for details.

Look-up table New data processing node. See Look-up Table node for details.

Multiple converters Collector now supports multiple converter modules.

Multiple outputformats

Distributor supports multiple output formats. See Support for multiple outputformats for details.

Simple Aggregator New data processing node. See Simple Aggregator node for details.

Traffica support Additional CDR type versions are sent to Traffica


In Charging Gateway rel. 4.1, the Functional Description has not changedsignificantly. The new functionality has, for the most part, been added to existingareas.

Some areas have been combined with others. In addition, there are new referenceareas, while those covering the configuration database tables have been removed.



2 Main functions and architecture

The 3rd Generation Partnership Project (3GPP) has specified Charging GatewayFunction (CGF), which provides a mechanism for transferring charginginformation from the Serving GPRS Support Nodes (SGSNs) and GatewayGPRS Support Nodes (GGSNs) to the network operator’s post-processingsystem. In the Nokia implementation, CGF is implemented as a stand-aloneelement, the Nokia Charging Gateway (CG). The CG is used in GPRS, 3G,mobile telephone exchange (MSC) networks, and Nokia Intelligent ContentDelivery (ICD), Operator Wireless LAN (OWLAN), and IP MultimediaSubsystem (IMS) product systems.

The Charging Gateway consolidates raw event records into charging data records(CDRs) and forwards them in a suitable format to the post-processing system.

The main functions of CG are:

. Collection of event records

. Intermediate event record storage buffering

. Processing of CDRs

. Transfer of CDR data to the post-processing system

In addition to the functionality described in 3GPP specifications, CG provides thefollowing:

. CDR routing

. CDR validating

. CDR combining

. CDR aggregating

. CDR correlation

. CDR field manipulation

. Hot billing support for prepaid CDRs



Main functions and architecture

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

. Storage of CDRs until a Customer Care and Billing System (CCBS) orother post-processing system collects them

. Configurable output interface

. Customisable data interfaces

CG manages the transfer of CDRs from network elements in GPRS, 3G, andmobile circuit switched networks in a reliable and controlled manner. Changesneeded in the CCBS or other post-processing system integration are minimisedby processing CDRs in the format that the system requires. The number ofinterfaces to the post-processing system are reduced, which also minimisesintegration needs.

CG aggregates CDRs, which decreases the number of output CDRs that are sentto the post-processing system. This, in turn, reduces the work load of the post-processing system.

The CDR processing uses several different data processing nodes (DPNs), forexample Aggregator2, Small Aggregator, Combiner, and Validator, each of whichare configurable. For more information, see Data Processing Nodes in ChargingGateway 4.3.

CG supports monitoring from Nokia NetAct, a network-wide monitoring andsupport system.

For more general information about Nokia Charging Gateway, please refer to theNokia Charging Gateway Rel. 4 Product Description. This can be found underthe Product Catalog in Nokia Online Services (NOLS).

2.1 Architecture of a single Charging Gateway

The following figure illustrates the basic architecture of CG.



pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

Figure 1. Architecture of CG

The main subsystems are Collector, Core, Distributor, and Administrator. Therecan be multiple instances of Collector, Core and Distributor subsystems.

CG is operated and maintained through a Graphical User Interface (GUI) andCommand Line Interface (CLI). Nokia NetAct can be used for remotelymonitoring the performance and status of the CG units installed in the network.

2.2 Resiliency and load sharing

Resiliency

Users need to shut down CG when repairs are needed, when users take a newconfiguration into use, or when new software is installed. Thus, there should be atleast two Nokia Charging Gateway units to handle all the charging data in thenetwork in a resilient manner.

FTPCollector

Collector

Admin

Rawdata

CAPI

GTP’Collector

CAPI

FTPCollector

CAPI

CFCollector

DAPI

HotbillOutput

DAPI

FTPOutput

DAPI

FileOutput

Distributor

Queues

ConfigDB

CommandLine Interface

Alarm (FM)

PerformanceManagementInterface

GraphicalUser Interface

Traffica

DAPI

UDP/IPDistributor

Core

Queues

Traffica

Traffica




pkic1201

Highlight

pkic1201

Highlight

The minimum requirement for servers is N+1 resiliency. For example, if there arethree CG servers, CDR-generating network elements configure two CG units asprimary, and they actively receive CDRs. The third CG is also fully operationalbut is configured as a secondary CG in the network elements sending CDRs. Ifone of the primary CG units fails, GTP' automatically redirects CDRs to thesecondary CG.

The expression, 2N resiliency, means that one primary CG server may have (oneor more) secondary CG servers.

Load sharing

The types of load sharing are:

. Load sharing within the same CG using multiple Core instances

The CG can be configured to perform CDR processing using multiple Coreinstances. Each Core instance can have the same data circuit, or a differentdata circuit can be used in each (recommended for advanced users only).By default you should use the single Core setting unless you knowprocessing capacity of one Core does not meet your CDR handlingrequirements. For details on the multi-Core feature configuration andusage, see the commissioning and integrating documentation.

. Network element load sharing

Network element load sharing is based on CG resiliency. Since there arealways at least two CG units in the network, the secondary CG can beconfigured to take care of some of the CDR traffic also in a normalsituation. In this case, it is important that both CG units run with less than50% of their capacity.

If the primary CG runs with 55% capacity, and the secondary with 50%capacity, the secondary CG cannot process the overall CDR traffic if theprimary CG is out of operation. This is because the overall load exceeds100%. The result is that CG stops processing CDRs. However, temporaryspikes in usage can be processed in this configuration.

2.3 Audit Log

The main Audit Log is located in the Admin Server, the location is configurablethrough the CG.cproperties file with the 'AuditLog' property. The main AuditLog includes information about the actions that have been performed through theGUI. However, an Audit Log is in every server. The Audit Logs in other serversdo not contain any GUI information and only carry information written bysubsystems when they start, and the ID of the rule that is started.



pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

The Audit Log can be viewed only from the command line. The location andname of the file is configurable. The default location and filename is /cdr/work/logs/cg4audit.log. The list of logged tasks is as follows:

. User login

. Logout

. Login failure

. Add/delete/update network element interface configuration

. Add/delete/update CG configuration

. Schedule/delete periodic task

. Schedule/delete single task

. Save Collector configuration

. Save output filename configuration

. Save protocol configuration

. Save output format configuration

. Save Distributor configuration

. Save data circuit configuration rule

. Core started with rule id x

. Distributor started with distributor id x

. Collector started with collector id x

. Changing user password

. Executing a cleanup script from GUI

. Add/delete/update cleanup procedures

. Add/delete/update node templates

. Load/save version history (TLV)

. Changing rule state

The following is an example:

Example Sample Audit Log entries

Wed Jan 25 14:27:24 EEST 2006, user 'cg': User logged in

Wed Jan 25 14:27:53 EEST 2006, user 'cg': Save datacircuit rule configuration

Wed Jan 25 14:27:53 EEST 2006, user 'cg': Saved datacircuit rule configuration




pkic1201

Highlight

with ID 5

Wed Jan 25 14:28:23 EEST 2006, user 'cg': Save collector configuration

Wed Jan 25 14:28:48 EEST 2006, user 'cg': Add NetworkElement

Wed Jan 25 14:28:55 EEST 2006, user 'cg': Save distributor configuration

Wed Jan 25 14:30:59 EEST 2006, user 'cg': Save outputfield configuration

Wed Jan 25 14:31:09 EEST 2006, user 'cg': Save protocol configuration

Wed Jan 25 14:31:17 EEST 2006, user 'cg': Save filename configuration

Wed Jan 25 14:31:38 EEST 2006, user 'cg': Add CG

Wed Jan 25 14:31:43 EEST 2006, user 'cg': User logged out

2.4 Process supervision

Process supervision is a watcher daemon that monitors CG processes and initiatesconfigurable actions to notify about and recover from process errors. Theenvironment variable PSV_PROPERTIES_FILE defines the configuration file forthis feature and where it is located. By default, the value is /opt/cg/<release>/cfg/processsupervision.properties.

Process supervision is implemented by sending Subsystem Alive Requests(SARs) to every subsystem and waiting for them to reply. If process supervisionreceives no response, SARs are resent. The number of retries is configurable. If asubsystem still does not respond, the pre-configured actions are started. For moredetails, see Configuring process supervision in Operating and MaintainingCharging Gateway 4.3.

Alarms (SNMP traps) are sent to NetAct when a subsystem malfunctions. When asubsystem malfunctions, process supervision executes a shell script to recoverfrom the problem. Alarms are automatically sent to NetAct even if there are norecovery actions (that is, the shell script is empty). If the script fails (processsupervision fails), this is recorded in the Audit Log.

The following table summarises the default recovery actions. These may beextended by editing the corresponding shell script. For example, a script can beextend to send an e-mail to the administrator using 3rd party software.

Table 4. Default recovery actions

Subsystem Recovery actions Description

Collector None There are no default recovery actions for Collector. Theother subsystem processes can continue even ifCollector fails.

Core Shutdown Collector is shut down when an error occurs in Core.

Distributor Shutdown Collector is shut down when an error occurs inDistributor.



pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

2.5 Supported CDR type versions

The following table outlines the supported CDR type versions and theidentification values used for processing in Core.

Table 5. CDR type versions

Recordtypeversion

Name Record type

6 G-CDR rel. 2 19

7 S-CDR 2G SGSN rel. 2 18

8 M-CDR 2G SGSN rel. 2 20

9 S-SMO-CDR 2G SGSN rel. 2 21

10 S-SMT-CDR 2G SGSN rel. 2 22

11 S-SMT-CDR 2G SGSN rel. 2

(CDR includes Calling Party Number field)

22

12 W-CDR rel. 2 95





18 TA-CDR rel. 1.2 94

19 CA-CDR rel. 1.1 93



22 S-SMT-CDR 2G SGSN rel3 22


24 G-CDR rel. 3 and 4 19

25 SA-CDR rel. 4 225





30 TA-CDR rel. 1.3 94

31 S-CDR 2G SGSN rel. 3.1, 4 and 5 18




pkic1201

Highlight

Table 5. CDR type versions (cont.)

Recordtypeversion

Name Record type

32 M-CDR 2G SGSN rel. 3.1, 4 and 5 20

33 S-SMO-CDR 2G SGSN rel. 3.1, 4 and 5 21

34 S-SMT-CDR 2G SGSN rel. 3.1, 4 and 5 22

35 POC-CDR rel. 1 15

36 CPS-CDR rel. 1 66

37 G-CDR rel. 4.1 19

38 SA-CDR rel. 4.1 225

39 CA-CDR rel. 2.0 93

40 TA-CDR rel. 2.0 generic 94

41 TA-CDR rel. 2.0 service 92

43 W-CDR rel. 4.1 95

44 G-CDR rel. 5.0 19

45 SA-CDR rel. 5.0 225



48 SMO-CDR 3G SGSN rel. 3 21

49 SMT-CDR 3G SGSN rel. 3 22

50 LCSMO-CDR 3G SGSN rel. 3 27

51 LCSMT-CDR 3G SGSN rel. 3 26

53 OSC rel. 2.0 -

54 CPS-CDR rel. 2 66

56 TA-CDR rel. 3.0 generic 94

57 TA-CDR rel. 3.0 service 92





62 LC-SMO-CDR 3G SGSN rel. 4 27

63 LC-SMT-CDR 3G SGSN rel. 4 26

64 G-CDR ISN rel. 3.0 19

65 SA-CDR ISN rel. 3.0 225




Recordtypeversion

Name Record type

66 S-CDR SGSN SG6.0 18

67 M-CDR SGSN SG6.0 20

68 SMO-CDR SGSN SG6.0 21

69 SMT-CDR SGSN SG6.0 22

70 OSC rel. 2 IACC 98

71 OSC rel. 2 Radius 98

72 OSC rel. 2 Diameter 98

73 OSC rel. 2 AGW 98

74 OSC rel. 2 MMSC 98

75 OSC rel. 2 SMSC 98

76 OSC rel. 2 DLS 98

77 OSC rel. 2 NMG 98

78 OSC rel. 2 NWG 98

99 NCDR ver. 1 99

201 MSC-MOC rel. 13 240

202 MSC-MTC rel. 13 240

203 MSC-FORW rel. 13 240

204 MSC-ROAM rel. 13 240

205 MSC-SUPS rel. 13 240

206 MSC-HLRI rel. 13 240

207 MSC-LOCA rel. 13 240

208 MSC-SMMO rel. 13 240

209 MSC-SMMT rel. 13 240

210 MSC-TRA rel. 13 240

211 MSC-POC rel. 13 240

212 MSC-PTC rel. 13 240

213 MSC-PBXO rel. 13 240

214 MSC-PBXT rel. 13 240

215 MSC-HW rel. 13 240

216 MSC-IN1 rel. 13 240

217 MSC-UCA rel. 13 240





Recordtypeversion

Name Record type

218 MSC-IN2 rel. 13 240

219 MSC-IN3 rel. 13 240

220 MSC-DOC rel. 13 240

222 MSC-RCC rel. 13 240

223 MSC-SMMF rel. 13 240

224 MSC-COC rel. 13 240

225 MSC-CTC rel. 13 240

226 MSC-IN4 rel. 13 240

227 MSC-LCS rel. 13 240

228 MSC-IN5 rel. 13 240

229 MSC-USSD rel. 13 240

230 MSC-SOC rel. 13 240

231 MSC-STC rel. 13 240

232 MSC-SOM rel. 13 240

233 MSC-STM rel. 13 240

235 MSC-SIPR rel. 13 240



3 Administrator subsystem

The purpose of Administrator (Admin) subsystem in the Charging Gateway (CG)is to provide a clear interface for client applications, such as the Command LineInterface (CLI) and Performance Monitoring (PM) interface, to administer andmonitor other CG subsystems. The Admin subsystem can run on the same serveras other subsystem, or on its own server as a standalone Admin server.

The typical client tasks carried out at runtime include:

. managing subsystems, for example, shutting down subsystem individuallyor globally

. monitoring subsystems, for example, querying Key Performance Indicators(KPIs) and checking which subsystems are up and running

. setting up subsystems (changing subsystem configuration). The supportedcommands are:. Change Log level (for all subsystems). Reset KPI counters (for all subsystems). Reload NE IP address (for GTP' Collector). Cancel potentially duplicated packets (for GTP' Collector). Release potentially duplicated packets (for GTP' Collector). Switch on/off GTP message logging (for GTP’ Collector). Switch Traffica IF on/off (for all Collector subsystems). Reinitialize Core (for Core)

. making functional calls (requests for immediate execution of a particularfunction). The supported commands are:. Raw data processing (for GTP' Collector). Masterflush execution (for Core). Periodic flush execution (for Core)

For more information on the interface clients using Admin, see Command LineInterface (CLI) and Performance Monitoring interface.



Administrator subsystem

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

4 Collector subsystem

4.1 Overview of Collector subsystem

The Collector subsystem receives CDRs from various network elements,validates the CDRs (for acceptance only; main content validation is in Core),saves them to the backup file, converts them to a uniform internal format, andforwards the CDRs to the Core subsystem for processing. The internal CDRformat is Tuxedo Field Manipulation Language (FML). The position of theCollector subsystem is illustrated in Figure Architecture of CG in Architecture ofa single Charging Gateway.

Some protocol, either proprietary or public, is used to transfer CDRs from CDR-generating nodes to CG. Collector supports enhanced GPRS Tunnelling Protocol(GTP'), File Transfer Protocol (FTP), and Nokia Control file FTP.

The Collector subsystem is made up of the following main components:

. Main application

. Converter modules

. Protocol handler modules

The Figure Collector architecture illustrates the architecture of the Collectorsubsystem and the flow of incoming CDRs.



Collector subsystem

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

Figure 2. Collector architecture

Supported CDR formats

CG supports incoming CDRs in the following formats:

. Nokia Fixed format

. Nokia TLV format

. CSV format

. Nokia MSC format

Collector toolkit

A software development toolkit is available to build modifications for Collector.With the toolkit, support for new network elements can be added to the defaultCollector subsystem. The toolkit consists of base classes from which the newconverter and protocol handler modules must be inherited. The base classescommunicate with the main application using the CG internal interface. For anycustomization needs, please contact your local Nokia representative.

The toolkits are for Nokia customization use only.

CGinternalinterface

NE1

NE3

NE2

NE n

raw data fileAdministrator

main application

protocolhandler

CAPI

converter

CAPI

Traffica

Core



pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

4.1.1 CDR buffer

The number of incoming CDRs per time period can fluctuate, and Core may notbe able to process all the CDRs coming from Collector instantly. The solution forthis 'rush-hour' problem is a CDR buffer that can temporarily store CDRs(converted to FML) before Core processes them. The queue between Collectorand Core provides this buffering. By default there is one queue per Collectorinstance, but when multiple Cores are used there can be several queues for eachCollector instance. Each queue is memory-based, and the size is configurable.

4.1.2 Crash recovery

If the Collector crashes, the CDRs in the raw data file can be re-processed so thatno CDRs are lost. For a GTP' Collector this has to be done manually using theAdmin command line interface. When a GTP’ Collector is told to read raw data, itsends re-direction messages to network elements to make them switch CDRtransmission to a secondary CG while the raw data processing is done.

4.1.3 Traffica support in Collector

Collector can create Traffica reports (without the report header) from raw CDRsand send them to the Distributor through a queue specifically for Traffica.

Collector has two counters for Traffica: one for reports and one for events. Thereport counter indicates the number of Traffica reports sent to Traffica, and theevent counter indicates the number of Traffica reports that should have been sent.These counter values are sent to Distributor that adds them to the Traffica reportheader before sending the report to Traffica. In normal situations, these countersare the same. However, in an overload situation, the event counter increases butthe report counter does not. These counters are cleared every night at midnight.

Overload handling

The Traffica interface can be automatically switched off when the CPU load getstoo high. This is done by using a load monitoring script (load_monitor.sh)which monitors CPU usage and switches the interface off and back onaccordingly. A log entry is created in each case.

The script can be edited to meet the environment-specific requirements. Theconfigurable parameters are described in the beginning of the script.



Collector subsystem

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

4.2 Collector main application

When Collector is started, the main application loads the protocol handler andconverter module according to the configuration values stored in theconfiguration database. Several instances of the main application with the same ordifferent protocol handler (excluding the GTP' module), and one or moreconverter modules can coexist. Communication with Administrator and CGadministration command-handling is done by the main application.

The Field Manipulation Language (FML) buffer for storing the converted CDRsis part of the main application, as well as the FML buffer manipulation and queuefunctions. Log writing and alarm handling are also performed by the mainapplication.

4.3 Collector protocol handler modules

The protocol handler module handles communication between CG and CDR-generating network elements. It receives CDRs from network elements andchecks that they can be decoded. The protocol handler also saves the CDRs to theraw data file, and then sends them to the converter module. CG provides protocolhandlers for GTP', FTP, and Nokia Control File FTP.

4.3.1 Validation in Collector

Before accepting a CDR, CG has to verify that it is able to decode it. Because ofthat validation naturally takes place in a protocol handler module. The validationalgorithm depends on the transfer protocol used and the CDR structure.

Collector does not check whether the values of the individual fields inside a CDRare valid. The Core subsystem does this kind of validity check. Collector justchecks that the CDR is not corrupted and that the conversion to FML format ispossible.

When Collector receives GTP' packets from network elements (NEs), it validatesthe following:

. IP address of the NE that sent the GTP’ packet

. version of the received GTP’ message

. format of the CDRs in the GTP’ packet

. version of the CDRs in the GTP’ packet

. CDR length fields (this is only for incoming CDRs with fixed format)



pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

If there is an invalid CDR in the GTP’ packet, a cause for CDR rejection is sentback to the GSN within a 'DataRecordTransferResponse' message. The causecode alerts the GSN as to the reason the GTP’ packet was refused. The sequencenumber lets the GSN know which packet was in question.

The FTP protocol handler does not perform validation.

The control file FTP checks the CDR length and compares the type to theconfiguration file. If the type does not match the CDR is ignored and an entry iswritten to the ULOG.

4.3.2 Raw data file

After receiving and validating the CDRs, CG can write them to non-volatilememory (disk file) through the raw data interface. This file is called a raw datafile which serves as a backup file in case of a system crash. The protocol handlermodule that writes the raw data file must also be able to reprocess its contents forcrash recovery. However, not all Collectors need to create raw data files. Forexample, GTP’ Collector creates a raw data file, but FTP collector does not.

The GTP' Collector creates raw data files to store incoming CDRs for backuppurposes. CG writes all GTP' Data Record Transfer Request messages, exceptempty ones, into the raw data file. One Data Record Transfer Request messagecontains one or more CDRs. The whole GTP’ packet is written to a raw data fileat once.

The FTP Collector stores the transferred file to the work directory. After CDRshave been processed, the file is moved to an archive directory. The transferred filecan be used as such for backup purposes, so there is no need to use the raw datainterface when processing CDRs from an FTP file.

The Nokia CF FTP Collector transfers the CDR files to an element specificdirectory. These directories are located in the work directory (default is /cdr/work/inbox). The name of the subdirectory is the same as the IP address of theelement. After the converter has processed all the CDRs of a file, the protocolhandler renames the file, and moves it to the archive directory.

4.3.3 GTP' protocol handler

The GTP' protocol handler receives GTP' packets from the GGSN (Releases 2, 3,4, 4.1, 5), Intelligent Service Node (ISN) Release 3, SGSN (2G Releases 2, 3, 3.1,4, and 5, and 3G Releases 1, 2, 3 and 4), SGSN SG6.0, Authentication ServerRelease 4.1 (AS 4.1), IP Multimedia Subsystem (IMS) Releases 1 and 2, NokiaContent Analyser (CA) Releases 1 and 2, Traffic Analyser (TA) Releases 1.3, 1.4,2 and 3, and Nokia OWLAN Release 2.



Collector subsystem

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

When the GTP' Collector receives a packet it validates the packet, saves thepacket in the raw data file, sends response message back to GSN, and unpacks theraw CDRs from the packet. Only one instance of the GTP' module can exist on aCG application server due to the port restrictions defined in the standards. Onlyport 3386 should be used for the GTP' messages.

4.3.3.1 Network element IP address reloading

The GTP’ protocol handler supports reloading of IP addresses at runtime. Youcan add or update network element addresses in the GUI, and then use thecommand line interface to reload the IP addresses. For new addresses, a NodeAlive Request signal is sent to indicate the CG exists.

4.3.3.2 GTP' collector communications

The input interface of GTP' protocol handler is the equivalent of ETSI’s 3GPP Gainterface. The messages sent on this interface are illustrated below.

Figure 3. Request/Response between CGs and GSNs

The interface handles and implements the following GTP’ messages:

Node Alive messages

CG sends Node Alive Request every time Collector becomes available and isready to receive CDRs.

A GSN sends Node Alive Response back to CG in reply to Node Alive Requestto inform CG that the request was received.

If CG does not receive Node Alive Response message, it writes to the ULOG file:CG did not receive NodeAlive response from <IP address>

Node Alive Request

Node Alive Response

Data Record Transfer Response

Echo Request

Echo Response

Data Record Transfer Request

Redirection Response

Redirection Request

Version Not Supported Response

GSN CG



GTP’ Collector can be configured to keep on sending Node Alive Request signalsto selected network elements until an answer (Node Alive Response) has beenreceived. Otherwise, the ‘T3 response’ and ‘N3 requests’ parameters determinehow many times and at what interval Node Alive Requests are sent. For newnetwork elements added through the GUI, this feature is deactivated by default.Constant resending should only be activated with Nokia 3G SGSN Release 3network elements.

Version Not Supported Response

If CG receives a GTP’ message about an unsupported version, Collector returns aGTP’ Version Not Supported response and the received data in the GTP’ packet isdiscarded.

Redirection messages

CG sends a Redirection Request to alert the GSN that CDRs need to be sent to asecondary CG. This happens when:

. CG is going to be down for a period of time

. Queue becomes full

A GSN sends a Redirection Response back to CG in reply to a RedirectionRequest to inform CG that the request was received.

Data Record Transfer messages

A GSN sends a Data Record Transfer Request to send CDRs to CG. The GSNsends this request without data to query whether a GTP' packet has been received.This is part of the duplicate prevention mechanism.

CG sends a Data Record Transfer Response back to the GSN in reply to a DataRecord Transfer Request to inform the GSN that the request was received.

Echo messages

A GSN sends an Echo Request to confirm that the connection between the GSNand CG is functional.

CG sends an Echo Response back to the GSN in reply to an Echo Request toinform the GSN that the message was received.

GTP’ Collector can be configured to periodically send echo messages toparticular network elements. The interval for resending messages is configurable,but any value below 60 seconds is treated as if no echo requests are sent at all. Bydefault this feature is not active and should not be used unless a particularnetwork element requires it.



Collector subsystem

4.3.3.3 GTP' message log file

GTP’ messages are not written to a file by default. However, there are situationswhen it is useful to see the GTP’ messages CG and network elements have sent.For example, the log can be used to trace the traffic between CG and networkelements and pinpoint possible Ga-interface related errors. If message logging isturned on, it stays on unless turned off manually or the Collector subsystem isshut down.

When message logging is on, all incoming and outgoing messages are writteninto the log file along with the timestamp, source or destination IP address (withport number when it is a network element address), and message type (node aliverequest, an so on).

The GTP’ message logging file name uses the formatgtpmessage_YYYYMMDDhhmmss.log. The file is located in the directory/cdr/work/logs.

The GTP’ message log is a binary file. However, when opened in a HEX editor,the inserted information (timestamp, address, and message type) is readable. Anarrow following the IP address indicates whether the message is incoming oroutgoing:

. "-->" means the following message is to CG

. "<--" means the following message is from CG

4.3.3.4 GTP' duplicate prevention

There may be situations when CG does not respond. Because of CG resiliency,the same CDRs could be charged twice in some situations. In such cases, GTP' 2defines a duplicate CDR prevention mechanism at the protocol level. Theduplicate CDR prevention mechanism is mandated by GTP' 2 and functionswithin the Nokia Packet Core Network.

Each GSN has its internal list of CGs, where one CG is marked as primary andthe other CGs as secondary. If the primary CG does not acknowledge receivingGTP' packets from an SGSN or a GGSN, the network element sends the packetsto one of the secondary CGs. The GTP' packets that the GSN sends to thesecondary CG are flagged as potential duplicates. Therefore, the secondary CGdoes not process these GTP' packets immediately but waits for further notificationfrom the GSN. When the primary CG acknowledges receiving packets again, oneof the following occurs:



. If the primary CG has received the GTP' packets that are marked aspotential duplicates, a response to the GSN query acknowledging that theprimary CG has processed the packets. These flagged packets are thendeleted in the secondary CGs.

. If the primary CG has not received the GTP' packets, an appropriatemessage is sent to the GSN. The flagged packets are then processed in thesecondary CGs.

CG includes a parameter that indicates whether duplicate prevention is performedin CG or in a Customer Care and Billing System (CCBS). Administrators canselect the parameter in the GUI. In CG, duplicate prevention is on by default.

4.3.3.5 GTP' attributes

The main purpose of GTP' protocol is to carry CDRs to CG and enablecommunication between GSNs and CG. GTP' attributes are as follows:

. GTP' specifies certain message types for communicating charginginformation from GSNs to CG.

. GTP' specifies how traffic is redirected from CGs that are not respondingto Data Transfer Requests.

. GTP' specifies how charging of potential duplicate CDRs caused byredirection are prevented.

. GTP' specifies a mechanism for guaranteeing delivery of its packets.

When Collector receives GTP’ packets from the GSNs, they have a sequencenumber attached to them. Collector receiver stores the information on thesequence numbers in its memory and on disk. GSNs and CG use these sequencenumbers as a part of duplicate prevention.

4.3.4 FTP protocol handler

The FTP protocol handler receives CDRs sent over FTP from Nokia ContentAnalyser (CA) Releases 1 and 2, Nokia Online Service Controller (OSC) Release2.0, and 3G SGSN Releases 3 and 4.

The FTP Collector logs in to the network element and fetches all CDR files usingFTP. After all the fetched CDR files have been processed from CA or OSC rel. 2,a new login is made, and those same files are deleted. For 3G SGSN the FTPCollector logs in and renames the processed files. The IP address, port number,username, password, and the source directory must be configured for each



Collector subsystem

network element. In addition for 3G SGSN, a secondary IP address must also beconfigured. The FTP protocol handler checks that the CDR type is either fromCA, OSC rel. 2 or a 3G SGSN. If it is not a CDR type from these networkelements the CDR is discarded. No other validation is performed.

FTP Collector stores the transferred file to the work directory. After the CDRshave been processed, the file is moved into an archive directory. The transferredfile can be used as such for backup purposes, so there is no need to use the rawdata interface when processing CDRs from FTP file.

4.3.5 Nokia Control File FTP protocol handler

The Control File (CF) FTP protocol handler receives CDRs from the NokiaMobile Services Switching Centre (MSC). A control file mechanism is used tocontrol the file transfer between CG and the MSC, and a specific configurationfile needs to be defined for the CF FTP protocol handler through the CLI inaddition to the GUI configuration. The configuration file contains information onCDR filenames and extensions, control file names, and structure of the controlfiles. For details on configuration, see Configuring CF FTP Collectors inCommissioning and Integrating Charging Gateway 4.3.

Nokia Control File mechanism

There are two control files: TTSCOF (VDS Device Data Storage Control File)and TTTCOF (VDS Device Data File Transfer Control File). After the protocolhandler has logged in to the network element, the control files are fetched. TheTTTCOF is fetched only at first login. The protocol handler checks the validity ofthe timestamps in TTSCOF. If there are invalid timestamps, an alarm is raised.

From TTSCOF the protocol handler searches for complete CDR files andcompares the information that was previously read from TTSCOF. According tothe result of this comparison, the protocol handler transfers the completed CDRfiles.

When a data file has been successfully transferred, the current time of the CFCollector is written to the TTTCOF as the transfer time of the data file. If thetimestamp of the corresponding record in the TTSCOF is 2 minutes or less fromthe time in CG, then the timestamp written to the TTTCOF will be the TTSCOFtimestamp + 1 s. After the TTTCOF is updated, the file is moved to back to thenetwork element.

The CF FTP protocol handler sorts the CDR conversion order. The CF FTPprotocol handler renames files in CG to prevent overwriting files with similarnames in CG.



pkic1201

Highlight

pkic1201

Highlight

4.4 Collector converter modules

Before CG is able to start processing the CDR it must be converted to a uniformformat. This is carried out by data converters. The Collector converter modulesdecode and convert raw CDRs into the Field Manipulation Language (FML)format in an FML buffer and adds them to a CDR buffer in the appropriate queue.

The Core subsystem reads the converted CDRs from the Collector's CDR bufferand processes them. Traffica reports are converted and sent straight to a queuespecifically for Traffica to be read by Distributor, by-passing the Core subsystementirely.

The converters are handled as a plug-in module. You define which module to usein each Collector instance through the GUI. Each converter can support certainCDR types and network element versions. The available modules are as follows:

CGNokiaAS41Converter

This module provides fixed-format CDR decoding for CDRs from:

. Nokia Authentication Server Release 4.1

CGNokiaCaTaConverter

This module provides TLV-format CDR decoding for CDRs from:

. Nokia Content Analyser Release 1

. Nokia Content Analyser Release 2

. Nokia Traffic Analyser Release 2

. Nokia Traffic Analyser Release 3

CGNokiaDFConverter1

This module provides fixed-format CDR decoding for CDRs from:

. Nokia 2G SGSN Release 2


. Nokia 2G SGSN Release 3.1






Collector subsystem

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

. Nokia GGSN Release 2

. Nokia OWLAN Release 2

. Nokia Traffic Analyser Release 1.3

. Nokia Traffic Analyser Release 1.4

. Nokia SGSN SG6.0

CGNokiaGGSNTLVConverter




. Nokia GGSN Release 4.1

. Nokia GGSN Release 5.0

. Nokia ISN Release 2.0

. Nokia ISN Release 3.0

CGNokiaIMSConverter


. Nokia PoC Release 1

. Nokia PoC Release 1.5

. Nokia PoC Release 2.0

. Nokia CPS Release 1

CGNokiaOSC2Converter

This module provides CDR decoding for CDRs from:

. Nokia Online Service Controller Release 2.0

CGNokiaSGNTLVConverter







CGNokiaCPS2Converter


. Nokia CPS Release 2

CGNokiaMSCConverter


. Nokia Mobile Switching Products (MSC) Release M13.3 (and older)

. Nokia VoIP Server (NVS)

4.4.1 CGNokiaMSCConverter configuration functionality

If the CGNokiaMSCConverter is used a specific master configuration file isrequired that contains the paths and filenames of the CDR type specificconfiguration files. These CDR type specific control files describe how eachCDR is converted. Thus, every MSC CDR type that is passed to theCGNokiaMSCConverter needs to have a separate configuration file. In this fileeach field of CDR and its position in the CDR has to be described in the samesequence as in the incoming CDR. The FML field name has to be given to thosefields that need handling in CG (and are passed to the Core). When no FML fieldname exists in the configuration file, the field is ignored.

For details on the configuration, see Configuring MSC CDR collecting in CG inCommissioning and Integrating Charging Gateway 4.3.

MSC field conversion functions

In addition a converting rule (conversion function) has to be given for each field.Conversion functions are needed, for example, to make byte order changes, andconversions from BCD to integer for CG’s internal representation. The followingtables describe the conversion functions. If a function name starts with letters DX,it means that byte order is to be converted from DX200 byte order, and the resultput to the FML field the function is operating on. There are two types offunctions, the basic functions and the special functions that can be used inaddition to the basic conversion functions.



Collector subsystem

pkic1201

Highlight

pkic1201

Highlight

Table 6. Basic conversion functions

Function name

Description (all numbers arehexadecimal unless otherwisestated)

B Default function. Copies one or morebytes into the FML field. Can be left outfrom the conversion line.

BCD Converts 1 to 4 BCD bytes to integer, forexample: 54 -> 36.

Amount is taken from the field length:. if length is 2, then a BCD word is

converted: 12 34 -> 4D2. if length is 4, then a BCD double word is

converted 12 34 56 78 -> BC 61 4E

Note, that if field is full of FFs, the field isconsidered as undefined and is notconverted and passed to CGCore.

DX Swaps the byte order of 1 to 4 bytes. Thenumber of bytes is taken from the fieldlength.

For example, the conversion line:

RECORD_LENGTH,SHORT=2,DX

This adds an FML fieldRECORD_LENGTH with value 4660 (dec)from incoming data 34 12.

If there are 4 bytes then result would be:78 56 34 12-> 12 34 56 78

DXBCD Operates as the BCD function, but theDX200 byte swap is performed first, forexample: 34 12 -> 4D2

Note, that if field is full of FFs, the field isconsidered as undefined and is notconverted and passed to CGCore.

DIGITS ,DIGITS(F) Swaps the digits within a byte. If aparameter is given then the charactergiven as parameter is removed from theresult. The resulting FML field must be oftype string.

Example: DIGITS

62 02 03 F6 FF FF FF FF -> 26 20 30 6FFF FF FF FF

Example: DIGITS(F)

62 02 03 F6 FF FF FF FF -> 26 20 30 6



pkic1201

Highlight

Table 6. Basic conversion functions (cont.)

Function name

Description (all numbers arehexadecimal unless otherwisestated)

TIMESTAMP Makes a UNIX timestamp from 5 bcdbytes and a bcd word. The FML fieldmust be of type long or double.

MAS (<parameters>) MAS function is used for making morespecific byte order swaps from DX200data field. Resulting FML field must betype of string. With the parameters byteorder, structure of received field must begiven. Parameters are separated withcolon (:)

Valid parameters are:. B: Takes an octet and makes it to two

hex characters.. W: Swaps the order of two octets. The

result is 4 hex characters.. D: Swaps the order of DX dword

containing 4 octets. The result is 8 hexcharacters.

For example:

CALL_REFERENCE,STRING=5,MAS(W:W:B) 55 44 33 22 11 -> 44 55 22 33 11

The result is 10 character long string inCALL_REFERENCE field.

NUMBERS_TO_ASC Copies field length amount of bytes toFML string field.

Special conversion functions can be given after the basic functions, separatedwith a comma. These special functions are listed in the following table.

Table 7. Special conversion functions

Function Description

DUPLICATE(<fieldname>) Creates a duplicate field.

For example:

RECORD_LENGTH,SHORT=2,DX,DUPLICATE

(REC_L)

CONCAT(<fieldname>) Adds two string fields together.

TRUNCATE(<number>) Truncates string to given size.



Collector subsystem

pkic1201

Highlight

pkic1201

Highlight

4.4.2 Protocol handler usage of converter modules

The protocol handlers can use only certain converter modules. The following listsindicate which converter modules can be used by each protocol handler. You needthis information when, for example, you are configuring Collectors using theGUI.

GTP' Collector

The GTP' Collector uses the following converter modules:

. CGNokiaDFConverter1

. CGNokiaIMSConverter

. CGNokiaCaTaConverter

. CGNokiaAS41Converter

. CGNokiaGGSNTLVConverter

. CGNokiaSGNTLVConverter

. CGNokiaCPS2Converter

FTP Collector

The FTP Collector uses the following converter modules:

. CGNokiaCaTaConverter

. CGNokiaOSC20Converter

. CGNokiaSGNTLVConverter

CF FTP Collector

The CF FTP Collector uses the following converter modules:

. CGNokiaMSCConverter

. CGNokiaDFConverter1



pkic1201

Highlight

pkic1201

Highlight

5 Core subsystem

5.1 CDR processing in Core

Core handles CDR processing and is the subsystem at the heart of ChargingGateway (CG) functionality. The processing logic is completely configurablethrough the graphical user interface. However, a set of pre-built data processingnodes are available which the user can configure to create a data circuit whichcontains the needed data processing logic.

The governing configuration of a data circuit is a rule, a set of configured nodesthat compose the data processing logic that is active at a given time. All the rulesever created are contained in the configuration database.

There are three parameters in the CG.cproperties file that can be used tomonitor Core processing and memory use. These are:

. CoreMemLimitWarn

. CoreMemLimitFlush

. Agg2StatInterval

For details, see CG.cproperties file.

Core toolkit

A software development toolkit is available to build modifications for Core. Withthe toolkit, new data process nodes can be added to the default Core subsystem.For any customization needs, please contact your local Nokia representative.




Core subsystem

pkic1201

Highlight

5.2 Data processing nodes

The data processing nodes make up the data circuit in CG Core. The dataprocessing node can be conceptually viewed as an independent logical processorwith 1 to n input pins and 1 to m output pins. The number of input and outputpins is specific for each node type. CDRs are delivered to the node through one ofthe input pins and processed CDRs are released through one of the output pins.The output pins usually have specific assigned tasks depending on the node. TheInput Interface, Output Interface, and Copier nodes are exceptions: the InputInterface node has no input pins, while the Output Interface node has no outputpins. The Copier node is specific for releasing CDRs, that is, copied CDRs arereleased to all the output pins.

Once the CDRs leave one of the output pins, they enter the input pin of next nodeto which the particular output pin is connected. In this way, the CDRs passthrough the data circuit and are 'processed'. When the CDRs reach the final node,Output Interface, the CDRs leave Core and enter Distributor via a defined POSIXqueue.

The data circuit must have only one Input Interface as the starting node. WhenCollector sends the CDRs to the defined queue, Core reads them and passes themto the Input Interface node. After mandatory pre-processing and validation in theInput Interface, the CDRs are passed to the subsequent nodes according to thedata circuit rule.

The data processing nodes are Unix shared libraries that are loaded into Core atstartup according to the configuration database.

All nodes are loaded as pluggable modules. Unsuccessful operations are logged.Also, if an unsupported configuration option is defined, a log entry is written tothe ULOG at the initialisation stage when the node fetches the correspondingconfiguration.

For detailed node descriptions, see Data Processing Nodes in Charging Gateway4.3.

5.3 Impact of flushes on CDR processing

Flushing can change the expected behaviour of CDR processing, so it needs to beused with great care. The general recommendation is to use as few triggers aspossible, and only use masterflush when absolutely necessary.



pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

5.3.1 Understanding masterflush

Masterflush is an administrative function that empties all CDRs in Core memoryto the Output Interface node. When this flush is executed, it does not stopongoing CDR processing. Those processes (for example, aggregation), arecompleted before the node carries out the masterflush command.

With the introduction of flush periods and expiration flush in release 4.0 ofCharging Gateway, there is no longer any need to use masterflush. The only casewhere it is still needed is when shutting down CG for maintenance or an upgrade.But even in this case, masterflush should not be executed directly. When you runstopcg.sh, masterflush is executed automatically.

If you execute masterflush, you run the risk of breaking your aggregation andcombining processes. If masterflush is executed before a particular flush period isclosed, Combiner cannot combine the CDRs from the incomplete flush period. Inaddition, the remaining CDRs for the flush period that arrive after the masterflushcannot be released by the aggregation node. They remain in the node memoryuntil the next masterflush.

To avoid these problems, you should rely on carefully defined flush triggers. Ifyou need to regularly flush the Core memory, then you should use the expirationflush (expiration time parameter in Aggregator and Combiner nodes) instead ofmasterflush. The expiration flush completely clears node memories of anyinactive sessions and does not cause any conflicts with flush periods.

5.3.2 Understanding flush triggers in Aggregator and Combiner

The flush triggers define how the Aggregator node handles CDRs of a given type.CDRs of type X (for example, S-CDRs) sent by a network element after a flushtrigger event (for example, a tariff change) and before the indication of the nextdefined event form a flush trigger period. If Aggregator has received all X-CDRsfor that period correctly (none are missing), Aggregator will aggregate the X-CDRs for that period. Aggregator, only if configured appropriately, can releasethe CDRs to the Combiner node.

The Combiner node then combines aggregated CDRs of each flush trigger period.For example, consider the case where the user has configured S-CDR version 2 tobe combined with G-CDR version 2 and defined QoS change and tariff change asflush triggers for both types. If no CDRs are missing and both flush trigger eventsoccur once within both S-CDRs and G-CDRs, Aggregator will release the sessionas six flush trigger periods. For S-CDRs, the periods are as follows:



Core subsystem

pkic1201

Highlight

pkic1201

Highlight

. Period 1 from session start to QoS change (S-CDRs)

. Period 2 from QoS change to tariff change (S-CDRs)

. Period 3 from tariff change to session end (S-CDRs)

For G-CDRs, the periods are as follows:

. Period 1 from session start to QoS change (G-CDRs)

. Period 2 from QoS change to tariff change (G-CDRs)

. Period 3 from tariff change to session end (G-CDRs)

The Combiner node then combines the first flush trigger period of S-CDRs withthe first flush trigger period of G-CDRs, the second period of S-CDRs with thesecond period of G-CDRs, and the third period of S-CDRs with the third periodof G-CDRs. This combining is due to the fact that all of the periods have equalnumber flush trigger event occurrences before the actual period.

Combiner combines aggregated G-CDRs with aggregated S-CDRs.

Note

For successful combining, aggregated parts must be released by Aggregator ascomplete flush trigger periods. Because of this, the flush triggers must bechosen carefully. Customers must verify which triggers are relevant in theirservice environment and use only those.

Flush triggers in default Core configuration

Independent of the user's configuration, default triggers include 'Normal release'and 'Abnormal release' as flush triggers. The following triggers are configured forall CDR types and versions in the default data circuit:

. SGSN change

. Management intervention

. Quality of Service change

. Tariff time

. Quality of Service change and SGSN change at the same time

The following triggers should not be configured. They are used by default.



pkic1201

Highlight

pkic1201

Highlight

. Abnormal release

. PDP context release

All flush trigger values are given in the following table.

Table 8. Flush trigger values

Trigger Value

0 PDP context release

1 volume limit

2 time limit

3 SGSN change

4 max. change condition

5 detach

6 management intervention

7 abnormal release

8 Quality of Service change and SGSN change at the same time

9 transaction completed

10 Quality of Service change

11 tariff time

12 cell change

13 session release

14 signal update

15 tariff or time/volume intermediate CDR

16 CAMEL init release

17 inter-PLMN SGSN change

18 Quality of Service for PDP context changed

19 usage of service ended

20 GGSN sent interim message to OCS

22 access type change

23 access time zone change

24 Location change

25 Quota holding time

26 GGSN interim

27 on-demand start



Core subsystem

pkic1201

Highlight

Table 8. Flush trigger values (cont.)

Trigger Value

28 no quota

29 re-authorization

30 MIP deregister

31 idle cleanup

32 MIP register

33 tunnel type change

52 unauthorized requesting

53 unauthorized LCS client

54 position method failure

58 unknown or unreachable LCS client

59 session modification intermediate charging

60 non-multiplexed media component removed

61 multiplexed media component removed

212 intermediate Sa-CDR due to time threshold reached

213 intermediate Sa-CDR due to volume threshold reached

214 intermediate Sa-CDR due to hit threshold reached

215 intermediate Sa-CDR due to change in PDP's access type

216 abnormal release of the last PDP context in session.

242 credit control change

Note

If SGSN_CHANGE is not configured as the flush trigger, other fields likeFIRST_SEQUENCE_NUMBER and LAST_SEQUENCE_NUMBER maynot allow verification of which CDRs were aggregated. In some cases, forexample SGSN, when SGSN_CHANGE happens, RECORD_SEQ_NUM isrestarted from 1.

5.3.3 Example of using Aggregator with SGSN CDRs

A session can be one phone call from a mobile subscriber. There are a number ofCDRs from this one session, and the subscriber may move from one SGSN areato another.



pkic1201

Highlight

pkic1201

Highlight

In this example, there is a mobile subscriber who in the course of a single sessionmoves through three SGSNs, each of which signals a change in tariff (charging)and a Quality of Service (QoS) change. The tariff and QoS changes are defined asflush triggers. The charging begins in SGSN1, continues in SGSN2 and SGSN3.Then, the mobile station user returns to SGSN1, as illustrated below:

Figure 4. SGSNs and charging

SGSN1 sends S-CDRS with sequence numbers 1, 2, 3, 4, and 5. We can refer tothese S-CDRs as 1(S1), 2(S1), 3(S1), 4(S1), and 5(S1). Aggregator detects that 1(S1) began the session, 3 (S1) indicated a tariff change, and 5 (S1) an SGSNchange.

SGSN2 sends 1(S2), 2(S2), 3(S2), 4(S2), 5(S2), and 6(S2). CDR 2(S2) indicateda tariff change. CDR 4(S2) indicated volume limit, and CDR 6(S2) a change fromSGSN2 to SGSN3.

SGSN3 sends 1(S3), 2(S3), 3(S3). CDR 2(S3) indicated a QoS change, and 3(S3)a change from one SGSN to another .The new SGSN is SGSN1 which sends thefollowing S-CDRs: 1(S1), 2(S1), 3(S1), with 3(S1) indicating the end of thesession.

1 3 4 5 6

SGSN change

SGSN change

SGSN change

QoS change

QoS change

Volume limit

Session start

Session end

1 2 3 4 5

123

SGSN1

SGSN3

SGSN2

123

Tariff change

2



Core subsystem

CDRs that are generated by the three SGSNs could arrive in different order. Forexample, the CDRs from the newest SGSN may arrive before the previousSGSN, and some of the CDRs might take an alternative route. From this session,CG may, for example, receive the S-CDRs in the following order:

. SGSN2 CDRs

. SGSN1 CDRs (first group)

. SGSN3 CDRs

. SGSN1 (second group)

. Some CDRs arrived late because of a different route: 3(S1), 5(S1), 3(S2), 5(S2)

As a result of these conditions, the CDRs arrive in the following order:

1(S2), 2(S2), 4(S2), 6(S2), 1(S1), 2(S1), 4(S1), 1(S3), 2(S3), 3(S3), 1(S1), 2(S1),3(S1), 3(S1), 5(S1), 3(S2), 5(S2)

Processing in Aggregator

Based on the example and the order the CDRs were received, processing inAggregator takes the following course:

. 1(S2) is the first CDR received by Aggregator. A shortcut record is storedin the CDR table, and the iCDR pointer (link to iCDR) is set to point to this1(S2).

. The first CDR does not indicate a session start, so an empty place is madefor the starting CDR to the left of 1(S2). Other empty spaces subsequentlyappear for S-CDRs that arrive late and out of the order in which they wereactually generated.

. 2(S2) arrives, and Aggregator determines that the placement in the table isto the right of 1(S2) based on the record opening timestamp.

Since Aggregator detects that 1(S2) and 2(S2) have consecutive sequencenumbers, the records can be aggregated if the record open time stamp of 2(S2) is close enough to the record closing time stamp of 1(S2). Afteraggregation CDR 1(S2) is discarded, and the iCDR pointer of thecorresponding CDR table shortcut is set to point to the iCDR to which theshortcut of 2(S2) was pointing. Upon aggregation, the iCDR is updated tocontain also the information of 1(S2).



The processing continues like this with successive CDRs. With each new CDR,the record is temporarily placed in the CDR type and version specific tables. Firstaggregated with the CDR to the right in the table (if it exists), and thenaggregated with the CDR to the left of the newly arrived CDR in the table, if itexists. If there is a empty place to the left or right of the newly arrived CDR,Aggregator tries to aggregate it with the next CDR after or before the emptyplace. If the aggregation takes place, the empty place and the iCDR that had beenaggregated with another iCDR are deleted.

Other factors that determine placement in the string of CDRs are sequencenumbers and record opening timestamps. Use of the flush triggers may take intoconsideration the empty places in the CDR type and version specific tables, andthe resolution of missing CDRs.

Aggregation is allowed normally under all of the following conditions:

. If the record opening timestamp of the later CDR and record closing timestamp of the previous CDR are close enough

. If the sequence numbers are consecutive

. If the previous CDR did not indicate a flush trigger event

Aggregation is also allowed in cases of SGSN handovers:

. If the record open time stamp of the later CDR and record closing timestamp of the previous CDR are close enough.

. If the previous CDR (CDR from the old SGSN) indicated an SGSNchange, and the sequence number of the latter CDR is 1.

This assumes that the user has not defined SGSN change as a flush trigger(as in this example).

Flush periods

The example session releases the CDRs in five separate flush periods:

. period 1, 1(S1) - 3(S1)

. period 2, 4(S1) - 2(S2)

. period 3, 3(S2) - 4(S2)

. period 4, 5(S2) - 2(S3)

. period 5, 3(S3) - 3(S1)

The following figure illustrates the five periods:



Core subsystem

Figure 5. Flush triggers

For Combiner, Aggregator adds the number of the flush trigger events in the field'FLUSH_TRIGGER_OCCURENCES' as follows:

. 000 for period 1, no preceding flush triggers

. 100 for period 2, one preceding QoS change

. 110 for period 3, one preceding QoS change and one preceding tariffchange

. 111 for period 4, one preceding QoS change, one tariff change, and onevolume limit

. 211 for period 5, two preceding QoS changes, one tariff change, and onevolume limit

The values '000' to '211' of the FLUSH_TRIGGER_OCCURENCES field areconstructed so that each flush trigger corresponds to one position in the string.QoS takes Position 1, tariff change Position 2, and volume limit Position 3, asillustrated below:

PERIOD 1 ,

1 2 3

Recording closingcause: QoS change

PERIOD 2 ,

4 5 1 2

PERIOD 3 ,

3 4

PERIOD 4 ,

5 6 1 2

PERIOD 5 ,

3 1 2 3

SGSN 1 SGSN 2 SGSN 3 SGSN 1

Recording closingcause: Tariff change

CDR sequencenumber

Recording closingcause: Volume limit

Recording closingcause: QoS change

Recording closingcause: session end



Figure 6. Tariff changes and flush triggers

5.3.4 Understanding flushing in Simple Aggregator, Aggregator2, andSmall Aggregator

The flush options in Simple Aggregator, Aggregator2, and Small Aggregator aredifferent to those in the Aggregator. They all share the expiration flush option asin Aggregator. However, flush periods are defined differently, though their impactis the same as in Aggregator.

In Aggregator, flush triggers are configured by selecting them from a predefinedlist of possible triggers. In Simple Aggregator, you do not have individuallyconfigurable flush triggers. Instead, you use a Flush expression (FML Booleanexpressions) to flush CDRs. The Simple Aggregator evaluates all incomingCDRs according to these expressions before aggregation to detect if the previousCDR should be flushed.

PERIOD 1 ,

1 2 3

PERIOD 2 ,

4 5 1 2

PERIOD 3 ,

3 4

PERIOD 4 ,

5 6 1 2

PERIOD 5 ,

3 1 2 3

SGSN 1 SGSN 2 SGSN 3 SGSN 1

One precedingTariff change

0 0 0 1 0 0 1 1 0 1 1 1 2 1 1

No precedingflush triggers

One precedingQoS change

One precedingVolume limit

Two precedingQoS changes

Period specific flushtrigger information

for Combiner

One precedingTariff change



Core subsystem

pkic1201

Highlight

In Aggregator2 you have flush triggers as in the Aggregator. However, you candefine much more complex methods for determining a flush period through theintroduction of two-level aggregation and through the session-aware flush timeoption. Also in Aggregator2 you can configure yourself the fields used to look forflush trigger values. By default the flush triggers are read from fields 'cause forrecord closing' and 'change condition'.

In the Small Aggregator node flushing is highly configurable. In addition to theexpiration flush, you can configure any field(s) in the CDR as flush trigger field(s), and for each field the flush trigger type is chosen from four different types.

For more information, see the related node specific sections in Data ProcessingNodes in Charging Gateway 4.3.

5.4 CdrEvaluator expression syntax

Aggregator2 and Correlator2 use user definable expressions to determine theirprocessing logic. The CdrEvaluator mechanism is used to parse these expressions(text strings). The following table outlines the operators that can be used in theseexpressions.

Table 9. CdrEvaluator expression operators

Logicaloperation

Operator Action

and && Compares two values and returns 1 ifneither of them is 0.

or || Compares two values and returns 1 ifat least one of the values is 1.

subtract - Subtracts the second value from thefirst value.

add + Adds one value to another.

multiply * Multiplies one value by another.

divide / Divides the first value by the secondvalue.

equal == Returns 1 if two values are equal.

not equal != Returns 1 if two values are not equal.

greater than > Returns 1 if the first value is greaterthan the second one.

smaller than < Returns 1 if the first value is smallerthan the second one.



pkic1201

Highlight

pkic1201

Highlight

Table 9. CdrEvaluator expression operators (cont.)

Logicaloperation

Operator Action

field existence <field name>

(Field name usedwithout operators.)

Returns 1 if the field exists in thecontainer.

absolute value abs(<value>) Returns the absolute value of thegiven parameter.

Expressions are defined per CDR type ID. The CDR type ID is not part of theexpression entered in the GUI. It is selected from a drop-down list before enteringthe expression.

When writing your expressions, keep the following guidelines in mind:

. Field names must be written in upper case.

. Constant values must be given as integers.

. Keep expressions as simple as possible. Processing speed is directly relatedto the complexity of the expressions.

Parsing order

CdrEvaluator parses the expressions left to right. If the order needs to be changed,parentheses must be used in the expression. For example, the expressionRECORD_TYPE==18&&RECORD_TYPE_VERSION==7 is evaluated as follows(RECORD_TYPE equals 18 and RECORD_TYPE_VERSION equals 7):

1. 18==18 (result is 1)

2. 1&&7 (result is 1)

3. 1==7 (result is 0)

The end result of the expression returns the value 'false'.

For correct parsing, the expression should be written (RECORD_TYPE==18)&&

(RECORD_TYPE_VERSION==7). The parsing order is then:

1. 18==18 (result is 1)

2. 7==7 (result is 1)

3. 1&&1 (result is 1)



Core subsystem

pkic1201

Highlight

pkic1201

Highlight

The end result of the expression returns the value 'true'.

Expressions for comparing two CDRs

Some expressions, such as the sorting and consecutiveness expressions inAggregator2, need to compare two CDRs. The CDR can be specified in theexpression by using cdr1 and cdr2 parameters. For example, the followingexpression returns 'true' if the GGSN_ADDRESS fields in two CDRs are equal:

cdr1:GGSN_ADDRESS==cdr2:GGSN_ADDRESS

5.5 FML boolean expressions

The FML (Field Manipulation Language) boolean expressions are used in theconfigurations for Validator, Router, and Small Aggregator data processingnodes. It is one of the three expression syntaxes used in CG. The others are theField Modifier Expression Language (FMEL) and the CdrEvaluator expressionsyntax.

Here you find the basic principles for using the FML boolean expressions in theCharging Gateway.

5.5.1 Operators in FML boolean expressions

FML has the basic operators for performing unary, multiplicative, additive,relational, comparison, and logical boolean operations.

Table 10. Operators used in FML boolean expression in CG

Type Operators

Unary +, -, !, ~

Multiplicative *, /, %

Additive +, -

Relational <, >, <=, >=, ==, !=

Equality and matching ==, != (numeric)

%%, !% (strings)

Exclusive OR ^

Logical AND &&

Logical OR | |



pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

5.5.2 Using FML boolean expressions

Any field that is referenced using an FML boolean expression must exist in thefield table. For the purposes of the Charging Gateway data processing nodes, theFML boolean operators are used to evaluate expressions to the logical values trueor false. These are used in the nodes to route CDRs or to configure flushexpressions.

Using FML with regular expressions

When using equality operations with strings, the right-hand side is evaluated as aregular expression. This expression must be a quoted string. You can use theregular expression to perform a wide variety of string comparisons. The wholeuse of regular expressions is beyond the scope of this documentation, but hereyou can find some basic principles for using regular expressions for makingstring comparisons in CG.

Table 11. Operations with regular expressions

Operation Explanation

Characters A character represents itself, with thefollowing exceptions.. The special characters: . * + ? | ( ) [ {

and \\. The characters: \\ (newline), \\t (tab), \\b

(backspace), \\r (carriage return) and \\f(formfeed)

To represent a special character as itsnon-significant self, use \ before thecharacter, for example, \+

[Range] Use [] to represent a range of characters,for example:. Numbers from 0 to 9: [0-9]. The alphabet from a to z (capital and

small letters): [a-zA-Z]

RE* Zero or more occurrences of RE.

RE+ One or more occurrences of RE.

RE? Zero or one occurrence of RE.

RE{n} n occurrences or RE (n inclusivelybetween 0 and 255).

RE{m, n} m through n occurrences of RE.

(RE) Precedence using quotation.

Example Grouping CDRs using a simple string comparison



Core subsystem

pkic1201

Highlight

This example shows how to group all the numbers beginning with 040 in theSERVED_IMSI field. The numbers can be of any length, and they can contain thenumbers from 0 to 9.

SERVED_IMSI%%'040[0-9]*'

The served IMSI is a string field, thus the string comparison operator %% mustbe used, and the number must be enclosed in quotation marks ' '. The value rangeis denoted as [0-9]. This can recur zero or more times, which is denoted using *.

If the field value could contain any characters after '040', then the any charactersign . (dot) should be used.

SERVED_IMSI%%'040.*'

Example Using regular expressions in an FML expression

To add other conditions to the FML expressions containing regular expressions,you can simply add it to the expression.

RECORD_TYPE == 18 && SERVED_IMSI%%'040.*' &&(RECORD_OPENING_TIME <= RECORD_CLOSING_TIME)

This evaluates to true only if the record type is 18, the served IMSI begins with040 followed by anything, and the record opening time is smaller than the recordclosing time.

Validating and routing CDRs

The validating and routing of CDRs in Core node processing is based on fieldvalues. Below you find some examples of FML Boolean expressions used invalidating and routing along with explanations.

(SGSN_ADDRESS && SGSN_ADDRESS !% '0*' )

This expression returns true, when the SGSN_ADDRESS field exists and itcontains something else than just zeros. The field is of type string so stringequality operator must be used.

(RECORD_TYPE_VERSION == 45) && !(SGSN_ADDRESS &&SGSN_ADDRESS !% '0*' )

This expression returns true, when the record type version is 45 and theSGSN_ADDRESS does not exist or it is only zeros.



pkic1201

Highlight

pkic1201

Highlight

(CHARGING_ID && (CHARGING_ID > 0 ))

This expression returns true when the charging ID field exist and it is greater thanzero.

5.6 Provided data circuits

The Charging Gateway Core provides several data circuits that you can use as abasis for CDR processing from different network elements. These rules are allpre-installed into Charging Gateway 4.3.

5.6.1 Default main data circuit rule

The default main data circuit rule is configured so that it can handle CDRs fromthe following:

. GPRS rel. 2 (2G SGSN rel. 2 and GGSN rel. 2)

. GPRS rel. 3 (2G SGSN rel. 3, GGSN rel. 3 and 4)

. 3G rel. 1 (3G SGSN rel. 1 and GGSN rel. 2)

. 3G rel. 2 (3G SGSN rel. 2, GGSN rel. 3 and 4)

. GGSN rel. 5.0

. 3G SGSN rel. 3

. ICD rel. 1.1

. ICD rel. 3.0 (GGSN rel. 4.1, TA rel. 2.0, CA rel. 2.0)

The default rule uses the following process logic (#N represents the node IDwithin the rule):

. #1 Input interface

. #2 First Validator - validates CDRs and routes invalid CDRs to #5 (defaultoutput node for valid CDRs is #3)

. #3 Second Validator - validates CDRs after first Validator and routesinvalid CDRs to #6 (default output node for valid CDRs is #4)

. #4 Third Validator - validates CDRs after second Validator and routesinvalid CDRs to #7 (default output node for valid CDRs is #8)

. #5-7 Concentrators - route to #25 (output for discarded CDRs)



Core subsystem

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

. #8 Router - routes NICD-CDR to node #26, hot billing CDRs to node #9,and M-, SMS-MO-, and SMS-MT-CDRs to node #21. All others are routedto node #10 (default output).

. #9 Output for hot billing CDRs.

. #10 Router - routes to nodes #11-14 for aggregating (and combining).Routing method is based on the charging tunnel type (configured manuallyafter system installation). Default output to the first combiner is present inthe circuit.

. #11-14 Aggregators and #15-18 Combiners arranged in pairs - aggregatesand combines S- and G-CDRs, configured to support GPRS rel. 2 (#11and#15), GPRS rel. 3 (#12 and #16), 3G rel. 1 (#13 and #17), 3G rel. 2 (#14and #18). Ignored, partial and uncombined CDRs are routed throughConcentrator #19 to Router #21, or straight to Router #21.

. #15-18 Combiners - configured to support all the GPRS and 3G elements.Each Combiner is configured for one S- and G-CDR type version. All datais passed to node #20.

. #19 Concentrator - to Router #21

. #20 Concentrator - to Router #21.

. #21 Router - routes duplicated CDRs to node #25, default output to node#22. Connections to nodes #23, #24 (conditions for routing need to beconfigured after system installation)

. #22-26 Output - output nodes support the following output formats: CGrel. 3.0, 3G rel. 2, CG4.0 discarded, and ICD rel 1.1).



pkic1201

Highlight

Figure 7. Default main data circuit rule

5/ Concentrator

1/ Input

2/ Validator

3/ Validator

4/ Validator6/ Concentrator

10/ Router - charging tunnel type routing

13/ Aggregator3G R1

7/ Concentrator

9/ Output

26/ Output (ICD)

14/ Aggregator3G R2

12/ AggregatorGPRS R3

11/ AggregatorGPRS R2

18/ Combiner3G R2

17/ Combiner3G R1

16/ CombinerGPRS R3

15/ CombinerGPRS R2

20/ Concentrator 19/ Concentrator

21/ Router

24/ Output 23/ Output 22/ Output25/ Output(discarded)

8/ Router



Core subsystem

pkic1201

Highlight

5.6.2 Sample data circuit: record type rule

This sample rule serves as an example of how to process CDRs based onRECORD_TYPE.

. #1 Input Interface

. #2 First Validator - validates CDRs and routes invalid CDRs to #5 (defaultoutput node for valid CDRs is #3).

. #3 Second Validator - validates CDRs after first Validator and routesinvalid CDRs to #6 (default output node for valid CDRs is #4).

. #4 Third Validator - validates CDRs after second Validator and routesinvalid CDRs to #7 (default output node for valid CDRs is #8).

. #5-6 Concentrators - route to #7 (output for discarded CDRs)

. #7 Output Interface for discarded CDRs

. #8 Router - routes G- and S-CDRs to node #9 for aggregating. All othersare routed to node #11.

. #9 Aggregator2 aggregates S- and G-CDRs. configured to support: G-CDR from GGSN release 2 through 5.0, 2G SGSN S-CDRs from 2GSGSN release 2 through 3.1, and S-CDRs from 3G SGSN release 1through 3. Successfully aggregated CDRs are routed to node# 10, others tonode# 11.

. #10 Combiner combines the correctly aggregated G- and S-CDRs. Anycombination of the above mentioned G- and S-CDRs can be combined. AllCDRs are routed to node# 11.

. #11 Router - basic configuration routes all CDRs to node #12.

. #12 Output - output to distributor primary queue



pkic1201

Highlight

Figure 8. Rule for record-type-based processing

5.6.3 Sample data circuit: ICD rule

This rule serves as an example on what could be done with CDRs generated bythe ICD network elements (such as Traffic Analyser).

5/ Concentrator

1/ Input

2/ Validator

3/ Validator

4/ Validator

6/ Concentrator

7/ Output 8/ Router

9/ Aggregator 2

11/ Router

10/ Combiner

12/ Output



Core subsystem

pkic1201

Highlight

pkic1201

Highlight

In this data circuit, the S- and G-CDRs are aggregated in one Aggregator2 nodeand combined after that. The Sa-CDRs and Ta-CDRs are aggregated withseparate Aggregator2 nodes. CA-, M- and SMS-CDRs are only validated, with nofurther processing, before they are sent to the Output Interface node.

5.6.4 Sample data circuit: IMS rule

This data circuit rule serves an example of what could be done with CDRsgenerated by IMS (CPS and PoC). The CPS CDRs are only validated. For PoCCDRs, some types are aggregated with Simple Aggregator. The aggregated typesof PoC CDRs are OTO, OTT, GTO, GTT, GFO, GFT. (Note that the PoC servercan be configured to do the aggregation by itself.) The aggregation in this draftcircuit is for such case where this PoC does not do its own aggregation.

5.6.5 Sample data circuit: MSC rule

This data circuit is designed to aggregate SMMO- and MOC- CDRs.

Figure 9. Sample MSC data circuit

The main operation principles of the nodes are listed below:

2/ Validator

4/ Router

6/ SmallAggregator

1/ Input-Interface

3/ Output-Interface

5/ Output-Interface

7/ SmallAggregator

8/ Output-Interface



pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

. #1 Input interface - reads CDRs from the collector_nok_cf-core queue. The'prefix fields' is not enabled.

. #2 Validator - validates MSC CDRs and routes invalid CDRs to node #3and valid CDRs to node #4.

. #3 Output interface - Output interface to Discarded queue.

. #4 Router - routes hotbilling CDRs to node #5, SMMO-CDRs to node #6and MOC-CDRs to node #7. All other CDRs are routed to node #8.

. #5 Output interface - Output interface to hotbilling queue.

. #6 Small Aggregator - counts the amount of SMMO-CDRs that are sentfrom each CALLING_NUMBER and inserts the result into theSMALL_AGGREGATOR_COUNT_01 field. The CDRs are routed tonode #8.

. #7 Small Aggregator - aggregates MOC-CDRs. The CDRs are routed tonode #8.

. #8 Output interface - Output interface to the Primary queue.

5.6.6 Sample data circuit: CPS Rel. 2 rule

This data circuit is designed to aggregate, combine, and correlate P-CSCF-CDRs,S-CSCF-CDRs and rel 5. G-CDRs. For the circuit to work, CPS has to createboth P-CSCF-CDRS and S-CSCF-CDRs.



Core subsystem

pkic1201

Highlight

Figure 10. Sample CPS Rel. 2 data circuit

The main operation principles of the nodes are listed below:

. #1 Input interface -reads CDRs from the collector_nok_gtp-core queue.The CDR identifications are used for P-CSCF-CDR and S-CSCF-CDR.The 'prefix fields' option is enabled due to G-CDRs.

. #2 Validator - validates CPS CDRs and routes invalid CDRs to node #4and valid CDRs to node #3.

7/ Output-Interface

5/ Aggregator2

4/ Concentrator

2/ Validator

3/ Validator

1/ Input-Interface

6/ Output-Interface

8/ Router

9/ Correlator2

10/ Router

11/ Correlator2



pkic1201

Highlight

. #3 Validator - validates (second level validation) CPS CDRs and routesinvalid CDRs to node #6 and valid CDRs to node #5.

. #4 Concentrator - routes CDRs to node #6

. #5 Aggregator2 - aggregates P-CSCF-CDRs, S-CSCF-CDRs and rel 5. G-CDRs. Correctly aggregated CDRs are directed to node #8. Others to node#7

. #6 Output interface - Output interface to the Discarded queue.

. #7 Output interface - Output interface for the processed CDRs.

. #8 Router - routes Rel 5. G-CDRs to node #11 and P- and S-CSCF-CDRsto node #9. All other CDRs are routed to node #7.

. #9 Correlator2 - moves fields from S-CSCF-CDRs to P-CSCF-CDRs.Only one P-CSCF-CDR receives fields from one delivering S-CSCF-CDR,and the delivering S-SCSF-CDRs are deleted. The resulting CDRs have theRECORD_TYPE_ID of 99 (N-CDRs or NC-CDRs). Successfullycorrelated CDRs are forwarded to node #10 and the rest to node #7.

. #10 Router - routes CDRs with RECORD_TYPE_ID: 99 andCORRELATION_ALLOWED: 1 (TRUE) for correlation with G-CDRs innode #11. Other CDRs are routed to node #7.

. #11 Correlator2 - moves charging information from G-CDRs to N-CDRs.The G-CDRs are released to the output immediately after storing the fields.Only one receiving type N-CDR receives fields from one delivering G-CDR. The CDRs are routed to node #7.

Use the FML to TLV converter in the Distributor when processing CPS rel. 2CDRs in CG.



Core subsystem

pkic1201

Highlight

6 Distributor subsystem

6.1 Overview of Distributor subsystem

The Distributor subsystem logically follows the CDR processing in Core. TheFigure Architecture of CG illustrates the position of Distributor in ChargingGateway. This subsystem converts CDR data from the CG-internal format to anexternal format and transfers CDRs to post-processing systems.

The Distributor subsystem is divided to the following components:

. Main application

. Data converters

. Protocol handlers

. Distributor APIs (DAPIs)

Each Distributor instance is constructed from the components of the subsystem.Each Distributor instance interfaces with a single queue or several queues if theTraffica converter is used. For a description of the architecture, see the FigureDistributor architecture.



Distributor subsystem

pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

Figure 11. Distributor architecture

Distributor operation

The Distributor subsystem operates as follows:

1. Distributor reads required database parameters from the configuration file,CG.cproperties.

With these parameters, Distributor can read its configuration fromdatabase. There are following types of parameters:. Protocol-related parameters. DAPI parameters that are Distributor-specific, such as, queue

parameters, the data converter name and protocol plug-in name. Parameters that define the format of the output CDRs, CDR field use

and formatting, output file naming, and file location.

When parameters are read and set, Distributor loads data convertermodules and the protocol handlers for data sending. Distributor also checksfor the existence of the FTP NOK file and the sequence number files. If theneeded sequence number files do not exist, the Distributor creates them.

2. The Distributor reads CDRs from the queue one at a time.

When a CDR is read from the queue, the CDR is converted from FML tothe external data format. Distributor also updates the corresponding KeyPerformance Indicator (KPI) every time one CDR is read from the queueand after the CDR is converted to the output format. When a threshold isexceeded, the output file is closed. Header and trailer for the CDR file maybe generated. Trailer and header generation is an optional feature.

CGinternalinterface

Administrator

main application

Converter

post-processingsystem

Protocolhandler

DAPI

DAPI



pkic1201

Highlight

3. When the CDR file has been generated, it is sent to a post-processingsystem via a specific protocol.

Each protocol has its own methods for performing data transfer. Users canconfigure the following Distributor properties through the GUI:. Format, fields, and field settings for the output CDR format.. Output file naming.. Protocol specific parameters.. Header and trailer information.

If the data sending to a post-processing system succeeds, the KPI counterfor outgoing CDRs is incremented.

Distributor toolkit

A software development toolkit is available to build modifications for Distributor.With the toolkit, new output data converters and interfaces (new protocols) fornew post-processing systems can be added to the default Distributor subsystem.The toolkit consists of base classes from which the new converter and protocolhandler modules must be inherited. The base classes communicate with the mainapplication using the CG internal interface. For any customization needs, pleasecontact your local Nokia representative.


6.2 Distributor main application

When the Distributor starts up, the main application reads in configurationparameters from the configuration database. Based on these parameters, theoutput format for the Distributor is set. The main application also loads the dataconverter and protocol modules. When all components have been loaded,Distributor will start reading CDRs from the queue(s).

6.2.1 Support for headers and trailers

Output files can also carry information in headers and trailers. Headerinformation is stored at the beginning of an output file and trailer information atthe end of the output file. The same fields are available to headers and trailers.The information contained in the headers and trailers is highly configurable. Forexample, users can decide on the order of fields and the length. Users can alsodecide whether or not to use headers or trailers at all.




pkic1201

Highlight

pkic1201

Highlight

The field length is configurable. If the value does not fit in the configured lengthof the field, the extra characters are dropped and a debug level 1 message iswritten in the log.

. Combined length

This includes the length of the header or trailer. At the same time, users canselect whether or not the field is present and its length. For example, whenthe length is specified as 4 and the header is 200 characters in length, thevalue would be set at 0200.

. Opening time

This is a 14-character time stamp that indicates the time the header wascreated and, therefore, the time the file was created. The format of field isYYYYMMDDhhmmss (year, month, day, hours, minutes, seconds) and ispresented in local time. The time stamp in the file name is in universaltime.

. Closing time

This time stamp format is the same as the opening time. The closing timeindicates the time of the last CDR.

. Number of CDRs

This field indicates the number of CDRs in the file. The length is alsoconfigurable.

. First sequence number

This field contains the sequence number of the first CDR in the file.

. Last sequence number

This is the same as the first sequence number except that the sequencenumber is the number of the last CDR.

. Closing cause

This field contains the reason for file closing. The file can be closedbecause the limit number of CDRs has been reached or because the timelimit for the keeping the file open has been reached. The number of CDRsis indicated in maxamount, and the time limit is indicated in timelimitin the header or trailer.

. CDR types



pkic1201

Highlight

This field contains all the CDR types that are in the file. If this field is used,the record number of each CDR is read, and a table is generated thatcontains all the different record types. The maximum number of theserecord numbers is configurable and for each type, three digits are reserved.If, for example, the amount is set to 3, and there is only one type of CDR,with the record type 19 in the file, the field will look like this: 019000000.

. CDR size

This field contains the number of characters in a single CDR. For example,if CG rel. 3.0 output format is used, the value is set at 843.

. Output format name

This field is the name of the output format from the configuration database.The length of the field is configurable.

. Distributor name

This field is the name of the Distributor from the configuration database.The length of the field is configurable.

6.2.2 Numbering outgoing CDRs and files

The Distributor numbers outgoing CDRs and output files by using sequencenumbers stored in specific sequence number files. There is a sequence number forthe CDRs of each Distributor, a global file sequence number for all the files sentfrom the all the Distributors, and a Distributor-specific output file sequencenumber. The file sequence numbers for the output file naming can be configuredthrough the GUI. Below are explanations on how the sequence numbers work,and which files they use.

CDR Sequence number file

Each Distributor has a sequence number file that is located in the /opt/cg/<release>/cfg/ directory. The file is named Distr_XXX.seq, where XXX isthe Distributor ID.

This file stores the CDR count. This number increases by one after each handledCDR. The number is inserted to the RECORD_SEQ_NUM field of the CDR.When the Distributor is shutdown, the sequence number is stored to the sequencefile. At start-up the sequence number is reset. If the file does not exist theDistributor creates and resets it. The sequence number increases until it reaches999 999 999, and after that it starts from one again.




pkic1201

Highlight

pkic1201

Highlight

Global file sequence number file

Global file sequence numbering among all Distributor queues (on a single server)provides a means to verify that all generated output files are received from theCG. The sequence numbers are allocated at the time of file transmission.

A single file, Distr_global_file.seq, is created in the directory /opt/cg/

<release>/cfg/, and can be accessed by all Distributors running on a givenCG server that have global file sequence numbering included in their output filenaming.

The file contains the next number in the sequence. Whenever a Distributor needsa new sequence number, the Distributor does the following:

1. Opens and locks the file

2. Reads the next sequence number from the file

3. Overwrites the previous sequence number with the next increment

If the maximum sequence number (defined by the configured length of thenumber in digits) is exceeded, the Distributor overwrites the previoussequence number with the configured sequence starting value.

4. Releases the lock and closes the file

The length of the number stored in this file is the number of significant digits.There is no left-padding with zeroes. Through the GUI you can configure thestarting number (0 or 1) and the length that is seen in the filename. The GUIconfiguration does not change the actual counter value length in the file, only thelength at which it is presented.

File sequence number file

Each Distributor has a file sequence number file that is located in /opt/cg/

4.3/cfg/ directory and named Distr_file_XXX.seq where XXX is theDistributor ID.

When a Distributor is shutdown, the sequence number is stored to the file. If theDistributors are configured to reset the file sequence numbers at start up(configurable through the GUI), they overwrite the sequence number in the filewith one, and restart the count. Otherwise the Distributor continues the countfrom the value stored into the file from previous operation.

The number is incremented until it reaches 999.999.999 and then starts againfrom 1. The GUI configuration does not change the actual counter value length inthe file, only the length at which it is presented.



pkic1201

Highlight

pkic1201

Highlight

6.2.3 Support for multiple output formats

Distributor supports the option of sending CDRs in more than one output format.This functionality makes it possible for one Distributor instance to send CDRs inseveral different output formats according to configurable rules. Thus it ispossible to use fewer Distributor instances.

Note

This functionality reduces the performance of the Distributor instanceconsiderably.

Only one CDR file per Distributor instance is still used. The CDRs formatted todifferent output formats are in the same file in random order. It is up to the post-processing system to interpret the multiple formats and correctly access the fieldsand their values.

The rules are collected into rule sets that one or more Distributor instances canuse. The rules themselves consist of four components:

. Order number. The smaller the order number, the higher the priority of therule. The comparison of the field name to the field value is made in thisorder. When the first match is found, not other rules are checked.

. Field name. The name of the field used in the comparison. WhenDistributor receives a CDR and multiple output format is used, it checkswhether any of the fields specified here are in that particular CDR. If a fieldis found, its values is read.

. Field value. The value that the field must have for the rule to apply.

. Output format. The resulting output format if the rule matches

Example Example of a rule set

Table 12. Multiple output rule set

Ordernumber

Field name Field value Outputformat

1 RECORD_TYPE 18 301

2 RECORD_TYPE 99 298




pkic1201

Highlight

pkic1201

Highlight

If the above rule set is used, all the CDRs would be checked for their RecordType. If the value matches with rule one or two, the corresponding output formatwould be used. If neither rule matches, the Distributor reverts back to defaultoutput format.

6.3 Distributor converter modules

The Distributor converter module converts CDR data from FML format to agiven external format, such as ASCII. The converter module also formats theoutput CDR. CG provides four conversion modules:

. FML to ASCII converter (fml2ascii.sl)

. FML to XSV converter (fml2xsv.sl)

. FML to TLV converter (tlvascii.sl)

. Traffica converter (trafficaconverter.sl)

Each converter module is a dynamically loaded library which is loaded when theDistributor is started.

The converter reads the output format from the database. The output formatdefines which fields are written to the output. The field information that is storedin the database includes field length, field type, padding character, and alignment.The padding character is the character that fills the field until it reaches the lengthdefined. Allowed characters are:

. '0' is zero.

. 'F' is character F.

. ‘S’ is space.

. ‘T’ is time stamp. If this padding character is used, the value is changed toUniversal Time Coordinated (UTC). This is only used in long type fields,and the field length should be 14.

. 'L' is local time stamp. The padding character is like 'T', but the time isshown in local time, including daylight savings adjustments.

. ‘H’ is hexadecimal conversion. This is only used in long and short fields.



pkic1201

Highlight

pkic1201

Highlight

6.3.1 FML to ASCII converter

The FML to ASCII converter module converts FML-formatted CDRs to theASCII format. Each field in the output format is specified by parameters whichdefine the format of the field. The parameters are: field size, padding character,type, and alignment. The FML to ASCII converter transforms the FML-formattedCDR fields based on these parameters to ASCII format.

For example, if the field in FML has values “ABCDEF” and "GHIJKL", theoutput size is 10, padding character is “space”, the type is string, and thealignment is "right" for both fields, the resulting output is:

" ABCDEF GHIJKL"

All the fields are placed one after another into the file without separators.Between CDRs there is a line break, that is, one line corresponds to one CDR.

6.3.2 FML to XSV converter

The FML2XSV converter module converts FML-formatted CDRs to ASCIIformat with a configurable field separator. The functionality is similar to that ofthe FML2ASCII converter. Each field in the output format is specified byparameters that define the format of the field. The parameters are field order andformatting, field separator character, string field quoting (" "), and separator andquote character escaping (for example, if the separator is *, then inside a field it ismarked \*).

6.3.3 FML to TLV converter

The purpose of the FML to TLV converter is to convert the incoming CDRs inFML to a Type Length Value (TLV) output. Each CDR is converted to an ASCIIstring on a single line. The CDRs are separated by a new line. Every field in thefielded buffer is read in the order they are presented.

Their type or tag, acquired during initialisation, is placed first in the output string,followed by the length of the value part, and then the value itself. The values ofsome numerical fields can have some operations performed on them. Some (shortand long) fields can be converted to hexadecimal, and some (long) fields can bepresented in two different timestamp notations (local and UTC). The timestampsuse the format YYYYMMDDhhmmss.




pkic1201

Highlight

pkic1201

Highlight

pkic1201

Highlight

These rules are stored in the database along with the tag and the name of the field.Also if the field in the buffer is a pointer to another buffer, or a separate bufferitself, the values in the buffer/pointer are preceded by the buffer/pointer fields tag,followed by the length of the entire content of the buffer/pointer in plain ASCII,and the individual fields in the buffer/pointer in TLV . This allows for containerinformation to be passed as a clearly identified entity inside the CDR.

If a field is encountered that has no entry in the database or is marked as disabled,the field is skipped and not present in the converted output.

As the FML to TLV converter does not use output formats, the GUI configures anempty output format named ‘None’ for Distributors that are configured to use theFML to TLV converter.

6.3.3.1 TLV type values

The TLV types or tags are in the datadase, and although they are configurable, thefields are assigned the same values as in cg_cdr.tbl and cg_pref_cdr.tbltables excluding the base value (10000).

When new fields are added to the field tables the fields should be assigned TLVtags as well. This can be done through the CG GUI.

It should be noted that the TLV tags used by the FML to TLV converter have noconnection to TLV tags used by Collector converters.

6.3.3.2 TLV encoding rules

A TLV field consists of three parts: Type, Length, and Data. The Data part in aTLV field is variable. However the Type and Length parts are, by default, onebyte (two characters in hexadecimal notation), although there can be exceptionsto this. The two parts have particular encoding rules.

Type encoding

The Type for any TLV field is by default 1 byte. This means there are a maximumof 256 different field Types. However, in practice there are 255, because type 0 isnot used to identify a field Type. Each field has a reserved number that is definedin the configuration database. Value 0 can be used to be extend the number oftypes. If the first byte of the Type field is set to 0, it means the Type continues inthe second byte. This rule is recursive: if the second byte is also 0, the Typecontinues in the third, and so on. For example, Type 01 (encoded in 1 byte) isdifferent than type 0001 (encoded in 2 bytes).



pkic1201

Highlight

pkic1201

Highlight

Length encoding

The Length for any TLVencoded field is also by default 1 byte. As with the Typeencoding, this means the maximum Length value is 255. Value 0 is not a validlength, (if the TLV field has no data [length == 0] then it should not be sent atall). Value 0 is also used here to extend the Length value range.

Example Length and type encoding

For example, the encoding for Length of a field with a length of 854 is:

854 = 255*3 + 89 --> 000 000 000 089 --> (0x) 00 00 00 59 --> 00000059

or

length = 255 x (n-1) + value n

6.3.3.3 Output CDR conversion examples

The following are two short examples of how the TLV conversion works.

Example Normal CDR (no buffers or buffer pointers)

The input CDR has the following field values:

. RECORD_TYPE: 18

. CHARGING_ID: 10

. RECORD_SEQ_NUM: 448827

The converted output CDR would be:

0302180B02105B06448827

Type tags:

. 03 for RECORD_TYPE

. 0B for CHARGING_ID

. 5B for RECORD_SEQ_NUM

Length tags:




pkic1201

Highlight


. 02 for CHARGING_ID

. 06 for RECORD_SEQ_NUM

Example CDR Containing a buffer

A CDR with following field values:

. RECORD_TYPE: 18

. CHARGING_ID: 10

. RECORD_SEQ_NUM: 448828

. DURATION: 10 (inside a test buffer)

The converted output CDR would be:

0302180B02105B06448828000000EB065E0210

Type tags:


. 0B for CHARGING_ID

. 5B for RECORD_SEQ_NUM

. 000000EB for TEST_BUFFER

. 5E for DURATION

Length tags:


. 02 for CHARGING_ID

. 06 for RECORD_SEQ_NUM

. 06 for TEST_BUFFER

. 02 for DURATION



pkic1201

Highlight

pkic1201

Highlight

6.3.4 Traffica converter

The Traffica converter module converts the CG-internal Traffica format to theformat that is sent to Traffica using User Datagram Protocol (UDP). Thisconversion includes adding the Traffica report header fields from the FML formatto the output format header, as well as adding the Binary Coded Decimal (BCD)time and date fields with the current time to the header.

The FML fields that are used are the following:

. TRAFFICA_CDR_TYPE

. TRAFFICA_REPORT_ID

. TRAFFICA_REPORT_LENGTH

. TRAFFICA_REPORT_COUNT

. TRAFFICA_EVENT_COUNT

. TRAFFICA_BINARY

This field includes raw CDR data in Traffica format.

The raw data generated by the Traffica converter includes a single byte in thebeginning that specifies the CDR type ID, CdrTypeId, followed by the Trafficareport to be sent to Traffica over UDP/IP.

When the Traffica converter is selected for use through the GUI, the outputformat is automatically set as ‘Traffica Output CDR format’.

6.4 Distributor protocol handler modules

The Distributor protocol handler modules send output CDR files to post-processing systems using a particular protocol.

CG supports FTP, file, hot billing, and UDP protocols.

File naming

The file naming of Distributor output files is highly configurable. The file namecan be created from following parts:

. Configurable filename part

This can be anything that is at maximum 64 characters. The name isDistributor specific.




pkic1201

Highlight

. Process number (the Distributor ID)

. Time stamp

The Time stamp element specifies the file creation time in GM (or UTC)time. The format is YYYYMMDDhhmmss. It should be noted that the filewith the time stamp is created at either CG start up or after the old CDRfile closes, and a new CDR arrives. Thus, the time stamp does not indicatethe time when the file was moved to the destination folder.

. Local time stamp

The Local time stamp element is identical to the Time stamp, except thatthe time is given in local time instead of GM time.

. Sequence number or global sequence number (not both).. The Global sequence number is a CG-specific sequence number. All

Distributors that are configured to use this naming element have acommon sequence number. The length shown in the file name (1-9)and the starting value (0 or 1) are configurable through the GUI. Thesequence number is given to the distributor instance when the file isclosed and moved to the destination folder or transferred via FTP tothe CCBS

. The sequence number is a Distributor-specific sequence number.The length shown in the file name (1-9), and whether it is restartedat start up, are configurable through the GUI.

For more information on sequence numbers, see Numbering outgoingCDRs under Distributor main application.

. File extension (*.abc)

The user can put these parts in any order, using one or all of them. The resultcould be, for example:

processed_00012_101202123523.cdr

However, if the output CDR search feature is used, then the file name has to be ofthe form:

<Anything>_<Process nr.>_<Timestamp>.cdr

For details, see Searching rawdata and output CDRs in Operating andMaintaining Charging Gateway 4.3.



pkic1201

Highlight

pkic1201

Highlight

6.4.1 File Transfer Protocol (FTP)

The FTP handler uses FTP to transfer output data to post-processing. After aconfigurable number of CDRs have been converted and written to a file, or aconfigurable amount of time has passed, the file containing the CDRs istransferred via FTP to a post-processing system. Whether empty files are sentafter the archive period has passed or not, is configurable through the GUI.

The active FTP is used as the default, but if passive FTP is needed, theFTP_PASSIVE environmental variable must be set to a non-zero value.

Temporary file renaming

The FTP can be configured to use file renaming during transfers to ensure that thereceiving post processing system does not start processing an incompletelytransferred file. When using file renaming, the file is first transferred using atemporary file name that has the intended target file name and a configurable filename suffix. Once the transfer is complete, the file is renamed to its intendedtarget file name. The temporary file name suffix is configurable through the GUI'sDistributor Protocols configuration. If the temporary file name suffix is leftempty, then file renaming is not used.

For example, the temporary filename suffix is configured to be ‘tmp’, and theintended target filename is 00000096_1_20060403153454.cdr. Then duringthe transfer the file will be called 00000096_1_20060403153454.cdr.tmp.Once the transfer is complete, the transferred file is remotely renamed back to00000096_1_20060403153454.cdr.

FTP NOK file

If an FTP transfer fails, the Distributor writes the information from the failedtransfer to a file called NOK_FTP_Distr_XXX.txt, where XXX is theDistributor ID. This file is written into the /cdr/work/inbox directory.

When the FTP Distributor is restarted, it will check the inbox to see if such a fileexists. If the file exists, it will read the name of the CDR-file from it and attemptto send it again before reading anything from the queue. If the file is sentsuccessfully, the Distributor will continue normally by reading CDRs from thequeue. If, however, the file still cannot be sent, the Distributor will shut down.

6.4.2 File protocol

The file protocol handler sends CDRs directly to a locally stored file. The nameand location of the output file is read from the configuration database.




pkic1201

Highlight

CDRs are written to the output file until it is closed, either as scheduled (forexample, every 15 minutes) or after a defined number of CDRs has beenprocessed.

The user can configure through the GUI whether empty files are sent or not.

. If empty file sending is not on, the scheduled time has passed, and noCDRs have been processed, then the empty file is not closed. Only thetimer for counting the archived period is restarted.

. If the empty file sending is on, the file is closed and sent in even if noCDRs were processed.

A new output file is created to the working directory in the following cases:

. at start-up

. when the first new CDR has been processed by the Distributor after theprevious file closing

6.4.3 CORBA protocol

The CORBA protocol handler is used for prepaid CDR handling, or hot billing.

Hot billing enables the immediate sending of charging records (CDR) to a billingcentre. The hot billing protocol handler in the Distributor subsystem uses asolution based on Common Object Request Broker Architecture (CORBA).CORBA method calls are used to communicate with the Customer Care andBilling System (CCBS) handling the hot billing process.

Hot billing operation in fault cases

If the connection for the hot billing interface is lost, CG attempts to re-initialisethe connection every second for 30 seconds. If it succeeds, the Distributor willresume reading from the CDR queue and deliver the CDRs through the CORBAmethod calls. If it fails, an alarm (131121) is sent and the CDRs are written to fileusing the File protocol. The name and amount of CDRs, and whether empty filesare sent or not are configurable through the CG GUI.

For more information, see Configuring the hot billing interface inCommissioning and Integrating Charging Gateway 4.3.



pkic1201

Highlight

6.4.4 User Datagram Protocol (UDP)

The User Datagram Protocol (UDP) module in CG sends data packets tospecified hosts using UDP/IP. The destination port and host names areconfigurable. All the destination hosts use the same port, but the host name canvary depending on the type of data.

Data is sent as generated by the Distributor converter except for the first byte ofdata. This first byte is removed from the data and used as an ID to identify thetype of data. In this way, different types of data can be sent to different hosts. Noverification of the success of delivery is performed. Port 1234 should be usedwhen the UDP is used for Traffica.

The UDP protocol handler is primarily meant to be used with Traffica, and itincludes a built-in mechanism for sending heartbeat messages to Traffica. Theheartbeat functionality can be enabled using the CG GUI. This message is sent toa host every 4 seconds if no data has been sent to that specific host. The checkingof whether or not data has been sent to hosts is done periodically every fourseconds for all hosts at one time so the heartbeat sending period can vary between4 to 8 seconds depending on the time of the last data packet sent. For moreinformation, see Configuring Traffica interfaces in Commissioning andIntegrating Charging Gateway 4.3.

6.5 Map of CDRs and predefined output formats

The following table maps incoming CDRs to the output formats that arepredefined in Distributor. These are supported combinations, but you can defineyour own output formats to expand the level of support. This is needed, forexample, with Nokia 3G SGSN Release 3 CDRs for which there is no predefinedoutput format.

Table 13. Supported CDR input-output combinations

Output formatID

Supported Network Element CDRs

190 Nokia GGSN Release 4.0


218 Nokia 3G SGSN Release 2

Nokia GGSN Release 3






Table 13. Supported CDR input-output combinations (cont.)

Output formatID


232 Nokia GGSN Release 1


233 Nokia GGSN Release 3




Nokia 2G SGSN Release 3





329 Nokia Content Analyser Release 1.1

330 Nokia Content Analyser Release 2.0

333 Nokia Traffic Analyser Release 1.3

Nokia Traffic Analyser Release 1.4

335 Nokia Traffic Analyser Release 2.0

422 Nokia 2G SGSN Release 3.1


Nokia Content Analyser Release 1.1



Nokia GGSN Release 4.0





Table 13. Supported CDR input-output combinations (cont.)

Output formatID


423 Nokia 2G SGSN Release 3.1
















520 Nokia Authentication Server Release 2.0

Nokia Authentication Server Release 3.0




550 Nokia CPS Release 1.0

555 Nokia PoC Release 1.0


Nokia 2G SGSN Release 3.1












7 User interfaces

7.1 Graphical user interface

The Graphical User Interface (GUI) provides an interface for configuring theCharging Gateway (CG). The GUI is a web application running on top of anApache Tomcat server. The figure Welcome window illustrates the look and feelof the GUI.

Figure 12. Welcome window

Modifications made in the GUI are stored to the configuration database (Oracle).Some modifications are not taken into use until the respective subsystem isrestarted.



User interfaces

Note

Charging Gateway is highly configurable, especially in terms of CDRprocessing. Users should be aware that the GUI does not evaluate the logic ofconfiguration parameters. The mechanism for checking and testing thereasonableness of configuration parameters needs to be taken into accountseparately, for example, in a test bed.

Environment configuration

The configurable properties include the following:

. User name and password for database access

. Location and file name of the Audit Log

. Session expiration time

. Graphical User Interface password

If changes are necessary, updates are made through the GUI or via the CG.

cproperties file.

For more detailed information and instructions, see the operation andmaintenance documentation.

Logs

The GUI server generates several log files, which can be used to observe systembehaviour such as system events. The operation and maintenance documentationprovides more information and instructions for using and customising the logs.

Centralised administration

There can be more than one CG server in a subnet. Centralised administrationallows all the CGs to be administered from a central place using the same GUI.To identify a particular CG server for administering, it is necessary to uniquelyidentify the CG server by using the unique ID.

Even if there are multiple servers in the subnet, the web server needs to reside inonly one of them.



7.2 Command line interface

The command line interface (CLI) client application (cg4admincli) provides anend user interface for administering Charging Gateway (CG). The CLI has twomodes:

. non-interactive - a single command is entered which cg4admincli executesand then immediately exits.

. interactive - cg4admincli is started without any parameters, and a simpletext-based menu is opened for browsing (to select target subsystem(s) anda command from the list of available options).

7.2.1 Commands in non-interactive mode

In non-interactive mode the command cg4admincli is used together with thefollowing options and arguments. Optional arguments are marked with squarebrackets, otherwise the argument is mandatory.

. -cdup <network element IP address> [GTP' Collector instance (all bydefault)]

Cancels all possibly duplicated packets that the network element with thespecified IP address has sent to the CG.

. -d <log level: 0|1|2|99> [subsystem type: core|coll|distr|all(default)][instance name (all by default)]

Sets log level.. 0 = errors only (default level). 1 = errors and warnings. 2 = errors, warnings, and informative messages. 99 = all possible logs (errors, warnings, informative messages, and

logging messages)

. -e <stopcg|stopcoll|stopcore|stopdistr> [instance name (all by default)]

Shuts down a subsystem.

. -f periodic_flush [Core instance name (all by default)]

Executes periodic flush.

. -g on|off [GTP' Collector instance(all by default)]

Sets GTP message logging on or off.

. -h



User interfaces

Displays help menu.

. -i reinit_core [Core instance name (all by default)]

Re-initialises Core.

. -l [subsystem type: core|coll|distr|all(default)] [instance name]

Lists subsystems present at runtime.

. -m master_flush [Core instance name (all by default)]

Flushes all partial or complete CDRs from Core.

. -o reload_ip [GTP' Collector instance name (all by default)]

Reloads configured network element IP addresses for CG GTP’ Collector.

. -q corekpi|collkpi|distrkpi|allkpi [instance name (all by default)] [numberof queries (default is 1)]

Queries KPIs.

. -r <raw data file> <GTP' Collector instance>

Reads and processes the raw data file.

. -rdup <network element IP address> [GTP' Collector instance (all bydefault)]

Releases all possibly duplicated packets that the network element with thespecified IP address has sent to the CG.

. -rkpi corekpi|collkpi|distrkpi|allkpi (all by default) [instance name (all bydefault)]

Resets KPIs.

. -t on|off [Collector instance name (all by default)]

Sets the Traffica interface on or off.

7.2.2 Commands in interactive mode

In interactive mode the command cg4admincli is given without parameters.This displays a text-based menu for browsing and command selection. The menuis divided into five main sections:

. Core administration

. Collector administration, subdivided into



. GTP’ Collector administration

. Collector common administration

. Distributor administration

. Common administration

. KPI administration

7.2.2.1 Core administration menu

All running Core instances are listed. The available commands are given with thefollowing syntax:

. “{Core instance} -d newLogLevel”: change the log level of the CG Coreinstance. Possible values 0, 1, 2, and 99. Higher log levels cause moretracing information to be stored to the ULOG.

. “{Core instance} -e stopcore”: Shut down the Core instance.

. “{Core instance} -m master_flush”: Perform the masterflush (flush allpartial or complete CDRs from the Core).

. “{Core instance} -f periodic_flush”: Perform the periodic flush.

. “{Core instance} -i reinit_core”: Re-initialise the Core.

7.2.2.2 Collector administration menu

Note

Collector names must include the substrings '_gtp', '_ftp' or '_cf', and the namemust end with the hostname. Otherwise the Collector administrationcommands might not work properly.

For example: xxx_xxx_gtp_<hostname>

GTP' Collector administration menu

All running GTP' Collector instances are listed. The available commands aregiven with the following syntax:

. “{GTP Collector instance} -r rawdatafile”: Read and process a raw datafile by the CG GTP’ Collector instance

. “{GTP Collector instance} -g <on | off>”: Set GTP' message logging on oroff for the GTP’ Collector instance



User interfaces

. “{GTP Collector instance} -o reload_ip”. Reload configured networkelement IP addresses

. “{GTP Collector instance} -cdup <IP address>”: Cancel potentiallyduplicated packets sent to CG by the network element with the specified IPaddress, for the GTP’ Collector instance

. “-cdup <IP address>”: cancel potentially duplicated packets sent to CG bythe network element with the specified IP address, for all the GTP’Collectors

. “{GTP Collector instance} -rdup <IP address>”: Release potentiallyduplicated packets sent to CG by the network element with the specified IPaddress, for the GTP’ Collector instance

. “-rdup <IP address>”: Release potentially duplicated packets sent to CG bythe network element with the specified IP address, for all the GTP’Collectors

Collector common administration menu

All running Collector instances are listed. The available commands are givenwith the following syntax:

. “{Collector instance} -d newLogLevel”: Change the log level for theCollector instance. The possible values are 0, 1, 2, and 99. Higher loglevels cause more tracing information to be stored to the ULOG.

. “{Collector instance} -e stopcoll”: Shut down the Collector instance

. “{Collector instance} -t <on | off>”: Set Traffica interface on or off for theCollector instance

7.2.2.3 Distributor administration menu

All running Distributor instances are listed. The available commands are givenwith the following syntax:

. “{Distributor instance} -d newLogLevel”: Change the log level of theDistributor instance. The possible values are 0, 1, 2, and 99. Higher loglevels cause more tracing information to be stored to the ULOG.

. “{Distributor instance} -e stopdistr”: Shut down the Distributor instance

7.2.2.4 Common administration menu

The menu lists the following common administration commands:



. List all the CG subsystems at runtime

. Stop all the subsystems at runtime

. Set log level for all the subsystems at runtime

7.2.2.5 KPI administration menu

This menu allows you to either query KPIs or reset KPIs. You can choose toquery KPIs for a single subsystem instance or all running subsystems. The sameapplies for resetting KPIs.

The menu lists the following options:

. Query CG Core KPIs. Query KPIs of a single CG Core instance. Query KPIs of all CG Core instances present in RTE

. Query CG Collector KPIs. Query KPIs of a single CG Collector instance. Query KPIs of all CG Collector instances present in RTE

. Query CG Distributor KPIs. Query KPIs of a single CG Distributor instance. Query KPIs of all CG Distributor instances present in RTE

. Query all CG subsystems KPIs

. Reset CG Core KPIs. Reset KPIs of a single CG Core instance. Reset KPIs of all CG Core instances present in RTE

. Reset CG Collector KPIs. Reset KPIs of a single CG Collector instance. Reset KPIs of all CG Collector instances present in RTE

. Reset CG Distributor KPIs. Reset KPIs of a single CG Distributor instance. Reset KPIs of all CG Distributor instances present in RTE

. Reset all CG subsystems KPIs

For descriptions of the available KPIs, see Key Performance Indicators (KPIs) inthe Functional Description of Charging Gateway 4.3.



User interfaces

8 External interfaces

8.1 Performance monitoring interface

During operation, Charging Gateway updates statistical counters and calculatesKey Performance Indicators (KPIs). Nokia NetAct monitors CG performance byquerying these KPIs. Nokia NetAct may also send administration commands toCG, for example, to reset the KPIs. All the KPIs and a special variable forenabling the reset statistical counters command are defined in CG MIB. NokiaNetAct uses the Performance Monitoring (PM) interface to send its queries toCG. The PM interface uses the Simple Network Management Protocol (SNMP).

Note

The SNMP PM interface only supports Nokia NetAct.

8.1.1 Architecture of the Performance Monitoring Interface

The Performance Monitoring (PM) interface consists of the followingcomponents: SNMP Agent (NetSNMP), CG subagent, HP-UX SNMP Agent,Administrator (Admin) subsystem, and all subsystems' KPI functionality. This isillustrated in Figure CG performance monitoring architecture.



External interfaces

Figure 13. CG performance monitoring architecture

The SNMP Agent module is responsible for accepting KPI query calls fromNetAct. The CG subagent acts as an Admin client and is responsible fordelivering calls to the Admin subsystem through the Tuxedo ATMI.

The Admin subsystem forwards the query request to CG subsystems in the formof Tuxedo events. Each subsystem subscribes to certain events (including KPIquery request events) at its initialisation phase. The subsystems reply to theevents providing their KPI information by writing the reply to a Tuxedo Queue.Admin gets the KPI reply from the queue. A reply is the delivered back to the CGsubagent, SNMP Agent, and eventually to NetAct.

The CG SNMPAgent is based on third-party software called NetSNMP. The CGsubagent has been developed using NetSNMPAPI and CG Admin API to act as abridge between the SNMP Agent and CG Admin. The following MIBs aresupported by the CG PM interface:

NetAct

set(OID, value)

CG MIB

MIB-II

HP-UNIX MIB

get(OID)

SNMPManager

SNMP Agent(NetSNMP)

SNMP

CG

TUXEDO

CG MIB

MIB-II

CG subagent

HP-UX MIB

HP-UXSNMPAgent

CGAdministrator

CG Core

CGDistributor

CGCollector

Tuxedoevents

SNMP

CG SNMP PM IF

ATMI



. CG MIB

CG MIB is a CG-specific MIB which contains information for themanagement of CG statistical counters (KPIs).

. MIB-II

The MIB-II is a standard MIB which contains information for themanagement of the TCP/IP protocol suite.

. HP-UNIX MIB

The HP-UNIX MIB is a standard MIB which contains information for themanagement of the HP-UX operating system.

The CG SNMP Agent (NetSNMP Agent) provides MIB-II support itself. Tosupport HP-UNIX MIB, the CG SNMP Agent receives SNMP requests fromNetAct and forwards them to the standard HP-UX SNMPAgent, which acts as asecondary SNMP Agent in CG and has full support for the HP-UNIX MIB.

This two SNMP Agent-layer architecture is transparent for NetAct. From theNetAct point of view, there is just one CG SNMPAgent running on the standardSNMP port (161) which supports the three MIBs.

8.1.2 Key Performance Indicators (KPIs)

Key Performance Indicators (KPIs) measure the performance of CG servers. TheKPIs are grouped according to subsystem. These can be queried remotely usingNokia NetAct, or locally, using the command line interface.

Collector KPIs

. Start-up time (CollStartupTime). This is the last time Collector was started.

. Statistics collection time (collStatCollectionTime). This is the Collectorcollection time that is the time when the CG statistics counters were lastreset.

. Number of network elements registered in CG (numberOfInterfaces). Thisis number of network elements that interface with Collector.

. Address of network element (NeAddress). This is the IP address of thenetwork element interfacing with Collector.

. Type of the network element (NeTypeIndex). This is the type of thenetwork element, for example, GGSN, SGSN, interfacing with Collector.

. Protocol used by the network element interface (ProtocolIndex). This is theinterface protocol used by the network element interfacing with Collector.



External interfaces

. Data unit type for the Collector (collDataUnitTypeIndex). This is the typeof data used by the Collector protocol handler: GTP' packet, kilobyte, ormessage.

. Total number of data units received since start-up or reset, per interface(collNbrReceivedDataUnits). This is the total number of data unitsreceived by Collector from the elements for all elements registered in CG.The data unit can be a GTP’ packets, kilobytes of data, or messages.

. Number of valid data units received since start-up or reset, per interface(nbrValidDataUnits). This is the number of data units validated byCollector. Each network element interface has its own counter. The dataunit can be a GTP’ packets, kilobytes of data, or messages.

. Number of discarded data units received since start-up or reset, perinterface (nbrDiscardedDataUnits). This is the number of data unitsdiscarded by Collector. Discarding can be due to a corrupted file, unknownIP address, and a corrupted packet. Each network element interface has itsown counter. The data unit can be a GTP’ packet or kilobytes of data ormessage.

. Number of Potential Duplicate Packets received(nbrReceivedDuplicateDataUnits). This is the total number of potentialduplicate packets in CG and not interface specific information. Thiscounter is GTP’ protocol specific.

. Number of Potential Duplicate packets released(nbrReleasedDuplicateDataUnits). This is the number of duplicate packets,which are released in CG. The released packets are sent to processing.They are not duplicates.

. Number of Potential Duplicate packets cancelled(nbrCancelledDuplicateDataUnits). This is the number of duplicatepackets, which are cancelled in CG. Cancelled packets are not sent toprocessing. They are duplicates and are discarded.

. Number of queues configured in CG Collector (nbrOfCollectorQs).

. Name of Collector queue (CollQueueName).

. Number of CDRs sent to Core (collNbrSentCDRs). This is the totalnumber of CDRs sent to Core.



Core KPIs

. Start-up time (coreStartupTime). This is the last time Core was started. Ifmultiple Cores are used then this marks the start-up time of the first Coreinstance.

. Statistics collection time (coreStatCollectionTime). This is the Corecollection time that is the time when the CG statistics counters were lastreset.

. Number of supported CDR types (numberOfsupportedCDRTypes). This isthe number of CDR types supported by Core.

. CDR type name supported by Core (CdrType). CDR types (such as S-CDRand G-CDR) supported by Core.

. Number of incoming CDRs for each supported CDR type(incomingCDRNum). This is the number of CDRs received by Core fromCollector per type.

. Number of combined CDRs for each supported CDR type(combinedCDRNum). This is the number of CDRs combined by Core, forall CDR types. Combining adds two or more types of CDRs to one CDR.

. Number of aggregated CDRs for each supported CDR type(aggregatedCDRNum). Aggregating adds several of the same CDR typeCDRs to one CDR.

. Number of correlated CDRs for each supported CDR type(correlatedCDRNum). Correlation adds some fields from other CDR typesto one CDR.

. Number of postpaid CDRs for each supported CDR type(postpaidCDRNum). This is counted after CDRs are read into Core withno processing done.

. Number of prepaid CDRs for each supported CDR type(prepaidCDRNum). This is counted after CDRs are read into Core with noprocessing done.

. Number of copied CDRs for each supported CDR type (copiedCDRNum).These are CDRs, which are copied by Copier in Core.

. Number of unsuccessful CDRs for each supported CDR type(unsuccessfulCDRNum). This counter is for those CDRs, in whichaggregation, correlation, or combination was unsuccessful. The reason canbe due to a missing CDR or when all CDRs have not come to CG beforethe expiration time is exceeded.

. Number of CDRs sent to Distributor (ProcessedCDRNum). Total numberof CDRs of each type sent to Distributor modules. The KPI is increasedevery time the Output Interface node puts a CDR in the queue.



External interfaces

. Number of rejected CDRs (rejectedCDRNum). This is the number ofCDRs rejected by Core, for all CDR types.

. CG Core Process State (ProcessStatus). 99 - active, 0 - starting up, 1 -maintenance mode, will not accept CDRs.

. Total number of contexts (totalNumberOfContexts). The total number ofopen contexts in Aggregator2 memory.

Distributor KPIs

. Number of Distributor instances in CG (NumberOfDistributors). This isnumber of Distributor instances running in CG.

. Distributor name (DistributorNameIndex). Name of the Distributorinstance.

. Distributor type (DistributorTypeIndex). Type of Distributor, for example,FTP.

. Distributor data unit type (DistrDataUnitTypeIndex). Type of data used bythe Distributor protocol handler, for example, CDR or kilobyte.

. Number of CDRs transferred through one Distributor module(DistrNbrSendDataUnits). Rejected and filtered CDR indicators are specialcases of this.

. Number of unsuccessful CDR sending in a Distributor module(distrNbrUnsuccesSendDataUnit). If FTP sending is not working or aCORBA call does not work, this counter is increased.

. Number of CDRs read from queue (DistrNbrReceivedDataUnits). This isthe total number of CDRs received from Core.

. Volume of data sent out from CG (VolumeOfData). This counter is usedonly when CG sends data through FTP. The volume is counted inkilobytes.

8.2 Alarm interface

The alarm interface allows remote fault management by Nokia NetAct. CGalarms are sent to NetAct in form of SNMP traps through this interface. Theinterface also provides such functionality as storing alarms and resending themupon request from NetAct.



In Charging Gateway the Mercury Alarm Agent is used by default. CG 4.3provides also the Nokia enhanced SNMP solution suite (NE3S) with theESYMAC Alarm Agent, but this needs to be installed separately if it is to beused.

The CG alarm interface consists of the following components: the SNMP AlarmAgent and the CG Alarm Dispatcher. When a CG subsystem encounters a failureduring runtime, it generates an alarm. The alarm contains information about thenature of the error and gives troubleshooting instructions.

The SNMP Agent module is responsible for converting the CG alarms from theCG's internal format to the SNMP alarm trap format defined in the NokiaCommon Alarm MIB and for delivering the alarm traps to the NetAct usingSNMP protocol.

The CG Alarm Dispatcher is used by all the CG subsystems for delivering CGalarm information in CG's internal format to the SNMP Agent.

Figure 14. CG Alarm interface

NetAct

set(OID, value)

CG subsystems(Core, Collector,Distributor)

get(OID)

SNMPManager

CG SNMPAlarm InterfaceSNMP

traps

NokiaCommonAlarmReportingMIB

Configurationparameters:SNMPManager’saddress

SNMP agent(Mercury/ESYMAC)

NokiaCommonAlarm MIBCG Dispatcher

HTTP

NokiaCommonAlarm TrapMIB

CG Alarmtraps

CGalarms/internalprotocol

SNMP



External interfaces

Alarm synchronization

By utilising the Nokia enhanced SNMP solution suite (NE3S), NetAct cansynchronise the presented and the CG raised alarms, when, for example, anetwork outage occurs. The Alarm synchronization is implemented usingESYMAC.

CG application processes send alarms using HTTP to port 8082. The AlarmAdapter socket server listens to this port. When an alarm message is received, it isforwarded to the ESYMAC Alarm Agent. The agent stores the alarm to its owndatabase and sends the alarm to the NetAct using NE3S over SNMP. If NetAct isdown or the transfer fails, NetAct can request all raised alarms from the AlarmAgent later. The alarms are cleared from the Alarm Agent database only by theCG application processes. All alarms are cleared at CG start up. Single alarms canbe cleared manually in the command line interface using the command cgalarm.

The Nokia enhanced SNMP solution suite (NE3S) needs to be configuredseparately if it is to be taken into use. For details on configuring the AlarmInterface, see Configuring the alarm interface in the Commissioning andIntegrating Charging Gateway 4.3.

CG alarms

The following table contains SNMP traps that are in used in CG. The traps aredefined in Nokia Common Alarm Trap MIB.

Table 14. CG SNMP traps

SNMP trapnumber

SNMP trap name Alarmnumber

131185 caDiskSpaceAlarm 32352

131186 caDiskSpaceAlarmCleared 32352

131189 caGTPPacketsProcessingFailure 32354

131190 caGTPPacketsProcessingFailureCleared 32354

131191 caModuleFailure 32355

131192 caModuleFailureCleared 32355

131193 caCDRProcessingFailure 32356

131194 caCDRProcessingFailureCleared 32356

131195 caFileOperationFailure 32357

131196 caFileOperationFailureCleared 32357

131121 caSWProcessCommunicationError 32347



Table 14. CG SNMP traps (cont.)

SNMP trapnumber

SNMP trap name Alarmnumber

131122 caSWProcessCommunicationErrorCleared 32347

131117 caprocessFailed 32345

131118 caprocessFailedCleared 32345

131241 cacollectorloginFailed 75000

131242 cacollectorloginFailedCleared 75000

131243 cacollectorconnectionFailed 75001

131244 cacollectorconnectionFailedCleared 75001

131245 calicencelimitExceed 75002

131246 calicencelimitExceedCleared 75002

131247 calicencelimitApproach 75003

131248 calicencelimitApproachCleared 75003

131249 calicenceInvalid 75004

131250 calicenceInvalidCleared 75004

131251 cadatabasewriteFailed 75005

131252 cadatabasewriteFailedCleared 75005

131253 caconfigurationError 75006

131254 caconfigurationErrorCleared 75006

Severity levels

The CG subsystems assign alarm severity at the time of alarm creation.

Table 15. Severity levels and their corresponding numbers

Severity level Number

Critical 1

Major 2

Minor 3

Warning 4

Cancel 5



External interfaces

Alarm states

The CG subsystems report to NetAct not only about failures, but also about thefact that the failure has been fixed. The alarm which is used to report about thestart of an error condition, when the fault happened, is called a stateful alarm. It isstored in the "current alarm log" in NetAct. (CG Alarm Agent also keeps currentalarm log for backup purposes). The stateful alarm is cancelled by cancelling thealarm when failure has been fixed in CG.

Table 16. Stateful and stateless alarms

Alarm Description

Stateful Stateful alarm characteristics:. remain active until a cancel alarm cancels them.. cancel alarms are generated when the fault situation has been

corrected. alarms of any type that have severity level 3 (minor), 2 (major) or 1

(critical). are cancelled with cancel alarms which have severity level 5 and

which are stateless

Stateless Stateless alarm characteristics. do not have cancel alarms, as they do not need to be cancelled.. primarily for information purposes. have severity level 4 (warning) or 5 (cancel).

8.3 Nokia Charging Center interface

The CG sends prepaid CDRs directly to the Nokia Charging Center (NCC) usingthe CORBA-based hot billing interface.

Prepaid and hot billing CDRs are marked with special flags and are notcombined. Instead, CG sends them in real time to NCC (that is, a CORBA server)as CORBA calls. Although hot billing or prepaid CDRs are not combined, theydo have to pass default validation and filtering.

If the hot billing server is not running for some reason, all CDRs are passed to theoutput file. The hot billing interface resumes normal operation after CG isrestarted.

For the hot billing interface to function properly, there must be a CORBA serveron the receiving end and a CORBA client on the sending end. Nokia CG containsa CORBA client that has been configured to function with the NCC CORBAserver.



8.4 Traffica interface

Charging Gateway can send Real-Time Traffic (RTT) reports to Traffica usingUDP/IP. CDR data in CG is sent to Traffica in different report types, one reporttype for each supported CDR type. The IP address and port for the interface areconfigurable (in Distributor).

All the reports have a fixed size, except for the CPS report. In CPS reports thereare several fields that can have multiple occurrences. The number of occurrencesfor those fields is defined in separate fields in the report. There can also bemultiple containers that hold several fields. The number of the containers isdefined in a separate field for each container type. If the size of the Traffica reportis too big (more than 65 000 bytes), the report will not be sent. A log entry iscreated when this occurs.

Collector converts the incoming raw CDR data to the RTT report format andsends it to the queue specifically for Traffica. The Distributor actually handles theconnection to Traffica. It reads the RTT reports from the queue. It adds additionaldata to the reports such as the header fields (report generation time and date) tothe reports before sending them to Traffica.

CG sends heartbeat messages to a Traffica to let Traffica know it is still running,even if reports have not been sent for a certain period.

For more information Traffica support, see Traffica Support in Collector, and inDistributor, see User Datagram Protocol (UDP) and Traffica converter.



External interfaces

9 Runtime environment

The application software of Nokia Charging Gateway uses the followingdirectories and environment variables in the runtime environment. $CG_HOMEdirectory is /opt/cg/<release>.

Table 17. Global directory structure

Directory Path Description

$CG_HOME/bin Application binaries (for example executables, dynamiclinked libraries, and batch files)

$CG_HOME/cfg Configuration files including UBB, tuxconfig, and anyother application-specific configuration files

$CG_HOME/configaddon Add-on script and templates

$CG_HOME/dev Tuxedo /Q devices

$CG_HOME/ftbl FML field table file directory

$CG_HOME/install Installation and setup tools

$CG_HOME/lib Libraries supplied with toolkit

$CG_HOME/mercury SNMP Alarm interface and other SNMP files (forexample, MIBs)

$CG_HOME/esymac SNMP NE3S Alarm interface related files and folders

$CG_HOME/net-snmp SNMP PM interface

$CG_HOME/pm SNMP PM interface

$CG_HOME/sql Storage of SQL scripts

/cdr/work/logs Storage of CDRs processing logs



Runtime environment

10 CG.cproperties file

The CG.cproperties file is an essential configuration file that is read by scriptsthat start up CG processes. The file is located in /opt/cg/<release>/cfg/

CG.cproperties and the environment variable that points to the file isCG4_PROPERTIES_FILE.

The following table contains the fields, descriptions of the fields, and defaultvalues. For example, to enable the startup of the FTP Collector with startcg.

sh, add the following collector_nok_ftp to the CGCOLLECTORS line.

Table 18. Fields in the CG properties file

Field Description Settings Process/Scriptusing thefield

PrimaryJdbcDriver Primary JDBC driver (usedby GUI processes).

oracle.jdbc.driver.

OracleDriver

GUI

PrimaryJdbcURL Primary connection definition(used by GUI processes).

Setting same for all users:jdbc:oracle:thin:

@localhost:1521:MCG

GUI

SecondaryJdbcDriver Secondary JDBC driver(used by GUI processes).

oracle.jdbc.driver.

OracleDriver

GUI

SecondaryJdbcURL Secondary connectiondefinition (used by GUIprocesses).

jdbc:oracle:thin:

@localhost:1521:MCG

GUI

SessionExpirationTime Time in seconds definingwhen the GUI sessionexpires.

1200 GUI

AuditLog Defines the location of theAudit Log for GUI and thesubsystem start-up events.

/cdr/work/logs/

cg4audit.log

GUI, cgcore,cgcollector,cgdistributor

RuleConfigDump

(optional)

Location of the SQL scriptthat is generated when adata circuit rule is saved.

/cdr/work/logs/

DataCircuit.sql

GUI



CG.cproperties file

Table 18. Fields in the CG properties file (cont.)


OutputFormatDumpDir

(optional)

Directory of the SQL scriptthat is generated when acustomised output format issaved.

/cdr/work/logs/ GUI

DBPassword Database password neededto open connection todatabase

4_CG-3 GUI, cgcore,cgcollector,cgdistributor

DBUsername Database user name neededto open connection todatabase

cg GUI, cgcore,cgcollector,cgdistributor

DBName Database service nameneeded to open connectionto database

CG4_1 cgcore,cgcollector,cgdistributor

CGCORERULE Current data circuit rule usedby Core

Setting depends on theoperator. Example:

1

startcg

CGDISTRIBUTORS Defines which Distributorsshould be started

Setting depends on theoperator. Example:

1 2 3 4 5 6

startcg

CGCOLLECTORS Defines which Collectorsshould be started

Setting depends on theoperator. Examples:

collector_nok_gtp_<hostname>, collector_nok_ftp

startcg

GUIConfig Defines GUI configuration filefor dialog layouts

CGGUI_config.xml GUI

AlarmListenPort Defines the port the AlarmAdapter socket server listensto. When an alarm isreceived by the AlarmAdapter it is forwarded to theMercury or ESYMAC Alarmagent.

8082 GUI

SearchTime Defines the maximum searchtime in seconds.

60 GUI

LogfileListSize Defines the maximumnumber files to display in alog file search result.

100 GUI



Table 18. Fields in the CG properties file (cont.)


LogfileSearchSize Defines the maximumnumber of rows to include ina log file search.

Do not use values above1000.

500 GUI

RawdataSearchSize Defines maximum number ofrawdata CDRs to include in asearch.

Do not use values above 20.

10 GUI

OutputCdrSearchSize Defines maximum number ofoutput CDRs to include in asearch.

Do not use values above 20.

10 GUI

Port Defines the port that thesocket server listens to.

8000 GUI

CoreMemLimitWarn Defines a limit value (inMBytes) for the memory useof the CG Core process. Ifthe limit is exceeded analarm is raised.

The size of the memorylimit in MBytes. Use anapproximate value with areasonable threshold.

Value 0 means that theparameter is not active.

cgcore

CoreMemLimitFlush Defines a limit value (inMBytes) for the memory useof the CG Core process. Ifthe limit is exceeded amasterflush is performed inthe Core.

The size of the memorylimit in MBytes. Use anapproximate value with areasonable threshold.

Value 0 means that theparameter is not active.

cgcore

Agg2StatInterval Defines a logging interval forAggregator2-relatedinformation. This can beused to log information onthe number of activesessions and aggregatedCDRs stored in theAggregator2 node memory tothe ULOG.

The value is the log writinginterval in seconds. Novalue or 0 means that noinformation is logged.

cgcore



CG.cproperties file

functional description of charging gateway 4.3

Education

file protocol

nokia logo

permission of nokia

nokia hasmade

gtp protocol handler

collector converter

copyright nokia corporation

sample data circuit