How To Account in MSC BSC

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

v.1
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
About this document 9

Scope of application 9
Structure of this document
Introduction to accounting
Interface modifications 15
4
4.1
4.2
4.2.1
4.2.2
4.2.3
Use of charging analysis parameters 17

Control of charging messages 18
Control parameters of accounting counters 19
NCB 20
TCI 20
ICC, OCC 20
5
5.1
Analyses 21
Handling of analyses 24
6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
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
7
7.1
7.2
Accounting counters in MSC 39

Handling of accounting counters 47
Mobile accounting 47
8
8.1
8.1.1
8.1.1.1
8.1.1.2
Accounting counters in MSS 49

Binary formats 51
Data block header 52
Header structure 52
Description of header fields 52
DN00133192
Issue 8-0 en
10
13
3 (93)
8.1.2
8.1.2.1
8.1.2.2
8.1.2.3
8.2
Record formats 55
General overview 55
ATM/IP counters 55
SIP/BICC counters 57
Handling of counters 59
Inter-MSC handover 61
10
10.1
10.2
Accounting counter backup 63

Handling counter backup 64
Differences in counters of CHU-1 and CHU-2
11
11.1
11.2
Transferring accounting data via FTAM 67

Advanced accounting data transfer 67
Charging capacity 68
12
Using CDRs for accounting purposes 69
13
13.1
13.2
Accounting parameters used in Advice of Charge 71

AOC-I, AOC-C 72
AOC-E, AOC-D 73
Appendix
A.1
A.2
A.3
A
75
Call case: PSTN-MS 75
Call Case: MS-PSTN 82
Accounting data transfer using FTAM
64
87
Glossary 89
References 92
4 (93)
DN00133192
Issue 8-0 en
List of tables
List of tables
Table 1.
HC/CP combinations and their effects on charging message transfer 18
Table 2.
MML commands for analysis and charging
Table 3.
MML commands for counter output
Table 4.
ATM accounting counter
Table 5.
IP accounting counter
Table 6.
SIP accounting counter
Table 7.
BICC accounting counter
Table 8.
Structure of header
Table 9.
Structure of ATM/IP counters
24
47
49
50
51
51
52
55
Table 10. Structure of SIP/BICC counters
57
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
DN00133192
Issue 8-0 en
59
69
5 (93)
List of figures
Figure 1.
Different charging zones in three call cases
Figure 2.
The analysis sequence in MSC/MSS
Figure 3.
Tariff change structure
Figure 4.
Pulse generation in MSC/MSS
Figure 5.
Pulse generation in Karlsson charging
Figure 6.
Pulse handling in AOC
Figure 7.
Non-integer pulse handling
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. 44
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. 45
Figure 10. Accounting counters
22
29
30
31
31
37
46
Figure 11. Inter-MSC handover accounting
6 (93)
17
61
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
About this document

This document provides information about accounting and the use of
counters in the DX 200.
1.1
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
10 (93)
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.
DN00133192
Issue 8-0 en
About this document
DN00133192
Issue 8-0 en
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.
11 (93)
12 (93)
DN00133192
Issue 8-0 en
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
IAZ
MCZ
PSTN -> MS
PSTN -> MSC -> MSC -> MS
Figure 1.
DN00133192
Issue 8-0 en
Different charging zones in three call cases
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/CP combinations and their effects on charging message transfer
HC
CP
Action
ACI, NCI, CI
IC, OE
No transfer of charging messages. No storing.
18 (93)
DN00133192
Issue 8-0 en
Table 1.
HC/CP combinations and their effects on charging message transfer

(cont.)
HC
CP
Action
CI, ACI
OC, OCI
Charging message transfer and storing
NCI
OC, OCI
No transfer of charging message. The pulses are

stored in accounting counters.
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
Routing & charging

attribute analysis
Digit
analysis
Priority
analysis
Origin
analysis
Charging origin
Reason
code
EOS
analysis
Reason code
or facility code
Figure 2.
EOS attribute
analysis
Function
analysis
Charging index
Charging
analysis
Call barring
analysis
Bc to prefix
analysis
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.
Calling party category. Acquired from the VLR. Values: normal, pay
phone, test or priority call.
2.
Cell tariff. Base station-dependent information (located in the

CDAFIL). There are four different tariffs.
3.
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.
MML commands for analysis and charging
Action
Command
Output the analysis data of an analysis tree
RII
Output the analysis data of an analysis tree & dialled digits
RIA
24 (93)
DN00133192
Issue 8-0 en
Analyses
Table 2.
MML commands for analysis and charging (cont.)
Action
Command
Output the data of an analysis component
RIL
Create EOS analysis
RXC
Modify charging analysis
RMG
Create charging zone
GNC
Create change group
GGC
Modify day classes
GDM
Create origin analysis
RVC
Create analysis component
RDE
Add charging case
RDG
Create subanalysis
RQC
Create charging result
RQJ
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
DCG 4
Mon
Tue
Sun
Cur
.
.
.
Day classes
Day class 3:
Change groups
Day class 2:
1: (0:00-8:00-17:00-21:00-24:00)
2
Charge rate index
1: (0:00-10:00-18:00-24:00)
3: (0:00-7:00-16:00-21:00-24:00)
1
Charging zone
1: tariff, tariff, tariff, tariff
2: tariff, tariff, tariff
chgr:1
chgr:1
day class gr. 3
day class gr. 4
3: tariff, tariff, tariff, tariff

chgr:3
Figure 3.
6.1
day class gr. 3
Tariff change structure
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
...
PLT
RPLT
RPLT
RPLT
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
...
PLT
Figure 6.
DN00133192
Issue 8-0 en
RPLT
RPLT
RPLT
Pulse handling in AOC
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:
DN00133192
Issue 8-0 en
1.
Expiration of the intermediate charging timer. This timer is set in the

beginning of the call to value CALL_TIME_LIMIT (parameter 1:4).
2.
Some of the pulse counters have exceeded the value

CHARGING_PULSE_LIMIT (parameter 1:2).
3.
The SCP has changed the charging parameters (chargeable

announcement or chargeable user interaction ended).
4.
Intermediate charging is caused due to a change of Channel Related

Parameters.
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.
6.
The call continues with a Follow-on Call. This requires Feature 994:
CAMEL.
7.
Call drop back situation. This requires Feature 1093: Advanced Call
Drop Back for VMS Interface.
8.
Inter-PLMN handover. This requires Feature 1168: Multiple PLMN

and Inter-PLMN Handover Support in MSC.
9.
Inter-system handover. This requires Feature 1260: Inter-system

handover and UMTS changes in MSC.
10.
Intermediate charging due to UMTS data call. This requires Feature

1265: CS Data User Plane Protocol Support for UMTS.
11.
Intermediate charging caused by SCP interactions. This requires

Features 1196 and 1197: CAMEL Phase 4.
12.
Intermediate charging due to inter-MSC handover.
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.4
2.3
PLT
RPLT
2
2.3
+1
MPM message
2.3
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
40 (93)
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.

.
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)
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:
.
DN00133192
Issue 8-0 en
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.
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
42 (93)
Sum metering data of the whole exchange, contains one record.

.
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.
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)
2)
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.
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
2. Outgoing
signalling
3.
2.
Time charging
Figure 8.
Accounting
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
2.
SSI
Incoming
call control
1.
SSO
5.
4.
Accounting
1.
Time charging
3.
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
Charging case
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
CTYPES
CP
HC
ICC
OCC
MCZ
IAZ
OAZ
CRFILE
ICC/OCC
MSB
0
PCM-TSL
Counter index
FFFF
CRCMAP
Counter 1
Counter 2
Counter 3
Counter 4
Counter 5
Counter 6
Counter 7
Counter 8
0
n
LSB
Counter 1
Counter 2
Counter 3
Counter 4
Counter 5
Counter 6
Counter 7
Counter 8
0
n
FFFF
FFFF
CIRMET
ALL
TOLL
REC
Ans. inc. calls
Inc. call time
Ans. outg. calls
Outg. call time
0
n
Charging zone
CSUMET
0
n
ALL (4)
Ans calls (4)
Call time (4)
Free calls (4)
Free call time (4)
FFFF
CIGMET
Figure 10.
46 (93)
FFFF
ZONMET
ALL
TOLL
REC
GEN
REM
UNP
Call time
Answered calls
MS-MS talk time
TOTMET
Accounting counters
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.
MML commands for counter output
File
Command
CIRMET
GOC
CSUMET
GOG
ZONMET
GOT
TOTMET, CIGMET
GOX
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.
DN00133192
Issue 8-0 en
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.
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.
ATM accounting counter
REC
SUBREC
VALUE
ATM
UPD index 1
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
VALUE
UPD index n
incoming calls
outgoing calls
Table 5.
IP accounting counter
REC
SUBREC
VALUE
IP
UPD index 1
incoming calls
outgoing calls
...
...
UPD index n
incoming calls
outgoing calls
Control plane SIP/BICC counters
50 (93)
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
.
.
DN00133192
Issue 8-0 en
Table 6.
SIP accounting counter
REC
SUBREC
VALUE
SIP
UPDR_id 1
incoming calls
outgoing calls
...
...
UPDR_id n
incoming calls
outgoing calls
Table 7.
BICC accounting counter
REC
SUBREC
VALUE
BICC
UPDR_id 1
incoming calls
outgoing calls
...
...
UPDR_id n
incoming calls
outgoing calls
8.1
Binary formats
The binary formats for MSS are defined below.
DN00133192
Issue 8-0 en
51 (93)
8.1.1
Data block header
8.1.1.1
Header structure
Table 8.
Structure of header
Byte
Contents
Code
01
Block checksum
25
Length of whole block
DW
615
Exchange identifier
C(10)
1619
Exchange system identifier
DW
20
Format version
21
Store method
22
Counter service identifier
2330
Transfer time of block
BCD(8)
3134
Order number of transferred block
DW
3538
Number of counter sets included

into the block
DW
39
Number of counter IDs included

into the block format
4051
ID of the first counter set in block
DW(3)
5263
ID of the last counter set in block
DW(3)
6465
Number of counters included into

the block format
6697
Counters included into block format C(32)
98
Index of logical path
99
Counter structure
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
Record formats
8.1.2.1
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.
Structure of ATM/IP counters
Byte
Counter
Code
03
ATM/IP
DW
47
UPD index 1/ UPD index n
DW
811
Incoming calls
DW
12
Turn around value for the 'incoming C

calls' above
1316
Outgoing calls
17
Turn around value for the 'outgoing C

calls' above
1821
22
Turn around value for the 'talk time C

(incoming calls)' above
2326
DN00133192
Issue 8-0 en
DW
DW
DW
55 (93)
Table 9.
Structure of ATM/IP counters (cont.)
Byte
Counter
27

(outgoing calls)' above
Code
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
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.
Structure of SIP/BICC counters
Byte
Counter
Code
03
SIP/BICC
DW
47
UPDR index 1/ UPDR index n

DW
811
Incoming calls
12
Turn around value for the 'incoming C

calls' above
1316
Outgoing calls
17
Turn around value for the 'outgoing C

calls' above
1821
22

(incoming calls)' above
2326
27

(outgoing calls)' above
DN00133192
Issue 8-0 en
DW
DW
DW
DW
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
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.
MML commands for handling MSS-related accounting counters
Action
Command
Interrogate counter parameter
GSI
Update counters to disk
GSK
Transfer compiled counters
GSL
Modify counter block format
GSM
Modify sum counting formula
GSN
Output counter block format
GSO
Display counters
GSQ
Set counter updating parameters
GSS
Set counter transfer parameters
GST
Add indices to updating
GSV
Remove indices from updating
GSX
Interrogate active indices
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
MOC/
MTC
MS
MSC-A
MTC/PTC/ (IAZ/
MOC/POC OAZ)
MSC-B
PTC
POC
OAZ
IAZ
MTC
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.
10.2
MML commands for counter backup and comparison
Action
Command
Copy counters to tape
GCP
Copy counters to disk
GCF
Compare counters
GCM
Update counters
GCU
Add counter type into backup copying
GCC
Remove counter type from backup copying
GCD
Modify backup copying characteristics
GCR
Set tape copying time
GCT
Set disk copying time
GCH
Output backup copying characteristics
GCO
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.
CDRs and the fields that can be used for accounting purposes
CDR Type
MCZ
MOC
IAZ
OAZ
MTC
FORW
TERM
X
X
ROAM
POC
X
X
PTC
PBXO
PBXT
DN00133192
Issue 8-0 en
ROAM
DOC
RCC
69 (93)
70 (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).
DN00133192
Issue 8-0 en
Accounting parameters used in Advice of Charge
13
Accounting parameters used in Advice

of Charge
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:
DN00133192
Issue 8-0 en
repeated pulse train. [0.0, 819.1]

charge rate[0.0, 819.1]
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
Accounting parameters used in Advice of Charge
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;
EXECUTION STARTED
DX 200
MON
TUE
WED
THU
FRI
SAT
SUN
...
...
...
...
...
...
...
DX220-LAB
1997-04-15
10:00:03
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
GROUP 3
1
GROUP 4
1
COMMAND EXECUTED
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;
CONFIRM COMMAND EXECUTION: Y/N ?
CHANGE GROUP CREATED
DAY CLASS:
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
CHARGING ZONE CREATED
E-PARAMETERS: E1 (RPLT), E2 (RATE), E4 (PLT), E7 (FT)
NUMBER METHOD CHNGR DCGR
1005
SYNC
10
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
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;
DX 200
PISPALAMSC
1997-04-15
10:00:05
CIRCUIT GROUP MODIFIED

NCGR = SORI
NEW ANALYSIS TREE: 70
NEW CHARGING ORIGIN: 6
COMMAND EXECUTED
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;
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
DIG = 38558
FIRST ANALYSIS
TREE:
70
1997-04-15
STATE:
ENDS
ALT = 0
NAME OF DESTINATION
:
NAME OF SUBDESTINATION :
ROUTING DATA
NBR
2
ADDITIONAL DATA
DTYPE
A
CHARGING INDEX
FOLLOWING DIGITS:
00042
HLRENQ
RT
SPR
CT
IC
DSTATE
A
: 31
SCT
-
SP
9
NL
32
CNT
-
SRCL
N
TS
0
AR
-
QA
N
RC
APR
PC
ORD
IAZ
1005
OAZ
0
CNP
N
CHARGING ORIGIN: 6
NAME OF CHARGING CASE: PSTNMS

DC
NDC
ICC
10:00:08
SPM
SPA
TCI NCB
PT
HC
N
N
Y
N
0
CI
111100000000
OCC 000011110000
CHA: 22
CP
IC
MCZ
101
ACZ
0
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
:
EXECUTE CM ANALYSIS
50
0
NOT SPECIFIED
NOT SPECIFIED
NOT SPECIFIED
NOT SPECIFIED
NOT SPECIFIED
NOT SPECIFIED
NOT SPECIFIED
COMMAND EXECUTED
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
TOLL METERING
PULSES
0000000240
GENERATED
PULSES
0000000000
RECEIVED
PULSES
0000000000
REMINDER
PULSES
000000000
UNPOINTED
PULSES
0000000000
ALL ANSWERED
CALLS
0000000001
TALK TIME
(SEC)
0000000045
ALL PSTN
ORIG CALLS
0000000001
PSTN ORIG
TALK TIME
0000000045
ALL PSTN
TERM CALLS
0000000000
PSTN TERM
TALK TIME
0000000000
ALL OWN
ORIG CALLS
0000000000
OWN ORIG
TALK TIME
0000000000
ALL OWN
TERM CALLS
0000000000
OWN TERM
TALK TIME
0000000000
ALL MOBILE
ORIG CALLS
0000000000
MOBILE ORIG
TALK TIME
0000000000
ALL MOBILE
TERM CALLS
0000000001
MOBILE TERM
TALK TIME
0000000045
ALL VPS
ORIG CALLS
0000000000
VPS
ORIG
TALK TIME
0000000000
ALL VPS
TERM CALLS
0000000000
VPS TERM
TALK TIME
0000000000
ALL DEVICE
ORIG CALLS
0000000000
DEVICE ORIG
TALK TIME
0000000000
ALL MOBILE TO
MOBILE CALLS
0000000000
MOBILE TO
MOBILE TALK TIME
0000000000
NCGR
METERING
PULSES
TOLL METERING
PULSES
RECEIVED
PULSES
ALL IN
ANSWER CALLS
INCOMING
TALK TIME
ALL OUT
ANSWER CALLS
OUTGOING
TALK TIME
ALL ANSWERED
TOLL CALLS
SORI
0000000240
0000000045
0000000240
0000000000
0000000000
0000000000
0000000001
0000000000
VSA11
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
COMMAND EXECUTED
CIRMET (Trunk Circuit Counters)

< ZGOC:76-29&&-31;
DX 200
PISPALAMSC
COUNTERS OF CIRCUITS
80 (93)
1997-04-15
10:12:40
DN00133192
Issue 8-0 en
PCM-TSL
CTR 1
CTR 7
000000000
000000000
000000240
000000000
000000000
000000000
76-29
76-30
76-31
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;
DX 200
PISPALAMSC
COUNTERS OF CIRCUIT GROUPS
NCGR
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
SORI
COMMAND EXECUTED
ZONMET
< ZGOT:1005&501;
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
10:13:02
METERING
PULSES
0000000000
0000000240
0000000000
0000000000
ANSWERED
CALLS
0000000000
0000000001
0000000000
0000000000
TALK TIME
(SEC)
0000000000
0000000045
0000000000
0000000000
ANSWERED
FREE CALLS
0000000000
0000000000
0000000000
0000000000
FREE TALK
TIME
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000001
0000000000
0000000000
0000000000
0000000045
0000000000
0000000000
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;
EXECUTION STARTED
COMMAND EXECUTED
DAY CLASSES HANDLING COMMAND <GD_>

< ZGDI;
EXECUTION STARTED
DX 200
MON
TUE
WED
THU
FRI
SAT
SUN
...
...
...
...
...
...
...
DX220-LAB
1997-04-15
13:51:17
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;
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
CHARGING ZONE CREATED
E-PARAMETERS: E1 (RPLT), E2 (RATE),
NUMBER METHOD CHNGR DCGR
2005
SYNC
10
RATE1-RPLT1
PLT1
FT1
1.0-2.5
40.0
5.0
E4 (PLT),
E7 (FT)
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
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
RESULT IDENTIFIER
NEW RESULT
---------CONTINUE CALL SETUP
CHARGING ORIGIN
: 0
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;
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
DIG = 50120
FIRST ANALYSIS
TREE:
2
1997-04-15
STATE:
ENDS
FOLLOWING DIGITS:
ALT = 0
NAME OF DESTINATION
: 00042
NAME OF SUBDESTINATION : PSTN2
NBR RT
CT
ROUTING DATA
2
SPR IC
ADDITIONAL DATA
84 (93)
DTYPE
A
10:05:08
DSTATE
A
SCT
-
SP
9
NL
32
CNT
-
SRCL
N
TS
0
AR
-
QA
N
RC
APR
PC
ORD
CNP
N
DN00133192
Issue 8-0 en
CHARGING INDEX
: 32
CHARGING ORIGIN: 0
NAME OF CHARGING CASE: MSPSTN0

DC
NDC
ICC
CHA: 23
SPM
SPA
TCI NCB
PT
HC
N
N
Y
N
0
NCI
111100000000
OCC 000011110000
CHARGING INDEX
: 32
CP
OC
ACZ
0
IAZ
0
OAZ
2006
ACZ
0
IAZ
0
OAZ
2005
CHARGING ORIGIN: 3
NAME OF CHARGING CASE: MSPSTN

DC
NDC
ICC
MCZ
202
CHA: 24
SPM
SPA
TCI NCB
PT
HC
N
N
Y
N
0
NCI
111100000000
OCC 000011110000
CP
OC
MCZ
201
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
TOLL METERING
PULSES
0000000000
GENERATED
PULSES
0000000000
RECEIVED
PULSES
0000000280
REMINDER
PULSES
000000000
UNPOINTED
PULSES
0000000000
ALL ANSWERED
CALLS
0000000001
TALK TIME
(SEC)
0000000045
ALL PSTN
ORIG CALLS
0000000000
PSTN ORIG
TALK TIME
0000000000
ALL PSTN
PSTN TERM
ALL OWN
OWN ORIG
ALL OWN
DN00133192
Issue 8-0 en
85 (93)
TERM CALLS
0000000001
TALK TIME
0000000045
ORIG CALLS
0000000000
TALK TIME
0000000000
TERM CALLS
0000000000
OWN TERM
TALK TIME
0000000000
ALL MOBILE
ORIG CALLS
0000000001
MOBILE ORIG
TALK TIME
0000000045
ALL MOBILE
TERM CALLS
0000000000
MOBILE TERM
TALK TIME
0000000000
ALL VPS
ORIG CALLS
0000000000
VPS
ORIG
TALK TIME
0000000000
ALL VPS
TERM CALLS
0000000000
VPS TERM
TALK TIME
0000000000
ALL DEVICE
ORIG CALLS
0000000000
DEVICE ORIG
TALK TIME
0000000000
ALL MOBILE TO
MOBILE CALLS
0000000000
MOBILE TO
MOBILE TALK TIME
0000000000
NCGR
METERING
PULSES
TOLL METERING
PULSES
RECEIVED
PULSES
ALL IN
ANSWER CALLS
INCOMING
TALK TIME
ALL OUT
ANSWER CALLS
OUTGOING
TALK TIME
ALL ANSWERED
TOLL CALLS
SORI
0000000280
0000000000
0000000000
0000000001
0000000280
0000000045
0000000000
0000000000
VSA11
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
COMMAND EXECUTED
CIRMET (Trunk Circuit Counters)

< ZGOC:76-29&&-31;
DX 200
PISPALAMSC
COUNTERS OF CIRCUITS
PCM-TSL
76-29
76-30
76-31
CTR 1
CTR 7
000000000
000000000
000000000
000000045
000000000
000000000
CTR 2
CTR 8
1997-04-15
CTR 3
10:12:40
CTR 4
CTR 5
CTR 6
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;
DX 200
PISPALAMSC
COUNTERS OF CIRCUIT GROUPS
86 (93)
1997-04-15
10:12:52
DN00133192
Issue 8-0 en
NCGR
CTR 1
CTR 2
CTR 3
CTR 4
CTR 5
CTR 6
CTR 7
CTR 8
000000000 000000000 000000000 000000001 000000280 000000000
000000045 000000001
SORI
COMMAND EXECUTED
ZONMET
< ZGOT:2005&201;
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
10:13:02
METERING
PULSES
0000000000
0000000240
0000000000
0000000000
ANSWERED
CALLS
0000000000
0000000001
0000000000
0000000000
TALK TIME
(SEC)
0000000000
0000000045
0000000000
0000000000
ANSWERED
FREE CALLS
0000000000
0000000000
0000000000
0000000000
FREE TALK
TIME
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000001
0000000000
0000000000
0000000000
0000000045
0000000000
0000000000
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
Advice of Charge
AOC-C
AOC - charging
AOC-I
AOC - information
AOC-D
AOC during the call
AOC-E
AOC at the end of the call
ATM
Asynchronous Transfer Mode
BICC
Bearer Independent Call Control
CM
Central Memory
CRG
Charging Information Message
CS
Circuit Switched
ENC
Event Notification Charging
EOS
End of Selection
IAZ
Incoming Accounting Zone
IN
Intelligent Network
IP
Internet Protocol
MCZ
Main Charging Zone
MGW
Multimedia Gateway
MPM
Metering Pulse Message
MSS
MSC Server
OAZ
Outgoing Accounting Zone
RNC
Request Notification Charging
SCP
Service Control Point
DN00133192
Issue 8-0 en
89 (93)
SIP
Session Initiation Protocol
SSP
Service Switching Point
TDM
Time Division Multiplex
UPD
User Plane Destination
UPDR
User Plane Destination Reference (Control Plane)
VPS
Voice Processing System
90 (93)
DN00133192
Issue 8-0 en
Glossary
DN00133192
Issue 8-0 en
91 (93)
References
92 (93)
1.
Binary Formats of Charging: Counters, References.
2.
CDR Field Description, Interface Specification.
3.
European digital telecommunications system (Phase 2); Description

of Charge Advice Information (CAI), GSM 02.24, pr ETS 300 510..
4.
Feature 265: FTAM Security, Feature Description.
5.
Feature 446: MSC-MSC Handover Accounting, Feature Activation

Manual.
6.
Feature 469: Accounting Improvement, Feature Description.
7.
Feature 641: Charging Capacity, Feature Description.
8.
Feature 646: Advanced Accounting Data Transfer, Feature

Description.
9.
Feature 694: Primary Rate Access Supplementary Services

Enhancements, Feature Activation Manual.
10.
Feature 698: Charging Based on Parameters from Network, Feature

Description.
11.
Feature 703: On-line Call Monitoring, Feature Description.
12.
Feature 739: CS-1 Continuation, Feature Description.
13.
Feature 747: Mobile Accounting, Feature Description.
14.
Feature 774: High Speed Circuit Switched Data, Feature

Description.
15.
Feature 927: Improvements of Inter MSC Handover Architecture,

Feature Description.
16.
Feature 994: CAMEL, Feature Description.
17.
Feature 1093: Advanced Call Drop Back for VMS Interface, Feature
Description.
18.
Feature 1168: Multiple PLMN and Inter-PLMN Handover Support in

MSC, Feature Description.
DN00133192
Issue 8-0 en
References
DN00133192
Issue 8-0 en
19.
Features 1196 and 1197: CAMEL Phase 4, Feature Description.
20.
Feature 1260: Inter-system handover and UMTS changes in MSC,

21.
Feature 1265: CS Data User Plane Protocol Support for UMTS,

22.
Feature 1417: Charging in MSS, Feature Description.
23.
Generation and Contents of CDRs in Different Call Cases, Interface

Specification.
24.
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..
25.
MSC/HLR-BC Customer-specific Part, Interface Specification.
26.
S.A. Karlsson: General Principles Of Charging And Their Adaptation

To a Global Network, Research Institute Of the Helsinki Telephone
Company, Helsinki Finland, 1966.
27.
Storing and Transfer of Charging Data, Interface Specification.
93 (93)

How To Account in MSC BSC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Account in MSC BSC

Uploaded by

Copyright:

Available Formats

MSCDOCM14PDFCD

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

Accounting in MSC / MSS

# Nokia Siemens Networks

Accounting in MSC / MSS

# Nokia Siemens Networks

About this document 9

Use of charging analysis parameters 17

Accounting counters in MSC 39

Accounting counters in MSS 49

# Nokia Siemens Networks

Accounting in MSC / MSS

Accounting counter backup 63

Transferring accounting data via FTAM 67

Using CDRs for accounting purposes 69

Accounting parameters used in Advice of Charge 71

# Nokia Siemens Networks

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

SIP accounting counter

BICC accounting counter

Structure of ATM/IP counters

Table 10. Structure of SIP/BICC counters

Table 11. MML commands for handling MSS-related accounting counters

# Nokia Siemens Networks

Accounting in MSC / MSS

Different charging zones in three call cases

The analysis sequence in MSC/MSS

Tariff change structure

Pulse generation in MSC/MSS

Pulse generation in Karlsson charging

Pulse handling in AOC

Non-integer pulse handling

Reminder pulses from incoming signalling service: 1. The time charging

Figure 10. Accounting counters

# Nokia Siemens Networks

Figure 11. Inter-MSC handover accounting

No changes have been implemented in the interface since the previous

The document has been updated to include enhancements due to

New cause codes have been added to intermediate charging.

Changes made between issues 62 and 61

# Nokia Siemens Networks

Accounting in MSC / MSS

# Nokia Siemens Networks

About this document

About this document

# Nokia Siemens Networks

Accounting in MSC / MSS

Structure of this 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

Chapter Interface Modifications explains the changes since the last

Chapter Use of Charging Analysis Parameters explains what

Chapter Analyses describes the different analyses made at the

Chapter Time Charging explains how time charging works, what

Chapter Accounting Counters in MSC introduces the counters used

# Nokia Siemens Networks

About this document

Chapter Accounting Counters in MSS introduces the counters used

Chapter Inter-MSC Handover explains what counters are updated in