You are on page 1of 204

AXE System Testing 1

Input/Output Group 20, IOG 20

PREFACE
This book is intended to be used as a course material in the Ericsson training program. The book is a training document and contains some simplifications of any Ericsson system or tool. The contents of this book are subject to revision without notice due to continued development of the described systems and tools. To be able to fully benefit from the contents of this book, the participants should attend the course, which adds to this book exercises illustrating the concepts, techniques and tools described. Any comments on this book will be appreciated. The Student Book is used in the following courses:

LZU 108 1410 LZU 108 1413 LZU 108 1416 LZU 108 1461

Responsibility This Learning Product is prepared by: MV/ETX/X/HCX

Table of Contents

1. Introduction to AXE IO System


1.1 1.2 1.3 1.4 1.5 1.6

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 SP-based IO Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Input/Output Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 HW components of an IOG 20 IO system . . . . . . . . . . . . . . . . . . . 7 IO Device Functions and Characteristics. . . . . . . . . . . . . . . . . . . 13 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2. Subsystems in the AXE IO System


2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subsystems in SP-based IO Systems . . . . . . . . . . . . . . . . . . . . . Support Processor Subsystem (SPS) . . . . . . . . . . . . . . . . . . . . . Man-machine Communication Subsystem (MCS). . . . . . . . . . . . File Management Subsystem (FMS) . . . . . . . . . . . . . . . . . . . . . . Data Communication Subsystem, DCS . . . . . . . . . . . . . . . . . . . . The Software Structure of the IO Subsystems. . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17
17 17 18 20 22 23 27 30

3. Hardware Structure
3.1 3.2 3.3 3.4 3.5 3.6 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subracks and boards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LEDs and Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31
31 31 32 35 38 41

4. FMS applications
4.1 4.2 4.3 4.4 4.5 4.6 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FMS Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Storage medium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . File attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43
43 43 43 45 49 49

IOG 20

4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

Operation of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The duplicated file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Corrupt Files and File Recovery . . . . . . . . . . . . . . . . . . . . . . . . . File protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Infinite Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . File Process Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Decompression of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Log in AXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55 60 64 65 65 69 81 82 82

5. System Backup Handling


5.1 5.2 5.3 5.4 5.5

85

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Backup Functions of the CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Command Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Backup of the SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6. MCS applications
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12

107
107 107 109 120 125 126 127 130 133 138 139 140

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The functions of MCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing of Printouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standby Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Device Attendance Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alphanumeric Information on File . . . . . . . . . . . . . . . . . . . . . . . MCS directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The MCS Transaction Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IO device load regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7. MCS - Command handling


7.1 7.2 7.3 7.4 7.5 7.6

141
141 141 143 145 146 148

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AXE Command Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entry Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subcommands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Mode and CPT Commands . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table of Contents

8. DCS Applications
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11

149
149 149 150 152 153 160 163 170 171 175 179

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General on Data Communication . . . . . . . . . . . . . . . . . . . . . . . The OSI Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General on DCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCS concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection of DCS ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition of Port for AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition of Port for X.25 Data Link . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9. Support Processor Subsystem (SPS)


9.1 9.2 9.3 9.4 9.5 9.6

181
181 181 181 182 183 188

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Hardware of SPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Software Functions of SPS. . . . . . . . . . . . . . . . . . . . . . . . . SP Hardware Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10. Start of SPG


10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8

189
189 189 190 191 192 196 197 198

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cold Start or Single Start of Both Nodes . . . . . . . . . . . . . . . . . . Command Initiated Restart of Node . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IOG 20

1. Introduction to AXE IO System

Chapter Objectives
After completing this chapter the student will: Describe the two main tasks of the IO group Name the different units and buses that together constitute an IOG 20 Explain the concepts node and link Explain the concept SPG and give the RP addresses used by the IO system Explain the main usage of the hard disk drives, flexible disk drive and optomagnetic disk drive Explain the main usage of data links in an IOG
Figure 1.1

Chapter Objectives

1.1 Introduction
This chapter gives an overview of the IO system IOG 20 in the AXE.

1.2 SP-based IO Systems


This book provides a description of SP-based IO Systems as suited to the work of AXE system technicians. SP is an abbreviation for Support Processor, the separate processor that controls the IO system. The IO system may be controlled by one or up to eight support processors. Several variants of SP-based IO systems in AXE exist today: IOG 11 A, IOG 11 B, IOG 1 C, IOG 11 B5, IOG 11 C5, IOMC, IOG 20 BP, IOG 20 B and IOG 20 C. This book deals with IOG 20 B-P, IOG 20 B and IOG 20 C only. The functionality of the IOG 20 and the variants of IOG 11 is similar. In some cases this book will indicate when a certain function is unique for IOG 20, as compared to IOG 11. The three versions of IOG 20 are described in detail later, but they are, in short two full size versions, for serial and parallel RP bus, and one compact size version.

R1B

AXE IO System, IOG 20

Note that an IOG 20 and an IOG 11, theoretically may coexist in the same switch, but its not recommended. The description will include such general topics as:

the subsystems included in SP-based IO Systems the hardware configuration supported external medias terminal definition the file system data links command handling and general operation procedures for SP-based IO systems

MCS Transaction Log Infinite files File Process Utility


As well as more advanced topics such as:

external data link protocols inter-node communication in SPG CP-SP communication function change in SP SP backup SP co-processor dump hardware maintenance functions SP Trace System Log SP system parameters SP Restart Log SPS Event Log Direct File Output Start up of IOG 20

1.3 Input/Output Functions


The tasks of the AXE IO system can be generally described as follows: Handling of data to and from the Central Processor, CP. Thus IOG 20 is the IO interface to the world outside an AXE exchange. The data may be alphanumeric, like printouts, commands and alarms, statistic and charging data. The data may also be binary like software backups, etc. Secondary storage (mass storage) of information on magnetic media, e.g. hard disk, optical disk and flexible disk.

R1B

Introduction to AXE IO System

From the above considerations we see that the hardware of the IO system must contain the following components:

an interface to the Regional Processor Bus (RP Bus) for connection of


the IO to the central processor

a processor with the necessary software to control the different units,


diagnose faults and to communicate with the CP

external mass storage devices (hard disks, optical disks and flexible
disks)

data links for both high speed and low speed traffic using both asynchronous and synchronous transfer

alphanumeric terminals for man-machine communication


As well as the above units, the IO group is also required to provide alarm information on the alarm panels and alarm printer. The alarm information concerns both internal alarms from APT, APZ and the IOG itself, as well as external alarms (temperature, humidity, door control, etc.). Thus the IOG must also contain:

an alarm printer - i.e. an alphanumeric terminal to which alarm printouts are automatically routed. A separate alarm printer is normally defined (but any AT and slave printer can be used).

an alarm interface to which alarm panels and external alarm sensors are
connected

1.4 HW components of an IOG 20 IO system


The above mentioned components are incorporated in IOG 20 as shown in Figure 1.2. (It should be noticed that this is a simplified diagram with regard to the IO device connections.)

R1B

AXE IO System, IOG 20

RP-bus
CP

SP

ICB

SP

RPV/RPV2
HD AT HD AT HD ALI FD OD DL AMTP DL HD

RPV/RPV2

Alarm paneI External alarm

FD AT, printer OD

Figure 1.2

Example of an IOG 20 HW configuration

Figure 1.2 shows a standard IO configuration for the products IOG 20 B-P and IOG 20 B. The differences between the variants of IOG 20 will be covered later. The interface to the RP bus is called the RP Bus Adapter VME (RPV or RPV2). The RPV acts as a regional processor, with its own unique RP address, that is adapted to the task of communicating between the control unit in IOG 20 and the CP. The RPV converts the RP bus interface to a VME bus interface.

R1B

Introduction to AXE IO System

RP-bus
CP

Ethernet RP bus
RPV/RPV2
HD AT HD ALI FD OD DL HD HD AT

SP

ICB

SP

RPV/RPV2

FD AT, printer OD

VME bus
DL AMTP

PC/AT VSA
VSA - VME to SCSI-2 adapter

SCSI-2

Figure 1.3

IOG 20 buses

Internally in the IOG 20 the interfaces VME bus, SCSI-2 bus, PC/AT and Ethernet are used. The Ethernet bus follows ISO 8802-2 and IEEE 802.2, 802.3. SCSI-2 - Small Computer Systems Interface. VME - VERSA Module Eurocards. VSA - VME to SCSI-2 adapter.

R1B

AXE IO System, IOG 20

CP

P a r a ll e l R P bus

RPV

VM E bus

SP

S e ria l R P b u s CP RPV2 VM E bus

SP

Figure 1.4

Interface between RP-bus and internal IOG bus

The RPV converts from a parallel RP bus interface while the RPV2 converts from a serial RP bus to VME bus. The control unit in IOG 20 is a processor called the Support Processor, or SP for short. The support processor in IOG 20 is based on the Motorola 68060 microprocessor. The processor is called CPU60. The CPU60 has an internal memory of 32 Mb. Furthermore, a certain amount of data required by the SP is stored on the hard disks and used by the SP when required. The CP also contains a fairly large amount of software which is part of the IO system. This is described more in detail later in the book. As can be seen, the RPV (or RPV2) and SP are duplicated in the standard IOG 20 configuration. This is done as a precaution against faults (HW or SW) arising in one of the SPs.

10

R1B

Introduction to AXE IO System

RP bus CP

Node ICB

Node

SPG
Figure 1.5

Support Processor Group, SPG

The two SPs in an IOG are connected by the Inter Computer Bus, ICB. The ICB allows data to be transferred between the two SPs. It is an Ethernet bus. The SP, file medias, and CP interface forms what is called a node. The nodes in the duplicated configuration shown in Figure 1.2 are designated Node A and Node B. The logical connection between the CP and SP, via the RPV (or RPV2) and the RP bus, is called a Link. The IO devices shown in the figure are the following: AT AMTP ALI HD FD DL OD Alphanumeric Terminal Alphanumeric terminal over Ericsson MTP Alarm Interface Hard Disk Flexible Disk Data Link Optical Disk

An IOG 20 as described above - with two SPs (or nodes) each controlling a number of IO devices - is called a Support Processor Group, SPG. An SPG and an Input output group, IOG, are equivalent concepts. An SPG may only have two SPs (or nodes).

R1B

11

AXE IO System, IOG 20

A Support Processor Group is shown in Figure 1.5. Remember that the nodes in a SPG contain independent processors. The situation is different from in the central processors where the two sides are executing the same code.

CP

RPB-A

RPB-B Node ICB Node ICB Node Node ICB Node Node ICB Node

Node

SPG-0
Figure 1.6

SPG-1

SPG-2

SPG-3

Multi SPG configuration

It is possible to connect up to four SPGs to the CP, as is shown in Figure 1.6. As can be seen from the figure, each SPG is numbered, with the first SPG being designated SPG 0. Most AXE exchanges with IOG 20 will require just one SPG, i.e. SPG 0, whereas exchanges requiring very large amounts of output data storage and transfer would require two or three SPGs. SPG 1, SPG 2, and SPG 3 provide basically separate processors for handling such data. They thus relieve the workload of the SPs in SPG 0 which can thus be used to handle the alphanumeric IO devices and alarms. The data stored in SPG>0 is normally charging and statistics data which is subsequently transferred to remote destinations on high speed data links. Also if separate functions like Statistics subsystem or Remote Measurement subsystem are used in the exchange it is recommended to locate them to a separate SPG. We will look more at this later when we examine the different possible IOG configurations.

12

R1B

Introduction to AXE IO System

In SPG 0, the link at Node A is designated Link 0 and at Node B is designated Link 1. In SPG 0, Link 0 has RP address RP-1, Link 1 has RP address RP-4. In the other SPGs the corresponding designations are: SPG 1 SPG 2 SPG 3 Link 0 (RP-5) and Link 1 (RP-6) Link 0 (RP-7) and Link 1 (RP-8) Link 0 (RP-9) and Link 1 (RP-10).

Note: the reason for allocating RP addresses 1 and 4 to SPG 0 is the following: The central processor is designed to search for a backup file on RP address 1 when doing a spontaneous reload. The RP-1 is therefore allocated to the A-node of the SPG. The RP address 2 is dedicated for the function change RP. The RP address 3 is dedicated for IOG 3 functions (it was a requirement that IOG 3 and IOG 11 should be able to interwork in the same switch). IOG 11 and IOG 20 may interwork in the same switch. The next consecutive RP-4, is then selected for the B-node of the SPG.

1.5 IO Device Functions and Characteristics


The IO devices that may be connected to AXE, via the IO system, have already been mentioned. They will now be examined in more detail. Alphanumeric Terminal (AT) is the device used for man-machine communication. The ATs are thus used for sending commands and receiving printouts. An AT can be any type of asynchronous terminal, normally a personal computer (PC) or a Work Station (WS). It can also be a line printer, e.g. the alarm printer is also an AT. The AT terminal may also be used for machine-machine communication. Two examples are: Alarm interface AT-1 is usually dedicated as an interface to the external alarm connecter(s) and to the alarm panel(s). AUC interface When using an Authentication Centre in the GSM mobile telephony network it may be connected as an AT terminal. There are a number of different communication programs for PC and WS, for example FIOL (for DOS), WINFIOL or AXEUSE (for Windows) or WIOL via TENUX (for UNIX). Alphanumeric Terminal over Ericsson MTP (AMTP) is another device used for man-machine communication. It has the same characteristics as an AT but is used for terminals connected over a long distance. The AMTP is connected over the Ericsson MTP protocol over the packet switched network (X.25).
R1B 13

AXE IO System, IOG 20

Whether to connect an AT or AMTP terminal is decided by the distance and transmission facilities between the switch and the operator. Alarm Interface (ALI) is the interface to which the alarm panels and external alarm sensors are connected. Thus external alarm information is sent to the SP, and internal and external alarm information sent to the alarm panels, via this interface. As we shall see when we look at the hardware configuration, the ALI is connected to the SP in exactly the same manner as an AT device. It communicates with the SP via an AT device and is defined in the data as such. The external alarm indications are then received by the IO system as commands and the orders to the alarm panel (turn on lamp, turn off bell) are sent as printouts. It should be noticed from Figure 1.2 that in the standard configuration the ALI is usually only found in the A- node. In the SP and CP reference packages, four AT devices are predefined in the initial data: AT-0 AT-1 AT-4 AT-5 alarm printer (operation) connected to the alarm interface, ALI normal AT for use once the IOG has been started (maintenance) as AT-4 (or ALI in node if this exists)

Note: terminals of type Type Writer, TW, are not connected via IOG 20 but to the subscriber stages of the switch. These terminals are part of the IO system but not described in this book. Hard Disk (HD). The number of hard disks per node varies between the different IOG 20 variants. Each hard disk has a capacity of 2 or 4 Gb. IOG 20 B-P and IOG 20 B hold 1-3 hard disks per node. IOG 20 C holds 1 hard disk per node. The HD unit is used to store many different kinds of information. It stores backup of all software in the AXE switch (including base stations), CP and SP exchange data, different logs, statistics data and charging data. A central processor may reload from two sources: its own primary memory or from a hard disk. The hard disks are connected to the SP via the SCSI-2 bus. Flexible Disk (FD) is a mass storage unit for replaceable diskettes. The diskette size is 3 1/2 inches and storage capacity is 1,44 Mb when formatted.

14

R1B

Introduction to AXE IO System

Two formats exist:

the Ericsson-specific APN format MSDOS


Diskettes are used as moveable media. Examples of their use are the loading of SP software at initial start of IOG 20 and the loading of command files. The CP reference dump can also be copied to hard disk from diskettes prior to initial loading of the CP. However, optical disk is normally more convenient for this due to the large number of diskettes otherwise required. The flexible disk drive is connected to the SP via a PC/AT interface. Diskette drive is not included in IOG 20 C. Optical Disk (OD), the complete name is Optomagnetic Disk, is a massstorage unit for replaceable disks. The OD exists in two formats:

3 1/2 inch
The storing capacity of the 5 1/4 disk is 2x325 MB or 2x650 MB. The storing capacity of the 3 1/2 is 1x640 MB. The OD is readable, writeable and rewritable. Writing and rewriting is realized by using the magnetic material on the disk. Before using the OD it must be formatted. Two formats exists:

Ericsson-specific APN format the industry standard NSR02, or ISO 13346, complying to OSTA-UDF
(Optical Storage Technology Association-Universal Disk Format). OD is mainly used for CP and SP backups but may also be used for charging and statistics data. The opto disk drive is connected to the SP via an SCSI-2 bus and the VME bus. In between the two buses is a converter named VSA, VME to SCSI adapter. The reason the OD is not connected to the SCSI-2 bus, like HD, is that it would slow down the access to HD. IOG 20 B-P and IOG 20 B contains 3 1/2 or 5 1/4 inch OD. IOG 20 C contains the 3 1/2 inch OD. Data Links (DL) may be connected to the IOG via a number of different interfaces and baud rates. There are a number of different protocols implemented in IOG 20: the Ericsson MTP, the File Transfer and Management, FTAM. An optional protocol is the Direct Data Output, DDO.

R1B

15

AXE IO System, IOG 20

Data links are used for transferring charging or statistics data or for alphanumeric terminal connection.

1.6 Chapter Summary


the concept SP Based IO Systems in AXE includes IOMC, IOG 11A,
IOG 11 B, IOG 11 C, IOG 11 B5, IOG 11 C5, IOG 20 B-P, IOG 20 B and IOG 20 C

the IO system handles secondary storage medias, data links, terminal


interfaces for man-machine communication and RP-bus interface

the IO system handles interfaces to external alarm sensors and to alarm


display

the interface between the support processor and RP-bus is implemented


in the RPV/RPV2

RPV interfaces to the parallel RP-bus RPV2 interfaces to the serial RP-bus the support processor in the IOG 20 is called CPU60 one node includes one support processor one SPG includes two nodes one IO system includes one to four SPGs it is possible to configure IOG 11 and IOG 20 in the same AXE the communication path between the CP and one node is called a Link each link (or node) is identified by one RP address the storage medias in IOG 20 are diskette, opto disk and hard disk

16

R1B

2. Subsystems in the AXE IO System

Chapter Objectives
After completing this chapter the student will be able to: Name the subsystems incorporated in AXE IO system Describe the main functions of each subsystem Give the names of the hardware units that are included in each subsystem Give account of the formal product and function structure
Figure 2.1

Chapter Objectives

2.1 Introduction
This chapter describes the different subsystems that implements the IO system in AXE. It also describes the formal structure of IO products and functions.

2.2 Subsystems in SP-based IO Systems


The following subsystems belong to the AXE IO system: SPS MCS FMS DCS Support Processor Subsystem Man Machine Communication Subsystem File Management Subsystem Data Communication Subsystem

The Central Processor Test, CPT, is partly implemented in the IOG 20 and partly in the central processor. It is not part of the IO system. CPT is part of the Maintenance Subsystem, MAS. The software of APT subsystems RMS and STS may also be executing in the SP. They are not part of the IO system.

R1B

17

AXE IO System, IOG 20

2.3 Support Processor Subsystem (SPS)


2.3.1 General
SPS implements the program control of the Support Processor, the SP-CP communication function, maintenance functions for the nodes and links, as well as several SPS operation functions. SPS consists of the following components:


2.3.2

the Support Processor (SP) with its operating system and buses the Regional Processor bus Adapters (RPV or RPV2) software for communication between CP and SP software for operation and maintenance and supervision functions for the SPG

The Hardware of SPS

CP

SP

ICB

SP

RPV/RPV2 HD AT HD ALI FD OD AMTP DL DL HD FD OD


AT

RPV/RPV2 HD AT

AT, printer

Figure 2.2

SPS hardware

Support Processor, SP. The support processor is a real time computer called CPU60. It is based on the Motorola M68060 processor. At loading or reloading of an SP, PROM-stored bootstrap software is used to initiate loading of the SP operating system and software into the primary memory of the SP from flexible disk, opto disk or hard disk. During start up of IOG 20 the software is first transferred to the hard disk from a number of diskettes, or from an opto disk. The CPU60 board contains the interface towards the intercomputer bus, ICB. The ICB is an Ethernet bus.

18

R1B

Subsystems in the AXE IO System

The CPU60 also contains a VME bus interface and a SCSI-2 bus interface.

CP

P a r a lle l R P bus

RPV

VM E bus

SP

S e r ia l R P b u s CP RPV2 VM E bus

SP

Figure 2.3

Interface CP-SP

The RPV, or RPV2, is the interface unit between the RP bus and the SP. It transfers and receives messages to and from the CP. RPV interfaces to parallel RP-bus and RPV2 interfaces to serial RP-bus. It consists basically of a microprocessor M68360 with its own operating system. The software is stored on hard disk (as part of the SP system) and downloaded to RPV/RPV2 at start-up. The RPV is implemented on boards PROVME and DRPBU. The RPV2 is implemented in board RPV2. The IOG 20B-P is configured with RPV. IOG 20B and IOG 20C are configured with RPV2.

2.3.3

The Software of SPS


The SPS software is situated in the processors CP, SP and RPV/RPV2. In the SP the function blocks of all the subsystems are divided into software units called modules. The modules are written in the real time, high level language EriPascal. The CP software is written in PLEX-C or ASA210C. The RPV/RPV2 software is written in C. The operating system in the SP is named EriOS and in the RPV OSE. OSE - Operating System Environment.

R1B

19

AXE IO System, IOG 20

As mentioned above, the SPS contains the operating system of the SP and software for handling both CP-SP communication, maintenance of the nodes and links and a number of SPS operation functions.

2.3.4

CP-SP Communication
Communication between the SP and the CP partly follows the Open Systems Interconnection, OSI, model for data communication. The CP regards the RPVs as RPs and chooses either one when sending signals to a function block in the SP. Normally the CP takes the direct path via the RPV, or RPV2, in the executive node, but can also access this node via the other RPV over the ICB if necessary. A blocked or separated RPV in the executive node are examples of such a case. The SP would take the same path for communication in the opposite direction. The CP may communicate with either of the two nodes in a SPG, but most functions are designed for communication with the executive node.

2.4 Man-machine Communication Subsystem (MCS)


2.4.1 General
MCS supplies the man-machine interface for the AXE system. MCS handles two types of information:

Alphanumeric information (commands, printouts) Alarm information (internal, external)


The terminal interfaces belong to DCS as will be seen in the section on this subsystem. MCS interworks with all command receiving and printout generating blocks. It also interworks with all SP and CP program blocks that generate alarms.

20

R1B

Subsystems in the AXE IO System

2.4.2

The Hardware of MCS

CP

SP

ICB

SP

RPV/RPV2 HD AT Alarm paneI


ALI

RPV/RPV2 HD AT HD FD OD HD FD OD DL
AT AT, printer

External alarm AMTP DL

Figure 2.4

MCS hardware

The hardware of MCS consists of:

alphanumeric terminals alarm interface, ALI external alarm connectors alarm panels

The alarm interface consist of two boards: ALCPU and ALEXP. The MCS function block AT in the CP handles inputs and outputs to and from the AT devices. AT block is software only. The AT devices themselves with the exception of the ALI are not part of the MCS hardware. Any suitable asynchronous terminal can be connected to the IOG. As will be seen later, the ATs are physically connected to hardware interfaces belonging to subsystem DCS.

2.4.3

The Software of MCS


The software of MCS executes in CP, SP and EMRP. The main functions of MCS software are:

R1B

21

AXE IO System, IOG 20

administration of alphanumeric data service functions for alphanumeric IO devices MCS transaction log MCS user directories (SP authority system) alphanumeric device block functions (AT, AF, AMTP, TW) administration of alarms (from CP and SP)

Note that the blocks of MCS are adapted to the FORLOPP function.

2.5 File Management Subsystem (FMS)


2.5.1 General
FMS incorporates hardware and software for handling the external mass storage requirements of AXE. The software of FMS executes both in the CP and the SP. FMS interworks with SPS, MCS, DCS and a number of file users in other different subsystems.

2.5.2

The Hardware of FMS

CP

SP

ICB

SP

RPV/RPV2
HD HD

RPV/RPV2 AT
HD ALI FD OD HD AT AT, printer OD DL VSA

AT

FD

AMTP

DL

Figure 2.5

FMS hardware

22

R1B

Subsystems in the AXE IO System

The hardware of FMS consists of:

the hard disks, HD flexible disks, FD opto disks, OD VME to SCSI-2 bus interface board, VSA

The hard disks are connected to SP via an SCSI-2 bus. The flexible disks are connected to SP via a PC/AT interface. The opto disks are connected to SP via the VME bus which is converted to SCSI-2 bus in the VSA. The reason for this is speed, the OD would slow down the fast accesses towards the hard disk if they were connected to the same bus. VSA. The VSA board is an interface board between the VME bus and the SCSI-2 bus. The board is used to connect the opto disk to the VME bus, via the SCSI-2 interface. It is part of FMS. The VSA board contains a Motorola MC68360 processor.

2.5.3

The Software of FMS


The software of FMS is divided between the CP and the SP. The software handles:

file functions, e.g. reading, writing or deleting data on file service functions, i.e. functions initiated by operator commands for
defining, removing, copying and renaming files, writing command files, reading files and handling diskette and opto disc media

file processing functions, i.e. functions for sending files over data links
or transferring them to opto or flexible disk, and removal

the Command Log function for logging commands that manipulate


exchange data in the CP

compression and decompression of files recovery of corrupt files file security functions

2.6 Data Communication Subsystem, DCS


2.6.1 General
The structure of DCS is based on the Open Systems Interconnection (OSI) model, i.e. a layered structure for data communication that is in general use today. It is not absolutely necessary to know the principles of the OSI model for normal operation of IOG 20.

R1B

23

AXE IO System, IOG 20

DCS software executes in the SP and in the Line Unit Module, LUM. The subsystem is different from the other three IO subsystems which exist in both the CP and SP. Data to/from ATs or data links enters the AXE IO system via DCS functions and is then transferred to either MCS or FMS within the SP. DCS interworks with SPS, FMS and MCS. DCS offers communication services and provides interfaces to data network users. It provides network services comparable to a stand-alone X.25 packet switching system, which allows connection to external X.25 equipment and X.25 networks. The EX node provides a data communication interface towards external connected equipment. A CM is a logical concept. It defines logically the presence of DCS in the node. In most cases it is correct to say that CM and node are equivalent concepts. The CM are numbered according to SPG number as follow: SPG0, node A CM-1 SPG0, node B CM-2 SPG1, node A CM-17 SPG1, node B CM-18 SPG2, node A CM-33 SPG2, node B CM-34 SPG3, node A CM-49 SPG3, node B CM-50 DCS also provides an alphanumeric terminal interface based on X.28/ X.3/X.29 recommendations for the connection of asynchronous terminals to synchronous X.25 equipment.

24

R1B

Subsystems in the AXE IO System

2.6.2

The Hardware of DCS

CP

SP

ICB

SP

RPV/RPV2
HD HD

RPV/RPV2 AT
HD ALI FD OD HD AT AT, printer

AT

FD OD DL

AMTP DL

Figure 2.6

DCS hardware

The hardware of the Line Unit is the Line Unit Module, LUM, boards. This is a mother board which can hold up to four daughter boards. The daughter boards interface to terminals and data links. Each daughter board has one port. The LUM board contains a Motorola M68360 and M68060 processors.

R1B

25

AXE IO System, IOG 20

E ach Line U nit M o dule, LU M , m ay ho ld a m axim um of fo ur d aug hter bo ards

D aughter boards: V .24/V .28/V .35/V .36/X .21 G .703 E 0 (64 kb it/s) G .703 E 1 (2M bit/s) T -E thernet (not introduced at this IO G 20 release) T o external data connections
Figure 2.7

DCS hardware

2.6.3

The Software of DCS


The software of DCS consists primarily of:

the communication protocols (X.25, X.28, X.3, X.29 and others) that
implements the OSI layers in the SP

network services (such as addressing and routing in data communication networks)

command receiving functions for DCS commands internal supervision functions for the DCS hardware and software statistics functions for DCS
The software is executing in the SP and in the LUM. The LUM software is stored on hard disk (as part of the SP system). If the Remote Measurement Subsystem is installed in the switch, the hardware is connected via DCS. An X.25 link is used for controlling the measurement instruments (which are also connected to the group switch).

26

R1B

Subsystems in the AXE IO System

2.7 The Software Structure of the IO Subsystems


2.7.1 General
From the above, we know that the software of SPS, MCS and FMS exist in both the CP and the SP. The software of DCS is found only in the SP. The figure below shows the software structure of the IO system.

CP FILES
READ WRITE

Other subsystems in CP PRINTOUTS


COMMANDS ALARMS

FMS File handling

SPS Supervision

MCS Commands, printouts, alarms

SP

CP - SP communication SPS

FMS file handling file access

MCS, alarms commands printouts

DCS Communication Interfaces Network

SPS Supervision Operating system

OD

FD

HD

Alarm panel

External alarms

Data links, terminals

Figure 2.8

The software structure of the IO system

Both data links and terminals are connected to DCS hardware. A command entered from an AT is thus transferred via DCS hardware and software to MCS software. The command must then be sent to MCS software in the CP for analysis and is thus transferred by SPS to the CP. In the CP, the command is transferred from SPS to MCS. From MCS the command is forwarded to the command owning block in the normal manner. If the command was, for instance, to define a file in FMS then the command owning block in FMS would - via SPS - communicate with the required FMS software in the SP in order to write on the hard disks.

R1B

27

AXE IO System, IOG 20

2.7.2

CP software
The software belong to the IO system that is executing in the CP is written in PLEX-C and ASA210C. A software unit in the CP is called a block.

2.7.3

SP software
The software executing in the SP is written in the programming language EriPascal. In the SP software each software unit is called a module and has its own unique name (compare to programs in RP and blocks in CP and EMRP). The module is the smallest unit which may be compiled in EriPascal. One or more interrelated modules are grouped together into a function block. The function block concept in the SP is thus different to that in the CP. In the software hierarchy, a module in the SP corresponds to the central (or regional) software unit in a CP function block. If a program in the SP has to be changed or corrected, the module has to be recompiled. No correction system exists in the SP. If a module is changed and recompiled only due to a fault correction (i.e. no change in function), it is released in a so called Rapid Correction Note Issue, CNI. A Rapid CNI may be compared to an approved program correction in CP, RP or EMRP. An IOG 20 system contains about 300 modules. The number of modules varies from system to system.

2.7.4

EMRP software
The software units of the IO system in EMRP belongs to subsystem MCS. The code is written in PLEX-M.

2.7.5

LUM software
The software of the Line Unit Modules belongs to subsystem DCS. The software is located in module LUCHAR79 and stored in volumes PROG_A and PROG_B. The software is booted from the hard disk when deblocking the line unit (command ILBLE). The code is written in C and the operating system in LUM is PsOS. LUM has no program correction system.

2.7.6

RPV/RPV2 software
The software of RPV/RPV2 belongs to subsystem SPS. The software is part of the SP system (module RPVFW or RPV2FW) and stored in volumes PROG_A and PROG_B. The software is loaded to the RPV/RPV2 at power on. The code is written in C and the operating system is OSE. RPV/RPV2 has no program correction system.

28

R1B

Subsystems in the AXE IO System

2.7.7

Functional and Product Structure of SP software


The functional structure follows the Early Design Process Improvement, EDPI, concept. The system is divided in four levels: FAM 101 - service ordering system FAM 102 - node type FAH 102 - configuration object FAX 141 - telecom object Examples of Configuration Objects included in IOG 20 are: FAH 102 8001 Communication Platform FAH 102 0102 CPSA FAH 102 0103 Data Communication Statistics FAH 102 0104 Data Communication Network Services FAH 102 0105 Line Interface FAH 102 0106 Upper Layer Interfaces FAH 102 0107 FTAM FAH 102 0108 File Management in AXE FAH 102 0109 AXE Command Log FAH 102 0110 Alphanumeric Handling FAH 102 0111 Authority System FAH 102 0112 Transaction Log FAH 102 0113 Alpha services FAH 102 0114 Alarm Handling etc. These in turn are divided in Telecom Objects. Example:

FAX 141 8105 - Alarm Administration in AXE10 FAX 141 8024 - Transaction Log
The entire system contains about 110 Telecom Objects. The product structure is divided in: ANZ = subsystem CNA = function block COA = software unit

R1B

29

AXE IO System, IOG 20

CAA 119, CAA 110 = module written in EriPascal The levels ANZ and CNA and COA are description levels - these products contain documents, e.g. subsystem, function block and software unit descriptions. The CAA level consists of products, containing the program listings and program code. In the APZ source systems applicable to this book, the subsystems are identified by the following designations: DCS FMS MCS SPS ANZ 216 20 ANZ 217 20 ANZ 218 20 ANZ 219 20

2.8 Chapter Summary


SPS - support processor subsystem handles CP-SP communication,
program execution, inter-node communication and HW maintenance

FMS - file management subsystem handles storage and processing of


data on secondary media

MCS - man-machine communication subsystem handles terminal communication, the alarm system and printout routing

DCS - data communication subsystem handles terminal interface, data


links, data protocols and data communication addressing, routing and statistics

SPG0 always contains SPS, FMS, MCS and DCS SPG1 to SPG3 always contains SPS, FMS and DCS all SPGs may optionally contain subsystems RMS and/or STS parts of subsystem MAS is always loaded in SPG0, this for the CPT SPS hardware includes the CPU60 and RPV/RPV2 FMS hardware includes the OD, FD and HD drives MCS hardware includes the alarm interface boards DCS hardware includes the LUM boards with daughter boards all physical ports are located on daughter boards which are attached to the LUM boards

software executing in the support processor is written in EriPascal or C software executing in LUM and RPV/RPV2 is written in C

30

R1B

3. Hardware Structure

Chapter Objectives
After completing this chapter the student will: Briefly account for the main differences between IOG 20 B-P, IOG 20 B and IOG 20 C Describe briefly the function of each board in the SPVM, SPVM-P and SPVCM subracks
Figure 3.1

Chapter Objectives

3.1 Introduction
This chapter describes the different hardware configurations that exist within IOG 20. Also described are the different boards of the IO system.

3.2 Hardware structure


3.2.1 Introduction
This chapter will explain the differences between the hardware configurations that exist in the SP-based IO systems IOG 20:

IOG 20 B-P IOG 20 B IOG 20 C


Remember that a number of SP-based IO systems exist in the IOG11 family: IOMC, IOG11A, IOG11B, IOG11C, IOG11B5 and IOG11C5. These are not covered in this book. All IO equipment is mounted in BYB 501 racks. The IOG 20 rack contains one subrack: SPVM-P SPVM SPVCM in IOG 20 B-P in IOG 20 B in IOG 20 C

R1B

31

AXE IO System, IOG 20

3.3 Hardware configurations


3.3.1 IOG 20 B-P

Figure 3.2

IOG 20 B-P

The IOG 20 B-P interfaces towards the parallel RP bus (this is indicated by the P). The IOG 20 B-P theoretically has a maximum capacity of:

32 terminals or
32 single data links or 16 duplicated data links or a combination of this 3 hard disks per node (2 or 4 Gb)

1 flexible disk per node 1x5 1/4 or 1x3 1/2 inch opto disk per node 32 external alarm connections per node 4 alarm panel interfaces per node 1 SCAN alarm interface per node

The IOG 20 B-P may be used as SPG>0 if the alarm interface boards are removed. Note: The 5 1/4 OD and 2GB HD will be phased out shortly.
32 R1B

Hardware Structure

3.3.2

IOG 20 B

Figure 3.3

IOG 20 B

The IOG 20 B interfaces towards the serial RP bus. The IOG 20 B theoretically has a maximum capacity of:

32 terminals or
32 single data links or 16 duplicated data links or a combination of this

3 hard disks per node (2 or 4 Gbyte) 1 flexible disk per node 1x5 1/4 or 1x3 1/2 inch opto disk per node 32 external alarm connections per node 4 alarm panel interfaces per node 1 SCAN alarm interface per node

The IOG 20 B may be used as SPG>0 if the alarm interface boards are removed. Note: The 5 1/4 OD and 2GB HD will be phased out shortly.

R1B

33

AXE IO System, IOG 20

3.3.3

IOG 20 C

Figure 3.4

IOG 20 C

The IOG 20 C interfaces towards the serial RP bus. The IOG 20 C theoretically has a maximum capacity of:

24 terminals or
24 single data links or 12 duplicated data links or a combination of this 1 hard disk per node (2 or 4 Gb)

1x3 1/2 inch opto disk per node 32 external alarm connections 4 alarm panel interfaces 1 SCAN alarm interface

The IOG 20 C is never used as SPG>0, although this is technically possible.

34

R1B

Hardware Structure

The SPVM, SPVM-P and SPVCM subracks are electromagnetic shielded.

OD drive (5 1/4 or OD drive (5 1/4 or 3 1/2) 3 1/2)


An IOG 20 B-P consists of two SPVM-P subracks.

OD drive (5 1/4 or 3 1/2) ALEXP ALEXP


An IOG 20 B consists of two SPVM subracks.

ALEXP ALEXP ALCPU ALCPU LUM LUM LUM LUM LUM LUM LUM LUM DRPBU DRPBU PROVME VSA VSA HD1 drive HD3 drive HD3 drive CPU60
Figure 3.5

ALCPU ALCPU LUM LUM LUM LUM

3.4 Subracks and boards

SPVM-P subrack IOG 20 B-P

SPVM subrack IOG 20 B

LUM LUM LUM ESDCV ESDCV RPV2 VSA VSA

FD drive HD2 drive


SPVM-P subrack

HD1 drive HD1 drive

FD drive FD drive

3.4.2

3.4.1

HD3 drive HD3 drive CPU60 CPU60

HD2 drive HD2 drive

Figure 3.6

Power Power

Power

SPVM subrack

R1B

35

AXE IO System, IOG 20

3.4.3

SPVCM subrack IOG 20 C


An IOG 20 C consists of one SPVCM subrack.

HD drive HD drive

Figure 3.7

SPVCM subrack

Power Power
36

CPU60

VSA VSA

VSA VSA RPV2 RPV2 LUM LUM LUM LUM LUM ALEXP ALEXP ALCPU LUM LUM LUM LUM LUM LUM RPV2

CPU60 CPU60

Power

HD drive

3.4.4

OD drive OD drive (3 1/2) (3 1/2)

OD drive OD drive (3 1/2) (3 1/2)

Boards
Power - supplies power for all boards in the subracks via the backplane. The power-feeding is connected to the front plane. Input power is 48 volts and output power is +5 and +/-12 volts. CPU60 - processor board with microprocessor M68060. The primary memory on the board is 32 MB. The CPU60 interfaces to the intercomputer bus (Ethernet) via the front plane and to the SCSI-2 bus, power and VME bus in the back plane. The CPU60 has two RS232 ports on the front plane for connection of IO terminal. The RS232 ports communicates at 4800 baud. FD/HD drive - this board contains both 3 1/2 inch diskette drive and hard disk drive. It interfaces to the SCSI-2 bus and power in the backplane. HD drive - this board contains one or two hard disks. It interfaces to the SCSI-2 bus and power in the backplane. OD drive 3 1/2 inch - this board contains one opto disk drive. It interfaces towards the VSA board via a separate SCSI-2 bus in the back plane. It is also power-fed in the backplane. OD drive 5 1/4 inch - this board contains one opto disk drive. It interfaces towards the VSA board via a separate SCSI-2 bus in the back plane. It is also power-fed in the backplane. VSA - this board converts VME bus to a separate SCSI-2 bus which interfaces to the opto disk drive. It interfaces to VME bus, SCSI-2 bus and power in the back plane.
R1B

Hardware Structure

DRPBU - this board interfaces to the parallel RP bus in the front plane. In the back plane it interfaces to the PROVME board, via an internal interface, and to power. PROVME - this board interfaces to the DRPBU board via an internal interface. It interfaces to the VME bus and power supply in the back plane. RPV2 - this board interfaces to the serial RP bus in the front plane. In the back plane it interfaces to the VME bus and to power. LUM - this board contains a microprocessor Motorola M68060. It interfaces to the daughter boards V.24/V.35/V.36/X.21 INTERFACE, G.703 E0 INTERFACE and G.703 E1 INTERFACE via a connecter on the board. It can hold four daughter boards, each of which controls one physical port. The boards are fitted on the LUM board with four screws. The LUM mother board interfaces to the VME bus and power in the back plane.

Each Line Unit Module, LUM, holds four daughter boards.

A-node

V.24/V.28/V.35/V.36/X.21 G.703 E0 (64 kbit/s) B-node G.703 E1 (2Mbit/s) T-Ethernet (not introduced at this IOG20 release) To external data connections

Figure 3.8

LUM board with daughter boards

V.24/V.35/V.36/X.21 INTERFACE daughter board - this boards implements one physical port towards a data link or terminal. It is fitted to the LUM board with four screws and is power-fed from the LUM board. It supplies the interfaces V.24, V.35, V.36 and X.21. G.703 E0 INTERFACE daughter board - this boards implements one physical port towards a data link or terminal. It is fitted to the LUM board with four screws and is power-fed from the LUM board. It supplies the interface G.703 E0 with a baudrate of 64 kbit/s. G.703 E1 INTERFACE daughter board - this boards implements one physical port towards a data link or terminal. It is fitted to the LUM board
R1B 37

AXE IO System, IOG 20

with four screws and is power-fed from the LUM board. It supplies the interface G.703 E1 with a baudrate of 2 Mbit/s. T- Ethernet INTERFACE daughter board - this board is not introduced as an orderable product at the first IOG 20 release. ALCPU - Alarm interface board. This board has two V.24 ports which interface to the LUM board and to the fan. The board has a SCAN input and input of external alarm. The board is connected to VME bus and power in the back plane. ALEXP- This board has four outputs for control of alarm displays. The board is controlled by board ALCPU. ESDCV - EMC shield and Daisy Chain VME bus circuit board. The purpose of the board is to fill empty positions in the SPVM subrack. This in order to maintain the electromagnetic shield that the subrack forms. The board also connections the VME bus in the back plane of the SPVM subrack. Empty positions may occur if the subrack is not fully equipped with LUM boards or if the RP bus interface is serial with one RPV2 board instead of the DRPBU and PROVME boards. Empty positions may also occur if only one hard disk is installed in an IOG 20 B-P or IOG 20 B node.

3.5 LEDs and Buttons


In the IOG hardware there are a number of lamps (LEDs) indicating different states and faults that can occur in an IOG.

Reset and restart switch buttons. The upper button restarts the support processor when toggled once. When toggled twice it reloads the support processor. The lower switch halts the execution of the SP when toggled once, it generates a level 7 IRQ. Display for HW test (not used). The lower turning strap indicates the node address (Node A - 1, node B - 2) and the upper, the SPG index (SPG0 - 0 and SPG1 - 1). LED indicators (see next picture)

CPU port, RS232 interface with 4800 baud

Ethernet interface (ICB)

Figure 3.9

LEDs and buttons CPU60 board


38 R1B

Hardware Structure

RUN

BM

RUN : Green during normal operation Red during reset and halt

BM - Bus Master: Green if CPU60 is bus master


FAIL EX

FAIL: Red if system failure EX: Green if node executive

Figure 3.10

LEDs on CPU60 board

There are also two flip buttons on the CPU60 board front. These buttons should only be used in special situations. The lower button is for debugging of SP programs. The upper (reset button) is for restarting (flip once) or reloading (flip twice) of the SP. A terminal can be connected straight in to the SP on the front of the CPU60 board. This is referred to as a local terminal. From this terminal only SP commands can be sent. There are two RS232 connections for this but only the upper one is used. A local terminal is, for instance, used at initial start of IOG 20. Normally no terminal is connected to the CPU port.

R1B

39

AXE IO System, IOG 20

Yellow LED indicates Maintenance interface alarm Red LED indicates RPV/RPV2 restart Red LED indicates link in separated state Green LED indicates normal state Green LED indicates RPV/RPV2 correct program execution Yellow LED indicates data channel open, flashes during CP reload

DIP switch for RP bus address on board

Pushbutton for separation of link

Figure 3.11

LEDs and buttons PROVME/RPV2 board

BM RUN

Right LED RUN indicates: green - processor running, red - processor halted Left LED BM indicates: flashing red - LUM is working normally off - LUM is not defined or is manually blocked

One LED per port indicates port status: Green - operational Red - blocked or not defined Yellow - automatically blocked Flashing yellow - stand by

Figure 3.12

LEDs on LUM board


40 R1B

Hardware Structure

G reen LE D indicates system running Y ellow LE D in dicates ongoing softw are update R ed L E D indicates S C S I term ination pow er O K

Figure 3.13

LEDs on VSA board

3.6 Chapter Summary



IOG 20 exists in three versions: IOG 20 B, IOG 20 B-P and IOG 20 C all three versions are two-node SPGs IOG 20 B and IOG 20 C interface to the serial RP-bus IOG 20 B-P interfaces to the parallel RP-bus the subrack implementing IOG 20 B-P is SPVM-P the subrack implementing IOG 20 B is SPVM the subrack implementing IOG 20 C is SPVCM all IOG 20 subracks are build according to BYB501 all three IOG 20 versions are use the M68060 microprocessor with 32 MB primary memory IOG 20 C has only one HD per node IOG 20 C has only one 3 1/2 OD per node IOG 20 C can have maximum three LUM boards per node IOG 20 B/-P can have maximum 3 HDs and one 3 1/2 FD per node IOG 20 B/-P has maximum one 5 1/4 OD per node IOG 20 B/-P can have maximum four LUM boards per node

R1B

41

AXE IO System, IOG 20

42

R1B

4. FMS applications

Chapter Objectives
After completing this chapter the student will: Name the basic concepts of FMS Know the different types of volumes in FMS and their use Describe the recommended contents of volumes PROG_A, PROG_B, OMFZLIBORD and RELVOLUMSW Have knowledge about operational documents and commands related to FMS Have knowledge about the Infinite Files function
Figure 4.1

Chapter Objectives

4.1 Introduction
This chapter describes the functions of the file management subsystem of AXE. The chapter concentrates on media, volume and file handling and file processing functions.

4.2 FMS Concepts


The basic concepts of FMS are:

Storage Medium Volume File

4.3 Storage medium


Storage medium for external data storage consists of the hard disks, flexible disks and opto disks. The media are divided in:

external, or removable, media - flexible disks and opto disks internal media - hard disks
All media needs to be formatted, in which a number of sectors are allocated on the medium. The sectors have different sizes on different media.
R1B 43

AXE IO System, IOG 20

The sector size is 512 bytes on 2 and 4 GB hard disks. The file system keeps a list of the sectors that are found to be faulty during operation. If a sectors is found to be faulty during a write operation the sector is mapped out and put in the faulty sectors list. Another sector is selected for writing. A diskette may have two different formats when used in AXE.

APN - An Ericsson-specific format which is named after the processor


APN 167

MSDOS - Microsoft Disk Operating System


One 3 1/2 inch diskette stores 1.44 MB. An opto disk may have two different formats when used in AXE:

APN is an Ericsson-specific format which is named after the processor


APN 167. This format is used for SP Software Backup and SP Exchange data.

NSR02, or ISO 13346, complying with the OSTA-UDF (Optical Storage Technology Association-Universal Disk Format). This format is supported by the Windows NT driver. This allows both reading and writing of files, such as TT files, in the standard format from a PC equipped with Windows NT. The optical disks exists in the following sizes: 2x325 MB, 2x650 MB and 1x640 MB. The 2x325 MB and 2x650 MB optical disks will be phased out shortly. Note: the data links may in some cases be treated as external medias.

4.3.1

Operation
The commands for handling medias are INMEI, INMEP and INATP. Below is an example of a 2 GB hard disk attributes:
: INMEP:IO=HD-1,NODE=A; MEDIA ATTRIBUTES STATUS IN USE HEADS 9 VOLUME PROG_A OMFZLIBORD RELVOLUMSW EXCHVOLUME CALLVOLUME STATVOLUME END SECTS 512 STRACK 139 TRACKS 36441

TOTSIZE(KBALLOCSIZE(KB)SUBUNITS 2096744 20757776 SIZE(KB) 200000 100000 500000 400000 400000 475777

44

R1B

FMS applications

SECTS STRACK TRACKS HEADS TOTSIZE ALLOCSIZE SUBUNITS SIZE

Sector size in bytes Number of sectors per track Number of tracks Number of heads for reading and writing Total memory available to user Total memory used by defined volumes Number of volumes Defined size of each volume

The command INMEI is used to format external medias, this is described in the following section. Formatting of internal volumes is only done at start up of the IOG. The command ISMEI is used.

4.4 Volumes
The storage area on a medium can be divided into one or more volumes. Volumes on hard disks can be defined as being a part of one disk or they can cover several disks, the latter is called volume across media border. A volume is identified by a volume name of 1 to 10 characters. Some volumes have the same names in SPG0, SPG1, SPG2 and SPG3. In this case the contents are not the same and these volumes are completely independent of each other.

Flexible disk 3 1/2 inch External, single volumes

Hard disk

node A

node B

Internal, single volumes Internal, duplicated volume over media border Internal, duplicated volume

Opto disk 3 1/2 or 5 1/4 inch

Figure 4.2

Volumes in AXE IO system

R1B

45

AXE IO System, IOG 20

On a hard disk there is a maximum of 16 volumes. These volumes are called internal volumes. One volume may cover a maximum of two hard disks. Volumes on flexible disks and opto disks are called external volumes. External volumes can only have one volume per media, except 5 1/4 opto disk which has one per side, and no volumes across media border. External medias always have a one-to-one relation to volumes. Internal volumes can be of two kinds:

single duplicated
External volumes are single volumes. A single volume is located only in one node. A duplicated volume:

is located in both nodes of an SPG, i.e. exists in two copies has a volume name of ten characters length the data in the duplicated volume is the same in both nodes in normal
operation The reason for having duplicated volumes is security. When writing to a file on a duplicated volume the data is physically written in both nodes of the SPG. If the standby node is blocked nothing is written on the duplicated volume of that node. If a difference between the contents of a duplicated volume, between the nodes, is detected a recovery action is initiated. This involves a restart of one of the nodes and an updating. The data in the duplicated volumes is logically identical, not physically. This means that the actual physical location on the hard disk may differ between the nodes for a file in a duplicated volume. Volume supervision. FMS has a supervision of the used space on a volume. The function issues the alarm VOLUME LIMIT EXCEEDED if the supervision limit is passed. The supervision limit is set in percent of the available volume space and the function is turned off by setting the limit to 0%. Command example:
:INVOC:VOL=EXCHVOLUME,LIMIT=75;

In the example above the volume supervision of volume EXCHVOLUME is set to 75%. If the volume is filled to more than 75% an alarm will be issued.

4.4.1

Operation
The commands for handling volumes are INVOP, INVEP, INVOI, INVOL and INVOC.

46

R1B

FMS applications

Command example:
:INVOP:VOL=OMFZLIBORD; VOLUME ATTRIBUTES INTERNAL REV 1 NODE1 A NODE2 B END DATE 991231 IO1 HD-1 IO2 HD-1 TOTSIZE(KB) 100000 SIZE1(KB) 100000 SIZE2(KB) 100000 USEDSIZE(KB 5528 LIMIT 99

Example of formatting an opto disk:


< INMCT:SPG=0; :INMEI:NODE=A,IO=OD-1,FORMAT=APN,VOL=TRAINING; ORDERED :END; EXECUTED VOLUME/MEDIA INITIATED EXECUTED NODE A END IO OD-1 VOLUME TRAINING FORMAT APN

Note: For diskette IO=FD-1 The volume name is written on the diskette or opto disk. The Support Processor keeps no record of these volumes. Therefore, before working with a diskette or an opto disk the volume table of contents (VTOC) has to be loaded into the system. This is loading the volume and done with command INVOL. Example of loading an external volume:
< INMCT:SPG=0; :INVOL:NODE=A,IO=OD-1; ORDERED :END; EXECUTED VOLUME LOADED EXECUTED VOLUME TRAINING END NODE A IO OD-1 FORMAT APN

Before removing a diskette or opto disk, the volume must be unloaded using the command INVOE. If this is not done, the device cannot be used for another diskette or opto disk.
R1B 47

AXE IO System, IOG 20

The formatting of hard disk and definition of volumes is not part of the ordinary operation and maintenance activities of the IO system.

4.4.2

Standard internal volumes


The following system defined volumes are always found on the hard disks in IOG20:


Node A

PROG_A PROG_B OMFZLIBORD RELVOLUMSW

Node B
Mandatory volumes

463+C% 31*>0-&36( 6)0:30917; )<',:3091) ',%6:3091) 78%8:3091) 0-78:3091)


Figure 4.3

463+C&
Optional volumes

31*>0-&36( 6)0:30917; )<',:3091) ',%6:3091) 78%8:3091) 0-78:3091)

Standard internal volumes

The volumes are shown in Figure 4.3. In addition to these, some market dependent volumes are usually defined for charging and statistics data The volumes PROG_A and PROG_B are unduplicated, and usually the only unduplicated volumes. PROG_A is located in node A and PROG_B in node B. The volumes contain SP software, including RPV/RPV2 and LUM software and the SP system files. If the SP Trace System function is activated, the SP Trace logs are stored here. The reason these volumes are unduplicated is that the SP software in two different nodes need not be identical. PROG_A and PROG_B reside in all SPGs.

48

R1B

FMS applications

OMFZLIBORD is a duplicated volume for storage of SP system data. It contains files for the SP exchange data and a series of logs and other files used for SPG maintenance functions, as well as other files created by the SP when required. SP exchange data for the Remote Measurement Subsystem (RMS) and Statistics and Traffic measurement Subsystem (STS) are also stored here if loaded. OMFZLIBORD resides in all SPGs. RELVOLUMSW is a duplicated volume for storage of Central Processor back up files and the command log. If the switch is a mobile application then the radio base station software is also stored in this volume. The volume is also used for temporary storage of SP software. RELVOLUMSW resides only in SPG0. A hard disk can contain up to sixteen volumes and usually some market specific volumes are created on the disk. The volume EXCHVOLUME is used as a default volume name if no specific market requirements on alternative name exists. This volume is duplicated and is used for charging and statistics data. The volume CHARVOLUME is often defined and used for charging data. The volume is duplicated. If defined, the volumes STATVOLUME or LISTVOLUME are used for statistics data.

4.5 Files
Files are stored in volumes. A file contains data and is physically located on one or more positions on the media (within a certain volume). A file cannot be stored in two volumes at the same time. A file cannot start in one volume and end in another. A file is identified by a filename of 1 to 12 characters. A filename may only be used once in an AXE system (exceptions to this rule exist). Each file is divided in a number of records. Records are of predefined lengths and, in certain file types, divided into subfields.

4.6 File attributes


4.6.1 File class
Files in FMS belong to one of three file classes:

Simple - SPL Composite - CMP Device - DEV


A simple file is just a normal file.

R1B

49

AXE IO System, IOG 20

A composite file is a file that consists of a mainfile and one or more subfiles. The mainfile contains no data and operates as an umbrella or directory to the subfiles. All data in a composite file is stored in the subfiles. There is no limit to the number of subfiles. A subfile name may be 1 to 12 characters long, if the subfile is located on hard disk. Subfile names on other medias are shorter, see the command description for command INFII.

Simple file

data data....

Composite file

Main file

data data...

data data...

data data...

Sub files
Figure 4.4

Simple and composite file types

A device file is a file identifying an external media where data to be written. One unique device file must be defined for each external medium (more than one may be defined, but this is unnecessary). Device files may be defined for devices of type:

Flexible Disk drive Optical Disk drive Data Link


It is possible to define device files directed to SP primary memory, but this is never done. In SPG 0, the device file names should be defined as:


50

FD0A1 for FD-1 in the A node FD0B1 for FD-1 in the B node OD0A1 for OD-1 in the A node OD0B1 for OD-1 in the B node
R1B

FMS applications

According to the file name convention the third character in the device file name indicates the SPG index and the fourth character the node. As an example: in SPG 3, the device file names should be defined as:

FD3A1 for FD-1 in the A node FD3B1 for FD-1 in the B node OD3A1 for OD-1 in the A node OD3B1 for OD-1 in the B node

To identify the files on the external medias (FD/OD) the name of the device file and the file name on the media must be specified. Example, to identify a file called ANYFILE on a diskette in FD-1, node A, SPG0, then the file must be referred to as FD0A1-ANYFILE. This is similar to the designation of subfiles of a composite file on hard disk. The device file naming is only a convention, they may be named in any way. Device files for data link is only used in conjunction with the Direct File Output function and then named according to the function it serves.

4.6.2

File Type
File Type can be one of the following:

Sequential (SEQ) Direct Access (DIR) Keyed Access (KEY)


Sequential access Record no.
1 2 3 4 5 6 -

Direct access Record no.


Read from top down
1 2 3 4 5 6 -

..or read record no. 102

Read record no. 765

Figure 4.5

Sequential and direct access file type

R1B

51

AXE IO System, IOG 20

Sequential files are files written in chronological order. Each new record is written in sequence after the previous one. Each record is numbered. Reading of the records from a sequential file is done in the same order as they were written, or according to record number. Direct access files consist of a finite number of records where each record is given a record number, just like sequential file. Reading and writing in the file is done directly using the record number. Direct access can be considered as a special case of sequential access.

Read all records with Fiat

Records with subfields: Key 1973 1988 Key Fiat Nissan Data Via Torino Nanjing road Data green white

year
Figure 4.6

carmake

address

colour

File class key

A key access file may be compared to a very simple data base. The reading of a key file is not done specifying a certain record but by specifying a search criteria or a key. An example is given in the Figure 4.6 above where a read order to the file system could be interpreted as read all records with FIAT in keyfield number 2. Another example could be read all records with a value larger than 1973 in keyfield 1. Only one search key may be specified in a read operation. A key access file consist of a number of records with one or more subfields.

52

R1B

FMS applications

The subfields may be of three different kinds:

data key keyunique


The data subfields contains any kind of data. A read (or search) in the file cannot be made in data subfields. A record may contain more than one data subfield. A key subfield contains data which can be used as search key when reading a file. A record may contain more than one key subfield. A keyunique subfield contains data which can be used as search key when reading a file. The keyunique subfield contains data that is unique, i.e. no other record may contain this data in this keyfield. A record may contain more than one keyunique subfield. Most files of type key only uses data and key subfields. The combinations of file types and classes are the following: Simple or composite files may be sequential, key or direct access. Device files are sequential.

4.6.3

Record length, size and expansion factor

Write Initial size

Expansion factor

Write

Expansion factor

Write

Record length
Figure 4.7

R1B

53

AXE IO System, IOG 20

File attributes size, expansion factor and record length

When defining a file the space allocated on the media is according to the size attribute. The parameter indicates number of records. When the initially allocated area is written, the file is expanded with the number of records indicated in the expansion factor. Note that the expansion factor may be overridden by the MAXSIZE parameter in the Infinite Files function. See the Infinite Files section. The record length indicates number of bytes per record. Which record length is suitable depends on the format of the written data, i.e. on the writing application. The suitable record length for a file can often be found in the application information for the file-using application.

4.6.4
Physical space on hard disk:

Blocking factor

block 3

block 4 Blocking factor n records Start of file block 1 block 2 End of file

Figure 4.8

Physical allocation of a file on hard disk

The file is physically stored in a number of blocks. Each block is a number of consecutive sectors on the media. A block consists of a number of records. The blocking factor may be defined by command but the system calculated default value is preferably used. Note that there are files on the hard disk that are not divided into blocks but are stored continuously on the hard disk. That is, they are stored in one long block. Example of such files are the SP modules which are stored in volumes PROG_A and PROG_B.

54

R1B

FMS applications

4.7 Operation of files


A new file is created with the command INFII. This is explained in the OPI SPG, File on Hard Disk, Define. See also the OPI FMS Output Files, Definition Recommendations. A file must be given a unique name. Some names are system defined, otherwise the name can be chosen either according to recommendations or at random. When a file is created on hard disk it must be put in a volume. Example of creation of file on HD:
< INMCT:SPG=0; :INFII:FILE=RELFSW2,VOL=RELVOLUMSW, TYPE=SEQ,FCLASS=CMP,RLENGTH=2048,SIZE=16,EXP=64;

In the example above a Central Processor backup file is created (all CP backup files are named RELFSWn). It is located in volume RELVOLUMSW. The record length is 2048 bytes and the initial file size is 16 records. If this size is reached (as it will be in this case) the subfiles will expand in steps of 64 records. When a device file is to be created the same command should be used but with another parameter combination. This is explained in the OPI SPG, Device File, Define. Here the file device must be given instead of the volume. Example of creating a device file:
< INMCT:SPG=0; :INFII:FILE=FD0A1,NODE=A,IO=FD-1,TYPE=SEQ, FCLASS=DEV,RLENGTH=512,SIZE=0,EXP=10;

Remember that a device file is a file pointing out a device (i.e. FD, OD, DL or Primary Memory in SP) where files are allocated. A file on a device will come up as a subfile to that specific device file. The example below shows the Ericsson recommendation of naming device files.
< INMCT:SPG=0; :INFIP:FCLASS=DEV; FMS FILE DATA FILE FD0A1 FD0B1 OD0A1 OD0B1 END FCLASS DEV DEV DEV DEV SPG 0 0 0 0 VOL NODE A B A B IO FD-1 FD-1 OD-1 OD-1

R1B

55

AXE IO System, IOG 20

Note that the file names above are Ericsson conventions. When using the function Direct File Output the device files will have other names. It is only necessary to have one device file for each file device e.g. FD0A1 is a pointer to the flexible disk drive in node A and FD0B1 is a pointer to the flexible disk drive in node B, etc. All files on a diskette in node A will come up as subfiles to the device file FD0A1. If the same diskette is used in node B the files will come up as subfiles to FD0B1. The files thus have unique names on the diskette, e.g. FDFILE1, but they must be addressed however by the full name, e.g. FD0A1-FDFILE1. Example of files on a diskette in node A:
< INMCT:SPG=0; :INFIP:FILE=FD0A1; FILE ATTRIBUTES RLENGTH BLK 512 4 TYPE NFIELDS SEQ 0 FCLASS DEV SUBFILES FD0A1-FDFILE1 FD0A1-FDFILE2 END SIZE 0 NKEYS 0 EXP 10 NUSERS

Here we see that two files FDFILE1 and FDFILE2 exist on the diskette. It should be noticed that diskette and opto disk files are not subfiles to the device files in the same sense as subfiles to a composite file on HD. Only composite files have subfiles. They appear as subfiles here because of the standard text SUBFILES in the printout format. Only the actual file name but not the device file name is written on the disk/opto disk. As seen above, to print the attributes of a file the command INFIP is used. The command can print a list of all defined files, all files of a given file class, all files in a given volume or data for a unique file. A printout of the data for the CP backup file defined earlier is given below:
:INFIP:FILE=RELFSW2; FILE ATTRIBUTES RLENGTH 2048 TYPE SEQ BLK 4 NFIELDS 0 SIZE 16 NKEYS 0 EXP 64 NUSERS

56

R1B

FMS applications

FCLASS CMP SUBFILES RELFSW2-R0 RELFSW2-R1 RELFSW2-R2 RELFSW2-R3 RELFSW2-R4 RELFSW2-R5 END

4.7.1

Removal of a File
A file can be removed with the command INFIR (for more information see the OPI SPG File, delete). A removed file may not be restored.

4.7.2

Copying of Files
Copying of files can either be done internally on hard disk or externally between hard disk and moveable media or between two moveable medias. The procedures are described in the OPIs FMS, Internal Files, Copy, FMS, Removable Media Files, Copy and FMS, SPG to SPG, Files Copy. Command INFIT is used to copy data stored in one file to another when both files are stored on hard disk in the same SPG. The destination file must be created in advance. If files are to be copied between hard disks in different SPGs the command IOFIT is used.

R1B

57

AXE IO System, IOG 20

RPB-A
CP

RPB-B

SP

ICB

RPV/RPV2
HD

AT
HD ALI FD OD DL

Commands INFIT, IOFIT and INFET

Figure 4.9

External transfer of file information

Command example:
< INMCT:SPG=0; :INFIT:FILE1=HDFILE1,FILE2=HDFILE2; ORDERED :END; EXECUTED FILE COPY INTERNAL EXECUTED SOURCE FILE DATA FILE HDFILE1 DESTINATION FILE DATA FILE HDFILE2 END

Command INFET is used to copy files between hard disk and movable media, diskette or opto disk. The command is also used for copying a file from one movable media to another. If copying to hard disk, the destination file must be created in advance. Example of file copy from HD to OD:
< INMCT:SPG=0; :INFET:FILE1=HDFILE,FILE2=FDFILE,NODE2=A,
58 R1B

FMS applications

IO2=OD-1; ORDERED :END; FILE COPY EXTERNAL EXECUTED SOURCE FILE DATA FILE HDFILE DESTINATION FILE DATA FILE FDFILE END GEN 0 VOLUME TEST NODE A IO OD-1 GEN VOLUME NODE OMFZLIBORD IO -

Note that since parameters NODE and IO are given in the command, the device file name (OD0A1) should not be used here. The copied file will have the name FDFILE on the diskette. To read this file from the diskette (command IOFAT), the name OD0A1-FDFILE must of course be used. If a file is copied from hard disk to diskette or opto disk the record length of the device file should be the same as the record length of the hard disk file. If this differs from 512 bytes a new device file should first be defined. Note: a keyed access file cannot be copied to external media.

4.7.3

Operator read/write files


All files can of course be read and written by software in the system. There is however a tool to read and write files by operator (MML) commands. The reading and writing may only be done towards sequential files (SEQ). Command example:
<IOAFT:FILE=CRYSTAL-XUJING; TRANSFER TO FILE :data to file; :data to file; :data to file; (EOT) END

In the example above data is written to the subfile XUJING of the mainfile CRYSTAL. Command example:
<IOFAT:FILE=CRYSTAL-XUJING; FILE DUMP

R1B

59

AXE IO System, IOG 20

CRYSTAL-XUJING;

data to file
END OF BLOCK 0

data to file
END OF BLOCK 1 END

In the example above the data in subfile XUJING is printed on the operator terminal. Note that in the printout FILE DUMP the END OF BLOCK must be interpreted as end of record. It must not be confused with the blocking parameter (BLK) of the file.

4.8 The duplicated file system


The duplicated file system makes sure that the data in a duplicated volume is identical in both nodes.

F ile syste m e xe cutive w orking node D uplica te d volum e a re a F ile

F ile syste m sta ndby w orking node D uplica te d volum e a re a F ile

W rite

R e sult

W rite

R e sult

D uplica te d file syste m

W rite R e sult R e sult W rite

D uplica te d file syste m

W rite orde r to file (from C P or S P )

Figure 4.10

Writing to a file in a duplicated volume

When writing to a file in a duplicated volume the write order is duplicated in the executive node and distributed to the standby node. The write results are collected and compared in the executive node.

60

R1B

FMS applications

If the data contents of the duplicated volumes in the standby node happen to be different from the data in the executive node, then the system will initiate a recovery activity. The data in a duplicated volume is in all normal cases identical in executive and standby node. The reason why the data would be different could for example be if the standby node has been blocked for some time or because of a file system error. Command example:
:IMCSP; NODE CONFIGURATION STATUS SPG 0 NPAIR 1 END NODE CM A 1 EX STATUS STATE WORKING NORMAL SB NODE CM STATUS STATE B 2 ISOLATED BLOCKED HDSTATE CORRUPT

The hard disk status may be printed with command IMCSP. The parameter HDSTATE can take the values CORRUPT or CONSISTENT. Both states will require an update. If the duplicated volumes are updated (equal), which is the normal state, the HDSTATE parameter is excluded from the printout. The recovery actions that may be taken are two:

large update small update


In the large update all data (of unknown status) in the duplicated volumes in the standby node is deleted. After this all the files are written from the executive node to the standby node. This is done via the ICB bus. The copying is load regulated (with reference to the load of the executive node) and the copying speed therefore varies. The file system is works as normal in the executive side during the update, this means users of the file system in SP or CP are unaffected by the updating activity. The fact that the duplicated volumes in the standby node are erased during the large update is a reason to be careful in operating the system when it is updating. Under no circumstances must a standby node where the duplicated volumes are not fully updated be forced in as executive. In the small update the differences between the duplicated volumes in the executive and standby node are updated towards the standby node.

R1B

61

AXE IO System, IOG 20

File system executive working node Duplicated volume area File

File system standby blocked node Duplicated volume area

Sector table
.......

File

Write Delete Duplicated file system Create

sector n ... sector y ... Duplicated file system

Delete Write

Create

Orders to file system (from CP or SP)

Figure 4.11

Blocked node

The small update is done using the so called Sector Map. When the standby node goes blocked a Sector Map is created in the executive node. The table is stored in the primary memory of the SP and is discarded at SP restart. All sectors that are changed in the executive node are recorded in this table. The table is finite, i.e. has a limited size.

File system executive node

File system standby node Updating small Duplicated volume area

Duplicated volume area File

Sector table
....... sector n ...

File

sector n Duplicated file system

sector y

Duplicated file system

sector y ....

62

R1B

FMS applications Figure 4.12

Small update

The small update updates the duplicated volumes in the standby node according to the sector table, i.e. the changed sectors are written to the standby node. The small update will be performed when a valid sector map exists and:

when deblocking the standby node or at manual SP restart or at spontaneous restart without response from the standby node
The large update will be performed when deblocking the standby node in the following cases:

at serious faults in the duplicated file system a restart in executive node has occurred (sector map discarded, cannot
perform small update).

R1B

63

AXE IO System, IOG 20

Node status during small update:


:IMCSP; NODE CONFIGURATION STATUS SPG 0 NPAIR 1 END NODE CM A 1 EX STATUS STATE WORKING NORMAL SB NODE CM STATUS STATE HDSTATE B 2 ISOLATED UPDATING S CORRUPT

During the small and large update the hard disk status (parameter HDSTATE) is CORRUPT.

4.9 Corrupt Files and File Recovery


This function is needed to correct corruptions detected in keyed files on the hard disk. The function does not detect corruptions in sequential or direct access files. A file of class key is physically implemented in a data file and a directory file. The directory file is a map which facilitates the search with keys. The data file contains the records of the file. When writing a key file both components are updated. If a SP restart or a fault in the file system occurs in between the updating of the two components the contents of them does not match. When a keyed file has been detected as having become corrupt, the file recovery function issues the alarm CORRUPT FILE WARNING, indicating which file is corrupt. The file is considered as corrupt if:

it was open during a restart and the file system has reported problems to open or access the file
The operator must first block the file with the command INFBI to prohibit reading and writing into the file and then enter the command INREI to recover the file. The command INREI will initiate recovery of a corrupt keyed file by logical copying. The directory component of the file is then rewritten on the basis of the data component. After the command INFBI to block the file is entered, the alarm FILE BLOCKED is issued to indicate that the file is blocked. At the completion of successful recovery of a corrupted file, the file is either optionally automatically deblocked, which is specified in the command INREI, or deblocked by command INFBE. As a result of this an alarm ceasing is issued to indicate that the file is now unblocked. If the

64

R1B

FMS applications

recovery of the file is unsuccessful, then the file remains blocked until the operator manually deblocks the file. The result printout states the success or failure of the recovery of the file. The command INMFP prints the list of files currently in recovery, blocked or corrupted. The File Recovery function is implemented in the RECFILE module.

4.10 File protection


Most files in the file system may be accessed with operator commands. These files may be created, deleted, copied, renamed etc. with ordinary commands. It may in some cases be necessary to block the access to some of these files by operators. This is done with the file protection function. Files included in this table may not be changed or removed in any way by operator commands. The table is specified with commands INPFI and INPFR and printed with command INPFP. Command example: <INPFI:FILE=TRARFILE; In the example above the file TRARFILE is added to the file protection table. Note: the commands for the file protection function are preferably defined as having a high grade of security in the CP authority system.

4.11 Infinite Files


The function infinite sequential files provides a file user with a virtual file of infinite size by dividing the file into a predefined number of subfiles. The infinite file function optionally compresses the file according to the FLAM method.

R1B

65

AXE IO System, IOG 20

SP or CP file user

Write to file STATFILE

FMS

Mainfile: STATFILE

-0001

-0002

-0003

-0004

-0005

Subfiles: STATFILE-0001 STATFILE-0002 STATFILE-0003 STATFILE-0004 STATFILE-0005 .....

Figure 4.13

Infinite files

The user of the file writes towards the mainfile. The infinite file functions distributes the data to subfiles belonging to the mainfile thus giving the user the impression that it is writing to the mainfile. The subfiles are created by the infinite files function. Writing is always done to the active subfile, the previous subfile is closed and the next subfile is waiting to receive data. The size of the subfiles and the number of subfiles are defined by command IOIFI. The subfiles are named sequentially with a four digit subfile name. When the last subfile is reached the infinite files will redirect the data flow to the first subfile again (-0001). This subfile must by then be transferred and deleted, i.e. the subfile name -0001 must be free to use a second time. This will normally be the case due to storage considerations; if all subfiles are still on hard disk the volume would be full. The infinite files will create subfiles in an infinite sequence stepping from -0001 to the highest subfile number (defined by command, usually -9999), and back to subfile -0001 again. If the subfile that infinite files attempts to create already exist, the infinite files function will halt and issue the alarm INFINTE FILE END WARNING. Infinite files never overwrites data. An existing composite file is defined as infinite with command IOIFI.

66

R1B

FMS applications

Command examples:
<IOIFP; FILE ATTRIBUTE INFINITE SEQUENTIAL FILE FILE TTFILE00 TTFILE01 TTFILE02 TRARFILE CMVNFILE TRDIPFILE END ACTIVESUB 0231 0001 0001 1201 0007 0763 NEXTSUB 0232 0002 0002 1202 0008 0764 NSUB 9999 9999 9999 9999 9999 9999 MAXSIZE MAXTIME 4096 4096 4096 512 1 1024 RELEASE NO NO NO YES YES YES COMP YES YES YES NO NO YES

< INMCT:SPG=0; :INFII:FILE=TTOPFILE,VOL=EXCHVOLUME,RLENGTH=2048, TYPE=SEQ,SIZE=20,FCLASS=CMP,EXP=5; :END; < IOIFI:FILE=TTOPFILE,NSUB=9999,MAXSIZE=40, MAXTIME=15,COMP=YES;

In this example the composite file TTOPFILE is defined as infinite. It can have a maximum number of 9999 subfiles. The data in the subfiles will be compressed with the FLAM compression method. Note: the compression of data is not default in the infinite file function. When subfile -0001 is full, i.e. has reached its maximum size (here 40 records) or if 15 minutes have passed before this, the subfile is automatically closed. The storing of data continues in subfile -0002. When storage starts in a subfile, the next subfile is automatically created to be used when the first subfile is closed, and so on up to subfile -9999. If the command parameter MAXSIZE is omitted, then the subfile will close after 15 minutes. If the parameter MAXTIME is also omitted then the expansion factor in command INFII must be set to zero for infinite files (EXP=0), otherwise the subfile will continue to expand indefinitely. A third parameter, RELEASE, is used for files receiving data in batch outputs. RELEASE=YES is used to ensure that the whole output goes into one subfile. When the parameter RELEASE is set to YES the switch to the next subfile is not done until the MAXTIME and/or MAXSIZE criterias are fulfilled and a release order is sent from the file user. If parameter RELEASE is omitted it takes the default value NO. Different file users handles their files differently. Some users seizes their file after restart and never release. An example is the Toll Ticketing function in the charging subsystem, CHS. Other file users makes a seizure, writes to the file and then release it. Examples of such functions are most statistic functions in OMS. Another example is the command output of call counters. For these files the release parameter is preferably set to YES.

R1B

67

AXE IO System, IOG 20

Note: setting the release parameter to yes for files with continuous output, like the toll ticketing files, would be fatal. Since the toll ticketing function never releases the file, the infinite files would never make a subfile switch. The subfile would grow infinitely and the volume would eventually fill up, causing a traffic stoppage.

-0064 Deleted -0065 SUBFILE Reported to FPU


-- " --

-0066 -0067 -0068 -0069 -0070 Data

-- " --

Active subfile Next subfile

-- " --

-- " --

(MAX -9999)

Figure 4.14

Infinite files without data compression

68

R1B

FMS applications

-0064 Deleted -0065 SUBFILE Reported to FPU


-- " --

Compressed data

-0066 -0067 -0068 -0069 -0070 Uncompressed data Data

-- " --

Active subfile Next subfile

-- " --

-- " --

(MAX -9999)

Figure 4.15

Infinite files with compression

The infinite files function may compress the data in the subfiles with the FLAM compression method. This is defined with parameter COMP in the IOIFI command. The purpose with compressing the data is to save space on hard disk (and possibly opto disk) and to save time when transferring over data link.

4.11.1

Implementation
The infinite files function is implemented in CP block FIE for command handling and modules INFFILECMD and INFFILEINT in the SP.

4.12 File Process Utility


4.12.1 General
The AXE system contains a number of functions which output data towards the IO system. These include functions in the charging subsystem, like Accounting, Pulse Metering, Toll Ticketing, Call Specification etc. These also include statistics and recording functions like Traffic Dispersion Measurement, Statistics subsystem, All Circuits Busy on Route and many others such as command log and CP backup functions. Some of these functions store their data on hard disk infinitely while other data needs to be transferred for further processing outside AXE. Example of data that may need to be transferred is the data from the above mentioned functions. The statistics and recording results needs to be transferred to an operation and maintenance centre and the charging data to a billing centre.
R1B 69

AXE IO System, IOG 20

The handling of this data requires:

transfer of data to external media removal of data from hard disk


These are the tasks of the File Process Utility function. The procedures of the File Process Utility are described in several operational instructions, all named File Process Utility, ..... The transfer of data to external media can be done to three different medias:

transfer over data link with Ericsson MTP transfer over data link with FTAM transfer to opto disk
Note: market systems may exist where the FTAM protocol is not implemented. The removal from hard disk is done according to certain removal criterias, depending on transfer method. File Process Utility usually interworks closely with the Infinite Files function in that the Infinite Files reports all subfiles which are full to FPU. FPU also interworks with the command log but may actually be used for any kind of files. FPU operates in SPG0, SPG1, SPG2 and SPG3 (if installed). Although FPU is mostly used to transfer charging and statistics data from the AXE to a remote centre, it may be used for any file transfer to and from the AXE IO system. An example: when sending SP or CP backups to the IO system from remote, for remote function change, FPU is used.

4.12.2

FPU concepts
A few concepts must be clarified before looking at the commands:

FPU destinations Equipment type Subfile list Sequence number

Transferring a file or subfile to or from somewhere is in FPU referred to as transferring it to a destination. A destination is a logical concept to which a file or mainfile must be connected. To be connected to a destination is to be processed by the FPU function. One file/mainfile may be connected to more than one destinations (up to 16) and one destination may have more than one file connected to it.
70 R1B

FMS applications

A file/mainfile is connected to a destination by command INFDI. FPU destinations:


<INFDP; FILE PROCESS UTILITY DESTINATION LIST SPG 0 0 1 END DEST TTFILEOD AOM STATDEST

The destinations may be of one of three equipment types:

NOLINK MTP FTAM


The equipment type NOLINK indicates that the files connected to a destination of this equipment type will be transferred to opto disk. The equipment type MTP indicates that the files connected to a destination of this equipment type will be transferred over data link with the Ericsson MTP protocol. The file may however also be transferred to opto disk. The equipment type FTAM indicates that the files connected to a destination of this equipment type will be transferred over data link with the FTAM protocol. The file may however also be transferred to opto disk. If a destination is of equipment type MTP or FTAM it must be defined in subsystem DCS with command ILDNI. Subfile list. When connecting a mainfile to a destination a subfile list is created. When a subfile belonging to this mainfile is reported to FPU it will be listed in the subfile list. The reporting of a subfile to FPU is usually done by the infinite files function but may also be done by the command log function. With the commands INFSI and INFUE subfiles may manually be reported to, or removed from, the FPU subfile list. The fact that a mainfile connected to a FPU destination has a subfile, does not necessarily mean that this subfile is reported to the FPU subfile list.

R1B

71

AXE IO System, IOG 20

The subfile list records a number of parameters for each subfile:

subfile name subfile size in records time of reporting to FPU whether the subfiles has been sent to opto disc the sequence number when the file was transferred over data link automatically when the file was transferred over data link manually a fault code if the data link transfer failed

The subfile list is printed with command INFSP which has two different formats. Example of subfile list:
< INFSP:FILE=TTFILE00,DEST=TTFILEOD; FILE PROCESS UTILITY SUBFILE LIST FILE = TTFILE00 DEST = TTFILEOD SUBFILE 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 END SIZE 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 TRANSF NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO DUMPED SEQNUM YES YES YES YES YES YES YES YES YES YES YES YES NO NO NO NO

FPU subfile data:


<INFSP:FILE=TTFILE00-2362,DEST=TTFILEOD; FILE PROCESS UTILITY SUBFILE DATA FILE = TTFILE00 GENERATION STATUS
72

SUBFILE = 2362 SIZE 1000

DEST = TTFILEOD SEQNUM

STARTTIME

STOPTIME

FAILTIME

REASON
R1B

FMS applications

DEFINITION MAN TRANS AUT TRANS DUMP1 DUMP2 END

970605 1121

970605 1128

970605 1130

Sequence number. The sequence number parameter is still in the printout but is not used when dumping to an opto disk. It is used in IOG11 when dumping to magnetic tape to keep track of which subfiles belongs to a certain magnetic tape. Although the use of the magnetic tape is not supported in IOG20, the parameter SEQNUM still exists for compatibility reasons. In the example it can be seen that the subfiles -2351 to -2362 are dumped to an OD. The subfiles -2363 to -2366 are not dumped at all and the reason is that these have been reported to FPU after execution of the INFMT command.

4.12.3

Transfer over data link with Ericsson MTP


The link transfer with the Ericsson MTP protocol may be performed in four different ways:

automatically - initiated from IOG automatically - initiated from remote destination manually manual re-transfer of an already transferred subfile

Automatic Transfer initiated from IOG Command example:


< INFDI:FILE=SPFILE01,DEST=BC,EQUIP=MTP;

In the example above the mainfile SPFILE01 is connected to a destination BC of equipment type MTP, i.e. data link with Ericsson MTP protocol. Subfiles belonging to mainfile SPFILE01 may when reported to FPU be sent over a data link with the Ericsson MTP protocol. The automatic transfer of the subfiles from IOG with Ericsson MTP, may be performed in two ways:

immediate transfer transfer at a certain time


An immediate transfer is done when a subfile is reported to the FPU subfile list. This is usually done automatically by the Infinite files. It may also be done by the command log function or by command (see above). FPU then transfers all reported subfiles to the specified destination as soon as possible.
R1B 73

AXE IO System, IOG 20

If transfer at a certain time is required a so called FPU Time Slot must be defined. The time slot defines two hours of the day during which data is transferred. Command example:
<INFPC:DEST=BC,TIME1=0600,TIME2=0800,SPG=0;

In the example above the automatic sending of subfiles to destination BC over Ericsson MTP will be done between six and eight oclock in the morning. The time slot may be overridden by command INFOI. When command INFOI is given for a certain destination all non-transferred subfiles in the FPU subfile list (for this destination) are transferred immediately. Command example:
<INFOI:DEST=BC,OVERRIDE=ON,SPG=0;

The INFOI command can also halt all transfer over data link to a certain destination, irrespective of the time slot. Command example:
<INFOI:DEST=BC,OVERRIDE=OFF,SPG=0;

Normal time slot function is restored by command INFOE, time slot override end. Command example:
<INFOE:DEST=BC,SPG=0;

Automatic Transfer initiated from remote When the remote side initiates the sending over data link (with Ericsson MTP) it is called polling. Command example:
<INFDI:FILE=ICIFILE01,DEST=BC,EQUIP=MTP,POLL;

For polling, the parameter POLL is included in command INFDI. In the example above the subfiles belonging to mainfile ICIFILE01 may be polled from destination BC over Ericsson MTP. Only subfiles in the FPU subfile list may be polled, not all subfiles belonging to mainfile ICIFILE01. FPU time slots are irrelevant for polled transfer. The transfer cannot be affected from the IOG side (apart from blocking the data link). Manual transfer The manual transfer over data link with Ericsson MTP may be done in two

74

R1B

FMS applications

directions:

from IOG to remote from remote to IOG


Command example:
<INFDI:FILE=SPFILE01,DEST=BC,EQUIP=MTP; <INFTI:FILE=SPFILE01-2076,DEST=BC;

In the example above the subfile SPFILE01-2076 is transferred from IOG to destination BC over Ericsson MTP. Command example:
<INFDI:FILE=SPFILE01,DEST=BC,EQUIP=MTP; <INFTI:FILE=SPFILE01,DEST=BC;

In the example above all subfiles belonging to SPFILE01 which are reported to FPU are transferred from IOG to destination BC over Ericsson MTP. Command example:
<INFDI:FILE=RELFSW2,DEST=AOM,EQUIP=MTP; <INFTI:FILE=RELFSW2-R5,DEST=AOM,REVERSE;

In the example above the subfile RELFSW2-R5 is transferred from an operation and maintenance centre to IOG. The operation and maintenance centre is destination AOM. The mainfile RELFSW2 must exist on the hard disk. A manually initiated file transfer may be interrupted by command INFTE. The OPI to be used for manual transfer over a data link is called File Process Utility, Manual File Transfer, Start. Manual re-transfer of an already transferred subfile Manual re-transfer may be performed on subfiles that already has been sent once over data link with Ericsson MTP. Whether a certain subfile has been sent or not can be seen in the FPU subfile list. Both subfiles that are sent manually, automatically from IOG or automatically from the remote destination (polled) may be re-transferred. The re-transfer transfers not only the subfile indicated in the command but all subfiles reported to the FPU subfile list after the indicated subfile. This is referred to as a roll-back. Command example:
<INFRI:FILE=SPFILE01-2076,DEST=BC;

R1B

75

AXE IO System, IOG 20

Assume that subfiles SPFILE01-2042 to -2081 are reported to the FPU subfile list and transferred over data link. The subfiles SPFILE01-2076 to -2081 will be re-transferred to destination BC.

4.12.4

Transfer over data link with FTAM


File transfer and Management, FTAM, is an industry standard protocol. The link transfer with the FTAM protocol may be performed in two different ways:

automatically - initiated from IOG automatically - initiated from remote


The file connected to FPU must be defined as a virtual file in FTAM. Automatic Transfer initiated from IOG In this case the FTAM in the IOG acts as initiator. Command example:
<INFDI:FILE=TRDIPFILE,DEST=AOM,EQUIP=FTAM;

Automatic Transfer initiated from remote In this case the FTAM in the IOG acts as responder. Command example:
<INFDI:FILE=TRDIPFILE,DEST=AOM,EQUIP=FTAM,POLL;

4.12.5

Dumping to opto disk


Dumping of subfiles with FPU to opto disk is always done manually. The command INFMT is used and requires that a formatted opto disk is inserted and the volume is loaded. Command example, connection of a file to a destination with equipment type nolink:
<INFDI:FILE=PERIODICACC,DEST=ODDEST,EQUIP=NOLINK;

Assume that subfiles are now being reported to FPU. FPU subfile list:
<INFSP:FILE=PERIODICACC,DEST=ODDEST; FILE PROCESS UTILITY SUBFILE LIST FILE=PERIODICACC SUBFILE 0001 0002 0003 SIZE 1000 1000 1000 DEST=ODDEST TRANSF NO NO NO DUMPED NO NO NO SEQNUM

76

R1B

FMS applications

0004 0005 0006 0007 END

1000 1000 1000 1000

NO NO NO NO

NO NO NO NO

Command example, transfer of subfiles to an opto disk:


<INFMT:DEST=ODDEST,VOL1=ODVOLSIDE1;

In the example above all reported and non-dumped subfiles of all files connected to destination ODDEST will now be copied to the opto disk having the volume name ODVOLSIDE1. In our example we assume that the only file connected to destination ODDEST is PERIODICACC. FPU subfile list:
<INFSP:FILE=PERIODICACC,DEST=ODDEST; FILE PROCESS UTILITY SUBFILE LIST FILE=PERIODICACC SUBFILE 0001 0002 0003 0004 0005 0006 0007 END SIZE 1000 1000 1000 1000 1000 1000 1000 DEST=ODDEST TRANSF NO NO NO NO NO NO NO DUMPED YES YES YES YES YES YES YES SEQNUM

The manual dumping to an opto disk may also be done in parallel, towards two medias at the same time. This is called duplicated output and requires that two different opto disks are inserted, one in each node, and the volumes are loaded. Serial output is not possible. Command example for parallel transfer:
<INFMT:DEST=ODDEST,VOL1=ODVOLSIDE1,VOL2=ODSTAT;

4.12.6

Copying to Data Link and OD


If both transfer and dumping of subfiles is required, then two separate destinations must be defined, as shown in the following example:
<INFDI:FILE=TTFILE,DEST=TTFILEOD,EQUIP=NOLINK; <INFDI:FILE=TTFILE,DEST=HQ,EQUIP=FTAM;

The removal conditions should be based on the dumping condition to ensure no removal of the subfiles before a manual dump has been made.

R1B

77

AXE IO System, IOG 20

Also, when more than one destination is defined, the removal conditions relate to the first defined destination. Thus INFDI for destination TTFILEOD must be given first in this case. If INFDI for the data link was given first then the subfiles would not be removed even after the dump. In the above example, transfer of the subfiles via data link does not affect the removal of the subfiles from hard disk. They will only be removed according to the removal conditions after the subfiles have been dumped to opto disk.

4.12.7

Copying to Data Link or OD


FPU output can be defined so that the subfiles can be transferred either over a data link or to a opto disk. This would allow the subfiles to be dumped to OD if a data link failed. If we require both transfer and dumping, independently of each other, then two separate destinations must be defined with INFDI as described above. To define an output for transfer to destination HQ or dumping to opto disk the data is defined as follows:
<INFDI:FILE=TTFILE,DEST=HQ,EQUIP=FTAM;

With EQUIP=FTAM, the default case, transfer is possible to both data link or opto disk. If the data link failed, the subfiles could now be dumped instead to opto disk using:
<INFMT:DEST=HQ,VOL1=ANYVOL;

In the above case where EQUIP=FTAM is used, copying to opto disk would only be defined as a backup to the data link in case this failed.

4.12.8

Renaming of files
The file process utility may rename the subfiles when transferring them. The renaming is usually done in order to identify the origin of the subfiles, i.e. the filename is changed according to the switch they originates from. An adjustment is also made in order to comply to other file systems than in FMS. Since the concept of a composite file is AXE-specific, the mainfile and subfile names are merged to one file name. Below are three examples of adaptation of a file name to an external file system: File in FMS: PERIODICACC-0007 PERIODICACC-0007 PERIODICACC-0007 File in external file system: PERIODICACC.0007 PERIODICACC0007.0000 PERIODICACC-0007

78

R1B

FMS applications

In the first case the FMS file name is adapted to a file system where generations are supported. The mainfile name forms the file name in the external file system and the subfile name are converted to file generation. In the second case the FMS file name is adapted to a file system where generations are supported. The mainfile and subfiles names are concatenated forming the file name in the external file system. The generation is set to zeroes. In the third case the external file system supports the same file structure as in FMS. The file name is kept. In addition to this adjustment a renaming may be done: File in FMS: PERIODICACC-0007 PERIODICACC-0007 PERIODICACC-0007 File in external file system: PERACCTOWN.0007 PERACCTOWN0007.0000 PERACCTOWN-0007

In the example above the file is renamed to indicate from which switch the files originate, TOWN. Which renaming method is defined with command INFDI, when connecting a file to a destination. Command example:
< INFDI:DEST=BC,EQUIP=MTP,FILEID1=PERACCTOWN, RULE1=1;

File in FMS: PERIODICACC-0007 Command example:

File in external file system: PERACCTOWN.0007

< INFDI:DEST=BC,EQUIP=MTP,FILEID1=PERACCTOWN, RULE1=2;

File in FMS: PERIODICACC-0007 Command example:

File in external file system: PERACCTOWN0007.0000

< INFDI:DEST=BC,EQUIP=MTP,FILEID1=PERACCTOWN, RULE1=3;

File in FMS: PERIODICACC-0007

File in external file system: PERACCTOWN-0007

4.12.9

Automatic Removal of subfiles


Once the subfile is safely transferred (or dumped) over data link or to opto disk, the subfiles must be removed to free the space on the hard disk.

R1B

79

AXE IO System, IOG 20

The removing of the subfiles is handled by FPU only for equipment types NOLINK and MTP, i.e. if opto disk or data link with Ericsson MTP is used. If a data link with FTAM is used the removal of the subfiles from the IOG hard disk is controlled and performed from remote via FTAM. If the removal of the subfiles is handled by FPU it is controlled by two parameters:

removal conditions removal time


The removal of a subfile is done if both the removal conditions and removal time are met. The removal conditions depends on the equipment type of the destination, i.e. the way the data has been transferred. The possible removal conditions are: Equipment type: NOLINK MTP Removal condition: DUMP DUPL AUTO MAN

(No removal conditions are set for equipment type FTAM.) The removal time is the time after which the subfiles may be removed. The time is specified in hours and minutes. The time is calculated from the time when the subfiles are reported to the FPU subfile list. So the countdown starts when the subfile is reported to FPU, not when the subfile is transferred over link or dumped to opto disk (which is done after the reporting). Note: this may be changed by a deferred constant! The removal conditions and time are set by command INFCC. Command example:
< INFDI:FILE=ICIFILE02,DEST=BILLING,EQUIP=MTP; < INFCC:FILE=ICIFILE02,TRANSCOND=AUTO, REMOVE=02400;

The subfiles of the file ICIFILE02 will be deleted from the hard disk 24 hours after they are reported to FPU, but only if the subfiles have been automatically transferred over data link. Command example:
< INFDI:FILE=TRACAFILE,DEST=OD,EQUIP=NOLINK; < INFCC:FILE=TRACAFILE,DUMPCOND=DUPL;
80 R1B

FMS applications

The subfiles of the file TRACAFILE will be deleted from the hard disk when the subfiles have been copied to opto disk twice. The setting of the removal times for frequently output data must be done calculating the traffic of the switch. The wish to keep the data on hard disk as long as possible, for security, must be weighted against the need for new hard disk space for new data. If the telephony traffic and data output is high the removal times must be set shorter.

4.12.10

Printout Commands for FPU


The following printout commands are useful when working with FPU: <INFDP; to get defined FPU destinations <INFDP: DEST=dest; to get files for destination <INFUP; to get the files defined for FPU <INFUP:FILE=file; to get FPU data for a file (e.g removal data) <INFSP:FILE=file,DEST=dest; to see which subfiles have been reported, transferred, dumped and removed from hard disk. The OPI used for automatic transfer of subfiles over data links is called File Process Utility, File and Destination, Define. The OPI used when transferring to OD is called File Process Utility, Removable Media, Single Dumping/parallel Duplication.

4.13 Decompression of files


When receiving files from outside the AXE into the IO system these files may in some cases be compressed, this usually to speed up the transfer over data link. Examples of such files may be CP backups or SP backups downloaded to the IO system via data link for a remote function change. IOG 20 supports two decompression methods:

FLAM PKZIP
Command example:
:IMDCI:FILE1=COMPREL,FILE2=RELFSW99;

In the example above, all subfiles of the mainfile COMPREL are decompressed into mainfile RELFSW99. The original compressed subfiles are kept on hard disk. The destination mainfile RELFSW99 must be created before hand. Which subfiles in a mainfile are to be compressed can be printed with command INCMP. Command example:
R1B 81

AXE IO System, IOG 20

:IMDCP:METHODS;

In the example above all available decompression methods are listed. Command example:
:IMDCP:STATUS;

In the example above all ongoing decompressions are listed. An ongoing decompression may be interrupted with command IMDCE. Note that the compression of files may in IOG20 only be done with the FLAM compression method and only when using infinite files.

4.14 Command Log in AXE


The Command Log function is for logging subscriber commands (from keysets) and operator commands that manipulate exchange data in the CP. The log is used to restore the data store in the CP after a reload with all the data logged between the last data dump and the reload. The function is activated and deactivated by operator command.

4.14.1

Implementation
The function is administered by the FMS block LOGB in the CP.

4.15 Chapter Summary


Storage medium, volume and file are the basic FMS concepts The storage medium consists of the hard disks, flexible disks and opto
disks

Internal volumes are volumes located on a hard disk External volumes are volumes located on a flexible disk or opto disk FMS has a supervision of the used space on a volume. If the supervision limit is exceeded, then an APZ alarm is issued

PROG_A, PROG_B, OMFZLIBORD and RELVOLUMSW are system


defined volumes. The rest of the volumes are market dependent

PROG_A and PROG_B, usually the only unduplicated volumes, contain the SP software, including RPV/RPV2 and LUM software and the SP system files. The SP trace log files are stored here as well

OMFZLIBORD is a duplicated volume, which contains the SP


exchange data and a series of logs and other files used by the maintenance functions, as well as other files created by the SP when required

RELVOLUMSW is a duplicated volume, which contains the Central


Processor back up files and the command log

The data in a duplicated volume is identical in both nodes In large update all data in the duplicated volumes is transferred, via the
ICB, from the executive node to the standby node

In small update only the differences between the duplicated volumes is


82 R1B

FMS applications

transferred, via the ICB, from the executive node to the standby node

Three file types exist, namely sequential (SEQ), direct access (DIR)
and keyed access (KEY)

Three file classes exist, namely simple (SPL), composite (CMP) and
device (DEV)

A file has a unique name and belongs to a volume A file can be copied internally hard to hard disk or externally between
hard disk and moveable media or between to moveable medias

Corrupt key files can be recovered by the operator The infinite file function will create subfiles in an infinite sequence
stepping from -0001 to the highest subfile number, usually -9999, and back to subfile -0001 again

The infinite file function may compress the data in the subfiles. The
compression saves space on the hard disk and time when transferring

File process utility (FPU) administers the transfer of data from the hard
disk to an external media and removal of data from the hard disk

Example of files defined in FPU: toll ticketing, pulse metering, call


specification, accounting, different statistics files, etc.

The transfer of data to the external media can be done over data link
with Ericsson MTP or FTAM or transferred locally to an opto disk

Subfiles can be decompressed by operator command

R1B

83

AXE IO System, IOG 20

84

R1B

5. System Backup Handling

Chapter Objectives
After completing this chapter the student will be able to: Perform a manual CP backup with the help of the relevant OPI Be familiar with the commands for rotating the file names for CP backups and for changing the file names of these dumps Explain and carry out a Conversion of System Backup files from external media or data link Explain the purpose and function of the command log Explain how the reloading of the CP is done and how this can be controlled by operator
Figure 5.1

Chapter Objectives

5.1 Introduction
This chapter deals with the backup storage and handling of CP and SP backups. The CP and SP backups together contains all software and data in the AXE system. Other software which is stored in the AXE IO system but is not part of AXE could for example be radio base software. This kind of software is not described here.

5.2 Backup Functions of the CP


A CP backup consists of:

CP, RP, EMRP, EMRP-D, RP-D and RPG/RPG2 software Data stored variables, i.e. exchange data CP reference store
CP backups may stored in two places in the AXE system:

In primary memory of CP (Backup in Main Store) On hard disk


When stored in primary memory of CP the backup is located in DS or PS depending on APZ version. This is called Backup In Main Store.
R1B 85

AXE IO System, IOG 20

The reason to store a backup in CP primary memory is the short times for backing up and for reload. The drawbacks are that about twice as much primary memory is needed in the CP and that the backup doesnt survive a power reset. Backup in main store must always be combined with a backup on hard disk. The primary memory may hold only one backup copy. When stored on hard disk the CP backup copies are stored in composite sequential files with predefined names. The CP backup files are always stored in volume RELVOLUMSW. The limitation to the number of CP backup files that may be stored on the hard disk is the size of volume RELVOLUMSW.

5.2.1

CP Backup in Main Store


The CP backup in Main Store is an optional function which is not necessarily used. The backup may have two different formats:

CP full backup CP backup of data store


The full backup is a copy of the entire dump. The backup of Data Store stores only the contents of Data Store. Command example:
< SYBMS:STORE=DS;

With the above command the backup in Main Store is limited to keep a backup copy of the data store only. Command example:
<SYBMS:STORE=NONE;

With the above command the backup in Main Store function is deactivated. The only CP backup is now stored on hard disk.

5.2.2

CP Backup on hard disk


A backup file is a composite file with six subfiles named R0, R1, R2, R3, R4 and R5. The name of a backup file is standardized to RELFSWn, where n=0 - 127.

86

R1B

System Backup Handling

Mainfile RELFSWn

Subfiles: R0 Control data

R1 Charging data, small backup, DS R2

R3 Reload marked variables, large backup, DS R4

R5

Contents of RS and PS

RS - Reference Store PS - Program Store DS - Data Store

Figure 5.2

CP backup file on hard disk

The subfile R0 contains control data for administration of the other subfiles, such as information indicating the subfiles to be loaded in the event of a reload. The CP dump header is stored in this subfile. The subfiles R1 and R2 contain charging data, mostly private meters. The automatic backup operation alternates between the two subfiles where the older version is overwritten with new data. These data are dumped at small automatic backups. In case of a reload the newest small dump will be loaded into the system. The subfiles R3 and R4 contain reload marked variables, i.e. variables to be loaded in conjunction with a reload. This file stores the exchange data of the system. R3 and R4 contain different versions of data dumped at different times at large automatic backups. For security reasons the older large dump will be loaded into the system if an automatic reload occur as it is less likely to contain a data fault that may have caused the reload. The subfile R5 contains a copy of the Program Store (PS) and Reference Store (RS) which are only dumped at manual dumps. This is usually the largest subfile. R5 is always loaded at a reload. CP backups may be output in two ways:

Manually by command Automatically according to a predefined time schedule

R1B

87

AXE IO System, IOG 20

5.2.3

Manual backup of CP
The manual backup of CP may be done towards:

primary memory and hard disk or hard disk


Manual backup of the CP must always be done when a size alteration, functional change or a program correction in the CP has been performed. Manual updating of the system backup files is also recommended to be done as a routine job. The command SYBUP dumps the CP backup to hard disk, and to primary memory if the backup in main store function is active. Note that the program store of the CP does not only store CP software but RP, EMRP, RP-D, EMRP-D and RPG/RPG2 software. All this is part of the CP backup. Command example:
<SYBMS:STORE=ALL; <SYBUP:FILE=RELFSW3;

In the example above the CP backup is stored in primary memory and on file RELFSW3 on hard disk. Command example:
<SYBMS:STORE=NONE; <SYBUP:FILE=RELFSW6;

In the example above the CP backup is stored in file RELFSW6 in volume RELVOLUMSW on the hard disk. The manual CP backup may be done towards any of the files on hard disk, except file RELFSW0 or files in the second file range, SFR (see below). File RELFSW0 is the default reload file and must therefore always be intact. If a backup is done towards a file which contains a CP backup, the old backup is overwritten. It is important to dump some types of data regularly so that the information will not be lost in the event of a serious failure (stoppage). This is done by the automatic CP backup function.

5.2.4

Automatic CP backup
The automatic CP backups are output to:

CP primary memory and file RELFSW0 or file RELFSW0


88 R1B

System Backup Handling

Whether the CP primary memory is updated or not depends on whether the backup in main store function is activated. There are two types of automatic CP backups:

small large
Charging information, i.e. call meter values, changes all the time. This charging data is dumped in small backup. Note that charging data of type Toll Ticketing, Call Specification or Immediate Call Itemisation is NOT part of the small CP backup. Data which are normally changed by command and which change only occasionally are dumped at large backups. These data are changed, for example, when an operator connects a new customer line, adds a trunk line or change an alarm threshold. A change of this kind can also be done by a customer using a subscriber service, e.g. ordering a wake up call. When making these types of changes, the values of the so called reload marked variables are altered. These reload marked variables are dumped at a large automatic dump. This type of dump is normally performed once a day. The automatic CP backup is always performed towards file RELFSW0. The reason is that this is the default reload file (the system may reload from other files, see below). The automatic CP backup is performed at times specified by command SYBTS in the operational instruction Backup Information Dump Output Times, Specify. Command example:
<SYBTS:TIME=0000,TDMI=240; <SYBUI:DISC;

In the example above the large automatic CP backup is performed at midnight and the small once every fourth hour. This is a common way of defining the automatic CP backup. This is of course market dependent. The automatic dumping function has to be activated by command SYBUI and deactivated by SYBUE.

5.2.5

CP Backup Handling
The CP backup files on hard disk are divided in two ranges, the first and second file range.

First file range, FFR, includes the files RELFSW0 - RELFSW99 Second file range, SFR, includes the files RELFSW100 - RELFSW127
Usually about three files (i.e. CP backups) are kept in each file range. This is depending on the available hard disk space in volume RELVOLUMSW.
R1B 89

AXE IO System, IOG 20

The reason for keeping two file ranges is security. The second file range contains older version of the CP backup while the first file range contains newer. The reload function in the CP may select backups files from the second file range if backup files reloaded from the first file range prove to be corrupt.

HD node A and B, SPG0 Automatic dump Reload CP RS, PS and DS Manual dump RELFSW2 RELFSW1 First File Range RELFSW0

RELFSW100 RELFSW101 RELFSW102 Second File Range

Figure 5.3

Manual and automatic CP backup

The automatic CP backup is done towards file RELFSW0. Thus RELFSW0 is always kept up to date with the latest information. This file is usually also loaded in case of an automatic reload. The selection of which file(s) will be reloaded at an automatic reload is described below in the next section. A manually initiated dump creates a new backup generation. This dump will overwrite one of the backup files, RELFSW1 or RELFSW2, depending on the parameter value used when ordering the dump. Normally the manual dump is made on the oldest backup file, i.e. RELFSW2 (see Figure 5.3). Note that a manual backup cannot be made towards the second file range. With commands the file names can be rotated and changed so that, for instance, the latest manual dump file will be renamed RELFSW0 and become the automatic backup file.

90

R1B

System Backup Handling

<SYTUC;
First File Range

RELFSW0 RELFSW1 RELFSW2

<SYTUC:SFR;
Second File Range

RELFSW100 RELFSW101 RELFSW102

Figure 5.4

Rotation of CP backup files on hard disk

Command SYTUC can be used for name rotation of system backup files if RELFSW2 is newer than RELFSW0 and RELFSW0 is not empty. Command SYTUC is normally used after a manual dump to RELFSW2. See Figure 5.4.

R1B

91

AXE IO System, IOG 20

<SYNIC;
First File Range

RELFSW0 RELFSW1 RELFSW2

<SYNIC:SFR;
Second file Range

RELFSW100 RELFSW101 RELFSW102

Figure 5.5

Rotation of CP backup files on hard disk

Command SYNIC can be used to change the file names when RELFSW2 is newer than RELFSW0 or when RELFSW0 is empty. SYNIC is normally only used at the first load of the exchange when, after the first manual dump, RELFSW2 is renamed RELFSW0. Figure 5.5. There is a third way of rotating the files. With command INFIC the backup files can change names or be given any name. This way of renaming files is preferably avoided, particularly in a live switch. This method is however very useful during installation test or in a test plant environment where the conditions for sending the commands SYTUC or SYNIC are not satisfied. Command example:
< INMCT:SPG=0; :INFIC:FILE1=RELFSW0,FILE2=RELFSWX; :INFIC:FILE1=RELFSW2,FILE2=RELFSW0; :INFIC:FILE1=RELFSWX,FILE2=RELFSW2; :END;

This example could have been where an older generation has been loaded into RELFSW2 from an opto disk, but is required to be in RELFSW0. In this case commands SYTUC and SYNIC could not be used.

92

R1B

System Backup Handling

Note that the commands SYTUC and SYNIC are part of the system backup functions and can only be used with the files with names RELFSWn.

<SYSFT;
First File Range

RELFSW0 RELFSW1 RELFSW2

RELFSW100 Second File Range Old contents are overwritten


Figure 5.6

RELFSW101 RELFSW102

Transfer of CP backup from first to second file range

The command SYSFT will copy RELFSW1 from the FFR to the highest consecutive number in the second file range. The old CP backup in the destination file will be overwritten. Command example:
<SYSFT;

Note that a manual backup cannot be performed towards the second file range. The command SYSFT is the only way to write a CP backup file in the second file range. With the command SYBFP it is possible to check which CP backups exist on hard disk or in primary memory. Command example:
<SYBFP:MS;

In the example above data related to the backup in main store is printed. Command example:
<SYBFP:FILE;

R1B

93

AXE IO System, IOG 20

In the example above data related to the backup files on hard disk is printed.

5.2.6

CP backup transfer to/from IOG


RP bus A RP bus B SYBUP SP

CP

ICB

RPV/RPV2 HD AT HD
ALI

SYACI SYCFI

SYMTP

FD OD

DL (via FPU)

Figure 5.7

CP backup conversion to/from external media

The CP backup may be transferred to and from the AXE system in three different ways:

via external media opto disk via external media diskette via data link
The conversion to opto disk is done by command SYMTP. One side of an opto disk is usually enough space to store more than one CP dump. The CP backup is converted to six separate files which are named according to what is specified in the command. The output conversion may be done in two ways:

full backup economic backup


The full backup contains all six subfiles while the economic contains subfiles R0 and R5, the youngest of R1, R2 and the oldest of R3, R4. The economic CP backup contains four subfiles.
94 R1B

System Backup Handling

Command example:
< SYMTP:SPG=0,DIR=OUT,ECO,FILE1=RELFSW3, FILE2=DUMP3,NODE=B,IO2=0D-1;

In the command example above the subfiles RELFSW3-R0, -R1, -R4 and -R5 are output to the opto disk in the B-node. The volume of this opto disk must be loaded. The files on the opto disk will be named DUMP3R0, DUMP3R1, DUMP3R4 and DUMP3R5. Command example:
< SYMTP:SPG=0,DIR=IN,FILE1=RELFSW101,FILE2=RELFP7, NODE=A,IO2=OD-1;

In the command example above the files RELFP7R0, RELFP7R1, RELFP7R2, RELFP7R3, RELFP7R4 and RELFP7R5 are input from the opto disk in the A-node. The volume of this opto disk must be loaded. The files on the hard disk will be RELFSW101-R0, -R1, -R2, -R3, -R4 and R5. The conversion to/from flexible disk is done with the commands SYACI and SYCFI. A flexible disk has a storage capacity of 1.44 MB therefore it takes many diskettes to store a CP backup. The output conversion may be done in two ways:

full backup economic backup


The full backup contains all six subfiles while the economic contains subfiles R0 and R5, the youngest of R1, R2 and the oldest of R3, R4. The economic backup contains four subfiles. Command example:
< SYACI:SPG=0; :SYCFI:FILE=RELFSW3,DIR=OUT,IO=FD-1,NODE=B; :SYCFP; ORDERED

(release terminal)
< SYACI:CON; :SYCFP; ORDERED

(this sequence is repeated for all diskettes)


END

In the command example above all subfiles of file RELFSW3 is converted and output to diskette. The diskette of course has to be changed in between giving the commands. The result printout tells us when to replace the dis-

R1B

95

AXE IO System, IOG 20

kette or when the backup is finished. The sequence of the diskettes is important and they must therefore be carefully labelled. Command example:
< SYACI:SPG=0; :SYCFI:FILE=RELFSW3,DIR=IN,IO=FD-1,NODE=A; :SYCFP; ORDERED

..
< SYACI:CON; :SYCFP; ORDERED

(this sequence is repeated for all diskettes)


END

In the command example above all subfiles of file RELFSW3 are converted and input from diskette. The diskettes of course has to be changed in between giving the commands. The diskettes must be inserted in the diskette drive in the correct sequence. The transfer to/from a data link can be done via protocols Ericsson MTP or FTAM. The sender or receiver of the files is the File Process Utility. Command example:
<INFDI:DEST=DUMPDEST,EQUIP=MTP,FILE=RELFSW102; <INFSI:FILE=RELFSW102-R0; <INFSI:FILE=RELFSW102-R1; <INFSI:FILE=RELFSW102-R2; <INFSI:FILE=RELFSW102-R3; <INFSI:FILE=RELFSW102-R4; <INFSI:FILE=RELFSW102-R5; <INFTI:FILE=RELFSW102,DEST=DUMPDEST;

In the command example above the main file RELFSW102 (belonging to the second file range) is connected to FPU. The subfiles are reported to the FPU subfile list and finally sent over the link with a manual transfer. The subfiles may of course be polled from the remote end, or transferred using the FTAM protocol. Which method to used is specified by the INFDI command. Note: the procedures are explained in the operational instruction System Backup Copy from Hard Disk to Removable Media, Convert

5.2.7

Automatic CP reload
Automatic CP reload happens if a serious software of data error has been detected by the system. If the ordinary recovery action does not remedy

96

R1B

System Backup Handling

the fault the system may reload a CP backup. An automatic CP reload will cause a temporary traffic stoppage in the switch. An automatic CP reload may be done from two medias:

CP primary memory Hard disk


The reload from CP primary memory is selected as the first alternative. A prerequisite is that the backup in Main Store function is activated. If the CP backup in primary memory consists of data store only, the automatic reload is always started with a check summing of the executing PS/ RS. If the checksum is OK the DS is reloaded from primary memory. If the checksum is not OK the automatic reload is performed from hard disk (of PS, RS and DS). If the first alternative fails or if the backup in main store is not activated, the system will continue by reloading from hard disk. The reload from hard disk is per default done via link 0 in the SPG0. The central processor is hard-coded to search its backup via RP address 1. If the communication towards RP address 1 fails the system will search on RP addresses 4, 2, 3, 5, 6, 7, and 8 in sequence. If communication is established with RP address 1 but no reload file is found then the reload is considered failed and no further search on other RP addresses will be performed. The default selection of reload file is RELFSW0 on RP address 1. There is however a range of possibilities for controlling the reloading function by command SYGPS. Among other things it is possible to control whether or not the relevant command log subfiles shall be loaded when loading a dump. The operator can also include the second group (SFR) among the reload files. These files will be taken if none of the first files (FFR) result in a successful reload (the time between two reloads exceeds a limit set by command). The complete function is controlled and handled by command SYGPS, which is used to specify the handling of the reloading. The automatic function, which loads the command log automatically, can be totally switched off by using the parameter SYGPS:CLH=MAN;. If this command is used, the command log is handled manually in the same way as in older APZ versions. However, if parameter CLH=AUT is chosen, a large number of parameters affect the reload as well as how the command log is handled. The first reload from the file is always done with the youngest reload file and the complete command log. Note that a reload from the Main Store does not affect this function. This means that an unsuccessful reload attempt from Main Store does not affect this function.

R1B

97

AXE IO System, IOG 20

If a second reload is done within the supervision time stated by parameter SUP, the parameters set by command SYGPS control the selection of next reload file as well as the handling of the command log. The reload attempts after the first one are controlled by the parameters in command SYGPS. An example is given to explain how the parameters control loading. The stored data in the function can be printed with command SYGPP. The command and printout example below shows the printout with some parameters loaded. System backup generation handling:
<SYGPP; BACKUP GENERATION HANDLING PARAMETERS CLH AUT NTAZ NTCZ 1 10 LOAZ 0 INCL1 RELFSW0 INCL2 101 INCLA 97062 SUP 60

LAST RELOADED FILE NAME CREATED RELFSW0 970618 END

AT 0832

Here is a short explanation of the different parameters in the example: CLH NTAZ Can be set to AUT for automatic handling of the backup system or MAN for manual. Number of truncation attempts with RELFSW0. If this parameter is set to zero, the following two parameters are insignificant. Number of additional commands to be truncated at each reload attempt. This parameter is set to 10 in the example. This means that 10 commands from the latest command log file are truncated (not loaded) for each retry. Log subfile omission attempt with RELFSW0. The parameter can be used to indicate that the command log subfile should be omitted completely (=2), that the youngest subfile should be omitted (=1) or that there should be no omission at all (=0). The last value is default. This parameter indicates the reload file or files which should be included from the first group (First File Range). Either RELFSW0 or ANY is specified. Determines which files from the Second File Range should be included in reload attempts. Either NONE or a value from 100 to 127 is specified. In the example, 101 is specified, which means that RELFSW100 and 101 are tried.

NTCZ

LOAZ

INCL1

INCL2

98

R1B

System Backup Handling

INCLA

This is a parameter which can age check the reload files. This means that no files older than the parameter are used. Supervision time in minutes between reloads. If the time is exceeded, the reload is regarded as successful. The parameter should be set to 60 minutes (should not be changed unless recommended by an APZ expert).

SUP

Command SYBRP can be used to show the extent of the latest reload, and also to see which reload file was loaded. An example of a printout can be seen below. System backup reloading information:
<SYBRP; SYSTEM RELOADING INFORMATION RELOADTIME 930429 1141 TYPE PS,RS DSSMALL DSLARGE COMANDLOG 000005 END ACTION LOADED LOADED LOADED RP 4 EM 0 DEV 1 RELOADFILE RELFSW0 SUBFILE R5 R1 R3

SOURCE FILE MEDIUM FILE MEDIUM FILE MEDIUM

OUTPUTTIME 930318 0832 930318 0832 930318 0832 OMISSION NONE

TRUNCATION 0

During a function change in the CP the automatic reload function may be turned off by command SYRBI. Command example:
<SYRBI;

In the example above the automatic reload function is turned off. The system will not reload. The alarm BACKUP INFORMATION FAULT is issued. The automatic reload function is turned on by command SYRBE.

5.2.8

System backup check


Each subfile of a CP backup consist of one or more sectors. This sector concept is not to be mixed up with the sector concept of FMS where each media is divided in sectors. When output each sector of the CP backup subfile is check summed and the check sum is written in the sector. This check sum is calculated and written at backup (manual or automatic). In order to verify the accuracy of a particular backup copy there is a function that reads the subfiles, calculates a check sum and compares to the checksum stored on hard disk.

R1B

99

AXE IO System, IOG 20

Command example:
<SYBCI:FILE=RELFSW101;

A backup check is made of the CP backup in file RELFSW101.

5.2.9

Hanging backup
The output of CP backup is supervised by the backup function. If the backup would for some reason hang this is indicated by the system by an alarm BACKUP INFORMATION FAULT. The supervision is active for both manual and automatic CP backups. Command example:
<SYBHP;

The printout above will tell whether the CP backup function is hanging and which block was last doing its backup. The alarm is remedied by following the OPI for the alarm above.

5.3 Command Log


The automatic large CP backup updates the CP backup in file RELFSW0 according to the executing system. If a reload would occur in between the updating of the backup, the exchange data which was loaded since the last large backup will be lost. The command log is used to avoid such losses of exchange data. The command log is also used when the CP is separated, this in order to log the possible differences between the executive and standby side. This is described under section Command Log During Function Change below.

5.3.1

Output of command log data to file


The command log in the exchange logs certain commands and subscriber services ordered from a telephone set (these services are translated into commands). The command description tells us whether a command is logged or not. Changes in the exchange data are automatically stored in the command log file in the form of commands. The command log file is named RELCMDHDF and defined in volume RELVOLUMSW. It is may have up to 9999 999 subfiles. Each subfile consists of command log information between two large data dumps in file RELFSW0. A new subfile is created for every large automatic CP backup that is performed. The subfile belongs uniquely to one particular subfile (-R3 or R4) of one particular CP backup (RELFSWn). The logging follows a sequence, example:

Large CP backup i s made to subfile RELFSW0-R3. A new empty


command log subfile, RELCMDHDF-0100230, is created and

100

R1B

System Backup Handling

attached to -R3.

The exchange data is modified and subscriber services are activated and
deactivated. The commands are stored in subfile -0100230.

A large backup is made to subfile RELFSW0-R4. A new empty command log subfile, RELCMDHDF-0100231, is created and attached to -R4.

The exchange data is modified and subscriber services are activated and
deactivated. The commands are stored in subfile -0100231. By following this sequence the system will create and attach one and only one command log subfile to each and every CP backup subfile -R3 or -R4. The relation can be seen in the printout SYSTEM BACKUP FILES. System backup files
<SYBFP:FILE=RELFSW3; ORDERED SYSTEM BACKUP FILES FILE RELFSW3 SUBFILE R1 R2 R3 R4 R5 END IO TYPE DSSMALL DSSMALL DSLARGE DSLARGE PS,RS EXCHANGE TRX-C:9 APZ 211 11 R1 OUTPUTTIME 970302 1600 970302 1200 970302 0000 970301 0000 950302 1614 CURRENT YES NO YES NO YES COMMANDLOG 0010021 0010020 -

If a reload occurs the backup file RELFSW0, with the later small dump and the older large dump, will be loaded into the system again. In order to restore the system to the situation before the reload both command log subfiles (attached to backup subfiles -R3 and -R4) must be loaded into the system. The reason is that it is always the older large data dump that is loaded.

5.3.2

Command log when separating CP sides


New subfiles of the command log file RELCMDHDF may also be created when the central processor is separated during a functional change. A new subfile is created if the CP is separated and CP-SB side is not fault marked. The command log subfile will record all data changing commands in the CP executive side, i.e. all differences between the executive and standby side. If a switch back to old system (stored in the SB side) would occur the operator has a possibility to updated the old system (now in EX side) with the new data.

R1B

101

AXE IO System, IOG 20

Example: A CNI shall be loaded in a switch. The CNI consist of a new block. The new block is loaded with command FCSUL and furax table is loaded with command FCTAL. The new software is switched in with FCSUC. Data from the old version of the block is converted and stored in the new block. The CP is separated with the old block in the SB side and the new block in the EX side. A new command log subfile is created. After the switch, one hundred subscribers are changing their subscriber services (activating/deactivating). All this is logged in the command log subfile. A software fault occurs in the EX side. The system automatically switches back the old system. EX becomes SB and SB becomes EX. All changes in subscriber services are lost. The operator updates the new EX-side by executing the command log subfile.

5.3.3

Loading of command log to system


The loading of the commands of the command log subfiles into the system may be done:

as a part of the reload or manually


If loading the command log as a part of the reload, this is specified in the command SYGPS, parameters CLH, NTAZ, NTCZ and LOAZ. See previous section in this chapter. If loading the commands in the command log subfiles manually the operator must first of all decide which of the two applicable command log subfiles is the older and newer. This is done by command SYBFP. After this the command log subfiles are read in the sequence older-newer. Command example, manual loading of command log subfile:
<IOCMC:STATE=PASSIVE; <IOCMI:FILE=RELCMDHDF-0100230,PROC=E; <IOCMI:FILE=RELCMDHDF-0100231,PROC=E; <IOCMC:STATE=ACTIVE;

Before giving the command IOCMI, the Command Reading Table for delayed action commands must be passivated by use of command IOCMC: This command will prevent command reading from any other source than the command log. The table should be reactivated after the commands in the command log have been executed.

102

R1B

System Backup Handling

The procedures of the Command Log are described in several OPIs, all named Command Log.......

5.3.4

Operation of command log


Start of command log Command example:
<SYCSI; <SYCLI;

The command example above starts with the creation of a new command log subfile with command SYCSI. After this the command log is activated. Removal of command log subfiles The main file RELCMDHDF may have up to 9 999 999 subfiles. Some of these are relevant for the CP backups and some are not. If a CP backup file, e.g. RELFSW5, is overwritten then the two related command log subfiles are of less relevance. The command log function uses the File Process Utility function to handle its subfiles after they have lost relevance to the CP backups on the hard disks, both the first and second file range. When this happens the command log reports the command log subfiles to the FPU subfile list. From this list the subfiles may be transferred to external media and eventually removed from hard disk. The criteria for reporting a subfile to file processes utility is that the subfile (R3 or R4) shall be overwritten by an automatic large backup, by a manual backup or by a dump transfer with command SYSFT. The mainfile RELCMDHDF must be connected to as FPU destination. Command example:
<INFDI:DEST=CLOGDEST,EQUIP=NOLINK,FILE=RELCMDHDF; <INFCC:FILE=RELCMDHDF,REMOVE=04800;

In the example above the command log subfiles are removed from hard disk 48 hours after they are reported to FPU.

5.4 Backup of the SP


5.4.1 Differences between CP and SP backup
The function of the SP backup is somewhat different from the CP backup. When changing the contents of an executing CP dump, these changes only take place in the primary memory of the CP. This may be the loading of some corrections, the function change of a new block, modification of exchange data or activation of a subscriber service. Once the contents of the CP is changed we make a backup of it towards the CP primary memory or towards hard disk.
R1B 103

AXE IO System, IOG 20

The architecture of the system in the SP is different. When making a change to the SP dump the SP backup on the hard disk is always updated automatically. This may be the function change of an upgraded module or the definition of a new terminal. In the SP there is no function for storing the contents of the primary memory to hard disk, no function comparable to the CP automatic or manual backup. In fact the handling of both software and exchange data in the SP and CP are fundamentally different. Assume that three CP backups of the same system are stored on the hard disk. This means that we have three copies of each and every block and program in CP, RP, EMRP, RPG, RP-D etc. stored on the hard disk. There is also three copies of the exchange data stored on the hard disk: three B-number tables, three charging analyses etc. If the SP has three versions of the same system installed (i.e. three SP backups on the hard disk), then each software unit (module) is still only stored once on the hard disk. Also for the SP exchange data this is only stored once on the hard disk. All installed SP systems (on hard disk) have the same exchange data. A reload in the CP may change the CP exchange data, a reload in the SP does not change the SP exchange data.

5.4.2

SP backup components
The SP backup consists of four components:

SP software (including RPV/RPV2 and LUM software) SP exchange data System description file The SP software is located to a number of number modules. Each module is stored in one individual file on volumes PROG_A and PROG_B. The LUM and RPV/RPV2 software is part of the SP backup as modules in the SP system. are usually stored in volume OMFZLIBORD. Examples of SP exchange data are port definitions, MCS transaction logging conditions, Network terminal numbers etc.

The SP exchange data files contain SP exchange data definitions. These

The system description file contains a description of the system. This


file is never stored on hard disk but is created when doing the backup towards external media.

104

R1B

System Backup Handling

5.5 Chapter Summary



The name of the CP backup file is RELFSWn (n=0 - 127) RELFSWn is a composite file with 6 subfiles Two types of dumps exist, the manual and the automatic. When manual dump DS, PS and RS are dumped Two types of automatic dumps exist, the large and the small dump At large dump, the reload marked variables are dumped while in the small dump the charging data is dumped

The backup files should be in the right chronological order The CP backup can be transferred to/from the IOG via an external
media or via data link

The CP can reload an older generation backup file The file RELCMDHDF is the command log file, where certain commands and subscriber services, ordered from a telephone set, are logged automatically

A new command log subfile is created at every large automatic dump


and when ever the function change commands FCSEI/ FCSUC are given

The command log recommended to be defined in FPU The CP is able to reload even older generation backup files and the
command log subfiles automatically. The operator can decide this by command

The SP software (including RPV/RPV2 and LUM software) from volumes PROG_A and PROG_B can be backed up on a FD or OD

The SP exchange data from OMFZLIBORD volume can be backed up


on FD

R1B

105

AXE IO System, IOG 20

106

R1B

6. MCS applications

Chapter Objectives
After completing this chapter the student will: Recall the main functions MCS Describe the alarm handling function in MCS Define data for routing of printouts to IO devices Understand how user authority data is used Write and execute command log
Figure 6.1

Chapter Objectives

6.1 Introduction
This chapter covers the functions and commands of the man-machine communication subsystem.

6.2 The functions of MCS


The hardware of MCS was described in chapter 2, i.e. the alarm interface to which the alarm panels and external alarm sensors are connected. MCS, however, consists mainly of software. The main functions provided by this software will be looked at below. The MCS software resides both in the CP and in the SP. The complete MCS software is only installed in SPG0. In SPG1, SPG2 and SPG3 only a part of the MCS software is loaded.

R1B

107

AXE IO System, IOG 20

The main functions of MCS are:

Administration of alphanumeric data (commands and printouts) Administration of alarms Printout routing Device attendance Authority system MCS directories Alphanumeric device communication IO device blocks MCS transaction log Command file

Administration of alphanumeric data includes command syntax analysis, location of command receiving block and transfer of command parameters, check of device and/or user authority, selection/seizure/release of device, selection of standby device, assembly of printouts with data from user blocks. Administration of alarms is carried out by the alarm functions in MCS. These contain all the functions for receiving, indicating, transmitting and acknowledging alarms. Printout routing. Specification of standby devices, specification of printout paths. Another printout routing function which is not used, is implemented in the MCS Directories. IO Device attendance. This function is used to indicate whether a certain IO device, or the switch, is staffed. The authority system. In order to increase the security of the operation of an AXE switch an authority system is implemented. The authority system handles users and terminals and may assign different authorities based on this. A parallel authority system which is used only in special cases is implemented in the MCS Directories. MCS directories The MCS directories are implemented in the SP only. They form an authority and printout routing system. The function is only partly used. The directories are used when defining terminals and when defining users for the Local Mode operation with command MCLOC. Alphanumeric device communication looks after the communication between the IO device blocks in CP and the device driver programs in DCS in the SP. The communication between CP-SP is handled by SPS in the lower four levels of the OSI communication model. MCS provides levels five to seven in OSI for command/printout sessions.
108 R1B

MCS applications

Device blocks are functions that are specific for each type of device and are not handled by the device drivers in the SP. Reception of user identity/ password, queuing of printouts to busy devices and alphanumeric output to file are examples of these functions. Four device blocks exist: AT (Alphanumeric Terminal), AF (Alphanumeric File), TW (Type Writer) and AMTP (Alphanumeric transfer using Message Transfer Protocol). The name of the device block plus a device individual is used as the IO parameter and is thus the name of the specific device. MCS transaction log. The MCS transaction log is used to log transactions on the alphanumeric terminals. Commands, printouts and logon IDs are logged. The MCS transaction log logs transactions on TW/AT and AMTP devices, but not on AF devices and not on the CPU port of the IOG20. Command file. Commands are usually executed manually from an alphanumeric terminal. Commands may however also be executed from a prepared command file on hard disk or external media. The command file may be executed manually or automatically according to a time schedule.

6.3 Alarm Handling


6.3.1
AXE

Introduction

Error

Error remedied M anual intervention Alarm issue Alarm cease

Error

Alarm issue

External alarm issue

MCS Alarm list ..... .... .......

Figure 6.2

Alarm handling in AXE

Each situation in AXE which gives rise to an operational disturbance of significance or which requires manual intervention generates an alarm. An

R1B

109

AXE IO System, IOG 20

alarm may also be an observation alarm, i.e. an alarm that is not issued to indicate a fault but to indicate that a manual intervention has taken place. All subsystems in AXE generates alarms. Alarms may also originate outside the AXE system. These alarms are then related to power, cooling, fans or attached to doors and windows of the building. These are called external alarms. The functions for receiving, storing, transmitting, and acknowledging alarms are located in MCS. MCS provides an interface to the operation staff for alarm information. MCS provides interfaces in both the CP and SP for internally generated alarms. An AXE alarm is issued when the fault or error happens, and ceases when the fault disappears or is remedied. Some alarms must be manually ceased by command.

6.3.2

AXE alarm concepts


Below some important concepts of the AXE alarm system are listed below. Alarm list. All alarms, internal or external, are reported to an alarm list when they are issued. The alarms are removed from the list when they cease. The alarm list is printed by command ALLIP. The fact that the alarm is removed from the alarm list when the alarm ceases makes the alarm list a record of the present alarm status of the switch. There is no alarm recording functionality of the alarm list. For each alarm the alarm list stores:

alarm printouts, which are text printouts indicating what is wrong alarm classes and categories exchange identity alarm numbers date and time FORLOPP identities

Alarm numbers are unique identifiers for alarms.

110

R1B

MCS applications

A la rm c la s s

A la r m n u m b e r A la rm c a te g o ry s lo g a n E xchange header D a te T im e A la r m F id

A 2 /A P Z "H M B R G L O C 1 2 .4 /0 0 /0 1 " 0 1 3 9 7 0 4 2 5 EM G FAULT EMG U N IT STATE RSS0 S T R -B C BLO C K

1258

H 0 2 6 2 -0 0 0 1

A la rm te x t

Figure 6.3

Example of an alarm in the alarm list

The alarm list may be printed out automatically at regular intervals. The alarm list has a printout category of 36 and the printout is routed according to this. The intervals are defined by command ALLTC. Command example:
<ALLTC:TIME=0800,TIME2=1700;

In the example above the alarm list is defined to be printed at eight and five oclock every day. The times are printed with command ALLTP. The alarm list has a finite size which is defined by a size alteration in the system. If the alarm list is full when an alarm is reported an alarm list overflow counter is stepped. The overflow counter is printed at the top of the alarm list. Alarm category. An alarm category indicates from which part of the AXE system the alarm comes from. An alarm always has an alarm category. There are 16 alarm categories in the AXE system. Each alarm category is assigned a number, 0-15, see below. This is referred to as the alarm category number (ALCATNO). The alarm categories and their ALCATNOs are as follows: 0 1 2 3-15 Data processing system Processors IO Device System dependent data, determined by the system projecting instance in question.

Normally, however, alarm categories 3-15 have the following meanings:

R1B

111

AXE IO System, IOG 20

3 4 5 6 7 8 9 10 11 12-15

Switch Switching part Switching device Subscriber lines Spare Power alarm House alarm Alarm from subordinate exchange Cable alarm Spare

Further, the alarm category slogan (ALCAT), is also associated with each alarm. It is the alarm category slogan which appears in the alarm printout under the heading Alarm Category. The slogans are APZ, APT, POWER, and EXT. Example of alarm and display categories:
<ALACP; ALARM ALCATNO 0 1 2 3 4 5 6 7 8 9 ... 14 15 END CATEGORY ALCAT APZ APZ APZ APT APT APT APT APT POWER EXT EXT EXT DATA DICAT 0&4 0&4 0&4 1&4 1&4 1&4 1&4 1&4 2&4 3&4 3&4 3&4

To each alarm category one or more display categories can be connected. A display category (DICAT) corresponds to a physical position (lamp) on an alarm panel. DICATs 0-3 corresponds to the primary alarm panel, and DICATs 4-15 corresponds to one position on each of up to 12 secondary alarm panels.The relation between alarm category number, alarm category slogan and display category is defined and printed by commands ALACC and ALACP. As DICAT 0 always corresponds to APZ ALCATNOs 0-2 must be connected to DICAT 0 etc. See Figure 6.4.

112

R1B

MCS applications

Alarm categories First alarm panel


APZ APT POW EXT A1 A2 O1 O2 ATT OBS A1 A2 ATT

2:nd alarm panel


AXE

3:rd...
AXE A1 A2 ATT

...13:th
AXE A1 A2 ATT

4 Display categories

5...

... 15

Figure 6.4

Display categories

Alarm class. The alarm class of an alarm indicates the seriousness of the fault. There are five alarm classes in AXE: A1, A2, A3, O1 and O2. Alarm class A1 is the most serious, the recommendation is that alarms of this class must be acted upon immediately. Alarm class A2 must be acted upon immediately during office hours and alarm class 3 must be acted upon during office hours. Observation alarms are used to indicate that a manual intervention is done. Examples of manual interventions that generates observation alarms is the manual blocking of a regional processor or the manual blocking of a TSM. To each alarm class an alarm class number is defined. The alarm class numbers are 0-4. For each alarm class it is defined whether:

the bell on the alarm display shall ring at alarm issue the bell on the IO device shall ring at alarm issue the alarm shall be automatically printed on the alarm printer at issue
Now days the IO device is usually a PC and the ringing of a bell on the IO device is irrelevant, this was used with printers with bells. The alarm class definitions are controlled by commands ALCLC and printed by command ALCLP. Example of alarm class definitions:
<ALCLP; ALARM ACLNO 0 CLASS ACL A1 DATA ALDB YES TWB NO PRINTOUT YES

R1B

113

AXE IO System, IOG 20

1 2 3 4 END

A2 A3 O1 O2

YES NO NO NO

NO NO NO NO

YES YES YES YES

6.3.3

Connection of alarm interface


The alarm interface is the hardware and software that interfaces the alarm panels and external alarm connectors to the IO system. Hardware-wise the ALI is implemented in a physical port on a LUM board and in the ALCPU and ALEXP boards in the SPVM subrack.

ALCPU
E xternal alarm sensor to E X R A N G 20. D evices E X A L 2 0 - 31

ALEXP
A larm panel, display categories 0-3. U S version categories 0-2. A larm panel, display categories 4-7. U S version categories 3-5. A larm panel, display categories 8-11. U S version categories 6-8. A larm panel, display categories 12-15. U S version categories 9-11.

SC A N interface categories 0-15. U S version categories 011. V .24 port to L U M port, 2400 baud V .24 port to fan, 2400 baud B us in backplane

P ow er -48 V

Figure 6.5

Alarm interface, ALI

A maximum of two alarm interfaces may be defined in one exchange, one per node in SPG0. The alarm interface is installed using the OPI Handling of ALI. The ALI is defined with its functions as an AT device using the OPI Connection of ALI. Command example:
<ALALI:ALI=0,IO=AT-1,EXAL=0,ALDI; <ALBLE:ALI=0;

In the example above an alarm interface, ALI-0, is connected in the Anode of SPG0. It is defined as AT-1, one or more alarm panels are to be

114

R1B

MCS applications

connected and it connects to external alarm receivers 0-31, i.e. devices EXAL2-0&&-31. Finally the alarm interface is deblocked. Command example:
<ALALI:ALI=1,IO=AT-5,EXAL=1; <ALBLE:ALI=1;

In the example above a second alarm interface, ALI-1, is connected in the B-node of SPG0. It is defined as AT-5, no alarm panel is connected and it connects to external alarm receivers 32-63. The alarm interface definitions are printed with command ALALP. External alarms. External alarms are used to connect things like power, cooling, fans or burglar alarms to the AXE alarm system. The external alarms are connected via external alarm connectors. These are connector fields which may be located in two places: either centrally in the SPG or remotely in the EMRP stage. The connector fields consists of a number of pin-pairs. To issue an alarm requires that the pins in a pair are either connected or separated, depending on how the external alarm connector is defined. The external alarm connector in the EMRP stage is implemented in the EXALI board. The external alarm sensors are defined as EXAL0 devices.

Central switch IOG20

EXAL2devices, EXRANG20 alarm sensor

Remote stages (subscriber stage or base stations) EXAL0devices, EXALI board

Alarm on cooling system

Alarm on power system Burglar alarm on door and window Alarm on cooling system

EXAL0devices

Alarm on cooling system Alarm on power system

Figure 6.6

External alarm sensors in AXE

R1B

115

AXE IO System, IOG 20

The external alarm sensors centrally in the SPG are implemented in the EXRANG20 connector. The external alarm sensors are defined as EXAL2 devices.

Iirvursvtrhr  ! # % '  ! # " $ " $ # # $ $ " $ & " $ & (   % % & ! ! " " @Y 6G!qrvprir

&

& ( ! !" !$ !& !( "

& (

'

'

( @hpuqrvprpvs prpv

' ! !! !# !%

! !" !$ !& !(

!!

!!

!"

!"

!%

!%

!&

!&

!' "

"

"

"

" 8hiyr6G8QV ihq

"

Figure 6.7

EXAL2 devices in EXRANG20 alarm sensor

The external alarms are handled by commands ALRDL, ALEXL, ALEXI, ALEXP, ALEXR and ALALI. Command example:
< ALRDL:DEV=EXAL0-5,CAW1=POWER ALARM, CAW2=POWER UNIT 3,AC=0,RTIME=5; < ALEXI:DEV=EXAL0-5; < ALEXL:DEV=EXAL0-5,PRCA=63,ACL=A3,ALCAT=8; < BLEAE:DEV=EXAL0-5;

In the command example above an external alarm sensor located remotely is defined. The sensor is activated by contact between the two pins in the alarm sensor. The alarm printout will be repeated every five minutes if the alarm condition stays (contact between pins). Command example:
<ALRDL:DEV=EXAL2-31,AC=1,MR,CAW1=FIRE ALARM; <ALEXI:DEV=EXAL2-31; <ALEXL:DEV=EXAL2-31,ACL=A1,ALCAT=15; <BLEAE:DEV=EXAL2-31;

In the command example above an external alarm sensor located centrally is defined. The sensor is activated by interrupting the connection between

116

R1B

MCS applications

the two pins of the alarm sensor. The external alarm must be manually reset by command ALEXR. External alarms are defined using the OPI External Alarm Connect. Scan interface. A separate physical interface is also provided for connection of external scanning equipment - the Scanning Interface provided by the SCAN connector on board ALCPU in the ALI. Similar information as is given in the alarm status printout see below, can be scanned at this interface, but only four alarm classes are given for each alarm category. Attendance is also given here as well as Exchange Alarm information. Exchange Alarm is issued only via the Scanning Interface in the ALI. It occurs directly at power failure to the CP or after eight minutes of no contact between the ALI and the CP. Command example:
<ALALI:ALI=0,IO=AT-1,EXAL=0,SCAN,ALDI; <ALBLE:ALI=0;

In the example above an alarm interface, ALI-0, with SCAN interface is connected in the A-node of SPG0. It is defined as AT-1, one or more alarm panels is to be connected and it connects to external alarm receivers 0-31, i.e. devices EXAL2-0&&-31. Finally the alarm interface is deblocked. The scan category and alarm category number relation is defined by command ALSCC and printed by command ALSCP. Heart beat. A heart beat signalling may be activated from the AXE to a remote O&M centre (AOM). The purpose is of course that if the AXE malfunctions the O&M centre will be informed by the fact that the heart beat signalling stops. The heart beat itself is the printout HB which is routed according to its printout category 35 to an AMTP device, i.e. an alphanumeric terminal over data link. Since the heartbeat printout will lock the terminal it is important that it is dedicated for the reception of heart beat signals. The heart beat signal is sent every 60 seconds. Commands for operating the function are: ALHBI and ALHBE. Alarm status is a printout with printout category 47. If the function is activated it is sent continuously to an OMC over data link. The printout routing is defined to send the information both when the exchange is attended and unattended, see example below.
ALARM ALARM ALARM ATTENDANCE END STATUS CATEGORY CLASS STATUS "HMBRG LOC 12.4/00/01" 0 1 2 3 4 5 6 7 .... O1 A2 A2 - - A2 - - .... N N N N N N N N .... 12 13 14 15 - - - N N N N

The printout is a list of all ongoing alarms in the exchange. Only alarm category numbers (0-15) and alarm classes (A1, A2, A3, O1 or O2) for each category are given for the alarms. The printout also contains attendR1B 117

AXE IO System, IOG 20

ance information for each alarm category - in principle, attendance for the exchange. A new printout is sent each time the status changes. Thus when command IODAC is given at the exchange the alarm status changes and the printout is sent to the OMC. It is through this information that the OMC staff know that an exchange is attended or unattended. The sending of the alarm status printout must be activated by command ALSTI. The alarm status can be printed manually by command ALSTP.

6.3.4

Alarm system implementation


The alarm function is handled by the blocks ALA, ALSA, AL, ALIM, EXAL0, EXAL2, ALCO, in the CP and module ALARMADM in the SP. ALA is the central block in the MCS alarm handling function. It receives alarm information signals from the supervision blocks (user blocks) in the different subsystems. It also receives alarm information from the block ALSA concerning external alarms. The signals from these alarm generating blocks includes alarm class, alarm category and detailed information about the error or fault.

A LA A larm s from user blocks in C P

A LS A

A LC O

E X A L2

E XA L0

CP SP
A LA R M A D M A LC PU E XA LI

A larm s from user blocks in SP G

E X R A N G 20

E xternal alarm s connected centrally in SP G

E xternal alarm s connected rem otely in EM G

Figure 6.8

Alarm system implementation

When ALA receives such a signal it seizes the alarm printer and writes the label for the alarm printout. It then links the alarm printer to the supervision block and this in turn sends the rest of the alarm printout to the printer. ALA then writes END in the printout and releases the terminal.

118

R1B

MCS applications

ALA informs block AL of the changed alarm status so that AL can make the necessary changes on the alarm panel(s). Block ALSA handles alarm printouts for external and observation alarms, and the functions for connection, disconnection blocking, deblocking of external alarm receivers. The receivers are contained in the ALI and correspond to the external alarm sensors. The block contains a table of the connected external alarm sensors, and a table for alarm status, alarm resetting conditions, alarm class, alarm category and printout strings for these. All the above information is set by commands (see below). When an external alarm is to be issued or ceased ALSA acts as a normal user to the block ALA, as described above. Blocks EXAL0 and EXAL2 both work as interfaces between the external alarm sensors and the block ALSA. EXAL2 is the interface used when using SP based IO systems. It uses the same hardware, ALI, as block AL. Block EXAL0 is not part of SP based IO systems - it is used for alarm sensors connected at EMRP, board EXALI. The main functions of both these blocks are the translation of signals from ALSA concerning changes of data for external alarm receivers and updating of the hardware. In the opposite direction, when an external alarm sensor indicates a fault, the functions filter out non-persisting fault indications and send a signal containing alarm information to ALSA if the fault persists. Block AL controls the alarm panels and scanning interface (SCAN). It receives changes in alarm status from block ALA. The lamp on the alarm panel is not extinguished until no alarms of that class and category remain. The block also contains the function for control of the attendance indicators and alarm panels depending on attendance. Block ALIM provides maintenance functions for the ALI. The block consists of software in the CP and the hardware of the ALI. The ALI controls the alarm panels and scanning interface by receiving signals from block AL. If the CP stops for some reason, no alarms can be issued in the exchange or sent to the OMC. In this case, the ALI will alone generate alarm information (the Exchange Alarm) to the alarm panel and over the Scanning Interface to the OMC. The Exchange Alarm is the final channel provided by the Scanning Interface. The ALI can also contain receivers for the information detected by the external alarm sensors.The information received is sent to block EXAL2. ALIM has the following functions:

storing the equipment alternatives of each ALI supervising the ALIs and issuing alarms on ALI fault detection isolating and testing of ALI functions.
R1B 119

AXE IO System, IOG 20

ALCO is the final alarm handling block in the CP. ALCO receives alarm information from the module ALARMADM in the SP. ALCO thus handles alarm information concerning faults in the SPG. Block ALCO stores the information for all SPG alarms in a list and initiates and ceases alarms in the same way as any other alarm user, as described above. It thus works with block ALA in a similar way to ALSA when this block administrates external alarms. Module ALARMADM is the interface in the SP to all alarm generating blocks in the SPG. Faults occurring in the SPG are detected and analysed by maintenance functions in the SPG itself and alarm information is sent to ALARMADM. The information is transferred to the ALCO block in the CP as described above.

6.4 Routing of Printouts


6.4.1 General
The assembly of printouts from the user blocks is one of the group of alphanumerical administration (ANA) functions. This function is handled by block AOT. It should be born in mind when reading the following text that by IO device is also meant:

alphanumeric file device, i.e. AF device data link (with corresponding IO device), i.e. AMTP device.
6.4.2 How Printouts are routed
Each automatically initiated printout is assigned to one of a number of Printout Categories, PRCA, at the software design stage. 128 printout categories are defined in the system, but normally a maximum of 64 are used. These printout categories are used to direct spontaneous printouts - such as alarm printouts - and other types of automatically initiated printouts - such as the alarm list, etc. - to certain IO devices. Answer printouts and result printouts (after ORDERED) are normally routed automatically back to the terminal from which the initiating command was given. For these types of printouts no printout category is assigned. Certain printouts, however, e.g. statistics, can be routed without using printout categories. A number of commands include an IO or IO2 parameter which allows diversion of answer printouts or result printouts to another IO device. In this case, by IO device is meant AT or AF devices. Answer printouts diverted in this way become result printouts on the new device.

120

R1B

MCS applications

Certain printouts can be routed using either printout category or the IO parameter in the initiating command. Printout of call meter values is an example of such an output.

6.4.3

Definition of Printout Routings using PRCA


By use of the command IOROL, the different printout categories are linked to one or more IO devices. Up to 32 printout categories can be given in the same command and these can be linked to up to 12 IO devices. The printouts belonging to the PRCAs can be output simultaneously on a maximum of eight devices. These devices are then said to be arranged in a device chain. Each PRCA or group of PRCAs can be connected to a device group consisting of up to maximum four device chains. Thus the PRCAs can be linked to up to twelve IO devices, but only a maximum of eight devices are allowed to receive the printouts simultaneously. This is done by defining the conditions accordingly. The device chains are defined by command. All chains belonging to the same printout category or printout category group thus form the device group.

<IOROL:PRCA=0&&31,IO=AT-0,DTYPE=FIRST; <IOROL:PRCA=0&&31,IO=AT-4,DTYPE=NEXT; <IOROL:PRCA=0&&31,IO=AT-2,DTYPE=NEXT;

AT-0

AT -4

A T-2

IO d evice 1 D TY P E= FIR S T

IO d evice 2 D TY P E= N EX T

IO device 3 D T Y P E= N EX T

Figure 6.9

Device chain

The parameter DTYPE in the command IOROL is used to define the position of each device in the device chain. The command must be given once for each device. For the first device, DTYPE has the value FIRST, for the second and third devices, DTYPE has the value NEXT.

R1B

121

AXE IO System, IOG 20

The sequential order in which the devices are specified will determine whether the device is the 2nd or 3rd device in a chain.

DTYPE=STB AT-10 AT-0

DTYPE=STB HD AFFILE-2 AT-4 AT-2

IO device 1

IO device 2

IO device 3

Figure 6.10

Device chain with standby devices

For each device a standby device can be defined. DTYPE has the value STB for a standby device. Thus, in a chain of maximum size, the command IOROL must be given six times: once for each device and once for each standby device. The PRCA parameter is only given the first time i.e when DTYPE=FIRST is specified. The parameter COND in IOROL is used to define which of the devices in the chain or chains is to receive the printout linked to the printout categories. For each DTYPE, the device is assigned a value for the parameter COND, as follows: 0 means that printouts will also be routed to the next device in the chain.

1 means that the printout will only be routed to the next device in the chain if the device (with COND=1) is unattended (attendance: see below.) 2 means that printouts are never sent to the next device in the chain. It should be noted that the when defining the third device in the chain, the parameter COND can be omitted as this is the last device. When defining a standby device - DTYPE=STB - then the parameter COND may not be given.

122

R1B

MCS applications

Thus whereas parameter DTYPE is used to define the chain, COND is used to define which device(s) in the chain receive the printout. Two further parameters of command IOROL are required to complete the printout routing definition: CLASSA and CLASSUA. These parameters are assigned to each device to determine which printouts belonging to the printout category(ies) shall be output. This is done by using the printout class, PCL, concept. As well as belonging to a printout category, automatically initiated printouts are assigned a printout class. Some printouts have several printout classes, see example below. PCL-0 for spontaneous printouts that are not alarms:
ALARM CLASS, ACLPRINTOUT CLASS, PCL A1 1 A2 2 A3 3 O1 4 O2 5

PCL can have the values 0-5 and these are defined as follows:

PCL-0 is for automatically initiated printouts that are not alarms PCL-1 to PCL-5 are for alarm printouts, PCL-1 being the highest priority (A1 alarms) and PCL-5 being the lowest (O2 alarms). An example of printout classes for alarm printouts is shown in Figure 6.4. When defining the devices in the chain, each device is assigned those PCLs for which a printout shall be output on the device. This is done by means of the parameters CLASSA or CLASSUA. CLASSA refers to Attended devices and CLASSUA refers to Unattended devices. Thus when a printout is routed to a device, a check is made to see if the PCL for the printout agrees with the CLASSA or CLASSUA value for the device. It should be noted that if CLASSA or CLASSUA is not specified, then all printout classes will be output. CLASSA=6 or CLASSUA=6 can also be specified. This means that no printouts will be output. The parameter NOSYST can be given to indicate that no system defined standby device exists for that device. If the parameter is not specified, the default value is that, in addition to any specified standby device, the device also has a system standby. All the above parameters belong to the command IOROL. Once the data for a given PRCA or PRCAs has been defined for each device using IOROL then the data must be entered into the device tables by the command IOROI.

R1B

123

AXE IO System, IOG 20

A new printout category cannot be routed by IOROL until the previously defined data has been inserted into the tables by IOROI.

6.4.4

Example of Printout Routing Definition


Command example:
< IOROL:PRCA=10,IO=AT-7,DTYPE=FIRST,CLASSA=0&&5, CLASSUA=0&&5,COND=0; < IOROL:IO=AT-5,DTYPE=STB,CLASSA=0&&5, CLASSUA=0&&5; < IOROL:IO=AT-9,DTYPE=NEXT,CLASSA=0&&2, CLASSUA=0&&2,COND=1; < IOROL:IO=AT-15,DTYPE=NEXT,CLASSA=1,CLASSUA=6; < IOROL:IO=AF-3,DTYPE=STB;

In the above example, a chain is defined for three IO devices: AT-7, AT-9 and AT-15. AT-7 is the alarm printer in the exchange, AT-9 is an alarm printer in the day OMC and AT-15 is an alarm printer in the night OMC. (Both AT-9 and AT-15 are accessed here via data links connected to X.28 ports for alphanumeric terminals, thus IO=AT-n and the remote AT belongs to the exchange. If using links connected to X.25 ports then IO=AMTP-n (data link using MTP) and the IO terminal is any suitable output device belonging to the OMC. Two standby devices are defined: AT-5 for device AT-7 and AF-3 for AT-15. As NOSYST is not defined, then the three devices in the chain have a system standby as a final backup. Printouts belonging to printout category 10 are always routed to AT-7 and AT-9 and are routed to AT-15 if AT-9 is unattended. On AT-7 (and standby AT-5) printouts of all printout classes are printed including all alarm printouts even if the device is unattended. On AT-9, only printouts of classes 0-2 are printed, thus including nonalarm printouts and alarm printouts of class A1 and A2 only. The printouts are output even if the device is unattended. On AT-15, only printouts of class 1 are printed, i.e. only A1 alarm printouts. The printouts are output only if the device is attended. It should be noted that the standby device to AT-15 is AF-3, an alphanumeric file device. The printouts routed here are stored in a predefined file on hard disk. The concepts attended/unattended have no meaning here: all printouts will be stored. This type of device will be looked at in the next section.

124

R1B

MCS applications

When working with the definition of printout routing data, quite complex solutions are sometimes required - especially when routing of alarms to different Operational and Maintenance Centres is required. The automatic printout of alarm status - indicating changes in ongoing alarms - and heartbeat supervision signals from the CP are also routed to the OMC. It is important to follow the relevant OPI when defining printout routings. The definition of printout routings is covered in the OPI Printouts, Spontaneous, Route. The function is handled by the block SEC2.

6.5 Standby Devices


All terminals may break down or go in operational for some reason. The background to having standby devices is simply that a backup is needed if the ordinary terminal goes out of operation. Standby devices for alphanumeric devices can be defined in several different ways:

by use of the command IOROL by use of the command IOSBC by use of the command IOSYC
The command IOROL has been covered above in the section Routing of Printouts. One standby device can be defined per device to which a printout is routed (DTYPE=STB). It should be noted that a device defined as standby device by IOROL is only standby for those printouts belonging to these particular printout categories and will not act as standby for any printout categories. Also, spontaneous printouts with printout categories will be diverted to the system standby if no suitable standby has been defined by IOROL, or if the standby cannot receive the printouts due its being unattended. The command IOSBC allows up to three standby devices to be defined for a given device. Function parameter is defined as ALPHA. A standby device defined by IOSBC will act as standby for result printouts only. By result printouts are meant printouts obtained after receiving ORDERED or answer printouts that have been diverted to another device by means of an IO parameter in the initiating command. Printouts routed on the basis of printout category will not be handled by this type of standby device. It should be noted, however, that a standby device defined by IOSBC may not be allowed to receive all printouts diverted to it. The user programs issuing the printout may contain parameters governing this.

R1B

125

AXE IO System, IOG 20

The standby devices defined by command IOSBC can be checked by command IOIOP. The OPI IO Device Standby List, Change should be used when defining standby devices for alpha terminals. The command IOSYC is used for the definition of the System Standby device. The system standby can be any normally defined AT, AF or AMTP device. Once defined, the system standby cannot be removed, but the actual IO device can be changed by use of command IOSYC. The system standby can be suppressed for spontaneous printouts routed on printout category - as has been shown earlier - by use of the parameter NOSYST in the command IOROL. The system standby device can be printed out by use of the command IOSYP.

6.5.1

Detachable IO devices
A detachable IO device is a temporary device attached to a permanently connected line. A strapping plug in the device connector replaces the IO device when this is detached. These devices are defined with the parameter DET in the command IOIOI. A detachable IO device cannot be defined as a standby device by any of the above commands.

6.6 Device Attendance Status


An alphanumeric IO device can have status attended or unattended. The status is an implication of whether or not the device is monitored by operation and maintenance staff. Attendance is set by command IODAC and the intention is that when the operator starts working in the switch he/she starts by defining the terminal as attended. Likewise the terminal is defined as unattended when the operator leaves. A device that has been inserted in a printout routing path (commands IOROL, IOROI) does not automatically receive the printouts belonging to the relevant printout category. It is the attendance status of the device that decides if the printout shall be sent to the device or not. The definition of the printout routing indicates which printouts are to be printed if the device is attended or if the device is unattended. The values of command parameter CLASSA say which printout classes may be printed if the device is attended and the values of CLASSUA determine the same for unattended devices. Control rooms - i.e. the exchange - also have attendance status. If a control room has status attended then all relevant alarms will be sent to the alarm panel in the control room.

126

R1B

MCS applications

If unattended then the alarm panel will not receive any alarms - it will be, in effect, switched off. Alarms status printout and heart beat information is constantly sent via a data link to the OMC using printout categories 47 and 35 even if the exchange is unattended. The alarm status printout also contains attendance information. Thus visual information on alarm status at all supervised exchanges is always available at the OMC independent of control room attendance status at the different exchanges. Attendance for a device is defined by the command
<IODAC:ATT;

Unattendance is defined by the command


<IODAC;

The command must be given from the device that is to be attended/unattended. To simplify matters, devices can have so called common attendance. This is defined for the devices when they are defined, by the command:
<IOIOI:IO=AT-4,COMMATT;

When changing the attendance status of a common attendance IO device by use of command IODAC, all other common attendance IO devices will also change status. The attendance status is also indicated by the ATT lamp on the alarm panel. When changing attendance status the OPI Change of Attendance Status for Control Room and IO Device should be used.

6.7 Alphanumeric Information on File


6.7.1 General
Printouts can be routed to a number of alphanumeric devices, either locally in the exchange or over a data link to an operation and maintenance centre, OMC. However, some printouts are so long that they are often unsuitable for output on an alpha device. Such printouts - e.g. statistics, CP error interrupts, the printouts received in connection with the execution of command files, etc. - sometimes occupy IO devices unnecessarily. Other types of printouts must be stored at the exchange and may even be required at another location, e.g. an OMC, either directly or at some later time. For all these types of printouts it is convenient to output the information directly to a file on hard disk.

R1B

127

AXE IO System, IOG 20

Command example: <IOIOI:IO=AF-3; <IOAFC:FILE=AFFILE-3,IO=AF-3; AT AXE

Printout .... ... ... .

HD

File=AFFILE-3

Figure 6.11

Alphanumeric file

This file, containing alphanumeric information, is called an alphanumeric file. The file has to be defined and a corresponding alphanumeric file device has to be defined in the MCS block AF in the CP, to allow printouts to be routed or directed by command to the file. The advantages of using an alphanumeric file to store printouts are: It avoids occupying IO devices with long printouts. The file is easy to use. It can be copied with INFIT or INFET, read with IOFAT, and sent over a data link from hard disk using File Process Utility, FPU. It speeds up the execution of a command file.

6.7.2

Definition of Alphanumeric File Device


The alphanumeric file must first be defined. Normally the file name AFFILE is used but any name can be specified. The file must be a sequential file on hard disk, and may be simple or composite. The record length should be at least 160 bytes (exchange dependent, the same length as the printout buffer in AF), but could be made longer, e.g. 512 bytes. When the file has been defined the next step is to define the alphanumeric file device. The device type is AF. The device is defined with command IOIOI.

128

R1B

MCS applications

On definition of an AF device, a subfile of file AFFILE corresponding to the device number is automatically created. Thus on defining device AF-3, subfile AFFILE-3 is created on the hard disk. Automatically initiated printouts, e.g. alarms, can now be routed to the AF device and will be stored in the subfile. By command directed printouts is meant result printouts received in answer to a printout command or the printout obtained at the execution of a command file. These printouts are directed to another device when giving the initial command, e.g.:
<EXEMP:RP=ALL,EM=ALL,IO=AF-12;

The example above diverts the printout to AF-12, i.e. to subfile AFFILE-12. As mentioned at the beginning of this section, the parent file for the subfiles does not have to be called AFFILE. Even the subfile identifiers do not have to be the same as the AF device numbers i.e. the default values. The file can be defined as having another name (but the same record length) and the subfile names can be changed from the default values. Both of these definitions are performed by the command IOAFC, e.g.:
<IOAFC:IO=AF-8,FILE=AFFILE-PHILIP;

to change the default value of the subfile from AFFILE-8 to AFFILE-PHILIP, or:
<IOAFC:IO=AF-14,FILE=PRINTFILE-ROBIN;

to define the subfile PRINTFILE-ROBIN to receive outputs diverted to device AF-14. The file PRINTFILE must previously have been defined. Thus both AFFILE and/or any other suitable file defined by command IOAFC can be used. It is recommended that for occasional printouts the subfiles should be of the form AFFILE-own-signature. The command IOAFP is used to print the existing links between AF devices and alphanumeric files. When working with AF devices and files the OPI Printout of Alphanumeric Information to File should be used.

R1B

129

AXE IO System, IOG 20

6.8 MCS directories


MCS directories form an authority and printout routing system. The function is only used partly. The directories are used when defining terminals and when defining users for the Local Mode operation with command MCLOC. The MCS directories are three:

user communication list


The MCS user directory comprises a list of the users in a system. This is a function that mirrors the user definition in the CP (see above) and therefore is not used. There are however some users that have to be defined:

All terminals connected to the system are defined as users when using the local mode with command MCLOC a user defined in
the MCS user directory must be specified Command example:
< IMLCT:SPG=0; :MCDCI:DIR=USER,NAME=SHIRLEY,AUTH=A&B&C&D&E; :MCDCI:DIR=USER,NAME=NAUKO,AUTH=F&G,PASSW=IOG3; :MCDBE:DIR=USER,NAME=SHIRLEY; :MCDBE:DIR=USER,NAME=NAUKO; :END;

In the command example above a user SHIRLEY is defined, the user is given the authority to issue commands of SP authorities from A to E. Shirley does not use a password. The second user NAUKO has the command authority G and F and has a password defined. The authority for the user defines the authority to issue certain commands. All SP commands have a command category from A to G. This is similar to the CP command categories. The above defined users NAUKO and SHIRLEY may be used with command MCLOC. The MCS communication directory comprises a list of the input/outputs to the system. All ports in DCS used for alphanumeric terminals are defined here.
< IMLCT:SPG=0; : MCDCI:DIR=COM,NAME=T1012101,NTN=1012101, AUTO=YES,SUPRV=NO,QUEUE=YES; : MCDBE:DIR=COM,NAME=T1012101; : END;

130

R1B

MCS applications

In the command example above a network port, identified by the network terminal number, NTN, is defined in the communication directory. The port has automatic logon which means that no user identity of password is required when issuing commands. All network ports are always defined as having automatic logon, if a user identification procedure is required this is handled by the CP authority system. A more detailed example of the definition of a network port for terminal communication is given below. The MCS list directory is a printout routing function which is never used. The CP implemented routing of printouts with command IOROL is always used. Local mode user authority verification must take place in the SP because, when accessing the system in local mode, only the SP is accessed, thus the authority check must be made there. When defining a port, authority data for the port must be inserted into the Communication Directory. The data includes user NAME, an AUTO logon parameter, the network terminal number (parameter NTN) of the port and supervision (parameter SUPRV) and queuing data (parameter QUEUE). Data for the port must also be inserted into the User Directory. The data includes user NAME and permissible command Authority (parameter AUTH). In the Communication Directory, any name can be used for the port and is normally defined as TNTN, i.e. T followed by the NTN of the port. Auto logon is entered as YES, and the NTN of the port is given. In the User Directory, the port name (e.g. TNTN) is again defined as the user name, and command authority is normally set to E (i.e. only those subcommands having Authority E - see command descriptions - are allowed from the terminal connected to the port). As AUTO logon is defined as YES any port user bypasses the authority control associated with the SP and verification takes place in the CP. An addition to the above port data must be made for users who are allowed to access the SP in local mode. To access local mode on any terminal a user is required to give a Username (USR) and Password (PSW) in the access command. Before this can be done, a name and password for each local mode user must be inserted in the User Directory. Initially, default values for USR and PSW exist in the User Directory, but these can be removed after all local mode users have been assigned individual names and passwords. To access local mode the command MCLOC is used and can be given from any terminal:
< MCLOC:USR=NAUKO,PSW=IOG3;

R1B

131

AXE IO System, IOG 20

6.8.1

Definition of Terminal Data


An example of SP authority verification used in connection with port definition is given below: Port definition: port 1-2-2-1 => NTN=1012201 Communication Directory:
: MCDCI:DIR=COM,NAME=T1012201,NTN=1012201, AUTO=YES,SUPRV=NO,QUEUE=YES;

User Directory:
: MCDCI:DIR=USER,NAME=T1012201,AUTH=E;

Any user can now access the CP from the terminal connected to this port. User authority verification, if any, will be carried out by the CP.

6.8.2

Definition of User Data


To further allow an individual user to access the SP in local mode via any such defined port, an entry of the users name and password must now be made in User Directory, e.g.:
: MCDCI:DIR=USER,NAME=URSULA, PASSWORD=USCHI,AUTH=EFH;

In this case, a user using the above name and password can now use MCLOC to access the SP in local mode from any terminal. Having made local mode access, commands having authorities E, F and H in the SP can now be given. It should be noted that the above entry is not required if the default user and password are left in the User Directory for all local mode users to use. If required, the default user - and any other user - can be removed from the User Directory by command MCDCR. It should be also be noted that even if user authority is applied to a port (i.e. AUTO=NO in Communication Directory, NAME and PASSWORD defined in User Directory) then any user who has a name and password defined in User Directory can access the system via this port using own name and password. It is thus impossible to limit the use of a given terminal/port to an individual user. All entries in the two directories must be deblocked, i.e. activated, by use of the command MCDBE. The entries in the two directories can be printed with command MCDCP. The defined passwords are not shown in the printouts. The OPIs which include the definition of user authority verification in the SP are: Connection of Alphanumeric Terminal, SP-Connected. Change of Directories in MCS.
132 R1B

MCS applications

6.9 The MCS Transaction Log


The MCS Transaction Log is an optional function which stores information about different command and printout transactions, i.e. logging of the operator communication. The transaction log does not log transactions on devices of type alphanumeric file (AF) or towards CPU port.

AT

STDEP PRINTOUT CACLS .... EXROI PRINTOUT SYREI PRINTOUT LAFBP ALARM ... INFUI ...

AXE

Logfile on hard disk DATE TIME IO USER STDEP PRINTOUT CACLS .... DATE TIME IO USER EXROI PRINTOUT SYREI PRINTOUT DATE TIME IO USER LAFBP ALARM ... INFUI ... DATE TIME IO USER

AT

AMTP

Figure 6.12

MCS transaction log

A transaction log file can be defined to log data according to one of the following types of logging criteria:

Logging of all IO device transactions excluding certain printout categories, PRCA, if required

Logging of all commands and result printouts on IO devices (like above


but without spontaneous printouts like alarms)

Logging of printouts by printout category, PRCA Logging of log on attempts to IO devices


Only one of the listed types of logging criteria can be defined per log file. In addition to this an exclusion may be added to each logging criteria:

Exclusion of certain commands in combination with logging criteria


Up to five log files can be active at the same time. Each file must have a unique name.
R1B 133

AXE IO System, IOG 20

The transaction log files are composite sequential files. The files must be created before any logging conditions can be defined. Unlike the command log file, the transaction log files are not system dependent and can have any name. The transaction log files are normally defined in the volumes where statistics data is recorded. The volume is preferably duplicated and must have a certain size as the transaction log may store huge amounts of alphanumeric data. The operational instruction MCS Transaction Log describes how to set up, change and remove logging conditions and also how to deblock (activate) the log. How to set up the MCS transaction log is market dependent and it may be configured according to the local needs. A few things could be recommended:

Never log the transactions of the terminal which is connected to the


alarm interface. This device sends out printouts which are orders to the alarm panel and receives commands which are input from the external alarm interface. This information is not alphanumeric and is an unnecessary waste of space in the log.

Never log the transactions on a IO device which is connected to an


authentication centre in the GSM mobile network. The traffic on such an IO device is very high and consists of garbage from an alphanumeric point of view.

Exclude the printout category for the heart beat printout, HB. If the
heart beat function is active this printout is emitted continuously. The printout category is parameter set in block ALA, usually 35.

In some markets the logging of the restart data and system restart printout is kept in a log of its own. Since this log contains very little data it may be stored for a long time on the hard disk and can therefore serve as a record when measuring the ISP. The printout category is 32 and this includes CP, EMRP and RP restart as well as Error Interrupt in APZ 212 20. The logging of this printout is then preferably excluded from other logs.

If the alarm status function is used (i.e. the alarm status printout is continuously sent to operation and maintenance centre), that printout is preferably excluded. The printout category is 47. Command example:
< IMLCT:SPG=0; : MCTLS:FILE=TLOG,FILEDUR=72,IO=AT-0&AT-2&AT-4& AT-5,XPRCA=32&35&47; : MCTLS:FILE=TLOGRESTART,FILEDUR=240,PRCA=32; : MCTLS:FILE=TLOGON,FILEDUR=120,LOGONS; : MCTBE:FILE=TLOG; : MCTBE:FILE=TLOGRESTART; : MCTBE:FILE=TLOGON;

134

R1B

MCS applications

: END;

Command example of setting logging conditions. The first condition logs all commands, printouts and alarms except the alarms of printout categories 32, 35 and 47. The second logs restart data only. The third logging condition is only relevant if the authority system is used. The log is deactivated by the command MCTBI. The transaction log files are composite files with the record length 256 bytes. The function automatically creates a new subfile every hour. The command parameter FILEDUR determine the file duration in hours, i.e. the number of subfiles to be used. A maximum of 250 subfiles can be created. When the specified time has expired the oldest subfile is deleted. Thus, every hour, one new subfile is created and one is deleted, which implies that the number of simultaneously kept subfiles, in one mainfile, never exceeds the file duration value. The subfile name indicates which time period the subfile contains logging data for. The log subfile name construction is ymmddhh where y indicates year, mm indicates month, dd day and hh hour. By using File Process Utility, FPU, the transaction log subfiles can be sent automatically to an operation and maintenance centre via data link. The infinite files function is never used with MCS Transaction Log.

6.9.1

Exclusion of certain commands and printouts from logging


An administration may chose to exclude certain commands and printouts from being logged by the MCS transaction log. This is performed by creating a text file in AXE-external environment (WS or PC) which lists the commands and printouts to be excluded.

R1B

135

AXE IO System, IOG 20

Text file with commands and printouts to exclude: AGKDI Hard disk in IOG20, SPG0 EXRPI EXROI printout printout File PC or WS

Encryption

Figure 6.13

Exclusion of printouts and commands

This file is loaded in SPG0 and encrypted before being stored on the hard disk. This file is read by the MCS Transaction Log after restart and the indicated commands and printouts excluded. Since the file is encrypted there is no way to read the file and which commands and printouts are excluded cannot be printed by command.

6.9.2

Search in Transaction Log


The search in the transaction log is performed according to one or more of the following criteria.

IO device date and time one command or part of command name e.g. CH for charging commands beginning with CH

all printouts one or a number of printout categories a specific user logon attempts

136

R1B

MCS applications

AT AXE Logfile on hard disk DATE TIME IO USER STDEP PRINTOUT CACLS .... DATE TIME IO USER EXROI PRINTOUT SYREI PRINTOUT DATE TIME IO USER LAFBP ALARM ... INFUI ... DATE TIME IO USER

AT

AMTP STDEP PRINTOUT CACLS ....

EXROI PRINTOUT SYREI PRINTOUT

LAFBP ALARM ... INFUI ...

Figure 6.14

Search in transaction log

This is described in the operational instruction MCS Search in Transaction Log. Two types of searches exists, i.e. search on transactions concerning the terminal the search is ordered from and authorised search which gives a possibility to search on any transaction made on any terminal. Example of search in transaction log:
< IMLCT:SPG=0; : MCSTP:FILE=file,COMMAND=CH,STIME=1000, ETIME=1200; ORDERED : END;

This command will give a printout of all commands beginning with CH (charging commands) sent from this terminal between 10:00 and 12:00 the current day. Example of authorised search in transaction log:
< IMLCT:SPG=0; : MCSAP:FILE=TRLOG1FILE,LOGONS,IO1=AT-2&&-4, IO2=AMTP-2,ETIME=1200;
R1B 137

AXE IO System, IOG 20

ORDERED : END;

This command will give a printout of all logon attempts (successful and unsuccessful) from the terminals AT-2, AT-3 and AT-4 from midnight to 12:00 the current day. The search result will be printed on terminal AMTP-2.

6.9.3

Implementation
The function is handled by the four modules TLOG, TLOGADM, TLOGS and TLOGSADM. The file TLOGCOND on hard disk stores the logging conditions.

6.10 Command file


Commands are usually executed manually or automatically from a alphanumeric terminal. Commands may however also be executed from a prepared command file on hard disk or external media. The command file may be executed manually or automatically according to a time schedule. The most important use of the command file is when executing a command log after a reload. All commands that have affected the exchange data up until the reload are then stored in two of the subfiles to file RELCMDHDF.

6.10.1

Creation of command file


Command example:
< INCMT:SPG=0; : INFII:FILE=COMMAND,SIZE=5,EXP=5,RLENGTH=128, TYPE=SEQ,FCLASS=CMP,VOL=EXCHVOLUME; : END; < IOAFT:FILE=COMMAND; < CACLP; < STDEP=DEV=LI3-133;

In the example above the file COMMAND is created on hard disk. Each record is defined to 128 bytes, this is to make sure that also very long commands may fit into one record. The commands CACLP and STDEP are written to the file.

6.10.2

Manual execution of command file


Command example (continued from above):
< IOCMI:FILE=COMMAND,PROC=D,IO2=AT-5; (on AT-5:)

138

R1B

MCS applications

COMMAND READING STARTED < CACLP; (...printout) < STDEP:DEV=LI3-33; (...printout) END OF COMMAND READING

In the example above the execution of the command file is started from one terminal while the execution of the commands in the command file is started on terminal AT-5. The process D is used which means that the commands are printed on screen when executed, also process printouts, answer printouts and result printouts are printed. The execution of the command log will continue irrespective of any fault codes. The process parameter can take values A, B, C, D and E. See the command description for command IOCMI for description.

6.10.3

Automatic execution of command file


A command file may be executed automatically in two ways, either according to a time schedule or automatically after a reload. According to time schedule. Command example:
< IOCMC:STATE=PASSIVE; < IOCML:FILE=COMMAND,DATE=970401,TIME=0200, PROCESS=B,IO2=AT-9,DAILY; < IOCMC:STATE=ACTIVE;

In the example above the time schedule for command files is deactivated and a time schedule for execution of command files is defined. After this the execution of command files is activated again. The command file COMMAND will be executed at two oclock in the morning every day, starting the first of April 1997. The commands will be executed on AT-9. The execution will be done according to process B which means that the execution is halted if a fault code is received from the system. The command log time schedule, and its status, is printed with command IOCMP. Automatically after a reload. This option is valid only for command log subfiles. This function is controlled by command SYGPS, parameter CLH, command log handling.

6.11 IO device load regulation


The load regulation of IO devices is used to regulate the output of printouts depending on the central processor load. The load regulation is controlled by block LOAS. The different priority levels are similar to the priority levels of a subscriber or of an incoming route, parameter PRI.
R1B 139

AXE IO System, IOG 20

Command example:
<IOLRC:IO=AT-5,PRI=EMERGENCY;

In the example above the priority of IO device AT-5 is set to the highest, emergency, indicating no load regulation at all. The definitions are printed by command IOLRP.

6.11.1

Implementation
Block LRCIO.

6.12 Chapter Summary


The MCS software resides both in the CP and in the SP Some of the main functions of MCS are: administration of commands
printouts and alarms, printout routing, authority system, MCS directories, MCS transaction log, etc.

There are two types of alarms internal and external There are five alarm classes A1, A2, A3, O1 and O2 and sixteen alarm
categories (0-15)

Each automatically initiated printout is assigned a printout category


(PRCA)

The PRCA is used to direct the printouts, such as the alarm list, to certain IO device(s)

Device chain is a chain of maximum eight devices receiving different


PRCAs simultaneously

Each PRCA or group of PRCAs can be connected to a device group


consisting of maximum four device chains

MCS transaction log stores information about different command and


printout transactions

Logging criteria for the MCS transaction log: logging of all IO device
transactions, logging of printouts by PRCA, logging attempts to IO devices

Search in MCS transaction log is performed according to several criteria, such as IO device, date and time, one command or part of a command, one or a number of PRCAs, etc.

140

R1B

7. MCS - Command handling

Chapter Objectives
After completing this chapter the student will: Explain the purpose of the entry commands used with IOG 20 Name the entry commands for the different subsystems
Figure 7.1

Chapter Objectives

7.1 Introduction
This chapter describes command handling in AXE.

7.2 AXE Command Handling


The AXE operator interface is implemented in a number of commands. Most of the commands follows the five-character MML standard. The software that implements the commands is located in the CP, SP and in firmware in the maintenance unit in the CP. In the AXE system there is a distinction between the commands that are implemented in software that exist in the CP and those commands which are handled by software in the SP. Or, putting it in a slightly simplified way, one must distinguish between CP commands and SP commands. All commands that are implemented in the CP - for both APT and APZ blocks - are given in the normal way in accordance with the rules of the man-machine language. IOG 20 is transparent for these commands and for the answer printouts received. This is shown in Figure 7.2.

R1B

141

AXE IO System, IOG 20

Alphanumeric terminal
Command AT

SP

CP

Printout
Figure 7.2

Handling of CP commands

When a command is to be executed in an SP - in any SPG connected to the CP - the CP must first be told that this is the case. To do this, one must give a special so called entry command which opens a dialogue between the operator terminal and the required SPG. There are a number of different entry commands in the AXE IO system.

a) AT

Entry command SPG0 Printout CP

c) AT

Entry command SPG0 Printout SPG1 CP

b) AT

Subcommand SPG0 Printout CP d) AT Printout Subcommand

SPG0

CP

SPG1

Figure 7.3

SP command handling a) Entry command and printout, SPG0 b) Subcommand and printout, SPG0 c) Entry command and printout, SPG1 d) Subcommand and printout, SPG1

142

R1B

MCS - Command handling

Note that terminals may be connected to LUM in SPG0 only. SPG1 does not contain subsystem MCS. Whether a command is implemented in CP or SP is in many cases indicated in the command description. The operator usually knows this by heart. The entry command is also called a path building command i.e. it is used to set up a path from the CP to the required command receiving block in the required SPG for the following command sequence. The dialogue is then carried out from the terminal side using so called subcommands. Command example:
<IMMCT:SPG=1;

This entry command builds a path from the CP to SPG 1. Entry commands are analysed in the normal manner by the ANA blocks in the CP. Thus user authority and terminal authority verification can be provided by the ANA blocks for these commands. Each entry command owns a given set of subcommands, so once an entry command has been given correctly any of these subcommands can be entered. During the dialogue with a certain entry command no other commands can be given but the sub commands belonging to this particular entry command. The subcommands thus pass from the SP to the CP where they are directed to the required SPG. The handling of the subcommands in the CP depends on the entry command. The printouts are sent back to the terminal on the same path. An exception to the above (Figure 7.3 b) is the special case of certain large result printouts received from the SP in own SPG. These can be sent directly to the terminal from the SP without going via the CP in order to gain CP capacity. For MCS, DCS and several SPS user function blocks in the SP, a group of MCS modules in the SP (MESSTRANS, COMANA and PRINTSERV) have the same function in the SP as the ANA blocks in the CP. They perform the necessary interface between the incoming commands/outgoing printouts and the user blocks.

7.3 Entry Commands


SPS maintenance and reconfiguration functions have just one entry command. Certain operation functions in SPS make use of a command receiving block in MCS and thus use entry commands belonging to MCS/DCS. The commands used for DCS/MCS are general entry commands that would also be used for addressing functions belonging to Remote Measurement Subsystem (RMS) and Statistics Traffic Measurement Subsystem (STS) if these were loaded.

R1B

143

AXE IO System, IOG 20

In each subsystem each entry command corresponds to a different authority level: high, middle and low. High authority entry commands allow all subcommands for the subsystem to be entered. Middle authority commands allow a limited number of subcommands to be entered. Low authority commands allow only print subcommands to be entered. The entry commands for each of the subsystems are listed below: SPS (maintenance)
IMMCT

FMS
INMCT INMIT INMPT

MCS/DCS/RMS/STS
IMLCT IMLIT (F-category) IMLPT (E-category)

All new subcommands being developed in IOG 20 are located under entry commands IMLCT, IMLIT and IMLPT. The fourth character of the commands: C is for I is for P is for Change and Print Initiate and Print Print high authority middle authority low authority

When an entry command is given correctly, the system answers by prompting a colon. Command example:
<IMMCT:SPG=1; : :END; EXECUTED <

In the example above a dialogue is started towards SPG1 and subcommands can now be given after the colon. Subcommands issued will be analysed in SPG1. A dialogue is terminated by command END and the ordinary prompt is used. A dialogue may also be temporarily terminated by an @-character. The dialogue is resumed by a EOT character which is for example sent by function key F1 in FIOL. Command example:
<IMMCT:SPG=2; : :@

144

R1B

MCS - Command handling

< INTERRUPTED COMMAND IMMCT <(EOT) : RE-ENTRY TO COMMAND IMMCT : :END; EXECUTED <

In the example above the dialogue towards SPG2 is temporarily suspended by a @-character and after that resumed by an EOT character. Finally the dialogue is terminated by command END. A further entry command not previously mentioned is the command ISMCT. This is a special entry command which is only used at start up of an IOG 20 - so called cold start. This command is implemented in the start system only and is not part of an ordinary IOG 20 system. The ISMCT command will only be accepted during the start up phase and therefore is not used for basic operation and maintenance.

7.4 Subcommands
To each of the entry commands belongs a set of subcommands. These are also found in the Command Descriptions in the B-Module. When a subcommand is entered with the necessary parameters (if any) answer printouts are received in exactly the same way as with CP commands. After each of these printouts a new colon is given so that a new subcommand can be entered, and so on. To end the dialogue the subcommand END must be given. After this subcommand the communication returns to the CP and the ready mark is obtained. Normal CP commands can now be given. A new entry command must be given if a new session between the CP and an SPG is to be initiated. Then the procedure printout ORDERED is received in answer to a subcommand, the dialogue must first be terminated before the terminal can be released. Thus the subcommand END must be used. After receiving printout EXECUTED the terminal can be released and the result printout obtained. As the dialogue has been terminated, if one wishes to continue with subcommands belonging to the original entry command then the entry command must be given again before it is possible to continue.

R1B

145

AXE IO System, IOG 20

7.5 Local Mode and CPT Commands


As has been seen so far, all commands concerned with an SP - entry and subcommands - are sent to the CP from the SP. The subcommands are directed by the CP back to the SP or to an SP in another SPG. However, the possibility exists to send commands to the SP which do not go on to the CP, but are handled directly by the SP. If commands are to be handled directly in the SP then:

the commands must be implemented in the SP the SP must be accessed by an operator working in local mode
Using local mode the operator access the SP directly and receives printouts directly from the SP.

Commands

AT SP CP

Printouts
Figure 7.4

Local mode

An SP is accessed in local mode in two ways:

connecting a terminal to the CPU port using the path building command MCLOC
One can access the SP in local mode at any time, even if the CP is running, but obviously there is no reason to do this. The number of commands that can be addressed to the SP alone are limited. Not all MCS and FMS subcommands can be handled by SP functions alone. Also certain functions that can be handled by the SP alone are not authorized in local mode if the CP is available. The main use of local mode is to be able to access the SP when the CP is unavailable for some reason. Thus, if the CP should become seriously faulty and IO commands are not accepted, then access to the system using local mode must be used to initiate a recovery process.

146

R1B

MCS - Command handling

Within the SP software exists part of the CPT function (Central Processor Test system). This software - a number of Maintenance Subsystem modules - allows us to access CPT hardware in the CP in order to facilitate testing and loading of the CP from hard disk. To do this we must use a set of CPT commands. To be able to give CPT commands the SP must be accessed in local mode. To use local mode a command is used: MCLOC. Access in local mode can be made from any terminal having authority for this command. At loss of contact with the CP for any reason the messages: CP UNAVAILABLE, ENTER EXIT OR MCLOC or CP SB UNAVAILABLE, ENTER EXIT OR MCLOC is given. The command MCLOC will always be accepted provided that the SP is running. The sequence is given below: <MCLOC:USR=XUJING,PSW=CRYSTAL; : :EXIT; EXECUTED < USR and PSW correspond to the operators user name and password defined in the MCS User Directory. A master user and password are defined in the initial data but can be removed by the administration. Commands can now be given to the support processor in the own SPG. It should be noted that MCS, DCS, STS or RMS subcommands require no entry command when issued in local mode. The subsystem FMS has its own specific entry command and thus with this subsystem the entry command must be given when FMS is to be accessed in local mode. The subsystem SPS is not accessible when accessing the SP in local mode in the above manner. Local mode can also be attained by making use of the local terminal mentioned earlier. If, for instance, all Line Units are blocked then no access can be made to the system. A terminal connected to the CPU60 board in the SP could be used to give SP commands to deblock the LUs. When entering local mode using a local terminal then the command MCLOC is not required. All four subsystems can be accessed in this case. The entry commands for SPS and FMS can be given without the SPG parameter.

R1B

147

AXE IO System, IOG 20

The AT must be working with capital letters in this case. If contact is lost during a command sequence, then the terminal must be switched to TTY mode and semicolon entered. On reception of the ready mark return to buffer mode. An important difference to notice between normal mode and local mode of access is that when a terminal has to be released in local mode then the command EXIT must be used. To return to local mode the command MCLOC must be used again. It is not usually necessary, however, to release a terminal on receiving ORDERED when accessing in local mode. This depends on the command used. When working with a local terminal or with suitable authority on an IO terminal the command HELP can be used to print all commands that can be used in local mode.

7.6 Chapter Summary


Entry command is given to open a dialogue with a specific subsystem
in a specific SPG

IMMCT is the entry command for SPS INMCT is the entry command for FMS IMLCT is the entry command for MCS/DCS/RMS/STS Commands given in normal mode are sent to the CP from the SP Commands given in local mode, are not sent to the CP, but are handled
directly by the SP

148

R1B

8. DCS Applications

Chapter Objectives
After completing this chapter the student will be familiar with: The structure of DCS with line units and ports The commands and HW implementation The interfaces and protocols supported in IOG 20 How to define a terminal in the AXE system How to define a data link
Figure 8.1

Chapter Objectives

8.1 Introduction
This chapter describes the different functions of the data communication subsystem, DCS. DCS functions are also described in the next chapter.

8.2 General on Data Communication


Before looking at DCS it may be a good idea to recap certain basic concepts in data communication. A data link is basically used to connect two computers together so that data can be transferred between them. A terminal connected to a computer is also connected via a type of data link. The communicating hardware in the computer/ terminal is called the physical interface. The rules for addressing, establishing sessions, exchanging data and messages between computers is called a protocol. The interfaces and protocols used depend to a certain extent on the type of data transfer: Asynchronous or Synchronous. Asynchronous transfer means that both ends of the transmission have independent clocks (of the same frequency). The characters (or data) are sent one by one with each character preceded by a start bit and followed by a stop bit or bits. Most terminals (e.g. PC or WS) are asynchronous.

R1B

149

AXE IO System, IOG 20

Synchronous transfer means that the transmission is controlled from the sending end. The data is sent in packets of several bytes. These packets are preceded by a number of synchronizing characters (flags) and some layer specific overheads. The predominant method of synchronous data transfer is in packet switched networks. Here the data is packed into packets, each with an address label, which are sent individually over the network. At the destination the packets are unpacked and the data reassembled to original form. Standardized interfaces and protocols has been defined by ITU-T and other standardization forums. Data Terminal Equipment, DTE, is usually a terminal or a computer. Data Circuit Terminating Equipment, DCE, is usually a network or a modem.

8.3 The OSI Reference Model


A standard model for data communication has been defined by the International Standards Organization, ISO. This standard is called the OSI Reference Model, where OSI stands for Open Systems Intercommunication. OSI is a logical structure in which the functions required for the data transfer have been broken down into seven distinct layers each of which communicates with the corresponding layer at the remote end of the connection. By protocol is meant the rules for the handshaking communication between the corresponding layers. A protocol may be implemented on one layer or more. The OSI model itself does not specify any protocols or interfaces. The model with the seven layers is often referred to as the OSI-stack.

150

R1B

DCS Applications

USER

USER

7 6 5 4 3 2 1

APPLICATION PRESENTATION SESSION TRANSPORT NETWORK LINK PHYSICAL

APPLICATION PRESENTATION SESSION TRANSPORT NETWORK LINK PHYSICAL

PHYSICAL MEDIA
Figure 8.2

Open Systems Interconnection model

In the OSI model, the users (i.e. programs) at either end of the physical connection are connected via the seven layers as shown in Figure 8.2. The physical layer, is normally implemented in hardware only, but in some cases - e.g. IOG 20 - software exists to support and supervise the hardware. The other layers consist only of software. Each layer performs specific functions and is independent of the other layers, apart from a well-defined interface to the layers directly above and below. A layer can be changed without affecting the other layers, thus providing flexibility which, in turn, simplifies the interconnection of different datacom systems.

R1B

151

AXE IO System, IOG 20

USER A

user data

USER B

7 6 5 4 3 2 1

APPLICATION PRESENTATION SESSION TRANSPORT NETWORK LINK PHYSICAL

user data user data user data user data user data user data user data

APPLICATION PRESENTATION SESSION TRANSPORT NETWORK LINK PHYSICAL

Layer specific overhead

Figure 8.3

Sending of data or message from A to B

Each layer provides a service to the layer above. A message from a user program arrives at layer 7 where control information is prefixed by the protocol for use by layer 7 at the other end. The message with this additional data is sent on to layer 6 where more information is prefixed and then the message is sent on to layer 5 and so on. At the receiving end, the control information is removed by each corresponding layer until the original message can be sent by level 7 to the required user. The layers are thus transparent for the data being sent from user to user. Layers 1-4 are used to set up a path from one user to another - they are network dependent. Layers 5-7 define and maintain the communication between the users - they are application dependent. Layer 7 functions as an interface between the user programs and the network, i.e. it gives the user access to the network services. It is, as such, the network communication program as seen from the users point of view.

8.4 General on DCS


DCS is used for three functions in the AXE system:

terminal communication data link communication CPT link communication (in some APZ versions)
152 R1B

DCS Applications

Note that terminals may also be connected to an AXE exchange via MCS, this in the case of terminals connected to EMRP. Note that the CPT communication is not done via DCS but via RPS, for some versions of APZ 211. Most versions of APZ 212 use DCS for CPT communication. CPT - Central Processor Test.

8.5 DCS concepts


The basic concepts in DCS are:


8.5.1

Communication Module Line Module Line Unit Ports

Communication module
The Communication Module, CM, is a logical concept. The first node in SPG identifies the CM, as follows: SPG 0 SPG 1 SPG 2 SPG 3 node A = CM 1 node A = CM 17 node A = CM 33 node A = CM 49

The background to the CM numbering is the operating system. The operating system supports up to 96 nodes possibly including CM-1 to CM-16 in SPG0. In AXE each SPG always has two nodes. The same effect can be seen in the file system where each node has the same index as the CM. The numbering of CMs is only important in one context: the CM number is used when numbering the Line Units and the Ports to which the ATs and data links are connected. Node status is printed with command IMCSP:
:IMCSP; NODE CONFIGURATION STATUS SPG 0 NPAIR 1 END NODE CM A 1 EXSB STATUS STATE WORKING NORMAL NODE B CM 2 STATUS ISOLATED STATE BLOCKED HDSTATE CORRUPT

R1B

153

AXE IO System, IOG 20

The result printout includes the CM number corresponding to each node. A node in an SPG is either executive or standby.

NP = CM-LM-LU-NP PP = CM-LM-LU-PP
LU - Line Unit PP, NP - ports

HD3 drive HD2 drive

HD1 drive FD drive HD1 drive FD drive

Power Power

CPU60 CPU60

ALEXP ALEXP ALCPU ALCPU LUM LUM LUM LUM LUM LUM LUM ESDCV ESDCV RPV2 RPV2 VSA

OD drive (5 1/4)

Figure 8.4

DCS hardware

8.5.2

Line module
The Line Module, LM, could hardware-wise be compared to the physical grouping of all LUMs located in the same node. The line module is designated as CM-LM, where CM is the communication module of the A-node in the SPG. The line module is LM=1 in the A-node and LM=2 in the B-node. Example: the line module in the B-node of SPG1 is LM=17-2. The LM has no status and there is no command for defining the LM in IOG 20.

8.5.3

Line unit
The Line unit, LU, is implemented in the LUM board hardware. One line unit is implemented in one or two LUM boards and controls one to four ports. Each line unit contains a processor which loads its software from the main store. The module LUCHAR79 is the software of the LUM. A line unit can be redundant (twin) or non redundant (single). Each node may have three or four line units depending on IOG 20 version. The line units are designated as CM-LM-LU. Example: the third line unit in the B-node of SPG1 is LU=17-2-3.

154

R1B

DCS Applications

Each line unit has its own VME-bus address. The address is the same as the line unit index and is strapped on the LUM board. The only allowed strapping addresses are 1, 2, 3 and 4 from left to right.

Line Units 1, 2, 3 and 4

HD3 drive HD2 drive HD3 drive HD2 drive

HD1 drive FD drive HD1 drive FD drive

Figure 8.5

Line unit addressing

Power Power
R1B

CPU60 CPU60

Command examples:
<IMLCT:SPG=2; :ILLUI:LU=33-2-1,CHAR=79; :END; <IMLCT:SPG=0; :ILLUI:LU=1-1-4,CHAR=79; :END;

In the command examples above the line units 1 and 4, located in the Bnode of SPG2 and the A-node of SPG0 are defined. The line units are single (non redundant). A line unit can take the status:

ALEXP ALEXP ALCPU ALCPU LUM LUM LUM LUM LUM LUM LUM LUM ESDCV RPV2 RPV2 VSA VSA

OD drive (5 1/4) OD drive (5 1/4)

Working Executive or Standby - WO/EX, WO/SB Manually Blocked - MBL Hardware Blocked - HBL Conditionally Blocked - CBL Automatically Blocked - ABL

The status of the line units is printed with command ILLUP.

155

AXE IO System, IOG 20

If a higher security is required the line unit may be defined as a twin (or redundant) line unit.

SPG0 Node A

SPG0 Node B

LUM

LUM

LUM

LUM

LUM

LUM

LUM

Y-cable

Figure 8.6

Twin line unit

In a twin (or redundant) line unit, two line units in different nodes of one SPG, are defined as one line unit. The purpose of having twin line units is security. If something would malfunction in one node the traffic is automatically switched over to the line unit in the other node. When the IOG 20 is started up, line units 1-1-1 and 1-1-2 are already twinned with the line units 1-2-1 and 1-2-2 respectively. Example: LU= 1-1-3 and LU=1-2-3 could be defined as being one twin line unit. Command example:
<IMLCT:SPG=0; :ILLUI:LU=1-1-3,CHAR=79,TWIN; :ILBLE:LU=1-1-3; :ILBLE:LU=1-2-3; :END;

In the command example above the logical line unit 1-1-3 is defined as twin and the physical line units, 1-1-3 and 1-2-3 are deblocked.
156 R1B

LUM

DCS Applications

A logical line unit can be defined, as it can be seen above, deleted or printed and is used when the ports are defined. Ports are always related to the logical line unit, thus LU=1-1-3 should be used when defining ports in the above example. A physical line unit can be blocked or deblocked as it can be seen above It is recommended, to always deblock first, the line unit located in the EXnode.

8.5.4

Port
The ports of DCS implements the interface towards data links, terminals or CPT. The ports are implemented on daughter boards attached to the LUM board. There are four kinds of daughter boards, implementing different communication interfaces, as below: V G E T V.24/V.35/V.36/X.21 G.703 E0 (64Kbps) G.703 E1 (2Mbps) Ethernet ***

*** Note: The optional ethernet connection (T), is not introduced as an orderable product at the first IOG 20 release. Each LUM board holds four ports.

Mother board

Screws

Daughter board

. . . .

. . . .
Each daughter board implements one physical port

Figure 8.7

LUM board

R1B

157

AXE IO System, IOG 20

The port concept is divided into:

Single link port Logical link port network port


The concepts are partly overlapping. A single link port, SLP, is a port located on a logical line unit (redundant or not) with one logical link defined to it. A single link port is identified as a network port (see below). A logical link port, LLP, is a port to a logical link. There are one or more logical links on a physical port. A logical link port is identified by LLP=CM-LM-LU-PP-LLP. This type of port is only used for CPT ports. A network port, NP, is a physical port with one or more logical links defined to it. Single Link ports and Logical Link ports are Network ports. A network port is identified by NP=CM-LM-LU-SLP or NP=CM-LMLU-PP-LLP. Example: the port NP=17-1-4-4 is the fourth port of the line unit number e in SPG1.

PP = 1-1-1-1 PP = 1-2-1-1 PP = 1-2-4-4

PP = 17-1-1-1 PP = 17-1-3-4 PP = 17-2-4-1

LUM

LUM

LUM

LUM

LUM

LUM

LUM

LUM

LUM

LUM

LUM

LUM

LUM

SPG0 Node A
Figure 8.8

SPG0 Node B

LUM

SPG1 Node A

LUM

SPG1 Node B

Port designation SPG0, SPG1

When defining a port not only layer 1 but also the layer 2 and 3 characteristics are specified. There are a number of different parameters related to the three layers that may be modified for each port or link. The OPI Single Link Port, Initiate gives recommendations and explanations to all
158 R1B

LUM

DCS Applications

parameters. Each parameter is always given a default value when defining the port. Command example:
<IMLCT:SPG=0; :ILSLI:NP=1-1-4-4,RATE=19200,PROT=X28/V24; :ILSLC:NP=1-1-4-4,PAD=6-1&1-0; :END;

In the command example above the single link port 1-1-4-4 is defined. Note that the command uses parameter NP, network port, to identify the SLP. The layer 1 hardware interface is V.24/V.28 and the baudrate is 19200 baud. X.28 and X.3 are used on layer 3. The packet assembly-disassembly parameters 6 and 1 are given the values 1 and 0. Command example:
<IMLCT:SPG=2; :ILSLI:NP=33-1-2-1,RATE=2048000,PROT=X25DTE/V36; :ILSLC:NP=33-1-2-1,TC=1-16; :END;

In the command example above the single link port 33-1-2-1 is defined with a baudrate of 2 Mbps. Layer 1 is a V.36 interface, layer 2 is HDLC/ LAPB and layer 3 is X.25 working as a Data Terminal Equipment. Logical channels 1 to 16 are defined as two-way channels. The ports are blocked and deblocked by commands ILBLI and ILBLE, and removed by command ILSLR. A port may have the following status:

Working, WO Automatically block, AB Conditionally blocked, CB Manually blocked, MB Hardware blocked, HB

The port parameters and status are printed by command ILNPP. Command example (CPT ports):
<IMLCT:SPG=0; :ILLLI:PP=1-2-4-1,RATE=64000,PROT=SDLC/V36; :ILLLI:NP=1-2-4-1-1,PROT=CPT/SDLC,ADDR=H01; :ILLLI:NP=1-2-4-1-2,PROT=CPT/SDLC,ADDR=H86; :ILLLI:NP=1-2-4-1-3,PROT=CPT/SDLC,ADDR=HA9; :ILLLI:NP=1-2-4-1-4,PROT=CPT/SDLC,ADDR=HCD; : :ILLLC:PP=1-2-4-1,ACCESS=LEASED; :END;

In the command example above the physical port 1-2-4-1 is defined with baudrate 64 000 bit/s.
R1B 159

AXE IO System, IOG 20

The logical link ports 1-2-4-1-1, 1-2-4-1-2, 1-2-4-1-3 and 1-2-4-1-4 are defined SDLC interface. Layers 3 and above are controlled by the Central Processor Test function. Note that the command ILLLC may change the characteristics of the logical link ports or physical ports (related to CPT ports). The ports are blocked and deblocked by commands ILLBI and ILLBE, and removed by command ILLLR. The status of logical link ports is printed by command ILNPP.

8.6 Implementation
Modules PORTADM, LME, CMMAN and LUMAN. Files CMFILE, LUFILEx and PEFILEx on hard disk (x indicates the SPG number).

8.6.1

Layer 1, interfaces
The interfaces provide layer 1 in the OSI reference model. The communication protocols cover layers 2-7.

CPT SW (CPTASP) MCS 7 6 5 4 3 2 1 V.25 bis/V.28 X.28/X.3 SDLC V.24/V.28 V.36 ATP

CP-SP communication
Users in SP

FMS

Ericsson MTP X.29

FTAM
Presenation (6)

Session (5)

X.224 X.25 HDLC / LAPB V.35


Network (3)

RFC1006

TCP/ IP
Data Link (2)

X.21 V.25 bis/V.28

E0

E1

Ethernet

V.24/V.28 DCS Asynchronous

Synchronous

Figure 8.9

AXE IOG 20 protocols and interfaces

The following types of interface standards are supported in IOG 20: Interface: Asynchronous transmission: Supported baudrates

160

R1B

DCS Applications

ITU-T V.24/V.28 (EIA RS 232 C) ITU-T V.25bis/V.28 Synchronous transmission: ITU-T V.24/V.28 (EIA RS 232 C) ITU-T V.35 ITU-T V.36 ITU-T V.25bis/V.28 ITU-T X.21 ITU-T G.703 E0 ITU-T G.703 E1 Ethernet V.24/V.28

2400 - 57 600 bits/s 2400 - 57 600 bits/s

2400 - 57 600 bits/s 2400 - 256 000 bits/s 2400 - 2 048 000 bits/s 2400 - 57 600 bits/s 2400 - 2 048 000 bits/s 64 000 bits/s 2 048 000 bits/s 10 240 000 bits/s

interface is used for the connection of asynchronous ter minals or other synchronous connections, either locally or via modem. V.24 identifies the physical layout of the connector (pins) and V.28 the electrical characteristics. Implemented in V.24/V.35/V.36/X.21 INTERFACE daughter board.

V.25bis/V.28

is for the connection of asynchronous or synchronous ter minals via modem (dial-in/dial out procedures). V.25 bis identifies the automatic calling and/or answering proce dures and V.28 the electrical characteristics (V.24 circuits are used). Implemented in V.24/V.35/V.36/X.21 INTERFACE daughter board.

V.35

Interface for interworking with V.35 modem. Implemented in V.24/V.35/V.36/X.21 INTERFACE daughter board.

V.36

Interface for interworking with V.36 modem. Implemented in V.24/V.35/V.36/X.21 INTERFACE daughter board.

X.21

X.21 interface is used for the connection of high speed synchronous data links in public data networks Implemented in V.24/V.35/V.36/X.21 INTERFACE daughter board.

R1B

161

AXE IO System, IOG 20

G.703 E0

is used for the connection of a 64 kbit/s PCM data link over the PCM network. (After connection through a PCM multiplexer the data occupies one channel in a 2 Mbit PCM line and can be connected to GSD). Implemented in G.703 E0 INTERFACE daughter board.

G.703 E1

is used for the connection of a 2 Mbit/s PCM data link over the PCM network. Implemented in G.703 E1 INTERFACE daughter board.

Ethernet

is not introduced as an orderable product at the first IOG 20 release.

8.6.2

Layer 2
Layer two in the OSI model is the Link layer. It provides reliable transfer across the physical links. It establishes the beginning and the end of blocks of data (with synchronisation), error detection and link flow control. On layer2, three protocols are supported by the AXE system:

SDLC (only for CPT ports) LAPB IP (Internet Protocol)


The Synchronous data link communication protocol, SDLC, is a standard which in AXE is only used with Central Processor Test, CPT. The Link Access Procedure Balanced Mode protocol, LAPB. This protocol is used together with X.25. LAPB is similar to High Level Data Link Control, HDLC.

8.6.3

Layer 3
Layer three in the OSI model is the network layer. Here AXE supports three protocols:

X.25 X28/X.3 TCP (Transport Control Protocol)


The X.25 protocol is a packet switching protocol used by Ericsson MTP and FTAM. Asynchronous terminals access the IOG 20 via protocols X.28/X.3. The asynchronous data from a terminal uses the X.28 protocol to access a Packet Assembly/Disassembly (PAD)-function based on X.3 protocol.

162

R1B

DCS Applications

8.6.4

Layer 4-7
Layers 4 to 7 implements the transport, session, presentation and application layers (like MTP and FTAM). A Session Port is a software protocol in DCS. Session ports can be defined for the following protocols in AXE:

X.224 X.29 Ericsson MTP


A session port is addressed by a network terminal number. Command example:
:ILSPI:SP=MTP,NTN=9837648844;

In the example above the session port for accessing the Ericsson MTP protocol is given the address NTN=9837648844. The session ports are printed with command ILSPP and removed with command ILSPR. Layers 4-7 implements the protocols X.29, ATP, X.224, Ericsson MTP, and FTAM in IOG 20. For file transfer to/from AXE the protocols Ericsson MTP and FTAM are used. For command/printout transfer over data link the Ericsson MTP protocol is used. The locally connected terminals connects via Asynchronous Terminal Protocol, ATP. ATP is the protocol used to interpret the control characters entered by the terminal operator during command sessions e.g.,<<CR>>, <<ESC>>, EOT>>. A number of applications use FTAM or MTP protocols for file transfer. File Process Utility (FPU) uses Ericsson MTP or FTAM for file transfer. Direct File Output (DFO) uses Ericsson MTP for file transfer.

8.7 Network Services


Many services are available, of which four will be discussed here:

Addressing Routing Permanent/Hot Virtual Circuits and Direct Call Access/priority

R1B

163

AXE IO System, IOG 20

8.7.1

Addressing
Basically, a network user is identified by a Network Terminal Number, NTN. An NTN could be compared to a telephone number in the telephone network. Each country has its own numbering plan for NTN, just as they have for telephone numbers. An NTN has up to 15 digits, including of the prefix, called Number Direction, ND, which corresponds to the area code in the telephone network: NTN =ND + internal digits

Data network nodes

Computer NTN=65392

NTN=9873

NTN=905

NTN=94

Terminating function, example X.29 or MTP NTN=830968


Figure 8.10

Alphanumeric terminal

Addressing in data network

Structured number plans are used with routing cases and routes as in the case of the B-Number Analysis tables for telephone traffic. The DCS digit analysis may be compared to the B-number analysis table in TCS, where the Origin for digit analysis, ODA, is the equivalent to the B-number origin, BO. All ports in IOG 20 used for connection of AT devices are assigned network terminal numbers. Selection by name is an optional facility within the addressing service. By this function, a name-to-address conversion facility allows the use of a name, consisting of an alphanumerical identifier, instead of the NTN in the selection information.
164 R1B

DCS Applications

The indicated name is translated into an NTN in a table common to all users connected to the IOG. The table is created and modified by operator commands. FPU destination. When File Process Utility uses a data link it identifies the data link by a destination. This destination is defined by command INFDI and may be of equipment type MTP or FTAM, defining the protocol to be used. The destination is translated to a NTN number, its a oneto-one relation, with command ILDNI. The relation is printed with command ILDNP. Traffic Direction, TRD. This concept is used for statistics purposes. It is similar to the concept off Traffic Destination, TRD, in TCS. The traffic direction is a figure that is defined to identify a certain area or destination in the data network. Command example:
:ILTDI:TRD=150,ODA=6,ND=76;

The definitions are removed with ILTDR. Example of number analysis:


DCS DIGIT ANALYSIS ODA=0 ND 1011101 1011102 1011103 1011203 1011204 1012101 ..... 1012104 1015100 1015200 ODA=6 ND 7631 7632 7633 7634 7635 .... 7638 7639 ODA=99 ND NEWODA= NEWODA= NEWODA= RC=127 RC=127 RC=127 RC=127 0 0 0 DTE DTE DTE DTE DTE DTE DTE X29 MTP NP= NP= NP= NP= NP= NP= 1111111111121112211 2 3 3 4 1

NP= 1- 2- 1- 4

R1B

165

AXE IO System, IOG 20

76 END

NEWODA=

Command descriptions: ILRAI ILDAP ILNAI The command defines number analysis data for a given number direction, ND. The command gives a printout of number analysis data for one or all number directions. The command is used to define a name for a predefined NTN and insert the name and NTN in the addressing by name analysis. The command is used to print the addressing by name analysis data. Destination to network terminal relation. Destination to network terminal relation. Assigns a NTN to a network port, dedicated line. Prints NTN and terminals.

ILNAP ILDNI ILDNP ILTEI ILTEP

8.7.2

Routing
Routing of switched data traffic through the network is based on the NTN address described above. The NTN is used to access a remote user, or a name can be used if the selection by name facility is used. The NTN is first analysed in the called address number analysis. The analysis is carried out by means of the number direction, ND, and indicates if the called NTN is locally defined (terminating) or has to be reached by an outgoing route. See fig. 9.11.

166

R1B

DCS Applications

Computer NTN=42 ROT=76

Computer NTN=65392

ROT=75

ND=653: RC=9, ROT=76, NP=1-2-3-1 ROT=75, NP=1-1-4-4


Figure 8.11

DCS routing

In the former case, the called NTN can correspond to either a terminal reached by a dedicated line connected to a local Network Port in the packet switch or to an internal software function within the packet switch. In the latter case, a routing case, RC, is indicated. Each RC corresponds to a unique destination directly connected to the own exchange, i.e. packet switch. Each RC contains a list of routes toward the given destination. Each route is identified by a routing number, ROT. A routing case should include at least two routes. The first route defined in the list is the primary. The other routes are alternative routes in case a call cannot be established over the primary route. A route may use one or several physical circuits, i.e. physical ports with data links. To each route we thus define the network ports corresponding to the data links in the route. A route should have at least two ports defined. For a given route, the ports are chosen in the order that they are defined. After the called address, RC and route analyses, an idle network port is thus chosen for the call. The destination (called) NTN complete with ND is inserted by the network layer protocol into the message, together with the calling NTN and sent on into the network. The analysis can now be repeated at each switch in the network until the final analysis at the terminating switch. To define the data tables required for the analysis, the following commands are used:

R1B

167

AXE IO System, IOG 20

ILROI

The command defines a new route and inserts one or more network ports into the route. It also inserts network ports into an existing route. The command is used to change route data for an existing route. The command is used to print route data. Removal of route data. The command defines a routing case with its associated routes. The command prints routing cases. Removal of routing cases.

ILROC ILROP ILROR ILRCI ILRCP ILRCR

The OPI to be used when defining, changing or removing routing data is "DCS Address and Routing Analysis, Initiate". Modules CALLCONTROL/NETMAN handles the routing analysis and module PSSADM handles the commands for defining and printing of address and routing analysis data.

8.7.3

Permanent/Hot Virtual Circuits and Direct Calls


A Permanent Virtual Circuit, PVC, is a circuit set up between two net work ports, NP. A PVC is, as the name implies, a virtual circuit that is always connected between predefined users through the CM. A Hot Virtual Circuit, HVC, is a circuit set up between a network port, NP, and a session port. A HVC is a virtual circuit that is connected automatically between predefined users only when one of the users wants to use the circuit (compare Hotline).

168

R1B

DCS Applications

IOG20

X.29, NTN=1015100 Hot virtual circuit X.28/X.3 AT-7 NTN=1012104

V.24 physical interface

Figure 8.12

Hot virtual circuit

Command example:
:ILPCI:NTNA=1012104,NTNB=1015100;

In the example above the network terminal number 1012104, which represents a terminal is connected to the network terminal number 1015100, which represents the X.29 protocol in IOG 20. Each time a terminal sets up a call towards DCS, i.e. when the operator starts using the terminal, a connection will be established to the X.29 protocol. From there on the data sent from the AT will be switched further on to the Asynchronous Terminal Protocol OSI layer 7, and then passed on to MCS. The circuits are printed with command ILPCP and removed with command ILPCR. An example of a Hot Virtual Circuit is found in the definition of a port for connection of an alphanumeric terminal. The network port and associated X.28/X.3 protocols have to be connected to the Session Port X.29. Direct call. The direct call function enables the setting up of a Switched Virtual Circuit, SVC. The function assigns a B-side address (command parameter DCALL) to the A-side address (command parameter NTN). Command example:
:ILDII:NTN=9873562,DCALL=2984655;

The direct call function is removed from a certain NTN by command ILDIR and printed with command ILTEP.

R1B

169

AXE IO System, IOG 20

8.7.4

Access control
The access control may be incoming or outgoing calls from a certain address (NTN). It is also controls the priority of the data calls. Command example:
:ILACC:NTN=763539,PRI=3-4;

In the example above, calls from NTN=763539 are given the default priority 3 and the maximum priority 4. The priority ranges from 1 to 4. Command example:
:ILACC:NTN=82,ICB=YES;

In the example above the incoming calls are barred to NTN=82. The access control is printed with command ILACP.

8.7.5

Dedicated Lines
It should be noted that not all traffic is switched through the network using routing functions. In some cases, the data link is connected instead as a dedicated line - a fixed direct line between the two ends (usually called leased lines when hired from a network operator). This type of link thus uses a dedicated line connecting two so called statically allocated ports (if such a link was using PCM media - or was converted to PCM at an AXE exchange - then the link would be semi-permanently connected through the digital group switch). In this simpler case, instead of performing route analysis to obtain the Network Port for a suitable data link, the home switch must obtain the required port in some other way. As every destination is identified by its unique NTN, it follows that a relationship must be defined between the destination NTN and the required port in the home switch. When data is to be sent, the destination NTN will be specified - as in the case with switching - but as no route analysis data exists for this address, the NTN will now simply point to the Network Port at which the required data link is connected. Data sent via this port will arrive automatically at the required destination. In an IOG 20, the relationship between destination NTN and home port is defined by the command ILTEI. In effect, by this command, the home Network Port is assigned the NTN of the required destination.

8.8 Connection of DCS ports


The procedure for the definition of an Alphanumeric Terminal, AT, is described below. The definition of an alphanumeric terminal involves both subsystems MCS and DCS and is performed both in CP and SP.

170

R1B

DCS Applications

In order to define a port, a series of commands must be given. The procedure differs somewhat depending on whether the port is to be defined for 1) alphanumeric terminal, AT, or 2) data link. In case 1) it should be realized that the AT can be located remotely at an OMC and access the IOG via modems over leased lines or via a circuit switched data network using secure access control such as user groups (e.g. X.21 protocol). The port is still defined for an alphanumeric terminal accessing X.28 protocol. The device is type AT, i.e. IO=AT-n. In case 2) when a port is defined as being for a data link this implies a link using X.25 protocol in the packet switched network. Such a data link can be used for alphanumeric or file transport. When used for alphanumeric transport, the device type in the exchange is the data link itself and must be specified as AMTP (Alphanumeric communication using MTP) in the relevant commands, i.e. IO=AMTP-n. When defining a port the command parameters refer sometimes to (NP) and sometimes to (PP). This depends on whether the action performed by the command refers to the logical entity (NP) or the physical entity (PP). As four ports is the maximum that is allowed per LU, it may also be necessary at some stage to define a new Line Unit.

8.8.1

General
After initial start of IOG 20 line units 1-1-1 and 1-1-2 are already defined and twinned with the line units 1-2-1 and 1-2-2 respectively. Further LUs can be defined in the Data Transcript loaded after start up of the CP. The number of LUs defined depends on the number required by the customer. The ports 1-1-1-1, 1-1-1-2, 1-1-2-1 and 1-1-2-2 are defined in the initial data. More ports can be defined in the DT at the requirement of the customer. These defined ports correspond to:

AT-0, the alarm printer, 4800 bits/s AT-1, the alarm interface, 2400 bits/s AT-4, an AT device defined for 9600 bits/s AT-5, an AT device defined for 19200 bits/s.

8.9 Definition of Port for AT


To define a port for an AT the OPI: Alphanumeric Terminal in SPG, Connect should be followed. This OPI in turn refers to other OPIs.

8.9.1

Line Unit
Command example:
<IMLCT:SPG=0; :ILLUP:LU=CM-LM-LU;

R1B

171

AXE IO System, IOG 20

Check the line unit status. If the LU required is not defined, define it.

8.9.2

Network port
Command example:

:ILSLI:NP=np,RATE=rate,PROT=X28/V24;
The port is defined with protocol X.28/X.3 and physical interface V.24/ V.28. The default values for the X.3 transmission parameters assigned to the port on definition are printed. (The bit rate value assigned by command ILSLI is marked with an * in the text and shall not be altered).
:ILNPP:NP=np,DETAIL;

The actual values are obtained with command ILNPP with parameter DETAIL for a given existing port.
:ILSLC:NP=np,PAD=pad,PRIV=priv;

The default values of the packed-assembly-disassembly, PAD, and private PRIV parameters are changed.

8.9.3

Test of port
The Physical Port is now tested using one of three possible loop tests according to the OPI. Loop 1 is used to test the internal DCS path as far as the port, i.e. when no data link is connected.
:ILLTI:PORT=pp,LOOP=1;

8.9.4

Network Terminal Number


The next step is to assign a Network Terminal Number, NTN, to the network port.

172

R1B

DCS Applications

NP = 1 - 1 - 4 - 1

NTN = 1 01 1 4 01
NP, PP Line unit Line module Communication module Always 1

NP = 1 - 2 - 3 - 4

NTN = 1 01 2 3 04
NP, PP Line unit Line module Communication module Always 1

Figure 8.13

Network terminal number convention

For ports defined for ATs, the value for parameter NTN consists of seven digits and is constructed according to Figure 8.13. Note that this is the internal number within the own IOG. (NTNs used for accessing remote destinations over data links are constructed differently, as mentioned earlier in the section on addressing).
:ILTEI:NTN=ntn,NP=np;

8.9.5

Deblock the Port


The next step is to deblock the NP. The port was manually blocked but now becomes automatically blocked as no AT is connected.
:ILBLE:NP=np;

The connection of the AT to the packet switched network via X.28/X.3/ X.29 protocols has been covered above. The relevant diagram is given in Figure 8.9.

8.9.6

Hot virtual circuit to X.29 Protocol


The Network Port has now to be linked to the X.29 protocol (Session Port) via a Hot Virtual Circuit. First the pre-defined NTN for the X.29 protocol has to be determined by a printout:
:ILSPP;

Check which address (NTN) is assigned to the X.29 session port.


:ILPCI:NTNA=ntna,NTNB=ntnb;
R1B 173

AXE IO System, IOG 20

The connection is now made between the NP (NTNA) and the SP (NTNB) by the command ILPCI.

8.9.7

Insertion in User and Communication Directories


The terminal to be connected to the port must now be inserted in the two MCS directories User and Communication. In the Communication Directory the entry name (e.g. TNTN) for the terminal and the NTN for the port are registered, together with data indicating that automatic logon is to take place on the terminal. Session supervision and printout queuing are also defined. In the User Directory the entry name (TNTN) and authority E for the terminal is entered. This procedure is followed below. The NTN of the port is assumed to be 1011203. Insertion of a terminal in Communication Directory:
:MCDCI:DIR=COM,NAME=T1011203,NTN=1011203, AUTO=YES,SUPRV=NO,QUEUE=YES;

Insertion of a terminal in User Directory:


:MCDCI:DIR=USER,NAME=T1011203,AUTH=E;

Check the entries:


:MCDCP:DIR=COM; :MCDCP:DIR=USER;

Deblock the entries:


:MCDBE:DIR=COM,NAME=T1011203; :MCDBE:DIR=USER,NAME=T1011203;

IOG local mode operators are also registered separately in the User Directory. Authority EFH is the normal command authority given to local mode users. (No entry is required in the Communication Directory).

8.9.8

Connect Terminal to NTN


The identity of the terminal to be connected to the NTN is defined:
:MCDVI:IO=AT-n,NTN=1011203; :END;

8.9.9

Size Alteration Events


Check SAE 344 (Records in block ASCP = the number of session channels toward DCS for alpha terminals, i.e. the number of simultaneous command/printout sessions required). <SAAEP:SAE=344; If necessary, increase the size:

174

R1B

DCS Applications

<SAAII:SAE=344,NI=ni;

Check the IO device data records in the CP:


<SAAEP:SAE=800,BLOCK=AT;

If necessary, increase the size:


<SAAII:SAE=800,BLOCK=AT,NI=ni;

8.9.10

Define the IO device data in the CP


<IOIOI:IO=AT-n;

8.10 Definition of Port for X.25 Data Link


The definition of a port for an X.25 data link is done in a similar manner to that for an alpha terminal given above. However, several new commands are required for data link ports, while - as shown below - the IO device related commands are not required for file transfer applications. Note that data links may be defined in SPG0, SPG1, SPG2 and SPG3 while alphanumeric terminals may be defined in SPG0 only. In the procedure followed below, a port is to be defined in the IOG at the exchange for an X.25 data link connected to an Operation & Maintenance Centre (OMC). At the OMC the link can terminate in an IO device or an AOM (a communication computer which switches between different exchanges) or some other such device. These would normally be used for alphanumeric communication, but could also be used for receiving files. The link could also terminate in another computer (including an SP-based IO system) used for sending/receiving files over the link. Whatever type of DTE was used at the OMC, however, it would have to contain software for X.25 and Ericsson MTP or FTAM protocols in OSI layers 2-7. In the case described below, the link will terminate at an AOM in the OMC. Whatever type of equipment exists at the OMC, an address (NTN) must exist there so that a path can be established to it from the IOG 20 at the exchange. The same is true in the opposite direction. As stated earlier, traffic over X.25 data links is either switched through the data network - analysis of the destination NTN being used to route and set up a path through the net - or sent via a dedicated line, using the destination NTN to directly point out the required Network Port in the home switch. In the case described below, the port defined will be for a data link of the dedicated line type. This method requires that the NTN assigned to the Network Port in the home IOG is the destination NTN. This is done using command ILTEI.

R1B

175

AXE IO System, IOG 20

In our case, the destination is the Session Port for Message Transfer Protocol (MTP) at the OMC. Each Session Port in a network is given its own NTN. In IOG 20 this is done by use of the command ILSPI. At the destination AOM it would be defined using an AOM command.

Session port MTP NTN=250

Computer NTN=150

IOG20

ROT=1

ROT=2 Routing in IOG20: ND=15,RC=1 ROT=1 ROT=2

AMTP-n

Figure 8.14

Addressing in data network

For traffic in the opposite direction, it follows that, at the OMC, the Network Port for the data link must be assigned the NTN of the MTP Session Port at the home IOG. The port defined below is a port in the home IOG. It will be a low speed link: 19200 bit/s. The port is a single link port, SLP. A corresponding Network Port must be defined in the DTE at the OMC, using AOM commands. Several OPIs exist for connection of data links to an IOG 20. The connection below is performed in accordance with the OPI OMC Using Message Transfer Protocol, Connect

8.10.1

Line Unit Status


<IMLCT:SPG=spg; :ILLUP:LU=ALL;

If the LU required is not defined, define it.

8.10.2

Define the Port


Command example:

176

R1B

DCS Applications

:ILSLI:NP=np,RATE=rate,PROT=X25/V36;

The port is defined using protocol X.25 and interface V.36.


:ILNPP:NP=np,DETAIL; :ILSLC:NP=np,TC=1-64;

All channels are defined as two-way channels. X.25 data links contain many separate channels where each user is given its own channel. TC: Interval range for the number of two way logical channels - i.e. separate communication channels - in the link. Maximum 4095 separate channels can exist in the one link.

8.10.3

Test the port


The physical port is now tested.
:ILLTI:PORT=pp,LOOP=1;

8.10.4

Network Terminal Number


As no switching to the destination exists in this case, the next step is to assign the NTN of the destination (SP for MTP) to the Network Port. For this example, assume this value is 150.
:ILTEI:NTN=150,NP=np;

(Note: the actual value of the destination NTN, if unknown, must be obtained from the staff at the OMC.) This example is using a dedicated line, not via routing data.

8.10.5

Deblock the Port


:ILBLE:NP=np;

8.10.6

Define the MTP Session Port


In this example, this NTN in the home IOG is assumed to be 250 as in Figure 8.14. Check if the Session Port for MTP in home IOG is defined.
:ILSPP; :ILSPI:SP=MTP,NTN=250;

The Network Port for the data link at the destination would now be assigned this value using the relevant AOM command. The next step depends on whether the data link is to be used for alphanumeric communication, file transfer or Direct File Output. The first two cases are covered here. For the case Direct File Output see the corresponding OPI.

R1B

177

AXE IO System, IOG 20

8.10.7

Data Link used for Alphanumeric Communication:


(Compare the definition of a port for alphanumeric devices described above.)

8.10.8

Assign Terminal Identity to the Port


The IO device associated with the port is defined. Here, the IO device is of type AMTP as it is an X.25 data link accessing MTP protocol with alphanumeric information. (AMTP - Alphanumeric communication using MTP.) The command links the IO device to the Network Ports NTN.
:MCDVI:IO=AMTP-n,NTN=150; :END;

8.10.9

Size Alteration Events


<SAAEP:SAE=344;

If necessary, increase the size:


<SAAII:SAE=344,NI=ni;

8.10.10

Define the IO device data in the CP


<IOIOI:IO=AMTP-n;

8.10.11

Route alarm status information and heart beat to OMC


The system alarm status printout (category 47) is sent to inform the OMC about alarm status and operator attendance at the exchange. Heart beat printouts, with category 35, are sent to the OMC from the CP to indicate that the CP is functioning normally. In the command IOROL, IO is the data link, AMTP. DTYPE=FIRST and NOSYST must be used. This implies that no standby nor system standby device (AT, AMTP or AF) may be used for alarm status and heart beat signals.
<IOROL:PRCA=35&47,IO=AMTP-n,DTYPE=FIRST,NOSYST, CLASSA=0&1,CLASSUA=0&1; <IOROI:PRCA=35&47;

8.10.12

Data Link used for File Transfer


If the data link is to be used for file transfer then the IO device commands given above (i.e. Data Link used for Alpha Communication) beginning with command MCDVI are not required. After the command ILSPI the sequence is as follows: Initiate the Destination-Remote NTN relationship for the port The destination must be connected to the NTN for the remote user (here MTP) accessed via the data link.
<IMCLT:SPG=spg; :ILDNI:DEST=dest,NTN=150;

178

R1B

DCS Applications

Using destination name (DEST) to get the destination NTN, the file is then - in our example - sent on a dedicated line directly to the OMC from a port having the same NTN as the destination. If the destination AOM was to be reached by routing through the network the following routing data would have to be defined as follows. The NP in the home IOG is NP=1-2-2-1. Define route:
<IMLCT:SPG=0; :ILROI:NP=1-2-2-1,ROT=1;

Define routing case:


:ILRCI:ROT=1,RC=1;

Define Number Direction for Routing Case:


:ILRAI:ND=15,RC=1;

The file would now be routed through the network to destination in the ILDNI command.

8.11 Chapter Summary


The main functions in DCS are the terminal, data link and the CPT link
communication

The basic concepts in DCS are the Ports, the Line Units, the Line Module and the Communication Module

Four ports can be connected to a LUM board The LU can be defined as Single or Twin Line Unit The recommendations of the OSI Reference Model are followed The following interface standards are supported in IOG 20: V.24/V.28, V.25bis/V.28, V.35, V.36, X.21, G.703 E0, and G.703E1

The maximum speed for data transfer via Data Link is 2Mbit/s The main Network Services are: Permanent/Hot Virtual Circuits and
Direct Call, Addressing, Routing and Access/Priority

R1B

179

AXE IO System, IOG 20

180

R1B

9. Support Processor Subsystem (SPS)

Chapter Objectives
After completing this chapter the student will: Know the hardware units included in SPS
Figure 9.1

Chapter Objectives

9.1 Introduction
This chapter describes functions in the support processor subsystem.

9.2 General
SPS is central to the work of the IOG in that SPS software implements the program control of the Support Processor, the SP-CP communication function and nearly all the maintenance functions for the SPG. SPS has been looked at briefly in chapter two and three where the hardware of the subsystem was described. In this chapter the above mentioned software functions of SPS will be looked at in some detail. A brief recap of chapter two is given first. SPS consists of:

the SPs with their operating system software software and hardware for SP-CP communication software and hardware for inter-node communication software for the SP function change and backup software for maintenance of the nodes and links software for SP operation functions

9.3 The Hardware of SPS


The hardware consists of the CPU60, and the RPV or RPV2. The CPU60 implements the support processor. It is built of the CPU60 board. The board contains, among other things, a MC68060 processor, 32 MB of DRAM, a boot PROM and interface circuits.

R1B

181

AXE IO System, IOG 20

At loading or reloading of an SP, the PROM-stored boot strap program (called Bootstrap) is used to initiate loading of the SP operating system and software into the primary memory of the SP from the hard disk. The RPV, or RPV2, is the interface unit between the RP bus and the SP. It contains a microprocessor, primary memory and boot software stored in a PROM. The software for the RPV, or RPV2, is stored on hard disk and read to the RPV/RPV2 at power on. The RPV is implemented in the boards PROVME and DRPBU. The RPV2 is implemented in board RPV2. The main function of the RPV is to send and receive RP signals to and from the CP and SP. CP-SP signalling will be looked at in chapter 10, CP-SP Communication.

9.4 The Software Functions of SPS


The SPS software is situated in both the CP, SP and RPV/RPV2. In the SP the software of SPS and the other subsystems consists of a series of EriPascal modules. The modules are often grouped into function blocks. The software in the RPV/RP2 is written in C. The SPS software functions are listed below:

system kernel (system executive) SP hardware administration loading function node communication SP statistics CP-SP communication maintenance functions SPS event log SP exchange data administration SP function change and SP software module handling SP trace system SP hardware administration SP restart log SP system parameter Handling SP co-processor dump

The system kernel administers the program execution in the SP. The tasks of this function include supervision of signals between the different processes contained in the program modules, time supervision for sending periodic signals, and administration of the primary memory.

182

R1B

Support Processor Subsystem (SPS)

Loading of SP modules from hard disk, starting of the software system and restarts of SP software are also handled by the system executive. The kernel is part of the EriOS. SP HW administration administers devices connected to the SP such as hard disks, flexible disks, etc. Before an application program (e.g. in CHS) can perform any operations reading/writing on hard disk - the device administrator must be informed. (Note that alphanumeric devices and data links are handled by subsystems MCS and DCS). Loading function is a complement to the PROM-stored bootstrap and the loading function in the system kernel mentioned above. Briefly, it allows modules to be designated as external so that they are only loaded from HD to the primary memory when required. The loading function is a part of EriOS. Node communication is the function that supports the distribution of the control system into two separate SPs (node A and B). It allows application software functions to be partly located in one node, partly in the other, or to be wholly located in both nodes. The application processes can communicate via the Inter Computer Bus, ICB. This function is implemented in both HW (on CPU60) and SW in function block ENCS, Ethernet Network Communication System. CP-SP communication will be covered separately in chapter 12. SP statistics, Maintenance functions and SPS event log will be covered separately in chapter 13. SP exchange data administration, SP function change and SP software module handling (including SP Backup) will be covered separately in chapter 14. The remaining functions are covered below.

9.5 SP Hardware Administration


9.5.1 General
The SP hardware administration function keeps a list of some of the hardware installed in an SPG. This information is required by the HW driver programs for operation and maintenance of each node.

9.5.2

The SP Hardware Table


The SP Hardware Table contains data for the hardware configuration in the node. There is one table for each node. Example of an SP hardware table:
:IMHWP:NODE=A;

R1B

183

AXE IO System, IOG 20

SP HARDWARE DATA SPG 0 NODE A NAME ADDR ACIA 25 BNA DISK_SC DISK_SC CONFIGURATIO MEMORY SCSI FDC FDI FDIADM EBA_VSA DESCR SPARE INDEX STD **** 1 00FA **** 1 **** 1 **** 4 **** 1 WSU **** 1 **** 3 **** 1 **** 1 **** 1 **** 1 UFIELD T..113 -----H31001 O14001 IOG20 32 5 1 11F 1 1 1

UNIT VD-1 NA-1 HD-1 OD-1 CONFIG-1 WSU-1 SCSI-1 FD-1 FDI-1 FDIADM-1 VSA-1 END

The hardware table is loaded to the primary memory when the modules are loaded from PROG_A or PROG_B at node reload. The hardware driver programs in each node read the data in the table at each reload to find out which, and how many, hardware units they have to drive. The information in the hardware table is of special use to the driver programs during diagnostics and repair checks, when carrying out orders for hardware tests. This will be covered in chapter 13 in the section on SP diagnostics. The hardware table may need to be changed from time to time, as and when units are added to, or removed from, the node. This has to be done by operator command. Each time a change has been made in the hardware table, the node has to be reloaded to get the new table into the primary memory. The data in the hardware table for each unit is fairly complex and this leads to an unusually complex command format. Therefore, to simplify the handling of the table, a set of default data is already defined for each unit. Thus, when making changes in the hardware table, only the name of the unit has to be given. The rest of the data is fetched from the default data. The default data is stored in a second table: the SP Hardware Default Table.

9.5.3

SP Hardware Default Table


This table is created from the data in the module SPHWTABLE by the module SPHWADM the first time it receives one of the HW administration commands. The default table is then stored in the volume OMFZLIBORD.

184

R1B

Support Processor Subsystem (SPS)

Hard disk A-node

Command IMHWP Volume PROG_A Volume OMFZLIBORD

Default SP HW table

SP HW table

SP HW table

Primary memory A-node Executing SP HW table

Commands IMHWI, IMHWC

Figure 9.2

SP hardware table

At start up of an SPG, the hardware tables for each node and the default table are thus identical. Those units that are not included in the actual nodes must be removed from the hardware tables. Thus in a working IOG20, the default table has the same format as the hardware tables, but normally contains data about more units than those found in the hardware tables. It contains default information for all possible units in the IOG20. Default SP hardware data:
SP HARDWARE DATA SPG 0 NODE A NAME ADDR ACIA 25 BNA DISK_SC DISK_SC DISK_SC DISK_SC CONFIGURATIO MEMORY SCSI FDC DESCR SPARE INDEX STD **** 1 00FA **** 1 **** 1 **** 1 **** 1 **** 4 **** 1 WSU **** 1 **** 3 **** 1 UFIELD T..113 -----H31001 H31002 H31003 O14001 IOG20 32 5 1 11F
185

UNIT VD-1 NA-1 HD-1 HD-2 HD-3 OD-1 CONFIG-1 WSU-1 SCSI-1 FD-1
R1B

AXE IO System, IOG 20

FDI-1 FDI FDIADM-1 FDIADM VSA-1 EBA_VSA END

**** **** ****

1 1 1

1 1 1

A simple printout of the hardware connected is obtained in the IO UNIT MODES printout from command INIOP. The printout lists the units in the node an their status (parameter OPMODE). The status may be READY or BLOCKED. The status is controlled automatically by the system or by commands BLSUI and BLSUE. IO units:
:INIOP:NODE=A; IO UNIT MODES SPG 0 NODE A A A A A A END UNIT VD-1 RPV-1 HD-1 NA-1 FD-1 OD-1 OPMODE READY READY READY READY READY READY

9.5.4

Operation
When the SPG is started, the hardware table must first be changed to match the actual configuration. All changes in the hardware and hardware default tables are made by commands. The procedures to be used are given in the OPI: Hardware in SP, Administration. The commands used are fully allocated in the SP and are assigned to the path building command IMLCT. To remove a hardware unit, e.g. OD-1, then the command IMHWR is used:
:IMHWR:NODE=B,UNIT=OD-1;

At a later stage it may be decided to add HD-3 to each node. Data for these must be added to the hardware table for each node. To add a new hardware unit or units, e.g. HD-3, the command IMHWI is used:
:IMHWI:NODE=A,UNIT=HD-3;

After the command IMHWI a reload must be initiated in the influenced node.

186

R1B

Support Processor Subsystem (SPS)

To print the data defined in the hardware table for a given node, the command IMHWP is used:
:IMHWP:NODE=A;

This gives the printout SP HARDWARE DATA, see Figure 9.2 for an example. It may happen that a new unit that does not have any data defined in the module SPHWADM has to be added to the SPG. This means that no data for the unit exists in the hardware default table. The command IMHWI cannot be used alone in this case. If given, the command will result in a fault code and printout UNIT NOT DEFINED. This means that the unit has to be defined first in the default table. To define a unit in the default table the command IMHWL is used. The definition is rather complex because of the nature of the data. However, it should be remembered that this command is only given very rarely, and if the command is needed the parameters would be supplied to site by Ericsson together with the hardware unit(s). After the command IMHWL has been given successfully, the command IMHWI can then be given. A more likely case than the above is the case of the default data for a unit being incorrect and having to be changed, or when a unit is replaced by a unit with different data. Changes to the data in the default table are made by the command IMHWC. The parameters are the same as for the command IMHWL and would be supplied by Ericsson. An example is given below:
: IMHWC:NODE=A,UNIT=HD-3,NAME="DISK_SC", UFIELD="H31001",INDEX=3;

Here, the default data for HD-3 has been changed. An explanation of the parameters is given in the command descriptions and the adaptation direction in the B-module. The adaptation direction is a key document when defining the SP Hardware table.

9.5.5

Implementation
The function is handled by the function block SPHWADM which consists of two modules: SPHWADM and SPHWTABLE. The module SPHWADM administers the function. The module SPHWTABLE contains a table called the SP Hardware Table. This table thus exists in the primary memory and in the volumes PROG_A and PROG_B on the hard disks. The module SPHWTABLE also contains an interface that enables reading and writing in the table on hard disk. The files SPHWADAPT0 and SPHWUNITS0 in volume OMFZLIBORD are used to store the SP hardware table in SPG0. The last character in the file name identifies the SPG.

R1B

187

AXE IO System, IOG 20

9.6 Chapter Summary


The hardware in SPS consists of the CPU60 and RPV or RPV2. Some of the main SPS software functions are: system kernel, loading
administration, node and CP-SP communication, maintenance functions, SPS event log, SP exchange data administration, etc.

The SP Hardware Administration function keeps a list of the hardware


installed in a SPG.

The SP Hardware Table contains data of the hardware configuration in


the node.

The SP Hardware Default Table is created automatically by


SPHWADM the first time it receives one of the hardware administration commands, and is stored in volume OMFZLIBORD.

At start-up of an SPG, the hardware tables for each node and the default
table are identical.

188

R1B

10.Start of SPG

Chapter Objectives
After completing this chapter the student will: List the different parts of the software package required at startup of an SPG Carry out a cold start of an SPG using OPI SPG, Start
Figure 10.1

Chapter Objectives

10.1 Introduction
This chapter describes the procedure and functions of the initial startup of the AXE IO system.

10.2 General
Once all hardware has been installed in the exchange and the cabling connected and tested then the first step in starting up the exchange is the starting of the IOG20. Once this is running then the APZ can be started using the functions of the IOG. Starting an IOG20 implies starting up the nodes of each SPG in the IOG. Note: Start of an SPG involves function change procedures. This chapter has been written to be sufficient for an understanding of function change at start up of an SPG. Function change is covered in more detail in chapter 14. Starting up a node can be divided into two phases:

the SP initiation phase, where the hard disks are formatted, the volumes
defined and SP exchange data files are loaded to hard disk.

the function change phase, where the SP, RPV and LUM software is
loaded to the volumes PROG_A/B and a system is created and installed. Starting IOG20 from scratch is often called cold start. Cold start of IOG20 normally only takes place during the installation of an AXE exchange. It is extremely rare that a new cold start must be made because of a fault once the IOG is in operation. This is because of the duplication of the SPs and the fact that the software of each SP is stored on

R1B

189

AXE IO System, IOG 20

the hard disks and can be manually reloaded by command SYRSI or by using the reset button on the CPU60 board. However, it may happen during operation that both the nodes of an SPG must be started again for some reason, e.g. because of a change in the number of hard disks. This would mean a reconfiguration of the hard disks, thus requiring a new start up of each node in turn. This is called reinitialisation of the hard disks. Unlike the case of a cold start, one node the executive, is always working. Starting both nodes in turn when the exchange is in traffic is a more complicated process than a cold start, as the nodes cannot run in parallel until they have both been reconfigured and started. In this case the standby node must be started first and as the nodes have different hard disk configurations no updating from the executive node to the newly started node can take place. Thus all relevant charging data must be dumped from hard disk to OD or sent over a data link, and a conversion of the CP backup file to OD or diskette should be made, just before the newly started node is switched to executive by command. The information previously dumped, charging data and CP backup, is then copied back to the new executive node. The previous executive node (presently standby) can then be reconfigured and started and when it is deblocked a long updating of its disks will take place from the new executive node. A simpler case to handle is the case of a hardware fault in one of the hard disks. This would mean that a disk in just one node has to be reinitialised. The amount of work required for this job would depend on whether or not the faulty disk contained the SP software, i.e. volumes PROG_A/B and OMFZLIBORD. If the disk contained these volumes - normally HD-1 - then the node would have to be started up, i.e. SP initiation and the function change would have to be performed. If not, then it would be sufficient to just format the new hard disk and define the required volumes, i.e no function change would be required. On deblocking of the node the contents of any duplicated volumes would be transferred from the executive node during the updating phase. Start up of an SPG, both in the installation phase and in the operational phase of an IOG20, it is covered in the OPI SPG, START .

10.3 Start System


There are two types of systems that can execute in a IOG20 node.

large, or ordinary, SP system start system

190

R1B

Start of SPG

The ordinary SP System is the system that executes in normal operation. The ordinary SP system always stored on hard disk and reloaded from there. The Start System is used only during startup or during hard disk reinitialization and recovery of IO system stoppage, as described above. The start system is a small system that contains only a limited set of functions. Start systems are never stored on hard disk but reloaded directly from diskette or opto disk. One start system usually fits on two diskettes or one 3 .5 OD. Functions in start system:

Node communication (ICB) File system SP function change SPHWTABLE

Functions not in start system:

DCS MCS (except a small part) CP-SP communication SPHWADM SP Exchange data administration (except a small part which supports the command SYSBT) FPU Infinite files SP backup SP restart logging SPS event log SP system parameter handling

This means that in an IOG with the start system loaded there is no communication via the network ports on the LUM boards. The only working terminals are the ones connected to the CPU port (board CPU60). There is no CP-SP communication. Note that the SP function change in an ordinary system and in the start system differs slightly.

10.4 Requirements
The requirements for starting up the IOG once the hardware is installed are as follows:

a work order containing data about the volumes that are to be created on

R1B

191

AXE IO System, IOG 20

the hard disks

the software package for the IOG an asynchronous terminal set for 4800 bit rate connected to the CPU
board of node A in the SPG that is to be started. If a single node is to be started then the terminal shall be connected to this node. Such a terminal is called a local terminal. The terminal is connected on the front of CPU60 board. There are two ports with the same function. The software package for IOG20 consists of a number of diskettes or opto disk(s), as follows:

One or two diskettes, or one OD, labelled STARTSn. If there are two
diskettes they will be labelled STARTSn_BOOT and STARTSn_FILE, where n is the version of the STARTS diskette.

A diskette, or OD, labelled SP_INITD_n containing the SP exchange


data for the SPG. The destination volume for the data is given on the disk label.

A number of diskettes, or one OD, labelled TRANSP_n containing the


program modules and system description file for the SP system (the large system). This includes the LUM and RPV/RPV2 software. Here, n is the sequence number in which the disks are to be loaded. The software is loaded into the volumes PROG_A and PROG_B. Note: The SP exchange data and the program modules are stored on one OD while the start system on another.

10.5 Procedure
As mentioned earlier the procedure differs slightly depending on whether a cold start of the SPG is to be performed at installation, OPI SPG, START , or whether one or both nodes are to be started singly during operation, as described above. The latter case is described in the OPI SPG In Single Node, Start. A summary is given below for the second case, where one node is started. In the summary, node B is working as executive and node A has to be started after the replacement of the hard disk containing the SP software. The local terminal is first connected to the CPU60 board in the node to be started and set for TTY (teletype) mode and capital letters. After inserting the disk STARTSn in FD-1, or OD-1, for the node, the reset switch is flicked twice. A loading program called Bootstrap, on a PROM on the CPU60 board, then reads the bootblock from the FD/OD to SP primary memory. The bootblock is a small area on the STARTSn disk reserved for the information containing a pointer to the so called System Start Information, SSI, file on the disk.

192

R1B

Start of SPG

The SSI contains the disk addresses (tracks and sectors) of the modules that are to be loaded. Using this information the bootstrap program loads the modules of the start system into the SPs primary memory. After a successful loading from STARTSn diskette or OD a message will be received saying that the bootblock has been read from Index 01 or 02 respectively. A restart of the node will take place after a few minutes and the printout SP INITIAL SYSTEM RESTARTED will be obtained. The communication is started by entering a CTRL-E character from the local terminal. The loaded software allows commands to be given for:

entering SP initiation mode, formatting the hard disks, preparing the


system defined volumes on the hard disk and loading the SP exchange data to these volumes

performing the required function change in SP, i.e. loading the SP software to the relevant volumes on hard disk and creating the required system that will be installed and loaded to the SP The command ISMCT is given to enter SP initiation mode. ISMCT is a path building command to the own SP. Its purpose is to stop the following "dangerous" commands from being used by mistake: ISMCT must be given first to start an initiating procedure. In SP initiation mode commands are given for:

formatting or reformatting the hard disk(s). There is no need to specify


faulty sectors manually. Command ISMEI.

creating the volumes according to the work order. Command ISVOI.


Note: Creation of the volumes and the subsequent work can be done when local terminal is in Buffer mode. If contact is lost in Buffer mode, return to TTY and enter semicolon and ENTER. Then return to Buffer mode. The command END is used to exit initiation mode. The SP_INITD_n disk is now inserted in FD-1 or OD-1 and the command SYSBT is given to load the SP Exchange Data files on the OMFZLIBORD volume. Note: The above step is only really required when starting both nodes. If only one node is to be started, then these files will be copied from the duplicated volume when the node is deblocked. The next step is to perform the function change in the SP, i.e. loading of the SP modules and creation and installation of the system. The function change at cold start or start of one node differs somewhat from a normal function change (as it is described in chapter 14). During normal function change, the CP is normally working and the SPG must be fault free - we have a so called large, or ordinary, system. At cold start the start system is used.
R1B 193

AXE IO System, IOG 20

A short description of each function change command is given below as applicable to the start of an SPG, i.e. a function change in a start system: The function change is started with the command FCSPI.
<FCSPI;

The node or nodes that are to be loaded with the software are defined next. Command FCSLS. In this command, the parameter LNODE (local node) applies to the command FCSII which is given later. LNODE is used to say in which nodes hard disks the so called System Start Information (SSI) file is to be created by FCSII. (The SSI contains the disk addresses of the modules to be loaded and is used for loading the node from its own hard disk). The parameters RNODE (remote node) and RSNODE (remote source node) apply to the command FCSRI, given later, which creates the two remote installation files (RIF & SSR) for each node. The files are stored on hard disk in RSNODE. RNODE is the remote node that is to be loaded and RSNODE is the node that loads the remote node. In our case, only one node will later be loaded, node A, and this node must be able to load node B if required, so the command would be written as:
<FCSLS:LNODE=A,RNODE=B,RSNODE=A;

The next step is to transfer all the software modules from the transport media (one optical disk or several diskettes TRANSP_n) to the program volume, in this case PROG_A. Command FCSSL. The disks are inserted and loaded from FD-1 or OD-1 to destination volume by the command. The diskettes do not have to be loaded in numerical order, but this is advisable as it is obviously very important to load all the TRANSP_n diskettes. Command example:
<FCSSL:IO=OD-1,IONODE=A;

The TRANSP_01 disk is now inserted again in FD-1 to enable the System Description File (SDF) to be loaded to the SPs primary memory. Command FCSDL. The SDF lists the modules with revision status that are included in the system. It also describes how each module is to be loaded from HD to the SP (i.e. boot-loaded by the PROM Bootstrap or file-loaded by FMS software once this has been booted). In normal IOG20 applications the modules are boot-loaded. In applications containing extra software - e.g. Remote Measurement Subsystem and Statistics Subsystem - then the extra modules may possibly be file-loaded. Normally all modules are boot-loaded.

194

R1B

Start of SPG

The System Description File also sets values for the deferred constants in the programs. Command example:
<FCSDL:IO=OD-1,IONODE=A;

The TRANSP_01 diskette is then removed from FD-1 or OD-1. The System File (.SYS) is created next. Command FCSSI. This file is created using the SDF, but it also contains the FMS addresses (i.e. volumes and files) of the program modules on the hard disk. Thus information for both boot loading and file loading is contained in the system file. It takes about 10 minutes to create the system (.SYS) file, which is then stored in PROG_A in our case. Command example:
<FCSSI;

The next step is to create the Remote Installation Files (RIF and SSR) for the node. These files are normally created by FCSSI, but in a small system they have to be created separately. Command FCSRI. These files are to allow a node (here called remote source) to reload the other node (here called remote) when the latter is unable to reload from its own hard disk. The loading is then via the Inter Computer Bus (ICB). The remote and remote source nodes are not defined by FCSRI as this command has no parameters. The remote and remote source nodes are the nodes defined earlier by the parameters RNODE and RSNODE respectively in the command FCSLS. The remote node will request the remote source node to load it and thus this node must contain information saying which system is to be loaded to the remote node. When RIF is asked by the remote node to be loaded, it uses that nodes designation to determine which system is to be used. The system name corresponds to a file name that is used as an address to SSR. SSR is, in effect, the required SSI for the remote node, and can thus be used to load that node. Thus each node contains an SSI for loading its own system and an SSR for loading the remote nodes system. The systems are normally the same, of course, in both nodes, but do not have to be. The remote installation files take about 10 minutes to create. They are stored in PROG_A in our case. Command example:
<FCSRI;

The next step is to install the system. Again, installation of a system during function change would normally be done by the command FCSSI, but in a small system has to be performed separately. Command FCSII.

R1B

195

AXE IO System, IOG 20

Installing the system implies creating the SSI and storing the address to this file in the bootblock area on hard disk in the node(s) specified earlier by parameter LNODE in command FCSLS - node A in our case. The SSI is needed for all types of reloading, manual or automatic. It contains the absolute addresses (tracks and sectors) of the modules in the system. When the system is later manually loaded using the reset switch, the loading is similar to that of loading the STARTSn diskette mentioned earlier. The PROM-ed Bootstrap reads the bootblock from Index xx, i.e. from the PROG_A or PROG_B volumes, and this gives the address to the SSI. The SSI in its turn gives the absolute addresses to the program modules on the hard disk so that these can be loaded to the SP. It takes about 5 minutes to install the system. The SSI file is stored in PROG_A in our case.
<FCSII;

The function change is now ended using command FCSPE.


<FCSPE;

Once the function change is complete then the software contained in the newly installed system is reloaded to the SP by flicking the reset switch twice. The local terminal connection can now be removed if required. The node status can now be checked by the normal command IMCSP. The entry command IMMCT must be used first. Before giving the commands from a local terminal press carriage return to gain contact with the system. (The same commands can now be given from any other AT connected to the IOG). The standby node status should now be SB - ISOLATED/BLOCKED The next step would be to deblock the node so that it will be updated from the executive node.
<BLSNE:SPG=spg,NODE=standby;

During the deblocking the node states will be reloading, diagnosing, updating, reloaded and normal. During the updating phase all files in the duplicated volumes will be copied over from the executive node. It should be noted that the updating must be a large update to transfer over all the contents of the duplicated volumes from the executive to standby node.

10.6 Cold Start or Single Start of Both Nodes


Whenever both nodes are started, all files belonging to the duplicated volume OMFZLIBORD are loaded from one of the SP_INITD_n diskettes or from the OD. Other files are later created in this volume by the SP pro-

196

R1B

Start of SPG

grams as and when required. (An example is the list of file attributes defined by INFII). In the case of starting just one node as described above, all files belonging to the other duplicated volumes are created during the updating of the node from the executive node. In the case of a cold start of an SPG, or when starting both the nodes singly (reinitialisation of the hard disks in both nodes), all files belonging to the other duplicated volumes - e.g. the CP backup files - must be defined by the operation staff. This can be done using a command file or by direct use of the command INFII. Some comments on these cases are given below: As the CP is normally not running at a cold start of an SPG, then the command INFII and its entry command will have to be entered from the local terminal or an AT using local mode. The attributes of the defined files will in this case be written directly on the relevant hard disks of both nodes. Once the CP is started the file attributes are copied to the CPs file table at the CP system restart. Data about each defined file is thus stored both in the CP software and on hard disk. If the CP is running during reinitialisation of the disks in both nodes, then the files would be defined in the first node to be started before this is switched to executive. On starting the second node the files would be copied over from the executive node during updating. If the CP is running, files should always be defined from an alphanumeric terminal connected to a LUM board. In this way the file attributes are written directly on the disks and in the CP data. The command INFUI can always be used to adjust the CPs file table so that it corresponds to the file attributes defined on hard disk. This command is always performed automatically at a system restart of the CP.

10.7 Command Initiated Restart of Node


A restart or a reload of a node can be performed by the command SYRSI. (It is always better to perform restarts/reloads by command instead of using the reset switch).
<SYRSI:SPG=spg,NODE=node,RANK=SMALL;

or
<SYRSI:SPG=spg,NODE=node,RANK=RELOAD;

The above command can also be used to switch nodes in a parallel working system by ordering the restart in the executive node. If a switch is desired the command IMEXS is however better. This will cause a node switch followed by the restart in the new standby node.

R1B

197

AXE IO System, IOG 20

10.8 Chapter Summary


Starting up a node can be divided into the SP Initiation phase and the
Function Change phase

In the SP Initiation phase, the hard disks are formattted, the volumes are
defined and SP Exchange data files are loaded.

In the Function Change phase, the SP, RPV and LUM software are
loaded to the volumes PROG_A/B and a system is created and installed.

There are two types of systems that can execute in a IOG20 node. The
large or ordinary SP System and the small or Start System.

The ordinary SP System is the system that executes in normal operation The Start System is used only during start up or during recovery of IO
system stoppage.

The Start System contains only a limited set of functions. The Start System is not stored on the hard disk but is reloaded directly
from opto disk oe diskettes.

The System Discription File (.SDF) lists the modules with their revision status that are included in the system.

The System File (.SYS) contains the same information as the SDF but it
also contains the FMS addresses of the program modules on the hard disk.

198

R1B

Ericsson Telecom AB MV/ETX/X/HCX S-126 25 Stockholm, Sweden Telephone: +46 8 719 9222

EN/LZT 101 1611 R1C Ericsson Telecom AB

Subject to alterations without prior notice. Printed in Sweden.