Mss

MSCDOCM14PDFCD MSC/HLR, Rel. M14.1, Product Documentation, v.
Accounting in MSC / MSS
DN00133192 Issue 8-0 en
# Nokia Siemens Networks
1 (93)
The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation 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 documentation 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 documentation 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 and finally 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 this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY 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 documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. The 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 2008. All rights reserved.
2 (93)
DN00133192 Issue 8-0 en
Contents
Contents
Contents 3 List of tables 5 List of figures 6 Summary of changes 7 1 1.1 1.2 2 3 4 4.1 4.2 4.2.1 4.2.2 4.2.3 5 5.1 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 7 7.1 7.2 8 8.1 8.1.1 8.1.1.1 8.1.1.2 About this document 9 Scope of application 9 Structure of this document Introduction to accounting Interface modifications 15 Use of charging analysis parameters 17 Control of charging messages 18 Control parameters of accounting counters 19 NCB 20 TCI 20 ICC, OCC 20 Analyses 21 Handling of analyses 24 Time charging 27 Internal pulse counters 29 Pulse generation 30 Sending charging messages 32 Receiving charging messages 32 Charging message transfer 33 Calls free of charge 33 Stopping of charging 34 Tariff change 34 Intermediate charging 35 Charging zone checking 36 Non-integer pulse sending 37 Accounting counters in MSC 39 Handling of accounting counters 47 Mobile accounting 47 Accounting counters in MSS 49 Binary formats 51 Data block header 52 Header structure 52 Description of header fields 52
10 13
DN00133192 Issue 8-0 en
3 (93)
8.1.2 8.1.2.1 8.1.2.2 8.1.2.3 8.2 9 10 10.1 10.2 11 11.1 11.2 12 13 13.1 13.2 Appendix A.1 A.2 A.3
Record formats 55 General overview 55 ATM/IP counters 55 SIP/BICC counters 57 Handling of counters 59 Inter-MSC handover 61 Accounting counter backup 63 Handling counter backup 64 Differences in counters of CHU-1 and CHU-2 Transferring accounting data via FTAM 67 Advanced accounting data transfer 67 Charging capacity 68 Using CDRs for accounting purposes 69 Accounting parameters used in Advice of Charge 71 AOC-I, AOC-C 72 AOC-E, AOC-D 73 A 75 Call case: PSTN-MS 75 Call Case: MS-PSTN 82 Accounting data transfer using FTAM Glossary 89 References 92
64
87
4 (93)
DN00133192 Issue 8-0 en
List of tables
List of tables Table 1. Table 2. Table 3. Table 4. Table 5. Table 6. Table 7. Table 8. Table 9. HC/CP combinations and their effects on charging message transfer 18 MML commands for analysis and charging MML commands for counter output ATM accounting counter IP accounting counter SIP accounting counter BICC accounting counter Structure of header 52 55 57 59 49 47 24
50 51 51
Structure of ATM/IP counters
Table 10. Structure of SIP/BICC counters
Table 11. MML commands for handling MSS-related accounting counters Table 12. MML commands for counter backup and comparison 64
Table 13. CDRs and the fields that can be used for accounting purposes
69
DN00133192 Issue 8-0 en
5 (93)
List of figures Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Different charging zones in three call cases The analysis sequence in MSC/MSS Tariff change structure 29 30 31 22 17
Pulse generation in MSC/MSS
Pulse generation in Karlsson charging Pulse handling in AOC 31 37
Non-integer pulse handling
Reminder pulses from incoming call control: 1. The incoming circuit (ICC) is released. 2. Time charging sends pulses or they are received from the outgoing circuit (OCC) before ICC removes charging. 3. Reminder pulses and charging pulses are used to update the accounting counters. 44 Reminder pulses from incoming signalling service: 1. The time charging sends pulses or the pulses are received from outgoing signalling (SSO). 2. ICC transfers these pulses to incoming signalling (SSI). 3. SSI cannot pass the pulses to incoming circuit due to subscriber A being on-hook. Pulses are added to proper accounting counters. 4. ICC removes charging. 5. The generated charging pulses are added to counters and stored in CDRs. 45 46 61
Figure 9.
Figure 10. Accounting counters
Figure 11. Inter-MSC handover accounting
6 (93)
DN00133192 Issue 8-0 en
Summary of changes
Summary of changes
Changes between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.
Changes made between issues 80 and 70
No changes have been implemented in the interface since the previous release.
The document has been updated to include enhancements due to Features 1196 and 1197: CAMEL Phase 4. Chapter Time charging, section Intermediate charging
.
New cause codes have been added to intermediate charging.
The title of the document has been changed from Accounting in MSC to Accounting in MSC / MSS. The document has been updated to include enhancements due to Feature 1417: Charging in MSS. Chapter Accounting counters in MSS has been updated.
DN00133192 Issue 8-0 en
7 (93)
8 (93)
DN00133192 Issue 8-0 en
About this document
1
1.1
About this document

This document provides information about accounting and the use of counters in the DX 200.
Scope of application
This document describes the functionality of accounting and the changes since the previous release. A general description of accounting and the purpose of time charging in the generation of pulses are introduced in this document. The charging analysis parameters needed for accounting and the analyses that are performed in the MSC/MSS are also described. The use of both pulses and CDRs for collecting accounting data are introduced. The use and backup copying of charging counters are explained, and the transfer of accounting data (pulses) via FTAM is also discussed in this document. The feature Advice of Charge and the use of charging pulses are described. The Appendices give examples of two call cases and the transfer of accounting data with FTAM. The necessary MML commands have been given with the corresponding outputs from the exchange. A general description of charging and the tasks related to detailed charging and the charging counters are presented in the operating instructions on charging handling. Call case examples with the corresponding CDR format, information in the data fields and timestamps can be found in Generation and Contents of CDRs in Different Call Cases, Interface Specification.
DN00133192 Issue 8-0 en
9 (93)
The charging data transfer principles and possible storing devices and logical file connections used in storing and transfer of charging data are introduced in Storing and Transfer of Charging Data, Interface Specification. Modifications concerning the storing devices, charging parameters and MMLs related to charging are also explained in the same document. A detailed description of the fields in CDRs can be found in CDR Field Description, Interface Specification. Information on the customer-specific charging format and CDR structure can be found in MSC/HLR-BC Customer-specific Part, Interface Specification.
1.2
Structure of this document

.
Chapter About this Document describes the scope and the structure of the document. Chapter References contains a list of the references used. Chapter Glossary explains the abbreviations used in the document. Chapter Introduction to Accounting briefly explains what accounting is used for. Chapter Interface Modifications explains the changes since the last release. Chapter Use of Charging Analysis Parameters explains what parameters are needed to control accounting. It also introduces the different charging messages and their purpose. Chapter Analyses describes the different analyses made at the exchange and lists the necessary MML commands for creating analyses. Chapter Time Charging explains how time charging works, what parameters are used and how pulses are generated. It also explains how charging messages are received, sent and transferred. Stopping of charging in certain cases, tariff changes during a call and generation of intermediate CDRs are also discussed. Chapter Accounting Counters in MSC introduces the counters used for accounting purposes and lists the necessary MML commands for handling accounting counters.
10 (93)
DN00133192 Issue 8-0 en
About this document
Chapter Accounting Counters in MSS introduces the counters used for accounting purposes in MSS, lists the necessary MML commands for handling accounting counters and binary format for MSS accounting counters. Chapter Inter-MSC Handover explains what counters are updated in an inter-MSC handover. Chapter Accounting Counter Backup explains how the counter files can be copied to disk or tape. It also lists the necessary MML commands. Chapter Transfer of Accounting Data via FTAM describes how counter files can be transferred via FTAM either through an OSI application or directly from the disk of the CHU. Chapter Using CDRs for Accounting Purposes explains that accounting data, pulses, can also be collected in CDRs instead of, or in addition to, charging counters. Chapter Accounting parameters used in Advice of Charge describes how charging pulses are used in the feature Advice of Charge. Appendix Call Case: PSTN-MS gives examples on how to make the necessary definitions for accounting parameters in a PSTN to mobile call. The definitions for a mobile to a PSTN call are given in Appendix Call Case: MS-PSTN. Appendix Accounting Data Transfer using FTAM shows the necessary steps for the definitions that need to be made for accounting data transfer with FTAM.
DN00133192 Issue 8-0 en
11 (93)
12 (93)
DN00133192 Issue 8-0 en
Introduction to accounting
Introduction to accounting
The charging in GSM is based on time charging. However, if the calling or the called party are not GSM mobile subscribers under the same MSC/ MSS, other methods for charging can also be used. Charging between operators is called accounting. Accounting is used when other exchanges are involved in a call. This way the external use of the MSC/MSS can easily be charged later on by checking certain pulse counters under a time period. The charging sent by operators from other exchanges can also be monitored using the accounting counters. Accounting includes the recording of generated and received pulses, call time and number of answered calls. Generally this means charging that is not related to subscribers, but it is also possible to gather similar data from mobileoriginated and mobile-terminated calls if the Mobile Accounting feature is activated. For more information see Feature 747: Mobile Accounting. In order for the operator to assign the costs caused by out-MSC/MSS calls to the right subscribers, the accounting information is also written in subscriber-specific Call Detail Records (CDRs). For more information, see Generation and Contents of CDRs in Different Call Cases, Interface Specification. In the following chapters, the term charging message is used to refer to the Charging Information and Metering Pulse Messages (CRG and MPM). The treatment of these messages in the MSC/MSS differs in cases, such as transactions with the Service Control Point (SCP), and the way the charge information is stored in CDRs. Some differences are described in this document but a detailed description can be found in the feature description of Feature 739: CS-1 Continuation and Feature 774: High Speed Circuit Switched Data.
DN00133192 Issue 8-0 en
13 (93)
14 (93)
DN00133192 Issue 8-0 en
Interface modifications
Interface modifications
No interface changes have been implemented since the previous release.
DN00133192 Issue 8-0 en
15 (93)
16 (93)
DN00133192 Issue 8-0 en
Use of charging analysis parameters

Accounting can be controlled with parameters in the digit analysis and charging analysis. The charging zones in the charging analysis are used to give a tariff class to a destination. For each charging case three charging zones can be defined: Main Charging Zone (MCZ), Outgoing Accounting Zone (OAZ) and Incoming Accounting Zone (IAZ). The use of these automatons and zones are described in figure Different charging zones in three call cases. The incoming accounting zone is not applicable in mobile-originated calls and the outgoing accounting zone is not applicable in mobile-terminated calls. The main charging zone is associated with subscriber charging: it is used for Advice of Charge (AOC) and sending charging messages to an incoming circuit.
MSC
OAZ MCZ
MSC
IAZ
PSTN
OAZ
MS -> PSTN PSTN -> MS PSTN -> MSC -> MSC -> MS
IAZ
MCZ
Figure 1.
Different charging zones in three call cases
DN00133192 Issue 8-0 en
17 (93)
Other parameters in charging analysis are Charging Point (CP), Handling of Charging (HC), Time Charging Interrupt (TCI), No Charging on B Answer (NCB), and Incoming and Outgoing Charging Control (ICC, OCC). The charging analysis parameters can be set with the normal digit analysis commands: RDE (create analysis component) and RDG (add charging case).
4.1
Control of charging messages

The sending and storing of charging messages is defined using the charging point and handling of charging parameters .
Charging point describes which exchange determines the charge for the call. Charging point may have the following values:
OE IC OC, OCI OEA Charging is implemented in the local (own) exchange Charging is implemented in the incoming circuit Charging is implemented in the outgoing circuit The local exchange determines the charging but the charging messages from the outgoing circuit are accepted. This parameter value is available only through Feature 698: Charging Based on Parameters from Network.
Handling of charging (sending of charging to the incoming circuit) describes what actions are made if the charging messages are received from the outgoing circuit. Handling of charging may have the following values:
ACI NCI All charging to incoming circuit No charging to incoming circuit
The effects of the different combinations of CP and HC on the treatment of received charging messages in a transit exchange are presented in table HC/CP combinations and their effects on charging message transfer.
Table 1. HC
ACI, NCI, CI
HC/CP combinations and their effects on charging message transfer Action

No transfer of charging messages. No storing.
CP
IC, OE
18 (93)
DN00133192 Issue 8-0 en
Table 1.
HC/CP combinations and their effects on charging message transfer (cont.) Action
Charging message transfer and storing No transfer of charging message. The pulses are stored in accounting counters.
HC
CI, ACI NCI
CP
OC, OCI OC, OCI
Note
Charging messages are never passed to the previous call leg (this means call forwarding or roaming cases) regardless of the value of the parameter HC.
If the call control processes and signalling in the SW package are appropriate, the charging message can be sent to an incoming circuit. Charging messages, by default, metering pulses (MPM) are sent to an incoming circuit if the charging point is in the local exchange (CP=OE/ OEA) and the handling of charging is set to HC=CI. If the charging point is set to OE, the received charging messages are discarded. In transit calls, the charging messages received from an outgoing circuit can be transmitted to an incoming circuit if the HC and CP parameters are set as described in table HC/CP combinations and their effects on charging message transfer. If the pulses are also to be stored in accounting counters, they are added to the RECEIVED PULSES field in the Total Meters File (TOTMET), Trunk Circuit Meter File (CIRMET), Trunk Circuit Sum Meter File (CSUMET) and Circuit Group Meter File (CIGMET), see Chapter Accounting Counters for a detailed description. The received pulses are also added to the TOLL PULSES.
4.2
Control parameters of accounting counters

The following parameters have primarily an effect on how the accounting counters are updated.
DN00133192 Issue 8-0 en
19 (93)
4.2.1
NCB
If this parameter is set to T, the free of charge information is attached to the charging zones in the charging case. There are parameters in the OUSIGN and the INSIGN files to tell whether the free of charge information is accepted.
4.2.2
TCI
The parameter defines whether the time charging of the call leg is interrupted at the subscriber B (PSTN) onhook. This parameter has no effect on how the onhook message is passed to incoming signalling in the transit exchange.
4.2.3
ICC, OCC
These parameters contain a bit field which is used to enable/disable the circuit counters and circuit sum counters counter by counter.
20 (93)
DN00133192 Issue 8-0 en
Analyses
Analyses
The analyses performed by an MSC/MSS can be divided into register analyses and central memory analyses. Register analyses are made by incoming call control in signalling units. The analyses made by the ICC are:
.
origin analysis priority analysis dialling preanalysis bearer capability analysis call barring analysis end of selection analysis central memory tree selection analysis bearer capability to prefix analysis function analysis.
The central memory analyses in the central memory are made upon the request of the ICC. These analyses are the following:
.
circuit group (digit analysis) charging analysis.
The order of the analyses in the MSC/MSS are shown in figure The analysis sequence in MSC/MSS.
DN00133192 Issue 8-0 en
21 (93)
Bearer capability analysis
Pre analysis
Priority analysis
Origin analysis
Charging origin
Routing & charging attribute analysis
Digit analysis
Charging index
Charging analysis
Reason code
EOS analysis
EOS attribute analysis
Call barring analysis Bc to prefix analysis
Reason code or facility code
Function analysis
Figure 2.
The analysis sequence in MSC/MSS
For mobile-originated calls the analyses affecting pulse charging are origin analysis and charging analysis. Origin analysis analyses the origin data of the calling subscriber. This is always done before the digit analysis. The input to the origin analysis is: 1. 2. 3.
Calling party category. Acquired from the VLR. Values: normal, pay phone, test or priority call. Cell tariff. Base station-dependent information (located in the CDAFIL). There are four different tariffs. MS classmark. This parameter describes the transmitting power of the mobile station. The value is from 1 to 5.
The origin analysis can be created with the RVC MML command . The result of the origin analysis is the charging origin which is a number from 0 to 254. The charging origin number is used by the charging analysis. The origin analysis is not executed for the forwarding subscriber. If the call is trunk-originated, the charging origin is received from the incoming circuit basic data. This data is set with the incoming circuit creation MML commands.
22 (93)
DN00133192 Issue 8-0 en
Analyses
The charging origin for the charging analysis may also be received from EOS (End of Selection) analysis in several call phases. The EOS analysis is executed, for example, when call forwarding occurs or the roaming number is received from the HLR. The input to the EOS analysis is always a DX cause code. The new charging origin and the CM analysis tree from EOS analysis is used by call control if the analysis result identifier has the value execute CM analysis. The charging origin points the charging case of the MSRN and the call forwarding number. The attribute analysis is executed only for PSTN, PBX and mobileoriginated calls. The charging attribute analysis is executed before the digit analysis, and it may affect charging by changing the charging origin. If the result of the EOS attribute analysis is execute digit analysis, both analysis tree and charging origin may be changed. The charging attribute analysis can be controlled with several general attributes and attributes of the calling, called and redirecting subscriber. The result of the charging attribute analysis is the charging origin. Some attributes of the calling subscriber in the charging attribute analysis:
.
CLI with TON or TON only Subscriber category IMSI indicator Channel type Cell-dependent routing category MS power capability MS location type Routing category
General attributes:
.
Incoming signalling Call forwarding leg indicator Digit analysis tree
For a detailed description of the attributes, see the operating instructions on Routing and Analysis.
DN00133192 Issue 8-0 en
23 (93)
The charging analysis is executed after the digit analysis. The input for the charging analysis is the charging origin from the origin analysis and the charging index from the digit analysis. The input for the digit analysis is digits and the analysis tree number. The result of the charging analysis is the number of the charging case. File CRFILE is addressed with this number (see figure Accounting counters). The CRFILE record contains, for example, the charging zones (MCZ, IAZ, OAZ) and the charging point and handling of charging parameters. The charging analysis is first executed for the dialled digits, or for a trunkoriginated call, digits received from the incoming signalling system. The result is normally GSM END, HLR enquiry or outgoing route. In trunkoriginated calls, the IAZ is always taken from the first analysis, that is, before any number modification by the CM analysis or by the SCP has been done. After the possible number modifications, the number is analysed with the changed analysis tree and charging origin. Whatever the result of this analysis is, the MCZ, IAZ/ICC (if not already given by the previous analysis), NCB, TCI, CP and HC parameters are stored. If the result of this analysis is an outgoing route, also the OAZ/OCC is taken. If the analysis has led to an HLR enquiry, the resulting roaming number or the number that the call has been forwarded to is analysed in analysis tree and with charging origin received from the EOS analysis. The applicable charging data is MCZ, OAZ/OCC (if the analysis result is outgoing route), TCI, NCB, CP and HC. The last two are only used to handle the received charging messages. Generally speaking this analysis data is used to control the charging of subscriber B. For a more detailed presentation on analyses, see the operating instructions on Routing and Analysis.
5.1
Handling of analyses
The operator can view and modify the analysis and charging data with various MML commands.
Table 2. Action
MML commands for analysis and charging Command

RII RIA
Output the analysis data of an analysis tree Output the analysis data of an analysis tree & dialled digits
24 (93)
DN00133192 Issue 8-0 en
Analyses
Table 2. Action
MML commands for analysis and charging (cont.) Command

RIL RXC RMG GNC GGC GDM RVC RDE RDG RQC RQJ
Output the data of an analysis component Create EOS analysis Modify charging analysis Create charging zone Create change group Modify day classes Create origin analysis Create analysis component Add charging case Create subanalysis Create charging result
DN00133192 Issue 8-0 en
25 (93)
26 (93)
DN00133192 Issue 8-0 en
Time charging
Time charging
The purpose of time charging in the MSC/MSS is to gather all the timeassociated charging data of the call. In addition to measuring the accurate call time, time charging also generates pulses for different purposes. The pulses are generated online by using charge rate timers. This means that the total amount of pulses is not calculated based on the call duration at the end of the call. When the call ends, the time charging data is written to the CDRs, and it is used when the accounting counters are updated. Charging zone The parameters for pulse generation are received from the charging zone. The charging parameters of the zone are:
.
change group change group class charging method (synchronous/asynchronous) pulse train (PLT) free time (FT) repeated pulse train (RPLT) charge rate.
The zone information is stored in the CRRATE, which is located in the CM, the LSU, the BSU, the PAU, the CASU, the GSU and the CCSU. The accuracy for pulse train and repeated pulse train is 1/10 pulses, and for charge rate and free time 1/10 seconds. This accuracy is required to support the Advice of Charge (AOC). For more information, see European digital telecommunications system (Phase 2); Description of Charge Advice Information (CAI). That accuracy is used when the pulses are generated to intermediate call counters of time charging. When pulses are sent to an incoming circuit, the amount of pulses to be sent is truncated to an integer value. Therefore, there can be differences in pulses sent and pulses stored in accounting counters if pulse trains of a zone are defined
DN00133192 Issue 8-0 en
27 (93)
non-integer. The difference is, however, at most one pulse, but the error is cumulative. The reason for this is described in section Non-integer Pulse Sending. At the end of the call, the time charging pulse counters are rounded up to the nearest integer value and that value is used in CDRs and the accounting counters. Change groups Each charging zone is linked to a certain change group. A change group divides a day up to eight sections which may have different charging parameters according to zone definitions. There can be up to 254 change groups; each change group is defined for one day class. Day classes The operator can define up to four day classes. For example, day class 1 includes working days, day class 2 is Saturday and day class 3 is Sunday. A set of special days (maximum of 256 days) are used with day classes. Special days are days when special charging is applied (for example, Christmas, 1st of May). For each special day and week day four day classes can be assigned, one for each day class group. For more information, see Feature 469: Accounting Improvement. Day class groups are used to set different day classes for, for example, accounting and advice of charge. Tariffs The selection of the tariff is done with two keys: the day class of the current day and the charging zone in question. Figure Tariff change structure presents a case where the current day is Tuesday. As a result of the charging analysis, charging zones 1, 2, 3 are used in different charging automatons. The charging zone contains the information of the change group and the day class group to be used. The change group number for the charging zone number 2 is 1. Change group 1 of day class 1 is used to decide which tariff of the charging zone tariffs is used. There is a charge rate index for each period of time in a change group. This index tells which tariff is used by the charging zone. In this case, if the current time is 6:00 a. m. or 10:00 p.m., the first tariff of the charging zone 2 is used. Correspondingly, if the current time is 5:00 p.m., the valid charging parameters are obtained from the second tariff of that zone.
28 (93)
DN00133192 Issue 8-0 en
Time charging
Day class groups DCG 1... Special days 1995-12-24 Mon Tue Day classes . . . Sun Cur Day class 3: Change groups Charge rate index 1: (0:00-8:00-17:00-21:00-24:00) 2 3 1 2 4 1 4 1 4 3 4 2 Day class 2: 1: (0:00-10:00-18:00-24:00) 1 2 1 4 1 1 4 1 1 4 3 3 DCG 4 4 2 2
3: (0:00-7:00-16:00-21:00-24:00) 1 Charging zone 2 1 3 2: tariff, tariff, tariff chgr:1 day class gr. 4
1: tariff, tariff, tariff, tariff chgr:1 day class gr. 3
3: tariff, tariff, tariff, tariff chgr:3 day class gr. 3
Figure 3.
Tariff change structure
6.1
Internal pulse counters

Time charging holds the pulses from different sources in different counters. This means that pulses can be generated for incoming accounting, outgoing accounting and incoming circuit (the MSC/MSS keeps track of the pulses sent to an incoming circuit) for the same call. The accuracy of these intermediate pulse counters is 0.1 pulses.
DN00133192 Issue 8-0 en
29 (93)
6.2
Pulse generation
Pulse generation is presented in figure Pulse generation in MSC/MSS. In the beginning of the call a pulse train is generated if one is defined. If free time is defined, a timer is set for it. After the free time expires, another timer is started with timer value set to rate. When this timer has ran out, a repeated pulse train is generated. Repeated pulse trains after charge rates are generated until the call is cleared or new charging parameters are applied. This means that the subscriber is charged after each charge rate which he uses.
FT Rate Rate Rate
... PLT RPLT RPLT RPLT
PLT = Pulse train RPLT = Repeated pulse train
Figure 4.
Pulse generation in MSC/MSS
The generation of the first repeated pulse train can be synchronised with the beginning of the call. This means that the repeated pulse train is generated after a predefined free time and charge rate, or the first repeated pulse train can be generated after a random period of time. The way the first repeated pulse train is generated is controlled by the charging method of the charging zone. If the first repeated pulse train is generated after a random period of time, the charging method is called Karlsson charging . For more information, see S.A. Karlsson: General Principles Of Charging And Their Adaptation To a Global Network (see figure Pulse generation in Karlsson charging). Karlsson charging is identified with ASYNC in the charging zone creation (GNC) MML command. The random time period is always between [FT, FT+Rate]. After the first repeated pulse train, the following pulse trains are generated at a normal rate. Each charging zone contains the information about synchronisation of the first pulse train.
30 (93)
DN00133192 Issue 8-0 en
Time charging
FT
Rate
Rate
Rate
Rate' = Random (Rate), Rate' = [0, Rate]

Figure 5. Pulse generation in Karlsson charging
Pulse generation in advice of charge Another way to send pulses is to send a repeated pulse train immediately after the free time (see figure Pulse handling in AOC). Then each charge rate is charged before it is used. If a free time is not specified, charge rate is used instead. Pulses are generated like this for Advice of Charge (AOC) and it is mainly used by the mobile station. Karlsson charging has no effect on the way charging information is generated by the mobile phone.
Free time Rate Rate
Figure 6.
Pulse handling in AOC
DN00133192 Issue 8-0 en
31 (93)
6.3
Sending charging messages

The charging messages are sent to the incoming circuit using the main charging zone. The prerequisite for sending charging messages is that the CP parameter has been set to OE/OEA and the HC to CI and that the signalling system supports the sending of charging messages. If the MSC/ MSS supports sending of different types of charging messages, the supported charging message of the circuit group is defined in the circuit group data (CMECGR). The different nature of the MCZ and IAZ charging zones should be taken into account. The MCZ determines the charge rate when sending the charging message to the incoming circuit. The IAZ is used to generate the pulses to be used in the incoming accounting. So that the sent pulses and the readings in the accounting counters correspond to each other, the charging parameters of the MCZ and the IAZ must be the same.
6.4
Receiving charging messages

Charging messages received from the outgoing circuit are controlled with the HC and CP parameters in the charging analysis (see table HC/CP combinations and their effects on charging message transfer). The received pulses are stored with the outgoing accounting data. Storing the received pulses with the outgoing accounting data during the call also means that the intermediate charging pulse limit is reached earlier depending on the amount of received pulses. The pulse limit for intermediate charging is a parameter in the PRFILE (parameter class 1, parameter 2). The intermediate charging due to reaching the pulse limit is enabled/disabled with the parameter 1:75. Since charging messages are eventually paid by the subscriber that pays for the outgoing call leg (calling, forwarding or roaming party), the metering pulses are also added to the subscriber automaton. That means that the pulses are added to the CDR fields XXX_ORIG_MCZ_PULSES, XXX_FORW_MCZ_PULSES or XXX_ROAM_MCZ_PULSES. If the SCP has issued an SCI operation with the change percentage, the received charging is changed with the percentage before the pulses are added to the subscriber automatons. If the SCP has not changed the charging or issued an AC operation, the subscriber automaton pulses contain only the pulses that are received from the network. Otherwise, the pulses generated with the MCZ (or charging parameters that the SCP has provided) are also added to the subscriber automatons.
32 (93)
DN00133192 Issue 8-0 en
Time charging
The received charging message can also be sent to the SCP as a notification (Event Notification Charging, ENC). The ENC messages can be sent in case of pulses when the charging message has been received, after a certain amount of pulses has been received (the pulses limit is PRFILE parameter 1:76) or at the end of the call. Intermediate charging has no effect on how the ENC messages are sent.
6.5
Charging message transfer

The charging message transfer functions similarly to pulse receiving. If the IAZ is defined for the call and the HC parameter allows the transfer of charging to the incoming connection, the received charging is also added to the incoming accounting data. This enables the recording of transmitted pulses in the accounting counters of both the outgoing and the incoming circuit groups.
6.6
Calls free of charge

The call leg can be defined to be free of charge. There are three sources for free of charge information:
.
charging analysis address complete message (ACM) or answer message (ANM).
The validity of the free of charge sources is defined in the OUSIGN and the INSIGN files. Time charging generates no pulses for calls that are free of charge. The only exception to this is when the SCP uses the SCI operation for a call that is free of charge. The charging instructions in the SCI are seen as additional charging for the call. From the accounting point of view this means that the charging messages can be sent to the incoming circuit also in a call that is free of charge. The fields all answered calls and talk time are updated in the accounting counters. Only the ZONMET update is an exception: there are separate counters for calls that are free of charge and for chargeable calls for each charging zone.
DN00133192 Issue 8-0 en
33 (93)
If the free of charge information is included in the CDR, the billing centre can discard the tickets when the subscriber is billed. The optional Answer Type Differentiation feature must be enabled so that this information is written in the CDRs. It is also possible to discard the free of charge CDRs already in the MSC/MSS. This definition is made separately for each CDR type with the Detailed Charging Handling MML command group (GT command group).
6.7
Stopping of charging
Time charging is normally stopped when either of the calling parties hang up. Time charging for the party that hangs up is stopped immediately. Indication about the call clear is sent to the other call party and when the acknowledge to the call clear is received, also the charging of the other subscriber is stopped. If the call is PSTN-terminated, the charging of the call is stopped when subscriber B hangs up. If subscriber B wishes to continue the call within a certain time limit, charging is continued. The time limit is customer-specific and it is an internal parameter of the MSC/MSS. The value for the time limit ranges between 20 seconds and 2 minutes. The on-hook time of subscriber B is subtracted from the total call duration. That is why the call time calculated from the call start time and call end time is not necessarily equal to the chargeable call duration. When pulse charging is used, the first pulse train generated during the time when subscriber B is on-hook is stored in a special stop counter. When charging continues, the contents of the stop counter are added to the correct intermediate accounting counter. The generation of time intervals, charge rates, is continued normally throughout the on-hook time. This means that pulse charging is not synchronised with the next B offhook moment but with the beginning of the call. If the mobile subscriber moves out of the coverage of a BTS, time charging of the subscriber is stopped. This has an effect only on mobile accounting, since the accounting is never stopped in this case.
6.8
Tariff change
The change groups determine the change times in the MSC/MSS for all the charging zones. At the change times the signalling unit's copy of the charge rate file, CRRATE, is updated by sending the changed charging zone values from the master CRRATE of the CM unit to the signalling
34 (93)
DN00133192 Issue 8-0 en
Time charging
units. Time charging updates the new charge rate index to all the ongoing calls and starts measuring call time using the new index. If the distribution of the new charge rate to a single call fails, the alarm 2112, charge_rates_distr_failure goes off. The old and the new charge rates are compared and the new charge rate is applied as follows:
.
If the new charge rate is greater than the contents of the current charge rate timer, the old charge rate time is allowed to run out before the new one is applied. If the old charge rate timer equals to zero or the new charge rate is lower than the old one, the new charge rate is loaded immediately to the charge rate timer. The modification of the charging zone has a similar effect on the tariff change that is controlled by the change groups but the charge rate index does not change.
6.9
Intermediate charging
Intermediate charging means the generation of CDRs when the call is still going on. All the CDRs have an indicator telling whether this CDR is made during or at the end of the call and the reason for the intermediate CDR. When the intermediate CDRs are produced, also the accounting counters are updated with the call data that has been gathered so far. The answered calls counters are updated only at the end of the call. When the call data has been written in the CDRs, the time charging data is reset and a new time measurement is started. Only some special counters are not reset. These counters are the AOC-D/E pulse counter, the AOC pulse buffer for received pulses and the RNC pulse buffer. The causes for intermediate charging are: 1. 2. 3. 4. Expiration of the intermediate charging timer. This timer is set in the beginning of the call to value CALL_TIME_LIMIT (parameter 1:4). Some of the pulse counters have exceeded the value CHARGING_PULSE_LIMIT (parameter 1:2). The SCP has changed the charging parameters (chargeable announcement or chargeable user interaction ended). Intermediate charging is caused due to a change of Channel Related Parameters.
DN00133192 Issue 8-0 en
35 (93)
5.
The mobile equipment recovers from a radio link failure. Only the MOC CDR or the MTC CDR is generated, or the mobile accounting counters are updated. The call continues with a Follow-on Call. This requires Feature 994: CAMEL. Call drop back situation. This requires Feature 1093: Advanced Call Drop Back for VMS Interface. Inter-PLMN handover. This requires Feature 1168: Multiple PLMN and Inter-PLMN Handover Support in MSC. Inter-system handover. This requires Feature 1260: Inter-system handover and UMTS changes in MSC. Intermediate charging due to UMTS data call. This requires Feature 1265: CS Data User Plane Protocol Support for UMTS. Intermediate charging caused by SCP interactions. This requires Features 1196 and 1197: CAMEL Phase 4. Intermediate charging due to inter-MSC handover.
6. 7. 8. 9. 10. 11. 12.
The generation of intermediate charging is controlled with the parameter 1:75, INTERMEDIATE_CHARGING. Intermediate charging should be considered as a slight source of error when comparing the incoming and the outgoing accounting of two exchanges. Specially when the intermediate charging time limit is different, the counters are updated differently during the same calls in two exchanges.
6.10
Charging zone checking

The charging zone parameters stored in the CRRATE file in each signalling unit are checked periodically against the contents of the CRRATE file located in the Central Memory (CM). The checking period is a PRFILE parameter the default value of which is two hours. If there is any difference between the charging zone parameters, the alarm 1054 charge_rate_fail_corr goes off with the charging zone number in question. The deviation in the signalling unit's copy of the CRRATE is corrected instantly by time charging, and the corrected charge rate values are applied to the new calls from that moment on.
36 (93)
DN00133192 Issue 8-0 en
Time charging
6.11
Non-integer pulse sending

Zones which are defined to have non-integer pulse trains are problematic since only integer pulses can be sent to a circuit with an MPM message. Generally, defining non-integer pulse trains to charging zones is not recommended. The possibility of defining pulse trains with an accuracy of 0.1 pulses is left to support the accuracy requirements of the Advice of Charge (AOC). However, the charging controls of the SCP may eventually lead to non-integer pulse trains. Problems caused by non-integer pulses are solved when both the total integer pulses sent and the total floating point valued pulses are registered. Each time pulses are sent to the circuit, the correspondence between these two counters is checked. If the difference is greater than 1, the amount of pulses to be sent is incremented by 1. This adjustment of pulses is represented in figure Non-integer pulse handling. This way the total accuracy of the charge for one call is one pulse.
2 2.4 PLT
2 2.3 RPLT
2 2.3
2 2.3
+1
MPM message Accounting counters 1.3 one pulse added
Figure 7.
Non-integer pulse handling
The sum of pulses is rounded to the nearest integer value at the end of the call. The accuracy of pulses in both the accounting counters and the CDRs is one pulse. This means that there might be a difference of one pulse in the accounting counters' pulses and the CDRs and the pulses that are actually sent to the incoming circuit.
DN00133192 Issue 8-0 en
37 (93)
38 (93)
DN00133192 Issue 8-0 en
Accounting counters in MSC

The accounting counters contain information on the charging pulses, call time and the number of answered calls. The counters are updated along with the ticket generation when the call has been cleared or when intermediate charging has been made. Accounting counters are also updated during an inter-MSC handover. For more information see Feature 446: MSC-MSC Handover Accounting and Feature 927: Improvements of Inter MSC Handover Architecture. The accounting counters contain:
.
pulses generated with the IAZ, the OAZ, and in some cases with the MCZ the call time the number of answered calls of the incoming and the outgoing accounting.
Although the parameters of the IAZ, the OAZ and the MCZ affect the rate according to which pulses are generated in the counters, it should be noted that also recording of the call time and the number of answered calls requires the definition of the IAZ or the OAZ in the charging analysis. If there is no need for pulse charging and the pulses should not be visible in the accounting counters, the charging zones used as the IAZ or the OAZ should be defined so that no pulses are generated. The main counter types in the counter files are metering pulses, received pulses and toll pulses. Toll pulses correspond to the pulses generated with the IAZ and received pulses correspond to sum of the pulses generated with the OAZ and pulses received in the MPM messages from the outgoing circuit. If the received pulses from outgoing signalling should only be visible in the received pulses fields, it is important that the OAZ is defined for the charging case. The charging parameters for the charging zone in question must be zero. The contents of the metering pulses field generally corresponds to the sum of received pulses and toll pulses. The accounting counters are as follows (see figure Accounting counters):
DN00133192 Issue 8-0 en
39 (93)
CIGMET - Circuit Group Meter File

.
Charging data of all the external circuit groups Contains the following counters: . Metering pulses: All pulses generated in the MSC for the incoming and/or the outgoing accounting plus pulses received from the outgoing circuit. . Toll metering pulses: Pulses generated with the IAZ plus the pulses transmitted to the incoming circuit. . Received pulses: Pulses generated for the outgoing circuit and received from the outgoing circuit. . All incoming answered calls . Incoming talk time . All outgoing answered calls . Outgoing talk time . All answered toll calls: Not used Addressed with the circuit group number
ZONMET - Zone Meter File

.
Charging information of the charging zones. The indexes 1-4 in the counters refer to the charge rate index of the charging zone. The changing moments of the charge rate indexes are defined by the change group of the zone. The information is gathered from the incoming and the outgoing accounting data defined by the IAZ and the OAZ in the charging analysis. If the Mobile Accounting feature is enabled, the ZONMET counters corresponding to the MCZs of the ISDN and roaming number analyses are updated as well. Pulses received from the outgoing circuit are not recorded in the ZONMET. Contains the following counters: . Metering pulses: All pulses generated with the charging zone (rate indexes 1-4). . Answered calls: Number of answered calls of the charge rate (1-4). If the charge rate changes during the call, the charge rate index in question is the one that is valid at the end of the call. . Talk time: Conversation time in seconds of the charge rate (14)
40 (93)
DN00133192 Issue 8-0 en
Answered free calls: Number of answered calls that are free of charge. It requires the Mobile Accounting feature. Free talk time: Conversation time of calls that are free of charge. It requires the Mobile Accounting feature. For more information, see Feature 747: Mobile Accounting.
Addressed with the charging zone
CIRMET - Trunk Circuit Meter File

.
Charging information of each time slot in each PCM circuit. Contains 8 counters, which are described in the CTYPES and CRFILE files. Addressed with the PCM via the pointer file CRCMAP. Used when the charging method for the current circuit is set to 1 in the CTYPES.
CSUMET - Trunk Circuit Sum Meter File

.
Charging data of trunks summed up per a circuit group. Contains 8 counters which are described in the CTYPES and CRFILE files. Addressed with the circuit group number.
The fields ICCON and OCCON in the CRFILE contain a bit mask, which determines the counters that are used in CIRMET and CSUMET. The counter types for these counters are described in the CTYPES file. Bit masks can be modified with digit analysis MML commands, for example, with the RMG command. The supported counter types are as follows:
.
All metering pulses (AP): All pulses generated in the MSC for the incoming and/or the outgoing accounting plus pulses received from the outgoing circuit. Developed pulses (DP): Pulses sent to the incoming circuit. Transferred pulses (TP): Pulses generated for the outgoing accounting plus the pulses received from the outgoing circuit. Unsent pulses (UP): Pulses which have been generated after the incoming circuit release but have not been subtracted from the pulse counters.
DN00133192 Issue 8-0 en
41 (93)
Untransferred pulses (UT): Received pulses that have not been sent to the incoming circuit. Call time (CT) Reply (RE): All answered calls BP, SP, PB, UK, AF and AB: Not used in GSM
It should be noted that the counter type for each counter is defined for the circuit group. The bit mask that enables the use of these counters is charging-case-specific information. TOTMET - Total Meters File
.
Sum metering data of the whole exchange, contains one record. Contains the following counters: . Metering pulses: All pulses generated in the MSC for the incoming and the outgoing accounting plus pulses received from the outgoing circuit. . Generated pulses: Pulses sent to the incoming circuit. . Toll metering pulses: Pulses generated with the IAZ plus the pulses transmitted to the incoming circuit. . Received pulses: Pulses generated in the MSC for the outgoing accounting plus the pulses received from the outgoing circuit. . Reminder pulse: See the explanation below. . Unpointed pulses: Pulses received before the charging point. . All answered calls . Talk time . All PSTN orig calls: Number of calls coming from another network.1) . PSTN orig talk time: Conversation time of calls coming from another network. . All PSTN term calls: Number of calls terminating to another network. . PSTN term talk time: Conversation time of calls terminating to another network. . All own orig calls: Number of calls coming from the operator's own network.2) . PSTN own talk time: Conversation time of calls coming from the operator's own network. . All own term calls: Number of calls terminating to the operator's own network.
42 (93)
DN00133192 Issue 8-0 en
. . . .
PSTN own talk time: Conversation time of calls terminating to the operator's own network. All mobile orig calls: Number of mobile-originated calls. Calls from the forwarding subscriber are excluded. Mobile orig talk time: Conversation time of mobile-originated calls. All mobile term calls: Number of mobile-terminated calls. Calls to the forwarding subscriber are excluded. Mobile term talk time: Conversation time of mobile-terminated calls. All VPS orig calls: Number of VPS-originated calls. VPS orig talk time: Conversation time of VPS-originated calls. All VPS term calls: Number of VPS-terminated calls. VPS term talk time: Conversation time of VPS-terminated calls. All device originated calls: Number of calls that have been monitored (OLCM, Feature 703: On-line Call Monitoring) and the calls that have used an external IP. Device originated talk time: Duration of the call monitorings and the use of an external IP. All mobile to mobile calls: Number of whole calls that both originate from an MS and terminate to an MS. A whole call may include an arbitrary number of call forwardings. Mobile to mobile talk time: Conversation time of the 'whole' MS-MS calls.
Note
1) PSTN and other network refer to the connections for which PSTN-originated call (POC) and PSTN-terminated call (PTC) CDRs are produced. This is defined in the INSIGN and OUSIGN files. Local (own) network refers to the connections for which POC and PTC CDRs are produced.
2)
Reminder pulses are pulses generated by time charging, but because the incoming circuit has been released, the pulses have not been sent to the incoming signalling. The situation where reminder pulses are not generated is illustrated in figure Reminder pulses from incoming call
DN00133192 Issue 8-0 en
43 (93)
control. In this case, reminder pulses are subtracted from the generated pulses field in each accounting counter, and if the IAZ is defined, the pulses are also subtracted from the metering pulses and the toll metering pulses fields. The subtraction is also made in the corresponding pulse fields in the CDRs.
Note
Because the number of pulses sent with the MCZ is subtracted from the pulses generated with the IAZ, it is important that either the parameters or the indices of the IAZ and the MCZ are the same in the charging cases where pulses are sent to the incoming circuit.
Incoming 1. signalling
Incoming call control 3. 2.
2. Outgoing signalling
Time charging
Accounting
Figure 8.
Reminder pulses from incoming call control: 1. The incoming circuit (ICC) is released. 2. Time charging sends pulses or they are received from the outgoing circuit (OCC) before ICC removes charging. 3. Reminder pulses and charging pulses are used to update the accounting counters.
Relatively rarely a situation might come up where the reminder pulses cannot be subtracted from all the accounting counters. This case is illustrated in figure Reminder pulses from incoming signalling service. By the time accounting receives the reminder pulses, the information of the IAZ number is already lost. That is why the subtraction for the ZONMET cannot be done. The pulses are added to the reminder pulses field in the TOTMET, the CIRMET and the CSUMET to tell the difference between the counter values and the pulse field values in CDRs. In this case the information of the reminder pulses cannot be passed on to CDRs.
44 (93)
DN00133192 Issue 8-0 en
SSI
2.
Incoming call control 4.
1. 5.
SSO
1. Time charging 3.
Accounting
Figure 9.
Reminder pulses from incoming signalling service: 1. The time charging sends pulses or the pulses are received from outgoing signalling (SSO). 2. ICC transfers these pulses to incoming signalling (SSI). 3. SSI cannot pass the pulses to incoming circuit due to subscriber A being on-hook. Pulses are added to proper accounting counters. 4. ICC removes charging. 5. The generated charging pulses are added to counters and stored in CDRs.
The pulses that are received from the outgoing circuit but cannot be sent to the incoming circuit because the incoming circuit has been released are not generally recorded in the accounting counters. These pulses are recorded in the accounting counters the same way as the unsent pulses in a case where the pulses have already reached the incoming signalling system. In the first case where the information about the incoming circuit release has already reached the incoming call control, the unsent pulses and the untransferred pulses are separated in the counters of the CIRMET and the CSUMET. Both the incoming and the outgoing circuit pulses of transit calls (for example, PSTN-PSTN calls) are added to the TOTMET's metering pulses. The answered calls and talk time fields are updated only once in transit calls and in a call forwarding case PSTN-MS-PSTN.
DN00133192 Issue 8-0 en
45 (93)
Counter types: All metering pulses Received pulses Generated pulses Unsent Pulses Talk time All answered calls Untransferred pulses
Circuit group number
Charging method: Per circuit group Per circuit and circuit group No charging
Type of counter 1 Type of counter 2 Type of counter 3 Type of counter 4 Type of counter 5 Type of counter 6 Type of counter 7 Type of counter 8 Charging method
Charging case
CP HC ICC OCC MCZ IAZ OAZ
CTYPES
CRFILE
ICC/OCC
MSB LSB
0 PCM-TSL Counter index Counter 1 Counter 2 Counter 3 Counter 4 Counter 5 Counter 6 Counter 7 Counter 8
0 n
FFFF CRCMAP
Counter 1 Counter 2 Counter 3 Counter 4 Counter 5 Counter 6 Counter 7 Counter 8
0 n
FFFF CIRMET CSUMET
FFFF
ALL TOLL REC Ans. inc. calls Inc. call time Ans. outg. calls Outg. call time
0 n
Charging zone
0 n ALL (4) Ans calls (4) Call time (4) Free calls (4) Free call time (4)
ALL TOLL REC GEN REM UNP Call time Answered calls MS-MS talk time TOTMET
FFFF CIGMET ZONMET
FFFF
Figure 10.
Accounting counters
46 (93)
DN00133192 Issue 8-0 en
7.1
Handling of accounting counters

The operator can access the accounting counters using MML commands. The counters are output with the following commands:
Table 3. File
CIRMET CSUMET ZONMET
MML commands for counter output Command

GOC GOG GOT GOX
TOTMET, CIGMET
The counter types in the CIRMET and the CSUMET are defined using the GRM MML command.
7.2
Mobile accounting
Mobile accounting means the update of the main charging zone counters. One zone counter (consisting of at least the answered calls and talk time counters) is updated for one calling party of the call leg. This means that for trunk calls the normal IAZ/OAZ updates are made if the defined zone deviates from zero. If the calling party is a mobile subscriber, the update is made to the counter corresponding to the MCZ of the dialled digit analysis. If the called party is a mobile subscriber, the MCZ of the roaming number analysis is used in the ZONMET update. In call forwarding cases, the resulting MCZs of the analysis of the number that the call has been forwarded to and the corresponding roaming number analysis are used in the ZONMET update. In a CFU call (A-B-C), the roaming number of subscriber B is not available, so the resulting MCZ update is omitted. The Mobile Accounting feature has also brought new counters in the sum meters. The names of most of the counters are self-explanatory, but some aspects should be noted while interpreting the counter values.
.
The counter MS-MS calls are internal calls where both the calling and the final (after an arbitrary number of call forwardings) called subscriber are mobile subscribers. The 'own network' also includes the private branch exchanges.
DN00133192 Issue 8-0 en
47 (93)
48 (93)
DN00133192 Issue 8-0 en
Accounting counters in MSS

The MSS concept contains a new accounting counter architecture that works parallel with the existing counter architecture. The accounting counters in MSS contain information about the call time and the number of answered calls which are routed by using through separate Control plane and User plane. Accounting for the TDM connections is collected in the same way as earlier. CIGMET, CIRMET and CSUMET counters contain data of circuits and circuit groups. ZONMET and TOTMET counter data is collected in the same way as earlier and even a new accounting counter architecture is defined for MSS. User plane ATM/IP counters
.
UPD defines user plane connections to/from MGWs controlled by the MSS. UPDs are created by the operator when configuring the network. Charging data of the user plane contains the following counters: . Incoming calls . Outgoing calls . Talk time (incoming calls) . Talk time (outgoing calls)
Table 4. REC
ATM
ATM accounting counter SUBREC

UPD index 1
VALUE
incoming calls outgoing calls talk time (incoming calls) talk time (outgoing calls)
...
...
DN00133192 Issue 8-0 en
49 (93)
Table 4. REC
ATM accounting counter (cont.) SUBREC

UPD index n
VALUE
Table 5. REC
IP
IP accounting counter SUBREC

UPD index 1
VALUE
... UPD index n
... incoming calls outgoing calls talk time (incoming calls) talk time (outgoing calls)
Control plane SIP/BICC counters

.
UPDR defines control plane connections towards the succeeding MSS and the preceding MSS. UPDRs are created by the operator when configuring the network. Charging data of the control plane contains the following counters: . Incoming calls . Outgoing calls . Talk time (incoming calls) . Talk time (outgoing calls)
50 (93)
DN00133192 Issue 8-0 en
Table 6. REC
SIP
SIP accounting counter SUBREC

UPDR_id 1
VALUE
... UPDR_id n
Table 7. REC
BICC
BICC accounting counter SUBREC

UPDR_id 1
VALUE
... UPDR_id n
8.1
Binary formats
The binary formats for MSS are defined below.
DN00133192 Issue 8-0 en
51 (93)
8.1.1
8.1.1.1
Data block header

Header structure
Table 8. Byte
01 25 615 1619 20 21 22 2330 3134 3538 39 4051 5263 6465 6697 98 99
Structure of header Contents

Block checksum Length of whole block Exchange identifier Exchange system identifier Format version Store method Counter service identifier Transfer time of block Order number of transferred block Number of counter sets included into the block Number of counter IDs included into the block format ID of the first counter set in block ID of the last counter set in block Number of counters included into the block format
Code
W DW C(10) DW C C C BCD(8) DW DW C DW(3) DW(3) W
Counters included into block format C(32) Index of logical path Counter structure C C
8.1.1.2
Description of header fields Block checksum Module 65536 counted per bytes, starting from byte 2 (length of whole block). Length of whole block This is the length of the data with the header included.
52 (93)
DN00133192 Issue 8-0 en
Exchange identifier This field is optional and identifies an exchange within the network. Exchange system identifier A unique numerical identifier (system C-number) which is used to identify the exchange within the network. Format version Identifier of the format of the records contained in a block. With this identifier it is possible to examine whether the format of the records included in the block has changed. If the format changes, the identifier is incremented. Store method 1 = Transfer activated by MML 0 = Automatically transferred Counter service identifier The service that is used. 1 = User plane 2 = Control plane Transfer time of block At this time the data is output through the logical file. The transfer time is stored in binary form (BCD coded time and date) as follows: Hundredths of a second C Seconds C Minutes C Hours C Days C
DN00133192 Issue 8-0 en
53 (93)
Months C Year W Order number of transferred block This value tells the block order in succession. In case of reset, this value starts from zero. Number of counter sets included into the block The number of counter sets included into the block in question. Number of counter IDs included into the block format The number of dimensions (ID number of the used service) of the block format in question. The MSS Accounting uses two-dimensional service. ID of the first counter set in block The IDs used in respect of the above field (Number of counter IDs included into the block format) for the first counter set of the block in question. ID of the last counter set in block The IDs used in respect of the above field (Number of counter IDs included into the block format) for the last counter set of the block in question. Number of counters included into the block format The number of the accounting counters (or sum counters) of the block format in question. By defining the locigal paths the operator can include/ exclude accounting counters (or sum counters) into/out of the block format. Counters included into block format The used accounting counters (or sum counters) and their order of the block in question. Index of logical path Index of logical path (1) via the block was transferred. Counter structure 1 = Turn around counters included
54 (93)
DN00133192 Issue 8-0 en
0 = No turn around counters
8.1.2
8.1.2.1
Record formats
General overview The index of the logical path is given for each record format, and this data is stored in the block header. The logical file through which the data block is stored in an I/O device is also mentioned.
8.1.2.2
ATM/IP counters
Record structure Service identifier: 1 Format version Logical file: MSSACCOUNT The record contains the ATM/IP-specific counters of the user plane. The record structure is the following:
Table 9. Byte
03 47 811 12 1316 17 1821 22 2326
Structure of ATM/IP counters Counter

ATM/IP UPD index 1/ UPD index n Incoming calls
Code
DW DW DW
Turn around value for the 'incoming C calls' above Outgoing calls DW
Turn around value for the 'outgoing C calls' above Talk time (incoming calls) DW
Turn around value for the 'talk time C (incoming calls)' above Talk time (outgoing calls) DW
DN00133192 Issue 8-0 en
55 (93)
Table 9. Byte
27
Structure of ATM/IP counters (cont.) Counter Code
Turn around value for the 'talk time C (outgoing calls)' above
Note
The value of an accounting counter is stated with the turn around information.
Description of record fields ATM/IP ATM = 0 IP = 1 UPD index UPD index (1 to 1000) that indicates from which destination the counters are collected. Counters Four counters are stored per record:
.
Incoming calls Outgoing calls Talk time (incoming calls) Talk time (outgoing calls)
Turn around field(s) (optional) You can select if it is included in a counter set or not. It is the number of turn arounds of a related accounting counter value. If this option is used, a counter set contains as many turn around fields as the number of the accounting counter fields in it. The total sum value of an accounting counter can be calculated using the following equation:
56 (93)
DN00133192 Issue 8-0 en
Total value of the accounting counter = the value of the accounting counter + the turn around value of the accounting counter * 4 294 967 296
Note
If turn around option is used, a counter set contains as many turn around fields as the number of the accounting counter fields, otherwise this field is not included!
8.1.2.3
SIP/BICC counters
Record structure Service identifier: 2 Format version Logical file: MSSACCOUNT The record contains the SIP/BICC-specific counters of the control plane The record structure is the following:
Table 10. Byte

03 47
Structure of SIP/BICC counters Counter

SIP/BICC UPDR index 1/ UPDR index n DW
Code
DW
811 12 1316 17 1821 22 2326 27
Incoming calls
DW
Turn around value for the 'incoming C calls' above Outgoing calls DW
Turn around value for the 'outgoing C calls' above Talk time (incoming calls) DW
Turn around value for the 'talk time C (incoming calls)' above Talk time (outgoing calls) DW
Turn around value for the 'talk time C (outgoing calls)' above
DN00133192 Issue 8-0 en
57 (93)
Note
The value of an accounting counter is stated with the turn around information.
Description of record fields SIP/BICC BICC = 0 SIP = 1 UPDR index UPDR index (1 to 4096) that indicates from which destination the counters are collected. Counter Four counters are stored per record:
.
Incoming calls Outgoing calls Talk time (incoming calls) Talk time (outgoing calls)
Turn around field(s) (optional) You can select if it is included in a counter set or not. The number of turn arounds of a related accounting counter value. If this option is used, a counter set contains as many turn around fields as the number of accounting counter fields in it. The total sum value of an accounting counter can be calculated using the following equation: Total value of the accounting counter = the value of the accounting counter + the turn around value of the accounting counter * 4 294 967 296
58 (93)
DN00133192 Issue 8-0 en
Note
If turn around option is used, a counter set contains as many turn around fields as the number of accounting counter fields, otherwise this field is not included!
8.2
Handling of counters
Dynamic Counter Handling (GS) MML Command Group The dynamic counters are managed by using the commands of the Dynamic Counter Handling command group (GS). By using these commands you can interrogate and modify the parameters of dynamic counters, add or remove counter set indices to or from updating, as well as display counters and active indices. With these commands you can also define which of the counters you wish to transfer to post-processing.
Table 11. Action

Interrogate counter parameter Update counters to disk Transfer compiled counters Modify counter block format Modify sum counting formula Output counter block format Display counters Set counter updating parameters Set counter transfer parameters Add indices to updating Remove indices from updating Interrogate active indices
MML commands for handling MSS-related accounting counters Command

GSI GSK GSL GSM GSN GSO GSQ GSS GST GSV GSX GSY
For more information about the above MML commands, see Dynamic Counter Handling Command Group (GS).
DN00133192 Issue 8-0 en
59 (93)
60 (93)
DN00133192 Issue 8-0 en
Inter-MSC handover
Inter-MSC handover
If subscriber A (or subscriber B) moves from location area 1 to location area 2, which belongs to another MSC/MSS than location area 1, the reservation of the circuit between MSC-A and MSC-B can be recorded with accounting. The charging of a call where an inter-MSC handover takes place is described in figure Inter-MSC handover accounting.
MS MS
MOC/ MTC
MSC-A
MSC-B
MTC
PTC MTC/PTC/ (IAZ/ MOC/POC OAZ) OAZ
POC IAZ
Subscriber A/B
Figure 11.
Inter-MSC handover accounting
A set of handover numbers are reserved for every connection that an interMSC handover may be made to. For the handover number in question a charging case with the OAZ must be defined in the MSC-A. The accounting counters in the MSC-A are updated with this charging zone for the time when the circuit between the MSC-A and the MSC-B was reserved. If a handover occurs after the
DN00133192 Issue 8-0 en
61 (93)
signalling phase and before the speech state is reached, the function of an inter-MSC handover is similar to an inter-MSC handover made during the speech state. If such a call is answered, the basic CDRs are produced in both the MSC-A and MSC-B. If the call is PSTN-terminating, the charging for the outgoing circuit (OAZ) is started normally and continued normally throughout the call. Accordingly, charging for the incoming circuit (IAZ) is started for the PSTNoriginated calls. In the MSC-B the call is treated as a call coming from the own network. The charging case is received from the analysis of the ISDN number of the subscriber making the handover. If the IAZ has been defined for this charging case, accounting counters (all the counters in figure Accounting counters) are updated. If CDR generation for calls coming from the own network is defined in the CHPARA, a POC CDR is created. A POC CDR is also created if the call is not answered. Also an MTC CDR can be generated if enabled in CHPARA. The accounting counters are updated in the same way in both MSCs. This means that, for example, the total call times are the same in the circuit and the circuit group counters of the inter-MSC circuit in the MSC-A and the MSC-B. The charging zone counter and the total counters of the exchange differ: the zone counter updates are made for the charging zone defined in the handover number analysis in the MSC-A. Thus, a special handover zone can be defined. Since the charging zone (IAZ) is received in the ISDN number analysis in the MSC-B, no special handover zone can be used.
62 (93)
DN00133192 Issue 8-0 en
Accounting counter backup
10

The contents of the accounting counters can be copied to disk and tape, or disk only. The contents are copied either periodically or manually using an MML command. The backup interval can be defined with an MML command, and it can be set from 1 hour to 24 hours in the case of disk storage and from 1 day to 30 days in the case of tape storage. The backup moment is defined as minutes past an even hour in the case of disk storage and as a time in the case of tape storage. In periodical backup copying the contents of the counters in the CHU-0 and the CHU-1 are compared. If the difference between these counters is greater than a tolerance defined by the MML command (see table MML commands for counter backup and comparison), the corresponding records are printed and the alarm 2084 Disk Back-up of Charging Counters Incomplete goes off. When the counters are copied manually to a tape or a disk, the charging unit is defined in the MML command. This means that no comparisons are made. The counter values of the two units can also be compared without writing them to disk/tape. Both in the periodical and in the manual counter backup copying the counter types to be copied to tape and/or disk can be specified. The counter types (meaning files) can be any set of counters described in Chapter Accounting counters. As a default, none of the counter files are written to disk/tape. The counters can be retrieved from the OMU's disk, or the contents of counters in the charging unit 1 can be copied to the counters in the charging unit 2, or vice versa. Also, the counters in the spare CHU can be updated from the working CHU counters. The accounting counters backup also provides a way to access the counters for accounting purposes. The approach is recommended because the accurate backup time can be defined using an MML command and the format of the backup files is well-documented, see
DN00133192 Issue 8-0 en
63 (93)
Binary Formats of Charging: Counters, References. The other approach would be to use the command calendar and the output commands of the counters. The implementation is easier with this approach if only a couple of charging zones are used.
10.1
Handling counter backup

The accounting counter files can be backup copied with the following MML commands:
Table 12. Action
MML commands for counter backup and comparison Command

GCP GCF GCM GCU GCC GCD GCR GCT GCH GCO
Copy counters to tape Copy counters to disk Compare counters Update counters Add counter type into backup copying Remove counter type from backup copying Modify backup copying characteristics Set tape copying time Set disk copying time Output backup copying characteristics
10.2
Differences in counters of CHU-1 and CHU-2

The active and the passive CHUs are synchronised, and they normally update the accounting counters in exactly the same way. However, if the accounting counters' backup is in use, the pre-backup comparison of the counters sometimes shows differences in the counters. The possible reasons for this are:
64 (93)
DN00133192 Issue 8-0 en
1.
CHU switchover When the counter files are warmed, the spare unit is in such a state that it cannot update the accounting counters. The counters are normally updated in the working unit. This causes a difference in the counters, which is noticed when the next counter backup is made. The magnitude of this difference varies. The difference depends on the duration of the calls that are released during the switchover and the number of released calls. The latter depends on the duration of the switchover, and thus, partly on the effective size of the ZONMET. The alarm can be prevented by copying the counters from the passive unit to the active unit. Increasing the tolerance does not necessarily help because the problematic calls during the warming of files may be extremely long. This causes quite large differences in the counters.
2.
Backup during heavy traffic The updates of the accounting counters in the active unit lag behind the passive unit during heavy traffic. The lag comes from the heavy procedure of the CDR generation which is made only in the active CHU. This may result in a growing difference in the accounting counters, but the difference will be corrected when traffic slows down. This can be prevented by performing the backup manually during as low traffic as possible.
3.
Counter copy from unit to unit during heavy traffic The main cause for the differences is the same as in the previous case. The lag should not be corrected by copying the counters from unit to unit during heavy traffic. The counters are written either with old data or early data depending on which unit the data is copied to. This may cause the counters to be corrupted. The corruption will come up when the next backup is made.
A proper tolerance should be used in the comparison of the counters. The difference is calculated by making a subtraction between the pulse, time and answer counters and adding up the differences by counter records. In the zone meters, the record consists of one charge rate index of one charging zone meter. The tolerance should be large enough to allow a difference of one call that is probable during the backup. A probable call could be, for example, a one-minute call with 60 pulses. The tolerance for this call would be 121 (60+60+1).
DN00133192 Issue 8-0 en
65 (93)
66 (93)
DN00133192 Issue 8-0 en
Transferring accounting data via FTAM
11
Transferring accounting data via FTAM

Each of the accounting counter files can be transferred with FTAM. The backup files can be linked to an OSI application. The counters can be transferred using the existing OSI applications. The use of a special accounting application is not necessary because typically the transfer does not have to be done immediately. It is up to the operator to determine whether a dedicated OSI application should be used. The creation of an OSI application for the FTAM transfer is described briefly in Appendix Accounting data transfer using FTAM.
11.1
Advanced accounting data transfer

The accounting counter files can also be transferred directly with FTAM from the disk of the CHU. This requires Feature 646: Advanced Accounting Data Transfer. The feature enables the use of the GCV MML command which is used to set the characteristics of the counter transfer. The advantage of using the advanced FTAM transfer is that the same procedure that is used to transfer the charging files can be used. The charging files are transferred using control files that tell which files have already been transferred and which are updated files in the MSC/MSS. This means that the backup period has to be defined in the MSC/MSS only, and the files are transferred automatically when new accounting data is available.
DN00133192 Issue 8-0 en
67 (93)
11.2
Charging capacity
This feature provides the option of having more than one pair of charging units in the DX 200 MSC hardware configuration. The functionality of charging is not affected by the number of CHU pairs. Adding more CHU pairs only improves the capacity significantly. This feature is only available for DX 200 MSCi and DX 200 Transit MSCi. For more information, see Feature 927: Improvements of Inter MSC Handover Architecture. The accounting counter files can be transferred with FTAM only from the 'master CHU' (CHU-0).
68 (93)
DN00133192 Issue 8-0 en
Using CDRs for accounting purposes
12
Using CDRs for accounting purposes

In addition to using the accounting counters, CDRs can be used to gather the necessary accounting data. This approach is much more flexible, as it provides more information about the calls than just the charging zone and the circuit group number. Accounting is made in the billing centre from the POC and the PTC CDRs. If PBX accounting is wanted, the PBXO and PBXT CDRs are used. The significant fields in these CDRs are IAZ_TARIFF_CLASS, IAZ_PULSES, IAZ_DURATION in the POC and the PBXO and OAZ_TARIFF_CLASS, OAZ_PULSES, OAZ_DURATION in the PTC and the PBXT. A full description of the CDR formats is available in Storing and Transfer of Charging Data, Interface Specification. The obvious drawback of this approach is that the amount of charging data gets larger if the PSTN and the PBX CDRs have not been generated earlier. The pulse data and the possible CDR types are presented in table CDRs and the fields that can be used for accounting purposes.
Table 13. CDR Type

MOC MTC FORW ROAM POC PTC PBXO PBXT DOC RCC
CDRs and the fields that can be used for accounting purposes MCZ
X X X X X X X X X X X X X X
IAZ
OAZ
TERM
ROAM
DN00133192 Issue 8-0 en
69 (93)
MCZ: Pulses generated for IN charging (SCI, O-BCSM) plus the received pulses multiplied by change percentage (SCI, O-BCSM). IAZ: Incoming accounting pulses generated with the IAZ plus pulses transferred to the incoming circuit in a transit exchange (or in a PBXoriginated call). OAZ: Outgoing accounting pulses generated with the OAZ plus received pulses. Term: Pulses generated for IN charging (SCI, AC, T-BCSM) Roam: Pulses generated for IN charging (SCI, G-BCSM) plus pulses received from the roaming leg multiplied by change percentage (SCI, G-BCSM).
70 (93)
DN00133192 Issue 8-0 en
Accounting parameters used in Advice of Charge
13

The function of the Advice of Charge (AOC) (see European digital telecommunications system (Phase 2); Description of Charge Advice Information) is as follows: The MSC/MSS transmits the current charging parameters, CAI elements (e-parameters), to the mobile station. When the MSC/MSS calculates the parameters, the charging method (SYNC/ASYNC) is discarded. The mobile station updates the internal counter, the current call meter (CCM), with these parameters to supply the subscriber with a real-time estimate of the bill which is eventually made by the billing centre. A reasonable amount of accuracy and stability is required from the AOC implementation. Stability means that the rate at which the mobile station increments its current call meter is even. What is not desired is, for example, sudden bursts of charge or low rate of CCM updating. The AOC-C differs from the AOC-I in that when the MSC/MSS sends the CAI elements to the mobile station, the mobile equipment does not send an acknowledgement message to the MSC/MSS. This may happen because the mobile phone is an old model that does not support the AOC functionality or the phone is faulty. In this case the AOC-C call is disconnected. The charging parameters are transmitted to the mobile station in the beginning of the call and always when the charge of the call changes. CAI elements The CAI elements consist of seven charging parameters of which five are currently used. These parameters are: e1: e2: repeated pulse train. [0.0, 819.1] charge rate[0.0, 819.1]
DN00133192 Issue 8-0 en
71 (93)
e3: e4: e5: e6: e7:
scaling factor, used to make a conversion between currency units [0.00, 81.91] pulse train in the beginning of the call [0.0, 819.1] units per data interval Not used. data usage interval for unitisation Not used. free time [0.0, 819.1]
See figure Pulse handling in AOC for the use of the parameters in pulse generation. With the pulses received from the network, the operator can bill the subscribers according to the costs they have caused when calling to the PSTN. The pulses can be shown as AOC to the MS. Normally the received pulses are stored for 10 seconds in the MSC/MSS and then sent to the mobile station along with the new CAI parameter set. This new CAI is the same as the effective CAI parameter set in the MS but the e4 parameter is set to the number of received pulses during the 10 second interval. Though this is seen as a tariff change at the MS side, only one SS CDR is generated if no tariff changes occur during the call. The total received pulses are shown as an additional charge in the e4 parameter of the SS CDR. The interval of flushing the pulse buffer is an exchange-specific parameter (1:64) which can be changed from zero (immediate tariff change after charging message receival) to FF00H with the WOC command. The parameter value FF00H disables the transmission of the received pulses to the MS. Other types of charging messages also have their effects on the AOC. The implementation can be found in Feature 698: Charging Based on Parameters from Network.
13.1
AOC-I, AOC-C
No pulses received from the outgoing circuit are currently sent to the AOC subscribers. Pulses are stored in the MOC and the FORW CDRs, and the CAI elements sent to the mobile station are stored in the SS CDR. In the case of AOC-C it is important that the CAI elements are stored for the billing centre. This way the charging of a mobile subscriber and the owner of the mobile station can be the same. If SCP (Camel) (see Feature 994: CAMEL) has given e-parameters for the call, these override all the existing (MSC, SCP (Core Inap)) parameters for the rest of the call. This means that the SCP must give appropriate parameters for different situations (if parameters are given for the announcement, ones must be given for the actual call too).
72 (93)
DN00133192 Issue 8-0 en
13.2
AOC-E, AOC-D
The Feature 694: Primary Rate Access Supplementary Services Enhancements supports the AOC-E (see Feature 747: Mobile Accounting and Integrated Services Digital Network (ISDN); Advice Of Charge: charging information at the end of the call (AOC-E) supplementary service. Service description) which is advice of charge sent after the speech state of the call and AOC-D (see Feature 694: Primary Rate Access Supplementary Services Enhancements), which is advice of charge sent during the call. This means that for a call coming from the PBX, an AOC-E/ D automaton is started and pulses are generated to the automaton pulse counters. In AOC-D, an exchange-specific parameter (001:0023) defines the time interval after which the currently collected pulses subtracted by already reported pulses are compared to the parameter (001:0022), and if the current value is greater, MSC/MSS sends the pulses generated since the beginning of the call to the PBX. When the call is cleared, the MSC/MSS sends all the pulses generated during the call to the PBX. The pulses to be sent to the PBX are generated with the MCZ of the analysis for the number received from the PBX. If the pulses are received from the outgoing circuit, these pulses are added to the advice of charge and the incoming and the outgoing accounting data. When the call is cleared, the MSC/MSS sends the pulses to the PBX. The AOC-E/D pulses are always gathered for the whole call; therefore, intermediate charging does not reset the pulse counter. If the defined IAZ deviates from zero, the AOC-D/E pulses are stored in the PBXO CDR. The incoming accounting counters are updated normally with the incoming accounting data of the call.
Note
In order to have the same number of pulses in the accounting counters which are sent as AOC-E/D pulses, either the charging zone numbers of the IAZ and the MCZ, or the parameters of the IAZ and the MCZ must be the same.
DN00133192 Issue 8-0 en
73 (93)
74 (93)
DN00133192 Issue 8-0 en
Appendix A
A.1
Call case: PSTN-MS

In this section, examples of the basic commands are presented for a PSTN to a mobile station call case. In order to have different accounting parameters for weekdays and weekends, day classes are defined. Each day has a default day class at the MSC/MSS startup, so the day classes can only be changed as follows:
< ZGDM:SAT&SUN,1,2,1,1; LOADING PROGRAM VERSION 1.18-0 EXECUTION STARTED CONFIRM COMMAND EXECUTION: Y/N ? Y COMMAND EXECUTED DAY CLASSES HANDLING COMMAND <GD_> < ZGDI; LOADING PROGRAM VERSION 1.18-0 EXECUTION STARTED DX 200 DX220-LAB 1997-04-15 10:00:03
MON TUE WED THU FRI SAT SUN
... ... ... ... ... ... ...
DAY CLASSES OF DAY CLASS GROUPS: GROUP 1 GROUP 2 GROUP 3 GROUP 4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 1 1 2 1 1
SPECIAL DAYS: GROUP 1 GROUP 2 1997-10-20 ... 1 4 COMMAND EXECUTED
GROUP 3 1
GROUP 4 1
The first day class group is reserved for accounting purposes in this example. The charge rate is the same every day. Change group 2 is used with the main charging zones for non-accounting purposes. For PSTNoriginated calls, the MCZ can in some cases be used for sending pulses to the incoming circuit. The operator can choose the way the day class groups are used. To have different charging parameters during busy hours, change group number 10 is defined:
DN00133192 Issue 8-0 en
75 (93)
< ZGGC:1,10,8-00&17-00,1&2&1; LOADING PROGRAM VERSION 1.16-0 CONFIRM COMMAND EXECUTION: Y/N ? CHANGE GROUP CREATED DAY CLASS: 1
CHANGE GROUP: 00010
CHANGE TIMES AND CHARGE RATE INDEXES: 00:00 - 08:00 - 12:00 - 24:00 1 2 1 COMMAND EXECUTED
Note
Because the change group is defined for one day class, it is necessary to have the change group defined for each day class. They are defined with the day class and special days MML commands (Change Groups Handling (GG) command group). If there is a change group missing for one day class, the creation of charging zone that uses the change group fails.
After this the charging zones are defined for the use of the incoming accounting and main charging (in this case for sending pulses to the incoming circuit). Only the definition of the IAZ is presented in this example (day class group 2 is used for the MCZ):
Note
If the change group for the charging zone to be created is not defined for the current day class, the creation of the charging zone fails.
< ZGNC:1005,SYNC,10,1:R1=1-2.5,PLT1=40,FT1=5,R2=1-5,PLT2=40,FT2=5; EXECUTION STARTED CONFIRM COMMAND EXECUTION: Y/N ? Y CHARGING ZONE CREATED E-PARAMETERS: E1 (RPLT), E2 (RATE), E4 (PLT), E7 (FT) NUMBER METHOD CHNGR DCGR RATE1-RPLT1 PLT1 FT1 1.0-2.5 40.0 5.0 RATE2-RPLT2 PLT2 FT2 1.0-5.0 40.0 5.0 RATE3-RPLT3 PLT3 FT3 0.0-0.0 0.0 0.0 RATE4-RPLT4 PLT4 FT4 0.0-0.0 0.0 0.0
1005
SYNC
10
COMMAND EXECUTED
76 (93)
DN00133192 Issue 8-0 en
For the call case in question a charging case named PSTNMS is created. The charging parameters are set in such a way that pulses can be sent to the incoming circuit. For this purpose the definition of the charging zone number 5 (MCZ) must be identical to the one number 1005 (IAZ). Note that the HC parameter cannot be set here. It must be changed with the RMG command. In this case the HC has no meaning and it is not set. To enable the updating of circuit and circuit group counters, the ICCON parameter is defined to include one half of the counter space, the other half is left for the outgoing counters. The outgoing counters are not updated in this example. The PT parameter has no meaning in the GSM.
/* GIVE CHARGING DATA: PARAMETER NAMES: CP .... CHARGING POINT OBLIGATORY MCZ ... MAIN CHARGING ZONE ACZ ... ADDITIONAL CHARGING ZONE IAC ... INCOMING ACCOUNTING ZONE OAC ... OUTGOING ACCOUNTING ZONE TCI ... INTERRUPTION OF TIME CHARGING FOR B ONHOOK TIME OCCON.. COUNTERS SET ON OUTGOING CIRCUIT ICCON.. COUNTERS SET ON INCOMING CIRCUIT PT .... PULSE TRAIN */ <ZRDE:NCHA=PSTNMS:CP=IC,TCI=Y,MCZ=101,IAC=1005,ICCON=1&&4,OCCON=5&&8; COMMAND EXECUTED
In order to have special charging for a call from the circuit group coming from the PSTN, make sure that the charging origin and the analysis tree are correctly set in the circuit group.
ZRCM:NCGR=SORI,TREE=70,CORG=6; CONFIRM COMMAND EXECUTION: Y/N ? Y DX 200 PISPALAMSC CIRCUIT GROUP MODIFIED NCGR = SORI NEW ANALYSIS TREE: 70 NEW CHARGING ORIGIN: 6 COMMAND EXECUTED
1997-04-15
10:00:05
More subdestinations can be attached to this charging case with the RDG command. With these definitions the summation and the zone counters are updated with the pulses generated with the IAZ automaton and with the pulses sent to the incoming circuit with the MCZ. Also, the call time and the answered calls in these counters are updated normally.
DN00133192 Issue 8-0 en
77 (93)
The charging case is now linked to digits/tree/charging origin:

<ZRDG:DIG=38558,TREE=70,CORG=6:NCHA=PSTNMS; LOADING PROGRAM VERSION 1.69-0 DIGIT ANALYSIS: ALT = 0 TREE = 70 DIG = 38558 CASE ADDED COMMAND EXECUTED
The charging case that was added can now be checked with the RIA command:
<ZRIA:DIG=38558,TREE=70; DX 200 PISPALAMSC 1997-04-15 10:00:08
DIG = 38558 FIRST ANALYSIS TREE: 70
STATE: ENDS
FOLLOWING DIGITS:
ALT = 0 NAME OF DESTINATION : NAME OF SUBDESTINATION : NBR 2 DTYPE A : 31
00042 HLRENQ RT SPR CT IC SCT SRCL N SP 9 TS 0 NL 32 AR CNT QA N RC APR PC ORD CNP N
ROUTING DATA
ADDITIONAL DATA CHARGING INDEX
DSTATE A
CHARGING ORIGIN: 6 CHA: 22 CP IC MCZ 101 ACZ 0 IAZ 1005 OAZ 0
NAME OF CHARGING CASE: PSTNMS DC NDC ICC SPM SPA TCI NCB PT HC N N Y N 0 CI 111100000000 OCC 000011110000
COMMAND EXECUTED
The result of the analysis is HLR enquiry. The resulting roaming number (assuming that the roaming numbers begin with 39000) is analysed with the tree and the charging origin received from the EOS analysis, which is executed according to the DX cause of the HLR enquiry. The associated analysis tree and charging origin are defined in the EOS analysis for the cause code 1009H:
78 (93)
DN00133192 Issue 8-0 en
ZRXI:RESGR=0,CAUSE=1009; DX 200 DX220-LAB 1999-09-27 12:22:55 END OF SELECTION ANALYSIS INTERROGATION RESULTS RESGR=0 CAUSE=00001009 NODE INFO=NOT SPECIFIED RESULT IDENTIFIER : CM ANALYSIS TREE : CHARGING ORIGIN : NOTIFICATION INFO : TIMESLOT OF TONE : ANNOUNCEMENT NUMBER : ANNOUNCEMENT CHARGING: FORWARD RELEASE INFO : NEW DX CAUSE CODE : IN DETECTION POINT : COMMAND EXECUTED EXECUTE CM ANALYSIS 50 0 NOT SPECIFIED NOT SPECIFIED NOT SPECIFIED NOT SPECIFIED NOT SPECIFIED NOT SPECIFIED NOT SPECIFIED
The analysis of the roaming number for tree 50 and the charging origin 0 is defined to use the MCZ number 501. The MCZ describes the air time charge of subscriber B and it is meaningful when subscriber B has the Advice of Charge active, or the charging of subscriber B is controlled by the SCP.
<ZGNC:501,SYNC,10,1:R1=60-1,R2=0-0; <ZRDE:NCHA=TOMS:CP=OE,TCI=Y,MCZ=501,IAC=0; <ZRDG:DIG=39000,TREE=50,CORG=0:NCHA=TOMS;
To enable the updating of the circuit group and the circuit counters (CSUMET, CIRMET), the counter types for each counter must be defined. The counters to be used are already defined in the charging case.
/* GIVE COUNTER TYPE AP TP DP BP UP UT CT RE SP PB UK AF AB NO .... .... .... .... .... .... .... .... .... .... .... .... .... .... ALL METERING PULSES TRANSFERRED PULSES DEVELOPED PULSES PULSE TRAIN/BASIC PULSE UNSENT PULSES UNTRANSFERRED PULSES CALL TIME REPLY PULSES SENT TO INCOMING CIRCUIT PULSES BEFORE ANSWERED UNPOINTED PULSES PULSES AFTER A CLEARED PULSES AFTER B CLEARED NO CIRCUIT CHARGING COUNTING */
ZGRM:NCGR=PSTN1,MODE=BOTH:CTR1=AP,CTR2=UK,CTR3=CT,CTR4=RE, CTR5=AP,CTR6=UP,CTR7=CT, CTR8=RE; COMMAND EXECUTED
DN00133192 Issue 8-0 en
79 (93)
After the first test call from the PSTN to the MS, the output of the accounting counters looks like this. The test call is made on Sunday, at 10:00 a.m. (Feature 747: Mobile Accounting is enabled): TOTMET & CIGMET (Monitoring Summation Counters)
< ZGOX; DX200 MSCPISPALA 1997-04-15 10:12:30 STATISTIC SUM-COUNTERS OF THE EXCHANGE AND CIRCUIT GROUPS TOTAL METERING PULSES 0000000240 UNPOINTED PULSES 0000000000 ALL PSTN TERM CALLS 0000000000 OWN TERM TALK TIME 0000000000 ALL VPS ORIG CALLS 0000000000 DEVICE ORIG TALK TIME 0000000000 NCGR
TOLL METERING PULSES 0000000240 ALL ANSWERED CALLS 0000000001 PSTN TERM TALK TIME 0000000000 ALL MOBILE ORIG CALLS 0000000000 VPS ORIG TALK TIME 0000000000 ALL MOBILE TO MOBILE CALLS 0000000000 METERING PULSES INCOMING TALK TIME
GENERATED PULSES 0000000000 TALK TIME (SEC) 0000000045 ALL OWN ORIG CALLS 0000000000 MOBILE ORIG TALK TIME 0000000000 ALL VPS TERM CALLS 0000000000
RECEIVED PULSES 0000000000 ALL PSTN ORIG CALLS 0000000001 OWN ORIG TALK TIME 0000000000 ALL MOBILE TERM CALLS 0000000001 VPS TERM TALK TIME 0000000000
REMINDER PULSES 000000000 PSTN ORIG TALK TIME 0000000045 ALL OWN TERM CALLS 0000000000 MOBILE TERM TALK TIME 0000000045 ALL DEVICE ORIG CALLS 0000000000
MOBILE TO MOBILE TALK TIME 0000000000 RECEIVED PULSES OUTGOING TALK TIME 0000000000 0000000000 0000000000 0000000000 ALL IN ANSWER CALLS ALL ANSWERED TOLL CALLS 0000000001 0000000000 0000000000 0000000000
TOLL METERING PULSES ALL OUT ANSWER CALLS 0000000240 0000000000 0000000000 0000000000
SORI
0000000240 0000000045 0000000000 0000000000
VSA11
COMMAND EXECUTED
CIRMET (Trunk Circuit Counters)

< ZGOC:76-29&&-31; LOADING PROGRAM VERSION 1.34-0 DX 200 PISPALAMSC COUNTERS OF CIRCUITS
1997-04-15
10:12:40
80 (93)
DN00133192 Issue 8-0 en
PCM-TSL 76-29 76-30 76-31
CTR 1 CTR 7 000000000 000000000 000000240 000000000 000000000 000000000
CTR 2 CTR 3 CTR 4 CTR 5 CTR 6 CTR 8 000000000 000000000 000000000 000000000 000000000 000000000 000000000 000000045 000000001 000000000 000000000 000000000 000000000 000000000 000000000 000000000 000000000 000000000
COMMAND EXECUTED
CSUMET (Trunk Circuit Counters by Circuit Groups)

< ZGOG:SORI; LOADING PROGRAM VERSION 1.34-0 DX 200 PISPALAMSC COUNTERS OF CIRCUIT GROUPS NCGR SORI
1997-04-15
10:12:52
CTR 1 CTR 2 CTR 3 CTR 4 CTR 5 CTR 6 CTR 7 CTR 8 000000240 000000000 000000045 000000001 000000000 000000000 000000000 000000000
COMMAND EXECUTED
ZONMET
< ZGOT:1005&501; LOADING PROGRAM VERSION 1.34-0 DX 200 PISPALAMSC 1997-04-15 STATISTIC COUNTERS OF CHARGING ZONES CHARGING ZONE 1005 1005 1005 1005 501 501 501 501 CHARGE RATE 1 2 3 4 1 2 3 4 METERING PULSES 0000000000 0000000240 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 ANSWERED CALLS 0000000000 0000000001 0000000000 0000000000 0000000000 0000000001 0000000000 0000000000
10:13:02
TALK TIME (SEC) 0000000000 0000000045 0000000000 0000000000 0000000000 0000000045 0000000000 0000000000
ANSWERED FREE CALLS 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000
FREE TALK TIME 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000
COMMAND EXECUTED
DN00133192 Issue 8-0 en
81 (93)
A.2
Call Case: MS-PSTN

In this section the definitions and the counter update examples are shown shortly for a PSTN-terminating call. The definitions are partially the same as in the PSTN-MS call case. See the explanations for MML commands in the Appendix Call case: PSTN-MS.
< ZGDM:SAT&SUN,1,2,1,1; LOADING PROGRAM VERSION 1.18-0 EXECUTION STARTED CONFIRM COMMAND EXECUTION: Y/N ? COMMAND EXECUTED DAY CLASSES HANDLING COMMAND <GD_> < ZGDI; LOADING PROGRAM VERSION 1.18-0 EXECUTION STARTED DX 200 DX220-LAB 1997-04-15 13:51:17
MON TUE WED THU FRI SAT SUN
... ... ... ... ... ... ...
DAY CLASSES OF DAY CLASS GROUPS: GROUP 1 GROUP 2 GROUP 3 GROUP 4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 1 1 2 1 1
SPECIAL DAYS: GROUP 1 GROUP 2 1997-10-20 ... 1 4 COMMAND EXECUTED
GROUP 3 1
GROUP 4 1
The day class group number 2 is reserved for the MCZ, in this case for the AOC. Change groups are created for all the day classes that have been defined. Only one example is shown here: ZGGC:1,10,8-00&17-00,1&2&1;
LOADING PROGRAM VERSION 1.16-0 CONFIRM COMMAND EXECUTION: Y/N ? CHANGE GROUP CREATED
DAY CLASS: 1 CHANGE GROUP: 00010 CHANGE TIMES AND CHARGE RATE INDEXES: 00:00 - 08:00 - 12:00 - 24:00 1 2 1 COMMAND EXECUTED
82 (93)
DN00133192 Issue 8-0 en
After this the charging zones are defined for the use of the outgoing accounting. The definition for the MCZ is not necessary. The only use for the MCZ is that it provides the parameters for the AOC for a mobile subscriber. If the AOC for subscriber A is supported, check that parameter e3 is set correctly (non-zero value). This can be checked with the MXP MML command and changed with the MXN command. Only the definition of the OAZ is presented in this example: ZGNC:2005,SYNC,10,1:R1=1-2.5,PLT1=40,FT1=5,R2=1-5, PLT2=40,FT2=5;
EXECUTION STARTED CONFIRM COMMAND EXECUTION: Y/N ? Y CHARGING ZONE CREATED E-PARAMETERS: E1 (RPLT), E2 (RATE), NUMBER METHOD CHNGR DCGR RATE1-RPLT1 PLT1 FT1 1.0-2.5 40.0 5.0
E4 (PLT),
E7 (FT) RATE3-RPLT3 PLT3 FT3 0.0-0.0 0.0 0.0 RATE4-RPLT4 PLT4 FT4 0.0-0.0 0.0 0.0
2005
SYNC
10
RATE2-RPLT2 PLT2 FT2 1.0-5.0 40.0 5.0
COMMAND EXECUTED
Similar definitions are also made for zones 2006, 201 and 202. In order to store the pulses received from the PSTN, a charging point must be set to the outgoing circuit (OC). In this case it is not wanted that pulses are transferred to the incoming circuit, so the HC parameter is set to NCI. ZRDE:NCHA=MSPSTN:CP=OC,TCI=Y,OAC=2005,MCZ=201, ICCON=1&&4,OCCON=5&&8; ZRDE:NCHA=MSPSTN0:CP=OC,TCI=Y,OAC=2006,MCZ=202, ICCON=1&&4,OCCON=5&&8; First assign the route to a subdestination and then the subdestination to a destination. In the second and third MML commands the charging cases are also assigned to the destination: ZRDE:NSDEST=PSTN2:ROU=444,SP=2,CT=NGC; ZRDE:NDEST=PSTN2,ALT=0:NSDEST=PSTN2:CORG=0, NCHA=MSPSTN0; ZRDE:NDEST=PSTN2,ALT=0:NSDEST=PSTN2:CORG=3, NCHA=MSPSTN;
DN00133192 Issue 8-0 en
83 (93)
The mobile-originated call always uses tree number 2 if the charging attribute analysis is not used. The base value of the tree is defined in the UTPFIL file. The charging origin that is used is received from the origin analysis in this case. The existing origin analysis is defined so that in one special case the charging origin number three (3) is received as a result.
RVM:ORD,1,3:3; DX 200 SORI-MSC 1997-04-15 10:04:05 ORIGIN ANALYSIS RESULT MODIFICATION SUBSCRIBER CATEGORY=ORDINARY CELL TARIFF=1 MS CLASSMARK=3 OLD RESULT ---------: CONTINUE CALL SETUP NEW RESULT ---------CONTINUE CALL SETUP 3
RESULT IDENTIFIER
CHARGING ORIGIN : 0 CONFIRM COMMAND EXECUTION: Y/N ? Y COMMAND EXECUTION STARTED -- PLEASE WAIT COMMAND EXECUTED AND FUNCTION STARTED
In the digit analysis, the tree, the charging origin, the digits and the destination are linked together. ZRDG:DIG=50120,TREE=2:NDEST=PSTN2;
LOADING PROGRAM VERSION 1.69-0 DIGIT ANALYSIS: ALT = 0 TREE = 2 DIG = 50120 CASE ADDED COMMAND EXECUTED
The analysis which was created can be checked with the RIA command. ZRIA:DIG=50120,TREE=2;
DX 200 PISPALAMSC 1997-04-15 10:05:08
DIG = 50120 FIRST ANALYSIS TREE: 2
STATE: ENDS
FOLLOWING DIGITS:
ALT = 0 NAME OF DESTINATION : 00042 NAME OF SUBDESTINATION : PSTN2 NBR RT CT ROUTING DATA 2 SPR IC DTYPE A DSTATE A
SCT SRCL N
SP 9 TS 0
NL 32 AR -
CNT QA N RC APR PC ORD CNP N
ADDITIONAL DATA
84 (93)
DN00133192 Issue 8-0 en
CHARGING INDEX
: 32
CHARGING ORIGIN: 0 CHA: 23 CP OC MCZ 202 ACZ 0 IAZ 0 OAZ 2006
NAME OF CHARGING CASE: MSPSTN0 DC NDC ICC SPM SPA TCI NCB PT HC N N Y N 0 NCI 111100000000 OCC 000011110000 : 32
CHARGING INDEX
CHARGING ORIGIN: 3 CHA: 24 CP OC MCZ 201 ACZ 0 IAZ 0 OAZ 2005
NAME OF CHARGING CASE: MSPSTN DC NDC ICC SPM SPA TCI NCB PT HC N N Y N 0 NCI 111100000000 OCC 000011110000
COMMAND EXECUTED
According to these definitions, the summation and the zone counters are updated with the pulses generated with the OAZ automaton. If pulses are received from the outgoing circuit, these pulses are added to the received pulses counters. The call time and the answered calls of these counters are also updated normally. To enable the updating of the circuit group and the circuit counters (CSUMET, CIRMET), the counter types for each counter must be defined. The counters to be used are already defined in the charging case. Received pulses are gathered to counter number 5.
ZGRM:NCGR=SORI,MODE=BOTH:CTR5=AP,CTR6=UT,CTR7=CT,CTR8=RE; COMMAND EXECUTED
After the first test call from the MS to the PSTN, the output of the accounting counter output is as below. A total of 40 metering pulses are received from the outgoing circuit. TOTMET & CIGMET (Monitoring Summation Counters)
< ZGOX; DX200 MSCPISPALA 1997-04-15 10:12:30 STATISTIC SUM-COUNTERS OF THE EXCHANGE AND CIRCUIT GROUPS TOTAL METERING PULSES 0000000280 UNPOINTED PULSES 0000000000 ALL PSTN
TOLL METERING PULSES 0000000000 ALL ANSWERED CALLS 0000000001 PSTN TERM
GENERATED PULSES 0000000000 TALK TIME (SEC) 0000000045 ALL OWN
RECEIVED PULSES 0000000280 ALL PSTN ORIG CALLS 0000000000 OWN ORIG
REMINDER PULSES 000000000 PSTN ORIG TALK TIME 0000000000 ALL OWN
DN00133192 Issue 8-0 en
85 (93)
TERM CALLS 0000000001 OWN TERM TALK TIME 0000000000 ALL VPS ORIG CALLS 0000000000 DEVICE ORIG TALK TIME 0000000000 NCGR
TALK TIME 0000000045 ALL MOBILE ORIG CALLS 0000000001 VPS ORIG TALK TIME 0000000000 ALL MOBILE TO MOBILE CALLS 0000000000 METERING PULSES INCOMING TALK TIME
ORIG CALLS 0000000000 MOBILE ORIG TALK TIME 0000000045 ALL VPS TERM CALLS 0000000000
TALK TIME 0000000000 ALL MOBILE TERM CALLS 0000000000 VPS TERM TALK TIME 0000000000
TERM CALLS 0000000000 MOBILE TERM TALK TIME 0000000000 ALL DEVICE ORIG CALLS 0000000000
MOBILE TO MOBILE TALK TIME 0000000000 RECEIVED PULSES OUTGOING TALK TIME 0000000280 0000000045 0000000000 0000000000 ALL IN ANSWER CALLS ALL ANSWERED TOLL CALLS 0000000000 0000000000 0000000000 0000000000
TOLL METERING PULSES ALL OUT ANSWER CALLS 0000000000 0000000001 0000000000 0000000000
SORI
0000000280 0000000000 0000000000 0000000000
VSA11
COMMAND EXECUTED
CIRMET (Trunk Circuit Counters)

< ZGOC:76-29&&-31; LOADING PROGRAM VERSION 1.34-0 DX 200 PISPALAMSC COUNTERS OF CIRCUITS PCM-TSL CTR 1 CTR 7 000000000 000000000 000000000 000000045 000000000 000000000 CTR 2 CTR 8
1997-04-15
10:12:40
CTR 3
CTR 4
CTR 5
CTR 6
76-29 76-30 76-31
000000000 000000000 000000000 000000000 000000000 000000000 000000000 000000000 000000000 000000280 000000000 000000001 000000000 000000000 000000000 000000000 000000000 000000000
COMMAND EXECUTED
CSUMET (Trunk Circuit Counters by Circuit Groups )

< ZGOG:SORI; LOADING PROGRAM VERSION 1.34-0 DX 200 PISPALAMSC COUNTERS OF CIRCUIT GROUPS
1997-04-15
10:12:52
86 (93)
DN00133192 Issue 8-0 en
NCGR SORI
CTR 1 CTR 2 CTR 3 CTR 4 CTR 5 CTR 6 CTR 7 CTR 8 000000000 000000000 000000000 000000001 000000280 000000000 000000045 000000001
COMMAND EXECUTED
ZONMET
< ZGOT:2005&201; LOADING PROGRAM VERSION 1.34-0 DX 200 PISPALAMSC 1997-04-15 STATISTIC COUNTERS OF CHARGING ZONES CHARGING ZONE 2005 2005 2005 2005 201 201 201 201 CHARGE RATE 1 2 3 4 1 2 3 4 METERING PULSES 0000000000 0000000240 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 ANSWERED CALLS 0000000000 0000000001 0000000000 0000000000 0000000000 0000000001 0000000000 0000000000
10:13:02
TALK TIME (SEC) 0000000000 0000000045 0000000000 0000000000 0000000000 0000000045 0000000000 0000000000
ANSWERED FREE CALLS 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000
FREE TALK TIME 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000
COMMAND EXECUTED
A.3
Accounting data transfer using FTAM

A local network address is defined for the transfer (an existing network address can also be used): ZQBC:MSCACC,L; A local OSI application is created for the transfer: ZQDL:ACCOUNTING:0:UNL:OMU:VFS:MSCACC:0201:0201:0201; The FTAM attributes of the ZONMET, a read password, a read attributes password and an owner ID are set: ZQFM:ACCOUNTING,"MM1_7_10_0/LFILES/ZONMETGX.IMG",BIN: REA=YES,REAP="PASSWORD",RAT=YES,RATP="PASSWORD", OID=""; The OID="" means that the owner identity is not checked by the DX 200. The passwords "PASSWORD" means that the password is not checked by the DX 200. Use these values if the Feature 265: FTAM Security is active.
DN00133192 Issue 8-0 en
87 (93)
Feature 265: FTAM Security checks the user name and the passwords when the connection is made. There is no need to recheck when the file is actually read from disk. You might have difficulties in using both of these checkings, as the owner ID/user ID must be 8 characters long and in the FTAM security the maximum is 6 characters.
Note
The post-processing system should not read the file during the update. Check the output of the GCO for characteristics. The GCF command should not be used during the reading of the ZONMET by FTAM either.
88 (93)
DN00133192 Issue 8-0 en
Glossary
Glossary
AOC AOC-C AOC-I AOC-D AOC-E ATM BICC CM CRG CS ENC EOS IAZ IN IP MCZ MGW MPM MSS OAZ RNC SCP Advice of Charge AOC - charging AOC - information AOC during the call AOC at the end of the call Asynchronous Transfer Mode Bearer Independent Call Control Central Memory Charging Information Message Circuit Switched Event Notification Charging End of Selection Incoming Accounting Zone Intelligent Network Internet Protocol Main Charging Zone Multimedia Gateway Metering Pulse Message MSC Server Outgoing Accounting Zone Request Notification Charging Service Control Point
DN00133192 Issue 8-0 en
89 (93)
SIP SSP TDM UPD UPDR VPS
Session Initiation Protocol Service Switching Point Time Division Multiplex User Plane Destination User Plane Destination Reference (Control Plane) Voice Processing System
90 (93)
DN00133192 Issue 8-0 en
Glossary
DN00133192 Issue 8-0 en
91 (93)
References
1. 2. 3. Binary Formats of Charging: Counters, References. CDR Field Description, Interface Specification. European digital telecommunications system (Phase 2); Description of Charge Advice Information (CAI), GSM 02.24, pr ETS 300 510.. Feature 265: FTAM Security, Feature Description. Feature 446: MSC-MSC Handover Accounting, Feature Activation Manual. Feature 469: Accounting Improvement, Feature Description. Feature 641: Charging Capacity, Feature Description. Feature 646: Advanced Accounting Data Transfer, Feature Description. Feature 694: Primary Rate Access Supplementary Services Enhancements, Feature Activation Manual. Feature 698: Charging Based on Parameters from Network, Feature Description. Feature 703: On-line Call Monitoring, Feature Description. Feature 739: CS-1 Continuation, Feature Description. Feature 747: Mobile Accounting, Feature Description. Feature 774: High Speed Circuit Switched Data, Feature Description. Feature 927: Improvements of Inter MSC Handover Architecture, Feature Description. Feature 994: CAMEL, Feature Description. Feature 1093: Advanced Call Drop Back for VMS Interface, Feature Description. Feature 1168: Multiple PLMN and Inter-PLMN Handover Support in MSC, Feature Description.
4. 5.
6. 7. 8.
9.
10.
11. 12. 13. 14.
15.
16. 17.
18.
92 (93)
DN00133192 Issue 8-0 en
References
19. 20.
Features 1196 and 1197: CAMEL Phase 4, Feature Description. Feature 1260: Inter-system handover and UMTS changes in MSC, Feature Description. Feature 1265: CS Data User Plane Protocol Support for UMTS, Feature Description. Feature 1417: Charging in MSS, Feature Description. Generation and Contents of CDRs in Different Call Cases, Interface Specification. Integrated Services Digital Network (ISDN); Advice Of Charge: charging information at the end of the call (AOC-E) supplementary service. Service description. ETS 300 180.. MSC/HLR-BC Customer-specific Part, Interface Specification. S.A. Karlsson: General Principles Of Charging And Their Adaptation To a Global Network, Research Institute Of the Helsinki Telephone Company, Helsinki Finland, 1966. Storing and Transfer of Charging Data, Interface Specification.
21.
22. 23.
24.
25. 26.
27.
DN00133192 Issue 8-0 en
93 (93)

Mss

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Mss

Diunggah oleh

Hak Cipta:

Format Tersedia

MSCDOCM14PDFCD MSC/HLR, Rel. M14.1, Product Documentation, v.

Accounting in MSC / MSS

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

# Nokia Siemens Networks

DN00133192 Issue 8-0 en

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

# Nokia Siemens Networks

DN00133192 Issue 8-0 en

Structure of ATM/IP counters

Table 10. Structure of SIP/BICC counters

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

Pulse generation in MSC/MSS

Pulse generation in Karlsson charging Pulse handling in AOC 31 37

Non-integer pulse handling

Figure 10. Accounting counters

Figure 11. Inter-MSC handover accounting

# Nokia Siemens Networks

DN00133192 Issue 8-0 en

New cause codes have been added to intermediate charging.

Changes made between issues 62 and 61

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

# Nokia Siemens Networks

DN00133192 Issue 8-0 en

About this document

About this document

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

Structure of this document

# Nokia Siemens Networks

DN00133192 Issue 8-0 en

About this document

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

# Nokia Siemens Networks

DN00133192 Issue 8-0 en

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

# Nokia Siemens Networks

DN00133192 Issue 8-0 en

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

# Nokia Siemens Networks

DN00133192 Issue 8-0 en

Use of charging analysis parameters

Use of charging analysis parameters

Different charging zones in three call cases

DN00133192 Issue 8-0 en

# Nokia Siemens Networks

Accounting in MSC / MSS

Control of charging messages