Functional Description of Charging Gateway 4.3 DN03353543 Issue 10 en # Nokia Corporation 1 (111) 00041683.00 Nokia Charging Gateway Release 4.3, Product Documentation
Jun 17, 2015
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
DN03353543Issue 10 en
# Nokia Corporation 3 (111)
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
4 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
10 CG.cproperties file 109
DN03353543Issue 10 en
# Nokia Corporation 5 (111)
Contents
6 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 7 (111)
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.
8 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
Table 1. New features in Charging Gateway rel. 4.3 (cont.)
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.
1.2 Changes between releases 4.1 and 4.2
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:
DN03353543Issue 10 en
# Nokia Corporation 9 (111)
Changes in functionality
Table 2. New features in Charging Gateway rel. 4.2
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
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. The existing 2G SGSN rel. 3.1output format can be used for this purpose.
Nokia 3G SGSNrel. 3.0 support
Collector supports the CDRs from this network element. The rel. 3.0 CDRs canalso be forwarded to Traffica.
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.
10 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
Table 2. New features in Charging Gateway rel. 4.2 (cont.)
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.
Changes in documentation
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.
1.3 Changes between releases 4.0 and 4.1
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:
Table 3. New features in Charging Gateway rel. 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.
DN03353543Issue 10 en
# Nokia Corporation 11 (111)
Changes in functionality
Table 3. New features in Charging Gateway rel. 4.1 (cont.)
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
Changes in documentation
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.
12 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 13 (111)
Main functions and architecture
. 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.
14 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 15 (111)
Main functions and architecture
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.
16 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 17 (111)
Main functions and architecture
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.
18 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
14 S-CDR 3G SGSN rel. 1 18
15 M-CDR 3G SGSN rel. 1 20
16 S-SMO-CDR 3G SGSN rel. 1 21
17 S-SMT-CDR 3G SGSN rel. 1 22
18 TA-CDR rel. 1.2 94
19 CA-CDR rel. 1.1 93
20 S-CDR 2G SGSN rel. 3 18
21 M-CDR 2G SGSN rel. 3 20
22 S-SMT-CDR 2G SGSN rel3 22
23 S-SMO-CDR 2G SGSN rel. 3 21
24 G-CDR rel. 3 and 4 19
25 SA-CDR rel. 4 225
26 S-CDR 3G SGSN rel. 2 18
27 M-CDR 3G SGSN rel. 2 20
28 S-SMO-CDR 3G SGSN rel. 2 21
29 S-SMT-CDR 3G SGSN rel. 2 22
30 TA-CDR rel. 1.3 94
31 S-CDR 2G SGSN rel. 3.1, 4 and 5 18
DN03353543Issue 10 en
# Nokia Corporation 19 (111)
Main functions and architecture
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
46 S-CDR 3G SGSN rel. 3 18
47 M-CDR 3G SGSN rel. 3 20
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
58 S-CDR 3G SGSN rel. 4 18
59 M-CDR 3G SGSN rel. 4 20
60 S-SMO-CDR 3G SGSN rel. 4 21
61 S-SMT-CDR 3G SGSN rel. 4 22
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
20 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
Table 5. CDR type versions (cont.)
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
DN03353543Issue 10 en
# Nokia Corporation 21 (111)
Main functions and architecture
Table 5. CDR type versions (cont.)
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
22 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 23 (111)
Administrator subsystem
24 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 25 (111)
Collector subsystem
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
26 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 27 (111)
Collector subsystem
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)
28 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 29 (111)
Collector subsystem
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
30 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 31 (111)
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:
32 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
. 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
DN03353543Issue 10 en
# Nokia Corporation 33 (111)
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.
34 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
. Nokia 2G SGSN Release 3.1
. Nokia 2G SGSN Release 4
. Nokia 2G SGSN Release 5
. Nokia 3G SGSN Release 1
DN03353543Issue 10 en
# Nokia Corporation 35 (111)
Collector subsystem
. 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
This module provides TLV-format CDR decoding for CDRs from:
. Nokia GGSN Release 3
. Nokia GGSN Release 4
. Nokia GGSN Release 4.1
. Nokia GGSN Release 5.0
. Nokia ISN Release 2.0
. Nokia ISN Release 3.0
CGNokiaIMSConverter
This module provides TLV-format CDR decoding for CDRs from:
. 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
This module provides TLV-format CDR decoding for CDRs from:
36 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
. Nokia 3G SGSN Release 2
. Nokia 3G SGSN Release 3
. Nokia 3G SGSN Release 4
CGNokiaCPS2Converter
This module provides CDR decoding for CDRs from:
. Nokia CPS Release 2
CGNokiaMSCConverter
This module provides CDR decoding for CDRs from:
. 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.
DN03353543Issue 10 en
# Nokia Corporation 37 (111)
Collector subsystem
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
38 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 39 (111)
Collector subsystem
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
40 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
The toolkits are for Nokia customization use only.
DN03353543Issue 10 en
# Nokia Corporation 41 (111)
Core subsystem
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.
42 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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:
DN03353543Issue 10 en
# Nokia Corporation 43 (111)
Core subsystem
. 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.
44 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
. 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
DN03353543Issue 10 en
# Nokia Corporation 45 (111)
Core subsystem
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.
46 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 47 (111)
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).
48 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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:
DN03353543Issue 10 en
# Nokia Corporation 49 (111)
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
50 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 51 (111)
Core subsystem
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.
52 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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)
DN03353543Issue 10 en
# Nokia Corporation 53 (111)
Core subsystem
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 | |
54 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 55 (111)
Core subsystem
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.
56 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
(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)
DN03353543Issue 10 en
# Nokia Corporation 57 (111)
Core subsystem
. #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).
58 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 59 (111)
Core subsystem
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
60 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 61 (111)
Core subsystem
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
62 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
. #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.
DN03353543Issue 10 en
# Nokia Corporation 63 (111)
Core subsystem
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
64 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
. #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.
DN03353543Issue 10 en
# Nokia Corporation 65 (111)
Core subsystem
66 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 67 (111)
Distributor subsystem
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
68 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
The toolkits are for Nokia customization use only.
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.
DN03353543Issue 10 en
# Nokia Corporation 69 (111)
Distributor subsystem
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
70 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 71 (111)
Distributor subsystem
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.
72 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 73 (111)
Distributor subsystem
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.
74 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 75 (111)
Distributor subsystem
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).
76 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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:
DN03353543Issue 10 en
# Nokia Corporation 77 (111)
Distributor subsystem
. 02 for RECORD_TYPE
. 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:
. 03 for RECORD_TYPE
. 0B for CHARGING_ID
. 5B for RECORD_SEQ_NUM
. 000000EB for TEST_BUFFER
. 5E for DURATION
Length tags:
. 02 for RECORD_TYPE
. 02 for CHARGING_ID
. 06 for RECORD_SEQ_NUM
. 06 for TEST_BUFFER
. 02 for DURATION
78 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 79 (111)
Distributor subsystem
. 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.
80 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 81 (111)
Distributor subsystem
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.
82 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
191 Nokia GGSN Release 4.1
218 Nokia 3G SGSN Release 2
Nokia GGSN Release 3
225 Nokia GGSN Release 4.0
230 Nokia GGSN Release 4.1
DN03353543Issue 10 en
# Nokia Corporation 83 (111)
Distributor subsystem
Table 13. Supported CDR input-output combinations (cont.)
Output formatID
Supported Network Element CDRs
232 Nokia GGSN Release 1
Nokia GGSN Release 2
233 Nokia GGSN Release 3
290 Nokia 2G SGSN Release 2
291 Nokia 2G SGSN Release 3
298 Nokia 2G SGSN Release 2
Nokia 2G SGSN Release 3
Nokia GGSN Release 2
Nokia GGSN Release 3
301 Nokia 3G SGSN Release 1
305 Nokia 3G SGSN Release 2
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 2G SGSN Release 4
Nokia Content Analyser Release 1.1
Nokia GGSN Release 2
Nokia GGSN Release 3
Nokia GGSN Release 4.0
Nokia Traffic Analyser Release 1.3
Nokia Traffic Analyser Release 1.4
84 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
Table 13. Supported CDR input-output combinations (cont.)
Output formatID
Supported Network Element CDRs
423 Nokia 2G SGSN Release 3.1
Nokia 2G SGSN Release 4
Nokia 3G SGSN Release 1
Nokia Content Analyser Release 1.1
Nokia Content Analyser Release 2.0
Nokia GGSN Release 2
Nokia GGSN Release 3
Nokia GGSN Release 4.0
Nokia GGSN Release 4.1
Nokia Traffic Analyser Release 1.3
Nokia Traffic Analyser Release 1.4
Nokia Traffic Analyser Release 2.0
512 Nokia 2G SGSN Release 1
Nokia 2G SGSN Release 2
Nokia GGSN Release 1
Nokia GGSN Release 2
520 Nokia Authentication Server Release 2.0
Nokia Authentication Server Release 3.0
522 Nokia 2G SGSN Release 1
Nokia 2G SGSN Release 2
Nokia 3G SGSN Release 1
550 Nokia CPS Release 1.0
555 Nokia PoC Release 1.0
999 Nokia 2G SGSN Release 2
Nokia 2G SGSN Release 3.1
Nokia 2G SGSN Release 4
Nokia 3G SGSN Release 2
Nokia Content Analyser Release 1.1
Nokia GGSN Release 2
Nokia GGSN Release 3
Nokia GGSN Release 4.0
Nokia Traffic Analyser Release 1.3
Nokia Traffic Analyser Release 1.4
DN03353543Issue 10 en
# Nokia Corporation 85 (111)
Distributor subsystem
86 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 87 (111)
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.
88 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 89 (111)
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
90 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
. 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
DN03353543Issue 10 en
# Nokia Corporation 91 (111)
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:
92 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
. 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.
DN03353543Issue 10 en
# Nokia Corporation 93 (111)
User interfaces
94 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 95 (111)
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
96 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
. 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.
DN03353543Issue 10 en
# Nokia Corporation 97 (111)
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.
98 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 99 (111)
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.
100 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 101 (111)
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
102 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 103 (111)
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.
104 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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.
DN03353543Issue 10 en
# Nokia Corporation 105 (111)
External interfaces
106 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 107 (111)
Runtime environment
108 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
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
DN03353543Issue 10 en
# Nokia Corporation 109 (111)
CG.cproperties file
Table 18. Fields in the CG properties file (cont.)
Field Description Settings Process/Scriptusing thefield
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
110 (111) # Nokia Corporation DN03353543Issue 10 en
Functional Description of Charging Gateway 4.3
Table 18. Fields in the CG properties file (cont.)
Field Description Settings Process/Scriptusing thefield
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
DN03353543Issue 10 en
# Nokia Corporation 111 (111)
CG.cproperties file