Loading...
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.1Basic 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 B- number 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.1General
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.2Definition 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. However, 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. However, this is 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 available in the CP as a backup. When new 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 soft- |
|
ware 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 |
Device and Route Data
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.
2.1.3Definition 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.4Definition 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 register 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 EXROI and EXRBC. The two commands have the following 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):
−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.
−DETY, Device type
The device type indicates the type of devices 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 |
Device and Route Data
Figure 2.8
Register signalling route
−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 B- number.
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.5Connection of Devices to the Route
When all the route data has been specified, it is time to connect devices to the route. However, 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 the 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.6Printout 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 |
Device and Route Data
STRSP, please study figure 2.13.
Figure 2.13
Printout of device state survey
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
EXROP, please study figure 2.15.
Figure 2.15
Printout of route data
16 |
03802-EN/LZM 112 18 R1 |
Device and Route Data
2.2 Supervision Data for Trunks
2.2.1General 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.
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.2Blocking 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 have to be loaded by 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 during 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;
The BLURE command is used to disconnect the supervision. If the
“ PERM” 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. An example of the printout generated can be seen in figure 2.18.
Figure 2.18
An example of a printout of the blocking supervision data
20 |
03802-EN/LZM 112 18 R1 |
Device and Route Data
2.2.3Disturbance Supervision of Devices
This function supervises that the proportion of the number of disturbances to the number of selections will not exceed a preset value. 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%.
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 |
Device and Route Data
Figure 2.20
The printout of the Disturbance Supervision of Individual Devices, example
2.2.4Disturbance 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 existing 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.5Seizure 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 can also be used when time is changed 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 suspected 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.6Groups 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...