Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Functional Description of Charging Gateway 4.3

1,161 views

Published on

Functional Description of Charging Gateway 4.3

Published in: Education
  • Be the first to comment

  • Be the first to like this

Functional Description of Charging Gateway 4.3

  1. 1. 00041683.00 Nokia Charging Gateway Release 4.3, Product Documentation Functional Description of Charging Gateway 4.3 DN03353543 Issue 10 en # Nokia Corporation 1 (111)
  2. 2. Functional Description of Charging Gateway 4.3 The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia's customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia and the customer. However, Nokia has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia will, if necessary, explain issues which 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 DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), 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 to the applicable laws. NOKIA logo is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only. Copyright © Nokia Corporation 2006. All rights reserved. 2 (111) # Nokia Corporation DN03353543 Issue 10 en
  3. 3. Contents Contents 3 Contents 1 Changes in functionality 7 1.1 Changes between releases 4.2 and 4.3 7 1.2 Changes between releases 4.1 and 4.2 9 1.3 Changes between releases 4.0 and 4.1 11 2 Main functions and architecture 13 2.1 Architecture of a single Charging Gateway 14 2.2 Resiliency and load sharing 15 2.3 Audit Log 16 2.4 Process supervision 18 2.5 Supported CDR type versions 19 3 Administrator subsystem 23 4 Collector subsystem 25 4.1 Overview of Collector subsystem 25 4.1.1 CDR buffer 27 4.1.2 Crash recovery 27 4.1.3 Traffica support in Collector 27 4.2 Collector main application 28 4.3 Collector protocol handler modules 28 4.3.1 Validation in Collector 28 4.3.2 Raw data file 29 4.3.3 GTP' protocol handler 29 4.3.3.1 Network element IP address reloading 30 4.3.3.2 GTP' collector communications 30 4.3.3.3 GTP' message log file 32 4.3.3.4 GTP' duplicate prevention 32 4.3.3.5 GTP' attributes 33 4.3.4 FTP protocol handler 33 4.3.5 Nokia Control File FTP protocol handler 34 4.4 Collector converter modules 35 4.4.1 CGNokiaMSCConverter configuration functionality 37 4.4.2 Protocol handler usage of converter modules 40 5 Core subsystem 41 5.1 CDR processing in Core 41 5.2 Data processing nodes 42 5.3 Impact of flushes on CDR processing 42 5.3.1 Understanding masterflush 43 5.3.2 Understanding flush triggers in Aggregator and Combiner 43 5.3.3 Example of using Aggregator with SGSN CDRs 46 5.3.4 Understanding flushing in Simple Aggregator, Aggregator2, and Small Aggregator 51 5.4 CdrEvaluator expression syntax 52 5.5 FML boolean expressions 54 DN03353543 Issue 10 en # Nokia Corporation 3 (111)
  4. 4. Functional Description of Charging Gateway 4.3 5.5.1 Operators in FML boolean expressions 54 5.5.2 Using FML boolean expressions 55 5.6 Provided data circuits 57 5.6.1 Default main data circuit rule 57 5.6.2 Sample data circuit: record type rule 60 5.6.3 Sample data circuit: ICD rule 61 5.6.4 Sample data circuit: IMS rule 62 5.6.5 Sample data circuit: MSC rule 62 5.6.6 Sample data circuit: CPS Rel. 2 rule 63 6 Distributor subsystem 67 6.1 Overview of Distributor subsystem 67 6.2 Distributor main application 69 6.2.1 Support for headers and trailers 69 6.2.2 Numbering outgoing CDRs and files 71 6.2.3 Support for multiple output formats 73 6.3 Distributor converter modules 74 6.3.1 FML to ASCII converter 75 6.3.2 FML to XSV converter 75 6.3.3 FML to TLV converter 75 6.3.3.1 TLV type values 76 6.3.3.2 TLV encoding rules 76 6.3.3.3 Output CDR conversion examples 77 6.3.4 Traffica converter 79 6.4 Distributor protocol handler modules 79 6.4.1 File Transfer Protocol (FTP) 81 6.4.2 File protocol 81 6.4.3 CORBA protocol 82 6.4.4 User Datagram Protocol (UDP) 83 6.5 Map of CDRs and predefined output formats 83 7 User interfaces 87 7.1 Graphical user interface 87 7.2 Command line interface 89 7.2.1 Commands in non-interactive mode 89 7.2.2 Commands in interactive mode 90 7.2.2.1 Core administration menu 91 7.2.2.2 Collector administration menu 91 7.2.2.3 Distributor administration menu 92 7.2.2.4 Common administration menu 92 7.2.2.5 KPI administration menu 93 8 External interfaces 95 8.1 Performance monitoring interface 95 8.1.1 Architecture of the Performance Monitoring Interface 95 8.1.2 Key Performance Indicators (KPIs) 97 8.2 Alarm interface 100 8.3 Nokia Charging Center interface 104 8.4 Traffica interface 105 9 Runtime environment 107 4 (111) # Nokia Corporation DN03353543 Issue 10 en
  5. 5. 10 CG.cproperties file 109 DN03353543 Issue 10 en Contents # Nokia Corporation 5 (111)
  6. 6. Functional Description of Charging Gateway 4.3 6 (111) # Nokia Corporation DN03353543 Issue 10 en
  7. 7. 1 Changes in functionality 1.1 Changes between releases 4.2 and 4.3 Changes in content Changes in functionality The current release of Charging Gateway is based on features in previous releases. 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 for aggregating MSC CDRs. For more information, see Small Aggregator nodein Data Processing Nodes in Charging Gateway 4.3. Multiple Core support The user can configure multiple Cores to increase CG's CDR handling capacity. Multiple Core support has caused modifications in the Input Interface node. Nokia CPS release 2 support CG supports CDRs from this network element. Due to this, changes have also been implemented in Correlator2 and Aggregator2 nodes. A new sample data circuit has been made for CPS 2. Nokia MSC support (up to M13.3) CG supports CDRs from this network element. The Small Aggregator node has been created to support this feature. A new sample data circuit has been made for MSC. Nokia FISN rel. 3 support The CG supports CDRs from this network element. DN03353543 Issue 10 en # Nokia Corporation 7 (111)
  8. 8. Functional Description of Charging Gateway 4.3 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 network element. Nokia SGSN SG6.0 support The CG supports CDRs from this network element. Push to talk over cellular (PoC) release 2 support The CG supports CDRs from this network element. FTP Collector enhancement The FTP Collector can now be used to fetch CDRs from 3G SGSN. Nokia Control File FTP Collector A new protocol handler for MSC and 2G SGSN support using the Nokia Control File mechanism. See Nokia Control File FTP protocol handler. FML2XSV Converter Configurable separator support in Distributor. Allows the use of any character as a separator in output CDRs. See Distributor converter modules. File renaming support in Distributor The Output CDR files can be renamed in FTP transfer to distinguish between closed files and files not ready for transfer. See Distributor converter modules. NVS support CG supports CDRs from this network element. Nokia enhanced SNMP solution suite (NE3S) for alarm handling The NE3S alarm interface with the ESYMAC alarm agent can be configured for use instead of the default alarm interface. For details, see Alarm interface. GUI changes Several configuration dialogs and pages have been modified to support the new features. Also several usability features improvements have been added. See Changes in the graphical user interface in Graphical User Interface Help for Charging Gateway 4.3. tlvReader The tlvReader is a new command line tool for viewing TLV-format CDRs produced by Distributors using the FML to TLV converter. For details on the tool and its use, seetlvReader functions and usage in Operating and Maintaining Charging Gateway 4.3. 8 (111) # Nokia Corporation DN03353543 Issue 10 en
  9. 9. Changes in functionality Table 1. New features in Charging Gateway rel. 4.3 (cont.) Feature Description Capacity licensing CG 4.3 introduces CDR load based capacity licensing. For details on use, see Configuring capacity licensing in Commissioning and Integrating Charging Gateway 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 any customization 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 converter modules . Control File FTP protocol handler has been added under Collector protocol handler modules All data processing node specific information has been moved to Data Processing Nodes in Charging Gateway4.3 document. In addition, all the changes related to the features listed in the above table have been 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: DN03353543 Issue 10 en # Nokia Corporation 9 (111)
  10. 10. Functional Description of Charging Gateway 4.3 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 type ID rather than record type version. For more information, see Aggregating CDRs. Input Interface node change The Input Interface data processing node was modified to support the new Aggregator2 node. Combiner node change The Combiner data processing node was modified to support configurations based on record type ID (used in Aggregator2). Correlator2 node This is a new data processing node that introduces more configurable options for correlating CDRs. For more information, see Correlator2 node in Data Processing Nodes in Charging Gateway 4.3. Nokia GGSN rel. 5.0 support Collector supports the CDRs from this network element. The rel. 5.0 CDRs can also be forwarded to Traffica. A predefined CDR output format is not included. Nokia 2G SGSN rel. 5.0 support Collector supports the CDRs from this network element. The rel. 5.0 CDRs can also be forwarded to Traffica. A predefined CDR output format is not included. The existing 2G SGSN rel. 3.1 output format can be used for this purpose. Nokia 3G SGSN rel. 3.0 support Collector supports the CDRs from this network element. The rel. 3.0 CDRs can also be forwarded to Traffica. A predefined CDR output format is not included. OSC rel. 2.0 support CG can send CDRs for OSC rel. 2.0 for rating, fetch the rated CDRs, and forward them to a billing system. These CDRs are routed through the data circuit directly to Distributor without further processing. Duplicate Checker node New data processing node. GTP' message logging Message type is now included in the logged information. Also, this plus the time stamp and IP address (with port number, when the message is from a network element) of each message are written into the file in readable format (when opened in a HEX editor). FML to TLV converter 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 a single line, with each CDR separated by a new line. For more information, see FML 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 the Graphical User Interface for details. IP address reloading Commands have been added to Admin CLI for reloading network element IP addresses used in GTP' Collector. Configurable echo message sending GTP’ Collector can be configured to send echo request messages periodically to particular network elements. 10 (111) # Nokia Corporation DN03353543 Issue 10 en
  11. 11. Changes in functionality Table 2. New features in Charging Gateway rel. 4.2 (cont.) Feature Description Configurable Node Alive message sending GTP’ Collector can be configured to keep sending Node Alive Request signals to selected network elements until an answer (Node Alive Response) is received. POSIX queues The Tuxedo-based queues between Collector and Core, between Core and Distributor, and between Collector and Distributor (Traffica queue), have been replaced by configurable queues based on POSIX. This introduces new parameters for some data process nodes, as well as for Collector and Distributor. Apache Tomcat server The BEA Weblogic Server has been replaced by Apache Tomcat. Note that the CG.cproperties file has changed due to this server change. Sequence number restart The Distributor sequence number can be restarted (default) or continue from the previous number after a subsystem is restarted. This is controlled through a new parameter in the CG.cproperties file. Changes in documentation Several new sections have been added to the Functional Description to cover the new functionality. Two sections, Position in the networks and Software and hardware components, have been replaced by references to the CG4 Product Description. 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 output formats 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. Process supervision CG processes are monitored according to configurable settings. See Process supervision for details. DN03353543 Issue 10 en # Nokia Corporation 11 (111)
  12. 12. Functional Description of Charging Gateway 4.3 Table 3. New features in Charging Gateway rel. 4.1 (cont.) Feature Description Generic hot billing interface 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 sequence numbering Single sequence numbering file that can be used by all Distributors on a given CG server. 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 output formats Distributor supports multiple output formats. See Support for multiple output formats 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 changed significantly. The new functionality has, for the most part, been added to existing areas. Some areas have been combined with others. In addition, there are new reference areas, while those covering the configuration database tables have been removed. 12 (111) # Nokia Corporation DN03353543 Issue 10 en
  13. 13. Main functions and architecture 2 Main functions and architecture The 3rd Generation Partnership Project (3GPP) has specified Charging Gateway Function (CGF), which provides a mechanism for transferring charging information from the Serving GPRS Support Nodes (SGSNs) and Gateway GPRS Support Nodes (GGSNs) to the network operator’s post-processing system. In the Nokia implementation, CGF is implemented as a stand-alone element, the Nokia Charging Gateway (CG). The CG is used in GPRS, 3G, mobile telephone exchange (MSC) networks, and Nokia Intelligent Content Delivery (ICD), Operator Wireless LAN (OWLAN), and IP Multimedia Subsystem (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 the following: . CDR routing . CDR validating . CDR combining . CDR aggregating . CDR correlation . CDR field manipulation . Hot billing support for prepaid CDRs DN03353543 Issue 10 en # Nokia Corporation 13 (111)
  14. 14. Functional Description of Charging Gateway 4.3 . Storage of CDRs until a Customer Care and Billing System (CCBS) or other post-processing system collects them . Configurable output interface . Customisable data interfaces CG manages the transfer of CDRs from network elements in GPRS, 3G, and mobile circuit switched networks in a reliable and controlled manner. Changes needed in the CCBS or other post-processing system integration are minimised by processing CDRs in the format that the system requires. The number of interfaces to the post-processing system are reduced, which also minimises integration needs. CG aggregates CDRs, which decreases the number of output CDRs that are sent to 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), for example Aggregator2, Small Aggregator, Combiner, and Validator, each of which are configurable. For more information, see Data Processing Nodes in Charging Gateway 4.3. CG supports monitoring from Nokia NetAct, a network-wide monitoring and support system. For more general information about Nokia Charging Gateway, please refer to the Nokia Charging Gateway Rel. 4 Product Description. This can be found under the 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 DN03353543 Issue 10 en
  15. 15. Config DB Figure 1. Architecture of CG Main functions and architecture Performance Management Interface The main subsystems are Collector, Core, Distributor, and Administrator. There can be multiple instances of Collector, Core and Distributor subsystems. CG is operated and maintained through a Graphical User Interface (GUI) and Command Line Interface (CLI). Nokia NetAct can be used for remotely monitoring the performance and status of the CG units installed in the network. Collector 2.2 Resiliency and load sharing Resiliency Users need to shut down CG when repairs are needed, when users take a new configuration into use, or when new software is installed. Thus, there should be at least two Nokia Charging Gateway units to handle all the charging data in the network in a resilient manner. FTP Collector Admin Raw data C A P I GTP’ Collector C A P I FTP Collector C A P I CF Collector D A P I Hotbill Output D A P I FTP Output D A P I File Output Distributor Queues Command Line Interface Alarm (FM) Graphical User Interface Traffica D A P I UDP/IP Distributor Core Queues Traffica Traffica DN03353543 Issue 10 en # Nokia Corporation 15 (111)
  16. 16. Functional Description of Charging Gateway 4.3 The minimum requirement for servers is N+1 resiliency. For example, if there are three CG servers, CDR-generating network elements configure two CG units as primary, and they actively receive CDRs. The third CG is also fully operational but is configured as a secondary CG in the network elements sending CDRs. If one of the primary CG units fails, GTP' automatically redirects CDRs to the secondary CG. The expression, 2N resiliency, means that one primary CG server may have (one or 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 Core instances. Each Core instance can have the same data circuit, or a different data circuit can be used in each (recommended for advanced users only). By default you should use the single Core setting unless you know processing capacity of one Core does not meet your CDR handling requirements. For details on the multi-Core feature configuration and usage, see the commissioning and integrating documentation. . Network element load sharing Network element load sharing is based on CG resiliency. Since there are always at least two CG units in the network, the secondary CG can be configured to take care of some of the CDR traffic also in a normal situation. In this case, it is important that both CG units run with less than 50% 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 the primary CG is out of operation. This is because the overall load exceeds 100%. The result is that CG stops processing CDRs. However, temporary spikes 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 configurable through the CG.cproperties file with the 'AuditLog' property. The main Audit Log includes information about the actions that have been performed through the GUI. However, an Audit Log is in every server. The Audit Logs in other servers do not contain any GUI information and only carry information written by subsystems when they start, and the ID of the rule that is started. 16 (111) # Nokia Corporation DN03353543 Issue 10 en
  17. 17. Main functions and architecture The Audit Log can be viewed only from the command line. The location and name 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 DN03353543 Issue 10 en # Nokia Corporation 17 (111)
  18. 18. Functional Description of Charging Gateway 4.3 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 initiates configurable actions to notify about and recover from process errors. The environment variable PSV_PROPERTIES_FILE defines the configuration file for this 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 supervision receives no response, SARs are resent. The number of retries is configurable. If a subsystem still does not respond, the pre-configured actions are started. For more details, see Configuring process supervision in Operating and Maintaining Charging Gateway 4.3. Alarms (SNMP traps) are sent to NetAct when a subsystem malfunctions. When a subsystem malfunctions, process supervision executes a shell script to recover from the problem. Alarms are automatically sent to NetAct even if there are no recovery actions (that is, the shell script is empty). If the script fails (process supervision fails), this is recorded in the Audit Log. The following table summarises the default recovery actions. These may be extended by editing the corresponding shell script. For example, a script can be extend 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. The other subsystem processes can continue even if Collector fails. Core Shutdown Collector is shut down when an error occurs in Core. Distributor Shutdown Collector is shut down when an error occurs in Distributor. 18 (111) # Nokia Corporation DN03353543 Issue 10 en
  19. 19. 2.5 Supported CDR type versions Main functions and architecture The following table outlines the supported CDR type versions and the identification values used for processing in Core. Table 5. CDR type versions Record type version 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 DN03353543 Issue 10 en # Nokia Corporation 19 (111)
  20. 20. Table 5. CDR type versions (cont.) Record type version Functional Description of Charging Gateway 4.3 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 DN03353543 Issue 10 en
  21. 21. Table 5. CDR type versions (cont.) Record type version Main functions and architecture 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 DN03353543 Issue 10 en # Nokia Corporation 21 (111)
  22. 22. Table 5. CDR type versions (cont.) Record type version Functional Description of Charging Gateway 4.3 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 DN03353543 Issue 10 en
  23. 23. 3 Administrator subsystem 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 Line Interface (CLI) and Performance Monitoring (PM) interface, to administer and monitor other CG subsystems. The Admin subsystem can run on the same server as 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 individually or 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 supported commands 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 particular function). 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 Line Interface (CLI) and Performance Monitoring interface. DN03353543 Issue 10 en # Nokia Corporation 23 (111)
  24. 24. Functional Description of Charging Gateway 4.3 24 (111) # Nokia Corporation DN03353543 Issue 10 en
  25. 25. 4 Collector subsystem 4.1 Overview of Collector subsystem 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, and forwards the CDRs to the Core subsystem for processing. The internal CDR format is Tuxedo Field Manipulation Language (FML). The position of the Collector subsystem is illustrated in Figure Architecture of CG in Architecture of a 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 Collector subsystem and the flow of incoming CDRs. DN03353543 Issue 10 en # Nokia Corporation 25 (111)
  26. 26. Figure 2. Collector architecture Supported CDR formats Functional Description of Charging Gateway 4.3 CG supports incoming CDRs in the following formats: . Nokia Fixed format . Nokia TLV format . CSV format . Nokia MSC format Collector toolkit Core A software development toolkit is available to build modifications for Collector. With the toolkit, support for new network elements can be added to the default Collector subsystem. The toolkit consists of base classes from which the new converter and protocol handler modules must be inherited. The base classes communicate with the main application using the CG internal interface. For any customization needs, please contact your local Nokia representative. The toolkits are for Nokia customization use only. NE1 NE3 NE2 NE n CG internal interface raw data file Administrator main application protocol handler C A P I converter CAPI Traffica 26 (111) # Nokia Corporation DN03353543 Issue 10 en
  27. 27. 4.1.1 CDR buffer Collector subsystem The number of incoming CDRs per time period can fluctuate, and Core may not be able to process all the CDRs coming from Collector instantly. The solution for this 'rush-hour' problem is a CDR buffer that can temporarily store CDRs (converted to FML) before Core processes them. The queue between Collector and Core provides this buffering. By default there is one queue per Collector instance, but when multiple Cores are used there can be several queues for each Collector 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 that no CDRs are lost. For a GTP' Collector this has to be done manually using the Admin command line interface. When a GTP’ Collector is told to read raw data, it sends re-direction messages to network elements to make them switch CDR transmission 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 CDRs and send them to the Distributor through a queue specifically for Traffica. Collector has two counters for Traffica: one for reports and one for events. The report counter indicates the number of Traffica reports sent to Traffica, and the event 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 report header before sending the report to Traffica. In normal situations, these counters are the same. However, in an overload situation, the event counter increases but the 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 gets too high. This is done by using a load monitoring script (load_monitor.sh) which monitors CPU usage and switches the interface off and back on accordingly. A log entry is created in each case. The script can be edited to meet the environment-specific requirements. The configurable parameters are described in the beginning of the script. DN03353543 Issue 10 en # Nokia Corporation 27 (111)
  28. 28. 4.2 Collector main application Functional Description of Charging Gateway 4.3 When Collector is started, the main application loads the protocol handler and converter module according to the configuration values stored in the configuration database. Several instances of the main application with the same or different protocol handler (excluding the GTP' module), and one or more converter modules can coexist. Communication with Administrator and CG administration command-handling is done by the main application. The Field Manipulation Language (FML) buffer for storing the converted CDRs is part of the main application, as well as the FML buffer manipulation and queue functions. Log writing and alarm handling are also performed by the main application. 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 and checks that they can be decoded. The protocol handler also saves the CDRs to the raw data file, and then sends them to the converter module. CG provides protocol handlers 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 of that validation naturally takes place in a protocol handler module. The validation algorithm depends on the transfer protocol used and the CDR structure. Collector does not check whether the values of the individual fields inside a CDR are valid. The Core subsystem does this kind of validity check. Collector just checks that the CDR is not corrupted and that the conversion to FML format is possible. When Collector receives GTP' packets from network elements (NEs), it validates the 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 DN03353543 Issue 10 en
  29. 29. Collector subsystem If there is an invalid CDR in the GTP’ packet, a cause for CDR rejection is sent back to the GSN within a 'DataRecordTransferResponse' message. The cause code alerts the GSN as to the reason the GTP’ packet was refused. The sequence number 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 the configuration file. If the type does not match the CDR is ignored and an entry is written to the ULOG. 4.3.2 Raw data file After receiving and validating the CDRs, CG can write them to non-volatile memory (disk file) through the raw data interface. This file is called a raw data file which serves as a backup file in case of a system crash. The protocol handler module that writes the raw data file must also be able to reprocess its contents for crash recovery. However, not all Collectors need to create raw data files. For example, GTP’ Collector creates a raw data file, but FTP collector does not. The GTP' Collector creates raw data files to store incoming CDRs for backup purposes. CG writes all GTP' Data Record Transfer Request messages, except empty ones, into the raw data file. One Data Record Transfer Request message contains one or more CDRs. The whole GTP’ packet is written to a raw data file at once. The FTP Collector stores the transferred file to the work directory. After CDRs have been processed, the file is moved to an archive directory. The transferred file can be used as such for backup purposes, so there is no need to use the raw data interface when processing CDRs from an FTP file. The Nokia CF FTP Collector transfers the CDR files to an element specific directory. 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 the element. After the converter has processed all the CDRs of a file, the protocol handler 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 Server Release 4.1 (AS 4.1), IP Multimedia Subsystem (IMS) Releases 1 and 2, Nokia Content Analyser (CA) Releases 1 and 2, Traffic Analyser (TA) Releases 1.3, 1.4, 2 and 3, and Nokia OWLAN Release 2. DN03353543 Issue 10 en # Nokia Corporation 29 (111)
  30. 30. Functional Description of Charging Gateway 4.3 When the GTP' Collector receives a packet it validates the packet, saves the packet in the raw data file, sends response message back to GSN, and unpacks the raw CDRs from the packet. Only one instance of the GTP' module can exist on a CG application server due to the port restrictions defined in the standards. Only port 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. You can add or update network element addresses in the GUI, and then use the command line interface to reload the IP addresses. For new addresses, a Node Alive 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 Ga interface. The messages sent on this interface are illustrated below. Node Alive Request Node Alive Response Version Not Supported Response Redirection Request Redirection Response GSN CG Data Record Transfer Request Data Record Transfer Response Echo Request Echo Response 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 is ready to receive CDRs. A GSN sends Node Alive Response back to CG in reply to Node Alive Request to 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> 30 (111) # Nokia Corporation DN03353543 Issue 10 en
  31. 31. Collector subsystem GTP’ Collector can be configured to keep on sending Node Alive Request signals to selected network elements until an answer (Node Alive Response) has been received. Otherwise, the ‘T3 response’ and ‘N3 requests’ parameters determine how many times and at what interval Node Alive Requests are sent. For new network elements added through the GUI, this feature is deactivated by default. Constant resending should only be activated with Nokia 3G SGSN Release 3 network elements. Version Not Supported Response If CG receives a GTP’ message about an unsupported version, Collector returns a GTP’ Version Not Supported response and the received data in the GTP’ packet is discarded. Redirection messages CG sends a Redirection Request to alert the GSN that CDRs need to be sent to a secondary 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 Redirection Request 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 GSN sends 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 Data Record 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 GSN and CG is functional. CG sends an Echo Response back to the GSN in reply to an Echo Request to inform the GSN that the message was received. GTP’ Collector can be configured to periodically send echo messages to particular 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. By default this feature is not active and should not be used unless a particular network element requires it. DN03353543 Issue 10 en # Nokia Corporation 31 (111)
  32. 32. 4.3.3.3 GTP' message log file Functional Description of Charging Gateway 4.3 GTP’ messages are not written to a file by default. However, there are situations when 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 network elements and pinpoint possible Ga-interface related errors. If message logging is turned on, it stays on unless turned off manually or the Collector subsystem is shut down. When message logging is on, all incoming and outgoing messages are written into the log file along with the timestamp, source or destination IP address (with port number when it is a network element address), and message type (node alive request, an so on). The GTP’ message logging file name uses the format gtpmessage_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. An arrow following the IP address indicates whether the message is incoming or outgoing: . "-->" 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' 2 defines a duplicate CDR prevention mechanism at the protocol level. The duplicate CDR prevention mechanism is mandated by GTP' 2 and functions within the Nokia Packet Core Network. Each GSN has its internal list of CGs, where one CG is marked as primary and the other CGs as secondary. If the primary CG does not acknowledge receiving GTP' packets from an SGSN or a GGSN, the network element sends the packets to one of the secondary CGs. The GTP' packets that the GSN sends to the secondary CG are flagged as potential duplicates. Therefore, the secondary CG does not process these GTP' packets immediately but waits for further notification from the GSN. When the primary CG acknowledges receiving packets again, one of the following occurs: 32 (111) # Nokia Corporation DN03353543 Issue 10 en
  33. 33. Collector subsystem . If the primary CG has received the GTP' packets that are marked as potential duplicates, a response to the GSN query acknowledging that the primary CG has processed the packets. These flagged packets are then deleted in the secondary CGs. . If the primary CG has not received the GTP' packets, an appropriate message is sent to the GSN. The flagged packets are then processed in the secondary CGs. CG includes a parameter that indicates whether duplicate prevention is performed in CG or in a Customer Care and Billing System (CCBS). Administrators can select 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 enable communication between GSNs and CG. GTP' attributes are as follows: . GTP' specifies certain message types for communicating charging information from GSNs to CG. . GTP' specifies how traffic is redirected from CGs that are not responding to Data Transfer Requests. . GTP' specifies how charging of potential duplicate CDRs caused by redirection are prevented. . GTP' specifies a mechanism for guaranteeing delivery of its packets. When Collector receives GTP’ packets from the GSNs, they have a sequence number attached to them. Collector receiver stores the information on the sequence numbers in its memory and on disk. GSNs and CG use these sequence numbers as a part of duplicate prevention. 4.3.4 FTP protocol handler The FTP protocol handler receives CDRs sent over FTP from Nokia Content Analyser (CA) Releases 1 and 2, Nokia Online Service Controller (OSC) Release 2.0, and 3G SGSN Releases 3 and 4. The FTP Collector logs in to the network element and fetches all CDR files using FTP. 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 FTP Collector logs in and renames the processed files. The IP address, port number, username, password, and the source directory must be configured for each DN03353543 Issue 10 en # Nokia Corporation 33 (111)
  34. 34. Functional Description of Charging Gateway 4.3 network element. In addition for 3G SGSN, a secondary IP address must also be configured. The FTP protocol handler checks that the CDR type is either from CA, OSC rel. 2 or a 3G SGSN. If it is not a CDR type from these network elements the CDR is discarded. No other validation is performed. FTP Collector stores the transferred file to the work directory. After the CDRs have been processed, the file is moved into an archive directory. The transferred file can be used as such for backup purposes, so there is no need to use the raw data 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 Nokia Mobile Services Switching Centre (MSC). A control file mechanism is used to control the file transfer between CG and the MSC, and a specific configuration file needs to be defined for the CF FTP protocol handler through the CLI in addition to the GUI configuration. The configuration file contains information on CDR filenames and extensions, control file names, and structure of the control files. For details on configuration, see Configuring CF FTP Collectors in Commissioning 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 protocol handler has logged in to the network element, the control files are fetched. The TTTCOF is fetched only at first login. The protocol handler checks the validity of the timestamps in TTSCOF. If there are invalid timestamps, an alarm is raised. From TTSCOF the protocol handler searches for complete CDR files and compares the information that was previously read from TTSCOF. According to the result of this comparison, the protocol handler transfers the completed CDR files. When a data file has been successfully transferred, the current time of the CF Collector is written to the TTTCOF as the transfer time of the data file. If the timestamp of the corresponding record in the TTSCOF is 2 minutes or less from the time in CG, then the timestamp written to the TTTCOF will be the TTSCOF timestamp + 1 s. After the TTTCOF is updated, the file is moved to back to the network element. The CF FTP protocol handler sorts the CDR conversion order. The CF FTP protocol handler renames files in CG to prevent overwriting files with similar names in CG. 34 (111) # Nokia Corporation DN03353543 Issue 10 en
  35. 35. 4.4 Collector converter modules Collector subsystem Before CG is able to start processing the CDR it must be converted to a uniform format. This is carried out by data converters. The Collector converter modules decode 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 buffer and processes them. Traffica reports are converted and sent straight to a queue specifically for Traffica to be read by Distributor, by-passing the Core subsystem entirely. The converters are handled as a plug-in module. You define which module to use in each Collector instance through the GUI. Each converter can support certain CDR 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 DN03353543 Issue 10 en # Nokia Corporation 35 (111)
  36. 36. . Nokia GGSN Release 2 . Nokia OWLAN Release 2 Functional Description of Charging Gateway 4.3 . 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 DN03353543 Issue 10 en
  37. 37. . 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: Collector subsystem . 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 is required that contains the paths and filenames of the CDR type specific configuration files. These CDR type specific control files describe how each CDR is converted. Thus, every MSC CDR type that is passed to the CGNokiaMSCConverter needs to have a separate configuration file. In this file each field of CDR and its position in the CDR has to be described in the same sequence as in the incoming CDR. The FML field name has to be given to those fields that need handling in CG (and are passed to the Core). When no FML field name exists in the configuration file, the field is ignored. For details on the configuration, see Configuring MSC CDR collecting in CG in Commissioning 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, and conversions from BCD to integer for CG’s internal representation. The following tables 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 result put to the FML field the function is operating on. There are two types of functions, the basic functions and the special functions that can be used in addition to the basic conversion functions. DN03353543 Issue 10 en # Nokia Corporation 37 (111)
  38. 38. Functional Description of Charging Gateway 4.3 Table 6. Basic conversion functions Function name Description (all numbers are hexadecimal unless otherwise stated) B Default function. Copies one or more bytes into the FML field. Can be left out from the conversion line. BCD Converts 1 to 4 BCD bytes to integer, for example: 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 is considered as undefined and is not converted and passed to CGCore. DX Swaps the byte order of 1 to 4 bytes. The number of bytes is taken from the field length. For example, the conversion line: RECORD_LENGTH,SHORT=2,DX This adds an FML field RECORD_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 the DX200 byte swap is performed first, for example: 34 12 -> 4D2 Note, that if field is full of FFs, the field is considered as undefined and is not converted and passed to CGCore. DIGITS ,DIGITS(F) Swaps the digits within a byte. If a parameter is given then the character given as parameter is removed from the result. The resulting FML field must be of type string. Example: DIGITS 62 02 03 F6 FF FF FF FF -> 26 20 30 6F FF FF FF FF Example: DIGITS(F) 62 02 03 F6 FF FF FF FF -> 26 20 30 6 38 (111) # Nokia Corporation DN03353543 Issue 10 en
  39. 39. Table 6. Basic conversion functions (cont.) Function name Collector subsystem Description (all numbers are hexadecimal unless otherwise stated) TIMESTAMP Makes a UNIX timestamp from 5 bcd bytes and a bcd word. The FML field must be of type long or double. MAS (<parameters>) MAS function is used for making more specific byte order swaps from DX200 data field. Resulting FML field must be type of string. With the parameters byte order, structure of received field must be given. Parameters are separated with colon (:) 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 hex characters. 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 in CALL_REFERENCE field. NUMBERS_TO_ASC Copies field length amount of bytes to FML string field. Special conversion functions can be given after the basic functions, separated with 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. DN03353543 Issue 10 en # Nokia Corporation 39 (111)
  40. 40. Functional Description of Charging Gateway 4.3 4.4.2 Protocol handler usage of converter modules The protocol handlers can use only certain converter modules. The following lists indicate which converter modules can be used by each protocol handler. You need this information when, for example, you are configuring Collectors using the GUI. 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 DN03353543 Issue 10 en
  41. 41. 5 Core subsystem 5.1 CDR processing in Core Core subsystem Core handles CDR processing and is the subsystem at the heart of Charging Gateway (CG) functionality. The processing logic is completely configurable through the graphical user interface. However, a set of pre-built data processing nodes are available which the user can configure to create a data circuit which contains the needed data processing logic. The governing configuration of a data circuit is a rule, a set of configured nodes that compose the data processing logic that is active at a given time. All the rules ever created are contained in the configuration database. There are three parameters in the CG.cproperties file that can be used to monitor 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. With the 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. DN03353543 Issue 10 en # Nokia Corporation 41 (111)
  42. 42. 5.2 Data processing nodes Functional Description of Charging Gateway 4.3 The data processing nodes make up the data circuit in CG Core. The data processing node can be conceptually viewed as an independent logical processor with 1 to n input pins and 1 to m output pins. The number of input and output pins is specific for each node type. CDRs are delivered to the node through one of the 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. The Input Interface, Output Interface, and Copier nodes are exceptions: the Input Interface node has no input pins, while the Output Interface node has no output pins. The Copier node is specific for releasing CDRs, that is, copied CDRs are released to all the output pins. Once the CDRs leave one of the output pins, they enter the input pin of next node to which the particular output pin is connected. In this way, the CDRs pass through 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 POSIX queue. The data circuit must have only one Input Interface as the starting node. When Collector sends the CDRs to the defined queue, Core reads them and passes them to the Input Interface node. After mandatory pre-processing and validation in the Input Interface, the CDRs are passed to the subsequent nodes according to the data circuit rule. The data processing nodes are Unix shared libraries that are loaded into Core at startup 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 to the ULOG at the initialisation stage when the node fetches the corresponding configuration. For detailed node descriptions, see Data Processing Nodes in Charging Gateway 4.3. 5.3 Impact of flushes on CDR processing Flushing can change the expected behaviour of CDR processing, so it needs to be used with great care. The general recommendation is to use as few triggers as possible, and only use masterflush when absolutely necessary. 42 (111) # Nokia Corporation DN03353543 Issue 10 en
  43. 43. 5.3.1 Understanding masterflush Core subsystem Masterflush is an administrative function that empties all CDRs in Core memory to the Output Interface node. When this flush is executed, it does not stop ongoing CDR processing. Those processes (for example, aggregation), are completed before the node carries out the masterflush command. With the introduction of flush periods and expiration flush in release 4.0 of Charging Gateway, there is no longer any need to use masterflush. The only case where 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 run stopcg.sh, masterflush is executed automatically. If you execute masterflush, you run the risk of breaking your aggregation and combining processes. If masterflush is executed before a particular flush period is closed, Combiner cannot combine the CDRs from the incomplete flush period. In addition, the remaining CDRs for the flush period that arrive after the masterflush cannot be released by the aggregation node. They remain in the node memory until the next masterflush. To avoid these problems, you should rely on carefully defined flush triggers. If you need to regularly flush the Core memory, then you should use the expiration flush (expiration time parameter in Aggregator and Combiner nodes) instead of masterflush. The expiration flush completely clears node memories of any inactive 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 flush trigger event (for example, a tariff change) and before the indication of the next defined event form a flush trigger period. If Aggregator has received all X-CDRs for that period correctly (none are missing), Aggregator will aggregate the X-CDRs for that period. Aggregator, only if configured appropriately, can release the 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 to be combined with G-CDR version 2 and defined QoS change and tariff change as flush triggers for both types. If no CDRs are missing and both flush trigger events occur once within both S-CDRs and G-CDRs, Aggregator will release the session as six flush trigger periods. For S-CDRs, the periods are as follows: DN03353543 Issue 10 en # Nokia Corporation 43 (111)
  44. 44. Functional Description of Charging Gateway 4.3 . 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 with the first flush trigger period of G-CDRs, the second period of S-CDRs with the second period of G-CDRs, and the third period of S-CDRs with the third period of G-CDRs. This combining is due to the fact that all of the periods have equal number 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 as complete flush trigger periods. Because of this, the flush triggers must be chosen carefully. Customers must verify which triggers are relevant in their service 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 for all 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 DN03353543 Issue 10 en
  45. 45. . Abnormal release . PDP context release All flush trigger values are given in the following table. Table 8. Flush trigger values Core subsystem 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 DN03353543 Issue 10 en # Nokia Corporation 45 (111)
  46. 46. Functional Description of Charging Gateway 4.3 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 like FIRST_SEQUENCE_NUMBER and LAST_SEQUENCE_NUMBER may not allow verification of which CDRs were aggregated. In some cases, for example SGSN, when SGSN_CHANGE happens, RECORD_SEQ_NUM is restarted 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 of CDRs from this one session, and the subscriber may move from one SGSN area to another. 46 (111) # Nokia Corporation DN03353543 Issue 10 en
  47. 47. Core subsystem In this example, there is a mobile subscriber who in the course of a single session moves 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 as flush triggers. The charging begins in SGSN1, continues in SGSN2 and SGSN3. Then, the mobile station user returns to SGSN1, as illustrated below: SGSN2 1 3 4 5 6 Tariff change 1 2 3 4 5 SGSN change Figure 4. SGSNs and charging SGSN change SGSN1 sends S-CDRS with sequence numbers 1, 2, 3, 4, and 5. We can refer to these 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 SGSN change. SGSN2 sends 1(S2), 2(S2), 3(S2), 4(S2), 5(S2), and 6(S2). CDR 2(S2) indicated a tariff change. CDR 4(S2) indicated volume limit, and CDR 6(S2) a change from SGSN2 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 the following S-CDRs: 1(S1), 2(S1), 3(S1), with 3(S1) indicating the end of the session. SGSN change QoS change QoS change Volume limit Session start Session end 3 2 1 SGSN1 SGSN3 3 2 1 2 DN03353543 Issue 10 en # Nokia Corporation 47 (111)
  48. 48. Functional Description of Charging Gateway 4.3 CDRs that are generated by the three SGSNs could arrive in different order. For example, the CDRs from the newest SGSN may arrive before the previous SGSN, 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 in Aggregator takes the following course: . 1(S2) is the first CDR received by Aggregator. A shortcut record is stored in the CDR table, and the iCDR pointer (link to iCDR) is set to point to this 1(S2). . The first CDR does not indicate a session start, so an empty place is made for the starting CDR to the left of 1(S2). Other empty spaces subsequently appear for S-CDRs that arrive late and out of the order in which they were actually generated. . 2(S2) arrives, and Aggregator determines that the placement in the table is to the right of 1(S2) based on the record opening timestamp. Since Aggregator detects that 1(S2) and 2(S2) have consecutive sequence numbers, 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). After aggregation CDR 1(S2) is discarded, and the iCDR pointer of the corresponding CDR table shortcut is set to point to the iCDR to which the shortcut of 2(S2) was pointing. Upon aggregation, the iCDR is updated to contain also the information of 1(S2). 48 (111) # Nokia Corporation DN03353543 Issue 10 en
  49. 49. Core subsystem 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. First aggregated with the CDR to the right in the table (if it exists), and then aggregated with the CDR to the left of the newly arrived CDR in the table, if it exists. 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 empty place. If the aggregation takes place, the empty place and the iCDR that had been aggregated with another iCDR are deleted. Other factors that determine placement in the string of CDRs are sequence numbers and record opening timestamps. Use of the flush triggers may take into consideration the empty places in the CDR type and version specific tables, and the 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 time stamp 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 time stamp of the previous CDR are close enough. . If the previous CDR (CDR from the old SGSN) indicated an SGSN change, 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: DN03353543 Issue 10 en # Nokia Corporation 49 (111)
  50. 50. Recording closing cause: Tariff change Recording closing cause: QoS change Functional Description of Charging Gateway 4.3 Recording closing cause: Volume limit 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 tariff change . 111 for period 4, one preceding QoS change, one tariff change, and one volume limit . 211 for period 5, two preceding QoS changes, one tariff change, and one volume limit The values '000' to '211' of the FLUSH_TRIGGER_OCCURENCES field are constructed 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, as illustrated below: 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 CDR sequence number Recording closing cause: QoS change Recording closing cause: session end 50 (111) # Nokia Corporation DN03353543 Issue 10 en
  51. 51. One preceding Tariff change No preceding flush triggers One preceding QoS change One preceding Volume limit Core subsystem Two preceding QoS changes 0 0 0 1 0 0 1 1 0 1 1 1 2 1 1 Figure 6. Tariff changes and flush triggers 5.3.4 Understanding flushing in Simple Aggregator, Aggregator2, and Small Aggregator The flush options in Simple Aggregator, Aggregator2, and Small Aggregator are different to those in the Aggregator. They all share the expiration flush option as in Aggregator. However, flush periods are defined differently, though their impact is the same as in Aggregator. In Aggregator, flush triggers are configured by selecting them from a predefined list of possible triggers. In Simple Aggregator, you do not have individually configurable flush triggers. Instead, you use a Flush expression (FML Boolean expressions) to flush CDRs. The Simple Aggregator evaluates all incoming CDRs according to these expressions before aggregation to detect if the previous CDR 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 Period specific flush trigger information for Combiner One preceding Tariff change DN03353543 Issue 10 en # Nokia Corporation 51 (111)
  52. 52. Functional Description of Charging Gateway 4.3 In Aggregator2 you have flush triggers as in the Aggregator. However, you can define much more complex methods for determining a flush period through the introduction of two-level aggregation and through the session-aware flush time option. Also in Aggregator2 you can configure yourself the fields used to look for flush trigger values. By default the flush triggers are read from fields 'cause for record closing' and 'change condition'. In the Small Aggregator node flushing is highly configurable. In addition to the expiration 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 Processing Nodes in Charging Gateway 4.3. 5.4 CdrEvaluator expression syntax Aggregator2 and Correlator2 use user definable expressions to determine their processing logic. The CdrEvaluator mechanism is used to parse these expressions (text strings). The following table outlines the operators that can be used in these expressions. Table 9. CdrEvaluator expression operators Logical operation Operator Action and && Compares two values and returns 1 if neither of them is 0. or || Compares two values and returns 1 if at least one of the values is 1. subtract - Subtracts the second value from the first value. add + Adds one value to another. multiply * Multiplies one value by another. divide / Divides the first value by the second value. 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 greater than the second one. smaller than < Returns 1 if the first value is smaller than the second one. 52 (111) # Nokia Corporation DN03353543 Issue 10 en
  53. 53. Table 9. CdrEvaluator expression operators (cont.) Logical operation Operator Action field existence <field name> (Field name used without operators.) Core subsystem Returns 1 if the field exists in the container. absolute value abs(<value>) Returns the absolute value of the given parameter. Expressions are defined per CDR type ID. The CDR type ID is not part of the expression entered in the GUI. It is selected from a drop-down list before entering the 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 related to 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 expression RECORD_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) DN03353543 Issue 10 en # Nokia Corporation 53 (111)
  54. 54. Functional Description of Charging Gateway 4.3 The end result of the expression returns the value 'true'. Expressions for comparing two CDRs Some expressions, such as the sorting and consecutiveness expressions in Aggregator2, need to compare two CDRs. The CDR can be specified in the expression by using cdr1 and cdr2 parameters. For example, the following expression 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 the configurations for Validator, Router, and Small Aggregator data processing nodes. It is one of the three expression syntaxes used in CG. The others are the Field Modifier Expression Language (FMEL) and the CdrEvaluator expression syntax. Here you find the basic principles for using the FML boolean expressions in the Charging 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 DN03353543 Issue 10 en
  55. 55. 5.5.2 Using FML boolean expressions Core subsystem Any field that is referenced using an FML boolean expression must exist in the field table. For the purposes of the Charging Gateway data processing nodes, the FML boolean operators are used to evaluate expressions to the logical values true or false. These are used in the nodes to route CDRs or to configure flush expressions. Using FML with regular expressions When using equality operations with strings, the right-hand side is evaluated as a regular expression. This expression must be a quoted string. You can use the regular expression to perform a wide variety of string comparisons. The whole use of regular expressions is beyond the scope of this documentation, but here you can find some basic principles for using regular expressions for making string comparisons in CG. Table 11. Operations with regular expressions Operation Explanation Characters A character represents itself, with the following exceptions. . The special characters: . * + ? | ( ) [ { and . The characters: (newline), t (tab), b (backspace), r (carriage return) and f (formfeed) To represent a special character as its non-significant self, use before the character, 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 inclusively between 0 and 255). RE{m, n} m through n occurrences of RE. (RE) Precedence using quotation. Example Grouping CDRs using a simple string comparison DN03353543 Issue 10 en # Nokia Corporation 55 (111)
  56. 56. Functional Description of Charging Gateway 4.3 This example shows how to group all the numbers beginning with 040 in the SERVED_IMSI field. The numbers can be of any length, and they can contain the numbers from 0 to 9. SERVED_IMSI%%'040[0-9]*' The served IMSI is a string field, thus the string comparison operator %% must be used, and the number must be enclosed in quotation marks ' '. The value range is 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 character sign . (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 with 040 followed by anything, and the record opening time is smaller than the record closing time. Validating and routing CDRs The validating and routing of CDRs in Core node processing is based on field values. Below you find some examples of FML Boolean expressions used in validating and routing along with explanations. (SGSN_ADDRESS && SGSN_ADDRESS !% '0*' ) This expression returns true, when the SGSN_ADDRESS field exists and it contains something else than just zeros. The field is of type string so string equality 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 the SGSN_ADDRESS does not exist or it is only zeros. 56 (111) # Nokia Corporation DN03353543 Issue 10 en
  57. 57. (CHARGING_ID && (CHARGING_ID > 0 )) Core subsystem This expression returns true when the charging ID field exist and it is greater than zero. 5.6 Provided data circuits The Charging Gateway Core provides several data circuits that you can use as a basis for CDR processing from different network elements. These rules are all pre-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 from the 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 ID within the rule): . #1 Input interface . #2 First Validator - validates CDRs and routes invalid CDRs to #5 (default output node for valid CDRs is #3) . #3 Second Validator - validates CDRs after first Validator and routes invalid CDRs to #6 (default output node for valid CDRs is #4) . #4 Third Validator - validates CDRs after second Validator and routes invalid CDRs to #7 (default output node for valid CDRs is #8) . #5-7 Concentrators - route to #25 (output for discarded CDRs) DN03353543 Issue 10 en # Nokia Corporation 57 (111)
  58. 58. Functional Description of Charging Gateway 4.3 . #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 routed to 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 manually after system installation). Default output to the first combiner is present in the circuit. . #11-14 Aggregators and #15-18 Combiners arranged in pairs - aggregates and 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 (#14 and #18). Ignored, partial and uncombined CDRs are routed through Concentrator #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 data is 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 be configured after system installation) . #22-26 Output - output nodes support the following output formats: CG rel. 3.0, 3G rel. 2, CG4.0 discarded, and ICD rel 1.1). 58 (111) # Nokia Corporation DN03353543 Issue 10 en
  59. 59. Figure 7. Default main data circuit rule 5/ Concentrator 1/ Input 2/ Validator 3/ Validator 6/ Concentrator 4/ Validator 10/ Router - charging tunnel type routing 13/ Aggregator 3G R1 7/ Concentrator 9/ Output 26/ Output (ICD) 14/ Aggregator 3G R2 12/ Aggregator GPRS R3 11/ Aggregator GPRS R2 18/ Combiner 3G R2 17/ Combiner 3G R1 16/ Combiner GPRS R3 15/ Combiner GPRS R2 20/ Concentrator 19/ Concentrator 21/ Router 24/ Output 23/ Output 22/ Output 25/ Output (discarded) 8/ Router DN03353543 Issue 10 en Core subsystem # Nokia Corporation 59 (111)
  60. 60. Functional Description of Charging Gateway 4.3 5.6.2 Sample data circuit: record type rule This sample rule serves as an example of how to process CDRs based on RECORD_TYPE. . #1 Input Interface . #2 First Validator - validates CDRs and routes invalid CDRs to #5 (default output node for valid CDRs is #3). . #3 Second Validator - validates CDRs after first Validator and routes invalid CDRs to #6 (default output node for valid CDRs is #4). . #4 Third Validator - validates CDRs after second Validator and routes invalid 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 others are 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 2G SGSN release 2 through 3.1, and S-CDRs from 3G SGSN release 1 through 3. Successfully aggregated CDRs are routed to node# 10, others to node# 11. . #10 Combiner combines the correctly aggregated G- and S-CDRs. Any combination of the above mentioned G- and S-CDRs can be combined. All CDRs 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 DN03353543 Issue 10 en
  61. 61. 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 Figure 8. Rule for record-type-based processing 5.6.3 Sample data circuit: ICD rule Core subsystem This rule serves as an example on what could be done with CDRs generated by the ICD network elements (such as Traffic Analyser). DN03353543 Issue 10 en # Nokia Corporation 61 (111)
  62. 62. Functional Description of Charging Gateway 4.3 In this data circuit, the S- and G-CDRs are aggregated in one Aggregator2 node and combined after that. The Sa-CDRs and Ta-CDRs are aggregated with separate Aggregator2 nodes. CA-, M- and SMS-CDRs are only validated, with no further 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 CDRs generated by IMS (CPS and PoC). The CPS CDRs are only validated. For PoC CDRs, some types are aggregated with Simple Aggregator. The aggregated types of PoC CDRs are OTO, OTT, GTO, GTT, GFO, GFT. (Note that the PoC server can be configured to do the aggregation by itself.) The aggregation in this draft circuit 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. 1/ Input- Interface 2/ Validator 4/ Router 3/ Output- Interface 6/ Small Aggregator 5/ Output- Interface 8/ Output- Interface Figure 9. Sample MSC data circuit 7/ Small Aggregator The main operation principles of the nodes are listed below: 62 (111) # Nokia Corporation DN03353543 Issue 10 en
  63. 63. Core subsystem . #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 #3 and 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 #6 and 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 sent from each CALLING_NUMBER and inserts the result into the SMALL_AGGREGATOR_COUNT_01 field. The CDRs are routed to node #8. . #7 Small Aggregator - aggregates MOC-CDRs. The CDRs are routed to node #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 create both P-CSCF-CDRS and S-CSCF-CDRs. DN03353543 Issue 10 en # Nokia Corporation 63 (111)
  64. 64. 1/ Input- Interface 2/ Validator 3/ Validator 5/ Aggregator2 7/ Output- Interface Functional Description of Charging Gateway 4.3 4/ Concentrator 6/ Output- Interface 8/ Router 9/ Correlator2 10/ Router 11/ Correlator2 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 #4 and valid CDRs to node #3. 64 (111) # Nokia Corporation DN03353543 Issue 10 en
  65. 65. Core subsystem . #3 Validator - validates (second level validation) CPS CDRs and routes invalid 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-CDRs to 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 the RECORD_TYPE_ID of 99 (N-CDRs or NC-CDRs). Successfully correlated CDRs are forwarded to node #10 and the rest to node #7. . #10 Router - routes CDRs with RECORD_TYPE_ID: 99 and CORRELATION_ALLOWED: 1 (TRUE) for correlation with G-CDRs in node #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. 2 CDRs in CG. DN03353543 Issue 10 en # Nokia Corporation 65 (111)
  66. 66. Functional Description of Charging Gateway 4.3 66 (111) # Nokia Corporation DN03353543 Issue 10 en
  67. 67. 6 Distributor subsystem 6.1 Overview of Distributor subsystem Distributor subsystem The Distributor subsystem logically follows the CDR processing in Core. The Figure Architecture of CG illustrates the position of Distributor in Charging Gateway. This subsystem converts CDR data from the CG-internal format to an external 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 the Traffica converter is used. For a description of the architecture, see the Figure Distributor architecture. DN03353543 Issue 10 en # Nokia Corporation 67 (111)
  68. 68. Figure 11. Distributor architecture Distributor operation Functional Description of Charging Gateway 4.3 CG internal interface 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 from database. 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 converter modules and the protocol handlers for data sending. Distributor also checks for the existence of the FTP NOK file and the sequence number files. If the needed 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 to the external data format. Distributor also updates the corresponding Key Performance Indicator (KPI) every time one CDR is read from the queue and after the CDR is converted to the output format. When a threshold is exceeded, the output file is closed. Header and trailer for the CDR file may be generated. Trailer and header generation is an optional feature. Administrator main application Converter post-processing system Protocol handler D A P I D A P I 68 (111) # Nokia Corporation DN03353543 Issue 10 en

×