Charging Subsystem

Technical Manual
C&C08 Digital SPC Switching System Table of Contents
Table of Contents
Chapter 6 Charging Subsystem.................................................................................................. 6-1

6.1 Generation of Charging Information ................................................................................. 6-1
6.2 Fetching of the Charging Information ............................................................................... 6-3
6.3 Transferred Storage of the Charging Information............................................................. 6-4
6.4 Coordination with the Offline Charging System................................................................ 6-4
6.5 The Format of Ticket File.................................................................................................. 6-5
6.6 Ticket Server................................................................................................................... 6-25
Huawei Technologies Proprietary
i
Technical Manual Chapter 6
C&C08 Digital SPC Switching System Charging Subsystem
Chapter 6 Charging Subsystem
The Charging Subsystem comprises the Exchange Charging Subsystem and BAM
Charging Subsystem, as shown in Figure 6-1.
The Exchange Charging Subsystem mainly collects and generates charging
information. It fetches the charging information for sending to the BAM Charging
Subsystem.
The BAM receives the charging information coming from the exchange (i.e. exchange
tickets), generates the BAM tickets and transfers the charging information for storing.
Fetch Fetch
Generate ticket Detailed ticket
B F
Mail
A A Free ticket
M M
box
Restore ticket Meter ticket
BAM FAM
Figure 6-1 Charging Subsystem composition
6.1 Generation of Charging Information

The exchange charging information refers to the charging information of the type
detailed ticket or meter table.
I. Generating principle
The generation of the exchange charging information is conducted in two ways:

Charging by group and charging by destination code.
Charging by group is conducted according to the charging type determined by the
charging groups to which the calling and the called party belong. Charging groups are
categorized by operators and are configured in the subscriber connection data. The
charging type, detailed ticket or meter table, between each pair of charging groups
would be configured with the intra-office group charging data.
Charging by destination code is conducted according to the charging type determined
by the charging group to which the calling party belongs and the called-party's
destination code. If the operator wishes to adopt a special charging type for calls with a
certain destination code, the charging by destination code type can be employed.
The charging by group type has a higher priority than the charging by destination code.
Only when the corresponding data cannot be found in the charging by group data, the
charging by destination code would be conducted. If the charging data cannot be found
in the charging-by-destination-code data either, an alarm call ticket and alarm would be
produced.
6-1
II. Generation of charging information
Generation of the exchange charging information mainly depends upon the data
configured by the operator. Different attributes play a major role in the data
management such as:
In terms of service attribute, there are local, national, international, etc.
In terms of charging party, there are calling party charging, called party charging,
both-party charging, third party charging, etc.
In terms of ticket, there are ordinary ticket, free ticket, complaint ticket, etc.
In terms of charging type, there are detailed ticket and meter table.
In terms of charging attribute, there are subscriber ticket and trunk ticket.
The operator can combine these attributes at will in the data management to achieve
requirements.
The complaint ticket is for the subscriber to view. All the other tickets are for the
telecommunication administration itself. Hence, if a certain number is configured as the
charging complaint in the subscriber connection data, the complaint ticket would be
generated first before other charging operations are conducted.
If ‘both-party charging’ has been set as the charging party in the charging data, then
both the calling & called parties would be charged and a ticket would be generated for
both of them.
If the charging method has been set as free, then the free ticket would be generated.
If the charging type has been set as meter table, then meter to be employed must be
set as well (from meter 1 to meter 10); if the charging type has been set as meter table
and detailed ticket, the meter table would be generated first before the detailed ticket
generation.
III. Storing the charging information
The storing of the exchange charging information refers to the storing of the exchange
tickets, which is divided into two levels: ticket buffer and extended memory. See Figure
6-2.
Main CPU Slave CPU

Bill Buffer
Extended
memory
Figure 6-2 Storing of charging information
When the ticket buffer is full, the content would be written into the extended memory
once for all, thereby the write/read efficiency of the extended memory could be
improved.
6-2
6.2 Fetching of the Charging Information

The fetching of the charging information refers to the process that the exchange
outputs the tickets stored in its extended memory & ticket buffer for sending to the BAM
mailbox, then the BAM reads these tickets from its mailbox to convert them into the
BAM tickets and store them into the disk file.
The fetching of the charging information starts when the BAM sends out a "start to fetch
tickets" frame. The exchange would then send out a handshaking frame for a
handshake with the BAM. After receiving an acknowledgement frame from the BAM, it
indicates the handshake is successful. Subsequently, each time the exchange sends
out 20 frames of the exchange tickets to the BAM, the BAM would send out an
acknowledgement frame after receiving these frames from the exchange. This process
is repeated until the exchange sends out a termination frame to which the BAM
responds with an acknowledgement frame for process termination. See Figure 6-3.
(AM/CM) (BAM)
Begin
Co nn ec t
ACK 0
D .a ta 0
.
.
D a ta 1 9
AC K 20
D a ta 2 0
.
.
.
D a ta 3
9
A C K 40
.
.
.
.
.
D a ta 1
80
D a ta 1 9
. 9
.
.
ACK 200
E nd
End
Figure 6-3 Process of fetching charging information
6-3
6.3 Transferred Storage of the Charging Information

Taking out the tickets from exchange and transfer them to an offline charging system is
the transferred storage of the charging information.
As the tickets pool of the exchange has a limited space, the transferred storage of
tickets should be conducted in time. This function is performed by the BAM on preset
schedules. The BAM sends out the fetch-ticket command to each module on schedule
(for example, the interval can be set as one hour). Those modules with tickets stored
respond to this command and transfer tickets to the BAM. The BAM stores these
received tickets into the ticket file. At the same time, it gives out a real-time display of
the number of tickets having been fetched onto the BAM and maintenance terminal,
thus facilitating the operator to monitor the process. After receiving the
acknowledgement that each module has completed transferring its tickets, the BAM
puts an end to this ticket-fetching process in this term and waits in standby for the next
term.
When transferring tickets to the BAM, each module attaches a piece of very important
information to each frame, i.e. serial number of the ticket. The BAM uses the serial
number of the ticket for sending the acknowledgement frame & "stop fetching tickets"
frame to the exchange and the exchange also depends on the ticket’s serial number
received from the BAM to know the exact number of tickets received by the BAM. Both
the exchange and BAM would insure the matching of the serial numbers to avoid
repeated tickets or loss of tickets.
In the course of fetching tickets, the BAM performs a large quantity of disk- write
operations and therefore during this period, no operation is supposed to be conducted
on the BAM. At the maintenance terminal, the operator can preset a timetable for the
BAM to automatically fetch tickets during several one-hour periods in the next 24 hours.
During the periods when no ticket-fetching operation is in progress, the operator can
perform other large-volume operations, such as the file conversion, etc. Fetching
tickets by the BAM is automatic, but also controllable. The operator can send
‘immediately-fetch-ticket’ command from the maintenance terminal regardless of the
automatic fetch-ticket timetable; or, when a ticket-fetching operation is in progress, a
command could be sent to terminate it. In other words, the operator can have the
control to start and terminate a ticket-fetching operation.
As the tickets file takes up a very large space in the disk, to ensure the system safety, if
the free space in the disk is less than 10M in volume, the BAM stops fetching tickets
and at the same time, an alarm message would be displayed at the maintenance
terminal to remind the operator of deleting those out of date files.
The BAM can reliably perform the ticket-fetching function and is capable of a number of
fault-tolerance measures. It can completely prevent the repetition of tickets and losses
of tickets from happening, thus enabling the offline charging system to smoothly &
completely perform charging and measurement operations on subscribers.
6.4 Coordination with the Offline Charging System

The charging information can be copied on mediums, such as the tape, compact disk,
floppy disk, etc., to be transferred to the Offline Charging System for sorting. If the
Offline Charging System is in a same network with the terminal system, the charging
information can be transferred via the network to the storing mediums, such as the hard
disk of the Offline Charging System and then the sorting process can be performed.
6-4
6.5 The Format of Ticket File

The C&C08 Switching System generates the following tickets:
z "Detailed ticket";
z "Meter table ticket";
z "Meter table statistics ticket";
z "Trunk duration statistics ticket";
z "Free call statistics ticket".
The following are the descriptions of the ticket formats and types, which are organized
in the following way:
z The ticket contents are described by every byte in an ascending sequence.
z Every bit in an ascending sequence describes the contents of every bite.
z BCD code: "OXF" is the end of BCD code, with its contents described by byte in an
ascending sequence. The sequence is from the high half-byte to the low- half byte
within a byte.
I. Detailed ticket
1) Detailed ticket has a length of 118 bytes and the meanings are described below in
every field in an ascending sequence:
[Serial Number]: 4 bytes
This is the unified sequence number for all the tickets since the starting of the
switching system, represented in a long format.
[Ticket Type]: 1 byte
Represents the type of the call a ticket records, with the following values:
0x01: Detailed ticket
0x02: Call record of DBO
0x03: Call record of IN
0x05: TAX record
0xF0: Meter table ticket
0xF1: Meter table statistics
0xF2: Trunk duration statistics
0xF3: Free call statistics
0xFF: Warn ticket
0x55: Failed call ticket (Incomplete call watch ticket, Partial record ticket)
Note: Ticket with this four byte valued 0x01 should be explained with the format
below.
[Checksum]: 1 byte
The sum of all the bytes except the first three fields (serial number, ticket type,
checksum), which is used to check the validity of a ticket.
6-5
[Partial Record Indicator]: 0.5 byte

Indicates whether a ticket is a stand-alone record or a record corresponding to a
segment of time duration in a long-time duration ticket.
0: Stand-alone record
1: Partial record
[Validity]: 0.125 byte
Value - 0: Valid; 1: Invalid
[Clock Changed Flag]: 0.125 byte
Indicates whether the clock has been changed during the call (for example,
whether the MPU time has been modified through the BAM).
Value - 0: Yes; 1: No
[Free flag]: 0.125 byte
Value - 0: Free of charge; 1: Charge (currently the default is set as 0 for call
attempt)
[Call attempt flag]: 0.125 byte
Value - 0: Free for call attempt; 1: Charge for call attempt
[Complaint flag]: 0.125 byte
Value - 0: No complaint; 1: Complaint
[Centralized charging flag]: 0.125 byte
Value - 0: Non-centralized charging; 1: Centralized charging
[Credit card flag]: 0.125 byte
Value - 0: Non credit card call; 1: Credit card call
[Charging method]: 0.125 byte
Value - 0: Meter table; 1: Detailed ticket
[Payer]: 0.5 byte
Value:
1: Calling party charged
2: Called party charged
3: Destination number charged (for IN)
4: Third party charged, classified into cases which are respectively: 11, 12, 13
and 14
9: Incoming trunk charged
10: Outgoing trunk charged
11: Calling party charged (the third party pays)
12: Called party charged (the third party pays)
6-6
13: Incoming trunk charged (the third party pays)

14: Outgoing trunk charged (the third party pays)
[Conversation End Time]: 6 bytes
Conversation end date and time, with the format: YYMMDDHHMMSS
YY: 0-99 (binary)
MM: 1-12 (binary)
DD: 1-31 (binary)
HH: 0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
[Conversation Duration]: 4 bytes
It is the duration of conversation recorded by the switching (Data type: long int;
Unit: 10ms).
[Caller Seizure Duration]: 4 bytes
Indicates the caller seizure duration (data type: long int; Unit: 10ms).
[Called Seizure Duration]: 4 bytes
Indicates the called seizure duration (Data type: long int; Unit: 10ms).
[Incomplete Call Watch]: 0.25 byte
Value - 0: No watch; 1: Watch caller; 2: Watch called; 3: Watch both
[Spare]: 0.25 byte
[Charging Number Address Nature]: 0.5 byte
Value:
0: Subscriber number
1: Reserved,
2: Valid national number (charging number = trunk code + local number)
3: International number (charging number = country code + trunk code + local
number)
4: Account card type A
5: Account card type B
6: Account card type C
7: Account card type D
8: VISA card
9: CTX group number
10: CTX inner extension number
11: Bank 1
6-7
12: Bank 2
13: Bank 3
14: Bank 4
15: Reserved
[Charging Number DnSet]: 1 byte
Indicates the numbering set of charging number.
[Charging Number]: 10 bytes
Indicates the charging number (Datatype: packed BCD, with "0xF" filling the
unoccupied space).
[Caller Number DnSet]: 1 byte
Indicates the numbering set of caller number.
[Connected Number DnSet]: 1 byte
This is the numbering set of connected number.
[Caller Number Address Nature]: 0.5 byte
This indicates the address nature of caller number.
Value:
0: Subscriber number (Caller number = Local number)
2: National valid number (Caller number = Trunk code + Local number)
3: International number (Caller number = Country code + trunk code + Local
number)
[Connected Number Address Nature]: 0.5 byte
Indicates the address nature of connected number.
Value:
0: Subscriber number, Connected number = Local number
2: National valid number, Connected number = Trunk code + Local number
3: International number, Connected number = Country code + trunk code +
Local number
[Caller Number]: 10 bytes
Data type: packed BCD, with "0xF" filling the unoccupied space.
[Connected Number]: 10 bytes
[Dialed Number]: 12 bytes
[CENTREX Group Number]: 2 bytes
6-8
Indicates the charging object's Centrex group number (0~65535. 0xFFFF

indicate non-Centrex group subscriber).
[Caller CENTREX short number]: 4 bytes
[Called CENTREX short number]: 4 bytes
[Caller module number]: 1 byte
This indicates the number of the module the caller belongs to.
[Called module number]: 1 byte
This indicates the number of the module the called belongs to.
[Incoming trunk group number]: 2 bytes
Indicates the group number of the incoming trunk (0 to 65535. 0xFFFF
indicates this call does not pass through any incoming trunk).
[Outgoing trunk group number]: 2 bytes
Indicates the group number for the outgoing trunk (0 to 65535. 0xFFFF
indicates this call does not pass through any outgoing trunk).
[Caller device type]: 1 byte
This indicates the device type for the caller party in the local office (all the
device types provided by the C&C08).
[Called device type]: 1 byte
This indicates the device type for the called party in the local office (all the
device types provided by the C&C08).
[Caller category]: 1 byte
Value:
0x00: Unknown
0x01: French operator without transfer facility
0x02: English operator without transfer facility
0x03: German operator without transfer facility
0x04: Russian operator without transfer facility
0x05: Spanish operator without transfer facility
0x06: Spare language 1 operator without transfer facility
0x09: French operator with transfer facility
0x0A: English operator with transfer facility
0x0B: German operator with transfer facility
6-9
0x0C: Russian operator with transfer facility

0x0D: Spanish operator with transfer facility
0x0E: Spare language 1 operator with transfer facility
0x0F: Spare language 2 operator with transfer facility
0x10: Spare language 3 operator with transfer facility
0x11: International ordinary subscriber
0x12: International prior subscriber
0x13: International data transmission
0x14: International maintenance equipment
0x15: International private meter subscriber (subscriber charged in 16/12KC
mode)
0x16: International coin box subscriber (subscriber charged in polarity
reversal\polarity reversal pulse mode)
0x20: National ordinary free subscriber
0x21: National ordinary periodic subscriber
0x22: National instant print subscriber
0x23: National private meter subscriber (subscriber charged in 16/12KC mode)
0x24: National coin box subscriber (subscriber charged in polarity
reversal\polarity reversal pulse mode)
0x25: National prior free subscriber
0x26: National prior periodic subscriber
0x27: National maintenance equipment
0x28: National data transmission
0x29: National operator with transfer facility
0x2A: National interception service operator
0x2B: National operator with trunk offering facility
0x2C: National ordinary operator
[Called category]: 1 byte
The values are same as above.
[Call type]: 0.5 byte
Value:
1: Intra-office
2: Incoming to office
3: Outgoing from office
4: Tandem
6-10
5: Supplementary Service
[Service type]: 0.5 byte
Value:
0: Intra-office
1: Local
2: Local toll
3: National toll
4: International toll
5: Supplementary Service
6: PABX call
14: Local CENTREX
[Supplementary Service type]: 1 byte
Value:
0: CENTREX out
1: Register abbreviated dialing
2: Use abbreviated dialing
3: Cancel abbreviated dialing
4: Cancel all abbreviated dialing
5: Check abbreviated dialing
6: Activate hot line
7: Use hot line
8: Cancel hot line
9: Check hot line
10: Activate outgoing call barring
11: Use outgoing call barring
12: Cancel outgoing call barring
13: Check outgoing call barring
14: Activate alarm call
15: Use alarm call
16: Cancel alarm call
17: Check alarm call
18: Activate multi-alarm call
19: Cancel multi-alarm call
20: Check multi-alarm call
6-11
21: Activate absent subscriber

22: Use absent subscriber
23: Cancel absent subscriber
24: Check absent subscriber
25: Activate do not disturb
26: Use do not disturb
27: Cancel do not disturb
28: Check do not disturb
29: Use malicious call trace
30: Activate registered call
31: Use registered call
32: Cancel registered call
33: Check registered call
34: Activate Call Forwarding Unconditional (CFU)
35: Use Call Forwarding Unconditional (CFU)
36: Cancel Call Forwarding Unconditional (CFU)
37: Check Call Forwarding Unconditional (CFU)
38: Activate Call Forwarding Busy (CFB)
39: Use Call Forwarding Busy (CFB)
40: Cancel Call Forwarding Busy (CFB)
41: Check Call Forwarding Busy (CFB)
42: Activate Call Forwarding No Reply (CFNR)
43: Use Call Forwarding No Reply (CFNR)
44: Cancel Call Forwarding No Reply (CFNR)
45: Check Call Forwarding No Reply (CFNR)
46: Activate call waiting
47: Use call waiting
48: Cancel call waiting
49: Check call waiting
50: Activate calling back on busy
51: Use calling back on busy
52: Cancel calling back on busy
53: Check calling back on busy
54: Use three parties communication
6-12
55: Use conference

56: Use designated picking up
57: Use call pickup for all
58: Use caller hooking
59: Use called hooking
60: Activate CLIR
61: Cancel CLIR
62: Check CLIR
63: Activate COLR
64: Cancel COLR
65: Check COLR
66: Use CLIP
67: Temporary booking CLIP
68: Temporary booking CLIR
69: Activate number barring
70: Used number barring
71: Cancel number barring
72: Cancel all number barring
73: Check number barring
74: Activate secretary station
75: Use secretary station
76: Cancel secretary station
77: Check secretary station
78: Activate secretary service
79: Use secretary service
80: Cancel secretary service
81: Check secretary service
82: Activate immediate hot line
83: Use immediate hot line
84: Cancel immediate hot line
85: Activate call forwarding table
86: Deactivate call forwarding table
87: Check call forwarding table
88: Activate remote CFU
6-13
89: Cancel remote CFU

90: Activate remote CFB
91: Cancel remote CFB
92: Activate remote CFNR
93: Cancel remote CFNR
94: Modify password
95: Clear conference participant
96: Receive conference incoming call
97: Reject conference incoming call
98: Register conference list
99: Use list conference
100: Clear one conference list
101: Clear all conference lists
102: Check list conference
103: Cancel all services
104: Use password call
105: Use outgoing call prompt
106: Activate booked call
107: Use booked call
108: Cancel booked call
109: Check booked call
110: CFB to voice mailbox
111: CFNR to voice mailbox
112: Add voltage MWN
113: Activate AOCE
114: Use AOCE
115: Cancel AOCE
254: All Supplementary Services
255: Supplementary Service BUTT
[Charging case]: 2 bytes
Charging case of this call, which is determined by the switch charging data
settings.
[Tariff]: 2 bytes
Indicates the charging unit. Unit: cent
6-14
[Charging pulse]: 4 bytes

This indicates the number of charging pulses.
[Fee]: 4bytes
Fee is calculated according to switch charging data and includes additional fee
and information fee. Its unit is cent.
[Bearer Services]: 1 byte
Value:
1: Circuit-mode, 64 kbit/s not restricted, 8KHz structured Bearer Services
2: Circuit-mode, 64 kbit/s, 8KHz structured bearer voice services, classified into
four cases: 100, 101, 102 and 103
3: Circuit-mode, 64 kbit/s, 8KHz structured bearer 3.1KHz voice service
4: Packet-mode, ISDN virtual call. User access to the permanent virtual service
is provided by B channel
5: User signaling Bearer Service
7: Circuit-mode, 2X64 kbit/s not restricted, 8KHz structured Bearer Service type
8: Circuit-mode, 6X64 kbit/s not restricted, 8KHz structured Bearer Service type
9: Circuit-mode, 24X64 kbit/s not restricted, 8KHz structured Bearer Service
type
10: Circuit-mode, 30X64 kbit/s not restricted, 8KHz structured Bearer Service
type
100: Voice, analog calls analog
101: Voice, analog calls digital
102: Voice, digital calls analog
103: Voice, digital calls digital
255: Unknown
Others: Reserved
[Teleservice]: 0.5 byte
Value:
0: Reserved
1: 3.1K Telecom service
2: 7KHz Telephony service
3: G4 Fax
4: Teletex
5: Videotext
6: Mixed mode
7: Video telephone 7KHz
6-15
15: Unknown
Others: Reserved
[Conversation End Reason]: 0.5 byte
Value:
0: Caller on-hook; 1: Called on-hook; 2: Exception
[Reason Number]: 1 byte
[Release Index]: 1 byte
[UUS1 Count]: 1 byte
It indicates the UUS1 switch number (64 bytes form a segment).
It indicates the UUS2 switch number (64 bytes form a segment).
It gives the count of UUS3 switch (64 bytes form a segment)
[Reserved]: 4 bytes
2) Detailed ticket types

Detailed ticket is generated when a call is completed. Tickets can be classified into the
following categories according to multiple properties (centralized charging or not,
charged target, charge type, pay party and ticket type):
At the calling side:
z Detailed subscriber ticket (attributes: not centralized charging, subscriber, charge,
calling and detailed ticket)
z Detailed trunk ticket (attributes: not centralized charging, trunk, charge, calling and
detailed ticket)
z Credit card ticket (attributes: not centralized charging, subscriber, charge, calling
and credit card ticket)
z Free call ticket (attributes: not centralized charging, subscriber, free of charge and
detailed ticket)
Note: Meter table charging does not generate ticket of the above mentioned types.
z Centralized ticket (attributes: centralized charging, subscriber, charging, calling
and common detailed ticket)
Note: For an incoming trunk call, centralized charging is carried out only when the
calling number is available.
z User complaint ticket (attributes: non centralized charging, subscriber, complaint,
calling and common detailed ticket)
Trunk complaint ticket (attributes: non centralized charging, trunk, complaint, calling
6-16
Credit card complaint ticket (attributes: non centralized charging, subscriber, complaint,
calling and credit card detailed ticket)
Free of charge complaint ticket (attributes: non-centralized charging, subscriber,
complaint, free of charge and common detailed ticket).
Note: Irrespective of the charging mode (for example, "Detailed ticket" or "Meter table"),
a complaint ticket will be generated as long as the calling party has a complaint request.
z User alarm ticket (attributes: non-centralized charging, subscriber, alarm, calling
Trunk alarm ticket (attributes: non-centralized charging, trunk, alarm, calling and
common detailed ticket).
At the called side:
z Called detailed ticket (attributes: non-centralized charging, subscriber, charging,
called and common detailed ticket)
Outgoing trunk detailed ticket (attributes: non-centralized charging, outgoing trunk,
calling and common detailed ticket)
Note: If the charging mode is "Meter table", the above tickets will not be generated.
z Called user complaint ticket (attributes: non-centralized charging, subscriber,
complaint, called and common detailed ticket)
Outgoing trunk complaint ticket (attributes: non-centralized charging, outgoing trunk,
complaint, calling and common detailed ticket)
Note: Irrespective of the charging mode (for example, "Detailed ticket" or "Meter table"),
a complaint ticket will be generated if the called party has a complaint request.
z User alarm ticket (attributes: non-centralized charging, subscriber, alarm, called,
Trunk alarm ticket (attributes: non-centralized charging, trunk, alarm, called and
common detailed ticket).
II. Meter table ticket
Meter table ticket has totally 118 bytes and the meanings are described below in every
field in an ascending sequence:
Indicates the unified number for the tickets generated since the starting of the
switching system, represented in a long int. format.
Indicates the type of the ticket recorded, with the following values:
0x02: Call record for DBO
0x03: Call record for IN
0x05: Records generated by TAX
6-17
0xF1: Meter table statistics

0xF2: Trunk duration statistics
0xF3: Free call statistics
0xFF: Warn ticket
0x55: Failed call ticket (incomplete call watch ticket, partial record ticket)
Note: Tickets with this field valued 0xF0 can be explained by the format
described below.
[Checksum]: 1 byte
It indicates the sum of all the bytes except those occupied by the first three
fields (Serial number, Ticket type and Checksum), for checking the validity of
the ticket.
[Reserved]: 0.5 byte
Value:
0: Valid; 1: Invalid
[Charging object]: 0.25 byte
Value - 0: Subscriber; 1: Incoming trunk; 2: Outgoing trunk
[Meter Table Number]: 1 byte
The value is the count of meter tables of the C&C08, which currently is 10.
[Meter Table Generate Time]: 6 bytes
This indicates the date and time when meter table is generated, with the format:
YYMMDDHHMMSS.
YY: 00-99 (binary)
MM: 1-12 (binary)
DD: 1-31 (binary)
HH: 0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
[Subscriber DnSet]: 1 byte
Indicates the subscriber numbering set.
[Subscriber Address Nature]: 1 byte
It indicates the address nature of telephone number of subscriber:
0: Subscriber number (telephone number of subscriber = local number)
1: Reserved
6-18
2: Valid national number (telephone number of subscriber = trunk code + local

number)
3: International number (telephone number of subscriber = country code + trunk
code + local number)
[Subscriber Number]: 10 bytes
Indicates the telephone number of subscriber (Datatype: packed BCD, with
“0xF” filling the unoccupied space).
[Trunk group number]: 2 bytes
Trunk group number when charging object is incoming trunk or outgoing trunk.
[Module number]: 1 byte
Module number of the subscriber or the trunk group
[Device Type]: 1 byte
Indicates the local office caller equipment types, which are available with
C&C08. Value: 0-255
[Equipment Number]: 2 bytes
This indicates the equipment sequence number for users within a module.
Value: 0-65534. 65535 is a vacant value.
[Meter Table 1 Value]: 4 bytes
Indicates the accumulated value of this meter table since the latest meter table
ticket was generated (the same explanation applies to the Meter Table 2~10
below).
[Meter Table 1 Call Times]: 2 bytes
Indicates the accumulated call times of this meter table since the latest meter
table ticket was generated (the same explanation applies to the Meter Table
2~10 below).
6-19

[Reserved]: 26 bytes
Note: C&C08 has 10 meter tables, which can be used to count for subscribers,
incoming trunks and outgoing trunks. For the tariff of each meter table, refer to the
"Meter table tariff list" at the data management terminal.
III. Meter table statistics ticket
This is the statistics ticket for the counting of various meters used for subscribers or
trunks with any of the four call types (intra-office, incoming, outgoing, and tandem). It
has a length of 118 bytes and the meanings are described below in every field in an
ascending sequence:
Indicates the unified number for all the tickets generated since the starting of
the switching system, represented in a long int.
Indicates the type of the call ticket recorded. Value:
0x03: IN call record
0x05: Record generated by TAX
0xF0: Meter table call ticket
0xF1: Meter table statistics ticket
0xF2: Trunk duration statistics ticket
0xF3: Free call statistics ticket
0xFF: Warn ticket
Note: ticket with this field valued 0xF1 can be interpreted by the following way.
[Checksum]: 1 byte
It indicates the sum of all the bytes except the first three fields (Serial number,
Ticket type and Checksum), which is used to check whether a ticket is a valid
one.
6-20

Value:
0: Valid; 1: Not valid
[Reserved]: 0.375 bytes
[Meter Table Number]: 1 byte
Its value is the count of the meter tables available with the C&C08, which
currently is 10.
[Ticket Generate Time]: 6 bytes
Indicates the date and time when a meter table statistical ticket is generated,
with the format: YYMMDDHHMMSS
YY: 00-99 (binary)
MM: 1-12 (binary)
DD: 1-31 (binary)
HH: 0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
It is the number of the module where the meter table statistics ticket is
generated, ranging 1-240.
[Call category]: 1 byte
Call type, with the following values:
1: Intra-office
2: Incoming to office
3: Outgoing from office
4: Tandem
Other: Invalid
Note: This field indicates the statistical types of the current meter table.
It indicates the accumulated counting value for designated call type of this
meter since the generation of the latest meter table ticket (the same explanation
applies to the Meter Table 2~10 below).
Indicates the accumulated times of calls with designated call type of this meter
since the generation of the latest meter table ticket (the same explanation
applies to the Meter Table 2~10 below).
6-21

Note: Value restricted:
When "Call category" is “intra-office” or “outgoing from office”, the "Charged object" is
"Subscriber"; while when the "Call category" is "Incoming to office" or "Tandem", the
"Charged object" is "Trunk".
IV. Trunk duration statistics ticket
This ticket keeps statistics of the times of incoming calls, tandem calls & calls going out
of the current trunk (outgoing and tandem calls) and their duration. It has a length of 118
bytes and the meanings are described below in every field in ascending sequence:
Indicates the unified number for all the tickets since the starting of the switching
system, represented in a long int.
Indicates the type of the call ticket recorded, Value:
0x05: Call record generated by TAX
6-22

0xF2: Trunk duration statistics ticket
0xF3: Free call statistics ticket
0xFF: Warn ticket
0x55: Failed ticket (Incomplete call watch ticket, partial record indication ticket)
Others: Reserved
Note: Tickets with this field valued 0xF2 can be interpreted in the following way.
[Checksum]: 1 byte
It indicates the sum of all bytes except those occupied by the first three fields
(Serial number, Ticket type and Checksum), which is used for checking the
validity of the ticket.
Value:
[Ticket Generated Time]: 6 bytes
Indicates the date and time when a trunk duration statistics ticket is generated,
with the format: YYMMDDHHMMSS.
YY: 00-99 (binary)
MM: 1-12 (binary)
DD: 1-31 (binary)
HH: 0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
This indicates the number of the module where the trunk duration statistics
ticket is generated, with value ranging from 1 to 240.
[Reserved]: 1 byte
[Trunk group number]: 2 bytes
Indicates the number of the trunk group involved.
[Incoming office call duration]: 4 bytes
It gives the statistics of call duration of in-office incoming calls through the
specified trunk group, which are to be charged since the generation of the latest
trunk duration statistics ticket.
6-23
[Incoming office call times]: 2 bytes

Gives the count of in-office incoming calls through the specified trunk group,
which are to be charged since the generation of the latest trunk duration
statistics ticket.
[Tandem incoming call duration]: 4 bytes
It gives the statistics of call duration of tandem incoming calls through the
specified trunk group, which are to be charged since the generation of the
previous trunk duration statistics ticket.
[Tandem Incoming Call Times]: 2 bytes
It gives the count of tandem incoming calls through the specified trunk group to
be charged since the generation of the previous trunk duration statistics ticket.
[Outgoing trunk call duration]: 4 bytes
This gives the statistics of call duration for call outgoing through the specified
trunk group (including out-of-office outgoing and tandem outgoing), which are to
be charged since the generation of the previous trunk duration statistics ticket.
[Outgoing Trunk Call Times]: 2 bytes
Gives the count of calls outgoing through the specified trunk group (including
out-of-office outgoing and tandem outgoing), which are to be charged since the
generation of the previous trunk duration statistics ticket.
V. Free call statistics ticket
This ticket keeps statistics of the duration and count of all the free calls. It has a length
of 118 bytes and every field in ascending sequence describes the meanings:
[Serial number]: 4 bytes
Indicates the unified number for all the tickets since the starting of the switching
system, represented in a long int.
[Ticket type]: 1 byte
Indicates the type of the call ticket, Value:
0x05: Record generated by TAX
0xF2: Trunk duration statistics ticket 0xF3: Free call statistics ticket
0xFF: Warn ticket
Others: Reserved
6-24
Note: Tickets with this field valued 0xF3 can be interpreted in the following way:
[Checksum]: 1 byte
It gives the sum of all the bytes except those occupied by the first three fields
(Serial number, Ticket type, and Checksum), which is used for checking the
validity of the ticket.
Value:
[Ticket Generated Time]: 6 bytes
Indicates the date and time when a free call ticket is generated, with the format:
YYMMDDHHMMSS.
YY: 00-99 (binary)
MM: 1-12 (binary)
DD: 1-31 (binary)
1HH: 0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
Indicates the number of the module where the free call statistics ticket is
generated, with value ranging from 1 to 240.
[Reserved]: 1 byte
[Free Conversation Duration]: 4 bytes
It gives the statistical value of the duration of the free calls since the generation
of the latest free call statistics ticket.
[Free Call Times]: 2 bytes
Give the count of free calls since the generation of the latest free call statistics
ticket.
6.6 Ticket Server

The C&C08 Switching System can be equipped with adaptable ticket server, which is
responsible for the conversion of original tickets from the binary format to text format.
Through this ticket server, the switching system can connect to the charging center and
implement the offline charging function.
1) Connection between ticket server and BAM
The method to connect the ticket server with the BAM is shown in Figure 6-4:
6-25
FAM Charge
HDLC center
BAM server Ticket

server
Net Net
adapter adapter
A B
Net
adapter Net Net
adapter adapter
C D
LAN switch
WS/ticket
counter
Figure 6-4 Method of connection between the ticket server and BAM
From the above figure, it can be noted that:

z On the ticket server there are 4 network adapter cards of which, card A is
connected with the charging center and card B with the BAM. These two cards are
mainly responsible for receiving original ticket data from the BAM. Network
adapter cards C and D serve as backup.
z The ticket server does not directly connect to the host. Instead, it receives original
ticket data and returns alarms through the BAM. Alarms from the ticket server are
sent to the alarm box of the switching system and the alarm box will issue alarms
when the ticket server is disconnected from the BAM.
z The ticket server is connected with the BAM through the LAN. A real-time ticket
transfer program in BAM is responsible for the setup of a TCP connection with the
communication module of the host. It is also responsible for sending the original
ticket data to the ticket server through the customized slip window protocol.
z The ticket server is related to the BAM on a one-one basis, that is, one BAM is
equipped with one ticket server.
2) Method of connection between ticket server and charging center:
The ticket server is connected with the charging center in the way as illustrated in
Figure 6-5:
6-26
Bill
server
Router
DDN or other
HUB E1 device
WAN
Trunk
Router
E1 device
Net
adapter
charge center HUB
Net adapter
charge center
Figure 6-5 Connection between ticket server and charging center
As shown in the figure, the ticket server can connect to the charging center through
WAN or LAN.
3) Ticket processing
With a ticket server, tickets are processed in the following manner:
Step 1: Original tickets from the MPU to the BAM
A call ticket after generation, is buffered in the ticket pool of the host. The BAM regularly
sends a ticket request to the host. The host after receiving the request sends the tickets
to the BAM where they are stored on the hard disk. The ticket is first buffered on the
BAM.
After obtaining original tickets, the BAM makes a simple analysis of them. If a ticket is
checked out to be too long or its checksum is incorrect, it is taken as an incorrect ticket.
Tickets of this type are put in a special error ticket file to be manually processed. Other
tickets are stored in files with ".bil" being their extension name, which are created every
one hour.
Step 2: Original ticket sent from the BAM to ticket server
A ticket sending process runs in BAM, which can check if there is any new ticket in the
BAM as frequent as once every minute. If a new ticket is generated, it will be packaged
& sent to the ticket server and a corresponding log is made for it.
To ensure the transmission of original ticket to the ticket server from the BAM in a most
speedy & secure way, TCP/IP is used at the bottom layer and an internally defined
communication protocol is used at the application layer. The ticket in the BAM is
transmitted to the ticket server in packets with unique packet number and the sending &
receiving terminals have detailed logs. Functions, such as automatic network
re-connection after disconnection, resending of ticket packages by BAM when no
confirmation message received and the filtering of repeated transferred ticket packages
by ticket server are provided.
Step 3: The ticket server receives original tickets from the BAM
6-27
The ticket server receives the ticket data packages from the BAM. After opening and
authenticating these packages, the server stores the original tickets in the hard disk. It
then sends confirmation messages to the BAM and makes corresponding logs.
Step 4: The ticket server processes the received tickets
After receiving an original ticket, the ticket server saves a copy as a backup and then
processes the original ticket. First of all, it sorts the tickets. This can be done on the
basis of the value of any field in the ticket. Besides, for fields like calling and called,
which are represented in BCD code, sorting can also be made on the basis of its prefix.
The sorting conditions can be field value relations (>, < or =) or combination of these
relations (and/or). Also, original tickets go through format conversion here, that is to say,
reformatting the binary original tickets into universal text tickets. The text format,
including the content, width of each field, filler, separator of the ticket, etc., can be set
and the fields can be customized, like adding a '(' in front of each ticket or a ')' at the end
of each ticket. Then the tickets sorted in corresponding category after processing.
Step 5: Reformatted ticket is transferred from the ticket server to the charging center
After storing the tickets to the place specified by the user, the ticket server provides the
charging center with the FTP/FTAM interface. It supports Server or Client as FTP &
Responder as FTAM and opens the generated tickets to the charging center. The
charging center gets tickets from the ticket server through the LAN or WAN. The ticket
server can also send tickets actively to the charging center through Client of FTP.
4) Definition of ticket file format
z Content and format of reformatted detailed ticket
The format of the reformatted ticket is shown in Table 6-1:
6-28
Table 6-1 Format of reformatted ticket
Item Content
All the fields contained in original detailed tickets, such as calling, called,
inbound trunk group, outgoing trunk group, start year, start month, start
day, start hour, start minute, start second, end year, end month, end day,
end hour, end minute, end second, duration (second), charged target,
Content list ticket type, charge type, call type, service type, Bearer Services, count of
B channels, Centrex group number, ticket type, CTX group number,
calling CTX private number, called CTX private number, calling user type,
call terminating cause, charging, connected number, charge number
initial set and terminal service
Alignment list Left-aligned and right-aligned
Filler list Space, zero and none
Separator list Comma, space, colon, slash, dot and none
Length Ranging from 0 to 99 digits
Customized domain Any character string can be customized
z Format and content of reformatted meter table ticket

The format for the reformatted meter table ticket is shown in Table 6-2:
Table 6-2 Format of meter table reformatted
Item Content
Fields, such as calling number, trunk group number, charged target, number initial
set, count of calls in table 1, count of calls in table 2, count of calls in table 3, count of
calls in table 4, count of calls in table 5, count of calls in table 6, count of calls in table
Content list
7, count of calls in table 8, count of calls in table 9, pages of table 1, pages of table 2,
pages of table 3, pages of table 4, pages of table 5, pages of table 6, pages of table
7, pages of table 8, pages of table 9 and pages of table 10.
Align list Left-aligned and right-aligned
Filler list Space, zero and none
Separator list Comma, space, comma, slash, dot and none
Length Ranging from 0 to 99 digits
Customized domain Any character string can be customized
5) Backup function of the ticket server

z Providing the automatic backup function and manual backup function. The user
can back up all ticket files in CD-ROM through the automatic backup function. The
result of the backup is stored or sent to the charging center. User's special
requirements can be met through manual back up of ticket files.
z The user can select the backup type in automatic backup mode: backing up
original ticket only, or final tickets only, or both. Original tickets and final tickets can
be backed up manually.
z Automatic backup modes include semi-auto mode and full-auto backup. The
former mode means that the user starts the automatic backup task through the
ticket station (the condition for terminating the backup can be specified). The latter
is a mode where the ticket server carries out automatic backup at a fixed time of a
day and the user does not need to carry out any operation (except for timing
replacement of disks). These two modes can be switched flexibly according to
6-29
needs. The full-auto mode conveniences the user and the semi-auto mode
provides the user with to a certain extent of flexibility. In general situation, the user
can select full-auto mode, while in some special situation, the user can use the
semi-auto backup mode.
z User control to the process of auto-back and manual backup is enabled. When
either of the two backup modes is in service, the user can suspend it. The user can
start automatic or manual backup through the ticket station at any time. If the
CD-ROM is found to be insufficient before its timing replacement, an alarm
message will be sent to the alarm box of the switch.
z As for final ticket files, tickets of different types can be backed up onto different
media, or only tickets of certain types can be copied.
z Support multiple backup.
z The user can view how many ticket files are stored on the backup disk and make
the label for MO on this basis.
6) Main technical indices for ticket server
The main technical indices for the ticket server include:
z The ticket server can process 1600 pages of original tickets per second.
z The alarms from the ticket server are sent to the BAM's alarm station, which then
sends all these alarms in unified manner to the alarm box of the switching system
for centralized alarms. When the ticket server is disconnected from the BAM, the
alarm box will also issue alarms.
z The minimum duration for the detailed ticket is 5 minutes from the subscriber
completing the call to the ticket being transmitted to the ticket server.
z The ticket server can support 20 terminals in operation and 60 operators.
7) Instructions about the ticket server
z TCP/IP is recommended for the network layer & transmission layer in the
connection between the ticket server & charging center and FTP or FTAM are
recommended for the application layer.
z The supported and not supported mode of X.25 connection between ticket server
and charging center
a. The ticket server is connected with the charging center via 2 routers. The routers can
be connected via X.25 protocol and the ticket server & routers are connected via
TCP/IP. This connection mode can match the ticket server of Huawei and it is illustrated
in Figure 6-6:
6-30
Bill
server
Net
adapter TCP/IP
Router
HUB
X.25
Router
HUB
Net
adapter
charge center
Figure 6-6 X.25 connection supported by Huawei's ticket server
b. Ticket server is connected with the charging center via one router and an X.25
adapter card is plugged into the PC of the charging center. Note that Huawei's ticket
server does not support this type of connection. The connection method is shown
in Figure 6-7:
Bill
server
Net
adapter TCP/IP
Router
HUB
X.25
X.25 card
charge center
Figure 6- 7 X.25 connection not supported by Huawei's ticket server
6.
6-31

Charging Subsystem

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Charging Subsystem

Hochgeladen von

Copyright:

Verfügbare Formate

Technical Manual

C&C08 Digital SPC Switching System Table of Contents

Chapter 6 Charging Subsystem.................................................................................................. 6-1

Huawei Technologies Proprietary

Chapter 6 Charging Subsystem

Figure 6-1 Charging Subsystem composition

6.1 Generation of Charging Information

The generation of the exchange charging information is conducted in two ways:

Huawei Technologies Proprietary

II. Generation of charging information

III. Storing the charging information

Main CPU Slave CPU

Figure 6-2 Storing of charging information

Huawei Technologies Proprietary

6.2 Fetching of the Charging Information

Figure 6-3 Process of fetching charging information

Huawei Technologies Proprietary

6.3 Transferred Storage of the Charging Information

6.4 Coordination with the Offline Charging System

Huawei Technologies Proprietary

6.5 The Format of Ticket File

Huawei Technologies Proprietary

[Partial Record Indicator]: 0.5 byte

Huawei Technologies Proprietary

13: Incoming trunk charged (the third party pays)

Huawei Technologies Proprietary

Huawei Technologies Proprietary

Indicates the charging object's Centrex group number (0~65535. 0xFFFF

Huawei Technologies Proprietary

0x0C: Russian operator with transfer facility

Huawei Technologies Proprietary

Huawei Technologies Proprietary

21: Activate absent subscriber

Huawei Technologies Proprietary

55: Use conference

Huawei Technologies Proprietary

89: Cancel remote CFU

Huawei Technologies Proprietary

[Charging pulse]: 4 bytes

Huawei Technologies Proprietary

2) Detailed ticket types

Huawei Technologies Proprietary

II. Meter table ticket

Huawei Technologies Proprietary

0xF1: Meter table statistics

Huawei Technologies Proprietary

2: Valid national number (telephone number of subscriber = trunk code + local

Huawei Technologies Proprietary

[Meter Table 8 Value]: 4 bytes

III. Meter table statistics ticket

Huawei Technologies Proprietary

[Validity]: 0.125 byte

Huawei Technologies Proprietary

[Meter Table 3 Value]: 4 bytes

IV. Trunk duration statistics ticket

Huawei Technologies Proprietary

0xF1: Meter table statistics ticket

Huawei Technologies Proprietary

[Incoming office call times]: 2 bytes

V. Free call statistics ticket

Huawei Technologies Proprietary

6.6 Ticket Server

Huawei Technologies Proprietary

BAM server Ticket