AXE Testing 1

of 152 /152
AXE System Testing 1 Exchange Data

Embed Size (px)

Transcript of AXE Testing 1

AXE System Testing 1Exchange Data

Table of Contents

1. Call Handling in AXEIntroduction 5 The Data Structure 6 Ringing and Supervision 10 Chapter Summary 16


2. Size AlterationIntroduction 17 Initial Setting 18 What is a Data file? 21 Chapter Summary 24


3. Device and Route DataChapter Introduction 25 Definition of Regional Processor 25 Definition of Extension Module 28 Definition of Routes 30 Chapter Summary 37


4. Analyses, a SurveyIntroduction 39 Analysis of B-number 39 Chapter Summary 44


6. Route AnalysisIntroduction 45 Analyses in General 45 The Basic Principles of Route Analysis 46 Chapter Summary 57


7. Hundred GroupsIntroduction 59



Exchange Data

What is a Hundred Group? 59 Specification of Area Code 60 Change of Hundred Groups 62 Chapter Summary 63

8. ChargingIntroduction 65 Pulse Metering and Toll Ticketing 65 Function Blocks in CHS 67 Analysis Tables, Survey 68 Traffic Activity Analysis 69 Charging Case Branching Analysis 71 Charging Program Analysis 72 Extended Charging Analysis 73 Tariff Class Analysis 74 Switching Class Analysis 74 Tariffs 76 Operational Instructions 77 Other Charging Related Services 77 The Calendar Function 79 Chapter Summary 81


9. B-number AnalysisIntroduction 83 Pre-analysis of B-number Information 83 Example of an Analysis Table 85


10.End-of-Selection AnalysisIntroduction 97 The Purpose of End-of-Selection Analysis 97 End-of-Selection Codes 98 The Analysis in Block RA 99 Actions Possible to Initiate in the EOS Table 100 Branching in the EOS Table 102 Commands 103 Chapter Summary 103


11.Access Barring and Time SupervisionIntroduction 1052


Table of Contents

Access Barring in General 105 Destination Codes 105 Access Barring Analysis 107 Time Supervision in general 109 Chapter Summary 110

12.A-number AnalysisIntroduction 111 Pre-Analysis of A-number Information 111 Why is A-number Analysis Performed? 112 Analysis Results 113 Loading and Changing Data 114 Chapter Summary 118


13.Equal Access AnalysisIntroduction 119 Survey 119 Subscriber category and signalling system 120 Carrier Access Code not Dialled 120 Carrier Access Code Dialled by the Subscriber 122 Example of an Analysis Table 123 Commands 123 Chapter Summary 124


14.Service Screening AnalysisIntroduction 125 The Analysis 125 The Services that can be Barred 126 The Commands 126 Chapter Summary 126


15.ISDN-Specific AnalysesIntroduction 127 Telecommunication Service Analysis 127 Service Indicator Analysis 130 Chapter Summary 132


16.Semipermanent Connections


Exchange Data

Introduction 133 General about Semipermanent Connections 133 Command Survey 140 Chapter Summary 140


1. Call Handling in AXE

Chapter ObjectivesAfter completing this chapter, you will be able to: describe the block interwork during an internal call describe the block interwork during an outgoing call using MFC and CCITT No 7 signalling.Figure 1.1

1.1 IntroductionThe internal interwork of an AXE exchange is impossible to see. This creates a problem as errors in program and data are difficult to find as compared with analog exchanges. This chapter describes how ordinary calls are handled by the software of AXE. Although the description is simplified, the information given will greatly facilitate the handling of exchange data.


Exchange Data

1.2 The Data StructureBefore studying the traffic handling inside the AXE software, we must take a look at the internal data structure. The data structure and the interrelationship between data and hardware are important features of the AXE software. Please study Figure 1.2.

Hardware LIC Regional software LIR Central software LIU Program Data One record per LIC

Figure 1.2

The structure of one function block

If a block has hardware, like the block LI in the figure, there are of course hardware circuits inside the magazines. The regional software in the RP or the EMRP controls the hardware and takes care of the routine tasks. Any changes in operation points are reported to the central software by means of a signal that includes information about the affected device. The central software contains a program and some data. The data is divided into records where each record represents one hardware circuit. Each record contains variables which are used to store data about the device. Information like state of device and number of disturbances is stored in the variables. The number of records in the data of block LI must be equal to the number of hardware devices. Blocks (such as RE and CJ) that do not contain hardware may also have records. In this case one record is used to store the call data for one call. The number of records required inside the blocks is dependent on the size and the traffic volume of the exchange. If the block RE contains 100 records, it can take part in the setting-up of 100 simultaneous calls. When the different traffic cases are described in this chapter, each block is illustrated by a box with the block name inside. The box represents the program and the data of the block. However, it must be noted that one record inside the block is specially reserved for the call. All records belonging to the same call are linked to each other by means of pointers. The pointers point from one record to another, creating chains of records6

Call Handling in AXE

inside the software. These chains must be intact as long as a call is established. During disconnection of the call, the chains are broken and the participating records are set to idle again.


Connection of RegisterIn this document the call handling in AXE is described by means of a number of figures with explanatory text. Only the hardware and the central software of the blocks are shown. Please study Figure 1.3.

LIC EMTSSubscriber Switching Subsystem Subscriber Control Subsystem Traffic Control Subsystem Figure 1.3




1 SUA/SC 2

Connection of register and sending of dial tone

When a subscriber lifts the handset, this is detected by the line interface to which he/she is connected. The regional software of block LI sends a message to the central software indicating the event. Next, block CJ is contacted in order to coordinate things inside subsystems SCS and SSS. The following is then done in the software (the numbers refer to the figure): 1. Block CJ, combined junctor, sends a signal to block SUA, subscriber analyses, and block SC, subscriber categories. SC is the block that stores all the categories of all subscribers in the exchange and block SUA handles analyses and some logic functions related to the traffic handling. SC checks if the subscriber is allowed to make a call and if subscriber services are activated (e.g. fixed destination call). Some categories relating to analyses (e.g. origin for charging and routing analysis) are fetched in SC and then sent to block RE, register. This block will coordinate all work until the call has been established. One record in block RE is then seized for the call. This record will, among other things, store all digits dialled by the subscriber. When a register record has been seized, block CJ is noted about this event. CJ can now order other blocks inside SCS and SSS to prepare for the call.




Exchange Data


A KRC has previously been connected to the LI via the time switch. A dial tone is now ordered from the hardware. The tone is generated in the time switch and sent towards the subscriber.

In the next phase, the subscriber dials the digits. Figure 1.4 shows how a digit is handled inside the software of the system.

LIC EMTSSubscriber Switching Subsystem Subscriber Control Subsystem Traffic Control Subsystem Figure 1.4






Reception of a digit


The digits are received by the KRC (key-set code reception circuit) which sends them to the central software of the block. Block KR will then send them to CJ which supervises the time between the dial tone and the first digit. In some cases, subscriber services should be activated if no digits are dialled. CJ does not store the digit but sends it immediately to RE for further handling. The register record reserved for the call stores each incoming digit and immediately sends them, one by one, to block DA (digit analysis) for analysis. Block DA delivers analysis results depending on the digits dialled and the data inside the B-number analysis table. A table is specified for each exchange because the routing plan and numbering plans determine its contents. Examples of analysis results are information about how the call is to be routed and charged, and in some cases how the number is to be modified.

2. 3.


Identification of B-subscriberWhen all digits have been received, the register knows that the call is a terminating call in the exchange. This information has been delivered as an analysis result from block DA after the analysis of some digits. Figure 1.5 shows the sequence when the B-subscriber is identified and seized.


Call Handling in AXE






Subscriber Switching Subsystem Subscriber Control Subsystem Traffic Control Subsystem Figure 1.5

LI LI 3 2 1 SUA/SC



Identification and seizure of B-subscriber


The register (block RE) orders blocks SUA and SC to check if the B-subscriber has any subscriber services activated. Examples of services checked are all variants of diversion services (e.g. immediate diversion). If no services are activated, the state of the subscriber is checked. Block LI is requested to seize the B-subscriber if he/she is idle at the moment. If the B-subscriber was idle, the state changes to busy and a signal is sent back to SC. If the subscriber was busy, some subscriber categories had to be checked in SUA/SC. Services like transfer on busy and call waiting are affected by the state busy.



When the register gets the signal indicating that the B-subscriber is seized, the call establishment can continue.


Exchange Data

1.3 Ringing and SupervisionFigure 1.6 shows the last part of the call establishment.





Subscriber Switching Subsystem Subscriber Control Subsystem Traffic Control Subsystem Figure 1.6





Group Switching Subsystem Charging Subsystem




Through-connection to the B-subscriber


Block RE orders CJ to seize a record for the B-subscriber and to set up a connection through SSS. Note that there is one CJ record for the A-subscriber and one for the B-subscriber. Block JT, junctor terminal, is requested to seize a channel from the subscriber stage to the group switch. A channel is reserved for both the A and B-subscriber. Block TS, time switch, is ordered to connect the subscribers to the selected JT channels. A path is established for both the A and B-subscriber. The charging has to be prepared for and block CHMON, charging monitoring, is included in the call. This block co-ordinates the functions inside the subsystem CHS. Depending on the charging method used, various blocks in subsystem CHS are included in the call. Block GS, group switch, is requested to set up a path between the two selected JT-channels. All preparations are now completed and block LI is requested to send a ring signal to the B-subscriber. A ring control tone is sent to the A-subscriber at the same time.




5. 6.

When the call has been established, the register (block RE) has fulfilled its task and can leave the call. The call will be handed over to block CLCOF, which will supervise and disconnect it (disconnection means that all the10

Call Handling in AXE

devices involved resume idle state). The charging is handled by block CHMON. Figure 1.7 shows the principle.





Subscriber Switching Subsystem Subscriber Control Subsystem Traffic Control Subsystem Figure 1.7





Group Switching Subsystem Charging Subsystem


Call supervision by block CLCOF and charging coordinated by block CHMON


Outgoing Call, Route AnalysisAn internal and an outgoing call start in exactly the same way. A subscriber dials some digits which are stored in the register and sent for analysis in block DA. The point where an outgoing call starts to differ is when the B-number analysis in block DA indicates that the call is an outgoing call. This is indicated to the register by means of a so-called routing case. The routing case must be further analysed in order to see which outgoing route should be selected. The outgoing route to be used may depend on a large number of factors such as subscriber categories and time and date. Figure 1.8 shows the block interwork during the analysis of the routing case.


Exchange Data

LIC EMTS Subscriber Switching Subscriber Control Traffic ControlFigure 1.8










Analysis of routing case

1. 2.

A digit is sent to the register from block CJ. The digit is as usual sent to block DA for analysis. The result of the analysis is a routing case (RC). Each RC has a number which defferentiates it from other RCs. The RC is returned to the register for further processing. Block RA, route analysis, is requested to analyse the routing case. Depending on a large number of factors, which will be studied in chapter 6 of this book, an outgoing route is selected. The identity of the route is sent back to the register together with some more parameters used to control the signalling.



Connection of Code SenderThe call establishment is completely controlled by the register which has information about routes, categories etc. For the establishment of calls to other exchanges, the register is controlled by the so-called sending program. The sending program was delivered from block RA at the same time as the identity of the outgoing route was indicated. The sending program tells the register when to seize the route, when to call the other exchange and finally which digits to send to the other exchange. Figure 1.9 shows the next part of the setup phase for an outgoing call.


Call Handling in AXE



EMTS LIC 6 Subscriber Switching Subscriber Control Traffic ControlFigure 1.9

CSR 5 CSR KR 3 BT KR Trunk and Signalling







1 Group Switchin

Seizure of route and connection of Code Sender


The register requests block BT to select an outgoing device in a specified route. BT stands for both-way trunk and this is the block that handles the channels in the PCM systems from a traffic handling point of view. When a device in the route has been selected for the call, RE orders block GS to reserve a path from the JT channel to the outgoing device. The path is only reserved in software. Block BT checks the data related to the route and finds that a code sender must be used for the register signalling. Block CSR, code sender and receiver, is requested to select a deviceto be used as a code sender. When a device has been selected, it must be connected to the selected channel. The tones in this signalling system are sent in band, which means that the information is sent on the speech channel before the speech. Block CSR will therefore request block GS to setup a path immediately. All preparations for the sending of the first digit are now completed. Block CSR orders the regional software of the block to send the digit from the hardware. The digit, which is coded by two mixed tones, is sent through the group switch to the selected channel. This channel will later on be used for the speech connection as well. Block BT request block ET to send a line signal to the other exchange. The signal is a seizure signal telling the other exchange that a call is coming. The seizure signal will be sent on channel 16 if a 32-channel PCM system is used.13






Exchange Data

In the other exchange, the line signal on channel 16 will be detected by block ET, and block BT will be notified. Block BT will request a code receiver and the CR is connected through the group switch. After that, a register record is reserved for the call. The CS in exchange A can now talk to the CR in exchange B. Please study Figure 1.10.

Exchange A GS ETC

Exchange B ETC GS



Figure 1.10

Connection of code receiver in exchange B


Outgoing call using CCITT No. 7If another signalling system is used for the call, the signalling will be slightly different. In this chapter, a call with CCITT No. 7 will be studied. Figure 1.11 shows the signalling network used.

STP Signalling

A SpeechFigure 1.11


Example of signalling network when CCITT No 7 is used

As Figure 1.11 shows, the speech and the signalling information are sent on separate routes. The STP, signalling transfer point, will read the destination address included in the message and send it on to exchange B. Figure 1.12 shows the block interwork for an outgoing call.


Call Handling in AXE



To STP Speech ST-7 6 C7ST2 5 C7DR2Common Channel Signalling Subsystem


Subscriber Switching Subsystem Subscriber Control Subsystem Traffic Control Subsystem



GS KR 1 3Group Switching Subsyste

C7BTC 2 C7OTHTrunk and Signalling Subsystem




Figure 1.12

Outgoing call with ITU-T No. 7

1. 2. 3. 4.

The register orders selection of an outgoing device in the route indicated by the route analysis (the same principle as in Figure 1.8). As the call is an outgoing call, block C7BTC requests help from block C7OTH (C7 outgoing traffic handling). The register delivers all call data to block C7OTH. The data includes the A-number, and B-number and the category of the A-subscriber. When all data has been assembled, a message is sent to block C7DR2 (C7 distribution and routing). This block contains tables of all the defined destinations in the signalling network. In this case, the address of the message will be exchange B (see Figure 1.11). The message, which now has the standardized ITU-T No 7 format, is sent to block C7ST2 (C7 signalling terminal). This block owns the hardware, i.e. the signalling terminals used to send the messages. The message will be sent to the signalling transfer point and then rerouted to exchange B. The rerouting in the STP is handled by block C7DR2.



Exchange Data

1.4 Chapter SummaryFrom this chapter you should remember these points:

Records inside the blocks are reserved for each call. The records reserved for a call are linked to each other by means ofpointers.

The pointers create chains in the software of the system. The register, block RE, is responsible for the establishment of all typesof calls.

Block CJ coordinates events inside subsystems SCS and SSS. Block CLCOF supervises and disconnects established calls.


2. Size Alteration

Chapter ObjectivesAfter completing this chapter, you will be able to: describe the main principles of size alterations perform size alterations generate and interpret printouts related to size alteration explain the use of size alteration events find the correct size alteration events in the B-module.Figure 2.1

Chapter Objectives

2.1 IntroductionSize alteration is the name of the function used to change the file sizes in the data store of the central processor. The changes are normally initiated by a change in the size of the exchange or in the traffic intensity of the exchange. Examples of changes in the size of the exchange are addition of more subscribers or more trunk lines added. If the traffic intensity is increasing, the extension of the number of register individuals have to be changed. This chapter describes the commands used to perform size alterations in the AXE software. When a size alteration is made, the affected part of the AXE system is the data store in the CP. In this store, the data related to all the blocks are stored. The size of the data, i.e. the number of data individuals, is changed by the function size alteration. The program store is not affected by this function as there is no change of the function of the system. If new or modified functions are loaded into the exchange, the process referred to as function change is used. Figure 2.2 shows the difference between these two methods.


Exchange Data

Function Change:

Central Processor Data Program Store Store Size Alteration: More data created for one function

New or modified function

Figure 2.2

The parts in the exchange affected by the functions Size Alteration and Function Change

2.2 Initial SettingThe initial size of the data records in the data store is set when the exchange is installed. The information about the sizes to set originates from the customer in the form of filled in data forms or similar information. The information is referred to as exchange requirement. The document exchange requirement is the input to the department inside Ericsson that produces the initial data. The process is referred to as data transcript. One of the activities included in the data transcript, is the setting of the file sizes in the software of the exchange. The output from the data transcript is a command file with commands related to size alteration and also other functions described later on in this Module. The commands with size alterations are loaded as one of the first files when loading the exchange data. This has to be done because no other data can be loaded before the file sizes in data have enough space for storage of the data. Figure 2.3 shows the principle.



Size of exchange: - number of trunk lines - number of subscribers - traffic intensity - services

Exchange Requirement

Data Transcript

Command file with the initial exchange data. Commands for Size Alteration included.

Figure 2.3

The production of the initial exchange data for one exchange18

Size Alteration


Extension with HardwareIf the number of trunk lines in an exchange is extended, there is usually requirements that more hardware is installed as well. This means that more ETC boards (or magazines for older types of ETCs) have to be installed in the exchange. For each channel in the PCM system (24 or 32 channels per ETC), there is some data in the data store that defines e.g. the state of the device and to which route it belongs. This fact, that there is data related to each hardware unit, require that the file sizes in the data store is changed by means of a size alteration. Please study Figure 2.4.

New hardware

Existing hardware

RP CP Data Store

More data required

Figure 2.4

Extension of hardware requires change of file sizes in the data store

When the hardware is installed in the exchange, various operational instructions have to be used depending on hardware type (the names of the instructions are Connection of ....). These operational instructions describe the commands and actions required to connect the new hardware in software.


Extension by using more Software IndividualsIn most cases of size alteration, only software is affected. Here are some examples of changes that only affect software: 1. If the traffic intensity (Erlang) is increasing in the exchange, more Register individuals are required to handle more simultaneous call setup. In this case, no additional hardware is required as the block RE is implemented in software only. If more subscribers would like to have a certain subscriber service (e.g. call transfer), more data individuals are required in order to handle more call transfers at the same time. Also the storage capacity of the service must probably be increased (e.g. the C-number in case of call transfer). Also in this case, only software is affected as all subscriber services are implemented in software only.



Exchange Data


Analysis tables have space for a limited number of analysis cases. The size of the analysis tables are set by means of a size alteration. Examples of such tables are the analysis table for the B-number analysis and the charging analysis table. If more analysis cases are to be introduced (e.g. more charging cases or new B-number series), a size alteration is used to create more space in the table.

Figure 2.5 gives an example of a change when only software is affected.

Program Store

Data Store New individuals created

Program of block RE Register individuals in Data StoreFigure 2.5

New register individuals are defined by means of a Size Alteration

If only a size alteration is to be made in the exchange, the operational instruction Size Alteration of Data Records has to be followed. Note that this instruction also will be used for reduction of data files.


Size Alteration

2.3 What is a Data file?A size alteration is affecting a data file consisting of data records (referred to as an individual in some cases). What, then, is a data record? Please study Figure 2.6.

GS New hardware means new records in data

Logical data structure:

Variable 1 Variable 2

Variable n

File One record per deviceFigure 2.6

Records and data files in one function block

The hardware located in the EMs must have some data related to it in the data store. For the same type of hardware in one block, the same type of data can be used. At design, one record is described by the designer of the function block. The record is the data required for one device. If the block contains 16 devices for one exchange, the number of records must also be 16. These 16 records make up one data file and the size of that file is in this example 16. If more hardware devices are to be added to the block, a corresponding change of the number of records in the data file is required. The change of the number of records is made by using commands belonging to the function size alteration. As already mentioned, most cases of size alteration involves no hardware. Only the file size in the data store will have to be affected in order to increase the number of devices. It should also be noted that one function block usually contains more than one file. As an example, one type of record is used to store data related to the devices inside the block and one type of records is used to store the data related to the routes defined in the block. This means that the block has two different files in the data store that can be changed independently of each other.


The use of Size Alteration EventsIn order to find the block or the blocks that are affected by a size alteration, the AXE system uses a numbering of the size alteration cases.21

Exchange Data

This number is referred to as size alteration event or just SAE. The SAE is used as a parameter in all the commands related to the size alteration function. Also the documentation in the B-module uses the SAE number in various documents and lists. There are two different types of size alterations in the AXE:

Global size alteration eventThese events will affect files in more than one block. An example is the number of routes in the exchange. Several blocks in the system store information about each route and all these blocks require the same file size (e.g. blocks for statistics and supervision).

Local size alteration eventThese events will only affect one block in the exchange. Examples of such events are the number of devices inside one block. The size alteration events (the numbers) are allocated in a special way in order to make it possible for the system to know which system (APT or APZ) and which type of event it is (local or global). The following numbering has been used inside the system:

Global events: APT: 000-299 APZ: 300-499 Local events: APT: 500-799 APZ: 800-999

This means that all SAE higher than the number 499 are local events. This is important to know as the parameters included in the commands related to the function are affected. More about that in next chapter.


Commands Related to Size AlterationThere are only three commands related to the function for size alteration. The three commands are:

SAAIIThe command is used to increase the files in a size alteration event.

SAADIUsed when decreasing the file sizes in one SAE.

SAAEPUsed when printing the number of individuals currently defined for the SAE. The two commands for changing the file size (SAAII and SAADI) have an optional parameter BLOCK=block. This parameter must be used if the SAE is a local event (499). The reason for having this parameter is that the local SAEs (e.g. SAE=500) use the same SAE number for several blocks. As an example, all the blocks that have telephony devices use


Size Alteration

SAE=500 for changing the number of devices in the block. If the operator wishes to change the number of BT1 devices, the format of the command is: SAAII:SAE=500,BLOCK=BT1,NI=XX; The parameter NI=XX in the command is the parameter indicating the total number of records after the change. Note that the total number is stated, not the number of records added. When the change has been ordered by the operator, the system will reallocate the data store in order to create more space for the variables included in the records. This reallocation will take some time to perform as much of the data has to be moved in the store. The work has to be done at a low priority in the system as traffic is handled at the same time. The time is takes i usually 5 to 10 seconds but it could take several minutes for a global event affecting several blocks. The result of the size alteration is sent to the operator in the result printout called DATA FILE INFORMATION. Figure 2.7 shows the format of the printout.



NI 128



The result printout for the Size Alteration

How, then, should the SAE numbers be found in the exchange library? This number is required in all the commands for the Size Alteration Function and it must be found before the work can start. There are two ways to find the SAE number: 1. In the application information of the block affected This method is used if the block is known and the SAE number is wanted. In the application information, all the SAE numbers related to the block can be found. In the parameter list in the last part of B14 This list is sorted in numerical order starting with SAE=0. The list contains information on the block/blocks affected by the event as well as information about how to calculate the number of individuals. This method is used when the SAE number is known and the block or the information about the event is wanted.


Figure 2.8 shows the principle.


Exchange Data

Block is known Application Information for the block (B14)

SAE number

SAE number is known Parameter List (B14)Figure 2.8

Block (and more information)

Two ways to find the SAE numbers in the exchange library

2.4 Chapter SummaryFrom this chapter you should remember these points:

Size alterations have to be made if more devices are connected to theexchange or if the traffic intensity is increasing.

The function creates more records in the data store for a specificfunction.

The global SAE affect more than one block and requires no parameterBLOCK=block in the commands.

The local SAE affect one block only and requires the parameterBLOCK=block in the commands.

The application information of the block indicates the SAE numbers forthe block.


3. Device and Route Data

Chapter ObjectivesAfter completing this chapter, you 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.Figure 1.1

Chapter Objectives

3.1 Chapter IntroductionAll hardware in the AXE system are controlled by regional processors and stored in extension modules. In case of extension in the exchange, new processors and extension modules have to be defined. Routes are used to interconnect exchanges and to define entry points to functions inside the AXE exchange. Routes must first of all be defined in data by means of commands. When they are defined, the function of the route can be changed by adding route data with commands. This chapter shows the commands required for defining routes as well as some useful printouts related to routes.

3.2 Definition of Regional ProcessorIf the exchange is extended with new hardware, there might be a need for new regional processors for the control of the new equipment. However, if some RPs have spare capacity (not all EMs used), that RP pair can in some cases be used for the extension. Figure 1.2 shows how the regional processors and the extension modules are interconnected to each other.


Exchange Data


EM EM RP New RP Pair

Central ProcessorFigure 1.2

Extension of the control system of AXE

First of all, the RP pair must be connected in hardware 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 noticed of there location. The location of the RP pair is determined 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 command EXRPI. The command has the following parameters: EXRPI:RP=rp,RPT=rpt,TYPE=type; The parameters RP and RPT are used to indicate to the system the addresses allocated to the RPs with the address strap. The parameter TYPE is used to indicate the version of the RP as both old and new RPs can be connected to the same exchange. The command description of the command EXRPI contains a list with valid RP types. When the RP pair has been defined, next step will be to define which software units (programs) that should be loaded into the RP pair when they are deblocked. The programs loaded into the RP should be some operating software and the regional software of the blocks connected to the RP (e.g. regional software of block BT is referred to as BTR). The command used to define that 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 them, e.g. at deblocking. At deblocking, 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. In those cases when new equipment is installed in the exchange (e.g. a new type of BT devices), the new RP program has to be loaded into the CP by means of command LAEUL.


Device and Route Data

The parameters included in command EXRUI are RP and SUNAME or SUID. The parameter RP is used to indicate one of the RPs in the RP pair (only one has to be specified). The parameters SUNAME and SUID 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 by the following:

SUNAMEThis 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 BTR.

SUIDIf there are 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 commands EXRUI, the RP pair can be put into service by deblocking them. The deblocking is made by using command BLRPE and the command includes first a test of the RP and then a reload of the software units specified in the table. Please study Figure 1.3.

PS1 2


SP LAEUL:...;Already loaded RP program New RP program


Loading of RP during deblocking

Loading table defined by EXRUI

Figure 1.3

The new RP programs are loaded into the CP and defined for the RP pair

All the data related to an RP pair can be removed by using the command EXRPE. This command is used if the RP pair is to be removed from the exchange. When the data is specified, the command EXRPP can be used to check the data specified. Please study Figure 1.4.


Exchange Data