1.InputOutput Group 20, IOG 20

AXE System Testing 1Input/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

1

Table of Contents

1. Introduction to AXE IO System 51.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 SP-based IO Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Input/Output Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 HW components of an IOG 20 IO system . . . . . . . . . . . . . . . . . . . 71.5 IO Device Functions and Characteristics. . . . . . . . . . . . . . . . . . . 131.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2. Subsystems in the AXE IO System 172.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Subsystems in SP-based IO Systems . . . . . . . . . . . . . . . . . . . . . 172.3 Support Processor Subsystem (SPS) . . . . . . . . . . . . . . . . . . . . . 182.4 Man-machine Communication Subsystem (MCS). . . . . . . . . . . . 202.5 File Management Subsystem (FMS) . . . . . . . . . . . . . . . . . . . . . . 222.6 Data Communication Subsystem, DCS. . . . . . . . . . . . . . . . . . . . 232.7 The Software Structure of the IO Subsystems. . . . . . . . . . . . . . . 272.8 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3. Hardware Structure 313.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 Hardware structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Hardware configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Subracks and boards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.5 LED’s and Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4. FMS applications 434.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 FMS Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3 Storage medium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4 Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6 File attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

IOG 20

2

4.7 Operation of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.8 The duplicated file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.9 Corrupt Files and File Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.10 File protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.11 Infinite Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.12 File Process Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.13 Decompression of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.14 Command Log in AXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.15 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5. System Backup Handling 855.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2 Backup Functions of the CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.3 Command Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.4 Backup of the SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6. MCS applications 1076.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.2 The functions of MCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.3 Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096.4 Routing of Printouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.5 Standby Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.6 Device Attendance Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.7 Alphanumeric Information on File . . . . . . . . . . . . . . . . . . . . . . . 1276.8 MCS directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306.9 The MCS Transaction Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

6.10 Command file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.11 IO device load regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396.12 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7. MCS - Command handling 1417.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417.2 AXE Command Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417.3 Entry Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437.4 Subcommands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457.5 Local Mode and CPT Commands . . . . . . . . . . . . . . . . . . . . . . . 1467.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Table of Contents

3

8. DCS Applications 1498.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498.2 General on Data Communication . . . . . . . . . . . . . . . . . . . . . . . 1498.3 The OSI Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508.4 General on DCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528.5 DCS concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538.6 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608.7 Network Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638.8 Connection of DCS ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708.9 Definition of Port for AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

8.10 Definition of Port for X.25 Data Link . . . . . . . . . . . . . . . . . . . . . 1758.11 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

9. Support Processor Subsystem (SPS) 1819.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819.3 The Hardware of SPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819.4 The Software Functions of SPS. . . . . . . . . . . . . . . . . . . . . . . . . 1829.5 SP Hardware Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

10. Start of SPG 18910.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18910.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18910.3 Start System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19010.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19110.5 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19210.6 Cold Start or Single Start of Both Nodes . . . . . . . . . . . . . . . . . . 19610.7 Command Initiated Restart of Node . . . . . . . . . . . . . . . . . . . . . 19710.8 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

IOG 20

4

R1B 5

1. Introduction to AXE IO System

Figure 1.1Chapter Objectives

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

1.2 SP-based IO SystemsThis book provides a description of SP-based IO Systems as suited to the work of AXE system technicians. SP is an abbreviation for Support Proc-essor, 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 B-P, 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 com-pact size version.

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

AXE IO System, IOG 20

6 R1B

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.

Introduction to AXE IO System

R1B 7

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 asyn-chronous 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 print-outs 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 systemThe 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.)


8 R1B

Figure 1.2Example 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 inter-face.

AMTP

CP

DL DL

ICB

RPV/RPV2

SP

HD

OD

ALI

OD

HD

RPV/RPV2

SP

FD FD

HD HD

RP-bus

AlarmpaneI

Externalalarm

AT AT

AT, printer


R1B 9

Figure 1.3IOG 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.

CP

DL DL

ICB

RPV/RPV2

SP

HD

OD

ALI

OD

HD

RPV/RPV2

SP

FD FD

HD HD

RP-bus

AT

AMTP

AT

AT, printer

Ethernet

SCSI-2

VME bus

RP bus

VSA

VSA - VME to SCSI-2 adapter

PC/AT


10 R1B

Figure 1.4Interface between RP-bus and internal IOG bus

The RPV converts from a parallel RP bus interface while the RPV2 con-verts 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 micro-processor. 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 SP’s.

C PR P V V M E b u s S P

C PR P V 2 V M E b u s S P

P a ra lle l R Pb u s

S e r ia l R P b u s


R1B 11

Figure 1.5Support Processor Group, SPG

The two SP’s in an IOG are connected by the Inter Computer Bus, ICB. The ICB allows data to be transferred between the two SP’s. It is an Ether-net 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 desig-nated 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 Alphanumeric Terminal

AMTP Alphanumeric terminal over Ericsson MTP

ALI Alarm Interface

HD Hard Disk

FD Flexible Disk

DL Data Link

OD Optical Disk

An IOG 20 as described above - with two SP’s (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 SP’s (or nodes).

RP bus

ICB

SPG

CP

Node Node


12 R1B

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.

Figure 1.6Multi SPG configuration

It is possible to connect up to four SPG’s 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 SPG’s.

SPG 1, SPG 2, and SPG 3 provide basically separate processors for han-dling such data. They thus relieve the workload of the SP’s 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 Measure-ment 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.

SPG-0 SPG-1 SPG-2

ICB

SPG-3

RPB-A

CP

Node

RPB-B

ICBICBICB

Node

NodeNode Node Node

NodeNode


R1B 13

In SPG 0, the link at Node A is designated Link 0 and at Node B is desig-nated Link 1.

In SPG 0, Link 0 has RP address RP-1, Link 1 has RP address RP-4.

In the other SPG’s the corresponding designations are:

SPG 1 Link 0 (RP-5) and Link 1 (RP-6)

SPG 2 Link 0 (RP-7) and Link 1 (RP-8)

SPG 3 Link 0 (RP-9) and Link 1 (RP-10).

Note: the reason for allocating RP addresses 1 and 4 to SPG 0 is the fol-lowing: 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 allo-cated 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 CharacteristicsThe 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 com-munication. The AT’s 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 GSMmobile telephony network it may be connectedas 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 net-work (X.25).


14 R1B

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 com-municates 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 ‘com-mands’ 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 alarm printer (operation)

AT-1 connected to the alarm interface, ALI

AT-4 normal AT for use once the IOG has been started(maintenance)

AT-5 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 mem-ory 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 format-ted.


R1B 15

Two formats exist:

• the Ericsson-specific APN format

• MSDOS

Diskettes are used as moveable media. Examples of their use are the load-ing 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 mass-storage 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 charg-ing 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.


16 R1B

Data links are used for transferring charging or statistics data or for alpha-numeric 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 SPG’s

• 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

R1B 17

2. Subsystems in the AXE IO System


2.1 IntroductionThis 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 Support Processor Subsystem

MCS Man Machine Communication Subsystem

FMS File Management Subsystem

DCS 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.

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 sub-system

• Give account of the formal product and function structure


18 R1B

2.3 Support Processor Subsystem (SPS)

2.3.1 GeneralSPS 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:

• 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

2.3.2 The Hardware of SPS

Figure 2.2SPS 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 pri-mary 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.

CP

DL DL

ICB

RPV/RPV2

SP

HD

OD

ALI AT

OD

AT

HD

RPV/RPV2

SP

FD FD

AMTP

HD HDAT

AT, printer

Subsystems in the AXE IO System

R1B 19

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

Figure 2.3Interface 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 par-allel 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 SPSThe 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 soft-ware 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.

C PR P V V M E b u s S P

C PR P V 2 V M E b u s S P

P a ra lle l R Pb u s

S e ria l R P b u s


20 R1B

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 CommunicationCommunication between the SP and the CP partly follows the Open Sys-tems Interconnection, OSI, model for data communication.

The CP regards the RPV’s as RP’s 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 execu-tive 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 exam-ples 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 GeneralMCS 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.


R1B 21

2.4.2 The Hardware of MCS

Figure 2.4MCS 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 them-selves 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 AT’s are physically connected to hardware inter-faces belonging to subsystem DCS.

2.4.3 The Software of MCSThe software of MCS executes in CP, SP and EMRP.

The main functions of MCS software are:

CP

DL DL

ICB

RPV/RPV2

SP

HD

AT

OD

ALI AT

OD

AT

HD

RPV/RPV2

SP

FD FD

AMTP

HD HD

AlarmpaneI

Externalalarm AT, printer


22 R1B

• 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 GeneralFMS 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

Figure 2.5FMS hardware

CP

DL DL

ICB

RPV/RPV2

SP

HD

OD

ALI AT

OD

HD

RPV/RPV2

SP

FD FD

AMTP

HD HD

AT AT

AT, printer

VSA


R1B 23

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 FMSThe 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 GeneralThe 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.


24 R1B

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 AT’s or data links enters the AXE IO system via DCS func-tions 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 net-work 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-1SPG0, node B CM-2




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.


R1B 25

2.6.2 The Hardware of DCS

Figure 2.6DCS 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.

CP

DL DL

ICB

RPV/RPV2

SP

HD

OD

ALI AT

OD

HD

RPV/RPV2

SP

FD FD

AMTP

HD HD

AT AT

AT, printer


26 R1B


2.6.3 The Software of DCSThe 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 communica-tion 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 hard-ware is connected via DCS. An X.25 link is used for controlling the meas-urement instruments (which are also connected to the group switch).

V .24/V.28/V.35/V.36/X .21

G .703 E0 (64 kbit/s)

G .703 E1 (2M bit/s)

To external data connections

Each Line Unit M odule, LUM , m ayhold a m axim um of four daughterboards

Daughter boards:

T-Ethernet (not introduced at this IO G20 release)


R1B 27

2.7 The Software Structure of the IO Subsystems

2.7.1 GeneralFrom 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.

Figure 2.8The software structure of the IO system

Both data links and terminals are connected to DCS hardware. A com-mand entered from an AT is thus transferred via DCS hardware and soft-ware 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 man-ner. 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.

CP

SPSCP - SP communication

DCSCommunicationInterfacesNetwork

MCS, alarmscommandsprintouts

FMSfile handlingfile access

SPSSupervisionOperating system

Data links, terminals

SP

Other subsystems in CPPRINTOUTS

COMMANDS ALARMS

FILESREAD WRITE

Alarmpanel

Externalalarms

MCSCommands, printouts,alarms

SPSSupervision

FMSFile handling

FD HDOD


28 R1B

2.7.2 CP softwareThe 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 softwareThe 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 softwareThe software units of the IO system in EMRP belongs to subsystem MCS.

The code is written in PLEX-M.

2.7.5 LUM softwareThe 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 softwareThe software of RPV/RPV2 belongs to subsystem SPS. The software is part of the SP system (module RPVFW or RPV2FW) and stored in vol-umes 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.


R1B 29

2.7.7 Functional and Product Structure of SP softwareThe 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


30 R1B

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 ANZ 216 20

FMS ANZ 217 20

MCS ANZ 218 20

SPS 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 com-munication, 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

R1B 31

3. Hardware Structure


3.1 IntroductionThis 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 IntroductionThis chapter will explain the differences between the hardware configura-tions 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 fam-ily: 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 in IOG 20 B-P

SPVM in IOG 20 B

SPVCM in IOG 20 C

Chapter Objectives


• 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


32 R1B

3.3 Hardware configurations

3.3.1 IOG 20 B-P

Figure 3.2IOG 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 or32 single data links or16 duplicated data links or a combination of this3 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.

Hardware Structure

R1B 33

3.3.2 IOG 20 B

Figure 3.3IOG 20 B

The IOG 20 B interfaces towards the serial RP bus.

The IOG 20 B theoretically has a maximum capacity of:

• 32 terminals or32 single data links or16 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.


34 R1B

3.3.3 IOG 20 C

Figure 3.4IOG 20 C

The IOG 20 C interfaces towards the serial RP bus.

The IOG 20 C theoretically has a maximum capacity of:

• 24 terminals or24 single data links or12 duplicated data links or a combination of this1 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 possi-ble.

Hardware Structure

R1B 35

3.4 Subracks and boardsThe SPVM, SPVM-P and SPVCM subracks are electromagnetic shielded.

3.4.1 SPVM-P subrack IOG 20 B-PAn IOG 20 B-P consists of two SPVM-P subracks.

Figure 3.5SPVM-P subrack

3.4.2 SPVM subrack IOG 20 BAn IOG 20 B consists of two SPVM subracks.

Figure 3.6SPVM subrack

VS

AV

SA

Po

wer

Po

wer

CP

U60

CP

U60

HD

2 drive

HD

2 drive

HD

3 drive

HD

3 drive

FD

drive

FD

drive

HD

1 drive

HD

1 drive

OD

drive (5 1/4” orO

D drive (5 1/4” or

3 1/2”) 3 1/2”)

PR

OV

ME

PR

OV

ME

DR

PB

UD

RP

BU

LUM

LUM

ALC

PU

ALC

PU

ALE

XP

ALE

XP

LUM

LUM

LUM

LUM

LUM

LUM

VS

AV

SA

Po

wer

Po

wer

CP

U60

CP

U60

HD

2 drive

HD

2 drive

HD

3 drive

HD

3 drive

FD

drive

FD

drive

HD

1 drive

HD

1 drive

OD

drive (5 1/4” orO

D drive (5 1/4” or

3 1/2”) 3 1/2”)

RP

V2

RP

V2

ES

DC

VE

SD

CV

LUM

LUM

ALC

PU

ALC

PU

ALE

XP

ALE

XP

LUM

LUM

LUM

LUM

LUM

LUM


36 R1B

3.4.3 SPVCM subrack IOG 20 CAn IOG 20 C consists of one SPVCM subrack.

Figure 3.7SPVCM subrack

3.4.4 BoardsPower - 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 intercom-puter 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 inter-faces to the opto disk drive. It interfaces to VME bus, SCSI-2 bus and power in the back plane.

Po

wer

Po

wer

CP

U60

CP

U60

OD

drive

OD

drive

(3 1/2”) (3 1/2”)

HD

driveH

D drive

OD

driveO

D drive

(3 1/2”) (3 1/2”)

HD

driveH

D drive

Pow

erP

ower

LUM

LUM

LUM

LUM

LUM

LUM

RP

V2

RP

V2

LUM

LUM

ALC

PU

ALC

PU

ALE

XP

ALE

XP

RP

V2

RP

V2

LUM

LUM

LUM

LUM

VS

AV

SA

CP

U60

CP

U60

VS

AV

SA

Hardware Structure

R1B 37

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 inter-face, 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 inter-faces 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 phys-ical 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.

Figure 3.8LUM board with daughter boards

V.24/V.35/V.36/X.21 INTERFACE daughter board - this boards imple-ments 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

V.24/V.28/V.35/V.36/X.21

G.703 E0 (64 kbit/s)

G.703 E1 (2Mbit/s)

A-node

B-node

To external data connections

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

T-Ethernet (not introducedat this IOG20 release)


38 R1B

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 intro-duced 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 pur-pose 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 sub-rack.

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 LED’s and ButtonsIn the IOG hardware there are a number of lamps (LED’s) indicating dif-ferent states and faults that can occur in an IOG.

Figure 3.9LED’s and buttons CPU60 board

• Reset and restart switch buttons. The upper button restarts the supportprocessor when toggled once. When toggled twice it reloads the supportprocessor. The lower switch halts the execution of the SP when toggledonce, 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)

Hardware Structure

R1B 39

Figure 3.10LED’s 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 debug-ging 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.

• RUN : Green during normal operation Red during reset and halt

• BM - Bus Master: Green if CPU60 is bus master

• FAIL: Red if system failure

• EX: Green if node executive

RUN BM

FAIL EX


40 R1B

Figure 3.11LED’s and buttons PROVME/RPV2 board

Figure 3.12LED’s on LUM board

Pushbutton for separation of link

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

Right LED ‘RUN’ indicates: green - processor running, red - processorhalted

RUNBM

Left LED ‘BM’ indicates: flashing red - LUM is working normallyoff - LUM is not defined or is manually blocked

One LED per port indicates port status:Green - operationalRed - blocked or not definedYellow - automatically blockedFlashing yellow - stand by

Hardware Structure

R1B 41

Figure 3.13LED’s 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 SPG’s

• 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 HD’s 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

Green LED indicates system running

Red LED indicates SCSI term ination power OK

Yellow LED indicates ongoing software update


42 R1B

R1B 43

4. FMS applications


4.1 IntroductionThis 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 mediumStorage medium for external data storage consists of the hard disks, flexi-ble 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 allo-cated on the medium. The sectors have different sizes on different media.


• 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

Chapter Objectives


44 R1B

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 Stor-age 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 OperationThe 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 SECTS STRACK TRACKSIN USE 512 139 36441

HEADS TOTSIZE(KBALLOCSIZE(KB)SUBUNITS9 2096744 20757776

VOLUME SIZE(KB)PROG_A 200000OMFZLIBORD 100000RELVOLUMSW 500000EXCHVOLUME 400000CALLVOLUME 400000STATVOLUME 475777END

FMS applications

R1B 45

SECTS Sector size in bytesSTRACK Number of sectors per trackTRACKS Number of tracksHEADS Number of heads for reading and writingTOTSIZE Total memory available to userALLOCSIZE Total memory used by defined volumesSUBUNITS Number of volumesSIZE 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 VolumesThe 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.

Figure 4.2Volumes in AXE IO system

External,single volumes

Opto disk 3 1/2 or5 1/4 inch

Hard disk node A node BFlexible disk 3 1/2 inch

Internal,single volumes

Internal,duplicatedvolume overmedia border

Internal,duplicatedvolume


46 R1B

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 dupli-cated volume of that node. If a difference between the contents of a dupli-cated 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 vol-ume. 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 OperationThe commands for handling volumes are INVOP, INVEP, INVOI, INVOL and INVOC.

FMS applications

R1B 47

Command example:

:INVOP:VOL=OMFZLIBORD;

VOLUME ATTRIBUTES INTERNAL

REV DATE TOTSIZE(KB) USEDSIZE(KB LIMIT1 991231 100000 5528 99

NODE1 IO1 SIZE1(KB)A HD-1 100000

NODE2 IO2 SIZE2(KB)B HD-1 100000

END

Example of formatting an opto disk:

< INMCT:SPG=0;:INMEI:NODE=A,IO=OD-1,FORMAT=APN,VOL=TRAINING;

ORDERED:END;

EXECUTED

VOLUME/MEDIA INITIATEDEXECUTED

NODE IO VOLUME FORMATA OD-1 TRAINING APN

END

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 com-mand INVOL.

Example of loading an external volume:

< INMCT:SPG=0;:INVOL:NODE=A,IO=OD-1;

ORDERED:END;

EXECUTED

VOLUME LOADEDEXECUTED

VOLUME NODE IO FORMATTRAINING A OD-1 APN

END

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.


48 R1B

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 volumesThe following system defined volumes are always found on the hard disks in IOG20:

• PROG_A

• PROG_B

• OMFZLIBORD

• RELVOLUMSW

Figure 4.3Standard 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 SPG’s.

Mandatoryvolumes

Optionalvolumes

Node A

0-78:3091)

78%8:3091)

',%6:3091)

)<',:3091)

6)0:30917;

31*>0-&36(

463+C%

Node B

0-78:3091)

78%8:3091)

',%6:3091)

)<',:3091)

6)0:30917;

31*>0-&36(

463+C&

FMS applications

R1B 49

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 Subsys-tem (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 vol-ume 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 spe-cific market requirements on alternative name exists. This volume is dupli-cated 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 FilesFiles 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 classFiles in FMS belong to one of three file classes:

• Simple - SPL

• Composite - CMP

• Device - DEV

A simple file is just a normal file.


50 R1B

A composite file is a file that consists of a mainfile and one or more sub-files. 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 sub-files. 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.

Figure 4.4Simple and composite file types

A device file is a file identifying an external media where data to be writ-ten. 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:

• 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

Simple file datadata

data....data....

Compositefile

datadata

data...data...

datadata

data...data...

datadata

data...data...

Main file

Sub files

FMS applications

R1B 51

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)

Figure 4.5Sequential and direct access file type

Directaccess

Sequentialaccess

Record no. 123456----

Readrecordno. 765

Readfromtopdown

Record no. 123456----

..or readrecordno. 102


52 R1B

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 con-sidered as a special case of sequential access.

Figure 4.6File 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 sub-fields.

Read allrecords withFiat

Records with subfields:

Key Key Data Data

1973 Fiat Via Torino green

1988 Nissan Nanjing road white

‘year’ ‘carmake’ ‘address’ ‘colour’

FMS applications

R1B 53

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 read-ing 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

Figure 4.7

Initialsize

Expansionfactor

Expansionfactor

Write

Write

Write

Recordlength


54 R1B

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 Blocking factor

Figure 4.8Physical 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.

Physical space onhard disk:

Start of file End of fileBlocking factorn records block 1

block 4

block 2

block 3

FMS applications

R1B 55

4.7 Operation of filesA 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, oth-erwise 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 REL-VOLUMSW.

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 vol-ume.

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 FCLASS SPG VOL NODE IOFD0A1 DEV 0 - A FD-1FD0B1 DEV 0 - B FD-1OD0A1 DEV 0 - A OD-1OD0B1 DEV 0 - B OD-1

END


56 R1B

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 ATTRIBUTESRLENGTH BLK SIZE EXP512 4 0 10TYPE NFIELDS NKEYS NUSERSSEQ 0 0

FCLASSDEV

SUBFILESFD0A1-FDFILE1FD0A1-FDFILE2

END

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 BLK SIZE EXP2048 4 16 64

TYPE NFIELDS NKEYS NUSERSSEQ 0 0

FMS applications

R1B 57

FCLASSCMP

SUBFILESRELFSW2-R0RELFSW2-R1RELFSW2-R2RELFSW2-R3RELFSW2-R4RELFSW2-R5

END

4.7.1 Removal of a FileA 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 FilesCopying 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 OPI’s ‘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.


58 R1B

Figure 4.9External transfer of file information

Command example:

< INMCT:SPG=0;

:INFIT:FILE1=HDFILE1,FILE2=HDFILE2;ORDERED

:END;EXECUTED

FILE COPY INTERNALEXECUTED

SOURCE FILE DATAFILEHDFILE1

DESTINATION FILE DATAFILEHDFILE2

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 destina-tion file must be created in advance.

Example of file copy from HD to OD:

< INMCT:SPG=0;:INFET:FILE1=HDFILE,FILE2=FDFILE,NODE2=A,

ICB

RPB-A

RPB-B

DL

RPV/RPV2

SP

HD

OD

ALIFD

HD

CP

AT

CommandsINFIT, IOFIT and INFET

FMS applications

R1B 59

IO2=OD-1;

ORDERED

:END;

FILE COPY EXTERNALEXECUTED

SOURCE FILE DATA GEN VOLUME NODE IOFILE - OMFZLIBORD - -

HDFILE

DESTINATION FILE DATA GEN VOLUME NODE IOFILE 0 TEST A OD-1

FDFILE

END

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 filesAll 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


60 R1B

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 opera-tor terminal.

Note that in the printout FILE DUMP the END OF BLOCK must be inter-preted as end of record. It must not be confused with the blocking parame-ter (BLK) of the file.

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

Figure 4.10Writing 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.

File systemstandbyworking node

File systemexecutiveworking node

W rite orderto file (fromC P or SP )

D uplicatedvolume area

F ile

D uplicatedfile system

D uplicatedvolume area

F ile

D uplicatedfile system

W rite

W rite

W rite W rite R esult

R esult

R esult

R esult

FMS applications

R1B 61

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 nor-mal 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

SPG0

NPAIR EX SB

NODE CM STATUS STATE NODE CM STATUS STATE HDSTATE1 A 1 WORKING NORMAL B 2 ISOLATED BLOCKED CORRUPT

END

The hard disk status may be printed with command IMCSP. The parame-ter 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 cop-ying 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 updat-ing 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 dupli-cated 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.


62 R1B

Figure 4.11Blocked 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 systemstandbyblocked node

Orders tofile system(from CP orSP)

Duplicatedvolume area

File

Duplicatedfile system

Sector table

File systemexecutiveworking node


File


Write

Write

Delete

Delete Create

Create

.......

sector n

...

sector y

...

File systemstandby nodeUpdating small


File


Sector table

File systemexecutive node


File


.......

sector n

...

sector y

....

sector n sector y

FMS applications

R1B 63

Figure 4.12Small 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).


64 R1B

Node status during small update:

:IMCSP;


SPG0

NPAIR EX SB

NODE CM STATUS STATE NODE CM STATUS STATE HDSTATE1 A 1 WORKING NORMAL B 2 ISOLATED UPDATING S CORRUPT

END

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

4.9 Corrupt Files and File RecoveryThis 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 compo-nents 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, indicat-ing 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 pro-hibit 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 com-mand 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

FMS applications

R1B 65

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 protectionMost 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 FilesThe 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.


66 R1B

Figure 4.13Infinite 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 cre-ated 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 com-mand 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.

SP or CP file user

Write to file STATFILE

Mainfile: STATFILE

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

FMS

FMS applications

R1B 67

Command examples:

<IOIFP;

FILE ATTRIBUTE INFINITE SEQUENTIAL FILE

FILE ACTIVESUB NEXTSUB NSUB MAXSIZE MAXTIME RELEASE COMPTTFILE00 0231 0232 9999 4096 NO YESTTFILE01 0001 0002 9999 4096 NO YESTTFILE02 0001 0002 9999 4096 NO YESTRARFILE 1201 1202 9999 512 YES NOCMVNFILE 0007 0008 9999 1 YES NOTRDIPFILE 0763 0764 9999 1024 YES YESEND

< 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 automati-cally 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 out-puts. 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 func-tion 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.


68 R1B

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.

Figure 4.14Infinite files without data compression

(MAX -9999)

Reported to FPU

SUBFILE -0066

-0067-- " --

-0068-- " --

-- " --

-0070-- " --

Deleted

Active subfile

Next subfile

-0064

-0065

-0069 Data

FMS applications

R1B 69

Figure 4.15Infinite 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 ImplementationThe 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 GeneralThe 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 Disper-sion 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 men-tioned functions. The statistics and recording results needs to be trans-ferred to an operation and maintenance centre and the charging data to a billing centre.

Uncompresseddata

Compresseddata

(MAX -9999)

Reported to FPU

SUBFILE -0066

-0067-- " --

-0068-- " --

-- " --

-0070-- " --

Deleted

Active subfile

Next subfile

-0064

-0065

-0069 Data


70 R1B

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 opera-tional 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 imple-mented.

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 func-tion 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.

FMS applications

R1B 71

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

FPU destinations:

<INFDP;FILE PROCESS UTILITYDESTINATION LIST

SPG DEST0 TTFILEOD0 AOM1 STATDEST

END

The destinations may be of one of three equipment types:

• NOLINK

• MTP

• FTAM

The equipment type NOLINK indicates that the files connected to a desti-nation 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 destina-tion 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.


72 R1B

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 UTILITYSUBFILE LISTFILE = TTFILE00 DEST = TTFILEOD

SUBFILE SIZE TRANSF DUMPED SEQNUM2351 1000 NO YES 2352 1000 NO YES 2353 1000 NO YES 2354 1000 NO YES 2355 1000 NO YES 2356 1000 NO YES 2357 1000 NO YES 2358 1000 NO YES 2359 1000 NO YES 2360 1000 NO YES 2361 1000 NO YES 2362 1000 NO YES 2363 1000 NO NO 2364 1000 NO NO 2365 1000 NO NO 2366 1000 NO NO

END

FPU subfile data:

<INFSP:FILE=TTFILE00-2362,DEST=TTFILEOD;FILE PROCESS UTILITYSUBFILE DATA

FILE = TTFILE00 SUBFILE = 2362 DEST = TTFILEOD

GENERATION SIZE SEQNUM- 1000

STATUS STARTTIME STOPTIME FAILTIME REASON

FMS applications

R1B 73

DEFINITION 970605 1121MAN TRANSAUT TRANSDUMP1 970605 1128 970605 1130 DUMP2

END

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 cer-tain 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 sub-file 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.


74 R1B

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 o’clock 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 over-ride 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

FMS applications

R1B 75

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 automati-cally 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;


76 R1B

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 FTAMFile transfer and Management, FTAM, is an industry standard protocol.

The link transfer with the FTAM protocol may be performed in two differ-ent 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 diskDumping 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 UTILITYSUBFILE LIST

FILE=PERIODICACC DEST=ODDEST

SUBFILE SIZE TRANSF DUMPED SEQNUM0001 1000 NO NO 0002 1000 NO NO 0003 1000 NO NO

FMS applications

R1B 77

0004 1000 NO NO 0005 1000 NO NO 0006 1000 NO NO 0007 1000 NO NO

END

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 UTILITYSUBFILE LIST

FILE=PERIODICACC DEST=ODDEST

SUBFILE SIZE TRANSF DUMPED SEQNUM0001 1000 NO YES 0002 1000 NO YES 0003 1000 NO YES 0004 1000 NO YES 0005 1000 NO YES 0006 1000 NO YES 0007 1000 NO YES

END

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 vol-umes 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 ODIf both transfer and dumping of subfiles is required, then two separate des-tinations 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.


78 R1B

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 ODFPU 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 filesThe 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: File in external file system:

PERIODICACC-0007 PERIODICACC.0007

PERIODICACC-0007 PERIODICACC0007.0000

PERIODICACC-0007 PERIODICACC-0007

FMS applications

R1B 79

In the first case the FMS file name is adapted to a file system where gener-ations are supported. The mainfile name forms the file name in the exter-nal 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 concate-nated 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:


PERIODICACC-0007 PERACCTOWN.0007

PERIODICACC-0007 PERACCTOWN0007.0000

PERIODICACC-0007 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 connect-ing a file to a destination.

Command example:

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


PERIODICACC-0007 PERACCTOWN.0007

Command example:



PERIODICACC-0007 PERACCTOWN0007.0000

Command example:



PERIODICACC-0007 PERACCTOWN-0007

4.12.9 Automatic Removal of subfilesOnce 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.


80 R1B

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 destina-tion, i.e. the way the data has been transferred.

The possible removal conditions are:

Equipment type: Removal condition:

NOLINK DUMPDUPL

MTP AUTOMAN

(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 count-down 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;

FMS applications

R1B 81

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 FPUThe 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 filesWhen 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 decom-pressed 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:


82 R1B

: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 AXEThe 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 ImplementationThe 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 supervi-sion 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, con-tain 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 mainte-nance 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

FMS applications

R1B 83

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


84 R1B

R1B 85

5. System Backup Handling


5.1 IntroductionThis 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 CPA 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.

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


86 R1B

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 doesn’t 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 REL-VOLUMSW.

5.2.1 CP Backup in Main StoreThe CP backup in Main Store is an optional function which is not neces-sarily 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 deacti-vated. The only CP backup is now stored on hard disk.

5.2.2 CP Backup on hard diskA 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.

System Backup Handling

R1B 87

Figure 5.2CP backup file on hard disk

The subfile R0 contains control data for administration of the other sub-files, 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 dif-ferent 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

R0

R1

R2

R3

R4

R5

Mainfile RELFSWn

Control data

Charging data, small backup, DS

Reload marked variables, large backup, DS

Contents of RS and PSRS - Reference StorePS - Program StoreDS - Data Store

Subfiles:


88 R1B

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 informa-tion 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


R1B 89

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 Out-put Times, Specify’.

Command example:

<SYBTS:TIME=0000,TDMI=240;

<SYBUI:DISC;

In the example above the large automatic CP backup is performed at mid-night 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 HandlingThe 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.


90 R1B

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.

Figure 5.3Manual 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, depend-ing 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.

Automatic dump

Reload

Manual dump

HD node A and B, SPG0

CP

RS, PSand DS

FirstFile Range

SecondFile Range

RELFSW102

RELFSW101

RELFSW100

RELFSW2

RELFSW1

RELFSW0


R1B 91

Figure 5.4Rotation 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. Com-mand SYTUC is normally used after a manual dump to RELFSW2. See Figure 5.4.

<SYTUC;

<SYTUC:SFR;

FirstFile Range

SecondFile Range

RELFSW102

RELFSW101

RELFSW100

RELFSW2

RELFSW1

RELFSW0


92 R1B

Figure 5.5Rotation 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 nor-mally only used at the first load of the exchange when, after the first man-ual 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 renam-ing files is preferably avoided, particularly in a ‘live’ switch. This method is however very useful during installation test or in a test plant environ-ment 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.

<SYNIC;

<SYNIC:SFR;

FirstFile Range

Secondfile Range

RELFSW102

RELFSW101

RELFSW100

RELFSW2

RELFSW1

RELFSW0


R1B 93

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.

Figure 5.6Transfer 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;

<SYSFT;

FirstFile Range

SecondFile Range

Old contentsare overwritten

RELFSW102

RELFSW101

RELFSW100

RELFSW2

RELFSW1

RELFSW0


94 R1B

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

5.2.6 CP backup transfer to/from IOG

Figure 5.7CP 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 sub-files R0 and R5, the youngest of R1, R2 and the oldest of R3, R4. The eco-nomic CP backup contains four subfiles.

SYBUP

SYMTPSYACISYCFI

ICB

RP bus ARP bus B

DL

RPV/RPV2

SP

HD

OD

ALI FD

HD

CP

(via FPU)

AT


R1B 95

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 sub-files R0 and R5, the youngest of R1, R2 and the oldest of R3, R4. The eco-nomic 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-


96 R1B

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 con-verted and input from diskette. The diskettes of course has to be changed in between giving the commands. The diskettes must be inserted in the dis-kette 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 reloadAutomatic CP reload happens if a serious software of data error has been detected by the system. If the ordinary recovery action does not remedy


R1B 97

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 auto-matic 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 con-trol 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 auto-matic 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.


98 R1B

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 load-ing. 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 NTAZ NTCZ LOAZ INCL1 INCL2 INCLA SUPAUT 1 10 0 RELFSW0 101 97062 60

LAST RELOADED FILENAME CREATED ATRELFSW0 970618 0832

END

Here is a short explanation of the different parameters in the example:

CLH Can be set to AUT for automatic handling of the backup system or MAN for manual.

NTAZ Number of truncation attempts with RELFSW0. If thisparameter is set to zero, the following two parameters are insignificant.

NTCZ Number of additional commands to be truncated at eachreload 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.

LOAZ Log subfile omission attempt with RELFSW0. Theparameter can be used to indicate that the command log subfile should be omitted completely (=2), that theyoungest subfile should be omitted (=1) or that thereshould be no omission at all (=0). The last value isdefault.

INCL1 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.

INCL2 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.


R1B 99

INCLA This is a parameter which can “age check” the reload files. This means that no files older than the parameter are used.

SUP 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).

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 RP EM DEV RELOADFILE930429 1141 4 0 1 RELFSW0

TYPE ACTION SOURCE OUTPUTTIME SUBFILEPS,RS LOADED FILE MEDIUM 930318 0832 R5DSSMALL LOADED FILE MEDIUM 930318 0832 R1DSLARGE LOADED FILE MEDIUM 930318 0832 R3

COMANDLOG TRUNCATION OMISSION000005 0 NONE

END

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 sys-tem 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 checkEach 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, calcu-lates a check sum and compares to the checksum stored on hard disk.


100 R1B

Command example:

<SYBCI:FILE=RELFSW101;

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

5.2.9 Hanging backupThe 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 fol-lowing the OPI for the alarm above.

5.3 Command LogThe 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 fileThe 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 per-formed. 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


R1B 101

‘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 com-mand 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 IO EXCHANGERELFSW3 - TRX-C:9 APZ 211 11 R1

SUBFILE TYPE OUTPUTTIME CURRENT COMMANDLOGR1 DSSMALL 970302 1600 YES -R2 DSSMALL 970302 1200 NO -R3 DSLARGE 970302 0000 YES 0010021R4 DSLARGE 970301 0000 NO 0010020R5 PS,RS 950302 1614 YES -

END

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 com-mand 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 sidesNew 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.


102 R1B

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 sub-file.

5.3.3 Loading of command log to systemThe 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 pre-vious section in this chapter.

If loading the commands in the command log subfiles manually the oper-ator must first of all decide which of the two applicable command log sub-files 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.


R1B 103

The procedures of the Command Log are described in several OPI’s, all named ‘Command Log......’.

5.3.4 Operation of command logStart 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 acti-vated.

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 sub-files 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 com-mand 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 backupThe 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.


104 R1B

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 mem-ory 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 mod-ule 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.

• The SP exchange data files contain SP exchange data definitions. These are usually stored in volume OMFZLIBORD. Examples of SP exchange data are port definitions, MCS transaction logging conditions, Network terminal numbers etc.

• 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.


R1B 105

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 com-mands 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 vol-umes 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


106 R1B

R1B 107

6. MCS applications


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

6.2 The functions of MCSThe 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.

Chapter Objectives


• 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


108 R1B

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 analy-sis, location of command receiving block and transfer of command param-eters, 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 print-out 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 imple-mented 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 lev-els five to seven in OSI for command/printout sessions.

MCS applications

R1B 109

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 (Alpha-numeric 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 param-eter 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 ID’s 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 alpha-numeric terminal. Commands may however also be executed from a pre-pared 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 Introduction

Figure 6.2Alarm 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

AXE

MCSAlarm list

.....

....

.......

Error

Alarmissue

Errorremedied

Alarmcease

Error

Externalalarm issue

Manualintervention

Alarmissue


110 R1B

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 conceptsBelow 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.

MCS applications

R1B 111

Figure 6.3Example 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 o’clock 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 cate-gory number (ALCATNO).

The alarm categories and their ALCATNOs are as follows:

0 Data processing system1 Processors2 ´ IO Device3-15 System dependent data, determined by the system projecting

instance in question.

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

A 2 /A P Z "H M B R G L O C 1 2 .4 /0 0 /01 " 0 13 97 04 25 1 25 8 H ’0 26 2-0 00 1 E M G F A U L T E M G U N IT S T A T E R S S 0 S T R -B C B LO C K

A larm n u m b er

D ate

A la rm tex t

E xch an g eh ead er

A la rmcateg o ryslo g an

A la rmclass T im e A larm F id


112 R1B

3 Switch4 Switching part5 Switching device6 Subscriber lines7 Spare8 Power alarm9 House alarm10 Alarm from subordinate exchange11 Cable alarm12-15 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 CATEGORY DATA

ALCATNO ALCAT DICAT0 APZ 0&41 APZ 0&42 APZ 0&43 APT 1&44 APT 1&45 APT 1&46 APT 1&47 APT 1&48 POWER 2&49 EXT 3&4...14 EXT 3&415 EXT 3&4

END

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 con-nected to DICAT 0 etc. See Figure 6.4.

MCS applications

R1B 113

Figure 6.4Display 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 dur-ing 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 CLASS DATA

ACLNO ACL ALDB TWB PRINTOUT0 A1 YES NO YES

APZ APT POW EXT OBS

ATT

A1

A2

O1

O2

AXE

ATT

A1

A2

AXE

ATT

A1

A2

AXE

ATT

A1

A2

First alarmpanel 2:nd alarm panel

Displaycategories

Alarm categories

0 1 2 3 4 5... ... 15

3:rd... ...13:th


114 R1B

1 A2 YES NO YES2 A3 NO NO YES3 O1 NO NO YES4 O2 NO NO YES

END

6.3.3 Connection of alarm interfaceThe 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.

Figure 6.5Alarm 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 ‘Connec-tion 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 A-node of SPG0. It is defined as AT-1, one or more alarm panels are to be

V.24 port to LU M port,2400 baud

Pow er -48 V

ALCPU

V.24 port to fan, 2400baud

A larm panel, displaycategories 0-3.U S version categories 0-2.

External alarm sensor toEX RAN G 20. DevicesEX AL2 0 - 31

SCA N interfacecategories 0-15.US version categories 0-11.

ALEX P

Bus in backplane




MCS applications

R1B 115

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.

Figure 6.6External alarm sensors in AXE

Remote stages(subscriber stageor base stations)

CentralswitchIOG20

EXAL0-devices

Burglaralarm ondoor andwindow

Alarm oncoolingsystem



Alarm onpowersystem

Alarm onpowersystem

EXAL2-devices,EXRANG20alarmsensor EXAL0-

devices,EXALIboard


116 R1B

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

Figure 6.7EXAL2 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

1XPEHUV�LQ�WKH�ILJXUH�DUH(;$/��GHYLFH�QXPEHUV�

��

�

� �

� �

� �

� �

��

��

��

�

��

�

�

�

�

��

��

�

��

�

��

��

� �

� �

��

��

��

�

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

&DEOH�WR�$/&38ERDUG

(DFK�GHYLFH�FRQVLVW�RI�WZRFRQQHFWRU�SLQV

MCS applications

R1B 117

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 connec-tion 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 inter-face, 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 con-tact 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 com-mand 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 STATUS "HMBRG LOC 12.4/00/01"ALARM CATEGORY 0 1 2 3 4 5 6 7 .... 12 13 14 15ALARM CLASS O1 A2 A2 - - A2 - - .... - - - -ATTENDANCE STATUS N N N N N N N N .... N N N NEND

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 attend-


118 R1B

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 implementationThe 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 generat-ing blocks includes alarm class, alarm category and detailed information about the error or fault.

Figure 6.8Alarm 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 supervi-sion 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.

ALA

ALSA

Alarm s from userblocks in CP

ALCO EXAL2 EXAL0

ALARMADM ALCPU EXALI

EXRANG20Alarm s from user

blocks in SPG

CP

SP

External alarmsconnected centrally

in SPG

External alarm sconnected remotely

in EMG

MCS applications

R1B 119

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 corre-spond 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 cate-gory 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 sen-sors 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 updat-ing of the hardware. In the opposite direction, when an external alarm sen-sor indicates a fault, the functions filter out non-persisting fault indications and send a signal containing alarm information to ALSA if the fault per-sists.

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 indica-tors and alarm panels depending on attendance.

Block ALIM provides maintenance functions for the ALI. The block con-sists 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 infor-mation (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 ALI’s and issuing alarms on ALI fault detection

• isolating and testing of ALI functions.


120 R1B

ALCO is the final alarm handling block in the CP. ALCO receives alarm information from the module ALARMADM in the SP. ALCO thus han-dles alarm information concerning faults in the SPG.

Block ALCO stores the information for all SPG alarms in a list and initi-ates 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 GeneralThe 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 routedEach 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 maxi-mum 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 com-mand 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 parame-ter 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.

MCS applications

R1B 121

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 PRCABy 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 PRCA’s 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 PRCA’s can be connected to a device group con-sisting of up to maximum four device chains. Thus the PRCA’s 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 defin-ing 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.

Figure 6.9Device chain

The parameter DTYPE in the command IOROL is used to define the posi-tion 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.

IO device 1

DTYPE=FIRST

IO device 2 IO device 3

AT-0 AT-4AT-2

<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;

DTYPE=NEXT DTYPE=NEXT


122 R1B

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

Figure 6.10Device 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 catego-ries.

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 nextdevice in the chain.

1 means that the printout will only be routed to thenext device in the chain if the device (withCOND=1) is unattended (attendance: see below.)

2 means that printouts are never sent to the nextdevice 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.

AT-10

IO device 1 IO device 2 IO device 3

AT-0AT-2

DTYPE=STBHD

AFFILE-2

AT-4

DTYPE=STB

MCS applications

R1B 123

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 print-outs 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, PCLA1 1A2 2A3 3O1 4O2 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 prior-ity (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 PCL’s 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 PRCA’s has been defined for each device using IOROL then the data must be entered into the device tables by the com-mand IOROI.


124 R1B

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 DefinitionCommand 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 sys-tem 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 non-alarm 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 print-outs. 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 alphanu-meric 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.

MCS applications

R1B 125

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 heart-beat 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, Spon-taneous, Route’.

The function is handled by the block SEC2.

6.5 Standby DevicesAll 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 differ-ent 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 print-out 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 cate-gories 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 print-outs 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.


126 R1B

The standby devices defined by command IOSBC can be checked by com-mand IOIOP.

The OPI ‘IO Device Standby List, Change’ should be used when defin-ing 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 devicesA 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 oper-ation 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 oper-ator 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.

MCS applications

R1B 127

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/unat-tended.

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 GeneralPrintouts 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 out-put 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.


128 R1B

Figure 6.11Alphanumeric 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 print-outs 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 DeviceThe 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 com-posite.

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.

Command example:

<IOIOI:IO=AF-3;<IOAFC:FILE=AFFILE-3,IO=AF-3;

HD

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

AXE

AT

File=AFFILE-3

MCS applications

R1B 129

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 giv-ing 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 sub-files 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 Alphanu-meric Information to File’ should be used.


130 R1B

6.8 MCS directoriesMCS directories form an authority and printout routing system. The func-tion 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 there-fore 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. Shir-ley 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 com-mand 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;

MCS applications

R1B 131

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 User-name (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;


132 R1B

6.8.1 Definition of Terminal DataAn example of SP authority verification used in connection with port defi-nition 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 DataTo further allow an individual user to access the SP in local mode via any such defined port, an entry of the user’s 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 termi-nal/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 OPI’s which include the definition of user authority verification in the SP are:

‘Connection of Alphanumeric Terminal, SP-Connected’.

‘Change of Directories in MCS’.

MCS applications

R1B 133

6.9 The MCS Transaction LogThe MCS Transaction Log is an optional function which stores informa-tion about different command and printout transactions, i.e. logging of the operator communication.

The transaction log does not log transactions on devices of type alphanu-meric file (AF) or towards CPU port.

Figure 6.12MCS 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 catego-ries, 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.

AXE

STDEPPRINTOUTCACLS....

LAFBPALARM...INFUI...

EXROIPRINTOUTSYREIPRINTOUT

Logfile on hard disk




DATE TIME IO USER

DATE TIME IO USER

DATE TIME IO USER

DATE TIME IO USER

AT

AMTP

AT


134 R1B

The transaction log files are composite sequential files. The files must be created before any logging conditions can be defined. Unlike the com-mand 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 statis-tics 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 (acti-vate) 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 recom-mended:

• 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 alphanu-meric 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 print-out 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 con-tinuously 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;

MCS applications

R1B 135

: END;

Command example of setting logging conditions. The first condition logs all commands, printouts and alarms except the alarms of printout catego-ries 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 cre-ated. 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” indi-cates 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 log-gingAn administration may chose to exclude certain commands and printouts from being logged by the MCS transaction log. This is performed by creat-ing a text file in AXE-external environment (WS or PC) which lists the commands and printouts to be excluded.


136 R1B

Figure 6.13Exclusion 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 com-mands and printouts are excluded cannot be printed by command.

6.9.2 Search in Transaction LogThe 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 com-mands beginning with CH

• all printouts

• one or a number of printout categories

• a specific user

• logon attempts

AGKDI

EXRPI

EXROI

printout

printoutFile

Encryption

Text file with commands andprintouts to exclude:

Hard disk in IOG20, SPG0 PC or WS

MCS applications

R1B 137

Figure 6.14Search in transaction log

This is described in the operational instruction “MCS Search in Transac-tion Log”.

Two types of searches exists, i.e. search on transactions concerning the ter-minal the search is ordered from and authorised search which gives a pos-sibility 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;

AT

AMTP

AT

AXE Logfile on hard disk




Logfile on hard disk




DATE TIME IO USER

DATE TIME IO USER

DATE TIME IO USER

DATE TIME IO USER


138 R1B

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 ImplementationThe 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 fileCommands are usually executed manually or automatically from a alpha-numeric terminal. Commands may however also be executed from a pre-pared 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 com-mand 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 RELC-MDHDF.

6.10.1 Creation of command fileCommand 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 com-mands may fit into one record. The commands CACLP and STDEP are written to the file.

6.10.2 Manual execution of command fileCommand example (continued from above):

< IOCMI:FILE=COMMAND,PROC=D,IO2=AT-5;

(on AT-5:)

MCS applications

R1B 139

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 fileA 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 o’clock 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, com-mand log handling.

6.11 IO device load regulationThe load regulation of IO devices is used to regulate the output of print-outs depending on the central processor load. The load regulation is con-trolled by block LOAS. The different priority levels are similar to the priority levels of a subscriber or of an incoming route, parameter PRI.


140 R1B

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 ImplementationBlock 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 directo-ries, 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 cer-tain IO device(s)

• Device chain is a chain of maximum eight devices receiving different PRCA’s simultaneously

• Each PRCA or group of PRCA’s 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 crite-ria, such as IO device, date and time, one command or part of a com-mand, one or a number of PRCA’s, etc.

R1B 141

7. MCS - Command handling


7.1 IntroductionThis chapter describes command handling in AXE.

7.2 AXE Command HandlingThe 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.

Chapter Objectives


• Explain the purpose of the entry commands used with IOG 20

• Name the entry commands for the different subsystems


142 R1B

Figure 7.2Handling 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 differ-ent entry commands in the AXE IO system.

Figure 7.3SP command handling

a) Entry command and printout, SPG0b) Subcommand and printout, SPG0c) Entry command and printout, SPG1d) Subcommand and printout, SPG1

Alphanumeric terminalSP CP

Command

Printout

AT

b)

CP

Entry command

Printout

CP

Subcommand

a)

SPG0

SPG0

Subcommandd)

SPG0

SPG1

CP

c)

SPG0

SPG1

Entry command

Printout

Printout

Printout

CP

AT AT

AT

AT

MCS - Command handling

R1B 143

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 indi-cated 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 pro-vided 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 com-mands 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 per-form the necessary interface between the incoming commands/outgoing printouts and the user blocks.

7.3 Entry CommandsSPS maintenance and reconfiguration functions have just one entry com-mand. Certain operation functions in SPS make use of a command receiv-ing 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 Meas-urement Subsystem (RMS) and Statistics Traffic Measurement Subsystem (STS) if these were loaded.


144 R1B

In each subsystem each entry command corresponds to a different author-ity 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) FMS MCS/DCS/RMS/STS

IMMCT INMCT IMLCT

INMIT IMLIT (F-category)

INMPT 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 Change and Print high authority

I is for Initiate and Print middle authority

P is for Print 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 subcom-mands can now be given after the colon. Subcommands issued will be ana-lysed 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;

:

:@


R1B 145

< 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 SubcommandsTo 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 com-mands. 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 subcom-mand, 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 sub-commands belonging to the original entry command then the entry com-mand must be given again before it is possible to continue.


146 R1B

7.5 Local Mode and CPT CommandsAs 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 print-outs directly from the SP.

Figure 7.4Local 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 sub-commands 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 initi-ate a recovery process.

CP

Printouts

Commands

SP

AT


R1B 147

Within the SP software exists part of the CPT function (Central Processor Test system). This software - a number of Maintenance Subsystem mod-ules - 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 operator’s 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 men-tioned 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 LU’s.

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.


148 R1B

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

R1B 149

8. DCS Applications


8.1 IntroductionThis 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 CommunicationBefore looking at DCS it may be a good idea to recap certain basic con-cepts 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 phys-ical interface.

The rules for addressing, establishing sessions, exchanging data and mes-sages 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.

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


150 R1B

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 destina-tion 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 ModelA standard model for data communication has been defined by the Interna-tional Standards Organization, ISO. This standard is called the OSI Refer-ence Model, where OSI stands for Open Systems Intercommunication.

OSI is a logical structure in which the functions required for the data trans-fer have been broken down into seven distinct layers each of which com-municates with the corresponding layer at the remote end of the connection. By protocol is meant the rules for the handshaking communi-cation 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’.

DCS Applications

R1B 151

Figure 8.2Open 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 hard-ware. The other layers consist only of software.

Each layer performs specific functions and is independent of the other lay-ers, apart from a well-defined interface to the layers directly above and below. A layer can be changed without affecting the other layers, thus pro-viding flexibility which, in turn, simplifies the interconnection of different datacom systems.

7

6

5

4

3

2

1

PHYSICAL MEDIA

APPLICATION

PRESENTATION

SESSION

TRANSPORT

NETWORK

LINK

PHYSICAL

USER

APPLICATION

PRESENTATION

SESSION

TRANSPORT

NETWORK

LINK

PHYSICAL

USER


152 R1B

Figure 8.3Sending 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 addi-tional 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 corre-sponding 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 net-work 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 net-work, i.e. it gives the user access to the network services. It is, as such, the network communication program as seen from the user’s 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)

7

6

5

4

3

2

1

APPLICATION

PRESENTATION

SESSION

TRANSPORT

NETWORK

LINK

PHYSICAL

USER A USER B

APPLICATION

PRESENTATION

SESSION

TRANSPORT

NETWORK

LINK

PHYSICAL

user data

user data

user data

user data

user data

user data

user data

user data

Layer specific overhead

DCS Applications

R1B 153

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:

• Communication Module

• Line Module

• Line Unit

• Ports

8.5.1 Communication moduleThe Communication Module, CM, is a logical concept. The first node in SPG identifies the CM, as follows:

SPG 0 node A = CM 1

SPG 1 node A = CM 17



The background to the CM numbering is the operating system. The operat-ing 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;


SPG0

NPAIR EXSB

NODE CM STATUS STATE NODE CM STATUS STATE HDSTATE1 A 1 WORKING NORMAL B 2 ISOLATED BLOCKED CORRUPT

END


154 R1B

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


8.5.2 Line moduleThe 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 communica-tion 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 unitThe 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.

VS

AV

SA

Po

wer

Po

wer

CP

U60

CP

U60

HD

2 drive

HD

2 drive

HD

3 drive

HD

3 drive

FD

drive

FD

drive

HD

1 drive

HD

1 drive

OD

drive (5 1/4”)O

D drive (5 1/4”)

RP

V2

RP

V2

ES

DC

VE

SD

CV

LUM

LUM

ALC

PU

ALC

PU

ALE

XP

ALE

XP

LUM

LUM

LUM

LUM

LUM

LUM

NP = CM-LM-LU-NP

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

DCS Applications

R1B 155

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.

Figure 8.5Line unit addressing

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 B-node of SPG2 and the A-node of SPG0 are defined. The line units are sin-gle (non redundant).

A line unit can take the status:

• 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.

VS

AV

SA

Po

wer

Po

wer

CP

U60

CP

U60

HD

2 drive

HD

2 drive

HD

3 drive

HD

3 drive

FD

drive

FD

drive

HD

1 drive

HD

1 drive

OD

drive (5 1/4”)O

D drive (5 1/4”)

RP

V2

RP

V2

ES

DC

VE

SD

CV

LUM

LUM

ALC

PU

ALC

PU

ALE

XP

ALE

XP

LUM

LUM

LUM

LUM

LUM

LUM

Line Units 1, 2, 3 and 4


156 R1B

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

Figure 8.6Twin 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 auto-matically 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.

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

SPG0 SPG0Node A Node B

‘Y’-cable

DCS Applications

R1B 157

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 aboveIt is recommended, to always deblock first, the line unit located in the EX-node.

8.5.4 PortThe 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 communi-cation interfaces, as below:

V V.24/V.35/V.36/X.21

G G.703 E0 (64Kbps)

E G.703 E1 (2Mbps)

T 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.

Figure 8.7LUM board

.

.

.

.

Screws

.

.

.

.

Daughterboard

Motherboard

Each daughter boardimplementsone physical port


158 R1B

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-LM-LU-PP-LLP.

Example: the port NP=17-1-4-4 is the fourth port of the line unit number e in SPG1.

Figure 8.8Port designation SPG0, SPG1

When defining a port not only layer 1 but also the layer 2 and 3 character-istics 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 ‘Sin-gle Link Port, Initiate’ gives recommendations and explanations to all

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

LU

ML

UM

PP = 1-1-1-1



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

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

PP = 1-2-4-4

DCS Applications

R1B 159

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-disas-sembly 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=H’01;:ILLLI:NP=1-2-4-1-2,PROT=CPT/SDLC,ADDR=H’86;:ILLLI:NP=1-2-4-1-3,PROT=CPT/SDLC,ADDR=H’A9;:ILLLI:NP=1-2-4-1-4,PROT=CPT/SDLC,ADDR=H’CD;::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.


160 R1B

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 logi-cal 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 ImplementationModules PORTADM, LME, CMMAN and LUMAN. Files CMFILE, LUFILEx and PEFILEx on hard disk (x indicates the SPG number).

8.6.1 Layer 1, interfacesThe interfaces provide layer 1 in the OSI reference model. The communi-cation protocols cover layers 2-7.

Figure 8.9AXE IOG 20 protocols and interfaces

The following types of interface standards are supported in IOG 20:

Interface: Supported baudrates

Asynchronous transmission:

Users in SP

Presenation (6)

Session (5)

Network (3)

Data Link (2)

X.28/X.3

X.21V.36V.24/V.28V.25 bis/V.28

SDLC

FTAM

CP-SP communicationCPT SW (CPTASP)

V.351

DCS

3

2

5

4

7

6Ericsson MTP

MCS FMS

Asynchronous Synchronous

E0 E1

V.24/V.28

HDLC / LAPB

V.25 bis/V.28

X.224 RFC1006

Ethernet

TCP/ IP

X.29

X.25

ATP

DCS Applications

R1B 161

ITU-T V.24/V.28 (EIA RS 232 C) 2400 - 57 600 bits/s

ITU-T V.25bis/V.28 2400 - 57 600 bits/s

Synchronous transmission:

ITU-T V.24/V.28 (EIA RS 232 C) 2400 - 57 600 bits/s

ITU-T V.35 2400 - 256 000 bits/s

ITU-T V.36 2400 - 2 048 000 bits/s

ITU-T V.25bis/V.28 2400 - 57 600 bits/s

ITU-T X.21 2400 - 2 048 000 bits/s

ITU-T G.703 E0 64 000 bits/s

ITU-T G.703 E1 2 048 000 bits/s

Ethernet 10 240 000 bits/s

V.24/V.28 interface is used for the connection of asynchronous terminals or other synchronous connections, either locally or via modem. V.24 identifies the physical layout of theconnector (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 terminals via modem (dial-in/dial out procedures). V.25 bis identifies the automatic calling and/or answering procedures and V.28 the electrical characteristics (V.24 circuits are used).


V.35 Interface for interworking with V.35 modem.


V.36 Interface for interworking with V.36 modem.


X.21 X.21 interface is used for the connection of high speedsynchronous data links in public data networks

Implemented in V.24/V.35/V.36/X.21 INTERFACEdaughter board.


162 R1B

G.703 E0 is used for the connection of a 64 kbit/s PCM data linkover the PCM network. (After connection through a PCM multiplexer the data occupies one channel in a 2 MbitPCM line and can be connected to GSD).

Implemented in G.703 E0 INTERFACE daughterboard.

G.703 E1 is used for the connection of a 2 Mbit/s PCM data linkover the PCM network.

Implemented in G.703 E1 INTERFACE daughterboard.

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

8.6.2 Layer 2Layer 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 stand-ard which in AXE is only used with Central Processor Test, CPT.

The Link Access Procedure Balanced Mode protocol, LAPB. This pro-tocol 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.

DCS Applications

R1B 163

8.6.4 Layer 4-7Layers 4 to 7 implements the transport, session, presentation and applica-tion 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 pro-tocol 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 proto-col is used.

The locally connected terminals connects via Asynchronous Terminal Pro-tocol, 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


164 R1B

8.7.1 AddressingBasically, a network user is identified by a Network Terminal Number, NTN.

An NTN could be compared to a telephone number in the telephone net-work. 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 Direc-tion, ND, which corresponds to the area code in the telephone network:

NTN =ND + internal digits

Figure 8.10Addressing 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 ori-gin, BO.

All ports in IOG 20 used for connection of AT devices are assigned net-work 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.

NTN=9873

Alphanumeric terminal

NTN=905

NTN=94

Data networknodes

Terminating function,example X.29 or MTPNTN=830968

ComputerNTN=65392

DCS Applications

R1B 165

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 proto-col to be used. The destination is translated to a NTN number, it’s a one-to-one relation, with command ILDNI. The relation is printed with com-mand 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=0ND

1011101 DTE NP= 1- 1- 1- 11011102 DTE NP= 1- 1- 1- 2 1011103 DTE NP= 1- 1- 1- 3 1011203 DTE NP= 1- 1- 2- 3 1011204 DTE NP= 1- 1- 2- 4 1012101 DTE NP= 1- 2- 1- 1 .....1012104 DTE NP= 1- 2- 1- 4 1015100 X29 1015200 MTP

ODA=6ND

7631 NEWODA= 07632 NEWODA= 07633 NEWODA= 07634 RC=127 7635 RC=127 ....7638 RC=127 7639 RC=127

ODA=99ND


166 R1B

76 NEWODA= 6

END

Command descriptions:

ILRAI The command defines number analysis data for a given number direction, ND.

ILDAP The command gives a printout of number analysisdata for one or all number directions.

ILNAI The command is used to define a name for a pre-defined NTN and insert the name and NTN in theaddressing by name analysis.

ILNAP The command is used to print the addressing byname analysis data.

ILDNI Destination to network terminal relation.

ILDNP Destination to network terminal relation.

ILTEI Assigns a NTN to a network port, dedicated line.

ILTEP Prints NTN and terminals.

8.7.2 RoutingRouting 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 anal-ysis 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.

DCS Applications

R1B 167

Figure 8.11DCS 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 com-mands are used:

ComputerNTN=65392Computer

NTN=42

ROT=76

ROT=75

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


168 R1B

ILROI The command defines a new route and inserts oneor more network ports into the route. It also insertsnetwork ports into an existing route.

ILROC The command is used to change route data for anexisting route.

ILROP The command is used to print route data.

ILROR Removal of route data.

ILRCI The command defines a routing case with its asso-ciated routes.

ILRCP The command prints routing cases.

ILRCR Removal of routing cases.

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 CallsA 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 pre-defined users only when one of the users wants to use the circuit (compare Hotline).

DCS Applications

R1B 169

Figure 8.12Hot virtual circuit

Command example:

:ILPCI:NTNA=1012104,NTNB=1015100;

In the example above the network terminal number 1012104, which repre-sents 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 Termi-nal Protocol OSI layer 7, and then passed on to MCS.

The circuits are printed with command ILPCP and removed with com-mand 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.

IOG20

X.29,NTN=1015100

AT-7NTN=1012104

Hot virtual circuit

V.24 physical interface

X.28/X.3


170 R1B

8.7.4 Access controlThe 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 prior-ity 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 LinesIt 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 stati-cally allocated ports (if such a link was using PCM media - or was con-verted 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 Net-work 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 portsThe 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.

DCS Applications

R1B 171

In order to define a port, a series of commands must be given. The proce-dure 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 termi-nal 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 com-munication 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 neces-sary at some stage to define a new Line Unit.

8.8.1 GeneralAfter 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 cus-tomer.

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 ATTo 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 UnitCommand example:

<IMLCT:SPG=0;:ILLUP:LU=CM-LM-LU;


172 R1B

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

8.9.2 Network portCommand 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 portThe 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 NumberThe next step is to assign a Network Terminal Number, NTN, to the net-work port.

DCS Applications

R1B 173

Figure 8.13Network 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 ear-lier in the section on addressing).

:ILTEI:NTN=ntn,NP=np;

8.9.5 Deblock the PortThe 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 ProtocolThe 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;

NTN = 1 01 2 3 04NP = 1 - 2 - 3 - 4

NP, PP

Line module

Line unit

Communication moduleAlways ‘1’

NTN = 1 01 1 4 01NP = 1 - 1 - 4 - 1

NP, PP

Line module

Line unit

Communication moduleAlways ‘1’


174 R1B

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 DirectoriesThe 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 ter-minal and the NTN for the port are registered, together with data indicat-ing 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 ter-minal 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 Direc-tory. 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 NTNThe identity of the terminal to be connected to the NTN is defined:

:MCDVI:IO=AT-n,NTN=1011203;:END;

8.9.9 Size Alteration EventsCheck SAE 344 (Records in block ASCP = the number of session chan-nels toward DCS for alpha terminals, i.e. the number of simultaneous com-mand/printout sessions required).

<SAAEP:SAE=344;

If necessary, increase the size:

DCS Applications

R1B 175

<SAAII:SAE=344,NI=ni;

Check the IO device data records in the CP:

<SAAEP:SAE=800,BLOCK=AT;


<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 LinkThe 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 commu-nication computer which switches between different exchanges) or some other such device. These would normally be used for alphanumeric com-munication, 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 destina-tion 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.


176 R1B

In our case, the destination is the Session Port for Message Transfer Pro-tocol (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 desti-nation AOM it would be defined using an AOM command.

Figure 8.14Addressing in data network

For traffic in the opposite direction, it follows that, at the OMC, the Net-work 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 PortCommand example:

ComputerNTN=150

Session portMTPNTN=250

IOG20

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

ROT=1

ROT=2

AMTP-n

DCS Applications

R1B 177

: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 portThe physical port is now tested.

:ILLTI:PORT=pp,LOOP=1;

8.10.4 Network Terminal NumberAs 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 Fig-ure 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 alphanu-meric communication, file transfer or Direct File Output.

The first two cases are covered here. For the case Direct File Output see the corresponding OPI.


178 R1B

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 PortThe 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 alpha-numeric information. (AMTP - Alphanumeric communication using MTP.) The command links the IO device to the Network Port’s NTN.

:MCDVI:IO=AMTP-n,NTN=150;:END;

8.10.9 Size Alteration Events <SAAEP:SAE=344;


<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 OMCThe 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 TransferIf 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;

DCS Applications

R1B 179

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 Mod-ule 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


180 R1B

R1B 181

9. Support Processor Subsystem (SPS)


9.1 IntroductionThis chapter describes functions in the support processor subsystem.

9.2 GeneralSPS 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 hard-ware 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 SPSThe 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.

Chapter Objectives


• Know the hardware units included in SPS


182 R1B

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 SPSThe 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 Eri-Pascal 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


• 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 dif-ferent processes contained in the program modules, time supervision for sending periodic signals, and administration of the primary memory.

Support Processor Subsystem (SPS)

R1B 183

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 GeneralThe SP hardware administration function keeps a list of some of the hard-ware 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 TableThe 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;


184 R1B

SP HARDWARE DATA

SPG NODE0 A

UNIT NAME ADDR DESCR SPARE INDEX UFIELDVD-1 ACIA 25 STD **** 1 T..113NA-1 BNA 00FA **** 1 ------HD-1 DISK_SC **** 1 H31001OD-1 DISK_SC **** 4 O14001CONFIG-1 CONFIGURATIO **** 1 IOG20WSU-1 MEMORY WSU **** 1 32SCSI-1 SCSI **** 3 5FD-1 FDC **** 1 1 11FFDI-1 FDI **** 1 1FDIADM-1 FDIADM **** 1 1VSA-1 EBA_VSA **** 1 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 pro-grams 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 TableThis table is created from the data in the module SPHWTABLE by the module SPHWADM the first time it receives one of the HW administra-tion commands. The default table is then stored in the volume OMFZLI-BORD.


R1B 185

Figure 9.2SP 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 possi-ble units in the IOG20.

Default SP hardware data:

SP HARDWARE DATA

SPG NODE0 A

UNIT NAME ADDR DESCR SPARE INDEX UFIELDVD-1 ACIA 25 STD **** 1 T..113NA-1 BNA 00FA **** 1 ------HD-1 DISK_SC **** 1 H31001HD-2 DISK_SC **** 1 H31002HD-3 DISK_SC **** 1 H31003OD-1 DISK_SC **** 4 O14001CONFIG-1 CONFIGURATIO **** 1 IOG20WSU-1 MEMORY WSU **** 1 32SCSI-1 SCSI **** 3 5FD-1 FDC **** 1 1 11F

CommandIMHWP

VolumePROG_A

Hard diskA-node Volume

OMFZLIBORD

SP HWtable

ExecutingSP HWtable

CommandsIMHWI,IMHWC

SP HWtable

PrimarymemoryA-node

DefaultSP HWtable


186 R1B

FDI-1 FDI **** 1 1FDIADM-1 FDIADM **** 1 1VSA-1 EBA_VSA **** 1 1

END

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

SPG0

NODE UNIT OPMODEA VD-1 READYA RPV-1 READYA HD-1 READYA NA-1 READYA FD-1 READYA OD-1 READY

END

9.5.4 OperationWhen 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.


R1B 187

To print the data defined in the hardware table for a given node, the com-mand 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 com-mand 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 def-inition 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 Erics-son 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 ImplementationThe function is handled by the function block SPHWADM which consists of two modules: SPHWADM and SPHWTABLE.

The module SPHWADM administers the function. The module SPH-WTABLE 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.


188 R1B

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 func-tions, 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 administra-tion 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.

R1B 189

10.Start of SPG


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

10.2 GeneralOnce all hardware has been installed in the exchange and the cabling con-nected and tested then the first step in starting up the exchange is the start-ing 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

Chapter ObjectivesAfter 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’


190 R1B

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 com-plicated 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 configura-tions 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 dis-kette 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 vol-umes 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 SystemThere are two types of systems that can execute in a IOG20 node.

• ‘large’, or ordinary, SP system

• start system

Start of SPG

R1B 191

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 reinitial-ization 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 dis-kette 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)


• 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 commu-nication via the network ports on the LUM boards. The only working ter-minals 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 sys-tem differs slightly.

10.4 RequirementsThe 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


192 R1B

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 ProcedureAs 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 infor-mation containing a pointer to the so called System Start Information, SSI, file on the disk.

Start of SPG

R1B 193

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 SP’s 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 communi-cation 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 soft-ware to the relevant volumes on hard disk and creating the required sys-tem 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 OMFZLI-BORD 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.


194 R1B

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 com-mand FCSII which is given later. LNODE is used to say in which node’s 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 it’s 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 vol-ume 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 SP’s primary memory. Com-mand FCSDL.

The SDF lists the modules with revision status that are included in the sys-tem.

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 Meas-urement Subsystem and Statistics Subsystem - then the extra modules may possibly be file-loaded. Normally all modules are boot-loaded.

Start of SPG

R1B 195

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 sys-tem 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 sys-tem 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 node’s 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 it’s own system and an SSR for loading the remote node’s 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 dur-ing function change would normally be done by the command FCSSI, but in a small system has to be performed separately. Command FCSII.


196 R1B

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 con-tains the absolute addresses (tracks and sectors) of the modules in the sys-tem.

When the system is later manually loaded using the reset switch, the load-ing 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 NodesWhenever both nodes are started, all files belonging to the duplicated vol-ume 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-

Start of SPG

R1B 197

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 sin-gly (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 com-mand 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 CP’s 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 cop-ied 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 writ-ten directly on the disks and in the CP data.

The command INFUI can always be used to adjust the CP’s file table so that it corresponds to the file attributes defined on hard disk. This com-mand is always performed automatically at a system restart of the CP.

10.7 Command Initiated Restart of NodeA 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 work-ing 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.


198 R1B

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 revi-sion 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.

EN/LZT 101 1611 R1C© Ericsson Telecom AB

Ericsson Telecom ABMV/ETX/X/HCXS-126 25 Stockholm, SwedenTelephone: +46 8 719 9222

Subj

ect t

o al

tera

tions

with

out p

rior

not

ice.

Pri

nted

in S

wed

en.

1.InputOutput Group 20, IOG 20

Documents

Transcript of 1.InputOutput Group 20, IOG 20