SGSN-1

Charging

dn0221949Issue 7 en

' Nokia CorporationNokia Proprietary and Confidential

1 (39)

ISNDO0040.00Nokia GGSN Release 4.0 ProductDocumentation

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

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

Nokias liability for any errors in the document is limited to the documentary correction of errors.NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENTOR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARYLOSSES), that might arise from the use of this document or the information in it.This document and the product it describes are considered protected by copyright according tothe applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

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

Copyright ' Nokia Corporation 2003. All rights reserved.

2 (39) ' Nokia CorporationNokia Proprietary and Confidential

dn0221949Issue 7 en

Charging

Contents

Contents 3

1 Introduction to Charging 5

2 Functional description of Charging 112.1 Charging parameters 112.1.1 Parameters for 2G-SGSN Charging 112.1.2 Parameters for 3G SGSN and GGSN Charging 122.2 Charging statistics 172.3 Charging alarms 182.3.1 2G-SGSN alarms 182.3.2 3G SGSN and GGSN alarms 202.4 Handling Charging Gateways 232.5 Features related to Charging 24

3 Charging records 273.1 CDR types 273.2 CDR format 283.3 Intermediate/manual CDR generation and tariffing 283.4 Overload control in 2G-SGSN 29

4 GTP' in Charging 31

5 Interfaces related to Charging 35

6 Compatibility issues in Charging 37

7 Main changes in Charging 39

dn0221949Issue 7 en


3 (39)

Contents


dn0221949Issue 7 en

Charging

1 Introduction to ChargingThe charging architecture for packet-switched networks in the Nokiaimplementation is based on the use of the Charging Gateways (CG). 2G-SGSN,3G SGSN, and GGSN (GSNs) collect charging information, generate ChargingRecords (CDRs), and send them to a CG. The CG, then, further analyses theinformation received from various sources, such as other SGSNs and GGSNs,and finally passes the consolidated data to a billing system.

GSNs collect charging information in the core network from each attachedsubscriber. The GSNs have slightly different functions: 2G and 3G SGSNs collectinformation involved with radio network usage, while GGSNs collect charginginformation involved with external data network usage. In addition, all GSNscollect charging information on the usage of packet-switched network resources.The produced CDR types in GSNs fall into six categories:

" Mobility Management CDR (M-CDR) generated by 2G and 3G SGSNs

" SGSN CDR (S-CDR) generated by 2G and 3G SGSNs

" Mobile-originated SMS-CDR (S-SMO-CDR) generated by 2G and 3GSGSNs

" Mobile-terminated SMS-CDR (S-SMT-CDR) generated by 2G and 3GSGSNs

" GGSN CDR (G-CDR) generated by GGSNs

The charging functionality generates CDRs when a pre-defined event (forexample, a PDP Context Deactivation) occurs. It places CDRs into a chargingpacket and transfers the packet to the correct CG. The transfer protocol used isGTP over UDP/IP.

The main charging features supported are:

" Data volume based charging

" Time based charging

" Intermediate CDR generation

dn0221949Issue 7 en


5 (39)

Introduction to Charging

" Manual CDR generation

" Tariffing

" Hot Billing

" Flat Rate charging

" Prepaid service

" Duplicate CDR removal

" CAMEL services (in 2G and 3G SGSNs)

Note

This first release of this document covers Nokia 2G-SGSN release 3, 3G SGSNrelease 2, and GGSN release 3. Unless otherwise stated, all information anddescriptions apply to all three GSN types.

Below is a figure showing the architecture of Charging in a 3G environment.


dn0221949Issue 7 en

Charging

Figure 1. Generic charging architecture in a 2G/3G environment

Software and hardware requirements

Charging is a basic function of the GSNs, so no additional software or hardwareis required beyond the basic package for each GSN type.

Compliancy

Nokia's Charging implementation is based on the following standardspecifications:

BSC/RNC

PSTN

HLR/AC

EIR

2G-SGSN/3G SGSN

BillingSystem

ChargingGateway

GGSN

Corporate 2

Corporate 1

Internet

MSC

Server

Server

SCP

Gb/Iu

Gn

GaGa

GiGi

Gi

SS7network

dn0221949Issue 7 en


7 (39)


" 3GPP TS 32.200 Telecommunication management; Chargingmanagement; Charging principles, Release 4, version 4.1.0

" 3GPP TS 32.215 Charging Data Description for the Packet SwitchedDomain, Release 4, version 4.1.0

Capacity

The capacity in Charging is not directly dependent on the number of active PDPcontexts, but on the number of CDRs created. Capacity figures for 3G SGSN arenot yet available.

For 2G-SGSN, the maximum number or simultaneous subscribers is 320,000.Each of these subscribers can have a maximum of 4 open PDP contexts, with aguarantee of at least one. One 2G-SGSN can handle a maximum of 10 CGs.

For GGSN, several tests concerning Charging capacity were done for GGSNrelease 2.1, and the results are displayed below.

The CDR sender's maximum sending capacity was measured to verify that it isnot the bottleneck in GGSN. It was done by filling the CDR send queue and thenstarting the CDR sending. The maximum CDR generation rate of GGSN isreached when using manual CDR generation. The maximum rate is 5000 CDRs/second.

Table 1. Comparison between GTP version 0 or 2 when sending CDRs

GTP' version 0 2

CDR size (in bytes) 120/128 208

CDRs in one GTP packet 12 7

Maximum sendingcapacity of CDRs/second

76189 38800

Note

The CDR size for GTP v0 is 128 bytes if it includes the MSISDN.


dn0221949Issue 7 en

Charging

A second test was performed to see the effect of the CDR generation onmaximum throughput. This test was done by changing the volume threshold ofCDR generation to alter the CDR generation rate while sending the maximumamount of traffic through the GGSN (1400-byte long packets were used). Theresults are shown in the following table:

Table 2. Results of maximum throughput test

CDRs created/second Packets/second Percent less

0 16915 -

5 16905 0%

525 15745 0.7%

1550 12200 28%

2350 9700 43%

3400 6780 60%

Restrictions

abstract syntax notation one (ASN.1) encoding is supported.

CDR content is Nokia proprietary. Third parties cannot modify or view CDRcontent.

Related features

Quality of Service (SY00026) has a relative impact on Charging. If the QoS for agiven user is decreased, it will make the Charging feature create a container(GGSN) or a CDR (3G SGSN) for the user. Charging itself does not have animpact on other features.

In 2G-SGSN and 3G SGSN, Charging interacts with Server Based Prepaid(SY00002), CAMEL phase 3 (SY00016). See Features related to 3G SGSNCharging for further details.

dn0221949Issue 7 en


9 (39)



dn0221949Issue 7 en

Charging

2 Functional description of ChargingWhenever a PDP context is created, the Charging functionality starts collectingcharging-related data. This information includes counters on how many bytes aretransmitted in both uplink and downlink for that PDP context. Any change in thetraffic activity for that PDP context alerts the Charging module to update counterswith the information on the traffic flow.

2.1 Charging parameters

2.1.1 Parameters for 2G-SGSN Charging

There are several MML programs for handling the SGSN Charging feature. Forfurther information, see the corresponding MML document.

" SGSN Charging Handling MML (SGHHAN)

The SGSN charging handling is used for handling different SGSNcharging parameters, for example: CDR properties and charging gatewayIP addresses. See SGSN Charging Handling.

" GPRS Network Handling MML (GSNHAN)

The GPRS network handling is used for handling several different SGSNparameters. It is also used for handling the following charging parameters:the CDR Exception Handling parameter, the Cell Accuracy parameter andthe Charging Release parameter. See GPRS Network Handling.

" Day Classes Handling MML (DAYCLA)

The day class handling is a part of the SGSN tariff handling feature.DAYCLA is used for creating and deleting special days and for modifyingday classes of special days and weekdays. See Day Classes Handling.

dn0221949Issue 7 en


11 (39)

Functional description of Charging

" Change Groups Handling MML (CHGROU)

The change group handling is a part of the SGSN tariff handling feature.CHGROU is used for creating, modifying, deleting and interrogatingchange groups. See Change Groups Handling.

" Charging Zones Handling MML (CHZONE)

The charging zone handling is a part of the SGSN tariff handling feature.CHZONE is used for creating, modifying, deleting and interrogatingcharging zones. See Charging Zones Handling.

2.1.2 Parameters for 3G SGSN and GGSN Charging

The parameters and parameter values related to Charging, which can beconfigured using the Voyager interface of the respective 3G SGSN or GGSN, arelisted in the following table. Note that the parameter names are not exact. GSNdevelopment is on-going, so the actual parameters names seen in Voyager (theWeb interface) may differ.

Parameters Values Description

Uplink Data Threshold 1024-4294965000 The number of bytes in the uplink which causesCDR triggering when it is reached for a PDPcontext of a normal user. There areindependent thresholds for prepaid/hotbillusers.

Downlink Data Threshold 1024-4294965000 The number of bytes in the downlink whichcauses CDR triggering when it is reached for aPDP context of a normal user. There areindependent thresholds for prepaid/hotbillusers.

Uplink Data Threshold forPrepaid and Hotbilling Users

1024-4294965000 The number of bytes in the uplink which causesCDR triggering when it is reached for a PDPcontext of a local prepaid or hotbill user.

Downlink Data Threshold forPrepaid and Hotbilling Users

1024-4294965000 The number of bytes in the downlink whichcauses intermediate CDR triggering when it isreached for a PDP context of a local prepaid orhotbill user.

Minimum Data Threshold 0-4294965000 This parameter restricts the generation ofCDRs until this threshold is reached. This valueis used for both up and downlink data. It isalways checked internally against the uplinkand downlink data thresholds so that the valuehere is never greater to those.


dn0221949Issue 7 en

Charging


Manual CDR Generation True | False When the value of this parameter is set totrue, CDR generation is manually forced forall active PDP contexts. After all theintermediate CDRs have been generated, thecharging functionality changes the valueautomatically back to false.

Charging Functionality 1=enabled2=disabled

With this parameter the operator can enable ordisable the charging functionality. If thecharging functionality is disabled, no CDRs arecreated.

Prepaid Functionality 1=enabled2=disabled (normalCDRs)3=disabled (no CDRs)

This parameter shows the status of the prepaidfunctionality. Enabled means prepaidfunctionality is enabled and prepaid CDRs canbe created for local prepaid users. Disabled,send CDRs means that, although the prepaidfunctionality is disabled, the GSN stillgenerates (normal) CDRs for local prepaidusers. Disabled, no CDRs means prepaid isdisabled and no CDRs are created for any localprepaid users.Note! If the charging functionality is disabled,this parameter has no effect.

Hotbilling Functionality 1=enabled2=disabled (normalCDRs)3=disabled (no CDRs)

This parameter shows the status of the hotbillfunctionality.Enabled means hotbillfunctionality is enabled and hotbill CDRs canbe created for local hotbill users. Disabled,send CDRs means that, although the hotbillfunctionality is disabled, the GSN stillgenerates (normal) CDRs for local hotbill users.Disabled, no CDRs means hotbill is disabledand no CDRs are created for any local hotbillusers.

Note! If the charging functionality is disabled,this parameter has no effect.

Flatrate Functionality 1=enabled

2=disabled

With this parameter, the operator can enable ordisable the flatrate functionality. If thefunctionality is enabled, the local flatrate usersdo not cause CDRs to be sent. If disabled, thelocal flatrate users are treated as normal users.

Note! If the charging functionality is disabled,this parameter has no effect.

dn0221949Issue 7 en


13 (39)



CDR Generation Interval 0-1440 With this parameter the operator can set theinterval in minutes, which is used to generateintermediate CDRs from the active PDPcontexts.

Note! The value 0 indicates that no time-basedintermediate CDRs are generated.

Generation Interval PrepaidHotbilling

0-1440 This is the intermediate CDR interval applied tolocal hotbill and prepaid users. Value 0indicates that no intermediate CDRs (timewise) are generated.

Node ID Characters (20) Name of the GSN.

Charging Tariff Change TimeTable

Table of indexes With these parameters the operator can set theTariff Change Times. These times are used totrigger CDR generation.Each table entry includes the following:" Change Minute (0-59): the minute of the

tariff change" Change Hour (0-23): the hour of the tariff

change" Row Status: sets the status of a table entry

in the current configuration. If the status isactive, then the table entry is applied in thecurrent configuration, otherwise not.

Note! When adding a new Tariff Change Time,the operator must give it as hours and minutes.The maximum number of Tariff Change Timesis restricted to 24.

IMSI Table Table of indexes Set of IMSIs which will be considered to belocal users. The maximum number of activeIMSIs is set to 10. An entry in the IMSI tableconsists of the two fields, IMSI number andstatus. The IMSI number contains the MMCand MNC numbers of a user (basically, theoperators ID); for example, if the MMC of theoperator is 123 and the MNC is 45, the entryshould read 12345 in this field. The status, as inthe tariff table, can be either active (take it inuse) or not in service (do not use it).

Maximum CDR Send QueueLength

10000-200000 (max.450000 in GGSN)

The size of the CDR send queue. With thisparameter the operator can set how manyCDRs will fit into the send queue.


dn0221949Issue 7 en

Charging


Send Queue Alarm Threshold 20-100% The percentage value of the used memory ofthe CDR send queue. With this parameter theoperator can set that after this value is reacheda specific sendQueueThreshold ALARM trapis created and sent to the NMS. There is analarm threshold for each charging type.

Charging Packet TransferInterval

50-360000 The transfer interval of charging packets inmilliseconds. With this parameter the operatorcan set the initial (desired) interval of chargingpacket transfer in milliseconds. The GSNusually uses this value, but can also alter itdynamically according to the length of the CDRsend queue.

Ack Wait Time 50-65536 The wait time of charging packetsacknowledgement in milliseconds. With thisparameter the operator can set how manymilliseconds the GSN waits for theacknowledgement of a charging packet fromthe CG.Note! When this time is reached, chargingpackets are resent (if so configured).

Charging Transmit Window Size 1-256 The transmit window size of charging packetswhich are not acknowledged. With thisparameter the operator can set how manycharging packets can be in theunacknowledged state at the same time.

Charging Packet ResendNumber

0-15 Number of resent attempts. With this parameterthe operator can set how many times chargingpackets will be resent from the GSN to the CGin case of transfer failure or delayedacknowledgement.

CDR Exception Handling 1 = possible discard2 = possible duplicate

The special CDR exception handling. With thisparameter the operator can set the CDRexception handling parameter to possiblediscard or to possible duplicate. Thisparameter is very seldom (hardly never) used,but if a certain special situation happensbetween the GSN and the CG using theduplicate CDR removal mechanism, theoperator can choose what to do with the CDRs.

DSCP Marking For GTPPackets

0-63 DSCP marking for GTP packets. With thisparameter the operator can set thedifferentiated service codepoint marking theGTP packets sent to the CG.

dn0221949Issue 7 en


15 (39)



Encoding Method fixed | TLV The name of the encoding method used toencode charging information into a CDR. Withthis parameter the operator can set whichencoding method is in use at that time for allcreated CDRs.TLV is the recommended value. Fixed issupported only to provide backwardscompatibility.

Charging Gateway Table Table of indexes List of CGs visible to the GSN. The maximumnumber of active CGs is set to 64. Each entry inthe table has the following fields: IP address(the IP address of the CG), Priority (priority ofthe CG; highest priority is 1 and lowest is 100;several entries can have the same priority), andstatus (if the CG is active or not in service).

Fair Charging 1=enabled2=disabled

This operator configurable parameter is used todescribe whether the Fair Charging feature is inuse (enabled) or not (disabled). Thisparameters in only found in 3G SGSNs.

GGSN IP Address IP address IP address of the GGSN network element tothe GPRS backbone. This address must be avalid address for the GGSN. If this address isincorrect, the charging functionality will not beenabled. This parameter is only found inGGSN.

Ga Address IP address IP address of the Ga interface (charging) forthe GSN. It must be a valid GSN address. Theoperator can set it to the Gn address.

CDR Sending Enabled | Disabled Enables/disables the CDR sender process. Ifdisabled, no CDRs are sent to the CGs, andCharging is disabled.

GGSN Process Enabled | Disabled Enables/disables the GGSN. For charging tobe fully operational, both CDR Sending andGGSN Process must be enabled. Thisparameter is only found in GGSN.

Active Index index This parameter allows the operator to set adesired CG as the active CG for the GGSN. Bydefault, it takes the CG with higher priority Thisparameter is only found in GGSN.

Charging Protocol Version GTP2 GTP protocol version. (Only GTP v2 issupported)


dn0221949Issue 7 en

Charging

2.2 Charging statistics

2G-SGSN statistics

The following are some examples of CDR Measurement counters in 2G-SGSN:

" Average CDR recovery buffer utilisation

" Peak CDR recovery buffer utilisation

" Number of CDRs generated

" Number of discarded CDRs due to buffer overflow

" Number of discarded CDRs due to other reason than buffer overflow

" Number of CDRs resent to the Charging Gateway

There are separate counters for each type of CDRs. For more information, seeSGSN Counters (CDR Measurement counters: 008001008034).

3G SGSN and GGSN statistics

The operator can access charging statistics with the Voyager interface. TheCharging-related statistics are:

CDR output queue length - The number of CDRs in the CDR output (send) queuein the GSN. The GSN updates this value when adding or removing CDRs to/fromthe output queue.

Number of created CDRs - Total number of CDRs (for each type) created in theGSN after (re)initialisation. The counter starts at value of zero. The GSNincreases it by one every time it creates a CDR (normal, prepaid or hotbill).Maximum number shown is 232-1 (4 294 967 295). After that, it starts over fromzero.

Number of discarded CDRs - The total number of CDRs (for each type) that theGSN has discarded after (re)initialisation or after the number of created CDRs hasreturned to zero. Initially this counter has the value zero. The GSN increases it byone every time it discards a CDR, due to buffer overflow, after trying to resend ita given number of times, or for some other reason. After the maximum valued(232-1) is reached, the counter starts again at zero. It returns to zero also when thenumber of created CDRs returns to zero.

dn0221949Issue 7 en


17 (39)


Number of resent CDRs - The total number of CDRs that the GSN has resentafter (re)initialisation, or after the number of created CDRs has reached themaximum of 232-1. The counter starts at a value of zero. The GSN increases it byone every time it resends a CDR. Resending is initialised by a timeout, becausethe timeout has not received acknowledgement of the sent CDR. A CDR can beresent several times before an acknowledgement is finally received. After themaximum valued (232-1) is reached, the counter starts again at zero.

Avg.%x10 CDR output queue length - This is the average percentage (x 10) ofthe CDR when the output equals the CDR queue length. This is used over a givenperiod of time and ends when the last sample is taken. The counter will return tozero when the calculated result is outside the allowed range. The allowed range is0 to 1000. This statistic is only for GGSN.

Avg.%x10 discarded CDRs - The average percentage (x 10) of the discardedCDRs over the total number of CDRs, when created in a defined period of time.The counter will return to zero when the calculated result is outside the allowedrange. The allowed range is 0 to 1000. This statistic is only for GGSN.

Avg.%x10 resent CDRs - The average percentage x 10 of the resent CDRs overthe total number of CDRs, when created in a defined period of time. The counterwill return to zero when the calculated result is outside the allowed range. Theallowed range is 0 to 1000.

CDR Exceptions Handled - CDR exceptions handled. This statistic is only for 3GSGSN.

2.3 Charging alarms

2.3.1 2G-SGSN alarms

Table 3. 2G-SGSN charging-related alarms

Alarm number Alarm name Description

1064 UNIT UPDATE FAILURE Failure in the updating of the partner unit oranother unit to be updated. The file has not beenupdated in the unit which received the updatinginput, either.

1065 DISK UPDATE FAILURE A file modification has not been updated ontodisk.


dn0221949Issue 7 en

Charging

Table 3. 2G-SGSN charging-related alarms (cont.)

Alarm number Alarm name Description

2060 CENTRAL MEMORY FILEERROR

The system has detected an error in the files ofthe central memory.

2062 EXCESSIVE ERRORS INCENTRAL INCOMING DATA

This is an error ratio counter alarm.

2110 ERROR IN CHARGE RATEFILE

The charge selection program block (CHASEL)has detected an error in the contents of a chargerate file. New charge rates are not updated.

2111 CHARGE RATE ERROR The alarm is set when the charge rate of acharging zone does not correspond to thepredetermined value.

2112 CHARGE RATESDISTRIBUTION FAILURE

Distribution of the charge rate file was notsuccessful.

2497 TARIFF DISTRIBUTIONFAILURE

A notification of the new tariff information updatehas not succeeded in internal data transmission.

3009 SGSN RESEND BUFFERFULL

This alarm is set when an SGSN Chargingresend buffer is full.

3010 NO OPERATIONAL CGs This alarm is set when no operational CG NE IPaddresses can be found in the CGDFILparameter file.

3040 SGSN CHARGING FAILURE SGSN charging data collection has failed.

3056 AN INOPERATIVECHARGING GATEWAY

This alarm is set when a CG becomesinoperative.

3076 SGSN RESEND BUFFERBECOMING FULL

One or more Charging Gateway networkelements may be inoperable or temporarilyoverloaded with heavy processing tasks. As aresult, the SGSN charging resend buffer isbecoming full.

3165 CHARGING DATAOVERLOAD

This alarm is set when the long lasting overloadcontrol is set.

dn0221949Issue 7 en


19 (39)


2.3.2 3G SGSN and GGSN alarms

131093 CA_CANNOT_INIT_CHARGING

Severity 1

Reason The Charging function is unable to start up, either because it did not find therequired configuration files or the values of the configuration parameters arenot valid.

Supplementaryinformation

Charging configuration init failed, CDR generation init failed, or Chargingconfiguration reinitialisation failed.Charging is disabled.

Instructions Check the configuration and see that the parameters have correct values.

Cancelling Cancelled automatically after the next time the configuration file is readysuccessfully.

131095 CA_CANNOT_ACCESS_PDP_CONTEXT_TABLE

Severity 1

Reason The GGSN charging feature does not get the information needed to accessthe PDP context table, therefore, no CDRs for the user can be generated.


No accessPointName found.

Instructions There is a problem with the PDP context table. Check the ggsntunnel.log file.It may be necessary to restart the ggsntunnel process.

Cancelling This alarm is cancelled automatically after 100 successfully created CDRs.

131097 CA_CANNOT_CREATE_CDR

Severity 1

Reason The Charging feature cannot create CDRs because of an unsupportedencoding method.


Invalid cdrEncodingMethod.Charging is disabled.

Instructions Change the encoding method to a valid value.



dn0221949Issue 7 en

Charging

131099 CA_CANNOT_WRITE_TO_FIFO

Severity 1

Reason The GSN process cannot communicate with the CDR sender process usingthe internal fifo.


CDRSender collapsed or Fifo temporarily full.Charging is disabled.

Instructions Restart the CDR sender process.


131101 CA_SEND_BUFFER_THRESHOLD_CROSSED

Severity 3

Reason The CDR output queue is nearly full.


--

Instructions Check that the communication with an active Charging Gateway is working. Itmay be necessary to increase the maximum length of the CDRs outputqueue.

Cancelling This alarm is cancelled automatically as soon as the length of the CDR outputqueue has fallen below the threshold value.

131103 CA_CDRS_DISCARDED

Severity 1

Reason The GSN Charging feature has discarded CDRs.


--

Instructions Check that all the processes are up and running. Check the log file and theerror file to find a reason why CDRs are being discarded. Check the length ofthe CDR output queue. Dependant on the reason, it may be wise to increasethe maximum length of the CDR output queue, to restart the active ChargingGateway, or to add a new Charging Gateway to the GSN configuration.

Cancelling This alarm is cancelled automatically after the GGSN receives 100 positiveacknowledgements from the Charging Gateway.

dn0221949Issue 7 en


21 (39)


131167 CA_CANNOT_INIT_CDR_SENDER

Severity 1

Reason The CDR sender process is unable to initialise.


Cannot get starting variablesCharging is disabled.

Instructions Check the Charging configuration and make all the changes needed toproperly initialise the CDR sender.

Cancelling This alarm will be cancelled automatically after configuration has beenupdated correctly.

131169 CA_VERSION_NOT_SUPPORTED

Severity 2

Reason The GSN sends the CDR to a Charging Gateway that does not support theGTP protocol version of the GSN.


--

Instructions Change the configuration of the GSN charging in accordance with theconfiguration and/or the ability of the Charging Gateway to support the GTPprotocol. Restart the GSN process.

Cancelling This alarm is cancelled when the Charging Gateway configurations of theGSN are updated.

131229 CA_CONNECTION_TO_CG_LOST

Severity 2

Reason The GGSN CDR sender process fails to send the charging packets to theactive CG.


Active CG was "

Instructions Check the functionality of the CG.

Cancelling This alarm is cancelled when either1. a Node Alive message is received from that particular CG, or2. a reply to GGSN polling message is received from that particular CG.


dn0221949Issue 7 en

Charging

2.4 Handling Charging Gateways

Handling CGs in 2G-SGSN

When CG IP addresses are set in 2G-SGSN, new ones can be added and deleted,or their status can be updated even while CDR generation and transferring isgoing on, with the MML command GHU.

The only way to add or delete IP addresses is to use the MML command GHU.There are two alternative ways to delete IP addresses: forced delete and delayeddelete. If the IP address is deleted using the forced delete, it is removedimmediately regardless the possible duplicated CDRs. Whereas the delayeddelete does not remove the IP address immediately, but the status is changed andno new CDRs are sent to it. The idea is to give some time for the 2G-SGSN andthe CGs to find the status of possible duplicated CDRs sent to that CG. When thestatus of all sent CDRs is found or an hour has passed, the IP address is removed.

Meanwhile, the status can change without the use of MML commands accordingto the situation in the network. The status and priorities of CGs can be checkedwith the MML command GHI.

If the 2G-SGSN notices that a CG does not reply to its supervision, it informs thecharging, after which the status of the CG in question is updated in the CGDFIL.Respectively, if a CG starts to respond to its supervision again, the status of thisCG is updated.

The change of the CG status is strongly related to its priority. Sometimes thepositions of the CGs have to be changed, for example because the primary CG isnot working correctly. The CGs stay in their positions unless they are changed bythe user with the MML command GHU.

If a CG finds itself in trouble, it informs the SGSN about it. The CG can alsorecommend another CG to which its CDRs should be sent. If the CG does notrecommend another CG, its CDRs are sent to the primary CG.

If the CG recommends another CG, the CDRs are sent to it if the recommendedCG is found in the 2G-SGSN, and if it is operational. Otherwise the primary CGis used. The redirection is cancelled if the CG informs it is operational again or ifthe CG status is manually updated either to operational or not operational with theMML command GHU.

dn0221949Issue 7 en


23 (39)


The redirection information can be viewed by checking the contents of theCGDFIL parameter file with the MML command ZDFD. The redirection indexfor a CG is the 19th byte from the beginning of a record. It points to a CG IPaddress index in the CGDFIL.

Handling CGs in 3G SGSN and GGSN

In 3G SGSN and GGSN the Charging Gateways (CGs) are handled by theCharging Gateway Table, where the IP address, priority, and status of CG areconfigured and recorded. The Charging Gateway list can be configured using theVoyager web interface or the SNMP interface.

In GGSN there is an active Charging Gateway where all the CDRs are sent. IfThe CG doesn't reply to the Data Record packets sent by GGSN, the next CGaddress in the prioritized list will be selected as active. Also an alarm is raised toindicate that the active CG went down.

In 3G SGSN there is no active CG. The CG where an individual CDR will be sentis the same as the active CG of the GGSN where that particular PDP context wascreated. Information about active CG in GGSN is delivered to SGSN in CreatePDP Context response and Update PDP Context response messages. If sendingof the Data Record packet fails, the packet will be sent to next CG in the list. IfCDRs which should be sent to a CG that is down are created, they are directlyforwarded to the next CG in the list. Only after the duplicate situation is resolved,the CDRs will be sent to that CG again.

2.5 Features related to Charging

Server Based Prepaid (SY00002)

The Nokia GSNs contains support for prepaid charging that identifies prepaidsubscribers from other users, and generates their CDRs more frequently thannormal, non-prepaid CDRs.

Charging in the GSN has configuration parameters that determine whether theprepaid functionality is in use as well as specific volumes and thresholds forprepaid subscribers.

When a UE attaches to the network, the GSN learns from the HLR if thesubscriber is a prepaid customer. When a PDP context is activated, a prepaid flagin the subscriber's profile marks the PDP context entry for that user as beingprepaid, and thus determines the threshold values for the intermediate CDRs of


dn0221949Issue 7 en

Charging

that PDP context. In addition, the GSN marks the CDRs with prepaid chargingcharacteristics, information that is used by other system elements involved in theprepaid implementation. Otherwise, a prepaid CDR and a normal CDR containexactly the same information.

There is no special queue or priority for handling the prepaid CDRs. The prepaidCDRs are sent to the CG, which immediately forwards them to the PrepaidServer. This entity can disable the subscriber from the HLR if there is no morecredit remaining. The HLR may then request deactivation the subscriber's PDPcontexts. The GSN itself does not know the prepaid limit for the subscriber.

CAMEL Phase 3 (SY00016)

CAMEL (Customised Applications for Mobile network Enhanced Logic) phase 3is a new feature for 2G and 3G SGSNs. This feature provides mechanisms tosupport services independent of the serving network. When a CAMEL service isinvolved in the GPRS session, PDP contexts and/or mobile-originated shortmessages, additional CAMEL information is included in the generated chargingrecords (M-CDR, S-CDR and S-SMO-CDR respectively). The included CAMELinformation contains basic information about the used CAMEL service (forexample, service key, SCF address and service usage), information aboutCAMEL service modified parameters (for example, APN) and transparentlyhandled free format data from the SCP.

When the SCP releases the PDP context or GPRS session by using the ReleaseGPRS operation, the 2G or 3G SGSN uses the cause CAMELInitCallRelease inthe M-CDR and/or S-CDR.

dn0221949Issue 7 en


25 (39)



dn0221949Issue 7 en

Charging

3 Charging records3.1 CDR types

Charging produces five different types of charging records (CDRs):

1. S-CDR (SGSN CDR) and G-CDR (GGSN CDR)

The GSN starts collecting CDRs information when a new PDP context isactivated, except for local flatrate subscribers if flatrate service is enabled.GGSN uses multiple containers to collect charging information. One CDRcan have serval containers. SGSN uses five containers per CDR. A CDR orcontainer is triggered on the following events:

" tariff change time reached (container)

" manual generation (CDR)

" Quality of Service (QoS) change (container)

" PDP context release (CDR)

" up/downlink data volume reached for a charging type (CDR)

" intermediate CDR time reached for a charging type (CDR)

" abnormal release (CDR)

" SGSN change (CDR in SGSN, container in GGSN)

2. M-CDR (Mobility Management CDR)

The 2G-SGSN / 3G SGSN starts collecting M-CDR information whenthere is a new GPRS Attach. An M-CDR is triggered on the followingevents:

" Routing Area Update

" GPRS Detach

" manual generation

" time out

dn0221949Issue 7 en


27 (39)

Charging records

3. S-SMO-CDR (Mobile-originated SMS CDR)

An S-SMO-CDR is generated for every short message transferred throughthe 2G-SGSN / 3G SGSN in uplink direction. No active PDP context isrequired when sending or receiving short messages.

4. S-SMT-CDR (Mobile-terminated SMS CDR)

An S-SMT-CDR is generated for every short message transferred throughthe 2G-SGSN / 3G SGSN in downlink direction. No active PDP context isrequired when sending or receiving short messages.

3.2 CDR format

There are two different types of CDR format: Fixed1 and TLV1. TLV1 is thedefault value; Fixed1 is supported only to provide backwards compatibility.

The new information elements introduced by the new features are possible onlyin CDRs that are in TLV1 format. TLV1 is an optimised format which means thatonly existing data is sent. The use of TLV1 format requires an update in the CG.

In 2G-SGSN, these two formats are reflected in the CDR versions, SG2+ andSG3. When the 2G-SGSN charging starts up, the CDR version is selectedaccording to the Charging Release Level (CRL) parameter value. The initial valueof the CRL parameter is SG2+. As soon as the parameter value is changed, thenew CDRs are produced according to the new, selected version.

3.3 Intermediate/manual CDR generation and tariffing

One of the features of Charging is that the operator can configure when togenerate intermediate CDRs. A user might have a very long session, and it wouldbe unfeasible for the operator to get CDRs only at start-up and close of thesession. Therefore, Nokias GSNs support intermediate CDR sending: theoperator can configure both time and/or volume based thresholds differently fornormal and prepaid/hotbill users.

A volume based threshold means that an intermediate CDR is sent for a user whotransmits/receives more than a given number of bytes. The operator can configuredownlink and uplink thresholds for normal and prepaid/hotbill users. Uplink anddownlink thresholds are treated as one CDR trigger.

A time based data threshold means that an intermediate CDR is sent for a userwho has not caused a CDR to be sent in a given number of seconds. Thisthreshold can be disabled by setting the value to zero seconds.


dn0221949Issue 7 en

Charging

Note

After an intermediate CDR has been sent, all volume counters are reset to zero.

In addition to the volume/time based intermediate generation, an operator canforce, at any given time, the creation of intermediate CDRs for all PDP contextswhich are active at that time. However, this operation is quite costly, creating aheavy load on the CPU (which must go through all the PDP contexts), so itshould be done seldom and with great care.

Tariffing

The operator can establish tariff times to bill the user differently depending on thetime of the day. The tariff times are configurable via the Voyager Web interface in3G SGSN and GGSN. In 2G-SGSN tariffing is controlled using the MMLcommand sets Change Groups Handling, Charging Zones Handling, and DayClasses Handling. Whenever there is any activity for an active PDP context aftera tariff change, the GSN will generate an intermediate CDR with the informationstored up to that point in time (so the tariff before the tariff change time can beapplied). After that, it will process the received information normally.

3.4 Overload control in 2G-SGSN

2G-SGSN Charging implements also the overload control feature. The idea of theoverload control feature is to prevent the charging from choking under the floodof CDRs.

The overload control feature, which includes actually two features that functionquite independently, is a part of the normal 2G-SGSN charging. In other words,the overload control feature is always active, but has naturally more importanceduring the busy hour.

Charging data peaks are prevented by changing the charging function after aPAPU reset or switch over. Unlike before, the CDRs under the reset PAPU are notsent immediately but only when the time trigger expires or a new attach is madewith the same IMSI. To avoid data peaks the execution of MML command GHA isnot allowed when there are a lot of CDRs in the 2G-SGSN.

dn0221949Issue 7 en


29 (39)

Charging records

A long lasting charging data overload is prevented by keeping the effective andthe set CDR creation triggers separate. CDRs are created according to theeffective triggers, which are usually the same as - and never smaller than - the setones. These effective triggers are kept higher than the set ones, when too manyCDRs are to be sent per minute according to the set triggers. When the overloadsituation ends, the effective triggers are slowly adjusted to the same values as theset ones.


dn0221949Issue 7 en

Charging

4 GTP' in Charging'GTP' is a protocol affecting three key aspects of charging:

" CDR sending

" CDR duplicate prevention mechanism

" signalling with CGs

CDR sending

Whenever there is some activity for an active PDP context, the chargingsubsystem checks if there is any condition to force the generation of a CDR.Activities for a PDP context include packets moving from/to the mobile attachedto the PDP context, a QoS change request, an SGSN change, and closing of thePDP context.

When a packet is received, if no special conditions are met, the GSN just storesthe information without generating a CDR. If that packet exceeds a volumethreshold, the GSN generates an intermediate CDR. If, when receiving the packet,the GSN notices that a time threshold (tariff included) has been exceeded, itcreates an intermediate CDR before handling the received packet.

If there is a QoS change, SGSN change, or tariff time change (just after a packetarrived), the GSN generates a container within the CDR. However, filling up acontainer does not guarantee the sending of a CDR. A single CDR can have up tothree containers (in GGSN). After the third container is filled, an intermediateCDR is generated.

Other causes of CDR generation include PDP context release, abnormal release,and manual generation of CDRs forced by the operator.

Once a CDR is generated, it is sent to the CDR sender (a stand alone process)which places them in the send queue, from where they are immediately (or asconfigured) sent to an active CG. The CDR sender maintains a "transmitwindow", which contains sent CDRs that have not been acknowledged. The sizeof the transmit window is configurable.

dn0221949Issue 7 en


31 (39)

GTP in Charging

CDRs are placed inside GTP' packets. One packet can carry several CDRsdepending on the encoding method used, fixed or type-length-value (TLV). WithTLV, content also affects how many CDRs are in a packet. The transmit intervalof charging packets changes dynamically to avoid

" overloading the CG (by increasing the send interval), and

" losing CDRs because the send queue fills up (by decreasing the sendinterval).

CDR duplicate prevention mechanism

The CDR sender also supports the duplicate CDR prevention mechanism, asrequired by GTP.

The purpose of this mechanism is to prevent duplicate CDRs ending up in thebilling system. When sending a packet to a CG has been attempted a certainnumber of times (configurable parameter), the packet is marked as duplicate andsent to the next CG in the priority list. After that, special GTP' messages are usedto determine whether duplicate packets should be released to the billing system,or cancelled (also a configurable parameter). This last configurable parameter istaken into use only if the CG is down for over 24 hours.

Sequence number usage

The GSN has a separate packet sequence number counter for each CG. Countersrun from 0 to 65535 and back to 0 again. The counter runs quite fast, thereforethere has to be a way to ensure the sequence numbers are unique so that the CGknows which packets it has already received and which are new.

This is done by using half the allowed value range, that is 32767 sequencenumbers, for the received numbers that the CG keeps track of. If CG receives apacket with a sequence number outside of that range, the packet is considerednew and the counter starts from that new sequence number. If the sequencenumber of a new packet is inside the value range, then the CG checks if thatpacket has already been received and replies accordingly.

This means that the GSN cannot send data record packets having a sequencenumber that is more than 32766 units away from first unacknowledged datarecord packet. However, there are two very rare situations where this mighthappen:


dn0221949Issue 7 en

Charging

" The GSN is sending data record packets with great speed. Some packetsare acknowledged and others are not. While the unacknowledged packetsare waiting for acknowledgement, the sequence numbers of those packetsexceed the value range that the CG is using. GGSN prevents this bystopping the data record packet sending until the situation with the firstunacknowledged packet is resolved. This is a very rare situation, becausethere can only be 32766 packets sent while the first unacknowledgedpacket waits for the acknowledgement.

" Let us assume that a GGSN has two CGs on its priority list, CG1 and CG2.CG1 is the active one; CG2 is non-active. GGSN sends packets to CG1. Itdoesn't get acknowledgment of packet with sequence number X. CG1 inthe meantime becomes inactive, so GGSN switches CGs and starts sendingpackets to CG2. Later CG1 becomes active again (operator changes stateof CG1). The GGSN keeps sending packets from sequence number Xonwards, but by this time the sequence number value range has beensurpassed, so an error occurs. This is very rare situation; normally theGGSN prevents this by not allowing CG1 to take over again. It sets activeCG back to CG2.

Signalling with Charging Gateways

The two GTP signals the CG can send to the GSN are the 'node alive request' andthe 'redirection request'. The GSN responds to them with a 'node alive response'or 'redirection response', respectively. The GSN can read both requests eitherfrom the Gn interface or the Ga interface (both addresses are configurable). TheCG must send the signals to either of those addresses.

With a redirection request, the CG announces to the GSN that it is about to godown. The GSN checks the sender of the signal (it must be a CG in the CG list),processes it, and replies to the CG. The reply will normally be a requestaccepted, but if, for instance, the sender of the signal is the only CG in the list(or the only one in service), the GSN will reject the request. The redirectionrequest signal might contain a recommended address. In that case, the activeCG will become that recommended CG. This feature is supported by the GSNbut not by the current version of Nokias CG.

The second signal is the node alive request. The GSN checks that the signal issent from a valid CG (in the CG list) and will set that node as the active CG if itspriority is higher than the priority of the active CG presently in use. The nodealive request also generates a response to the sender, though the response does notinclude a status of the operation like redirection response.

There is a third signal, the 'echo request', which is sent from the GSN to the CG.With this signal, the GSN knows if a given CG is alive. This signal is notsupported by the GSN; instead, it uses possible duplicated empty CDRs tosimulate the same polling effect as the echo request.

dn0221949Issue 7 en


33 (39)

GTP in Charging


dn0221949Issue 7 en

Charging

5 Interfaces related to ChargingOperator interfaces for Charging

The main operator interface for 3G SGSN and GGSN is Web interface, Voyager.With the Voyager interface, the operator can configure the Charging parameters,including the possibility to disable Charging altogether, and view Chargingstatistics. SNMP can be used 2G-SGSN, 3G SGSN, and GGSN.

A command line interface is also available.

Subscriber interfaces for Charging

The subscriber, when (s)he joins the operators network, (s)he negotiates theconditions of the contract, which will include, among others, the type of charging,known as Charging characteristics. This type of charging can have at least thefollowing values: normal, prepaid, hot billing and flatrate. Depending of the valueof that charging characteristics field, the charging feature will charge the userdifferently.

External interfaces for Charging

The charging feature is responsible of creating the CDRs and sending them to theconfigured Charging Gateway, where the CDRs are handled. Charging requiresthe Ga interface with the Charging Gateway using the protocol GTP' .

The GTP protocol is the standard protocol used by the GSN to both transmit theCDRs to CGs and receive the signals (node alive and redirection messages) fromthe different CGs.

The CG must be able to support the GTP protocol version 2.

Due to the nature of the CDRs (Nokia proprietary and with the content not openat the moment to other vendors), the GSNs cannot interact with CGs from othervendors.

dn0221949Issue 7 en


35 (39)

Interfaces related to Charging


dn0221949Issue 7 en

Charging

6 Compatibility issues in ChargingSGSN updating

GGSN release 3 supports both GTP version 0 and GTP version 1 protocols in theGn interface. This means that the GGSN can communicate with Nokias 2G-SGSNs and 3G SGSNs.

In an SGSN update in which the SGSNs are using different GTP protocols, theGGSN remains the same and keeps on sending CDRs as normal for that PDPcontext that had the SGSN change. For example, GGSN (release 3) is sendingTLV CDRs to the Charging Gateway as in the figure below. At the beginning ofthe PDP context, the GGSN was communicating with 3G SGSN which alsosends TLV records to the CG. Then, an SGSN update takes place and the PDPcontext is moved to the 2G SGSN. This SGSN only sends old fixed CDRs to theCG, but the GGSN still sends TLV CDRs to the CG for the PDP context.

Figure 2. SGSN update

3G SGSN

2G-SGSN

ChargingGateway

GGSN

SGSNupdate

GnGa

Gn

Ga

Ga

dn0221949Issue 7 en


37 (39)

Compatibility issues in Charging

Updating SGSNs does not impact Charging in GGSN.

GGSN update from GGSN release 2

The way a GGSN release 2 should be updated to a GGSN release 3 is the same asfor previous releases of GGSN. Upgrading can be done even when using oldCharging Gateways (CGs, versions 3.x or older), so long as fixed format is usedfor CDRs and not TLV. When the CGs are upgraded, TLV can be used.

Quality of Service compatibility

In general, SGSN and GGSN will send in their S- and G-CDRs the sameinformation related to the QoS profile for a given PDP context through the life ofthe context. Previously (in GGSN release 2), the problem was that the GGSNsent only release 99 QoS (9 bytes) information, so if the SGSN was sendingrelease 97 QoS (3 bytes only), the Charging Gateways could not see the match inthe QoS fields received from both GSNs for a given PDP context. GGSN release3 sends both release 97 and release 99 QoS, solving that problem.


dn0221949Issue 7 en

Charging

7 Main changes in ChargingChanges in 2G-SGSN

The changes between Nokia 2G-SGSN release and release 3 that affectedCharging include:

" implementation of CAMEL phase 3 (this has replaced the IN-basedprepaid charging)

" Charging upgrade - two versions of each CDR type can be produced: SG2+ and SG3 (version is controlled by the Charging Release Level parameter)

Changes in 3G SGSN

3G SGSN Charging is implemented in 3G SGSN release 2 with the followingchanges to 3G SGSN release 1:

" a new type of CDR format, TLV1

" The Server based prepaid feature is supported.

" The CAMEL phase 3 in 3G SGSN feature is supported.

Changes in GGSN

" Support for TLV (Type-Length-Value) encoding: With this addition, theCDR will contain only the needed fields and not all of them (as opposed tothe fixed format).

" CDR storage: GGSN release 3 stores to disk the CDRs which wouldotherwise be discarded when the CDR sender queue overflows. Thisensures that the CG receives all CDRs that it should. The transmission ofthe stored CDRs to the CG will be handled the same way as normalsending of CDRs. They will be placed into the send queue when there isagain free space.

" Support for multiple containers per CDR

dn0221949Issue 7 en


39 (39)

Main changes in Charging

ChargingContents1 Introduction to Charging2 Functional description of Charging2.1 Charging parameters2.1.1 Parameters for 2G-SGSN Charging2.1.2 Parameters for 3G SGSN and GGSN Charging

2.2 Charging statistics2.3 Charging alarms2.3.1 2G-SGSN alarms2.3.2 3G SGSN and GGSN alarms

2.4 Handling Charging Gateways 2.5 Features related to Charging

3 Charging records3.1 CDR types3.2 CDR format3.3 Intermediate/manual CDR generation and tariffing3.4 Overload control in 2G-SGSN

4 GTP' in Charging5 Interfaces related to Charging6 Compatibility issues in Charging7 Main changes in Charging

Date post:	23-Nov-2015
Category:	Documents
Upload:	akhilesh341
View:	17 times
Download:	2 times

SGSN-1

Documents