Ericsson AXE 2 Service Manual
Competence Development Centre
AXE Operation & Maintenance Platform
Exchange Data
Help Exit
PREFACE
Target Audience
This book is preliminary intended to be used as a course manual in the
Ericsson Operation and Maintenance training program. The book is a
training document and is not to be considered as a specification of any
Ericsson language or system.
Identification
EN/LZT 101 105/2 R1A
Responsibility
Training Supply
ETX/TK/ZM
Ericsson Telecom AB 1996, Stockholm, Sweden
All rights reserved. No part of this document may be reproduced in any
form without the written permission of the copyright holder.
Table of Contents
1. Introduction 3
1.1 Module Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Device and Route Data 5
2.1 Route Concepts and Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Definition of Regional Processors . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Definition of Extension Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4 Definition of Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.5 Connection of Devices to the Route . . . . . . . . . . . . . . . . . . . . . . 14
2.1.6 Printout of Device and Route Data . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Supervision Data for Trunks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 General Principles of Supervision . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Blocking Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Disturbance Supervision of Devices . . . . . . . . . . . . . . . . . . . . . . 23
2.2.4 Disturbance Supervision of Routes . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.5 Seizure Quality Supervision of Devices. . . . . . . . . . . . . . . . . . . . 26
2.2.6 Groups for Seizure Quality Supervision. . . . . . . . . . . . . . . . . . . . 27
2.2.7 Seizure Supervision of Trunks. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3. Connection to Group Switch 31
3.1 GSS in General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Basic Functions, Hardware and Software.. . . . . . . . . . . . . . . . . . 31
3.1.2 Hardware Structure and Switching . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.3 Control of the Switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.5 Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.6 Printouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.7 Blocking of Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Connection of SNT and DIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
i
AXE 10, Operation & Maintenance, Platform
3.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.2 Devices Connected to the Group Switch. . . . . . . . . . . . . . . . . . . 49
3.2.3 ETC (Exchange Terminal Circuit) . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.4 PCD (Pulse Code Device) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3 The SNT Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.1 Connection of SNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.2 Connection of Devices to the SNT. . . . . . . . . . . . . . . . . . . . . . . . 55
3.4 The DIP Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6 Appendix 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.6.1 Channel Associated Signalling, CAS. . . . . . . . . . . . . . . . . . . . . . 63
3.6.2 Common Channel Signalling, CCS . . . . . . . . . . . . . . . . . . . . . . . 64
3.6.3 Supervision of the PCM Line. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4. Size Alteration 67
4.1 Size Alteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1.2 Initial Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.3 Hardware Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.4 Extension by Using More Software Individuals . . . . . . . . . . . . . . 71
4.1.5 What is a Data File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.6 The Use of Size Alteration Events. . . . . . . . . . . . . . . . . . . . . . . . 73
4.1.7 Commands Related to Size Alteration. . . . . . . . . . . . . . . . . . . . . 74
4.2 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5. Analysis 77
5.1 Analysis in General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.1.1 The Use of Operating and Non-Operating Area . . . . . . . . . . . . . 78
5.2 Branching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3 Route Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3.1 The Sending Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3.2 The Commands Used to Define Routing Cases . . . . . . . . . . . . . 85
5.4 Charging Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.4.1 Charging Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.4.2 Charging Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.4.3 A Survey of the Charging Analysis . . . . . . . . . . . . . . . . . . . . . . . 89
5.4.4 Definition of Tariffs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.5 Definition of Tariff Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.4.6 Definition of Charging Case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4.7 The Calendar Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
ii
5.5 B-Number Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.5.1 An Example of an Analysis Table. . . . . . . . . . . . . . . . . . . . . . . . . 97
5.5.2 A Study (Case) of an Outgoing Call. . . . . . . . . . . . . . . . . . . . . . . 99
5.5.3 A Study Case of an Internal Call . . . . . . . . . . . . . . . . . . . . . . . . 103
5.5.4 Parameters in the Analysis Table. . . . . . . . . . . . . . . . . . . . . . . . 103
5.5.5 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.6 Pre-Analysis of B-numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
iii
1. Introduction
1.1 Module Objectives
Module Objectives
After completing this module the participant will be able to:
• Define various types of Routes in the exchange with Route Data as
well as connected Devices.
• Load, print and change Supervision Data for Trunks.
• Briefly describe the Group Switch.
• Perform connection of SNT and DIP.
• Perform Size Alteration of data files in the Data Store.
• Understand the main principles of analysis.
• Perform changes in Route Analysis, Charging Analysis and Bnumber Analysis.
Figure 1.1
Module Objectives
1.2 General
This module is named Exchange Data, Basic. The subjects covered in this
module are:
Route and Device Data
•
Supervision Data for Trunks
•
Group Switch Subsystem
•
SNT and DIP Data
•
Size Alteration
•
Route Analysis
•
Charging Analysis
•
B-number Analysis.
•
These subjects are based on AXE Local 12.3 for ordinary telephone calls.
(Not for ISDN calls using ISDN services.)
03802-EN/LZM 112 18 R1 1
Exchange Data Basic
2 03802-EN/LZM 112 18 R1
2. Device and Route Data
Chapter Objectives
After completing this chapter the participant will be able to:
• Define a Regional Processor.
• Define an Extension Module.
• Define a new Route and modify existing Route Data.
• Connect Devices to Routes and generate and interpret printouts of
the specified data.
• Load, print and change Supervision Data for Trunks.
Figure 2.1
Chapter Objectives
2.1 Route Concepts and Definition
2.1.1 General
To be able to set up a call between two exchanges you must have a route.
In this route devices must be connected. All devices in an exchange must
belong to an EM that are controlled by an RP-pair. This is the reason why
we have to start with defining the Regional Processors (RP).
2.1.2 Definition of Regional Processors
If the exchange is extended with new hardware devices, new Regional
Processors may be needed for the control of the new equipment. Howev er,
if some RPs have spare capacity (i.e. all EMs are not used), they can in
some cases be used for the extension. Figure 2.2, on the next page, shows
the parts of the system that are handled in this chapter.
03802-EN/LZM 112 18 R1 3
Exchange Data Basic
Figure 2.2
The control part of the AXE system
First of all, the hardware of the RP pair must be connected and the power
must be connected to the magazine. Howe ver , this i s not enough as the RP
pair must be defined in data as well. This means that some initial data is
loaded into the system and that the parts that take care of the maintenance
of the RPs are informed of their location. The location of the RP pair is
marked by an address strap on one of the boards in the RP and that address
must always be used when using commands related to the RP. The Operational Instruction “Connection of RP” describes the actions required for
the definition. The first command used for the definition of an RP pair is
the EXRPI command.
EXRPI:RP=rp,RPT=rpt,TYPE=type;
The RP and RPT parameters are used to indicate to the system the
addresses allocated to the RPs with the address strap. The TYPE parameter
is used to indicate the version of the RP as both old and new RPs can be
used in the same exchange. The Command Description of the command
EXRPI contains a list of valid RP types.
When the RP pair has been defined, the next step will be to define which
software units (programs) that should be loaded into the RP pair when
deblocked. The programs loaded into the RP should be some operating
4 03802-EN/LZM 112 18 R1
Device and Route Data
software and the regional software of the blocks connected to the RP (e.g.
the regional software of block BT1 is referred to as BT1R).
The command used to define the RP programs to be loaded is EXRUI.
This command will build up a table inside the APZ related to each RP pair.
The table can be used by the APZ when reloading it, e.g. in connection
with deblocking. Then the software indicated in the table is sent to the Program Store of the RPs in the RP pair. This also means that a copy of all
regional software units must be a v ailable in the CP as a backup. When ne w
equipment is installed in the exchange (e.g. a new type of BT devices), the
new RP program must be loaded into the CP by means of command
LAEUL.
The parameters included in the EXRUI command are RP and SUNAME
or SUID. The RP parameter is used to indicate one of the RPs in the RP
pair (only one has to be specified). The SUNAME and SUID parameters
are used to indicate the name or the identity of the software units that
should be included in the RP pair . Which parameter to use is determined as
follows:
SUNAME This parameter is used if there is only one version of the
software unit loaded in the CP. An example of a software
unit name is BT1R.
SUID If there is more than one version of the RP program
loaded into the CP, this parameter must be used to indicate
which version to use. This parameter is used if the version
of a Regional Software unit is changed because of software update or function change. An example of the
parameter is “5/CAA1052105/1R2A02”. The correct
identities can be printed by using command LAEUP.
When the loading table has been defined, perhaps using several EXRUI
commands, the RP pair can be put into service by deblocking it. The
deblocking is done by using command BLRPE which first includes a test
of the RP and then a reload of the software units specified in the table.
Please study figure 2.3, on the next page.
03802-EN/LZM 112 18 R1 5
Exchange Data Basic
Figure 2.3
The new RP programs are loaded into the CP and defined for the RP pair
6 03802-EN/LZM 112 18 R1
When the data has been specified, the EXRPP command can be used to
check it. Please study figure 2.4.
Figure 2.4
Answer printout of command EXRPP
All the data related to an RP pair can be removed by the EXRPE command. This command is used if the RP pair is to be removed from the
exchange.
Device and Route Data
2.1.3 Definition of Extension Modules
When the new RPs have been defined, it is time to define the equipment
they should control. As you probably know, this equipment is located in
Extension Modules using the same type of interface to the RPs. Figure 2.5
shows the principle of connecting two different types of EMs to the EM
bus.
Figure 2.5
Connection of two different types of EMs to the RP pair
03802-EN/LZM 112 18 R1 7
Exchange Data Basic
When the EMs are defined, the data in both the APZ and the blocks that
own the hardware is updated with various types of information. The data
in the block that controls the hardware is updated with information about
the address of the hardware (RP and EM addresses). This information is
required when sending signals to the hardware for initiating functions in
the hardware.
The command used to define the EMs is EXEMI and the following parameters are included for a normal definition:
EXEMI:RP=rp,RPT=rpt,EM=em,EQM=eqm;
RP: Indicates the RP that controls the EM in normal cases.
RPT: Indicates the stand-by RP. This RP must be the twin RP in an
RP pair.
EM: Address of EM (an address strap is used).
EQM: Used to indicate the equipment type and identity of the devices
in the EM. Example: EQM=BT1-32&&-63.
When the EM has been defined, it can be deblocked by command
BLEME. This means that the EM is put into service from a control point
of view. The devices in the EM are probably still blocked as more data
related to the devices must be specified.
If an EM is to be removed from the exchange, command EXEME is used.
When the data has been specified, the print command EXEMP can be
used. Figure 2.6 shows an example of a printout of command EXEMP.
Figure 2.6
Answer printout of command EXEMP
2.1.4 Definition of Routes
Before we discuss how routes are connected and defined in the software of
AXE, the route concept in AXE should be studied. In AXE, the concept
“route” has been extended slightly if compared with other, analog systems.
8 03802-EN/LZM 112 18 R1
Device and Route Data
There are basically three types of routes in the system:
1. External routes, e.g. routes to other exchanges
2. Internal routes, e.g. routes to Code Senders and Announcing
Machines
3. Software routes, e.g. routes to subscriber services or routes for regis-
ter individuals.
Figure 2.7 shows the three variants of the routes.
Figure 2.7
The three types of routes used in AXE
03802-EN/LZM 112 18 R1 9
Exchange Data Basic
All the three types of routes require “Route Data” in order to function in a
specified way. Route data is, as the name says, data related to a route in the
exchange. Examples of route data for an external route is the type of signalling system used, the function of the route (incoming or outgoing) and
the number of devices connected to the route. The route data is stored in
the block to which the hardware belongs. The Operational Instruction
“Connection of route for BT” is one of the documents available that
describes the commands that should be used. In this chapter, only the commands and the most common parameters are described. Supervision and
connection of the devices to the Group Switch are handled in other parts of
this Module.
How, then, is the route data defined in the exchange? The answer is the
two commands
lowing meaning:
•
EXROI
This command is used to initiate the route for the very first time. The
parameters included in the command are (not all shown):
−
EXROI
R, Route name
This parameter gives the route a name consisting of up to 7
characters. Characters like #, % and + can be used in the route
name to distinguish between incoming and outgoing routes.
and
EXRBC
. The two commands have the fol-
−
DETY, Device type
The device type indicates the type of de vices used in the block.
The parameter should be the same as the block name of the
block used for the route (e.g. BT1).
−
FNC, Function Code
The function code is used to indicate the function of the route.
The meaning of the parameter must be fetched from the Application Information of the block indicated in DETY. For external routes, the parameter is usually used to indicate the traffic
direction of the route.
•
EXRBC
This command is used when more route data is to be assigned to the
route. Also existing routes can be changed by this command. The command has several parameters of which only a few are explained here:
−
R1, Register Signalling Route
This parameter is used to indicate if another route must be
used for the register signalling. If MFC (Multi-Frequency
Compelled) signalling is used, the route name of the Code
Sender route is indicated here. Figure 2.8 shows the principle.
10 03802-EN/LZM 112 18 R1
Figure 2.8
Register signalling route
Device and Route Data
−
RG, Route Group
The Route Group parameter is used to prevent the traffic from
one exchange to be returned to the same exchange (also
referred to as “return blocking”). By giving all routes to and
from the same exchange the same RG value, the system will
not route the traffic back to the same destination.
Please study figure 2.9.
Figure 2.9
Return blocking principle
03802-EN/LZM 112 18 R1 11
Exchange Data Basic
−
RO, Origin for route analysis
For incoming routes, this parameter can be used if the Route
Analysis should be made differently for this route compared
with others. More about this in the Unit describing Route
Analysis.
−
PRI, Priority
Some incoming routes can be given priority. This parameter
can be used in various analyses in the exchange.
−
MB, Modification of B-number
This parameter can be used to add or delete digits from the Bnumber.
As already mentioned, there are several other parameters included in the
EXRBC command. For more details please study the Command Description and the Application Information for the blocks concerned.
When all the route data has been specified for the route, and if the route
should be put into service, it should be deblocked by using the BLORE
command. Note that only outgoing routes can be blocked/deblocked. The
command BLORP can be used to check if any outgoing route is blocked in
the exchange.
2.1.5 Connection of Devices to the Route
When all the route data has been specified, it is time to connect devices to
the route. Howev er, before this is done, the devices should be connected to
the Group Switch. How that is done is described in Unit 3 of this Module.
Before this step is started, the route has been properly defined by means of
EXROI and EXRBC. However, no devices are connected to the route. The
EXDRI command is used to make a connection in data between the
devices and the route:
EXDRI:DEV=dev,R=r;
In case of ISDN services special devices are required, but this is not the
case for ordinary telephone calls.
Figure 2.10 shows what the command does in the data of the block.
12 03802-EN/LZM 112 18 R1
Device and Route Data
Figure 2.10
The effect of command EXDRI in the data of a block
When all the devices have been connected to the route, they should be
taken into service by using the command EXDAI. This command will
change the state of the devices from “Pre-post service” to “service”.
Finally, the devices can be deblocked by using command BLODE. That
will enable the system to use the devices in traffic handling.
In most cases, the supervisory functions should be connected to the route
in order to activate functions like “Blocking supervision”. In case of an
extension of an existing route, the data related to t he supervisory functions
should be changed (the number of devices included in the route has
changed).
03802-EN/LZM 112 18 R1 13
Exchange Data Basic
2.1.6 Printout of Device and Route Data
When the data has been defined, and also during the definition, the data
loaded can be printed by using print commands. Some of the most useful
commands are shown below.
EXDEP, please study figure 2.11.
Figure 2.11
Printout of device data
EXDRP, please study figure 2.12.
Figure 2.12
Printout of the RP and EM that the device belongs to
14 03802-EN/LZM 112 18 R1
STRSP, please study figure 2.13.
Figure 2.13
Printout of device state survey
Device and Route Data
STRDP, please study figure 2.14.
Figure 2.14
Printout of device state survey and details
03802-EN/LZM 112 18 R1 15
Exchange Data Basic
Figure 2.15
Printout of route data
EXROP, please study figure 2.15.
16 03802-EN/LZM 112 18 R1
2.2 Supervision Data for Trunks
2.2.1 General Principles of Supervision
Telephony devices interwork with their environment, such as subscribers,
other exchanges and transmission equipment. A single disturbance in one
device does not mean that the device is faulty. The disturbance might come
from the environment. For that reason, the supervision of telephony
devices is rather a slow process. Several calls causing disturbances will in
many cases have to be registered before any actions are taken by the system. In some cases, the supervisory period will cover several days.
The actual supervision of the devices is performed by the blocks that own
the hardware. As an example, disturbances in devices belonging to block
BT1 are also registered in that block. Disturbances are registered by means
of counters in the software. In some cases, the counters are common to one
route and in others, there is one disturbance counter per device.
The errors that are to step the disturbance counter are to a great extent
determined by the protocol of the signalling system. Any abnormal event
such as time out, signalling errors and state error, are registered in the disturbance counter.
Device and Route Data
When should an alarm be initiated and what alarm class should be used? Is
the supervision activated or not? These types of questions are usually handled by blocks specially dedicated to the administration of the supervisory
functions. These blocks are located in the OMS, Operation and Maintenance Subsystem, and they handle functions such as:
•
changing of alarm levels
•
changing of alarm classes
•
activation and deactivation of the supervision
•
handling of commands and printouts.
When the supervision is activated, the block in OMS that administers the
function, reads the disturbance counters at regular intervals. The time
between the readings is usually between 10 seconds and 1 minute. If the
readings are too frequent, they will load the processor unnecessarily. The
read disturbance counters will then be compared with the stated alarm levels which are stored inside the block. For some types of functions, the
block that own the disturbed device will report each disturbance to the
block that handles the administration related to the function. Figure 2.16,
on next the page, shows an example of how the supervision can be made.
03802-EN/LZM 112 18 R1 17
Exchange Data Basic
Figure 2.16
General principle of supervision of telephony devices
2.2.2 Blocking Supervision
This function, handled by block BLOS, checks that the number of blocked
devices in a route does not exceed a preset value. The function counts the
number of manually, automatically and control blocked devices. If
required, the function can use several alarm limits tied to different alarm
classes. Figure 2.17 shows the principle.
18 03802-EN/LZM 112 18 R1
Device and Route Data
Figure 2.17
Alarm limits in the blocking supervision, example
The Blocking Supervision is always initiated per route and all commands
and printouts are related to a given route in the exchange. The function can
be used to supervise routes belonging to blocks of type BT, AS, CR, CS
and KR.
If no data has been specified for a route, e.g. the route has just been initiated, new supervision data will hav e to be loaded b y means of the BLURC
command. The parameters in the command are:
R=r,LVB=lvb1[&lvb2][&lvb3],ACL=acl;
The “R” parameter indicates the name of the route (the same as in
EXROI). The “LVB” parameter, Limit Value for Blocking, is used to indicate the maximum number of blocked devices in the route. If several values are to be used (as in figure 2.17) the values are listed and separated by
“&”. The last parameter is “ACL”, Alarm Class, which is used to indicate
the alarm class the alarm should have if the limits are exceeded. If several
limits have been specified, this parameter indicates the alarm class tied to
the first limit value. An example is:
03802-EN/LZM 112 18 R1 19
Exchange Data Basic
BLURC:R=ALPHA,LVB=10&20&30,ACL=A3;
If this command is used, the system will initiate the following alarms:
A3 alarm: if the number of blocked devices is between 10 and 20.
A2 alarm: if the number of blocked devices is between 20 and 30.
A1 alarm: if the number of blocked devices exceeds 30.
The blocking supervision of a route can be temporarily disconnected dur-
ing maintenance activities or other changes related to the route. It is also
possible to disconnect the blocking supervision permanently. The commands used to disconnect and reconnect the blocking supervision are:
BLURE:R=r[,PERM];
BLURI:R=r;
BLURE
The
PERM
“
command is used to disconnect the supervision. If the
” parameter is used, the supervision is permanently disconnected.
This means that the supervision data is erased. When the supervision is to
be connected again, the
BLURI
command is to be used.
The supervision data can be printed by using command
BLURP
example of the printout generated can be seen in figure 2.18.
. An
Figure 2.18
An example of a printout of the blocking supervision data
20 03802-EN/LZM 112 18 R1
2.2.3 Disturbance Supervision of Devices
This function supervises that the proportion of the number of disturbances
to the number of selections will not exceed a preset v alue. The supervision
is used to supervise individual devices of type CS, CR and some variants
of BT (not all types of BT can have this type of disturbance supervision).
In case of analogue CS and CR devices, they are blocked if a number of
consecutive disturbances are detected.
Disturbances are defined as disconnections not caused by the subscriber or
not allowed traffic cases. Examples are time out, not valid signals and
abnormal states in the signalling.
When a new route is defined which should have this type of supervision,
the data must be loaded by means of command DUIAC. The parameters
included in the command are:
DUIAC:R=r,ADL=adl,ACL=acl;
Parameter “R” indicates the name of the route concerned. Parameter
“ADL”, Allowed Disturbance Level, indicates the level in percent. If this
level is reached, an alarm with the alarm class according to parameter
“ACL” will be generated. The possible values in ADL are 1, 2, 4, 5, 10,
20, 25, 33 and 50%.
Device and Route Data
How, then, is the supervision made in block DISSD which handles the
function? The answer is a disturbance counter used to record both the seizures and the disturbances. Figure 2.19, on the next page, shows the principle.
03802-EN/LZM 112 18 R1 21
Exchange Data Basic
Figure 2.19
The use of a disturbance counter
For each seizure of the device, the counter is decremented by one. In case
of a disturbance, the counter is incremented by a value dependent on the
parameter ADL, Allowed Disturbance Level.
The loaded data can be printed by using the print command DUISP. Figure
2.20 shows an example of such a printout.
22 03802-EN/LZM 112 18 R1
Figure 2.20
The printout of the Disturbance Supervision of Individual Devices, example
Device and Route Data
2.2.4 Disturbance Supervision of Routes
This function is very similar to the one described in the previous chapter.
The only major difference is that this function supervises the disturbance
level of each route, not individual devices. The function is implemented in
block DISSR and the routes that can be supervised are the ones of type BT .
The function uses a disturbance counter like the one described in figure
2.19, with the only difference that there is one counter per route.
When a new route has been introduced in the exchange, or if some e xisting
data should be changed, command DUDAC shall be used. The parameters
included in the command are:
DUDAC:R=r,ADL=adl,ACL=acl;
Parameter “R” is used to indicate the route. Parameter “ADL”, Allowed
Disturbance Level, specifies the maximum disturbance level allowed in
the route (in percent). If this value is exceeded, an alarm with the alarm
class according to parameter “ACL” will be generated. The possible disturbance levels in parameter ADL are 1, 2, 4, 5, 10, 20, 25, 33 and 50%.
03802-EN/LZM 112 18 R1 23
Exchange Data Basic
When the data has been loaded, it can be printed by using the print command DUDAP. Figure 2.21 shows an example of such a printout.
Figure 2.21
Printout using command DUDAP
2.2.5 Seizure Quality Supervision of Devices
This function is used to supervise the ratio (quotient) of the number of seizures to the number of normal calls. What, then, is meant by “normal
call”? This is nothing but a time (usually set to 60 seconds) specified by
command which is used to indicate a minimum duration of a normal call.
This function utilizes the fact that subscribers connected to bad lines,
replace earlier than if they were connected to normal lines.
The average quotient is also calculated for the devices in the same route,
and each device in the route is compared with this value. If any of the
devices deviates more than a command specified value, an alarm will be
initiated. Two limits are used by the function:
•
one limit which indicates that the device is suspected of being faulty
•
one level which indicates that the device should be blocked.
When the function is started the very first time, i.e. when the exchange is
installed, the time for a “normal call” is loaded. This is done by using the
command SEQAC . This command ca n al so be used when time is cha nged
if other conversation times are used in the exchange (can be detected by
means of Traffic Recording). An example of how the time is changed is:
SEQAC:CTIME=55;
The normal conversation time is, in this case, set to 55 seconds. The time
can vary between 10 and 255 seconds.
24 03802-EN/LZM 112 18 R1
Device and Route Data
If the supervision is to be initiated for a new defined route in the exchange,
the same command is also used to load the supervision data related to the
function. An example of the command is:
SEQAC:R=BTOWN+,ACL=A3,QUOS=30,QUOB=60;
If this command is used, the supervision will be initiated for the route
“BTOWN+”. If any abnormal devices are detected, an A3 alarm will be
generated. If a device deviates by more than 30% from the average quotient, the device is suspecte d of being faulty. In that case, the device is still
in traffic (only fault marked). If a device deviates by more than 60% from
the average quotient, it will be blocked.
The data specified for a route can be printed by using command SEQAP.
Figure 2.22 shows an example of a printout generated by command
SEQAP.
Figure 2.22
Example of printout related to Seizure Quality Supervision
2.2.6 Groups for Seizure Quality Supervision
The Seizure Quality Supervision function uses the routes as groups if
nothing is indicated to the system. If there are requirements that new
groups should be defined, command SEQGI can be used to group routes
together. This means that the average quotient (Q) will be calculated for
the whole group. Different types of routes with different characteristics
can be grouped together with this function. Command SEQGI has only
one parameter:
SEQGI:R=r....;
Several routes can be specified in one command and the number of routes
included in one group is unlimited. When the groups have been specified,
command SEQGP can be used to print the routes included in each group.
Please study figure 2.23.
03802-EN/LZM 112 18 R1 25
Loading...