13 CN3401DEN30GLN1 Basics of Charging

CN3401DEN30GLN1

© Nokia Siemens Networks

1 (52)

3G Rel4 SCNOM

Basics of Charging Training Document

Basics of Charging

CN3401DEN30GLN1


2 (52)

Legal notice Intellectual Property Rights All copyrights and intellectual property rights for Nokia Siemens Networks training documentation, product documentation and slide presentation material, all of which are forthwith known as Nokia Siemens Networks training material, are the exclusive property of Nokia Siemens Networks. Nokia Siemens Networks owns the rights to copying, modification, translation, adaptation or derivatives including any improvements or developments. Nokia Siemens Networks has the sole right to copy, distribute, amend, modify, develop, license, sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individuals can use the Nokia Siemens Networks training material for their own personal self-development only, those same individuals cannot subsequently pass on that same Intellectual Property to others without the prior written agreement of Nokia Siemens Networks. The Nokia Siemens Networks training material cannot be used outside of an agreed Nokia Siemens Networks training session for development of groups without the prior written agreement of Nokia Siemens Networks. Indemnity 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 Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks 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 are given “as is” and all liability arising in connection with such hardware or software products shall be defined conclusively in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in the document as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY MONETARY LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT This document and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright © Nokia Siemens Networks 2009. All rights reserved.

Basics of Charging

CN3401DEN30GLN1


3 (52)

Contents

1 Objectives ...............................................................................................5

2 Introduction ............................................................................................6

3 Basic concepts of Charging..................................................................7 1.2 Charging...................................................................................................8 1.2 Billing........................................................................................................8 1.2 Accounting ...............................................................................................9 1.2 Chapter review .........................................................................................9

4 Basis for Charging ...............................................................................10 1.2.1 Installation ..............................................................................................10 1.2.2 Service rental .........................................................................................11 1.2.3 Network use ...........................................................................................11 1.2.4 Parameters for defining charging ...........................................................11 1.2 Chapter review .......................................................................................11

5 Detailed charging .................................................................................12 1.2 Charging record (CDR) ..........................................................................12 1.2.1 Exercise .................................................................................................15 1.2 Dynamic data formatting ........................................................................22 1.2 Dynamic data formatting record counter ................................................23 1.2 Collecting and storing charging data......................................................23

6 Charging data transfer to the BC........................................................26 1.2 Virtual Data Store...................................................................................27 1.2.1 Data file states .......................................................................................28 1.2.2 Control files ............................................................................................29 1.2 File use in normal billing.........................................................................30 1.2.1 FTAM solution ........................................................................................30 1.2 MML interface ........................................................................................35 1.2 Interfaces between the MSS and the BC ...............................................37 1.2.1 FTAM and FTP file transfer protocol ......................................................37

7 Charging data recovery .......................................................................40

8 Charging Hardware ..............................................................................41

9 Check your understanding..................................................................43

Basics of Charging

CN3401DEN30GLN1


4 (52)

Appendix……………………………………………………………………………….…46 1. Hot Billing………………………………………….…………………………………..46

1.1 Physical interface requirements ............................................................ 47 1.2.1 User interface ........................................................................................ 47 1.2 Charging Based on Home Area (optional)............................................. 47 1.2.1 Functionality .......................................................................................... 48 1.3 Transferring hot billing records .............................................................. 48

Basics of Charging

CN3401DEN30GLN1


5 (52)

1 Objectives Upon completion of this module, you should be able to:

• Describe the basic concepts of charging on the network level, including MSS/HLR

• Interpret a CDR to show the different factors that can affect the price of a call

• Describe the available interfaces between the MSS/HLR and the Billing Centre

• Explain how charging data is collected and transferred to the Billing Centre

• Describe how charging data can be recovered in a fault situation

Basics of Charging

CN3401DEN30GLN1


6 (52)

2 Introduction A subscriber making a call uses a variety of GSM network resources, which are included in the call charge. The system collects all charging data relating to a call in charging records, (CDRs), stores and transfers them to the Billing Centre for bill processing.

This module investigates the concepts of detailed charging, which entails collection and storing of charging data for call charging, and the transfer to the Billing Centre for bill processing.

It also discusses possible file transfer protocols and available interfaces between the MSS and the Billing Centre (BC).

Basics of Charging

CN3401DEN30GLN1


7 (52)

3 Basic concepts of Charging Charging involves more than just charging the subscriber for using operator network facilities. Other areas of charging are accounting, which essentially is charging between operators, and billing.

Figure 1 shows the three areas of charging:

• Charging

• Billing

• Accounting

MSC

BC

HLR

PSTNBSC

BC

MSC

HLR

BC

BC

Charging

Transfer ofCharging data

Billing

Bill to subscriber

Accounting

Accounting

Path ofthe call

Figure 1. Three areas of charging

Basics of Charging

CN3401DEN30GLN1


8 (52)

1.2 Charging

Charging involves collecting charging data about charging events used as a basis for determining the call charge and billing.

Methods for generating charging data are based on pulses or currency. The pulse method refers to the positioning of the first charging pulse when the call is established. In time charging, it refers to the number of metering pulses generated during the call, which determine the price. In time charging, there are two alternative charging methods: synchronous charging and asynchronous charging (Karlsson charging).

1.2 Billing

Billing is the service providing methods for converting the charging information produced in a network to actual call bills. It involves calculating call costs on the basis of charging information received from the MSS/HLR.

Billing is not a system feature of the DX 200. It is done in the BC, which is an external element to the core network connected through the MSS/HLR using data communication links, as illustrated in Figure 2.

Figure 2. Relationship between DX 200 charging functions and the Billing Centre

Basics of Charging

CN3401DEN30GLN1


9 (52)

1.2 Accounting

Accounting is the process for measuring use and determining costs for use of network services. Essentially, accounting is the process for calculating call costs and settling accounts between operators for use of network services.

Subscribers are not aware of the accounting that goes on between operators.

1.2 Chapter review

1. Describe the concept of charging.

______________________________________________________

______________________________________________________

______________________________________________________

2. What is the purpose of accounting?

______________________________________________________

______________________________________________________

Basics of Charging

CN3401DEN30GLN1


10 (52)

4 Basis for Charging Operators independently determine how subscribers are charged for use of network services by defining chargeable events as seen in Figure 3.

Operators generally use the following scheme as a basis for charging the subscriber, although rates can vary:

• Installation

• Service rental

• Network use

• Installation fee

• Service rental

• Network use

Figure 3. Basis for charging

1.2.1 Installation

Operators charge an installation fee for defining a subscriber's information in the network (HLR, SIM, AUC), creating a subscription, and issuing a SIM card.

Basics of Charging

CN3401DEN30GLN1


11 (52)

1.2.2 Service rental

Operators charge a monthly flat fee for renting the service.

1.2.3 Network use

Operators charge on a per call basis for use of the operator network.

Pricing for the above services varies, and is used to attract customers. For example, an operator can offer a free subscription as an incentive for subscribers to sign up.

1.2.4 Parameters for defining charging

You can use the following parameters to define charging:

• Type of basic service (voice (T11)

• Short Message Service (T21, T22)

• Duration of call

• Time of call

• Destination of call

• Origin of call

• Network use, (SPDN, PSTN, operator)

• Use of supplementary services (call forwarding, call barring)

• Use of radio network resources (HR, FR, EFR)

• Calling/called subscriber's mobile equipment type (single/dual mode)

• Cell type used in the call (GSM 900/GSM 1800)

• Roaming leg.

When subscriber-B roams in a fixed network, subscriber-A pays for the call. When subscriber-B roams in a mobile network, subscriber-B is charged for the roaming leg.

1.2 Chapter review

1. For what services do network operators generally charge?

Basics of Charging

CN3401DEN30GLN1


12 (52)

5 Detailed charging There are two types of charging in GSM networks - detailed charging and time or pulse charging.

In detailed charging, the stored data (date, time, call length, number of subscriber B) of a single call can be used to give detailed information about the call.

Detailed charging used for charging subscribers. Time or Pulse Charging is used for accounting and the Advice of Charge supplementary service.

The definitions for Detailed Charging are created in the DX200 MSS/HLR, which collects the charging data and sends it to the BC. The BC calculates the call charge and sends a bill to the subscriber.

The focus of this document is collection and storage of charging data and its transfer to the BC. It does not cover billing, which is not a DX200 feature, but performed in the BC, an external entity to the core network.

In collecting data, the MSS/HLR creates a charging record (CDR), which contains all events in the GSM network that can be used as a basis for charging a subscriber, such as defined call cases or location updates. A CDR, or Toll Ticket (TT), is stored in charging files in the MSS/HLR and then transferred to the Billing Centre.

1.2 Charging record (CDR)

A charging detailed record (CDR) as shown in Figure 4 is a record of a call comprising all charging events required for call billing, excluding price information.

The MSS/HLR collects the charging information, creates the CDR when the connection has been released, and sends it to the BC for pricing and billing the subscriber.

Following is a list of CDR types:

• Mobile Originated Call (MOC). Figure 4 shows a MOC CDR.

Basics of Charging

CN3401DEN30GLN1


13 (52)

• Mobile Terminated Call (MTC)

• Call to a Roaming Subscriber (ROAM)

• Forwarded Call (FORW)

• Supplementary Service (SUPS) (use and activation)

• Location Update (LOCA)

• HLR Interrogation for call establishment (HLRI)

• Mobile-Originated Short Message (SM-MO)

• Mobile-Terminated Short Message (SM-MT)

• PSTN Originated Call (POC)

• PSTN Terminated Call (PTC)

• PBX Originated Call (PBXO)

• PBX Terminated Call (PBXT)

• Intelligent Network Data

Each type of CDR has a fixed format, which is customer-specific. The formats are stored in file forms in the hard disk of the OMU. They can be displayed and activated with MML command.

GAP::ST=A,UF=NORMAL,FT=1,:; DX 200 MSS01 2008-03-15 15:38:28 DISPLAY OPERATION FOR SERVICE 0 IN TABLE FORMAT FILENAME: Y00AN1MX.IMG SERVICE: 00 STATE: ACTIVE USED FOR: NORMAL BLOCK VERSION: MJ010200 VERSION NUMBER: 002 FORMAT TYPE: 1 MESSAGE NUMBER: dd98 FORMAT TYPE NAME: MOC RECORD LENGTH: 210 HEADER: FIELD NAME DATA TYPE POSITION record_length W( 1) 0 record_type BCD( 1) 2 record_number BCD( 4) 3 record_status C( 1) 7 check_sum W( 1) 8 call_reference C( 5) 10 exchange_id C( 10) 15 DATA: FIELD NAME DATA TYPE POSITION

Basics of Charging

CN3401DEN30GLN1


14 (52)

intermediate_record_number BCD( 1) 25 intermediate_charging_ind C( 1) 26 number_of_ss_records BCD( 1) 27 calling_imsi C( 8) 28 calling_imei C( 8) 36 calling_number C( 10) 44 calling_category C( 1) 54 calling_ms_classmark C( 1) 55 called_imsi C( 8) 56 called_imei C( 8) 64 dialled_digits_ton C( 1) 72 called_number C( 12) 73 called_category C( 1) 85 called_ms_classmark C( 1) 86 dialled_digits C( 12) 87 calling_subs_first_lac W( 1) 99 calling_subs_first_ci W( 1) 101 calling_subs_last_ex_id C( 10) 103 calling_subs_last_lac W( 1) 113 calling_subs_last_ci W( 1) 115 called_subs_first_lac W( 1) 117 called_subs_first_ci W( 1) 119 called_subs_last_ex_id C( 10) 121 called_subs_last_lac W( 1) 131 called_subs_last_ci W( 1) 133 out_circuit_group BCD( 2) 135 out_circuit BCD( 2) 137 basic_service_type C( 1) 139 basic_service_code C( 1) 140 facility_usage C( 2) 141 non_transparency_indicator C( 1) 143 channel_rate_indicator C( 1) 144 set_up_start_time C( 7) 145 in_channel_allocated_time C( 7) 152 charging_start_time C( 7) 159 charging_end_time C( 7) 166 orig_mcz_duration BCD( 3) 173 cause_for_termination DW( 1) 176 data_volume W( 1) 180 call_type C( 1) 182 orig_mcz_tariff_class BCD( 3) 183 orig_mcz_pulses BCD( 2) 186 dtmf_indicator C( 1) 188 aoc_indicator C( 1) 189 orig_mcz_chrg_type C( 1) 190 called_number_ton C( 1) 191 redirected_indicator C( 1) 192 hot_billing_record_number BCD( 4) 193 called_msrn_ton C( 1) 197 called_msrn C( 12) 198

Figure 4 MOC CDR

Basics of Charging

CN3401DEN30GLN1


15 (52)

1.2.1 Exercise

In Figure 5 through Figure 16, draw the call path and define possible CDR types and the corresponding network elements.

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen. Figure 5. Mobile subscriber-A calls PSTN subscriber-B

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen. Figure 6. PSTN subscriber-A calls mobile subscriber-B

Basics of Charging

CN3401DEN30GLN1


16 (52)

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen. Figure 7. Mobile subscriber-A calls subscriber-B, both in HPLMN

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen. Figure 8. Mobile subscriber-B roaming in another PLMN

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen.Figure 9. Swedish mobile subscriber-A roaming in Finnish PLMN calls PSTN subscriber-B in Finland

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen.

Figure 10. Finnish subscriber-A in PSTN calls Swedish mobile subscriber-B roaming in Finland

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen.Figure 11. Mobile subscriber-A calls mobile subscriber-B, both in PLMN-A. Mobile subscriber-B, with Call Forwarding Unconditional on, forwards the call to mobile subscriber-C of PLMN-A, who is roaming in PLMN-B

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen.Figure 12. Mobile subscriber-A calls mobile subscriber-B, both in PLMN-A. Mobile subscriber-B, with Call Forwarding if No Answer on, forwards the call

Basics of Charging

CN3401DEN30GLN1


17 (52)

conditionally to mobile subscriber-C of PLMN-A, who is roaming PLMN-B

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen. Figure 13. Mobile subscriber-A does a location update in PLMN-B

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen. Figure 14. Mobile subscriber-A activates call barring

supplementary service

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen.Figure 15. Mobile subscriber-A sends a Short Message to the Short Message Service Centre in PLMN-A

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen.Figure 16. Mobile subscriber-A of PLMN-A, roaming in PLMN-B, receives a Short Message from the Short Message Service Centre in PLMN-A

1.2 Dynamic data formatting

Dynamic data formatting allows you to manage the contents of call related records and reports generated by the exchange. It does not change the functionality of charging data handling, but offers more flexible and generic data formatting for any application by giving you the tools to handle different formatting services and different kinds of formats simultaneously.

You can define different formats to determine which data fields are included in CDRs generated by the exchange for different call types and

Basics of Charging

CN3401DEN30GLN1


18 (52)

services. These formats are stored in form files on the OMU hard disk. Each format is used to generate CDRs for a specific call type. All changes to outgoing CDRs/reports are done with MML commands. The process for changing the contents of outgoing CDRs begins with an application process, which sends a service request message to the formatter. If the requested service is allowed, the formatting process acknowledges with the success status. After the service request has been accepted, the formatting process is ready to format received data according to the format that is defined in the customer form, which is stored in the form files on the OMU hard disk.

Nokia initially creates the form files and includes them in the software build delivery. Any changes to CDR forms are also carried out by Nokia and saved to the OMU disks. In both cases, the new form files are saved in the passive state to the LFILES directory on the OMU hard disk of the DX200 exchange, with specific version numbers, ready for you to activate with the GAE command. You can also use the same command to reverse activation.

If the new form file is correct and all the required operations can be carried out by the system, the new formats are taken into use immediately and the next outgoing CDR/report will be according to the new form.

You can check the version number of a file with the GAL command. Use GAR command to check that the version numbers of the form files in use are the same as the version numbers on the disk.

When you have activated the new forms, it is advisable to use the record counter to check that CDRs are being successfully generated as intended. In this way, you can detect any problems immediately and avoid possible loss of charging data.

1.2 Dynamic data formatting record counter

The optional dynamic data formatting record counter counts and displays the total number of normal and hot records generated for each format type. It also displays the time that the first and last records are generated.

You can use the record counter to check that CDRs have been successfully generated after activation of a new file form. This enables you to detect problems immediately and prevent possible charging data loss.

Basics of Charging

CN3401DEN30GLN1


19 (52)

You can start and stop the record counter with the GEC command.

1.2 Collecting and storing charging data

Take a look at Figure 4 and note that the MOC CDR has IMSI, MSISDN, service-related data, and time-stamp parameters. These parameters are typically provided by signalling units and are used by the MSS/HLR to collect and store charging data, and collect statistical data.

The STU and the STU and CHU are dedicated units for collecting and storing charging data. During the call, they store the charging data into a CDR in a work file (SCALLF). After the call has been released, the MSS/HLR generates the CDR, and the STU/CHU store the CDR into an All-ticketing Buffer file (TTCHAB). The CDR is then stored to the STU and CHU disks using charging blocks.

Figure 17 displays charging block content.

GEP:::BLK=CUR:; DX 200 MSS01 2008-03-15 15:41:12 DISPLAY OPERATION FOR SERVICE 0 CURRENT BLOCK BLOCK IS ONLY IN RAM MEMORY BLOCK INDEX: 1 A1 00 00 01 01 00 A1 00 68 31 09 10 00 FF FF FF FF FF 45 00 00 00 FF 00 00 00 01 00 56 46 16 14 12 00 20 4D 4A 01 02 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 94 00 02 45 00 00 00 00 DE 2D 04 40 41 40 9F 68 31 09 10 00 FF FF FF FF FF 00 00 00 68 31 09 01 10 F2 FF FF FF FF 64 00 00 00 00 00 00 F3 FF FF FF FF FF FF FF FF 68 31 09 01 00 F3 FF FF FF FF FF FF 00 03 02 10 01 00 C8 00 C9 00 68 31 09 10 00 FF FF FF FF FF C8 00 C9 00 00 11 00 00 FF 18 07 17 09 15 12 00 20 07 17 09 15 12 00 20 13 17 09 15 12 00 20 17 31 09 15 12 00 20 44 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 05 FF FF FF FF 94 00 02 46 00 00 00 00 76 2F 04 40 41 40 A2 68 31 09 10 00 FF FF FF FF FF 00 00 00 68 31 09 01 10 F2 FF FF FF FF 64 00 00 00 00 00 00 F3 FF FF FF FF FF

Figure 17. Charging block content

The size of charging blocks can vary to a maximum depending on the storing device. The maximum size for charging blocks in the MTU and

Basics of Charging

CN3401DEN30GLN1


20 (52)

CTU is 8 Kb, and 64 Kb for the Virtual Data Store (VDS). You can adjust the size of charging blocks by increments of 2 Kb.

Whenever a charging block reaches capacity, or the timer expires, the charging block is written onto the charging file in the STU/CHU disk, magnetic tape of the OMU, or the DAT of the STU/CHU, as defined in the logical file. Charging file sizes vary from 10 Kb to 4 Mb. 1 Mb is the recommended size. Disk unit capacity can be 200 Mb, 500 Mb, or 1-4 Gb. Magnetic tape capacity is approximately 30 Mb per reel.

The STU/CHU parallel disk units are used for backing up the charging files. In this back-up process, the active charging unit writes charging data to a spare disk unit. The CDRs created by both units are then compared to check the status of the CDR (OK/faulty).

Below picture depicts how the CDRs are written into charging block:

Fehler! Es ist nicht möglich, durch die Bearbeitung von Feldfunktionen Objekte zu erstellen. Figure 18. Writing flow to charging block

As discussed in chapter 01.2, you can use hard disk space more efficiently with CDR type formats.

Figure illustrates the functionality of charging.

1. Start Call

2. End Call charging

record

STU/CHU OMU

BDCU SU

chargingblock

4. Write block into Charging Files

6. Backup to DAT Tape

5. Transfer to Billing Center Via BDCU

7. Take DAT to BC

chargingblock

TTCHAB

call record

DAT

DAT

3.

3. Generate Record and put into TTCHAB

Figure 19. Functionality of charging

Basics of Charging

CN3401DEN30GLN1


21 (52)

6 Charging data transfer to the BC Once a connection has been released and the charging data is stored to a CDR, the CDR is sent to the BC for processing. The BC interprets the charging parameters on the CDR and processes subscriber bills. Figure displays a MOC CDR that has been processed by the BC.

Record length : 194 (dec) c2 (hex) MOC_RECORD_TYPE, ( 2) 01 MOC_RECORD_NUMBER, ( 3) 00000067 MOC_RECORD_STATUS, ( 7) 00 MOC_CHECK_SUM, ( 8) 5f63 MOC_CALL_REFERENCE, ( 10) 4131004600 MOC_EXCHANGE_ID, ( 15) 4917705fffffffffffff MOC_INTERMEDIATE_RECORD_NUMBER, ( 25) 00 MOC_INTERMEDIATE_CHARGING_IND, ( 26) 00 MOC_NUMBER_OF_SS_RECORDS, ( 27) 01 MOC_A_SUBSCRIBER_IMSI, ( 28) 262091000000003f MOC_A_SUBSCRIBER_IMEI, ( 36) ffffffffffffffff MOC_A_SUBSCRIBER_NUMBER, ( 44) 491779000003ffffffff MOC_A_CATEGORY, ( 54) 00 MOC_MS_CLASS_MARK_A, ( 55) 00 MOC_B_SUBSCRIBER_IMSI, ( 56) ffffffffffffffff MOC_B_SUBSCRIBER_IMEI, ( 64) ffffffffffffffff MOC_DD_TYPE_OF_NUMBER, ( 72) 04 MOC_B_SUBSCRIBER_NUMBER, ( 73) 5551779000005fffffffffff MOC_B_CATEGORY, ( 85) 35 MOC_MS_CLASS_MARK_B, ( 86) ff MOC_DIALLED_DIGITS, ( 87) 05551779000005ffffffffff MOC_A_SUBS_FIRST_LOC_LAI, ( 99) 03e8 MOC_A_SUBS_FIRST_LOC_CELL_ID, (101) 006f MOC_A_SUBS_LAST_LOC_EX_ID, (103) 4917705fffffffffffff MOC_A_SUBS_LAST_LOC_LAI, (113) 03e8 MOC_A_SUBS_LAST_LOC_CELL_ID, (115) 006f MOC_B_SUBS_FIRST_LOC_LAI, (117) ffff MOC_B_SUBS_FIRST_LOC_CELL_ID, (119) ffff MOC_B_SUBS_LAST_LOC_EX_ID, (121) ffffffffffffffffffff MOC_B_SUBS_LAST_LOC_LAI, (131) ffff MOC_B_SUBS_LAST_LOC_CELL_ID, (133) ffff MOC_OUT_CIRCUIT_GROUP_NR, (135) 2000 MOC_OUT_CIRCUIT_NR, (137) 0003 MOC_CHAR_SERV_TYPE, (139) 00 MOC_CHAR_SERV_CODE, (140) 11 MOC_SEC_SERV_TYPE, (141) ff MOC_SEC_SERV_CODE, (142) ff MOC_NON_TRANSPARENCY_IND, (143) 00 MOC_HALF_RATE_INDICATOR, (144) 00 MOC_SET_UP_START_TIME, (145) 09:30.21,06-11-1995 MOC_CHANNEL_ALLOCATED_TIME, (152) 09:30.22,06-11-1995 MOC_CHARGING_START_TIME, (159) 09:30.32,06-11-1995 MOC_CHARGING_END_TIME, (166) 09:30.41,06-11-1995 MOC_ORIG_CHARG_DURATION, (173) 000009 MOC_SUCCESS_INDICATOR, (176) 00000000 MOC_DATA_VOLUME, (180) 0000 MOC_CALL_TYPE, (182) 03 MOC_ORIG_TARIFF_CLASS, (183) 000000

Basics of Charging

CN3401DEN30GLN1


22 (52)

MOC_OUT_CHARGING_PULSES, (186) ffff MOC_DTMF_SENDER_IND, (188) 00 MOC_AOC_IND, (189) 01 MOC_PNI, (190) ffffff MOC_REDIRECTED, (193) 00

Figure 20. Post processed MOC CDR

1.2 Virtual Data Store

The VDS provides intermediate data storage and reliable data transfer.

It consists of a defined number of data files and control files that contain file related information such as file numbers, file states, and time stamps.

As with all other I/O-devices in the DX 200, interfacing is based on logical files, as illustrated in Figure 181.

VDS-0

VDS-1

CHU

W0

\

CF0001.DATCF0002.DAT

…CF9999.DAT BF0001.DAT

BF0002.DAT…

BF0999.DAT

GSMBIL ACCDIR

Normal CDRs

Hot billing CDRsVDS-2

VDS-3

VDS-4

VDS-5

VDS-6

Counters files(Accouting purpose)

Disk structure of STU/CHU disk

TTLOFI

HBLOFI

TRACIG

TRACSU

TRACIR

TRAZON

TRATOT

Logical file VDS

Control filesfor VDS-0

Control filesfor VDS-1

AG0001--25

Control files for VDS-2

AS0001--25


AC0001--25


AZ0001--25


AT0001--25


CHU

W1

Figure 181. Relationship between logical files and the VDS and CHU disks

VDS-1 of the CHU stores hot billing CDRs. Normal CDRs are stored in the VDS-0.

Counter files are stored in VDS-2, VDS-3, VDS-4, VDS-5, or VDS-6, depending on the type of counter used. Counter files are used in time charging.

Basics of Charging

CN3401DEN30GLN1


23 (52)

1.2.1 Data file states

Since the VDS uses only one data file at a time for storing data, the system has to keep track of the files currently used for storing data by using dedicated states.

The state of a data file is any one of the following, as illustrated in Figure 192:

• Open - File in use and data being written into file. Only one file can be open at a time.

• Full - File is closed and waiting to be transferred.

• Transferred - File has been transferred to remote side and can be overwritten if required.

• Waiting - File waiting to be compressed.

• Compressing - File being compressed.

• Unusable - File unusable because hard disk is full.

ZIFO:CHU:GSMCHA:1&&15;

FILE ORIGINAL/

NUMBER STATUS COMPRESSED FILLING TIME TRANSFER TIME

1 TRANSFERRED OK/OK - - - 2007-01-18 21:36:03 2007-01-18 22:40:00

2 TRANSFERRED OK/OK B - - 2007-01-18 21:36:07 2007-01-18 22:50:00

3 FULL OK/OK B - - 2007-01-18 21:36:11 2007-01-17 06:47:00

4 FULL W0/W0 B - - 2007-01-18 21:36:14 2007-01-17 06:52:00

5 FULL W0/W1 B - - 2007-01-18 21:36:18 2007-01-17 07:03:00

6 FULL W1/W1 B - - 2007-01-18 21:36:22 2007-01-17 07:06:00

7 FULL OK/OK - - - 2007-01-17 17:50:11 0000-00-00 00:00:00

8 FULL OK/OK - - - 2007-01-17 18:01:22 0000-00-00 00:00:00

9 COMPRESSING OK/-- - - - 2007-01-18 21:36:46 0000-00-00 00:00:00

10 WAITING OK/-- - - - 2007-01-18 21:36:49 0000-00-00 00:00:00

11 WAITING OK/-- - - - 2007-01-18 21:36:53 0000-00-00 00:00:00

12 OPEN --/-- - - - 2007-01-18 21:36:54 0000-00-00 00:00:00

13 TRANSFERRED --/-- - - - 0000-00-00 00:00:00 0000-00-00 00:00:00

Figure 192. Charging file states

Basics of Charging

CN3401DEN30GLN1


24 (52)

1.2.2 Control files

The system needs two control files for every VDS to transfer data files from the DX 200 to the BC.

Figure 203 displays the file structure of the TTTCOF and TTSCOF control files.


Figure 203. File structure of TTTCOF and TTSCOF

The Toll Ticket Transfer Control File (TTTCF) shows the last time a file was transferred to the BC.

The Toll Ticket State Control File (TTSCOF) shows the file state and the last time data was written to the file.

(The VDSx uses TTSCOF0x and TTTCOF0x control files.)

TTTCOF content is controlled by the remote side (the BC) and is read-only for the DX 200 side. TTSCOF content is updated by the DX200 and is read-only for the remote side.

The two files are updated regularly copying them from the MSS to the BC, and vice versa. The files can also be updated using the File Transfer, Access, and Management (FTAM) and Common Management Information Service Element (CMISE) – where the FTAM transfers the data files, and the CMISE handles related events, such as file full and successful transfer.

1.2 File use in normal billing

In normal billing, a new file is used when a file becomes full or at file time expiry.

Files are used in rotation. For example, for 100 charging files (CF0001-CF0100), CF0001 will be used after CF0100.

When a file is full, it is transferred to the BC with FTAM via an X.25 or LAN interface. The transfer is controlled from the BC. If there is no interface, files can also be transferred by magnetic tape.

Data that is not transferred to the BC, nor stored on a memory device will be lost.

Basics of Charging

CN3401DEN30GLN1


25 (52)

Charging disks can normally contain 72 hours worth of charging data. You can set up to two thresholds remaining empty files. An alarm signals that the first threshold of empty files has been reached. A second alarm signals that the last file has been taken into use.

1.2.1 FTAM solution

When FTAM is implemented, the MSS/HLR determines which files are available for reuse by comparing the TTSCOF (contains state and time stamp; updated by MSS/HLR) with the TTTCOF (contains time stamp; updated by the BC). The BC compares the two files to select which files to transfer.

6..1.1 Exercise Fill in the missing information on the control file records below according to the charging file transfer procedure. Use arrows to show file transfer directions.

1. Original situation at 12:55, as shown in Figure 214: There is one full charging data file (CF0001) in the MSS’s STU disk, which was filled up at 12:15. The STU is now storing charging data to a second file (CF0002, which was last written at 12:50). The last transfer of these charging data files was at 12:00.

CF001.DATCF002.DATCF003.DAT

CF001

charging files

transfer controlfile (TTTCOF) CF002

CF003

CF001.DATCF002.DATCF003.DAT

CF001CF002CF003

CF001state controlfile (TTSCOF) CF002

CF003

CF001CF002CF003

charging files

state controlfile (TTSCOF)

MSC BC

state time state time

time time

BC can’tupdate this filelocally, it isonly copiedfrom the MSC

Figure 214. Files used in the transfer of charging data (step 1)

Basics of Charging

CN3401DEN30GLN1


26 (52)

2. At 13:00 as shown in Figure 225, the BC copies the state control file from the MSS.



3. At 13:00, as shown in Figure 236, the BC copies the charging files, which are in “Full” state, and updates the transfer control file.



Still at 13:00, as shown in

4. Figure 247, the BC copies the transfer control file to the MSS.



5. At 13:15, as shown in Figure 258, the MSS updates the state control file according to the transfer control file information. During steps 2, 3, and 4, the second charging file has become full (at 13:15), and the MSS has started writing into the third file.



Basics of Charging

CN3401DEN30GLN1


27 (52)

6..1.2 FTAM/CMISE solution When FTAM/CMISE is implemented, a CMISE event reports full files from the MSS to the BC. The FTAM copies the files. A CMISE event indicates successful file transfer from the MSS to the BC. Figure 269 illustrates this process.

MSC BC

Q3, C

FTA

Q3, C

M-Event Report: TransferUpReady

FTAM Read

M-Action: TransferUp received

Figure 269. File transfer to the BC with FTAM/CMISE

1.2 MML interface

Generally when charging is involved, following MML commands are used:


Figure 30 Related MML Commands to charging

Basics of Charging

CN3401DEN30GLN1


28 (52)

With MML commands also, you can define the closing time to induce forced closing of an open file. This enables you to transfer files to the BC even if traffic is slow.

Figure displays basic charging file settings, and Figure 2 shows statistical charging file settings in the DX200 MSS.

IFI:STU,GSMCHA:B; DX 200 MSS-CSC 2008-03-15 16:34:46 FILE NAMES: ORIGINAL FILES: CF0000.DAT COMPRESSED FILES: CF0000.Z STORAGE CONTROL FILE: TTSCOF00.IMG TRANSFER CONTROL FILE: TTTCOF00.IMG FORMAT OF RING BUFFER: SKIPPING OF UNTRANSFERRED DATA IS NOT ALLOWED OVERWRITE OF UNTRANSFERRED DATA IS NOT ALLOWED FILE IS NOT COMPRESSED DISK FILE SIZE: 64 KB DISK FILE AMOUNT: 150 BATCH SEQUENCE NUMBER: FILLED TO OFFSET: 22 TIME CONTROL FOR FILE CLOSING: DAILY DISK FILE CLOSING TIME: 00-00 DISK FILE CLOSING INTERVAL: 00-00

Figure 31. Basic charging file settings in the DX 200 MSS

Basics of Charging

CN3401DEN30GLN1


29 (52)

Figure 32. Statistical charging file setting in the DX 200 MSS

You can also use the MML interface to define the number and size of charging files, get data file states (ZIFO command), enable/disable TTTCOF loading (ZIFH command), activate and handle CMISE (with TTTCOF loading disabled), and define related Q3-parameters (ZIFQ command).

1.2 Interfaces between the MSS and the BC

You can transfer charging disk files and charging control files from the CHU hard disks to the BC with FTAM protocol over an X.25 or an OSI/LAN connection, or with FTP over TCP/IP.

1.2.1 FTAM and FTP file transfer protocol

Charging control files are copied from the MSS to the BC and from the BC to the MSS during the charging disk file transfer procedure. This charging information transfer concept is a TTSCOF and TTTCOF based method for controlling transfer of charging disk files to the BC.

IFI:STU,GSMCHA:S;

DX 200 MSS-CSC 2008-03-15 16:35:05

ALARM SETTINGS:

ALARM MODE: ALL CHARGING FILLING RATIO ALARMS IN USE

FIRST ALARM LIMIT: 70 %

FIRST ALARM CANCEL: 65 %

SECOND ALARM LIMIT: 90 %

SECOND ALARM CANCEL: 85 %

STATISTICS:

CURRENT FILL UP RATIO: 0 %

AMOUNT OF FULL FILES: 0

CURRENT BATCH SEQUENCE NUMBER: 14043

CURRENT DISK FILE NUMBER: 115

CURRENT FILE OFFSET: 01 %

Basics of Charging

CN3401DEN30GLN1


30 (52)

TTTCOF, which is a read-only file for the MSS, is updated by the BC, whereas the TTSCOF is updated by the MSS, and not by the BC.

File transfer to the BC is realized with FTAM or File Transfer Protocol (FTP). The general functionality for file transfer with FTAM and FTP is the same as for the MSS and the BC, the only difference being the file transfer protocol.

The BC initiates file transfer and the CHU responds. The transferring sequence from the CHU to the BC is described in steps 1-6 below.

The procedure for transferring is as follows: 1. The BC activates a FTAM or FTP file transfer to read the TTSCOF

from the CHU hard disk. (Forced transfer mode should be binary.) 2. The BC examines the TTSCOF for states and storing status

information of the charging disk. The BC uses the storing status flag to find out the location of charging disk files with a FULL state, and whether they are compressed.

3. The BC activates either the FTAM or FTP file transfer and reads all

charging disk files with a FULL state from the CHU. The BC analyses the storing status flag. If the file is successfully stored to one hard disk only, the BC must add a hard disk ID (W0-/ or W1-/) at the beginning of the path.

4. The BC updates the timestamps for the transferred disk files in the

TTTCOF file. The timestamp must not be the same as for the TTSCOF file. It should one second more than the TTSCOF file. This ensures that the file states will be changed from FULL to TRANSFERRED after the transfer.

5. The BC activates either the FTAM or FTP connection to write the

TTTCOF file to the hard disk of the CHU. (The forced transfer mode should be binary.)

Note If TTTCOF is corrupted during writing, all charging files could have a FULL state, which could result in charging data not being stored and transferred.

The MSS compares the TTSCOF and TTTCOF and updates the TRANSFERRED state information of all the files in the TTTCOF with a more recent timestamp. The TTSCOF is not immediately updated when

Basics of Charging

CN3401DEN30GLN1


31 (52)

the TTTCOF is received from the BC. The updating occurs when the file state is changed from a TRANSFERRED to an OPEN state. The alarms for the VDS ring file system fill-up are set and reset when the TTSCOF is updated.

Note Charging files marked OPEN and files that become OPEN during transfer should not be transferred to the BC, because this may prevent storing the charging data to hard disks.

Basics of Charging

CN3401DEN30GLN1


32 (52)

7 Charging data recovery If have a software package failure and are using backup software instead, the system can still access the most recent normal charging data in control files TTTCOF and TTSCOF in the STU/CHU hard disks.

If the X.25 or LAN connection to the BC fails, you should copy the charging files onto DAT or magnetic tape or MO in order to be able to send them to the BC later. You can copy all VDS data files to the BC with command ZIFC. For further details on copying VDS data files to the BC, see DX 200 Safecopying (more steps will be covered in exercise).

Basics of Charging

CN3401DEN30GLN1


33 (52)

8 Charging Hardware Charging operations in the DX 200 MSS are distributed over several computer units.

Detailed charging functions require the STU. Large exchanges also require the CHU for detailed charging.

Charging file transfer originates from the STU/CHU Winchester disks, with FTAM file transfer protocol.

The BDCU provides the X.25 connection, used to transfer charging files to the BC.

If FTAM is not used, magnetic tapes are used to store charging files for physical transport to the BC.

Time charging programs and files reside in the central memory (CM).

The VLRU and HLRU provide information about location register related chargeable events, such as location updates and supplementary services activation. Figure 3 illustrates the charging hardware architecture.

Basics of Charging

CN3401DEN30GLN1


34 (52)

CHUSTU

GSW

M BDCU

X.25

OMUCM

SU

VLRU

SS DigitAnalysis

ChargingFiles

FTAM to BCSignalling Units:CCSU, BSU, etc.

CMHLRUSTU

MBDCU

X.25

OMU

CCSU GSW

SS

Figure 33 Charging hardware in the DX200 MSS/HLR

Basics of Charging

CN3401DEN30GLN1


35 (52)

9 Check your understanding 1. Describe the process for changing an outgoing CDR with dynamic

data formatting.

_________________________________________________________

_________________________________________________________

_________________________________________________________

_________________________________________________________

_________________________________________________________

2. Describe the factors that can affect the price of an MOC from the data provided in the following CDR for an MOC shown in Figure 34.

_________________________________________________________

_________________________________________________________

_________________________________________________________

_________________________________________________________

_________________________________________________________

_________________________________________________________

_________________________________________________________

Basics of Charging

CN3401DEN30GLN1


36 (52)

GAP::ST=A,UF=NORMAL,FT=1,:; DX 200 MSS01 2008-03-15 15:38:28 DISPLAY OPERATION FOR SERVICE 0 IN TABLE FORMAT FILENAME: Y00AN1MX.IMG SERVICE: 00 STATE: ACTIVE USED FOR: NORMAL BLOCK VERSION: MJ010200 VERSION NUMBER: 002 FORMAT TYPE: 1 MESSAGE NUMBER: dd98 FORMAT TYPE NAME: MOC RECORD LENGTH: 210 HEADER: FIELD NAME DATA TYPE POSITION record_length W( 1) 0 record_type BCD( 1) 2 record_number BCD( 4) 3 record_status C( 1) 7 check_sum W( 1) 8 call_reference C( 5) 10 exchange_id C( 10) 15 DATA: FIELD NAME DATA TYPE POSITION intermediate_record_number BCD( 1) 25 intermediate_charging_ind C( 1) 26 number_of_ss_records BCD( 1) 27 calling_imsi C( 8) 28 calling_imei C( 8) 36 calling_number C( 10) 44 calling_category C( 1) 54 calling_ms_classmark C( 1) 55 called_imsi C( 8) 56 called_imei C( 8) 64 dialled_digits_ton C( 1) 72 called_number C( 12) 73 called_category C( 1) 85 called_ms_classmark C( 1) 86 dialled_digits C( 12) 87 calling_subs_first_lac W( 1) 99 calling_subs_first_ci W( 1) 101 calling_subs_last_ex_id C( 10) 103 calling_subs_last_lac W( 1) 113 calling_subs_last_ci W( 1) 115 called_subs_first_lac W( 1) 117 called_subs_first_ci W( 1) 119 called_subs_last_ex_id C( 10) 121 called_subs_last_lac W( 1) 131 called_subs_last_ci W( 1) 133 out_circuit_group BCD( 2) 135 out_circuit BCD( 2) 137

Basics of Charging

CN3401DEN30GLN1


37 (52)

basic_service_type C( 1) 139 basic_service_code C( 1) 140 facility_usage C( 2) 141 non_transparency_indicator C( 1) 143 channel_rate_indicator C( 1) 144 set_up_start_time C( 7) 145 in_channel_allocated_time C( 7) 152 charging_start_time C( 7) 159 charging_end_time C( 7) 166 orig_mcz_duration BCD( 3) 173 cause_for_termination DW( 1) 176 data_volume W( 1) 180 call_type C( 1) 182 orig_mcz_tariff_class BCD( 3) 183 orig_mcz_pulses BCD( 2) 186 dtmf_indicator C( 1) 188 aoc_indicator C( 1) 189 orig_mcz_chrg_type C( 1) 190 called_number_ton C( 1) 191 redirected_indicator C( 1) 192 hot_billing_record_number BCD( 4) 193 called_msrn_ton C( 1) 197 called_msrn C( 12) 198

Figure 34 Charging hardware architecture in the DX200 MSS

3. Explain the data recovery procedure, in the core network, for a fault situation.

_________________________________________________________

_________________________________________________________

_________________________________________________________

_________________________________________________________

Basics of Charging

CN3401DEN30GLN1


38 (52)

Appendix

1 Hot billing For mobile subscribers with the Hot billing supplementary service, detailed CDRs are sent to the BC immediately after the connection has been released, as illustrated in Figure 275.

Records are handled as hot billing records only when they relate to services used by the hot billing subscriber. Otherwise, hot billing records can be handled in the same manner as normal records.

For example, in a call forwarding case where subscriber-B is a hot billing subscriber, only the call forwarding and supplementary service use CDRs would be handled as hot billing records.

MSC

VLR

HLR

AC EIRHLR

12

3

45

6

7 89

0Θ

#

abcdef

ghi jklmn

prstuv

wxy

oqz

ABC

C

$$$

End ofCall

X.25 PAD

Billing CenterRental Office Bill

Call DataRecord

Hot Billed Call

Rental Services &Following up newsubscribers

Figure 275. Hot billing process

Sending individual records to the BC produces extra load, which makes it necessary for you to define the maximum number of hot billing subscribers. The extra load which hot billing necessitates would not allow you to send all collected charging data as hot billing records.

Glossary

CN3401DEN30GLN1


39 (52)

1.1 Physical interface requirements

A separate X.25 connection is necessary for hot billing to ensure the basic capacity requirement.

Hot billing also necessitates operator-specific extensions to the MAP, available only in MAP phase 2. The MAP should be able to carry a PLMN-specific supplementary service code.

The BC requires special software to enable it to receive hot billing via the X.25 connection.

1.2.1 User interface

Figure 286 displays the ZGB commands used to handle hot billing.

HOT BILLING HANDLING COMMANDS ? ..... DISPLAY MENU S: ..... SET SENDING ON/OFF A: ..... SET ALARM LIMITS F: ..... SET RESENDING PARAMETERS Y: ..... SET SYNCHRONIZING STRING I; ..... INTERROGATE PARAMETERS T: ..... SET TRANSFER PATH E: ..... CONFIGURE IP Z: ..... RETURN TO MAIN LEVEL

Figure 286. ZGB commands used for hot billing

1.2 Charging Based on Home Area (optional)

With this optional feature, the tariff for a MOC inside subscriber-A’s home area is lower than tariffs outside the subscriber’s home area.

A home area, defined in the HLR, consists of up to three defined charging areas, as illustrated in Figure 7.

Basics of Charging

CN3401DEN30GLN1


40 (52)

MSC

VLR

HLR

AC EIRHLR

$$$

ChargingArea 1

CA 2

CA 3

1 23

45 6

78 9

0Θ

#

abcdef

ghijkl

mn

prs tuvwxy

oqz

ABC

C

Home area

Figure 37. Charging Based on Home Area

1.2.1 Functionality

When creating subscribers in the HLR, each subscriber is assigned either a regional or national charging class. You can give up to three charging areas to a regional subscriber, which form the subscriber’s home area.

Both charging class and charging area data are stored in the HLR. Charging areas and the supplementary service code for Charging Based on Home Area is transferred from the HLR to the VLR upon location update.

During call setup, the MSS uses attribute analysis to identify if the MOC is made from a home area.

This feature requires MAP version 2 and the BC to be able to handle the changed call data record format.

1.3 Transferring hot billing records

Transferring hot billing records uses any of the following protocol interfaces:

Glossary

CN3401DEN30GLN1


41 (52)

• A Packet Assembler/Dissembler (PAD) printer over X.25

• Connection-oriented transport service (COTS) over LAN or X.25

• GPRS Tunnelling Protocol (GTP’) over TCP/IP or UDP/IP

1.3.1 PAD printer over X.25 With this method, there are no application level acknowledgements from the BC. Rather, hot billing records are numbered in sequential order, making it possible to detect missing records.

Due to the nature of this connection, there are no delimiters between hot billing CDRs, which means that the BC sees hot billing data as a byte stream.

The BC can also use a synchronizing string, which the MSS adds after each hot billing string, to locate the beginning of a CDR if synchronization is lost due to a file transfer error. The synchronizing string is a hexadecimal double word, with possible nibble (half-byte) values of OAH.OEH. The default string is ABBAABBA.

If hot billing CDRs are stored to disk files using a VDS device, the disk files can be transferred to the BC using the same method as for normal charging files, with a separate pair of control files (TTSCOF01.IMG and TTTCOF01.IMG).

1.3.2 COTS over LAN or X.25 When COTS is used, you can set the interface for hot billing data between the MSS and BC to support connection with immediate confirmation. If the interface is set to support connection with immediate confirmation, the BC must confirm all received data. The BC detaches the counter from the CDR (attached as the CDR departs from the exchange) before it begins processing the CDR. The BC sends the counter back to the exchange as confirmation. The confirmation includes a status byte, indicating if the received data was correct. The counter is an ascending number, which is independent of any possible number sequence in hot billing data. The field value is in double-word format. This method restricts transfer capacity due to the time that the BC requires for sending confirmation. Yet, without confirmation, the problem arises that charging data could be lost before detecting the problem.

Basics of Charging

CN3401DEN30GLN1


42 (52)

1.3.3 GTP’ over TCP/IP or UDP/IP (over LAN) This transfer method enables you to get a higher transfer rate because several records can be sent in the same packet and several packets can be sent before receiving acknowledgement from the post-processing system.

Storing between the MSS and the BC is realized with the Data Record Transfer Request and Data Record Transfer Response messages. The Data Record Transfer Request message contains information element Packet Transfer Command, which indicates what is the nature of the message, such as Send Data Record Packet. The Data Record Packet field in the Data Record Transfer Request contains the actual data records.

For more information on GTP’ protocol, see GSM 12.15 GPRS Charging. For more information about configuring TCP/IP for hot billing data transfer see Hot Billing Handling and Command Reference Manual.

1.3.4 Transfer capacity Sending hot billing charging records to the BC causes extra load. This must be taken into consideration when defining the maximum number of hot billing subscribers. The extra load makes it impossible for you to collect all charging data by hot billing.

The CHU reserves 2 MB RAM memory for buffering hot billing records. This is the equivalent of about 4000 CDRs. For more information on hot billing capacity, see Hot Billing - Parameters and Protocol, Interface Specifications, and OSI Guide.

Glossary

CN3401DEN30GLN1


43 (52)

Glossary The following sections provide definitions for key words, phrases, and acronyms used in this training document.

Definitions

Term Definition Charging block A group of CDRs to be collected to the memory of

the charging unit (CHU or STU). The charging block is a unit used in storing charging information onto disk.

Charging file The way of measuring the parameter determining the price of the call, e.g. Karlsson charging, in which the sending of the metering pulses is not synchronised with the beginning of the call.

Charging method The way of measuring the parameter determining the price of the call, e.g. Karlsson charging, in which the sending of the metering pulses is not synchronised with the beginning of the call.

Charging record (CDR) The amount of information linked with one charging case. Each type has been given its own CDR type. The records of different types can be of different lengths, but within each type the records are of a fixed length.

Detailed charging An implementation method of charging where a CDR is made of every successful call or other charging cases. The CDR includes information needed in setting the price for a call.

Record format The record format describes the structure of the CDR. Each CDR type has its own format.

Tariff The information needed for charging about the charge rate or the number of pulses in the pulse train or both.

Time charging A way of charging in which the length of the call determines its price. When time charging is used, metering pulses are generated during the call, and their interval, that is, the charge rate, is determined by the tariff.

Basics of Charging

CN3401DEN30GLN1


44 (52)

Abbreviations Abbreviation Term AoC Advice of Charge BC Billing Centre CDR Charging Detailed Record CF Conference calling CMISE Common Management Information Service

Element COTS Connection-oriented transport service FTAM File Transfer, Access and Management FTP File Transfer Protocol GTP’ GPRS Tunnelling Protocol OSI Open Systems Interconnection PAD Packet Assembler/Dissembler PDP Packet Data Protocol VDS Virtual Data Storage

Documents

13 CN3401DEN30GLN1 Basics of Charging